Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
Bug reported as https://issues.dlang.org/show_bug.cgi?id=14298
Re: Replace core language HexStrings with library entity
On 3/16/2015 3:49 PM, Andrei Alexandrescu wrote: hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei That's right. Being able to read in custom-formatted data into compile time literals is a big deal. It's a lot better than the way idgen.d (dmd compiler source) works.
Release Candidate D 2.067.0-rc1
Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin
DREPL will be back soon.
I'm talking about: https://drepl.dawg.eu/ It has been several days already that it is coming soon. How soon is soon ?
Re: Replace core language HexStrings with library entity
On 3/16/15 3:02 PM, Adam D. Ruppe wrote: I really think users should learn the language more than the library if you know the implementation of hexString, you can do so much more with it than if you just know the function name. (this is also a benefit to this kind of function over a built in, of course) hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei
Re: How to generate a random string ...
On Monday, 16 March 2015 at 22:19:52 UTC, Gary Willoughby wrote: I guess it depends on the encoding? No the character itself are encoding independent. Some references: http://stackoverflow.com/questions/23853489/generate-a-random-unicode-string This will not work as the caller has to specify the code range. I want to specify the string length and the random use is not even uniform (see channel 9 link) http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful http://www.bonf.net/2009/01/14/generating-random-unicode-strings-in-c/ I'm not use how that is going to give me the 113,021 unicode defined characters let alone in a uniform way.
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote: On Saturday, 14 March 2015 at 13:52:13 UTC, Craig Dillabaugh wrote: I don't have any C# experience so I can't compare those languages much, but I've heard people say their are D / C# similarities. Anyway, this isn't a criticism of your comment, I was just curious what (other than the shared C++ syntax heritage) you find so Java-like in D? Cheers, Craig I've been using C# pretty extensively for the last year or so. Superficially, at least, C# and D are pretty similar, eg auto (var), foreach, lambdas, classes and structs. C# is more biased towards OO than D. Metaprogramming is significantly weaker in C#. This is probably the one area where I've wished for some of D's functionality. Reflection is all runtime. C# has some AST capabilities that D doesn't. This is probably the main area where I envy C# when using D. And C# has LINQ, which when combined with the last point is fricken awesome. You should give C# a try, its actually great. The only thing that holds me back is that its maintained by microsoft, Multi Platform support is sub par, and it cant be targeted towards other architectures.
Re: The next iteration of scope
On Monday, 16 March 2015 at 20:50:46 UTC, Marc Schütz wrote:
On Monday, 16 March 2015 at 19:43:01 UTC, Zach the Mystic wrote:
I always tend to think of member functions as if they weren't:
struct S {
T t;
ref T fun() return {
return t;
}
}
In my head, I just translate fun() above to:
ref T fun(return S* __this) {
return __this.t;
}
Therefore whatever the scope of `__this`, that's the scope of
the return, just like it would be for any other parameter.
Then:
S s;
s.fun();
... is really just `fun(s);` in disguise. That's why it's hard
for me to grasp `scope` members, because they seem to me to be
just as scope as their parent, whether global or local.
It works just the same:
struct S {
private int* payload_;
ref int* payload() return {
return payload_;
}
}
ref int* payload(scope ref S __this) return {
return __this.payload_;// well, imagine it's not private
}
More accurately,
// `return` is moved
ref int* payload(return scope ref S __this) {
return __this.payload_;
}
I think that if you need `return` to make it safe, there's much
less need for `scope`.
Both the S.payload() and the free-standing payload() do the
same thing.
From inside the functions, `return` tells us that we're allowed
to a reference to our payload. From the caller's point of view,
it signifies that the return value is scoped to the first
argument, or `this` respectively.
To reiterate, `scope` members are just syntactical sugar for
the kinds of accessor methods/functions in the example code.
There's nothing special about them.
That's fine, but then there's the argument that syntax sugar is
different from real functionality. To add it would require a
compelling use case.
My fundamental issue with `scope` in general is that it should be
the safe default, which means it doesn't really need to appear
that often. If @safe is default, the compiler would force you to
mark any parameter `return` when it detected such a return.
How a member could be scope when the parent is global is hard
for me to imagine.
The following is clear, right?
int* p;
scope int* borrowed = p;
That's clearly allowed, we're storing a reference to a global
or GC object into a scope variable. Now let's use `S`, which
contains an `int*` member:
S s;
scope S borrowed_s = s;
That's also ok. Doesn't matter whether it's the pointer itself,
or something containing the pointer. And now the final step:
scope int* p2;
p2 = s.payload; // OK
p2 = borrowed_s.payload; // also OK
static int* p3;
p3 = s.payload; // NOT OK!
However, if `payload` were not the accessor method/function,
but instead a simple (non-scope) member of `S`, that last line
would be allowed, because there is nothing restricting its use.
See above. With `return` being forced on the implicit this
parameter:
ref int* payload(return /*scope*/ ref S __this) { ... }
`return` covers the need for safety, unless I'm still missing
something.
For members that the struct owns and want's to manage itself,
this is not good. Therefore, we make it private and allow
access to it only through accessor methods/functions that are
annotated with `return`. But we could accidentally forget an
annotation, and the pointer could escape.
Same argument. Forgetting `return` in safe code == compiler
error. I think DIP25 already does this.
Re: const as default for variables
On Monday, 16 March 2015 at 19:52:00 UTC, deadalnix wrote: On Monday, 16 March 2015 at 14:40:51 UTC, Zach the Mystic wrote: On Sunday, 15 March 2015 at 20:09:56 UTC, deadalnix wrote: On Sunday, 15 March 2015 at 07:44:50 UTC, Walter Bright wrote: const ref can tell the optimizer that that path for a ref counted object cannot alter its ref count. That is not clear why. const ref is supposed to protect against escaping when ref does not ? There are two cases here. One is when the reference is copied to new variable, which would actually break const because the reference count of the original data would have to be incremented (which is a separate issue). I think we should provide library solution for this kind of things. Changing the reference count is a very low-level operation. I'm not sure how to go about breaking the type system in order to support `const` variations on it.
Re: SDLang-D v0.9.0
Very nice. I wonder about representation of references, and perhaps replication, inheritance. Does SDL just punt on those?
Re: Replace core language HexStrings with library entity
On 3/16/15 6:45 PM, Daniel Murphy wrote: Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in. Agreed. On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make its removal a net positive. Andrei
Re: SDLang-D v0.9.0
On 03/16/2015 11:02 PM, Jay Norwood wrote: Very nice. I wonder about representation of references, and perhaps replication, inheritance. Does SDL just punt on those? SDL does not specifically address those. It's just left up to your own schema. (Which reminds me: I'd really like to see an official SDL schema format designed. I'll have to come up with a proposal and kick the idea upstream.)
enabling persistent state for the REPL?
On Monday, 16 March 2015 at 21:36:45 UTC, deadalnix wrote: I'm talking about: https://drepl.dawg.eu/ It has been several days already that it is coming soon. How soon is soon ? It's a different topic (and hope you will forgive my hijacking your thread - I don't know the answer, but guess you will hear back soon enough - hijack or no), but I was thinking about how one could make the REPL more useful as something closer to the ipython notebook. What do you/others think about having the REPL serialize any variables (optionally only those that are declared in a certain way, or part of a particular struct) to RAM disk or SSD and reload them at each stage rather than calculating them (ie compiling the generating statements) from scratch each time. The overhead would be modest in the trivial case, but it would allow you to use the REPL to explore larger data sets that take time to generate. Simple example here: http://nbviewer.ipython.org/gist/twiecki/3962843 (This data doesn't take long to generate, but larger data sets might).
[Issue 14298] New: std.typecons.Proxy incorrectly defines opCast operator, that breaks casting to supertype.
https://issues.dlang.org/show_bug.cgi?id=14298
Issue ID: 14298
Summary: std.typecons.Proxy incorrectly defines opCast
operator, that breaks casting to supertype.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: luk.wrzo...@gmail.com
//test case
import std.typecons;
class IA {}
class IB {}
class C : IB {
IA a;
mixin Proxy!a;
public this() {
a = new IA;
}
}
void main() {
C c = new C;
assert(c !is null);
IA a = cast(IA)c;
assert(a !is null);
IB b_ok = c;
assert(b_ok !is null); //implicit cast works
IB b_not_ok = cast(IB)c;
assert(b_not_ok !is null); //assert fails on explicit cast.
}
//Proxy template always casts to Proxy'ied type:
auto ref opCast(T, this X)() { return cast(T)a; }
--
Re: Replace core language HexStrings with library entity
Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in.
[Issue 14184] Cannot resolve type for lambda stringof in constructor
https://issues.dlang.org/show_bug.cgi?id=14184 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
Re: A bug on the website dlang.org
On Monday, 16 March 2015 at 20:03:36 UTC, Marc Schütz wrote: You can file bugs against component websites there. Thanks. This has already been fixed AFAIK, it's just not yet deployed. OK.
Re: Deadcode on github
On Monday, 16 March 2015 at 18:27:52 UTC, Dicebot wrote: On Monday, 16 March 2015 at 15:14:03 UTC, Jonas Drewsen wrote: Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. I got bunch of errors from windowdragger.d amd guiapplication.d modules because those directly import windows api stuff and use types like `DWORD` and friends. I see :( The windowdragger.d could be fixed on linux using something from : http://rosettacode.org/wiki/Mouse_position#C The guiapplication.d is stuff for watching dirs, locating window position info, and getting default dir paths e.g. user dir.
Re: struct / cast / ? design problem
The problem in your example is that your making a copy of the
returned data. Of course any changes to that copy won't affect
the original. You need to return a pointer to it (`ref` won't do
if you want to store it in a local variable, because these can't
be `ref`).
struct BlockHead
{
uint magic = 20150312;
uint magic2;
uint blockSize;
uint unused1;
ulong unused2;
ulong spare[61];
T* embedded(T)() {
static assert(T.sizeof spare.length);
return cast(T*) spare.ptr;
}
}
How to use it:
void useIt(ref BlockHead bh) {
static struct InternalData {
int foo;
ubyte[20] bar;
}
auto data = bh.embedded!InternalData;
data.foo = 42;
}
Re: ref for (const) variables
On Monday, 16 March 2015 at 19:20:09 UTC, anonymous wrote: On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. It is, for example, not nullable. ;) Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed. I will research this. Thank you.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:06:39 UTC, weaselcat wrote: On Monday, 16 March 2015 at 12:45:58 UTC, Martin Nowak wrote: On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: Ruby has over 6,000 packages, ...starting with letter A. It's over 100K in total. http://www.modulecounts.com/ Hey, that's over 6000 ;) Also, yes more interviews please. Also also, An example of a simple but fundamental issue are the defaults of the built-in attributes. I think some of them, for historical or compatibility reasons, are currently simply the wrong way around (pure, @safe, final and scope should really all be enabled by default, with scope providing recursive guarantees) and using them properly completely destroys the initial idea of having a clean language syntax. It's sometimes really sad to see modern idiomatic D code degrading into a mess of attributes and contract syntax noise. After all, a clean syntax used to be one of the key selling points. +1 for this entire paragraph, sometimes D looks simple and elegant, other times it looks like someone puked attributes.
Berlin D Meetup March 2015
Hi All, The next Berlin D Meetup will be happening on Friday the 20th of March at 19:30. The venue will be Berlin Co-Op (http://co-up.de/) on the 3rd floor. Martin Nowak will be doing a presentation on recent improvements in the garbage collector. After the presentation we will have time for questions/discussions/drinks. Details are also on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/ Thanks, Ben.
Re: Using std.format required std.string?
On Mon, 16 Mar 2015 12:32:01 +0100, Robert M. Münch wrote:
I prefer to move things to the far future compatibility path ASAP.
Reduce a lot of maintenance headaches.
then you can check properties, not versions. ;-)
static if (__traits(compiles, {import std.string : format;})) {
import std.string : format;
} else {
import std.format : format;
}
signature.asc
Description: PGP signature
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote: On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote: I see D attracting *really* good programmers, programmers from, let's say the 90-95th percentile in skill and talent in their field on average. By marketing to these programmers specifically -- that is, telling everyone that while D is for everyone, it is especially designed to give talented and experienced programmers the tools they need to get their work done -- even if you repel several programmers from, say, the 45th percentile or below in exchange for the brand loyalty of one from 92nd percentile or above, it's probably a winning strategy, because that one good programmer will get more done than all the rest combined. Isn't that implicitly what D is (and it is a compliment that you do a good job of unfolding it). I agree with the economic understanding, and with the strategy. Yep, this is what I meant by my Blackberry analogy earlier in this thread. Blackberry used to own the smartphone market, when it was limited to professionals who emailed and texted a lot. When the market broadened to include everyone, they decided to go the popular route and sell touch-screen phones without physical keyboards like everyone else. It was a disaster, from which they're only recently recovering by offering physical keyboards again. I'm not saying it _had_ to fail, only that RIM clearly didn't have what it took to succeed there. Similarly, D's never going to do very well with programmers who don't care about the efficiency of their code: simpler, slower languages like python or ruby have that niche sewn up. The best we can do is point out that if you're already here for the advanced features, it can also be used for scripting and the like. And of course, we should always strive to make things as easy as we can for both small and large projects, including better documentation. One day, the tide may turn towards native efficiency again, say because of mobile or more people writing code that runs on large server clusters, and D will be well-positioned to benefit if and when that happens. The future is here already, but just not evenly distributed (Gibson). It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals. http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade Data sets are exploding in size but the marginal dollar value commercially of every byte is collapsing whilst the free lunch from Moore's Law is over. That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions.
Re: The next iteration of scope
On Monday, 16 March 2015 at 04:00:51 UTC, Zach the Mystic wrote:
Functions and methods can be overloaded on scope. This allows
efficient passing of RC wrappers for instance...
How does the compiler figure out which of the variables it's
passing to the parameters are `scope` or not? Does the caller
try the scoped overloads first by default, and only if there's
an error tries the non-scoped overloads? If so, what causes the
error?
Hmm... I guess it only makes sense for postblits and destructors.
I'm not sure about constructors and opAssign, so I'll leave these
out for now. I've changed the wiki page accordingly.
To specify that the value is returned through another
parameter, the return!ident syntax can be used...
struct RC(T) if(is(T == class)) {
scope T payload;
T borrow() return {// `return` applies to `this`
return payload;
}
}
The example contains no use of `return!ident`.
I added an example.
Also, what exactly does the `scope` on T payload get you? Is it
just a more specific version of `return` on the this parameter,
i.e. `return this.payload`? Why would you need that
specificity? What is the dangerous operation it is intended to
prevent?
Nick already answered that. I'll expand on his explanation:
Let's take the RC struct as an example. Instances of RC can
appear with and without scope. Because structs members inherit
the scope-ness from the struct, `payload` could therefore be an
unscoped pointer. It could therefore be escaped unintentionally.
By adding `scope` to its declaration, we force it to be scoped to
the structs lifetime, no matter how it's accessed.
Re: The next iteration of scope
On Monday, 16 March 2015 at 12:21:17 UTC, Nick Treleaven wrote: On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote: I too want a scope attribute e.g. for safe slicing of static arrays, etc. I'm not sure if it's too late for scope by default though, perhaps. If we get @safe by default, we automatically get scope by default, too. I don't follow that. In @safe code parameters could still default to escaping, causing compiler errors when passing things that can't be allowed to escape. I do see that scope parameters by default would probably cause less churn than having to put `scope` on non-template function parameters in order to be usable by non-GC-heap memory. It's part of the proposal, under Implicit scope: @safe implies scope. I think this would cause the least compatibility problems, because what can be done with references in @safe code is already restricted. And as @safe is going to be used more and more, scope will spread with it. We already have scope on local delegates (at least it's accepted by dmd): Object obj; scope del = ()=obj; Oh, I thought this was deprecated, together with scope classes. I was aware that `scope` already works (at least partially) for delegate params, but not for locals. Anyway, I think it's unnecessary for locals, because: Also, what would be the 'type' of a static array slice without `scope` applying to locals? int[2] arr = [1, 2]; scope int[] s = arr; I suppose `scope` can be inferred for s, I'm just pointing out that it can apply to locals. Yes, it will be inferred. I've removed this part of the proposal from the article, because I thought it is too technical, and I wanted to describe only what would be visible to the end-user. But I moved my notes about that to the talk page [1]. The examples further up on this page are a bit chaotic; they were experiments for me to try out the algorithm. While the algorithm as described there probably works, I want to change it a bit to allow detection for the RCArray problem. The important thing is that the end-user doesn't have to annotate local variables as scope. As it's unnecessary, we can even consider disallowing it. [1] http://wiki.dlang.org/User_talk:Schuetzm/scope2#Scope_inference
Re: Dlang seems like java now,but why not let d more like C# Style?
On Monday, 16 March 2015 at 12:18:42 UTC, Ellery Newcomer wrote: On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote: Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL. There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability. At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way. overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards.. I don't think the problem is the lack of pattern matching. I think the problem is that by forcing the query syntax into lambda expression syntax, you obfuscate the syntax tree without really gaining any value.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:11:56 UTC, weaselcat wrote:
An example of a simple but fundamental issue are the defaults
of the built-in attributes. I think some of them, for
historical or compatibility reasons, are currently simply the
wrong way around (pure, @safe, final and scope should really
all be enabled by default, with scope providing recursive
guarantees) and using them properly completely destroys the
initial idea of having a clean language syntax. It's sometimes
really sad to see modern idiomatic D code degrading into a
mess of attributes and contract syntax noise. After all, a
clean syntax used to be one of the key selling points.
+1 for this entire paragraph, sometimes D looks simple and
elegant, other times it looks like someone puked attributes.
Rust code is safe by default and it is littered with unsafe{ }
blocks.
It is also immutable by default and it is littered with the 'mut'
keyword.
I think D absolutely choose the good defaults everytime but some
attribute don't buy enough compared to the line-noise they
generate.
For these reasons I mostly ignore pure, nothrow, @safe, immutable
etc... in routine code and only put them when the code is
especially reusable and somehow won't change much.
Since D1 I really value the ability to make bad code quickly in
time-contrained situations.
How to generate a random string ...
... from all Unicode characters in an idiomatic D way?
(std.interal.unicode_*)
```
T genUnicodeString(T)(size_t minChars, size_t maxChars)
if(isSomeString!T) {
...
}
```
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 12:45:58 UTC, Martin Nowak wrote: On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: Ruby has over 6,000 packages, ...starting with letter A. It's over 100K in total. http://www.modulecounts.com/ Hey, that's over 6000 ;) Also, yes more interviews please.
Re: DlangUI EditLine question
Thanks! I'll try this out after I get home.
`return const` parameters make `inout` obsolete
char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.
Re: Replace core language HexStrings with library entity
On Mon, 16 Mar 2015 14:22:38 +, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. and i'll drop `*`. there is no reason to have multiply operator, we already have `+`! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 14:26:27 UTC, ketmar wrote: On Mon, 16 Mar 2015 14:22:38 +, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. and i'll drop `*`. there is no reason to have multiply operator, we already have `+`! Just submit an implementation of templated `+` to phobos a +!5 b ;)
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:21:13 UTC, ponce wrote:
On Monday, 16 March 2015 at 13:11:56 UTC, weaselcat wrote:
An example of a simple but fundamental issue are the defaults
of the built-in attributes. I think some of them, for
historical or compatibility reasons, are currently simply the
wrong way around (pure, @safe, final and scope should really
all be enabled by default, with scope providing recursive
guarantees) and using them properly completely destroys the
initial idea of having a clean language syntax. It's
sometimes really sad to see modern idiomatic D code degrading
into a mess of attributes and contract syntax noise. After
all, a clean syntax used to be one of the key selling points.
+1 for this entire paragraph, sometimes D looks simple and
elegant, other times it looks like someone puked attributes.
Rust code is safe by default and it is littered with unsafe{ }
blocks.
I think this has more to do with Rust's extreme safety, many
things doable in @safe D code would be no-no in Rust(i.e, you
can't even manipulate pointers IIRC)
Re: `return const` parameters make `inout` obsolete
On Mon, 16 Mar 2015 14:17:57 +, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. but why compiler has to rewrite return type? i never told it to do that! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote: On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote: On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote: I see D attracting *really* good programmers, programmers from, let's say the 90-95th percentile in skill and talent in their field on average. By marketing to these programmers specifically -- that is, telling everyone that while D is for everyone, it is especially designed to give talented and experienced programmers the tools they need to get their work done -- even if you repel several programmers from, say, the 45th percentile or below in exchange for the brand loyalty of one from 92nd percentile or above, it's probably a winning strategy, because that one good programmer will get more done than all the rest combined. Isn't that implicitly what D is (and it is a compliment that you do a good job of unfolding it). I agree with the economic understanding, and with the strategy. Yep, this is what I meant by my Blackberry analogy earlier in this thread. Blackberry used to own the smartphone market, when it was limited to professionals who emailed and texted a lot. When the market broadened to include everyone, they decided to go the popular route and sell touch-screen phones without physical keyboards like everyone else. It was a disaster, from which they're only recently recovering by offering physical keyboards again. I'm not saying it _had_ to fail, only that RIM clearly didn't have what it took to succeed there. Similarly, D's never going to do very well with programmers who don't care about the efficiency of their code: simpler, slower languages like python or ruby have that niche sewn up. The best we can do is point out that if you're already here for the advanced features, it can also be used for scripting and the like. And of course, we should always strive to make things as easy as we can for both small and large projects, including better documentation. One day, the tide may turn towards native efficiency again, say because of mobile or more people writing code that runs on large server clusters, and D will be well-positioned to benefit if and when that happens. The future is here already, but just not evenly distributed (Gibson). It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals. http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade Data sets are exploding in size but the marginal dollar value commercially of every byte is collapsing whilst the free lunch from Moore's Law is over. That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions. Hence why both Java and .NET are getting full AOT compilation to native code on their canonical toolchains in Java 9/10 and .NET 4.6. -- Paulo
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-15.html Also remember about the RSS feed here: http://arsdnet.net/this-week-in-d/twid.rss I'm currently out west so I'm a couple hours off, but here's the next installment with summaries of forum discussions - with a few of my opinions added in - and a contributed interview! Lots of cool stuff this week. DDOC is showing through: ($P - DUB was born as a spin-off of vibe.d and the closing paren at the end of the paragraph.
Re: Deadcode on github
On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode GitHub README.md is a natural place for such information. How far you estimate it from being buildable/usable on Linux?
Re: sudo apt-get install dmd
On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? We could try to host an apt and yum repo on dlang.org. Might be simple to do, but it's not much better than the deb/rpm download we offer. It only gets interesting when we could land DMD in official repos, volunteering package maintainers are welcome and should please contact me. I hope we can sort out the redistribution part of the backend somehow. We should include the few commands to install the packages on the download page.
Re: sudo apt-get install dmd
On 16 March 2015 at 12:36, Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? We could try to host an apt and yum repo on dlang.org. Might be simple to do, but it's not much better than the deb/rpm download we offer. With a repo, at least you can let the package manager take care of upgrades (or non-upgrades if you want to pin a specific version). We could use dlang.org/rpm and dlang.org/debian maybe? Iain
Re: Replace core language HexStrings with library entity
On 15/03/2015 19:46, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities? 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) Also, there are some things which I think are unnecessary: /++/ - If we made /**/ nest, /++/ would be unnecessary. It would potentially break code, but I think it would always cause a compiler error so breakage wouldn't be silent. I think good C code tends to avoid having /* /* */ comments (and instead uses #if 0 ... #endif). q'' non-nested delimited strings. Delimited strings seem to be quite rarely used, but the non-matching form I've never seem in the wild. Probably any intended use of these could instead use the q[] matching form or raw `` or heredoc strings instead.
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:44:38 UTC, Baz wrote: Yes, i'll send a PR tomorrow of tuesday. Thank you !
Re: dfmt options
On Monday, 16 March 2015 at 02:16:18 UTC, Brad Anderson wrote: On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? clang-format has a pretty extensive set: http://clang.llvm.org/docs/ClangFormatStyleOptions.html I don't think all of that is necessary however. When I started using clang-format I just looked at the predefined styles (LLVM, Google, Chromium, Mozilla, Webkit) and picked the one I liked the most and didn't stress the details. I guess what I'm saying is I'd like a bunch of predefined styles. I don't want to wade through 50 options to make my own style. dfmt would, of course, need to support expressing all the predefined styles and all of those differences should have options. That's why dfmt should be able to read the configuration from a file(clang-format has that option). That way, all these predefined styles can simply be style files you can download - no need to make separate paths for predefined styles and custom styles. That being said - I'm against having predefined styles bundled with dfmt(either as separate style files or embedded into the executable). The only build-in style should be the one true style. While there are enough D projects out there to require dfmt to be configurable, we don't have multiple commonly accepted styles like C or C++, and I see no point in encouraging such a thing...
Re: sudo apt-get install dmd
weaselcat wrote in message news:ilvohiiubkvzrglmk...@forum.dlang.org... Do you know if the backend license will remain with DDMD? Yes Actually, is DDMD just a frontend port? I feel sort of dumb now for not checking before asking that : ) And yes, but even if the backend was being converted to D that wouldn't change the license.
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On Monday, 16 March 2015 at 09:03:18 UTC, Lukasz Wrzosek wrote:
Hello
I was just exploring possibility to mimic multiple inheritance
from C++ (do not ask why, just for fun).
I've stumbled on below issue (let's say corner case) and most
likely this is bug in implementation of template Proxy, isn't
it ?
import std.typecons;
class IA {}
class IB {}
class C : IB {
IA a;
mixin Proxy!a;
public this() {
a = new IA;
}
}
void main() {
C c = new C;
IA a = cast(IA)c;
IB b_ok = c;
IB b_not_ok = cast(IB)c;
assert(c !is null);
assert(a !is null);
assert(b_ok !is null);
assert(b_not_ok !is null); //fails
}
What behaviour would you expect if both IA and C inherited from
IB?
Re: Dlang seems like java now,but why not let d more like C# Style?
On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote: Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL. There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability. At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way. overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards..
Re: A few notes on choosing between Go and D for a quick project
On 16/03/2015 10:31 p.m., rumbu wrote: On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote: On 3/16/2015 5:07 PM, ninja wrote: 3. Improve Windows support. Include http://www.dsource.org/projects/bindings/wiki/WindowsApi. The fact that D needs Visual Studio for 64bit apps in 2015 is a shame. Including the WindowsAPI won't change this. D uses the MS toolchain to generate the final binaries. The WindowsAPI static linking model is obsolete. Since the usage of new Windows API Sets, a dynamic linking model integrated in the language is needed (https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx) Something similar with the external directive from Delphi - http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions So instead of writing: extern(Windows) DWORD GetVersion(), we can write: extern(Windows, api-ms-win-core-sysinfo-l1-2-1.dll, [optional funcname]) DWORD GetVersion() or extern(Windows, kernel32.dll) DWORD GetVersion() for older Windows versions (8). I know probably a mixin will partially solve this, but this will save some important boilerplate code (just look at DerelictOrg bindings, thousands LOC just to load some functions from a dll). Don't, please don't dare me... I could totally do this with UDA's and CTFE for function pointers. Plus my new total secret API could make this trivial to hook into.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 10:02:46 UTC, Rikki Cattermole wrote: So instead of writing: extern(Windows) DWORD GetVersion(), we can write: extern(Windows, api-ms-win-core-sysinfo-l1-2-1.dll, [optional funcname]) DWORD GetVersion() or extern(Windows, kernel32.dll) DWORD GetVersion() for older Windows versions (8). I know probably a mixin will partially solve this, but this will save some important boilerplate code (just look at DerelictOrg bindings, thousands LOC just to load some functions from a dll). Don't, please don't dare me... I could totally do this with UDA's and CTFE for function pointers. Plus my new total secret API could make this trivial to hook into. Been there, done that: https://github.com/rumbu13/sharp/blob/master/src/system/runtime/interopservices/package.d alias GetVersion = DllImport!(api-ms-win-core-sysinfo-l1-2-1.dll, GetVersion, DWORD function()) I didn't achieve more than that, i consider this ugly, non-intellisense friendly, that's whay a builtin language construct will be better. Can't wait to see your total super secret API :)
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:18:11 UTC, Baz wrote: On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A Thoughts? Anyone want to write the hex template? I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba Nitpick: Literal is spelled with one t.
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 07:45:16 UTC, Kagamin wrote: On Sunday, 15 March 2015 at 20:36:18 UTC, Marc Schütz wrote: On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote: http://dpaste.dzfl.pl/0f63623cc262a ? Wrong link? Or wrong thread? On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities? Ok, I get it now. But this replaces only `scope(exit)`. What about `scope(success)` and `scope(failure)`?
Re: DlangUI EditLine question
On Sunday, 15 March 2015 at 16:21:21 UTC, Kyle wrote:
I have a variable, x, which I want to update when the content
of a DlangUI EditLine is modified. I tried making this work
with the onContentChange method listed in the API
documentation, but dmd told me it's not there. I've got this
working now by implementing a custom subclass of EditLine as
below:
class XEditLine : EditLine
{
this(string ID, dstring initialContent = null)
{
super(ID, initialContent);
}
override bool onKeyEvent(KeyEvent e)
{
super.onKeyEvent(e);
x = to!double(this.text);
return true;
}
}
This works but it seems like there should be a cleaner way to
do this, any suggestions? Thanks.
You can either override onContentChange or use
onContentChangeListener
override void onContentChange(EditableContent content,
EditOperation operation, ref TextRange rangeBefore, ref TextRange
rangeAfter, Object source) {
super.onContentChange(content, operation, rangeBefore,
rangeAfter, source);
// do something
x = to!double(this.text);
}
or
EditLine line = new EditLine();
line.onContentChangeListener = delegate(EditableContent) {
// do something
x = to!double(line.text);
}
of a DlangUI EditLine is modified. I tried making this work
with the onContentChange method listed in the API
documentation, but dmd told me it's not there. I've got this
If you don't see onContentChange method, probably you have older
version of DlangUI. Try dub upgrade --force-remove
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: Ruby has over 6,000 packages, ...starting with letter A. It's over 100K in total. http://www.modulecounts.com/
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad wrote: On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote: We invariably end up talking about language features and syntax, as if D lost out against Go, because of feature X being (or not being) there. We lose, because we fail to give people that warm glow in their chests. The feeling of now I have something, which is basically what makes people go for something. I felt like this about D when I first got to know it, after a long period of being frustrated with every other language. Although irrational, my intuition was that D would offer me a lot, and it hasn't failed to do so. But this is, because I was willing to make an effort. Many potential users are either not willing to make an effort or they don't have enough time. So we should make it as easy as possible for them. Makes a lot of sense. But… As was said in a post earlier, the decision to go for language X is often not 100% rational, but also based on subjective positive feelings. To ignore this basic human fact, doesn't help us. Having a great language with advanced features and doing some feel good marketing are not mutually exclusive. This is true, but D's main problem isn't that people haven't come to D with high expectations of getting a better alternative to C++. The problem is that they came for emotional reasons and left for rational reasons. This is an interesting assertion, and you have been around here much longer than me. Of course the above must be generally true of any language (since one develops a better sense for what it is like by using it for a while), and I suppose it is also true that people who stick with D stick for more informed reasons. Are there reasons to be concerned that the right kind of people don't stick with D, given that it is still maturing as a language, that not everyone can use it at work, and that there are many options available now, so a degree of churn is normal. A language will be successful by starting with a very high appeal to a certain group, rather than a modest appeal to everyone. They key is in understanding why people leave. Retention of the _target audience_ is more important than adoption rate. Okay, but target audience is an emergent more than a centrally planned property, although one can remove the obvious roadblocks for certain important groups. It seems that many of those that stays with D either picked it for a hobby, or are not primarily programmers (I am not really sure why they pick D? Does not seem like a rational choice.), then a very small (and vocal) group use it for business. I don't know if true without the data (is it worth trying a questionnaire on the download page) but supposing it is true is this surprising given it is not yet standard in the enterprise, and most firms are conservative? Surely most languages get their start in this way. It is a rational choice for people in this camp because native code, and who wants to deal with C++. (And I love C, but...) In my opinion you need to pick a target audience, and with the CTFE focus targeting professional system level programmers is the only thing that makes sense. D needs to deliver on all aspects that C++ is good at before it is marketable, or else it will stay a hobby language for professionals and others. That means matching C++ on stability too. See Innovator's Dilemma and Peter Thiel's work. It needs to have a monopoly of appeal to certain groups, and as it develops spread out from there. I don't see the link between CTFE and systems level programming. If it is more work to implement smart pointers in D than in C++, then there are some fundamentally unacceptable limits in the core language. So it is not only marketing... D is not complete. D needs a redesign to get away from lock-the-world GC without scars... A language redesign that cannot be done with last minute patches of special casing hell. I don't claim to understand the topic well enough, but it looks to me like a relative resource question combined with a desire to do things elegantly (which takes longer even though it is the right way) not a fundamental design question. Over focusing on growing the user base by making tutorials, will only make changes harder, and it will attract the wrong kind of people that will ask for the non-system-level features making it even harder to improve the core language. Why grow the user base before the language is done? You end up with no target audience, a very fragmented user base and equally fragmented eco system. Fragmentation makes it harder to produce professional level things. That's one reason saying D hasn't gone anywhere, so it won't seems a misdiagnosis. It wouldn't have been possible/ the cost would have been higher to move to D2 with a much larger installed base (look at Python), and the language previously perhaps wasn't ready for prime time.
Re: const as default for variables
On Sunday, 15 March 2015 at 22:48:18 UTC, Sönke Ludwig wrote: My idea was to make the change explicit first, but module wide (e.g. using a pragma or similar), so that there is no immediate breakage at all. Only the last stage of the deprecation plan would finally switch over the defaults for unannotated modules. This can be an interesting approach to breaking change that don't introduce new concepts but it can become tricky with mixins and mixin templates because semantic context is different from declaration context.
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #35 from Dicebot pub...@dicebot.lv --- After small e-mail conversation with Walter we came to compromise that this specific issue will remain closed as deprecation can possibly be more problematic than the fix but this won't be considered a normal practice to do and deprecations for non-critical bug fixes won't be rejected. --
Re: Using std.format required std.string?
On 2015-03-15 19:16:52 +, anonymous said: Answerting myself: static if (__traits(compiles, version_minor 67)) import std.string; // format() for versions 2.0.67 else import std.format; // format() for versions = 2.0.67 That doesn't do what you want. You need to `import std.compiler;` for version_minor. Without that import, `__traits(compiles, version_minor 67)` is always false, because version_minor is undefined. I have std.compiler imported. And if you add the import, `__traits(compiles, version_minor 67)` is always true, no matter the value of version_minor. Use `static if(version_minor 67)` instead. Ah, ok. Got it. so __traits(compiles,...) checks if the code can be compiled, that's it. Finally, there's need for this (yet). `std.string.format` is fine with 2.067, too. So unless you're going for (far) future compatiblity, you can just do `import std.string;`. I prefer to move things to the far future compatibility path ASAP. Reduce a lot of maintenance headaches. Thanks for the feedback. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
More interviews please :P
Re: sudo apt-get install dmd
On Sunday, 15 March 2015 at 12:25:35 UTC, Joseph Rushton Wakeling wrote: On 14/03/15 18:31, Andrei Alexandrescu via Digitalmars-d wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? It would be nice to have an official apt repo. I find the way things are packaged there slightly unsatisfactory, inasmuch as it packages various different tools into the dmd-bin package (e.g. both dmd and rdmd) rather than allowing you to install/uninstall them separately. Alternatively, might be worth setting up a dlang PPA on Launchpad (I think it probably makes things easier setting up packages for multiple different Ubuntu and Debian installs). I'm not sure Ubuntu allows hosting non-FLOSS in their PPAs.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 10:12:53 UTC, bachmeier wrote: I once proposed a ban on auto as a return type in documentation examples This. Figuring out the return types in the examples was a daily struggle in the first few weeks.
Re: The next iteration of scope
Marc Schütz: Here's the new version of my scope proposal: http://wiki.dlang.org/User:Schuetzm/scope2 Let's see what Andrei and Walter think about this all :-) Bye, bearophile
Re: sudo apt-get install dmd
On Monday, 16 March 2015 at 11:01:47 UTC, Leandro Lucarella wrote: On Sunday, 15 March 2015 at 12:25:35 UTC, Joseph Rushton Wakeling wrote: On 14/03/15 18:31, Andrei Alexandrescu via Digitalmars-d wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? It would be nice to have an official apt repo. I find the way things are packaged there slightly unsatisfactory, inasmuch as it packages various different tools into the dmd-bin package (e.g. both dmd and rdmd) rather than allowing you to install/uninstall them separately. Alternatively, might be worth setting up a dlang PPA on Launchpad (I think it probably makes things easier setting up packages for multiple different Ubuntu and Debian installs). I'm not sure Ubuntu allows hosting non-FLOSS in their PPAs. They do, but DMD's license specifically prohibits redistribution. I think the best way to solve this is to work on LDC/GDC's compilation speed, I guess.
Re: The next iteration of scope
On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote: I too want a scope attribute e.g. for safe slicing of static arrays, etc. I'm not sure if it's too late for scope by default though, perhaps. If we get @safe by default, we automatically get scope by default, too. I don't follow that. In @safe code parameters could still default to escaping, causing compiler errors when passing things that can't be allowed to escape. I do see that scope parameters by default would probably cause less churn than having to put `scope` on non-template function parameters in order to be usable by non-GC-heap memory. scope T payload; ^ This is a nice way to help enforce the correctness of @safe wrapper types. Yes, it's an exception to the general rule of scope only in function signatures, but it's so useful I think it's worth it. We already have scope on local delegates (at least it's accepted by dmd): Object obj; scope del = ()=obj; Also, what would be the 'type' of a static array slice without `scope` applying to locals? int[2] arr = [1, 2]; scope int[] s = arr; I suppose `scope` can be inferred for s, I'm just pointing out that it can apply to locals.
Re: The next iteration of scope
On 16/03/2015 04:00, Zach the Mystic wrote:
struct RC(T) if(is(T == class)) {
scope T payload;
T borrow() return {// `return` applies to `this`
return payload;
}
}
...
Also, what exactly does the `scope` on T payload get you?
It means if you forget the `return` attribute the compiler would issue
an error about escaping payload. payload only has to be annotated once
and the whole body of RC is checked to prevent implicit escaping of it.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote: One day, the tide may turn towards native efficiency again, say because of mobile or more people writing code that runs on large server clusters, and D will be well-positioned to benefit if and when that happens. I hear ya, we have a NodeJS app running that easily eats 100mb of memory. Every week it grows to 200mb and we have a process manager restart it gracefully (which takes another 50mb). Compare that with a vibe.d app we have: 7mb. And it has been running for over 260 days.
Re: A few notes on choosing between Go and D for a quick project
On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote: We invariably end up talking about language features and syntax, as if D lost out against Go, because of feature X being (or not being) there. We lose, because we fail to give people that warm glow in their chests. The feeling of now I have something, which is basically what makes people go for something. I felt like this about D when I first got to know it, after a long period of being frustrated with every other language. Although irrational, my intuition was that D would offer me a lot, and it hasn't failed to do so. But this is, because I was willing to make an effort. Many potential users are either not willing to make an effort or they don't have enough time. So we should make it as easy as possible for them. Makes a lot of sense. But… As was said in a post earlier, the decision to go for language X is often not 100% rational, but also based on subjective positive feelings. To ignore this basic human fact, doesn't help us. Having a great language with advanced features and doing some feel good marketing are not mutually exclusive. This is true, but D's main problem isn't that people haven't come to D with high expectations of getting a better alternative to C++. The problem is that they came for emotional reasons and left for rational reasons. They key is in understanding why people leave. Retention of the _target audience_ is more important than adoption rate. It seems that many of those that stays with D either picked it for a hobby, or are not primarily programmers (I am not really sure why they pick D? Does not seem like a rational choice.), then a very small (and vocal) group use it for business. In my opinion you need to pick a target audience, and with the CTFE focus targeting professional system level programmers is the only thing that makes sense. D needs to deliver on all aspects that C++ is good at before it is marketable, or else it will stay a hobby language for professionals and others. That means matching C++ on stability too. If it is more work to implement smart pointers in D than in C++, then there are some fundamentally unacceptable limits in the core language. So it is not only marketing... D is not complete. D needs a redesign to get away from lock-the-world GC without scars... A language redesign that cannot be done with last minute patches of special casing hell. Over focusing on growing the user base by making tutorials, will only make changes harder, and it will attract the wrong kind of people that will ask for the non-system-level features making it even harder to improve the core language. Why grow the user base before the language is done? You end up with no target audience, a very fragmented user base and equally fragmented eco system. Fragmentation makes it harder to produce professional level things. It is also completely misguided to push D as a web dev platform. D is up against: Ruby, Python, Dart, node.js+angular, Java, Go etc in an environment where performance is mostly about networking, database/ORM integration and infrastructure AWS/Azure/Google... D is nowhere near being a plausible solution in this space, CTFE is essentially pointless in this domain.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote: On 3/16/2015 5:07 PM, ninja wrote: 3. Improve Windows support. Include http://www.dsource.org/projects/bindings/wiki/WindowsApi. The fact that D needs Visual Studio for 64bit apps in 2015 is a shame. Including the WindowsAPI won't change this. D uses the MS toolchain to generate the final binaries. The WindowsAPI static linking model is obsolete. Since the usage of new Windows API Sets, a dynamic linking model integrated in the language is needed (https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx) Something similar with the external directive from Delphi - http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions So instead of writing: extern(Windows) DWORD GetVersion(), we can write: extern(Windows, api-ms-win-core-sysinfo-l1-2-1.dll, [optional funcname]) DWORD GetVersion() or extern(Windows, kernel32.dll) DWORD GetVersion() for older Windows versions (8). I know probably a mixin will partially solve this, but this will save some important boilerplate code (just look at DerelictOrg bindings, thousands LOC just to load some functions from a dll).
Re: Deadcode on github
On Sunday, 15 March 2015 at 22:33:34 UTC, Jonas Drewsen wrote: On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: On 3/15/2015 2:39 PM, Jonas Drewsen wrote: Here you go... Website: http://deadcode.steamwinter.com Changelog: http://deadcode.steamwinter.com/downloads/Changelog.txt Trello:https://trello.com/b/ufLqwxVW Thank you! BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode I know... and you are right. On the todo... just soo much more fun to code D than HTML. Then use vibe.d and code it in D :D
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-15.html Also remember about the RSS feed here: http://arsdnet.net/this-week-in-d/twid.rss I'm currently out west so I'm a couple hours off, but here's the next installment with summaries of forum discussions - with a few of my opinions added in - and a contributed interview! Lots of cool stuff this week. Nice ! The interview is a cool idea. Nitpick: Loose (P after the dub question ;)
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 08:07:26 UTC, ninja wrote: On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote: If stories are wanted, I might as well tell mine. I am an attorney and a typical programming-language-user: I love to code my own utilities for the job (document-creation, bookkeeping, etc.), but I use Windows and have an android smart phone. In the last 15 years, I tried C (which I still use for specific tasks), C++, C#, Pascal, Java, Perl, Ruby, Lua and D now. I avoided Python and PHP because a good roofer listens to his heart, not his wallet* :) My experiences so far: 1. D has to worst docs I happened to meet. I am still having difficulties figuring out functions like 'any' and 'all', while I understood the Ruby Enumerables at the first time. Same goes to string manipulation. Last time I used std.zip I had to read it's source to make my code work. That's a big warning sign. 2. Please stop changing the (core) language all the time. There are like 3 new proposals every week in the forums and at least 2 of those are seriously considered. Please, just stop. 3. Improve Windows support. Include http://www.dsource.org/projects/bindings/wiki/WindowsApi. The fact that D needs Visual Studio for 64bit apps in 2015 is a shame. 4. D needs some kind of default GUI toolkit. I can't give my utilities to associates/friends because no one wants to use a console any more. I know it is not a small feat, but look at Ruby - they just bundle the last version of Tk with their installer and maintain a thin wrapper. Tk can be love/hated (I actually like its flat and winnative theme) but it enables out-of-the-box platform independent desktop-developement for Ruby. * sorry for the ancient Star Wars/Clerks reference Smart phones seem to have an under allocation of attention to them in the D community given the stakes. If I had the free cashflow I would pay for someone to work on that full time for a bit, but that's not practicable for the time being. Interesting to hear about your experience using D for your work. Would you be willing to write a little more about it and share your experience in a way that could be added to a collection of user stories? For the GUI, have you considered creating a local web front end ? Less work than a pure GUI, but people are used to using a browser.
Re: const as default for variables
On Sunday, 15 March 2015 at 20:09:56 UTC, deadalnix wrote: On Sunday, 15 March 2015 at 07:44:50 UTC, Walter Bright wrote: const ref can tell the optimizer that that path for a ref counted object cannot alter its ref count. That is not clear why. const ref is supposed to protect against escaping when ref does not ? There are two cases here. One is when the reference is copied to new variable, which would actually break const because the reference count of the original data would have to be incremented (which is a separate issue). But the other case is where the original is reassigned, in which the counter for the data it used to point to gets decremented, possibly to zero. `const` would guarantee against this. But even this is a blunt force weapon, because it would also stop you from mutating the original data, even though that wouldn't change the reference count.
Re: Deadcode on github
On Monday, 16 March 2015 at 10:07:16 UTC, Dicebot wrote: On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode GitHub README.md is a natural place for such information. How far you estimate it from being buildable/usable on Linux? It was buildable on Linux a month ago on my server. Usable I cannot say because I have never tried it on a linux box with a monitor. It really hurts me to say since I've been a die hard linux user for many years, but my work the recent years has been solely mac/win which led me in this direction. That will change at some point though. Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. /Jonas
[Issue 14292] New: writing to file opened for reading - incorrect error report
https://issues.dlang.org/show_bug.cgi?id=14292
Issue ID: 14292
Summary: writing to file opened for reading - incorrect error
report
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: ga...@mail.ru
Created attachment 1492
-- https://issues.dlang.org/attachment.cgi?id=1492action=edit
the example code
Say we want to overwrite a file test.txt.
Say we instead have a typo and so open it for reading.
After trying to write to the file, a hilarious message appears:
-
std.exception.ErrnoException@somepath\std\stdio.d(2113): (No error)
-
The culprit (line 2337 of stdio.d at master currently) is:
-
if (result != writeme.length) errnoEnforce(0);
-
That errnoEnforce(0) produces a nonsense message ...ErrnoException...: (No
error).
Which I believe is wrong code regardless of the context.
But I don't know which way of reporting the error is right here.
Below is the complete example code.
The file test.txt must be present for it to work.
Its contents may be arbitrary.
-
import std.stdio;
void main ()
{
auto f = File (test.txt, rt); // file must exist
f.writeln (!);
}
-
--
Re: `return const` parameters make `inout` obsolete
On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote: On Mon, 16 Mar 2015 14:17:57 +, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. but why compiler has to rewrite return type? i never told it to do that! It has to if you pass an immutable to x, which you're allowed to do. It only gives an error if you assign the result to a mutable variable. The point is that the signature still contains all the information it needs without `inout`. What old errors will fail to be reported and what new errors would it cause? I haven't been able to think of any.
Re: `return const` parameters make `inout` obsolete
On Monday, 16 March 2015 at 15:39:39 UTC, ketmar wrote: On Mon, 16 Mar 2015 15:33:40 +, Zach the Mystic wrote: On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote: On Mon, 16 Mar 2015 14:17:57 +, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. but why compiler has to rewrite return type? i never told it to do that! It has to if you pass an immutable to x, which you're allowed to do. It only gives an error if you assign the result to a mutable variable. The point is that the signature still contains all the information it needs without `inout`. What old errors will fail to be reported and what new errors would it cause? I haven't been able to think of any. this is the question of consistency. if i wrote `char* fun()`, i want fun to return `char*`, and i'm not expecting it to change in a slightest. i don't like when compiler starts to change things on it's own. I think it's just less cluttered than `inout`. The simple fact is that if you try to assign an immutable variable to a mutable reference, you will still get an error. I doubt it would take long for programmers to adjust to the new way of reading the signatures. They just see `return` sitting there in front of `const` and know how to handle the situation.
Re: Replace core language HexStrings with library entity
On 16/03/2015 14:22, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. They need to nest in order to allow block comments in documentation blocks.
Re: `return const` parameters make `inout` obsolete
On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. That's a very interesting observation. I never liked the name `inout`, as it doesn't describe what it does. The only downside I see is that it's more magic, because nothing on the return type says its mutability is going to depend on an argument. I think Kenji also had additional plans for `inout`, related to uniqueness. There was a PR. Better ask him whether it's going to be compatible.
Re: Facebook, D and the web
On Monday, 16 March 2015 at 14:47:15 UTC, Chris wrote: In a recent thread[1] there was a lot of talk about how to make D more attractive, how to communicate it's advantages to a broader audience etc. I was wondering, if Facebook would be interested in either developing or championing the development of a scripting language based on D that would be a. useful for in-house development at Facebook and b. for a broad audience of web developers. This would (ideally) be a language that: 1. is easy, even for non-programmers (like Lua and Python) 2. can be used to easily build web based UI apps (forms etc) 3. can be used for server-side programming and data analysis 4. is, of course, compatible with D and can be extended with modules written in D (and C for that matter) 5. runs on mobile platforms 6. may be able to interact with JS 7. is open source I don't know, if there is any demand for this at Facebook at the moment, but I could imagine that there is demand for a better web language in general. People keep mentioning killer apps for D and maybe a killer technology / framework would be even better. Facebook aside, I can see a use for an interpretable subset of D. It could be used in templates, for example for vibe.d. These could then be loaded at runtime, leading to faster development (no need to recompile if just a template is changed). In release mode, they could still be precompiled.
Re: `return const` parameters make `inout` obsolete
On Mon, 16 Mar 2015 15:54:19 +, Zach the Mystic wrote: I think it's just less cluttered than `inout`. The simple fact is that if you try to assign an immutable variable to a mutable reference, you will still get an error. I doubt it would take long for programmers to adjust to the new way of reading the signatures. They just see `return` sitting there in front of `const` and know how to handle the situation. having argument modifier that changes function return type is very surprising regardless of how much people used to it. really, why should i parse *arguments* to know the (explicitly specified!) *return* *type*? it's ok with `auto`, it's ok with `inout`, but when i wrote `char *`, i want `char *`. and then compiler decides that it knows better. ok, compiler, you win, can you write the rest of the code for me? no? stupid compiler! signature.asc Description: PGP signature
Re: Deadcode on github
On Monday, 16 March 2015 at 15:37:00 UTC, ketmar wrote: On Mon, 16 Mar 2015 15:14:02 +, Jonas Drewsen wrote: Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. i tried to build it, but no luck: it can't build libdparse. ah, the joy of dub... is there any way to build some testing app that doesn't require libdparse? i'm not in a mood of fixing anything right now... It is only extensions that using libdparse. You should be able to remove extensions/language/d folder and the extensions/highlight/d.d file and make it work I believe.
Re: `return const` parameters make `inout` obsolete
On Monday, 16 March 2015 at 16:02:57 UTC, Idan Arye wrote: On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. Is the `return` in the argument list a new feature? It doesn't compile in 2.066, and I don't see it in 2.067's changelog... It's been experimentally introduced by DIP25: http://wiki.dlang.org/DIP25
Re: GDC fails to link with GSL and fortran code
On Mon, 16 Mar 2015 16:44:45 +, Andrew Brown wrote: can you please show output of `dmd -v` and `gdc -v`, so we can see the actual commands they both using for linking? signature.asc Description: PGP signature
Re: What is the best practice of organization multi-threading ?
UP
[Issue 14283] [2.067-b4]: Spurious this is not an lvalue deprecation message for auto ref arguments
https://issues.dlang.org/show_bug.cgi?id=14283 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/56e59d841a3854afb8509f5930bfa4016fa7443d Merge pull request #4497 from MartinNowak/fix14283 fix Issue 14283 - spurious 'this' is not an lvalue deprecation for auto ref --
Re: `return const` parameters make `inout` obsolete
On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. Is the `return` in the argument list a new feature? It doesn't compile in 2.066, and I don't see it in 2.067's changelog...
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote: Walter Bright: Unfortunately, it needs to be a dropin replacement for x..., which returns a string/wstring/dstring. This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() --- additionally to x string, a template parameter allows to put raw whites, e.g --- assert(hexString!(30 30, true) == 0 1); assert(hexString!(30 31) == 01); // standard x string ---
Re: struct / cast / ? design problem
On 03/15/2015 04:51 PM, ketmar via Digitalmars-d-learn wrote:
On Sun, 15 Mar 2015 16:34:14 -0700, Charles Hixson via Digitalmars-d-learn
wrote:
if you know the exact layouts of `spare`, you can use union for that:
struct S {
// ...
union {
ulong[61] spare;
struct { int vala; ubyte valb; }
// etc.
}
}
and then you can use it like this:
auto s = S();
s.vala = 42;
assert(s.spare[0] == 42);
you can also write a CTFE function that builds struct to cast where
`spare` is changed to something else, using `S` as a source, but this
solution will not be pretty. ;-)
The original method had no knowledge of the layout that the using module
will need, merely that it will need to store some information. (In this
particular case I *could* just modify the header in the original file,
but that isn't solving the design problem, and means that working code
needs to be modified to accommodate new code in a different file.)
IOW, if I could write the union, I wouldn't have needed to label the
unused header memory spare. That solution *would* allow for multiple
secondary users, with different union values, but it would again mean
that new code would require the modifying of the file containing
existing code. This is normally considered bad practice.
Re: A few notes on choosing between Go and D for a quick project
On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote: The future is here already, but just not evenly distributed (Gibson). It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals. Facebook is an edge case. Most computers run idle 90% of the time... If you need to complete something fast (but not low latency real time) you can do it in parallel paying by the hour, cheaper and more hassle free than ever before. whilst the free lunch from Moore's Law is over. Not so sure about Moore's Law, keep in mind that Intel has very little pressure from AMD these days. But faster/bigger things are out there: http://en.wikipedia.org/wiki/Neurogrid http://en.wikipedia.org/wiki/Memristor http://en.wikipedia.org/wiki/Field-programmable_gate_array But these kinds of technologies are more expensive to develop for. That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions. Not very specific, so hard to address, but factor in the increased development cost and you might see that it becomes cheaper to run it on a rented cluster using dedicated tools even if the code is running at half speed. Average programmers are less and less capable of writing fast code... and the work it takes to write fast code is expensive. Not many are willing to pay for it, so in most cases it is cheaper to buy/rent better tools/hardware. But that's only because hardware is cheap compared to programmer time in most cases! If hardware was expensive then more people would be willing to pay for hand optimised programming?
GDC fails to link with GSL and fortran code
Hi, I'm trying to compile code which calls C and fortan routines from D on the linux cluster at work. I've managed to get it to work with all 3 compilers on my laptop, but LDC and GDC fail on the cluster (though DMD works perfectly). I'm using the precompiled compiler binaries on these systems, the cluster doesn't have the prerequistites for building them myself and I don't have admin rights. For GDC the commands I run are: gcc -c C_code.c Fortran_code.f gdc D_code.d C_code.o Fortran_code.f -lblas -lgsl -lgslcblas -lm -lgfortran -o out The error messages are: /software/lib64/libgsl.so: undefined reference to `memcpy@GLIBC_2.14' /software/lib64/libgfortran.so.3: undefined reference to `clock_gettime@GLIBC_2.17' /software/lib64/libgfortran.so.3: undefined reference to `secure_getenv@GLIBC_2.17' collect2: error: ld returned 1 exit status I can remove the gsl messages by statically linking to libgsl.a, but this doesn't solve the gfortran issues. If anyone knows a way round these issues, I'd be very grateful. I'd also eventually like to find a way to easily share linux biniaries with people, so they can use this code without these kinds of headaches. If anyone has any advice for making this portable, that would also help me out a lot. Thanks very much Andrew
Re: Replace core language HexStrings with library entity
On 3/16/15 9:29 AM, Baz wrote: On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote: Walter Bright: Unfortunately, it needs to be a dropin replacement for x..., which returns a string/wstring/dstring. This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() --- (Drop the public, this ain't Java.) I don't see a necessity for the input string having different widths; string is enough. There may be a necessity to choose the width of the output with changes in function name, e.g. hexWString and hexDString. That opens the question whether we want only ubyte[] for hex bytes or all integral types. additionally to x string, a template parameter allows to put raw whites, e.g --- assert(hexString!(30 30, true) == 0 1); assert(hexString!(30 31) == 01); // standard x string --- I don't see a need for this. Andrei
Re: A few notes on choosing between Go and D for a quick project
On 15/03/2015 05:06, Walter Bright wrote: In D we have some implicit casts also because the cast(int)x syntax is dangerous. But now we can write safe casts with the int(x) syntax, so there's less need of naked implicit casts. Again, too many casts can cause bugs. You can have safe wrappers for casts. If you don't want to change the type, use something like std.conv.signed. Isn't that safe?
[Issue 14279] [REG:git-head]Failed to make dmd because of idgen : HOST_DC missing
https://issues.dlang.org/show_bug.cgi?id=14279 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com Resolution|FIXED |WONTFIX --
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 09:53:38 UTC, Mathias Lang wrote: Nitpick: Loose (P after the dub question ;) thanks, fixed
Facebook, D and the web
In a recent thread[1] there was a lot of talk about how to make D more attractive, how to communicate it's advantages to a broader audience etc. I was wondering, if Facebook would be interested in either developing or championing the development of a scripting language based on D that would be a. useful for in-house development at Facebook and b. for a broad audience of web developers. This would (ideally) be a language that: 1. is easy, even for non-programmers (like Lua and Python) 2. can be used to easily build web based UI apps (forms etc) 3. can be used for server-side programming and data analysis 4. is, of course, compatible with D and can be extended with modules written in D (and C for that matter) 5. runs on mobile platforms 6. may be able to interact with JS 7. is open source I don't know, if there is any demand for this at Facebook at the moment, but I could imagine that there is demand for a better web language in general. People keep mentioning killer apps for D and maybe a killer technology / framework would be even better. [1] http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com
Re: sudo apt-get install dmd
On 3/16/15 5:47 AM, Iain Buclaw via Digitalmars-d wrote: On 16 March 2015 at 12:36, Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? We could try to host an apt and yum repo on dlang.org. Might be simple to do, but it's not much better than the deb/rpm download we offer. With a repo, at least you can let the package manager take care of upgrades (or non-upgrades if you want to pin a specific version). Yah, that would be better than just the downloads. We could use dlang.org/rpm and dlang.org/debian maybe? Would be awesome. Who can work on this? Andrei
Re: Deadcode on github
On Monday, 16 March 2015 at 09:52:55 UTC, extrawurst wrote: On Sunday, 15 March 2015 at 22:33:34 UTC, Jonas Drewsen wrote: On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: On 3/15/2015 2:39 PM, Jonas Drewsen wrote: Here you go... Website: http://deadcode.steamwinter.com Changelog: http://deadcode.steamwinter.com/downloads/Changelog.txt Trello:https://trello.com/b/ufLqwxVW Thank you! BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode I know... and you are right. On the todo... just soo much more fun to code D than HTML. Then use vibe.d and code it in D :D As a matter of fact I am using vibe.d for the website. Unfortunately I found out that the iteration time is quite bad which is important for web development. It would especially be nice if vibe.d could detect if there is no D logic in the diet file and if not parse+render it directly at runtime instead (may in dev mode only). That way you would not have to wait for compile+link everytime you insert a paragraph you want to preview. /Jonas
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On Monday, 16 March 2015 at 12:03:12 UTC, John Colvin wrote: What behaviour would you expect if both IA and C inherited from IB? This case should assert at compile time. But my example shows that case with implicit case is working, but the explicit cast is not. That seems to be incorrect IMO.
Re: Facebook, D and the web
On Monday, 16 March 2015 at 14:47:15 UTC, Chris wrote: In a recent thread[1] there was a lot of talk about how to make D more attractive, how to communicate it's advantages to a broader audience etc. I was wondering, if Facebook would be interested in either developing or championing the development of a scripting language based on D that would be a. useful for in-house development at Facebook and b. for a broad audience of web developers. This would (ideally) be a language that: 1. is easy, even for non-programmers (like Lua and Python) 2. can be used to easily build web based UI apps (forms etc) 3. can be used for server-side programming and data analysis 4. is, of course, compatible with D and can be extended with modules written in D (and C for that matter) 5. runs on mobile platforms 6. may be able to interact with JS 7. is open source I don't know, if there is any demand for this at Facebook at the moment, but I could imagine that there is demand for a better web language in general. People keep mentioning killer apps for D and maybe a killer technology / framework would be even better. [1] http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com Having a way to do data analysis in a notebook like Ipython would be very nice indeed. At the moment your best option is calling D from Julia or Python. D REPL won't cut the mustard because you want persistent state to be able to iteratively explore large data sets without reloading from disc every time you enter a new command. You could use a RAM disk, but that's still very clumsy. I disagree with the other poster that the standard library is bloated. It just needs better docs.
Re: The next iteration of scope
On Monday, 16 March 2015 at 13:55:43 UTC, Marc Schütz wrote:
Also, what exactly does the `scope` on T payload get you? Is
it just a more specific version of `return` on the this
parameter, i.e. `return this.payload`? Why would you need that
specificity? What is the dangerous operation it is intended to
prevent?
Nick already answered that. I'll expand on his explanation:
Let's take the RC struct as an example. Instances of RC can
appear with and without scope. Because structs members inherit
the scope-ness from the struct, `payload` could therefore be an
unscoped pointer. It could therefore be escaped
unintentionally. By adding `scope` to its declaration, we force
it to be scoped to the structs lifetime, no matter how it's
accessed.
If an RC'd struct is heap-allocated, but one of its members
points to the stack, how is it ever safe to escape it? Why
shouldn't the heap variable be treated as scoped too, inheriting
the most restricted scope of any of its members? To me, the
question is not how you can know that a member is scoped, so much
as how you could know that it *isn't* scoped, i.e. that a
sub-pointer was global while the parent was local. I think it
would require a very complicated type system:
struct S {
T* p;
}
// note the elaborate new return signature
T* fun(return!(S.p) S x) {
return x.p;
}
T* run() {
S s;
s.p = new T; // s local, s.p global
return fun(s);
}
The above is technically safe, but the question is whether it's
too complicated for the benefit. In the absence of such a
complicated system, the safe default is to assume a struct is
always as scoped as its most scoped member (i.e. transitive
scoping). Your idea of `scope` members would only be valid in the
absence of this safe default. But even then it would be of
limited usefulness, because it would prevent all uses of global
references in those members, even if the parent was global. For
me, it comes down to that you can't know if anything is global or
local until you define an instance of it, which you can't do in
the struct definition.
