New libraries wave-d and y4m-d
wave-d is a library for reading and writing WAV format (range-based). https://github.com/p0nce/wave-d --- y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d Y4M is one of the simplest uncompressed video format, it's designed to provide a bit of meta-data over raw YUV files.
Re: New libraries wave-d and y4m-d
There was a typo error: https://github.com/p0nce/y4m-d On Tuesday, 29 April 2014 at 18:46:51 UTC, ponce wrote: y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d
Re: New libraries wave-d and y4m-d
On Tuesday, 29 April 2014 at 18:48:33 UTC, ponce wrote: There was a typo error: https://github.com/p0nce/y4m-d On Tuesday, 29 April 2014 at 18:46:51 UTC, ponce wrote: y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d I checked out y4m-d when it went up on the dub repository. Looks interesting. I do have to ask, are you interested in creating a unified library for multimedia with a importers/exporters a bit like ASIMPP? Because I think that could be rather useful and not too much work on top of the given types already had.
Re: DIP61: redone to do extern(C++,N) syntax
On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote: First off, I expect std to be put in core.stdcpp.std, and then imported. So this issue would only happen if 3rd party A and 4th party B each imported 5th party C. Yeah, it'll happen, and it'll still work, as the import system regards the same file as being the same import regardless of the import path used to get to it. No, it'll happen if they use the same vector library an #include the same vector3D and independently specify their own binding? But if they cooperate and use the same binding, then you are ok? That makes no sense. It's no different than if you have: A::foo() in one framework, and a different: A::foo() in another framework. It won't work in C++, either. That is only true if you mangle D modules and C++ namespaces the same way. You should be able to have A.foo and A::foo. It makes no sense to conflate the paths if they mangle differently. The problem is that you are forced to qualify the D-binding rather than the path of the cpp function. This will only work out ok if different framework authors cooperate. Not correct. This is not a problem. I can mix two independent cpp bindings without casting? Remember, a C++ signature is the same as its type in C++, but that is not true of D. And that makes it tedious to interact with C++? I don't see how it makes it any more tedious than dealing with the ODR rule in C++ anyway. Why not? It only applies to the translation unit. I see no relationship.
listing template function overloads for use in compile time decisions
Let's say that we have a struct `A` that contains some template
function named `fn` template-parameterized on its argument types:
struct A {
...
void fn(A)(auto ref A a) { ... }
...
}
I cannot get a handle on `fn` as an alias when searching for
overloads of the string fn in `A` via
`__traits(getOverloads,A,fn)`. This makes sense, obviously,
because `fn` doesn't really 'exist' as a template.
But the compiler can, nevertheless, generate a proper
implementation of `fn` depending on its argument(s). It doesn't
have to create the code, as with e.g. `__traits(compiles,
A.init.fn(0))`. While it doesn't make sense to list overloads of
a given name when they're templates, it does make sense that
given some argument types and qualifiers all candidate functions
can be easily enumerated. I can't find such a feature, however.
Moreover, I cannot figure out how one could acquire a handle on
even *just* the best match for a given function name with some
given argument types.
With this, library writers could perform their own overload
resolution without enforcing the use of wrapper classes when
trying to plug one library into another library, ex. lib A has
struct A with `fn` and lib B has struct B with `fn` and they have
functions `fn` that accept each other and we want to choose the
one that partially specializes on the other over the one that
doesn't. It's basically the decision process behind the rewriting
that occurs with a.opCmp(b) vs. b.opCmp(a), but fully emulated in
the presence of templates without extra client-code-side hints
and taking into account granularity finer than the four levels of
overload resolution. It moves glue-code (or glue-behavior like
argument ordering to a library function) from the user to the
library writer, and allows that glue-code to be generic.
Is this a facility that is present in D, and I missed it? Are any
of the above bulleted use-cases manageable with present-day D?
I'm kind of an obsessive metaprogramming-fiend, so this little
issue is strangely vexing. I've come up with an idea for a
solution, and am attempting to implement it, but it's
extraordinarily hackish. It assumes that the name `fn` when
called can be entirely resolved with its arguments by looking at
the arguments' types and their template parameters (if any) and
implicit target conversions (and their template parameters [if
any]). I'm seeing in my head a combinatoric blow-up from the
possible orderings of template arguments in the template
declaration of `fn`, so... yeah. Kinda would like a __traits
thing that gets all possible resolutions of a symbol in a call
expression.
Thanks for your time~!
Re: listing template function overloads for use in compile time decisions
On Tuesday, 29 April 2014 at 06:22:34 UTC, Atash wrote:
Let's say that we have a struct `A` that contains some template
function named `fn` template-parameterized on its argument
types:
struct A {
...
void fn(A)(auto ref A a) { ... }
...
}
I cannot get a handle on `fn` as an alias when searching for
overloads of the string fn in `A` via
`__traits(getOverloads,A,fn)`. This makes sense, obviously,
because `fn` doesn't really 'exist' as a template.
But the compiler can, nevertheless, generate a proper
implementation of `fn` depending on its argument(s). It doesn't
have to create the code, as with e.g. `__traits(compiles,
A.init.fn(0))`. While it doesn't make sense to list overloads
of a given name when they're templates, it does make sense that
given some argument types and qualifiers all candidate
functions can be easily enumerated. I can't find such a
feature, however.
Moreover, I cannot figure out how one could acquire a handle on
even *just* the best match for a given function name with some
given argument types.
With this, library writers could perform their own overload
resolution without enforcing the use of wrapper classes when
trying to plug one library into another library, ex. lib A has
struct A with `fn` and lib B has struct B with `fn` and they
have functions `fn` that accept each other and we want to
choose the one that partially specializes on the other over the
one that doesn't. It's basically the decision process behind
the rewriting that occurs with a.opCmp(b) vs. b.opCmp(a), but
fully emulated in the presence of templates without extra
client-code-side hints and taking into account granularity
finer than the four levels of overload resolution. It moves
glue-code (or glue-behavior like argument ordering to a library
function) from the user to the library writer, and allows that
glue-code to be generic.
Is this a facility that is present in D, and I missed it? Are
any of the above bulleted use-cases manageable with present-day
D?
I'm kind of an obsessive metaprogramming-fiend, so this little
issue is strangely vexing. I've come up with an idea for a
solution, and am attempting to implement it, but it's
extraordinarily hackish. It assumes that the name `fn` when
called can be entirely resolved with its arguments by looking
at the arguments' types and their template parameters (if any)
and implicit target conversions (and their template parameters
[if any]). I'm seeing in my head a combinatoric blow-up from
the possible orderings of template arguments in the template
declaration of `fn`, so... yeah. Kinda would like a __traits
thing that gets all possible resolutions of a symbol in a call
expression.
Thanks for your time~!
Ignore the 'bulleted' bit. I edited that preceding section from a
list to a paragraph.
Re: python vs d
On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote: Paulo Pinto: Pascal expatriates like myself won't consider indexes from 1 a design mistake. :) What's the good of having all arrays always start from index 1 (this is different from Ada, where you can choose the indexing range and type)? Bye, bearophile True, in Pascal languages you can choose the starting index.
Re: DIP61: redone to do extern(C++,N) syntax
On 4/28/2014 11:06 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote: First off, I expect std to be put in core.stdcpp.std, and then imported. So this issue would only happen if 3rd party A and 4th party B each imported 5th party C. Yeah, it'll happen, and it'll still work, as the import system regards the same file as being the same import regardless of the import path used to get to it. No, it'll happen if they use the same vector library an #include the same vector3D and independently specify their own binding? But if they cooperate and use the same binding, then you are ok? That makes no sense. I simply don't know what you're talking about when you use the word binding. It's no different than if you have: A::foo() in one framework, and a different: A::foo() in another framework. It won't work in C++, either. That is only true if you mangle D modules and C++ namespaces the same way. C++ identifiers do not get the module name mangled in. You should be able to have A.foo and A::foo. It makes no sense to conflate the paths if they mangle differently. There is no A::foo in D. The problem is that you are forced to qualify the D-binding rather than the path of the cpp function. This will only work out ok if different framework authors cooperate. Not correct. This is not a problem. I can mix two independent cpp bindings without casting? Casting has nothing to do with symbol lookup. Why not? It only applies to the translation unit. I see no relationship. I'm sorry, I do not understand what your mental model of how this works is. Perhaps if you wrote your questions in terms of D code examples, I can answer them.
Re: DIP61: redone to do extern(C++,N) syntax
On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote: No, it'll happen if they use the same vector library an #include the same vector3D and independently specify their own binding? But if they cooperate and use the same binding, then you are ok? That makes no sense. I simply don't know what you're talking about when you use the word binding. You bind the C++ extern to a D path, and as a result you get 2 types because you have 2 paths rather than one. (according to what you have said) If they mangle to the same name then I want them to be the same type. As a result I am better off when using pure C++ frameworks and creating my own D layer than when I am using 2 mixed D/C++ frameworks that have been developed independently. C++ identifiers do not get the module name mangled in. An therefore they should be seen as the same type!
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 12:10 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote: No, it'll happen if they use the same vector library an #include the same vector3D and independently specify their own binding? But if they cooperate and use the same binding, then you are ok? That makes no sense. I simply don't know what you're talking about when you use the word binding. You bind the C++ extern to a D path, and as a result you get 2 types because you have 2 paths rather than one. (according to what you have said) If they mangle to the same name then I want them to be the same type. The namespace contributes to the mangling of C++ symbols, but has no contribution to its type. As a result I am better off when using pure C++ frameworks and creating my own D layer than when I am using 2 mixed D/C++ frameworks that have been developed independently. C++ identifiers do not get the module name mangled in. An therefore they should be seen as the same type! The type is not a scope.
Re: DIP61: redone to do extern(C++,N) syntax
Basically, Ola, if you could write a piece of sample D code that you feel will not work, please do so.
Re: python vs d
On 4/28/2014 7:02 PM, bearophile wrote: Nick Sabalausky: VB6 let you choose your starting index, too. It was rarely useful and constantly made array-handling code a pain in the ass. Of course, VB made pretty much everything a PITA...(I used to work at a VB6 house. *shudder*) (As far as I know, and I am ignorant about Julia) in Julia you can't choose the start index of an array, they start from index 1. So the situation is not the same as VB. I have written more Delphi code than D code, and I've seen that being able to choose the index range is quite useful, you can use enumerations and characters to index arrays :-) You avoid c - '0' the idiom used in D, and associative arrays with enum keys, while keeping the code very efficient and generally not bug-prone. I don't know VB much, but all language features should not be abused. And they work or fail not just being good themselves, but in the context (and ecology) of all other features of a language. This means choosing arrays index types and start values is very good in Ada, it's rarely a PITA. But perhaps a similar feature is not good if used in VB. Ada has a very strong static typing, so being able to specify array index types gives you back lot of safety that probably is not available in VB. So the return of investment is probably different. Yea. To be perfectly fair, classic VB made pretty much anything a pain. I imagine a better language could probably manage custom index ranges much better than VB6 did. In VB6, it was a pain because of iterating over the elements. Since it lacked anything like foreach (as I recall), the simplest iterate over an array was something like (from memory, might not have it exact): FOR index = 0 TO Len(myArray) *But* that code was wrong. It would *usually* work, and then suddenly blow up whenever someone used a different starting index. So instead, it was best to use this syntactic mess every time you iterated: FOR index = LBound(myArray) TO UBound(myArray) Ugh, I don't miss VB. Worse still, it was so simple it encouraged companies (like the one where I worked) to use programmers who were absolute bottom-level and wrote the WORST code. I saw shit at that job that (I'm not exaggerating here) even CS 101 students know not to do. It was amazing any of our codebase even worked at all. Back to the point though, having never looked at Julia, I assume it probably does a much better job of this stuff than VB did.
Re: python vs d
On Monday, 28 April 2014 at 23:02:03 UTC, bearophile wrote: I think it could be a good idea to add something intermediate to D: optional strong typing for array indexing. I'd like to write a DIP on this someday (note that this does not mean I am suggesting D array indexes to optionally start from values different from 0. I am referring just to types, and enumerations are could be not supported). Bye, bearophile Any reason why this needs language support? I haven't tried it, but I can't see why it can't be trivially done in a library.
Re: STUN/TURN servers
On Tuesday, 29 April 2014 at 01:21:36 UTC, Vladimir Panteleev wrote: On Monday, 28 April 2014 at 18:36:59 UTC, Radu wrote: Every time I read anything related to STUN/TURN, it becomes obvious that these technologies were designed by some committee. Metric tons of technical jargon and bureaucratic overhead with an absurdly overcomplicated protocol to achieve such a simple thing. I implemented basic concept behind the TURN server, a TCP relay: http://worms2d.info/WormNAT2 The protocol is much simpler. As soon as a connection is received, it allocates a port and sends it to the client. This is the public port allocated for the connection - peers wishing to connect to the client can connect to that port on the relay server and talk as if they were talking to the client directly. Every time a peer connects, the server allocates a temporary port for the client to connect to, and sends it over the original control connection. After the client connects to said port, they can start talking to the peer directly, as if there's no proxy in-between. This avoids complicated handshakes, headers, and having to modify your protocol and wrap every single packet in a stupid header. It's also based on TCP, so you don't have to reimplement reordering, retransmission etc. on top of UDP all over again. It's not open-source, and although I could share the source code, it's not Vibe'd (D1 in fact). The implementation is very simple, though. Vibed is in D1? Are you sure? I can't seem to find any mention of that, it works with the current DMD, but then again I've never tried to compile a D1 program with it. Thhanks for you're answer, but I was looking for something a little more comprehensive, something that will work with WebRTC, that means binary or encoded messages, audio and video communication. It may seem hard to understand of you read the official documents but there are server examples written in C, C++, Java, Python, Erlang and node.js all open-source. I was hoping to find one written in D too. Oh well...
Re: python vs d
On Tuesday, 29 April 2014 at 08:21:04 UTC, John Colvin wrote: On Monday, 28 April 2014 at 23:02:03 UTC, bearophile wrote: I think it could be a good idea to add something intermediate to D: optional strong typing for array indexing. I'd like to write a DIP on this someday (note that this does not mean I am suggesting D array indexes to optionally start from values different from 0. I am referring just to types, and enumerations are could be not supported). Bye, bearophile Any reason why this needs language support? I haven't tried it, but I can't see why it can't be trivially done in a library. Pascal example: type colors = (red, blue, yellow); var pallete : array colors of integer; begin pallete[red] := 4; end You want a compiler error if the index is invalid and bounds checking when iterating over the enumeration and using it as indexes. Probably possible with some heavy duty compile time metaprogramming, not sure about the quality of possible error messages and if it would cover all scenarios Pascal and Ada allow for. -- Paulo
Re: DIP61: redone to do extern(C++,N) syntax
On Tuesday, 29 April 2014 at 07:50:41 UTC, Walter Bright wrote:
Basically, Ola, if you could write a piece of sample D code
that you feel will not work, please do so.
But I did?
framework1.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,graphics){ void g(vec4 …) … }
application1.d:
import framework1;
import framework2;
graphics.g( physics.f(…) ); // you said this would not work?
-
myframework.d
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
extern(C++,graphics){ void g(vec4 …) … }
application2.d
import myframework;
graphics.g( physics.f(…) ); // but now it works?
tuple can write [],but can't read []
Hi,erveryone,
type Tuple!(int,int,int,string) can write[],but can't read[];
module main;
import std.stdio,std.typecons,std.conv;
void main(string[] argv)
{
alias Tuple!(int,int,string) tuple2;
alias Tuple!(int,int,string)[10] tupleS2;
void bbx(tupleS2 x)
{
foreach(v;x)
{
writeln(v);
foreach(k;v)
writeln(k);
}
}
tupleS2 xy2;
foreach(i,v;xy2)
{
xy2[i] = tuple2(1,-1,xy2 :~i.to!string);
}
xy2[1][0]=100; // can write
bbx(xy2);
for(int i=0;i3;i++)
{
writeln(xy2[0][i]); // can't read
}
}
---code end--
if use the 'for(int i=0;i3;i++)' ,then error.
Error: no [] operator overload for type Tuple!(int, int, int,
int, int, int, int, int, int, int, int, string)
Thank you.
Frank
Re: tuple can write [],but can't read []
On Tuesday, 29 April 2014 at 09:23:03 UTC, FrankLike wrote: Hi,erveryone, [...] xy2[1][0]=100; // can write [...] writeln(xy2[0][i]); // can't read [...] If I'm right, index should be a compile-time value.
Re: tuple can write [],but can't read []
Andrea Fontana: If I'm right, index should be a compile-time value. Right. Because tuples in general don't contain N values of the same type (as in your case), so the compiler has to know statically the index to compute their position efficiently. Further similar questions are better asked in D.learn. I also suggest to not mix tab and spaces to indent code, configure your editor to use only spaces or only tabs (4 spaces is the D standard). Bye, bearophile
Re: tuple can write [],but can't read []
On Tuesday, 29 April 2014 at 09:38:45 UTC, Andrea Fontana wrote: On Tuesday, 29 April 2014 at 09:23:03 UTC, FrankLike wrote: Hi,erveryone, [...] xy2[1][0]=100; // can write [...] writeln(xy2[0][i]); // can't read [...] If I'm right, index should be a compile-time value. index is exists,but not be read,why? Thank you.
Re: tuple can write [],but can't read []
On Tuesday, 29 April 2014 at 09:23:03 UTC, FrankLike wrote:
Hi,erveryone,
type Tuple!(int,int,int,string) can write[],but can't read[];
module main;
import std.stdio,std.typecons,std.conv;
void main(string[] argv)
{
alias Tuple!(int,int,string) tuple2;
alias Tuple!(int,int,string)[10] tupleS2;
void bbx(tupleS2 x)
{
foreach(v;x)
{
writeln(v);
foreach(k;v)
writeln(k);
}
}
tupleS2 xy2;
foreach(i,v;xy2)
{
xy2[i] = tuple2(1,-1,xy2 :~i.to!string);
}
xy2[1][0]=100; // can write
bbx(xy2);
for(int i=0;i3;i++)
{
writeln(xy2[0][i]); // can't read
}
}
---code end--
if use the 'for(int i=0;i3;i++)' ,then error.
Error: no [] operator overload for type Tuple!(int, int, int,
int, int, int, int, int, int, int, int, string)
Thank you.
Frank
Tuple indexes must be compile-time values. This will work:
import std.stdio, std.typecons, std.conv, std.typetuple;
void main()
{
alias Tuple!(int, int, string) tuple2;
alias Tuple!(int, int, string)[10] tupleS2;
void bbx(tupleS2 x)
{
foreach(v; x)
{
writeln(v);
foreach(k;v)
writeln(k);
}
}
tupleS2 xy2;
foreach(i, v; xy2)
{
xy2[i] = tuple2(1, -1, xy2 : ~ i.to!string);
}
xy2[1][0]=100;
bbx(xy2);
foreach(i; TypeTuple!(0,1,2))
{
writeln(xy2[0][i]);
}
}
Re: STUN/TURN servers
On Tuesday, 29 April 2014 at 08:42:53 UTC, Radu wrote: On Tuesday, 29 April 2014 at 01:21:36 UTC, Vladimir Panteleev wrote: On Monday, 28 April 2014 at 18:36:59 UTC, Radu wrote: Every time I read anything related to STUN/TURN, it becomes obvious that these technologies were designed by some committee. Metric tons of technical jargon and bureaucratic overhead with an absurdly overcomplicated protocol to achieve such a simple thing. I implemented basic concept behind the TURN server, a TCP relay: http://worms2d.info/WormNAT2 The protocol is much simpler. As soon as a connection is received, it allocates a port and sends it to the client. This is the public port allocated for the connection - peers wishing to connect to the client can connect to that port on the relay server and talk as if they were talking to the client directly. Every time a peer connects, the server allocates a temporary port for the client to connect to, and sends it over the original control connection. After the client connects to said port, they can start talking to the peer directly, as if there's no proxy in-between. This avoids complicated handshakes, headers, and having to modify your protocol and wrap every single packet in a stupid header. It's also based on TCP, so you don't have to reimplement reordering, retransmission etc. on top of UDP all over again. It's not open-source, and although I could share the source code, it's not Vibe'd (D1 in fact). The implementation is very simple, though. Vibed is in D1? Are you sure? I can't seem to find any mention of that, it works with the current DMD, but then again I've never tried to compile a D1 program with it. No, he means that WormNAT2 is written in D1 and doesn't used Vibe.d Vibe.d is D2 only.
Default arguments in function callbacks not taken into account when instantiating templates has huge security implications
-
import std.traits;
import std.stdio;
void handler(C)(C callback)
{
callback(John);
}
void main()
{
auto safeCallback = (string user, string pass = hunter2)
{
writefln(The password is: '%s', pass);
};
handler(safeCallback);
someOtherFunc();
}
void someOtherFunc()
{
auto hijackPassword = (string user, string pass)
{
writefln(Now I know your password: '%s', pass);
};
handler(hijackPassword);
}
-
Re: python vs d
On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote: Libraries. not part of the language (unless you count the standard library. I don't see anything particularly special about python's standard library). Hmm… I think that for Python, Ruby and Perl, the libraries and the ecosystems to a large extent are part of the language. And I think the lack of C-like efficiency in the language encourage that, e.g. you don't really care that much about a library being 50% faster/slower. You care primarily about getting the job done. Not so with C/C++ libraries… For closures for arrays and dicts. I don't understand I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts. improvements. It's surprising how much python-style tuple code you can do in D already, but the syntax is a little lacking. But for tuples the ease-of-use syntax is important, otherwise you can just use struct or some other aggregate. Tuples are often used as anonymous on-the-fly structs. (Runtime integration of python and templates.) I presume you mean web templates? That is the most common scenario. This is a strong point in favour of an interpreted language, although the compile-time approach in vibe.d is powerful. As long as the code doesn't change too often, you can always recompile it and load as a shared library (I believe this is being looked at by vibe.d developers). Yeah, except when you build a CMS, but you can always include a scripting language. However, given the trade offs I still think I would prefer static typing (such as D) because runtime errors tend to show up after release. (Assuming fast on-the-fly compilation which is a must-have for web development.) Lots of how-to-stuff on the web. Ditto Actually, I think it is part of the language's resulting eco system. I believe toolbox languages like Python and Perl will have more recipes and nimble quick fix libraries on the web than application languages.
Re: python vs d
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad wrote: On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote: Libraries. not part of the language (unless you count the standard library. I don't see anything particularly special about python's standard library). Hmm… I think that for Python, Ruby and Perl, the libraries and the ecosystems to a large extent are part of the language. And I think the lack of C-like efficiency in the language encourage that, e.g. you don't really care that much about a library being 50% faster/slower. You care primarily about getting the job done. Not so with C/C++ libraries… For closures for arrays and dicts. I don't understand I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts. improvements. It's surprising how much python-style tuple code you can do in D already, but the syntax is a little lacking. But for tuples the ease-of-use syntax is important, otherwise you can just use struct or some other aggregate. Tuples are often used as anonymous on-the-fly structs. (Runtime integration of python and templates.) I presume you mean web templates? That is the most common scenario. This is a strong point in favour of an interpreted language, although the compile-time approach in vibe.d is powerful. As long as the code doesn't change too often, you can always recompile it and load as a shared library (I believe this is being looked at by vibe.d developers). Yeah, except when you build a CMS, but you can always include a scripting language. However, given the trade offs I still think I would prefer static typing (such as D) because runtime errors tend to show up after release. (Assuming fast on-the-fly compilation which is a must-have for web development.) Lots of how-to-stuff on the web. Ditto Actually, I think it is part of the language's resulting eco system. I believe toolbox languages like Python and Perl will have more recipes and nimble quick fix libraries on the web than application languages. My bet is that D users will be able to produce the same sort of quick-fix libraries. The newsgroups are dominated by systems-type people and there is a serious emphasis on super-low-cost abstractions, but in my opinion D is a more than suitable language for throwing together something that just does the job, but with much more pleasant routes for later optimisation than other languages.
Re: python vs d
On Tuesday, 29 April 2014 at 11:04:38 UTC, John Colvin wrote: My bet is that D users will be able to produce the same sort of quick-fix libraries. The newsgroups are dominated by systems-type people and there is a serious emphasis on super-low-cost abstractions, but in my opinion D is a more than suitable language for throwing together something that just does the job, but with much more pleasant routes for later optimisation than other languages. To a certain extent, but some things are just easier in a dynamic language. Like reading a xml file, then decorate the nodes with your own class attributes an properties, transform it and dump it back to file. Sure, you can do it in a stricter languge, but only if the library author planned for it.
Re: python vs d
On Mon, 2014-04-28 at 18:07 +, John Colvin via Digitalmars-d wrote: […] What features does python, as a language (syntactical preferences aside), actually have to recommend it over D (assuming drepl* or similar became full-featured)? This is definitely not a rhetorical question, it could be useful to D development. Principally there are a large number of users and installation and there is a wealth of support for different user bases from sys admins to quants. Python is a relatively small language that is easy to learn. The esoteric libraries can be a pain, but the core libraries do what they say on the can and are easy to use with a simple syntax. People can write working, tested code quickly without having to fight the fascist intransigence of a compiler. Most importantly though Python has penetration in the market so it is a safe choice. This is reinforced by the quants driving performance Python so that it can play in the CPU bound arena as well as the IO bound arena of sys admins and Web-related stuff. Ian Oszvald and co-author are just bringing a book to market about all this driven by the needs of the data scoence community This is as much about perception and marketing as about actual technical features. There is also an element of Python evolving to fit with what end-user programmers who aren't really programmers need. This is a self-reinforcing feedback loop. Python doesn't have a killer app, it invaded programming on multiple fronts to create a perception, and indeed reality, of all-pervasiveness as a programming platform. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: python vs d
On Tue, 2014-04-29 at 10:51 +, via Digitalmars-d wrote: […] I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts. Don't forget dictionary comprehensions and set comprehensions. And definitely don't forget generator expressions. And indeed generator functions. […] Yeah, except when you build a CMS, but you can always include a scripting language. Python vs Lua here. Photo-related C++ systems tend to drift to Lua for scripting. Post-production effects C++ systems seem to rely on Python. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: DIP61: redone to do extern(C++,N) syntax
On 2014-04-28 21:06, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
I believe Steven expects things to work this way:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // Calls bar.func (or is that bar.foo.func?)
}
It would call bar.foo.func(). But your example is different from Steven's.
It is. That was kinda the point. :p
Building on this knowledge:
module foo;
void func();
module bar;
extern(C++, foo) void func();
module prog;
import foo;
import bar;
void main()
{
// Seems like it's ambiguous between foo.func and bar.foo.func.
foo.func();
}
--
Simen
More on Heartbleed and related matters
Through Reddit I've found a nice blog post, Using Static
Analysis And Clang To Find Heartbleed:
http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/
The part about the range analysis is nice:
Ranges of symbol values:
conj_$2{int} : { [-2147483648, -2], [0, 2147483647] }
conj_$9{uint32_t} : { [0, 6] }
Unlike D, here the Clang compiler is keeping and managing those
ranges across different lines of code. This means that here C/C++
is more modernadvanced than D.
Then the blog post shows a small C program that contains a
Heartbleed-like bug:
int data_array[] = { 0, 18, 21, 95, 43, 32, 51};
int main(int argc, char *argv[]) {
int fd;
char buf[512] = {0};
fd = open(dtin, O_RDONLY);
if(fd != -1) {
int size;
int res;
res = read(fd, size, sizeof(int));
if(res == sizeof(int)) {
size = ntohl(size);
if(size sizeof(data_array)) {
memcpy(buf, data_array, size);
}
memcpy(buf, data_array, size);
}
close(fd);
}
return 0;
}
Using a language a little less primitive than C helps avoid those
bugs and to avoid several other mistakes that can happen in that
C example code.
This is hypothetical equivalent D code that I think it's less
bug-prone (perhaps I've missed some little part of the original C
code):
immutable int[$] data = [0, 18, 21, 95, 43, 32, 51];
void main() {
ubyte[512] buf;
auto fIn = dtin.File;
scope(exit) fIn.close;
immutable sizeBytes = fIn.tryRead!uint.Maybe!bswap;
if (!sizeBytes.isNull) {
if (sizeBytes.get data.sizeof) {
copyBytes(buf, data, sizeBytes.get);
}
copyBytes(buf, data, sizeBytes.get);
}
}
Notes:
The int[$] = syntax means data is a fixed size array where the
length is inferred. This is a possible syntax to avoid bug-prone
code like (that currently compiles):
immutable int[8] data = [0, 18, 21, 95, 43, 32, 51];
An alternative syntax:
immutable data = [0, 18, 21, 95, 43, 32, 51]s;
scope(exit) helps avoid to forget to close the file when the
scope ends. It's not essential in D, that closes the File using
RAII and reference counting.
Instead of the ugly and bug-prone mess of read(fd, size,
sizeof(int)); I have used something nicer. tryRead!uint tries
to read an uint, and returns a Nullable!uint. The Maybe is a
function currently missing in Phobos
(https://issues.dlang.org/show_bug.cgi?id=12679 ), it's used to
chain other functions on nullables, so bswap gets called only if
tryRead doesn't return a null value. If tryRead returns a null,
then Maybe returns a nulled Nullable (currently I think tryRead
is not present in Phobos, but it's not hard to add something
similar, using parse).
copyBytes is a template function that accepts both dynamic arrays
and fixed-static arrays (if the input is a fixed-static array it
doesn't throw away this precious compile-time information, as
usually done by Phobos), that is much safer than memcpy. In
non-release mode the code inside copyBytes will give a out of
range error.
There are simple ways to reduce the template bloat caused by
handling the length of fixed size arrays in library code:
introducing in D a simple syntax to handle ghost typing (or here
ghost values), that allows to manage types (and compile-time
values) to enforce compile-time invariants, but that do not
generate distinct instantiations of code and data structures,
like templates on regular types (and regular compile-time values)
do.
The D version also uses better names that make the semantics more
clear, uses immutability (that is partially available in C too,
with const that is quite underused in C code), and is less
cluttered and noisy, this helps spot the bugs better.
In general I suggest to avoid using the raw C functions in D.
Better to wrap them inside something a little safer. If such
wrappers are standard Phobos functions it's even better:
https://d.puremagic.com/issues/show_bug.cgi?id=12548
Bye,
bearophile
Re: DIP61: redone to do extern(C++,N) syntax
On Mon, 28 Apr 2014 17:00:11 -0400, Simen Kjærås via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
bar.func(); // ok, uses C binding (no name mangling)
}
In this case, even though the C function is not mangled or in any other
namespace, the module can be used for unambiguous calling.
Right.
module foo;
void func() {}
module bar;
extern(C++, foo) void func(); // foo::func in C++ land
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ALSO error
No, not an error. Why would it be?
I believe Steven expects things to work this way:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // Calls bar.func (or is that bar.foo.func?)
}
Yes, exactly. That is what the DIP says:
Declarations in the namespace can be accessed without qualification in
the enclosing scope if there is no ambiguity. Ambiguity issues can be
resolved by adding the namespace qualifier
Which then proceeds to show that only the namespace qualifier is needed
to disambiguate the symbol.
-Steve
Re: python vs d
John Colvin: Any reason why this needs language support? I haven't tried it, but I can't see why it can't be trivially done in a library. I don't yet know the answer. I have to think more about the topic, and to try to implement something in library code. And then I can judge (a bit) if the result is good enough. In D there are things that can be implemented well enough in library code (tensors). And we don't yet know if other things can be implemented well enough in D library code (like Typedef, or Algebric: http://forum.dlang.org/thread/olpznzscwiqdysfqv...@forum.dlang.org Currently Algebraic is not acceptable). And then there are things that now we know cannot be implemented acceptably well in D library code (like Phobos tuples, that lack essential features like unpacking in some different contexts. See Rust for an example of simple and reasonably designed built-in tuples: http://rustbyexample.github.io/examples/tuples/README.html ). For D programmers to invest in the usage of (optionally) strongly typed array indexing in their medium-integrity D programs (you can avoid using that indexing style in script-like D programs), such feature has to return them some valuable advantages. This means this feature should increase compile-time safety and offer a rich enough semantics. Otherwise it's a waste of time for the people that implement it, because D programmers (rightfully) will not use it. If you look at Ada, where this feature is more developed, you see some semantics that could be not so trivial to reproduce in D library code. Time ago I have suggested to add to D enum preconditions that in theory can be used in library code to better implement some of the static semantics of similar data structures. Bye, bearophile
Re: STUN/TURN servers
On Tuesday, 29 April 2014 at 09:56:18 UTC, John Colvin wrote: No, he means that WormNAT2 is written in D1 and doesn't used Vibe.d Vibe.d is D2 only. Thanks for the clarification :). It seems my English is a bit rusty.
Re: python vs d
On Tuesday, 29 April 2014 at 11:31:11 UTC, Russel Winder via Digitalmars-d wrote: Don't forget dictionary comprehensions and set comprehensions. Yes, I use dict comprehensions a lot too. I have never used set comprehensions. And definitely don't forget generator expressions. Actually, I do. :-) They are so transparent that they look like list comprehensions. Python vs Lua here. Photo-related C++ systems tend to drift to Lua for scripting. Post-production effects C++ systems seem to rely on Python. I believe Inkscape uses C++, Boehm GC and Python, Blender uses C++ and Python…
Re: python vs d
On Tuesday, 29 April 2014 at 11:28:07 UTC, Russel Winder via Digitalmars-d wrote: Principally there are a large number of users and installation and there is a wealth of support for different user bases from sys admins to quants. Python is a relatively small language that is easy to learn. The esoteric libraries can be a pain, but the core libraries do what they say on the can and are easy to use with a simple syntax. People can write working, tested code quickly without having to fight the fascist intransigence of a compiler. As opposed to the fascist intransigence of the Python interpreter with its ridiculous indent-mania. Maybe you are only referring to static vs. dynamic typing. Be it a compiler or an interpreter, they are all inherently stubborn and fond of rules. A D program can be written with the same ease as a Python program. It's up to the user to make it fancy or straight forward. I like the freedom of choice that ships with D. [snip]
Re: More on Heartbleed and related matters
Though, here size of data_array is known at compile time, so the analyzer is sure that it can complain without risk of a false positive. In real code knowing the size of array is not that easy.
Re: python vs d
On Tuesday, 29 April 2014 at 13:05:34 UTC, Chris wrote: As opposed to the fascist intransigence of the Python interpreter with its ridiculous indent-mania. Maybe you are only referring to static vs. dynamic typing. Be it a compiler or an interpreter, they are all inherently stubborn and fond of rules. As someone who only occasionally uses D and Python, I just wanted to add as a datapoint that I find the D compilers an order of magnitude more agreeable than the Python interpreter. The thought that anybody could actually enjoy significant whitespace baffles me.
Re: Poll - How long have you been in D?
I started using D2 about a year ago. Now all projects make to D2 along with the GUI QtE (Qt bindings own production). http://qte.ucoz.ru/index/screenshots/0-6
D For A Web Developer
I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development?
Re: python vs d
On Monday, 28 April 2014 at 19:34:38 UTC, Kapps wrote: D can actually do a rather good job of runtime reflection. I made a runtime reflection module (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d / https://shardsoft.com/docs/ShardTools/Reflection.html) for my own personal code and it's served the uses I've needed it for quite nicely. Cool. Can it access private members?
Re: python vs d
On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote: What's the good of having all arrays always start from index 1 (this is different from Ada, where you can choose the indexing range and type)? I'd say, for a math-oriented language starting position 1 is more meaningful than starting offset 0, the latter is an idiom for system programming language, the former better corresponds to mathematical formalism.
Re: python vs d
On Tuesday, 29 April 2014 at 14:53:48 UTC, Kagamin wrote: I'd say, for a math-oriented language starting position 1 is more meaningful than starting offset 0, the latter is an idiom for system programming language, the former better corresponds to mathematical formalism. An argument for zero-based indexing from Dijkstra: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Re: D For A Web Developer
On 2014-04-29 10:41 AM, James wrote: I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development? You should ask this in http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ But while we're here, maybe you could send him a link to http://vibed.org/ along with a link to http://dlang.org/phobos/std_algorithm.html that he could read when he has 10 minutes I don't know how else you could convince him. Possibly benchmarks? http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/ Or an example of a dynamic web project backend? https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web He might not be so familiar with type safety though, so then your arguments will have to be more technical - type safety is the only way you can ever scale a project because most bugs are caught by the compiler. He can keep using his front-end libraries too. Browsers don't run D code, they simply request bytes from it. Good luck!
Re: D For A Web Developer
I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. (And, of course, a dynamic site in D runs about 3x faster out of the box than hello world served by Rails, zero effort in optimization. And rake test, just shoot me, I'd rather rebuild a C++ project from scratch, at least that'll finish before the heat death of the universe.)
Re: D For A Web Developer
On 4/29/2014 10:41 AM, James wrote: I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development? Show him forum.dlang.org (written in D) and point out that modern HTML5/JS sites are freaking horrid. /admitted-curmudgeon
Re: DIP61: redone to do extern(C++,N) syntax
On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote:
Building on this knowledge:
module foo;
void func();
module bar;
extern(C++, foo) void func();
module prog;
import foo;
import bar;
void main()
{
// Seems like it's ambiguous between foo.func and bar.foo.func.
foo.func();
}
It will call foo.func, because the module foo is in scope in module prog
and hence hides the namespace foo in module bar.
You can already try this today, as the DIP _does not actually introduce
any new lookup rules_:
module a;
void func(){}
//---
module bar;
mixin template X(){
void func();
}
mixin X foo;
//---
import foo,bar;
void main(){
foo.func();
}
In particular, any problems you find with symbol lookup are actually
orthogonal to the DIP.
Re: DIP61: redone to do extern(C++,N) syntax
On 04/29/2014 02:01 PM, Steven Schveighoffer wrote: That is what the DIP says: Declarations in the namespace can be accessed without qualification in the enclosing scope if there is no ambiguity. Ambiguity issues can be resolved by adding the namespace qualifier Which then proceeds to show that only the namespace qualifier is needed to disambiguate the symbol. -Steve You seem to be missing the only important statement that the DIP makes about symbol disambiguation, that follows straight after those examples: Name lookup rules are the same as for mixin templates. (Maybe it should say 'named template mixins'.)
Re: D For A Web Developer
On 2014-04-29 11:27 AM, Adam D. Ruppe wrote: I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. (And, of course, a dynamic site in D runs about 3x faster out of the box than hello world served by Rails, zero effort in optimization. And rake test, just shoot me, I'd rather rebuild a C++ project from scratch, at least that'll finish before the heat death of the universe.) That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence.
Re: DIP61: redone to do extern(C++,N) syntax
On Tue, 29 Apr 2014 11:47:28 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 02:01 PM, Steven Schveighoffer wrote:
That is what the DIP says:
Declarations in the namespace can be accessed without qualification in
the enclosing scope if there is no ambiguity. Ambiguity issues can be
resolved by adding the namespace qualifier
Which then proceeds to show that only the namespace qualifier is needed
to disambiguate the symbol.
-Steve
You seem to be missing the only important statement that the DIP makes
about symbol disambiguation, that follows straight after those examples:
Name lookup rules are the same as for mixin templates.
(Maybe it should say 'named template mixins'.)
I am not familiar with the rules.
Perhaps you can just outline for me:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // works?
}
If this works, then we have a problem. If it doesn't work, well, then I
see nobody using this feature (using C++ namespace for disambiguation, not
the mangling, which is still useful).
-Steve
Re: DIP61: redone to do extern(C++,N) syntax
On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
I am not familiar with the rules.
Perhaps you can just outline for me:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // works?
}
If this works, then we have a problem.
It does work. What happens is analogous to:
module bar;
void func(){}
module prog;
import bar;
void func(){}
void main(){
func();
}
I.e. if you add a new symbol to your own module, then this identifier
will be hidden, no questions asked. Importing a module adds a new symbol
of its name to your module. I'm not sure why you see this as a problem.
The name lookup rules are designed such that changes in one module
cannot silently change name lookup in _another_ module, but anything may
happen to lookup in the same module.
If it doesn't work, well, then I
see nobody using this feature (using C++ namespace for disambiguation,
not the mangling, which is still useful).
-Steve
The name disambiguation feature fundamentally addresses one simple
issue, namely the case when the same name occurs in multiple different
namespaces occurring in the same module. (It is trivial to implement in
a compiler, if that helps, because there is no new machinery, just share
the implementation with named mixin templates.)
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 15:17:10 UTC, Etienne wrote: On 2014-04-29 10:41 AM, James wrote: I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development? You should ask this in http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ But while we're here, maybe you could send him a link to http://vibed.org/ along with a link to http://dlang.org/phobos/std_algorithm.html that he could read when he has 10 minutes I don't know how else you could convince him. Possibly benchmarks? http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/ Or an example of a dynamic web project backend? https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web He might not be so familiar with type safety though, so then your arguments will have to be more technical - type safety is the only way you can ever scale a project because most bugs are caught by the compiler. He can keep using his front-end libraries too. Browsers don't run D code, they simply request bytes from it. Good luck! Agree. Give vibe.d a try. If your friend uses dub to build it, it should be pretty easy to get started. A basic server app is very simple and straight forward to implement with vibe.d. Once the server is running he can use his existing html / js files (the server app just, well, serves them), or he can do more fancy script like stuff with diet templates: http://vibed.org/docs#html-templates and http://vibed.org/templates/diet And yes, vibe.d is by an order of magnitude faster than your usual web infrastructures.
Re: DIP61: redone to do extern(C++,N) syntax
On Tue, 29 Apr 2014 12:03:02 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
I am not familiar with the rules.
Perhaps you can just outline for me:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // works?
}
If this works, then we have a problem.
It does work. What happens is analogous to:
module bar;
void func(){}
module prog;
import bar;
void func(){}
void main(){
func();
}
I.e. if you add a new symbol to your own module, then this identifier
will be hidden, no questions asked. Importing a module adds a new symbol
of its name to your module. I'm not sure why you see this as a problem.
The name lookup rules are designed such that changes in one module
cannot silently change name lookup in _another_ module, but anything may
happen to lookup in the same module.
OK, so you are saying that from a module different than the one that
defines the namespace/function, I can call it via it's full namespace.
But what happens when you add another import that conflicts?
module foo;
void func() {}
module prog; // updated
import bar;
import foo;
void main(){
foo.func(); // now calls foo.func, and not bar.func as it originally
did, right?
}
So by importing from another module, we have silently and drastically
changed the behavior. Have I missed something?
Why is this not a problem?
-Steve
Re: python vs d
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad wrote: For closures for arrays and dicts. I don't understand I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts. I think that list and dictionary comprehensions could be implemented with mixins fairly easily, but I haven't had a chance to test this theory yet.
Re: Default arguments in function callbacks not taken into account when instantiating templates has huge security implications
On Tuesday, 29 April 2014 at 10:38:24 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
void main()
{
auto safeCallback = (string user, string pass = hunter2)
{
writefln(The password is: '%s', pass);
};
I'm sorry, but can you explain how this lets an attacker learn
anything useful? I think it's a funny trick, and I agree on
principle that it's probably an error that should be fixed, but
I'm having trouble coming up with reasons why being able to
discover the default argument (which I would assume is sentinel
junk) has gravity. I would generally consider literal
assignments in code to be trivially compromised anyway?
-Wyatt
Re: D For A Web Developer
On Tue, Apr 29, 2014 at 11:55:11AM -0400, Etienne via Digitalmars-d wrote: On 2014-04-29 11:27 AM, Adam D. Ruppe wrote: I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. (And, of course, a dynamic site in D runs about 3x faster out of the box than hello world served by Rails, zero effort in optimization. And rake test, just shoot me, I'd rather rebuild a C++ project from scratch, at least that'll finish before the heat death of the universe.) That's funny b/c most people say RoR made them love web development. [...] That's not what I hear. My cousin, who does RoR, hates it with a passion, and wishes she could get out of it. But unfortunately, she can't. I don't use RoR personally, though, so I can't speak for it myself. T -- I see that you JS got Bach.
Re: More on Heartbleed and related matters
On Tuesday, 29 April 2014 at 11:52:04 UTC, bearophile wrote: Instead of the ugly and bug-prone mess of read(fd, size, sizeof(int)); I have used something nicer. tryRead!uint tries to read an uint, and returns a Nullable!uint. The Maybe is a function currently missing in Phobos (https://issues.dlang.org/show_bug.cgi?id=12679 ), it's used to chain other functions on nullables, so bswap gets called only if tryRead doesn't return a null value. If tryRead returns a null, then Maybe returns a nulled Nullable (currently I think tryRead is not present in Phobos, but it's not hard to add something similar, using parse). Hopefully we will eventually get a good Option range type in Phobos, and use it everywhere that is applicable. Even though I don't like Nullable that much, I wish it or an Option type were used wherever they could be throughout Phobos. This would make a lot of code a lot more safe... We're already partway there with ranges, which are almost monads.
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote: That's funny b/c most people say RoR made them love web development. That's probably because they went into it with very little experience with the alternatives. I was spoiled by my web.d and friends, as well as knowing how to use a real relational database, so getting on the Rails to me is like going back into the stone age. But if you came from mysql 3 and PHP 4 or some other primitive trash, RoR might seem like the best thing ever. I do kinda like the rails console repl tho. Of course, I kinda have that with cgi.d too, you can call its methods on the regular command line pretty easily, but that doesn't let you build up state as easily for quick changes and I do like that. (Maybe I'll offer such with my script.d, should be easy to add :P) the rest of it tho is just awful.
Why are immutable fields with initializers deprecated?
A recent discussion https://github.com/D-Programming-Language/dmd/pull/3452 brought up a matter I'd forgotten - struct fields that are immutable and have initializer are deprecated. Why? Andrei
Re: Default arguments in function callbacks not taken into account when instantiating templates has huge security implications
This is a compiler bug.
When template parameter C is deduced from the call handler(safeCallback),
the default argument `= hunter2 should be stripped from the deduced
function pointer type.
Then, the call callback(John); in handler template function body should
fail to compile always, because void function(string, string) is not
callable using one string argument.
Kenji Hara
2014-04-29 19:38 GMT+09:00 Andrej Mitrovic via Digitalmars-d
digitalmars-d@puremagic.com:
-
import std.traits;
import std.stdio;
void handler(C)(C callback)
{
callback(John);
}
void main()
{
auto safeCallback = (string user, string pass = hunter2)
{
writefln(The password is: '%s', pass);
};
handler(safeCallback);
someOtherFunc();
}
void someOtherFunc()
{
auto hijackPassword = (string user, string pass)
{
writefln(Now I know your password: '%s', pass);
};
handler(hijackPassword);
}
-
Re: python vs d
On Tuesday, 29 April 2014 at 14:01:44 UTC, logicchains wrote: As someone who only occasionally uses D and Python, I just wanted to add as a datapoint that I find the D compilers an order of magnitude more agreeable than the Python interpreter. The thought that anybody could actually enjoy significant whitespace baffles me. You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation. The argument is roughly like this: if we accept that it would be a good thing if there was a universal indentation/code formatting standard that everyone followed (like gofmt for Go) then punctuation is redundant and the remaining question is whether the added punctuation helps or hinders readability on the whole. I'm guessing you find the lack of punctuation to hinder readability. I find that the opposite is true, and so enjoy reading such code more. I'm also a frequent user of Python and my main issue with it is the lack of static typing, not the syntax. I'm a rather slapdash coder and I benefit greatly from a type system that gets in my way. The same is true of most Lisps too; I'm fine with the syntax, but I suffer from the lack of static typing. BTW, there is even a surface syntax for D2, https://github.com/pplantinga/delight, which uses indentation, though I have to say that I dislike the separation of function and procedure a lot.
Re: Why are immutable fields with initializers deprecated?
On Tue, 29 Apr 2014 13:09:01 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: A recent discussion https://github.com/D-Programming-Language/dmd/pull/3452 brought up a matter I'd forgotten - struct fields that are immutable and have initializer are deprecated. Why? I think possibly it has to do with the fact that they originally did not get stored per-instance. I remember a conversation about this (being a bad thing), but have not searched the NG for it. -Steve
Re: Why are immutable fields with initializers deprecated?
In future release, non-static const or immutable field will be made an
instance field.
struct S
{
immutable int x = 1;
}
static assert(S.sizeof == int.sizeof); // will succeed in the future
So current implicit static behavior is now deprecated.
Related:
http://dlang.org/changelog#staticfields
http://dlang.org/changelog#staticfields2
Kenji Hara
2014-04-30 2:09 GMT+09:00 Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com:
A recent discussion https://github.com/D-Programming-Language/dmd/pull/
3452 brought up a matter I'd forgotten - struct fields that are immutable
and have initializer are deprecated.
Why?
Andrei
Re: Why are immutable fields with initializers deprecated?
On Tuesday, 29 April 2014 at 17:11:50 UTC, Steven Schveighoffer wrote: On Tue, 29 Apr 2014 13:09:01 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: A recent discussion https://github.com/D-Programming-Language/dmd/pull/3452 brought up a matter I'd forgotten - struct fields that are immutable and have initializer are deprecated. Why? I think possibly it has to do with the fact that they originally did not get stored per-instance. I remember a conversation about this (being a bad thing), but have not searched the NG for it. http://dlang.org/changelog#staticfields2
Re: D For A Web Developer
On 4/29/2014 11:55 AM, Etienne wrote: On 2014-04-29 11:27 AM, Adam D. Ruppe wrote: I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. (And, of course, a dynamic site in D runs about 3x faster out of the box than hello world served by Rails, zero effort in optimization. And rake test, just shoot me, I'd rather rebuild a C++ project from scratch, at least that'll finish before the heat death of the universe.) That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence. Ruby on Rails popularized MVC web frameworks, and that was a significant step forward from the stuff that came before, like PHP, ASP or even arguably ASP.NET (or *shudder* ColdFusion). I think that's always been RoR's main benefit and appeal. But since then, every other language under the sun (or rather, under florescent lights?) has grown its own MVC web framework, so Rails's biggest distinguishing characteristic now is just that it's in Ruby. And Ruby is kinda famous for having little significance outside of Rails itself. (Although, I did find Rake quite beneficial in an older project with a rather complex build. Course, these days D/Phobos has gotten good enough I'd just do a build script in D.) At least that's my impression of Ruby and Rails.
Re: Why are immutable fields with initializers deprecated?
On 4/29/14, 10:18 AM, Kenji Hara via Digitalmars-d wrote:
In future release, non-static const or immutable field will be made an
instance field.
struct S
{
immutable int x = 1;
}
static assert(S.sizeof == int.sizeof); // will succeed in the future
So current implicit static behavior is now deprecated.
Related:
http://dlang.org/changelog#staticfields
http://dlang.org/changelog#staticfields2
Kenji Hara
That makes sense - thanks Nick and Kenji! -- Andrei
Re: D For A Web Developer
Am 29.04.2014 19:45, schrieb Nick Sabalausky: On 4/29/2014 11:55 AM, Etienne wrote: On 2014-04-29 11:27 AM, Adam D. Ruppe wrote: I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. (And, of course, a dynamic site in D runs about 3x faster out of the box than hello world served by Rails, zero effort in optimization. And rake test, just shoot me, I'd rather rebuild a C++ project from scratch, at least that'll finish before the heat death of the universe.) That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence. Ruby on Rails popularized MVC web frameworks, and that was a significant step forward from the stuff that came before, like PHP, ASP or even arguably ASP.NET (or *shudder* ColdFusion). I think that's always been RoR's main benefit and appeal. But since then, every other language under the sun (or rather, under florescent lights?) has grown its own MVC web framework, so Rails's biggest distinguishing characteristic now is just that it's in Ruby. And Ruby is kinda famous for having little significance outside of Rails itself. (Although, I did find Rake quite beneficial in an older project with a rather complex build. Course, these days D/Phobos has gotten good enough I'd just do a build script in D.) At least that's my impression of Ruby and Rails. I was already doing RoR back in 1999, but it was with our own in-house TCL Apache/IIS module in a Portuguese startup, far far away from Silicon Valley and loosely based in AOL Server concepts. We eventually moved into .NET, at the time only known to Microsoft partners like our mother company, before it was announced to the world. It was a very good learning experience, building a whole stack from the ground up, back in the early web days. We already had Active Record and MVC with security layers and scaffolding, just in TCL and unknown to the world. -- Paulo
Re: What's the deal with Warning: explicit element-wise assignment...
Steven Schveighoffer:
On Tue, 15 Apr 2014 13:46:11 -0400, bearophile
What do you think are the reasons I suggested the enhancement
for?
To make people write code the way you like? :)
Honestly, it's like you require someone to call a function like:
T foo(T)(T t){return t;}
Just so you can see the foo there. I understand the idea, but
the result is not logical, just superficial.
Issue 7444 allows to tell apart the two very different operations
of this code, that look the same:
void main() {
int[][3] x;
int[]y;
int[]z;
x[] = z; // copies just the z pointer
y[] = z; // copies the elements in z
}
In Phobos there are awkward names like walkLength, and in D we
don't have a built-in x in array syntax, both just to tell
apart the O(1) cases from the O(n) ones. Requiring the [] when
you perform an array copy (instead of just a copy of the slice
struct) allows to visually tell apart the O(1) operations from
the O(n) ones:
void main() {
int[][3] x;
int[]y;
int[]z;
x[] = z;
y[] = z[];
}
the result is not logical, just superficial.
In D vector operations are allowed only with the [] syntax:
void main() {
int[] a, b;
a = a + b; // Wrong
a[] = a + b; // Wrong
a = a[] + b; // Wrong
a = a + b[]; // Wrong
a[] = a[] + b; // Wrong
a = a[] + b[]; // Wrong
a[] = a[] + b[]; // OK
}
A copy of the items can be seen as the simplest vector operation,
so I think it's logical for it to require the [] like the others.
Bye,
bearophile
Re: What's the deal with Warning: explicit element-wise assignment...
On Tue, 29 Apr 2014 14:08:59 -0400, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
On Tue, 15 Apr 2014 13:46:11 -0400, bearophile
What do you think are the reasons I suggested the enhancement for?
To make people write code the way you like? :)
Honestly, it's like you require someone to call a function like:
T foo(T)(T t){return t;}
Just so you can see the foo there. I understand the idea, but the
result is not logical, just superficial.
Issue 7444 allows to tell apart the two very different operations of
this code, that look the same:
void main() {
int[][3] x;
int[]y;
int[]z;
x[] = z; // copies just the z pointer
y[] = z; // copies the elements in z
}
x[] = z[]; // copies just the z pointer
y[] = z[]; // copies the elements in z.
The problem is that the brackets don't affect the operation, just the type
of the expression. To ascribe more logical meaning results in rather
awkward and incorrect assumptions.
-Steve
Re: D For A Web Developer
On Tue, 29 Apr 2014 11:55:11 -0400 Etienne via Digitalmars-d digitalmars-d@puremagic.com wrote: That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence. no, please, no! the latest thing D needs is a bunch of php-coders! signature.asc Description: PGP signature
Re: D For A Web Developer
On Tue, 29 Apr 2014 14:41:17 + James via Digitalmars-d digitalmars-d@puremagic.com wrote: just show him vibe.d. it's what node.js wants to be, but failed. ;-) signature.asc Description: PGP signature
Re: D For A Web Developer
On 2014-04-29 17:27, Adam D. Ruppe wrote: I recently started a Ruby on Rails job and using it makes me really, really miss the high productivity and ease of use D offers. I'm curious to why you think D is more productive and easier to use. -- /Jacob Carlborg
Re: D For A Web Developer
On Tue, 2014-04-29 at 20:04 +0200, Paulo Pinto via Digitalmars-d wrote: […] I was already doing RoR back in 1999, but it was with our own in-house TCL Apache/IIS module in a Portuguese startup, far far away from Silicon Valley and loosely based in AOL Server concepts. […] We already had Active Record and MVC with security layers and scaffolding, just in TCL and unknown to the world. Californians insist that everything is invented in California, and all other USAnians believe them. It is about time Europeans stopped believing them. Especially as everything in the future will be invented in China. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 2:01 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
framework1.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,graphics){ void g(vec4 …) … }
application1.d:
import framework1;
import framework2;
graphics.g( physics.f(…) ); // you said this would not work?
That won't work because framework1.veclib.vec4 is not the same as
framework2.veclib.vec4, as far as D's symbol lookup is concerned.
-
myframework.d
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
extern(C++,graphics){ void g(vec4 …) … }
application2.d
import myframework;
graphics.g( physics.f(…) ); // but now it works?
Yes, because now there is only one myframework.veclib.vec4.
I'd do your example as:
vec.d:
extern(C++,veclib){ struct … vec4 …; }
framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
import vec;
extern(C++,graphics){ void g(vec4 …) … }
application1.d:
import framework1;
import framework2;
graphics.g( physics.f(…) ); // works
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 8:43 AM, Timon Gehr wrote: as the DIP _does not actually introduce any new lookup rules_ [...] In particular, any problems you find with symbol lookup are actually orthogonal to the DIP. Yes!
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 15:28:00 UTC, Nick Sabalausky wrote: Show him forum.dlang.org (written in D) and point out that modern HTML5/JS sites are freaking horrid. /admitted-curmudgeon forum.dlang.org is written in HTML/JS too.
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
But what happens when you add another import that conflicts?
module foo;
void func() {}
module prog; // updated
import bar;
import foo;
void main(){
foo.func(); // now calls foo.func, and not bar.func as it originally did,
right?
}
So by importing from another module, we have silently and drastically changed
the behavior. Have I missed something?
Why is this not a problem?
Because the compiler would now issue an error for that, it's its anti-hijacking
feature.
Try it and see!
Re: DIP61: redone to do extern(C++,N) syntax
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
But what happens when you add another import that conflicts?
module foo;
void func() {}
module prog; // updated
import bar;
import foo;
void main(){
foo.func(); // now calls foo.func, and not bar.func as it
originally did,
right?
}
So by importing from another module, we have silently and drastically
changed
the behavior. Have I missed something?
Why is this not a problem?
Because the compiler would now issue an error for that, it's its
anti-hijacking feature.
Try it and see!
I agree! that was my central point, which Timon seemed to be arguing
against :)
Quoting:
On Tue, 29 Apr 2014 11:43:45 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote:
Building on this knowledge:
module foo;
void func();
module bar;
extern(C++, foo) void func();
module prog;
import foo;
import bar;
void main()
{
// Seems like it's ambiguous between foo.func and bar.foo.func.
foo.func();
}
It will call foo.func, because the module foo is in scope in module prog
and hence hides the namespace foo in module bar.
You can already try this today, as the DIP _does not actually introduce
any new lookup rules_:
module a;
void func(){}
//---
module bar;
mixin template X(){
void func();
}
mixin X foo;
//---
import foo,bar;
void main(){
foo.func();
}
In particular, any problems you find with symbol lookup are actually
orthogonal to the DIP.
-Steve
Re: DIP61: redone to do extern(C++,N) syntax
On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
I'd do your example as:
vec.d:
extern(C++,veclib){ struct … vec4 …; }
framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
import vec;
extern(C++,graphics){ void g(vec4 …) … }
Yes, but that requires the authors of framework1 and framework2
to cooperate. Which is why you with this DIP will end up with
people being better off by using pure C++ rather than mixed D/C++
from different sources.
With graphics::g(physics::f(…)) this would not have been an
issue.
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 1:23 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
I'd do your example as:
vec.d:
extern(C++,veclib){ struct … vec4 …; }
framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
import vec;
extern(C++,graphics){ void g(vec4 …) … }
Yes, but that requires the authors of framework1 and framework2 to cooperate.
Not really. It is reasonable to expect that when Framework1 and Framework2 each
import 4th party Vec, that they do it with an import rather than inlining Vec's
declarations.
Which is why you with this DIP will end up with people being better off by using
pure C++ rather than mixed D/C++ from different sources.
With graphics::g(physics::f(…)) this would not have been an issue.
Having an alternative lookup method is a large increase in language complexity.
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 1:33 PM, Walter Bright wrote: On 4/29/2014 1:23 PM, Ola Fosheim Grøstad With graphics::g(physics::f(…)) this would not have been an issue. It does occur to me that two C++ symbols in the same namespace may be regarded as the same by the lookup code. That may be a reasonable enhancement request.
Re: DIP61: redone to do extern(C++,N) syntax
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Because the compiler would now issue an error for that, it's its
anti-hijacking feature.
Try it and see!
I agree! that was my central point, which Timon seemed to be arguing
against :)
And in fact, so were you!
On Mon, 28 Apr 2014 16:50:45 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
module foo;
void func() {}
module bar;
extern(C++, foo) void func(); // foo::func in C++ land
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ALSO error
No, not an error. Why would it be?
This is EXACTLY the same code that you said would now be an error above!
I think you guys need to reexamine this, and choose one way or another. At
this point, I have no clue as to how it's supposed to work.
-Steve
Re: DIP61: redone to do extern(C++,N) syntax
On Tuesday, 29 April 2014 at 20:33:07 UTC, Walter Bright wrote:
Not really. It is reasonable to expect that when Framework1 and
Framework2 each import 4th party Vec, that they do it with an
import rather than inlining Vec's declarations.
Vectors are not the best example since one library might use
struct{float x,y,z,w;} and another use float[4], but that would
be too complicated to unify on the D side without a wrapper. At
least as far as I can tell.
(I.e. the C++ frameworks interoperate because the memory layout
and semantics are the same, although the types are not.)
With graphics::g(physics::f(…)) this would not have been an
issue.
Having an alternative lookup method is a large increase in
language complexity.
I wouldn't mind using fully qualified names, but others probably
would.
It does occur to me that two C++ symbols in the same namespace
may be regarded as the same by the lookup code. That may be a
reasonable enhancement request.
Yes, that would help.
Re: DIP61: redone to do extern(C++,N) syntax
On 04/29/2014 10:49 PM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Because the compiler would now issue an error for that, it's its
anti-hijacking feature.
Try it and see!
I agree! that was my central point, which Timon seemed to be arguing
against :)
And in fact, so were you!
...
This is EXACTLY the same code that you said would now be an error above!
Maybe he didn't notice that you changed the 'main' function relative to
my post. If you don't mention 'foo' explicitly, then obviously it cannot
be hidden by the import and the code is in error.
I think you guys need to reexamine this,
Not me. I typically test my claims even if I am sure, if only to file
bug reports.
and choose one way or another.
At this point, I have no clue as to how it's supposed to work.
Obviously you did not actually try. :P
Again, to make it really easy for you to test the behaviour:
module foo;
import std.stdio;
int func(){ writeln(hello from foo!); return 1; }
//---
module bar;
import std.stdio;
mixin template X(){
int func(){ writeln(hello from bar!); return 2; }
}
mixin X foo;
//---
module prog;
void main(){
void onlybar(){
import bar;
auto r=foo.func(); // hello from bar!
assert(r==2); // pass!
}
void fooandbar(){
import bar,foo;
auto r=foo.func(); // hello from foo!
assert(r==1); // pass!
}
onlybar();
fooandbar();
}
http://dlang.org/download.html
$ dmd prog foo bar ./prog
hello from bar!
hello from foo!
This is because the import of module 'foo' hides the namespace 'foo'
imported from 'bar' in the scope of 'fooandbar'. It is not 'func' that
is being hidden, but 'foo'.
Re: Distributing implib?
On Monday, 28 April 2014 at 03:09:32 UTC, Trent Forkert wrote: On Sunday, 27 April 2014 at 17:53:18 UTC, Jeremy DeHaan wrote: Hi all, I am doing some updates to the C back end of my binding, and I wanted to know what it would entail to be able to distribute implib along with my CMake things. I was just thinking that it would be nice to automatically produce .lib files when it builds 32bit libs on Windows systems. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy Nick already answered your question, but I have another suggestion for you. Set things up to look for implib (or perhaps coffimplib[1]), and complain if CMake can't find it. This tool should be part of the user's tools and environment, not part of your project. This may be my Linux bias talking, but I would tend to not want to ship binaries as part of my source. The good thing about CMake is that it can help you deal with your dependencies in a sane way. - Trent [1]ftp://ftp.digitalmars.com/coffimplib.zip That's not a bad idea, but it would suck for people that might not know what the heck implib even is and make them have to search for it. I'd like them to be able to build the library with the right import libraries right out of the box.
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 19:06:59 UTC, Jacob Carlborg wrote: I'm curious to why you think D is more productive and easier to use. A lot of things, mostly focusing around having the compiler to help refactor with confidence (the importance of this really can't be understated) and having libraries that fit better. The speed is a nice bonus too, having to spend half a minute just waiting for the tests to run really grates me. But wrt libraries, ActiveRecord is unbelievably awful, for example. It is a bad idea from the ground up: why, oh why are we reinventing the database? erb templates are painful to use too, and so is the routing. I don't understand why routing isn't done automatically for the common case. The scaffolding is a pain too. Contrast to what web.d does: given a function signature, it automatically generates a form for it (using type information to select correct widgets) and can format the response in several forms automatically including plain text, html list, html table, json, xml, csv, and a custom template. Maybe Rails can do this stuff and I'm too much of a n00b, but the other experienced team members say the way we're doing it is pretty standard and I'm just not impressed. I can just get stuff done in D in a fraction of a time it takes to do even less in RoR.
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrei
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrie
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/14, 12:49 PM, Walter Bright wrote: On 4/29/2014 8:43 AM, Timon Gehr wrote: as the DIP _does not actually introduce any new lookup rules_ [...] In particular, any problems you find with symbol lookup are actually orthogonal to the DIP. Yes! This is a biggie. KISS etc. -- Andrei
Re: DIP61: redone to do extern(C++,N) syntax
On Monday, 28 April 2014 at 01:18:04 UTC, Walter Bright wrote:
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
You can also have N.M
I've updated the DIP page to include documentation of the change
to the language grammar.
Re: What's the deal with Warning: explicit element-wise assignment...
Andrei Alexandrescu: On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrei The name like walkLength was chosen (by you?), instead of a more natural name like length (or even a nice, short, clean, readable, handy and easer to write name like len as in Python) to underline that walkLength could be O(n). Bye, bearophile
Re: DIP61: redone to do extern(C++,N) syntax
On 4/29/2014 4:08 PM, Brian Schott wrote: I've updated the DIP page to include documentation of the change to the language grammar. thanks!
Re: DIP61: redone to do extern(C++,N) syntax
On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 10:49 PM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Because the compiler would now issue an error for that, it's its
anti-hijacking feature.
Try it and see!
I agree! that was my central point, which Timon seemed to be arguing
against :)
And in fact, so were you!
...
This is EXACTLY the same code that you said would now be an error above!
Maybe he didn't notice that you changed the 'main' function relative to
my post. If you don't mention 'foo' explicitly, then obviously it cannot
be hidden by the import and the code is in error.
I never changed the code. It always was foo.func(). That was my point.
I think you guys need to reexamine this,
Not me. I typically test my claims even if I am sure, if only to file
bug reports.
Your view has been consistent. I think it defeats the purpose of having
namespaces to disambiguate calls, since the disambiguation itself
conflicts with modules.
If foo.func means one thing today and another thing tomorrow, based on an
import, I think the feature is flawed. Template namespaces are just as
flawed.
and choose one way or another.
At this point, I have no clue as to how it's supposed to work.
Obviously you did not actually try. :P
No, I get what you are saying. The above statement is because I'm getting
conflicting reports from Walter.
Again, to make it really easy for you to test the behaviour:
module foo;
import std.stdio;
int func(){ writeln(hello from foo!); return 1; }
//---
module bar;
import std.stdio;
mixin template X(){
int func(){ writeln(hello from bar!); return 2; }
}
mixin X foo;
//---
module prog;
void main(){
void onlybar(){
import bar;
auto r=foo.func(); // hello from bar!
assert(r==2); // pass!
}
void fooandbar(){
import bar,foo;
auto r=foo.func(); // hello from foo!
assert(r==1); // pass!
}
onlybar();
fooandbar();
}
Wouldn't a similar test be to create a struct for a namespace?
The confusing issue here to C++ programmers is, when I specify x::y::z, it
means z in namespace x::y, regardless of where it was imported. If in D we
say you can access this via x.y.z, they are going to think they can always
type that. To have it so easily break is not a good thing.
http://dlang.org/download.html
$ dmd prog foo bar ./prog
hello from bar!
hello from foo!
This is because the import of module 'foo' hides the namespace 'foo'
imported from 'bar' in the scope of 'fooandbar'. It is not 'func' that
is being hidden, but 'foo'.
In fact, it's the entire foo namespace.
module bar;
import std.stdio;
mixin template X(){
int func(){ writeln(hello from bar!); return 2; }
int func2(){ writeln(hello also from bar!); return 2;} // no
equivalent in foo.d
}
mixin X foo;
module foo; // same as before
...
module prog;
import foo; // comment out to compile
import bar;
void main()
{
foo.func2(); // Error: undefined identifier 'func2', did you mean
'function func'?
}
So basically any namespace that matches the root phobos import path will
cause conflicts. You don't suppose any C++ code uses that do you? ;)
-Steve
Re: tuple can write [],but can't read []
On Tuesday, 29 April 2014 at 09:53:29 UTC, John Colvin wrote:
foreach(i; TypeTuple!(0,1,2))
{
writeln(xy2[0][i]);
}
}
Thank you,John Colvin,
It works very good.
Frank.
D vs Rust: function signatures
The unbelievable amount of time and energy that's been spent discussing the smallest syntax, you would think that D would, at the very least, have better looking function signatures, but it doesn't. auto zip(Ranges...)(Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); auto zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); fn zipB, U: IteratorB(self, other: U) - ZipSelf, U auto chain(Ranges...)(Ranges rs) if (Ranges.length 0 allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void)); fn chainU: IteratorA(self, other: U) - ChainSelf, U template map(fun...) if (fun.length = 1) auto map(Range)(Range r) if (isInputRange!(Unqual!Range)); fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self template filter(alias pred) if (is(typeof(unaryFun!pred))) auto filter(Range)(Range rs) if (isInputRange!(Unqual!Range)); fn filter'r(self, predicate: |A|: 'r - bool) - Filter'r, A, Self MaxType!(T1, T2, T) max(T1, T2, T...)(T1 a, T2 b, T xs) if (is(typeof(a b))); pub fn maxT: TotalOrd(v1: T, v2: T) - T
Re: D vs Rust: function signatures
On 4/29/2014 9:38 PM, Narrator wrote: fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self That looks like line noise.
Re: python vs d
On 4/29/2014 1:05 PM, Brian Rogoff wrote: The argument is roughly like this: if we accept that it would be a good thing if there was a universal indentation/code formatting standard that everyone followed (like gofmt for Go) then punctuation is redundant and the remaining question is whether the added punctuation helps or hinders readability on the whole. I'm guessing you find the lack of punctuation to hinder readability. I find that the opposite is true, and so enjoy reading such code more. The problem with the standardized indentation argument is that it's *impossible* for a language like python to enforce indentation rules. All it can do, and indeed all is *does* do, is blindly assume that the indentation as presented is correct and adheres to the universal style. If something is indented wrong, there is no enforcement, only bugs. So there's definitely more to it than just whether a person finds non-whitespace syntax to help/hinder readability.
Re: D For A Web Developer
On 4/29/2014 3:48 PM, JN wrote: On Tuesday, 29 April 2014 at 15:28:00 UTC, Nick Sabalausky wrote: Show him forum.dlang.org (written in D) and point out that modern HTML5/JS sites are freaking horrid. /admitted-curmudgeon forum.dlang.org is written in HTML/JS too. Anything on the web involves HTML, the difference is whether the HTML is the platform (ie HTML5) or just the renderer. And forum.dlang.org uses very little JS (and only optionally). It's certainly not built out of JS.
Re: D vs Rust: function signatures
On Wednesday, 30 April 2014 at 01:38:46 UTC, Narrator wrote: The unbelievable amount of time and energy that's been spent discussing the smallest syntax, you would think that D would, at the very least, have better looking function signatures, but it doesn't. auto zip(Ranges...)(Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); auto zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); fn zipB, U: IteratorB(self, other: U) - ZipSelf, U IIUC: 1. The Rust function is non-variadic 2. The Rust function has no StoppingPolicy equivalent 3. The Rust function is a method of some type, such as Zip or Chain, which must be declared explicitly in every such type. Here is the equivalent D syntax: auto zip(R)(R other) if (isInputRange!R) It is shorter than the Rust version. auto chain(Ranges...)(Ranges rs) if (Ranges.length 0 allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void)); fn chainU: IteratorA(self, other: U) - ChainSelf, U Same as points 1 and 3 above. Most of that boilerplate comes from validating the variadic parameter types. template map(fun...) if (fun.length = 1) auto map(Range)(Range r) if (isInputRange!(Unqual!Range)); fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self Same as points 1 and 3 above (D's version allows specifying multiple functions). Not sure what 'r or |A| means in Rust syntax, but I guess this would be the equivalent D syntax: auto map(R)(R delegate(T)) Note that D's real version has the function alias as a template parameter, and not as a runtime parameter, meaning that you will have a guarantee of a separate template instantiation for every different map predicate. This allows you to make assumptions about the performance of the generated code which don't rely as much on expected compiler optimizations (although I don't know what guarantees Rust makes about this). template filter(alias pred) if (is(typeof(unaryFun!pred))) auto filter(Range)(Range rs) if (isInputRange!(Unqual!Range)); fn filter'r(self, predicate: |A|: 'r - bool) - Filter'r, A, Self As above, though D's filter also accepts only one predicate. MaxType!(T1, T2, T) max(T1, T2, T...)(T1 a, T2 b, T xs) if (is(typeof(a b))); pub fn maxT: TotalOrd(v1: T, v2: T) - T Same as point 1 above. Also, the Rust version requires that the two values have exactly the same type.
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote: I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development? If you want to show him what's possible with D, just show him Cmsed[0] ;) All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1]. [0] https://github.com/rikkimax/Cmsed [1] https://gist.github.com/rikkimax/11043210
Re: D For A Web Developer
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
wrote:
All I'm saying is, if you ever not want to write ajax code
again, Cmsed is your friend [1].
My web.d does some javascript generation too.
D:
import arsd.web;
class Foo : ApiProvider {
export int add(int a, int b) { return a+b; }
}
mixin FancyMain!Foo;
Javascript:
Foo.add(1, 2).get(alert); // calls alert(3) when it returns
The generated JS code creates an object with the same name as the
D class with all the export functions as methods that return a
proxy object, setting the arguments. You can then modify it and
eventually fire off the request with methods like get, getSync,
and getHtml which take a function to call with the result.
Just one of the many things I miss when doing RoR instead of D :(
