Re: using tuple as value type for associative array
On Thursday, 21 June 2018 at 03:04:46 UTC, Computermatronic wrote: On Thursday, 21 June 2018 at 02:44:12 UTC, Flaze07 wrote: when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ? what["something"].first = 20 will attempt to get an element of what, then assign a member, while what2["something"] = 20 will add an element to what2 with the value of 20. Since what["something"] is not present, it will throw a range error. Try what["something"] = tuple(20, 0); instead. huh, interesting, thanks
Re: using tuple as value type for associative array
On Thursday, 21 June 2018 at 02:44:12 UTC, Flaze07 wrote: when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ? what["something"].first = 20 will attempt to get an element of what, then assign a member, while what2["something"] = 20 will add an element to what2 with the value of 20. Since what["something"] is not present, it will throw a range error. Try what["something"] = tuple(20, 0); instead.
using tuple as value type for associative array
when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ?
Re: Vibe D Examples
On Wednesday, 20 June 2018 at 22:46:16 UTC, infinityplusb wrote:
I'm trying to reacquaint myself with D, and Vibe in particular.
I notice that some of my previous working apps now don't work.
While going through the tour.dlang page, I can't seem to get
any of those sample apps working either. Nor do the apps in
Vibe's github page appear to be up to date with the recent
changes.
Are there some current, simple, working examples that I could
plagiarise to get something going?
TIA
Brian
Nevermind. Simple case of RTFM ...
-- source/app.d
import vibe.d;
void main()
{
auto settings = new HTTPServerSettings("127.0.0.1");
settings.port = 48081;
auto router = new URLRouter ;
router
.get("/", &homeScreen)
;
listenHTTP(settings, router);
runApplication();
}
void homeScreen(HTTPServerRequest req, HTTPServerResponse res)
{
// res.writeBody("Hello again Vibe.d: ");
res.render!("home.dt") ;
}
-- views/home.dt
doctype html5
head
title Hello World
body
p Hello template vibe
Vibe D Examples
I'm trying to reacquaint myself with D, and Vibe in particular. I notice that some of my previous working apps now don't work. While going through the tour.dlang page, I can't seem to get any of those sample apps working either. Nor do the apps in Vibe's github page appear to be up to date with the recent changes. Are there some current, simple, working examples that I could plagiarise to get something going? TIA Brian
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 05:49:15 UTC, Dukc wrote:
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote:
Is there anything I can do to improve zip, before I go ahead
and change to the faster but slightly less readable enumerate?
The problem might be that zip checks both arrays for empty
during each step, enumerate only the first one. Try appending
takeExactly(1000) on the result of zip. It might be even faster
than enumerate.
takeExactly didn't change the timings at all.
I did write a rough zip function that took advantage of random
access inputs and didn't need to account for different stopping
policies:
auto myZip(R1,R2) (R1 r1, R2 r2) {
struct MyZip(R1,R2) {
size_t index=0;
R1 rng1;
R2 rng2;
size_t length;
this (R1 r1, R2 r2) {
rng1=r1;
rng2=r2;
index=0;
length=r1.length;
}
auto empty() { return index==length; }
auto front() { return tuple(rng1[index],rng2[index]); }
void popFront() { index++; }
}
return MyZip!(R1,R2)(r1,r2);
}
This ended up being 40% faster than normal zip, both DMD 32/64.
I briefly tested with LDC and didn't notice any difference, which
I thought was weird, but didn't have time to investigate further.
That fact that zip is slower is not bad, as it provides far more
flexibility, different stopping policies, all types of ranges.
What is interesting (TBC) is the fact that it's only noticeably
slower using DMD.
Jordan
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote: I suppose that. [snip] I suppose that would be good.
Re: Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
On 06/20/2018 08:06 AM, rikki cattermole wrote: This board is for the D programming language. The one you want is https://forum.dlang.org/group/c++ And the Lesson 1 he wants is http://ddili.org/ders/d.en/hello_world.html :o) Ali
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. - This can be a problem if the project is very active. This issue was noticed by the people who converted DMD compiler from C++ to D and finally a dedicated tool was used, improved until some CI tests passed. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? - The runtime can be initialized by hand if it's required, see core.runtime.Runtime.initialize()
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? I'm a little confused...you mean like embedr [1, 2] and pyd [3], but for Octave and Matlab? The idea would that you could write functions in D and call them in Matlab/Octave, and vice-versa. I suppose that. I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add... There was an old forum post years ago on the subject [4], but the link to the repository is dead. [1] https://bitbucket.org/bachmeil/embedr [2] https://github.com/bdilday/embedr [3] https://code.dlang.org/packages/pyd [4] https://forum.dlang.org/thread/op.vhjavyoc3nc...@enigma.fem.tu-ilmenau.de
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? With respect to this part of your question, you might want to check out https://dlang.org/spec/betterc.html and especially the limitations https://dlang.org/spec/betterc.html#consequences It shouldn't take much to do this, but the limitations of betterC are not minor.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? I've looked into this a bit, but haven't had time to do anything with it. My opinion is that the starting point is to add functionality using Oct-Files. The reason is that it is the simplest way to do so in a way that you can share your work with others. That allows you to call into the Octave API and reuse that code. Given the recent work on C++ interoperability, I think this strategy is the clear winner.
Is it feasible to slowly rewrite a C++ codebase in D?
I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas?
Re: Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
This board is for the D programming language. The one you want is https://forum.dlang.org/group/c++
Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
I am a newbe to the C/C++ Development System. I downloaded the C/C++ Development System a couple of days ago. In following the directions for Lesson 1: Create the DOS Application, when I did the Rebuild (called for in the instructions), I got an error: Error: c:\dm\lib\sds.lib(cinit) : Previous Definition Different : __Exit. The instructions say nothing about this. Is there something missing in the instructions for Lesson 1?
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:54:29 UTC, Per Nordlöw wrote:
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
Oops, this doesn't work for enums with "holes". How do I most
easily fix that?
This is my solution:
T toDefaulted(T)(scope const(char)[] value, T defaultValue) @safe
pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (member; __traits(allMembers, T))
{
case member:
mixin(`return T.` ~ member ~ `;`);
}
default:
return defaultValue;
}
}
Is there a way to avoid compile-time-string-concat plus mixin
here?
Re: What is the point of nothrow?
On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote: But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ? I just read stack trace from console. Initially D ecosystem focused on windows console applications, linux support came later, and compiling windows gui application is not straightforward. Simply because console support is the first thing to implement. And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ? The state is invalid in a sense that program shouldn't continue to serve its intended purpose. And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)? In most cases stack trace is enough to diagnose the error. and provides a better UX than a core dump (especially to Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself. Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.
Re: Nothrow std.conv.to with explicit default value
On Wednesday, June 20, 2018 09:37:00 Per Nordlöw via Digitalmars-d-learn wrote: > On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote: > > On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer > > > > wrote: > >> It just means re-doing std.conv.to, which is pretty hairy, but > >> also pretty well-organized. > > > > Ok. Where in std.conv do the string-to-enum conversions take > > place? > > AFAICT, string-to-enum-conversion must include a switch > containing a static foreach over all the enumerators, right? If you want to know where std.conv deals with converting enums, look for EnumMembers, since that's the trait to get all of the members of an enum. - Jonathan M Davis
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:37:00 UTC, Per Nordlöw wrote:
AFAICT, string-to-enum-conversion must include a switch
containing a static foreach over all the enumerators, right?
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
default:
return defaultValue;
}
}
@safe pure nothrow /*TODO @nogc*/ unittest
{
enum E { unknown, x, y, z }
assert("x".toDefaulted!(E)(E.init) == E.x);
assert("_".toDefaulted!(E)(E.init) == E.unknown);
}
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:52:04 UTC, Per Nordlöw wrote:
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
Oops, this doesn't work for enums with "holes". How do I most
easily fix that?
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote: On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer wrote: It just means re-doing std.conv.to, which is pretty hairy, but also pretty well-organized. Ok. Where in std.conv do the string-to-enum conversions take place? AFAICT, string-to-enum-conversion must include a switch containing a static foreach over all the enumerators, right?
Re: Nothrow std.conv.to with explicit default value
On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer wrote: It just means re-doing std.conv.to, which is pretty hairy, but also pretty well-organized. Ok. Where in std.conv do the string-to-enum conversions take place?
