Re: DConf: register now!
On 4/6/2015 10:08 PM, Daniel Murphy wrote: w0rp wrote in message news:zynuvcoprfgplvboq...@forum.dlang.org... I spotted a typo in the schedule. Daniel Murphy's talk says Motivation for converting the project to C++. That should say to D. My secret plan is to convert it back to C++ after we've converted it to D. 1960's machine translation: The spirit is strong but the flesh is weak. To Russian, then back to English: The vodka is good, but the meat is rotten. translate.google.com gets it right, but I suspect it is cheating.
Re: Strange behavior std.range.takeNone
Yes it is.
takeNone() take a char from a string.
So you are going to append a char (with code 5) on the next line.
If you replace that line with:
s ~= 65;
it will print A. (65 is ascii code for letter 'A')
On Tuesday, 7 April 2015 at 02:24:00 UTC, Dennis Ritchie wrote:
Hi,
Is it OK?
-
import std.stdio : writeln;
import std.range : takeNone;
void main() {
auto s = takeNone(test);
s ~= 5;
writeln(s); // prints ♣
}
-
Windows 8.1 x64, DMD 2.067.0
Re: Static if to compare two types are the exact same
On Tuesday, 7 April 2015 at 06:37:50 UTC, Jonathan wrote: static if (is(T == V)) Are static ifs always checked outside of runtime? Is it possible for a static if condition to be undeterminable outside of runtime, or would such a condition throw a compiler error? 'static if' is always run at compile time, so it needs access to compile time information. Fortunately, you can access quite a lot at compile time in D.
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #14 from yebblies yebbl...@gmail.com --- (In reply to Martin Nowak from comment #9) If you really think we should fix this, then a time limit for CTFE execution might be feasible. An iteration limit would be better than a time limit, because it will not be dependent on environmental conditions. This would need to be configurable from the command line etc. The compilation would terminate with a nice stack trace, making it easy to debug. (In reply to Jens Bauer from comment #10) 1: on dlang.org, there's an on-line compiler. It wouldn't take much effort to bring it to the knees. It's trival to make a D program that will take a very very long time to compile, even without infinite loops. --
Re: Why I'm Excited about D
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
Hello everyone, this is my first post on the forum. I've been
investigating the language for the past few weeks. I was able
to complete my first useful program thanks to very helpful
people in #d on IRC . The experience made me very interested in
the language and improving the community around it.
I'm primarily Ruby developer (been so about the last 7-8 years)
doing web stuff with significant JavaScript work as well. I
wrote a blog post on why I'm excited about D. You can read it
here: http://hawkins.io/2015/04/excited-about-d/.
I've been reading the forums here so I can see that there is a
focus on improving the marketing for the language and growing
the community. I see most of the effort is geared towards C++
programmers, but have you considered looking at us dynamic
languages folk? I see a big upside for us. Moving from Ruby to
D (my case) gives me power performance. I still have OOP
techniques but I still have functional things like closures and
all that good stuff. Only trade off in the Ruby case is
metaprogramming. All in all I think there is a significant
value promise for those of us doing backend services for folks
like me.
Regardless, I figured it might be interesting to hear about
some experience coming to the language from a different
perspective. Cheers!
This is awesome :)
A few notes on the blog:
peaked my interest should be piqued my interest
You can have as many unittest blocks as you want in a file/module.
@property isn't really about parentheses-less calls (parentheses
are optional for all function calls), it's more for this sort of
thing:
struct S
{
private int a_;
enum flagMask = 1u 31;
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
@property int val()
{
return a_ ~flagMask;
}
@property void flag(bool b)
{
a_ = ((cast(uint)b) 31) (a_ ~mask);
}
@property bool flag()
{
return a_ flagMask;
}
}
unittest
{
S s;
s.flag = true;
s.val = 75;
assert(s.flag);
assert(s.val == 75);
}
Note that the assignments are calling the property functions.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 01:12:20 UTC, bachmeier wrote: The thing I liked, coming from languages like R and Ruby, was that I could write D code in the most convenient, least efficient manner possible and still get good enough performance that it wouldn't matter. I find D to be easier to write than any scripting language. When I write D I always have to remind myself that I can just write, without concern for efficiency. And in the few cases that performance is critical I know I can do as well as C. This! This is really the thing I like about D overall! I used to prototype in python and either rewrite part of it in C (process involving lots of latent rage for missing common features) or give up on performance (which, honestly, was most of the time a good answer). In D I feel like I don't have this tradeoff. I start prototyping in D putting auto everywhere and not anotating anything and when the prototype works I just start cleaning the code, annotating it, etc The fact that where I used two languages I can now use only one is what convinced me (even if, to be fair, the prototyping part is way much easier in python... But that may be due to the gab of experience).
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 04:05:38 UTC, Vladimir Panteleev wrote: On Tuesday, 7 April 2015 at 03:17:26 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP76 I am against this. It can lead to silent irreversible data corruption. I can see the value in both. With something like Objective C on iOS, basically everything is nothrow. They don't do any cleanup for references when exceptions happen, so they don't generate slower reference counting code. Exceptions in Objective C on iOS are not supposed to be caught ever. So you don't use exceptions and garbage collection, your code runs pretty fast, and your applications are smooth. On the other hand, not throwing the exceptions leads to silent failures, which can lead to creating garbage data. Objective C in particular is designed to tolerate failure, given that messages run on nil objects simply do nothing and return cast(T) 0 for the message's return type. You're in a world of checking return codes, validating data, etc. Maybe autodecoding could throw an Error (No 'new' allowed) when debug mode is on, and use replacement characters in release mode. I haven't thought it through, but that's an idea.
Re: getting started with std.csv
On Tuesday, 7 April 2015 at 05:51:33 UTC, yazd wrote:
On Tuesday, 7 April 2015 at 05:49:48 UTC, yazd wrote:
I got this to work with:
```
import std.stdio, std.file, std.csv, std.range;
void main()
{
std.file.write(test.csv, 0,1,abc\n2,3,def);
scope(exit) std.file.remove(test.csv);
static struct Rec { int a, b; char[] c; }
auto file = File(test.csv, r);
foreach (s; csvReader!Rec(file.byLine().joiner(\n)))
{
writeln(struct - , s);
}
}
```
I am not sure about using `file.byLine()` here, because
`byLine` reuses its buffer, but this is working correctly (for
some reason, anyone can comment?) as far as I tested.
Btw, joiner is a lazy algorithm. In other words, it doesn't
join the whole file when it is called but only when needed.
This reduces the memory requirements as you won't need the
whole file in memory at once.
Replace `std.range` with `std.algorithm`.
Re: Reggae v0.0.5 super alpha: A build system in D
On Sunday, 5 April 2015 at 12:50:52 UTC, Kagamin wrote: On Sunday, 5 April 2015 at 12:22:15 UTC, Dicebot wrote: Unless LDC does some D specific WPO magic I am not aware of this is not what your original statement was about. llvm does normal WPO in a sense that compiled code is not opaque. And I have never been speaking about normal WPO, only about one specific to D semantics. Erm. Either it is coding style issue or a language issue. Pick one. Only coding style for D I am aware of that deals with attribute hell is ignore most attributes which is hardly solution. The problem can't be solved for coding styles, which rely on attribute hell, I only said the problem depends on coding style. This sentence probably means something but I were not able to figure it out even after re-reading it several times. coding style which relies on attribute hell, what kind of weird beast that is?
Re: Reggae v0.0.5 super alpha: A build system in D
On Monday, 6 April 2015 at 11:29:20 UTC, Sergei Nosov wrote: On Sunday, 5 April 2015 at 00:22:35 UTC, Atila Neves wrote: It seems to me that different projects might benefit from different compilation strategies. It might just be a case of unit tests alongside production code vs in separate files. As mentioned before, my experience with per-module compilation was usually faster, but I'm going to change the default to be per package. I want to also share my experience in that regard. ... See, the problem with this approach is that you can trivially get out of 1GB of memory with DMD even when compiling single module, all you need is to do enough compile-time magic. Separate compilation here delays the issue but does not actually solve it. If any effort is to be put into supporting this scenario (on-server compilation), it is better to be put in reducing actual memory hog of compiler, not supporting another workaround. Also you can still achieve the similar profile by splitting your project in small enough static libraries, so it is not completely out of question.
[Issue 14350] Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/6833d64a4f3ab2fb7af979ddf9ab1558dd369606 fix Issue 14350 - Unit test failures are not displayed in Windows GUI programs https://github.com/D-Programming-Language/druntime/commit/de0c8495054995fbb0237f53c9752ebd65884034 Merge pull request #1200 from CyberShadow/pull-20150327-170332 fix Issue 14350 - Unit test failures are not displayed in Windows GUI pr... --
[Issue 14350] Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14420] New: partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420
Issue ID: 14420
Summary: partial template ordering with specialization and
different arities seems broken
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
void foo(string op:+, T)(ref T val, T mod)
{
}
void foo(string op, T, V1)(ref T val, V1 mod)
{
}
void main()
{
int i32 = 12;
foo!+(i32, 13); // should match first
ubyte u8;
foo!+(u8, 1); // not sure about this one
}
---
Maybe my intuition is wrong here, but it's surprising that the first template
function which is specialized for op:+ isn't called.
--
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 07:42:02 UTC, w0rp wrote: Maybe autodecoding could throw an Error (No 'new' allowed) when debug mode is on, and use replacement characters in release mode. I haven't thought it through, but that's an idea. No no no, terrible idea. This means your program will pass your test suite in debug mode (which, of course, is never going to test behavior with bad UTF in all the relevant places), but silently corrupt real-world data in release mode. Errors and asserts are for logic errors, not for validating user input!
Re: Mid-term vision review
On Monday, 6 April 2015 at 18:17:31 UTC, deadalnix wrote: On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started. Over time, while researching how macro approach feels like in other languages, I have become more sceptical of providing it as a generally available feature. But it could be interesting to allow them only in std / core package to be able to move more language implementation into library.
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 03:17:26 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP76 Deprecation can be reported by checking version: version(EnableNothrowAutodecoding) alias autodecode=autodecodeImpl; else @deprecated(compile with -version=EnableNothrowAutodecoding) alias autodecode=autodecodeImpl;
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 03:17:26 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP76 I have doubts about it similar to Vladimir. Main problem is that I have no idea what actually happens if replacement characters appear in some unicode text my program processes. So far I have that calming feeling that if something goes wrong in this regard, exception will slap me right into my face. Also it is worrying to see so much effort put into `nothrow` in language which endorses exceptions as its main error reporting mechanism.
[Issue 14420] partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420 --- Comment #1 from Ketmar Dark ket...@ketmar.no-ip.org --- i'm expecting the same (with second instantiates non-specialized template, which it does currently). --
Re: Why I'm Excited about D
On Mon, 06 Apr 2015 23:51:16 +, Adam Hawkins wrote: I've been reading the forums here so I can see that there is a focus on improving the marketing for the language and growing the community. I see most of the effort is geared towards C++ programmers, but have you considered looking at us dynamic languages folk? it seems that there are not so many people that comes from some dynamic language. i believe that most of us using c/c++ (c#/java/etc.), so while we know bits and pieces about dynamic land, we generally not using it for something serious (unless we are forced to do so ;-). Regardless, I figured it might be interesting to hear about some experience coming to the language from a different perspective. sure. you're welcome, it's always good to have more opinions, both positive (yay!) and negative (heh... so what we can do with that?). signature.asc Description: PGP signature
Re: Static if to compare two types are the exact same
static if (is(T == V)) Are static ifs always checked outside of runtime? Is it possible for a static if condition to be undeterminable outside of runtime, or would such a condition throw a compiler error?
Re: DConf: register now!
On 7 April 2015 at 07:08, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: w0rp wrote in message news:zynuvcoprfgplvboq...@forum.dlang.org... I spotted a typo in the schedule. Daniel Murphy's talk says Motivation for converting the project to C++. That should say to D. My secret plan is to convert it back to C++ after we've converted it to D. Then after the convert back to C++, convert it to Erlang.
Re: [WORK] Bringing http://dlang.org/phobos/ in good shape
On 3/31/2015 12:32 PM, Andrei Alexandrescu wrote: I'm looking at the dlang.org statistics and am seeing the top pages looked at are: download.html, changelog.html, and phobos/. The first two are nice, but http://dlang.org/phobos/ is in serious need of completion - many modules don't have a brief description. Could anyone make this their priority? Yes, Master: https://github.com/D-Programming-Language/phobos/pull/3155 BTW, the markup of this page sux. It uses $(BR) where it should be using tables. But that's fodder for a separate PR. This one just addresses the text.
Re: Why I'm Excited about D
On 2015-04-07 01:51, Adam Hawkins wrote: Only trade off in the Ruby case is metaprogramming. You can do metaprogramming in D, it's just a bit different compared to Ruby. -- /Jacob Carlborg
Re: Why I'm Excited about D
On 2015-04-07 02:29, Adam D. Ruppe wrote: On Tuesday, 7 April 2015 at 00:15:51 UTC, w0rp wrote: [...]and runtime templates. The last two haven't been written yet. Really? Runtime templates aren't even hard to implement vibe.d has a template system. It's based on Jade, which seems to be based on Haml. -- /Jacob Carlborg
Re: Making regex replace CTFE by removing malloc
thank you. and i read the code a little, and found that matching engine using stream- like interface to work with data, so it wouldn't be very hard to use ranges instead of strings. and for real regexps (those without backtracking) range seems to doesn't even require random access. signature.asc Description: PGP signature
Re: DIP76: Autodecode Should Not Throw
Vladimir Panteleev: std.conv doesn't return NaN if you try to convert banana to a double. I have suggested to add a nothrow function like maybeTo that returns a Nullable result. Bye, bearophile
Re: D1: Out of memory problems
Depends on how you fill aTUs.
Re: Why I'm Excited about D
import std.stdio, std.parallelism;
auto names = [ Adam Hawkins, Peter Esselius ];
foreach(name; taskPool.parallel(names)) {
writeln(name);
}
There is a convenience function in std.parallelism that allows
you to write the following instead for your foreach loop:
foreach (name; names.parallel) {
writeln(name);
}
Also, @system, @trusted, @safe don't really have much to do
with optimization or access levels, but safety. Theoretically,
if all of your code is @safe, then it is impossible for your
program to corrupt memory.
Also, have you considered posting this article to Hacker
News/Reddit?
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
Re: D1: Out of memory problems
For example if you slice the original string, it will be preserved in memory. That's why parsers keep parsed substrings by duplicating them - this can result in smaller memory footprint.
Re: Mid-term vision review
On Friday, 3 April 2015 at 15:35:15 UTC, Iain Buclaw wrote: On 3 April 2015 at 12:10, Andrea Fontana via Digitalmars-d digitalmars-d@puremagic.com wrote: It would be great to have dmd on embedded platforms. We have GDC supporting ARM, MIPS, PPC, S390, etc... LDC supporting ARM... what more do you want? Hmmm, probably I'm missing something. I tried some time ago to develop something for raspberry pi co but it wasn't fully supported, if I'm right. Is phobos ported too? It would really useful: have you ever seen code for 3d printers? It would be benefit a lot from D :) I build a 3d printer, and its firmware is written in C for arduino from many hands. I thinks it would a good idea to switch to something like rpi, and rewrite firmware in D, it's not that complex. I had to check many times that C code, and I think it's really messy. Andrea
Re: Strange behavior std.range.takeNone
On Tuesday, 7 April 2015 at 08:49:58 UTC, Andrea Fontana wrote: Yes it is. takeNone() take a char from a string. So you are going to append a char (with code 5) on the next line. If you replace that line with: s ~= 65; it will print A. (65 is ascii code for letter 'A') Thanks. I am aware :)
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 09:04:09 UTC, Walter Bright wrote: On 4/7/2015 1:19 AM, Dicebot wrote: I have doubts about it similar to Vladimir. Main problem is that I have no idea what actually happens if replacement characters appear in some unicode text my program processes. It's much like floating point NaN values, which are 'sticky'. Yes, but std.conv doesn't return NaN if you try to convert banana to a double. With UTF strings, if you care about invalid UTF (a surprisingly large amount of operations done on strings simply don't care about invalid UTF) the validation can be done as a separate step. So can converting invalid UTF to replacement characters. Also it is worrying to see so much effort put into `nothrow` in language which endorses exceptions as its main error reporting mechanism. There is definitely a tug of war going on there. Exceptions are great, except they aren't free. What I've tried to do is design things so that erroneous input is not possible - that all possible input has straightforward output. In other words, try to define the problem out of existence. Then there are no errors. I think the correct solution to that is to kill auto-decoding :) Then all decoding is explicit, and since it is explicit, it is trivial to allow specifying the desired behavior upon encountering invalid UTF-8.
Re: DIP76: Autodecode Should Not Throw
On 4/7/2015 2:10 AM, Vladimir Panteleev wrote: On Tuesday, 7 April 2015 at 09:04:09 UTC, Walter Bright wrote: On 4/7/2015 1:19 AM, Dicebot wrote: I have doubts about it similar to Vladimir. Main problem is that I have no idea what actually happens if replacement characters appear in some unicode text my program processes. It's much like floating point NaN values, which are 'sticky'. Yes, but std.conv doesn't return NaN if you try to convert banana to a double. Maybe it should :-) With UTF strings, if you care about invalid UTF (a surprisingly large amount of operations done on strings simply don't care about invalid UTF) the validation can be done as a separate step. So can converting invalid UTF to replacement characters. I know, I read your post. The machinery to allocate, throw, catch, and replace is still there. I think the correct solution to that is to kill auto-decoding :) Then all decoding is explicit, and since it is explicit, it is trivial to allow specifying the desired behavior upon encountering invalid UTF-8. I agree autodecoding is a mistake, but we're stuck with it.
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei vibe.d is a comprehensive approach to web development that is approaching maturity. We aim to raise its importance and relevance to D development: offer bundled installation with dmd, release in lockstep, make working with vibe.d an acceptance criterion for dmd releases. This idea does not sit well with me. I don't want D to become a framework like this (coming from Rails nonsense with Ruby). If the the compiler and the library will be released at the same time, then why not put vibe.d into phobos? Maybe not the entire thing but at least parts of it.
Re: getting started with std.csv
Many thanks for the feedback yazd! I've tested the approach with
a large csv file and it works fine. Unfortunately csvReader seems
very convenient but it is no speed daemon. To my dismay it was
much slower (about 4x) than a simple approach I am using in
Python, which is essentially equivalent to
chomp(line).split(','). I guess I'll have to keep studying and
learning. Thx again.
Re: DIP76: Autodecode Should Not Throw
On 4/7/2015 1:19 AM, Dicebot wrote: I have doubts about it similar to Vladimir. Main problem is that I have no idea what actually happens if replacement characters appear in some unicode text my program processes. It's much like floating point NaN values, which are 'sticky'. So far I have that calming feeling that if something goes wrong in this regard, exception will slap me right into my face. With UTF strings, if you care about invalid UTF (a surprisingly large amount of operations done on strings simply don't care about invalid UTF) the validation can be done as a separate step. Then, the program logic is divided into operating on validated and unvalidated data. Also it is worrying to see so much effort put into `nothrow` in language which endorses exceptions as its main error reporting mechanism. There is definitely a tug of war going on there. Exceptions are great, except they aren't free. What I've tried to do is design things so that erroneous input is not possible - that all possible input has straightforward output. In other words, try to define the problem out of existence. Then there are no errors.
Re: getting started with std.csv
On Tuesday, 7 April 2015 at 09:44:11 UTC, gjansen wrote:
Many thanks for the feedback yazd! I've tested the approach
with a large csv file and it works fine. Unfortunately
csvReader seems very convenient but it is no speed daemon. To
my dismay it was much slower (about 4x) than a simple approach
I am using in Python, which is essentially equivalent to
chomp(line).split(','). I guess I'll have to keep studying and
learning. Thx again.
What compiler are you using? What compilation flags?
Re: Why I'm Excited about D
On 2015-04-07 10:33, John Colvin wrote: (parentheses are optional for all function calls), Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well. -- /Jacob Carlborg
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 07:50:40 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 April 2015 at 07:42:02 UTC, w0rp wrote:
Maybe autodecoding could throw an Error (No 'new' allowed)
when debug mode is on, and use replacement characters in
release mode. I haven't thought it through, but that's an idea.
No no no, terrible idea. This means your program will pass your
test suite in debug mode (which, of course, is never going to
test behavior with bad UTF in all the relevant places), but
silently corrupt real-world data in release mode. Errors and
asserts are for logic errors, not for validating user input!
I'd say that invalid UTF8 in `string`s _is_ a logic error,
because these are defined to be valid UTF8. If they aren't,
someone didn't correctly validate their inputs.
Unfortunately, not even the runtime cares about UTF correctness:
void main(string[] args) {
import std.utf;
args[1].validate; // throws
}
# ./testutf8 `echo 'äöü' | recode utf8..latin1`
Re: Why I'm Excited about D
On 04/07/2015 08:28 AM, Jacob Carlborg wrote: vibe.d has a template system. It's based on Jade, which seems to be based on Haml. There is also a runtime template system, http://code.dlang.org/packages/mustache-d. See https://github.com/D-Programming-GDC/gdcproject for an example.
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 09:21:52 UTC, Walter Bright wrote: On 4/7/2015 2:10 AM, Vladimir Panteleev wrote: On Tuesday, 7 April 2015 at 09:04:09 UTC, Walter Bright wrote: On 4/7/2015 1:19 AM, Dicebot wrote: I have doubts about it similar to Vladimir. Main problem is that I have no idea what actually happens if replacement characters appear in some unicode text my program processes. It's much like floating point NaN values, which are 'sticky'. Yes, but std.conv doesn't return NaN if you try to convert banana to a double. Maybe it should :-) There was a time when operations on NaNs where painfully slow. Also, since NaNs tend to spread, once a NaN appears, there usual is not much of a result left. Debugging used to be painfully hard if NaNs are enabled. We used to rely on floating point exceptions instead. This might or might not be relevant.
[Issue 14421] New: Variadic args array force on heap
https://issues.dlang.org/show_bug.cgi?id=14421
Issue ID: 14421
Summary: Variadic args array force on heap
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
char[] foo(char[] args ...)
{
return args;
}
This is obviously wrong code, as args can be allocated on the stack. However,
it might not be.
Currently the only way out is to go `return args.dup` but that can lead to
allocating twice.
--
[DerelictOrg] Forum down ?
Hi, I think I have a bug report for DerelictGL3, but cannot find the related Forum ( http://dblog.aldacron.net/forum/index.php ), is it still in the process of being moved ? Regards, ParticlePeter
Re: [DerelictOrg] Forum down ?
On Tuesday, 7 April 2015 at 10:48:38 UTC, ParticlePeter wrote: Hi, I think I have a bug report for DerelictGL3, but cannot find the related Forum ( http://dblog.aldacron.net/forum/index.php ), is it still in the process of being moved ? Regards, ParticlePeter Post it there: https://github.com/DerelictOrg/DerelictGL3/issues
Re: getting started with std.csv
dmd -O (2.066.1) and gdc -O3 (4.9.2)
But... as I tried to convey, I was comparing apples to oranges. I
have now rewritten the D test simply using split(',') instead of
csvReader, to be more similar to the python test, and it runs
about 2x faster in D with dmd and about 4x faster with gdc
compared to Python 3.4.3. :-)
On Tuesday, 7 April 2015 at 10:47:14 UTC, John Colvin wrote:
On Tuesday, 7 April 2015 at 09:44:11 UTC, gjansen wrote:
Many thanks for the feedback yazd! I've tested the approach
with a large csv file and it works fine. Unfortunately
csvReader seems very convenient but it is no speed daemon. To
my dismay it was much slower (about 4x) than a simple approach
I am using in Python, which is essentially equivalent to
chomp(line).split(','). I guess I'll have to keep studying and
learning. Thx again.
What compiler are you using? What compilation flags?
Re: json parsing performance
On 04/06/2015 11:09 PM, Brad Anderson wrote: We actually have a JSON parser meant to replace std.json that should be very high performance. You can try it out now using dub: http://code.dlang.org/packages/std_data_json It also includes a stream parser for the highest performance requirements. http://s-ludwig.github.io/std_data_json/stdx/data/json/parser/parse_json_stream.html
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 03:17:26 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP76 The DIP lists the benefits but does not mention any cons. A con that I can see is that it is violating the 'fail fast' principle. By silently replacing data the developer will be presented with a probably-hard-to-debug problem later down the application lifecyle (probably in an unrelated area), wasting developer time.
Re: Standardpaths library
On Monday, 6 April 2015 at 21:40:28 UTC, Marco Leise wrote: So if some configuration is portable and you want to create something really fine grained you could offer that directory as an alternative roaming config dir (returning null or ~/.config on Linux). Though it's unusual for an average programmer to figure out the correct usage of roaming profiles :)
[Issue 14422] std.process: Pipes do not append to files on Win64
https://issues.dlang.org/show_bug.cgi?id=14422 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/3160 --
Re: Reggae v0.0.5 super alpha: A build system in D
On Tuesday, 7 April 2015 at 08:28:08 UTC, Dicebot wrote: And I have never been speaking about normal WPO, only about one specific to D semantics. AFAIK, hypothetical D-specific optimizations were never implemented (like elision of pure calls and optimization of immutable data). But they work on signature level, so they shouldn't be affected by separate compilation in any way. This sentence probably means something but I were not able to figure it out even after re-reading it several times. coding style which relies on attribute hell, what kind of weird beast that is? I suppose your coding style can be an example, you wouldn't be interested in attribute hell otherwise.
Future of contract-based programming in D
The D features which interest me the most are those supporting contract-based programming. I want to experiment with that and I know no other production ready language which has this level of support, except the original gangsta Eiffel but the only supported Eiffel compiler is proprietary and expensive. Thing is, while contract-based programming was promoted by Walter Bright in the early days it seems to get no attention nowadays. There are critical bugs in it e.g. contracts do not work correctly with interfaces. Also the compiler does not utilize the contracts for advanced static analysis and optimizations which are enabled by them. But the most worrying thing is that Andrei Alexandrescu obviously does not like contract-based programming at all. I read a thread here where he wrote you should get rid of those in/out contracts and replace them with assert()s in the function body. Now we all know that the vultures are already circling above Mr. Bright and after his departure Alexandrescu will be D's Ceausescu (horrible pun intended) and that really makes me worry about the future of contract-based programming in D. But I am not following D's development that closely it is just one of many interesting languages I casually watch / consider for experiments. So I would like to hear a more inside view of the current and future state of contract-based programming in D.
Berlin D Meetup April 2015
Hi All, The next Berlin D Meetup will be happening as always on the third Friday of the month, April the 17th at 19:30. The venue will be Berlin Co-Op (http://co-up.de/) on the 3rd floor. Mihails Strasuns will be doing a presentation titled Highway to D2. 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: Future of contract-based programming in D
On Tuesday, 7 April 2015 at 13:11:01 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote: I know no other production ready language which has this level of support, except the original gangsta Eiffel but the only Ada2012? Some languages use require and ensure or a similar notion in the body of a function for pre/post conditions. I have no idea where D contracts go, but the current in/out/body syntax is too noisy to be worth using IMO. Contracts in C# are implemented using attributes: https://msdn.microsoft.com/en-us/library/dd264808%28v=vs.110%29.aspx?f=255MSPPError=-2147217396 Personally, I think that the D contracts looks nicer, but they are not so versatile like an attribute solution.
Re: Future of contract-based programming in D
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote: The D features which interest me the most are those supporting contract-based programming. I want to experiment with that and I know no other production ready language which has this level of support, except the original gangsta Eiffel but the only supported Eiffel compiler is proprietary and expensive. EiffelStudio does have an open source license for non commercial purposes. You are also forgetting Ada 2012, Spark, .NET, Clojure, Raket among many others. C++17 also has a few proposals for contract programming (N4160, N1962, N4075, N4110). -- Paulo
Re: UFCS and overloading
EDIT: mis-formatted previous snippet
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter with
this lambda function
.map!(s = s.to!double) // Map the strings to doubles
.array // Sorting needs random access
.sort!((a, b) = a b) // Another lambda
.take(10) // Applyable to any range
.writeln;
}
[Issue 14420] partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
(In reply to Martin Nowak from comment #0)
void foo(string op:+, T)(ref T val, T mod)
void foo(string op, T, V1)(ref T val, V1 mod)
---
Partial specialization order is defined only when two templates have same
template parameters except for TemplateTypeParameterSpecialization. For
example:
template A(string op, T) {} // A1
template A(string op:+, T) {} // A2 is a specialized version of A1
But in the OP code, Two 'foo's have different number of parameters, so neither
of them is not a specialized version of one another.
Therefore the ambiguous error is correct result.
--
Re: DIP76: Autodecode Should Not Throw
On Tue, Apr 07, 2015 at 02:21:50AM -0700, Walter Bright via Digitalmars-d wrote: On 4/7/2015 2:10 AM, Vladimir Panteleev wrote: [...] I think the correct solution to that is to kill auto-decoding :) Then all decoding is explicit, and since it is explicit, it is trivial to allow specifying the desired behavior upon encountering invalid UTF-8. I agree autodecoding is a mistake, but we're stuck with it. How so? There *are* possible options we can consider to migrate away from autodecoding. AFAICT the real roadblock here is that some people strongly disagree with this, so it's more a community barrier than a technical one. T -- Unix is my IDE. -- Justin Whear
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #2 from Sönke Ludwig slud...@outerproduct.org --- Do you know if that been a concious decision or is it just an artefact of the implementation? I don't think it makes much sense as it is. Personally I always use /** */ style comments, but anyone using /// is going to have issues with it. --
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 01:28:03 UTC, Rikki Cattermole wrote: I'm watching your progress closely. I think we are ready to get D properly on micro controllers and you are really testing, exploring it even. Johannes made some very important additions for regarding this. It might already be possible for me to write a complete startup file entirely in D, because of these additions. I would be very surprised in the next year or so, if you don't make atleast one breakthrough! I'm looking forward to the first one; it's just around the corner: The file startup.d. :) -I'll be sure to create a thread about it, when it's complete (it's at something like 98% already). One thing I'd like to add to why I like D, is that it feels limitless. I don't feel like I'm restricted by the language or the compiler; in other words, I feel a lot of 'freedom'.
Re: UFCS and overloading
On Monday, 6 April 2015 at 18:00:46 UTC, Szymon Gatner wrote:
Why is that? The use case is to provide a set of convenience
extension methods to a basic interface. Say, given:
This is not the only use case, another (maybe even more common)
use is to allow pipeline programming.
Example from one of Andrei's talks (
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D ):
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter with
this lambda function
.map!(s = s.to!double) // Map
the strings to doubles
.array
// Sorting needs random access
.sort!((a, b) = a b) //
Another lambda
.take(10)
// Applyable to any range
.writeln;
}
With such constructs, it is important to be able to call a method
and not the function as there are ways to explicitely call the
function but not the method (AFAIK). As this style of programming
is actively encouraged by both Andrei and Walter, I think the
design is coherent.
Re: Future of contract-based programming in D
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote: I know no other production ready language which has this level of support, except the original gangsta Eiffel but the only Ada2012? Some languages use require and ensure or a similar notion in the body of a function for pre/post conditions. I have no idea where D contracts go, but the current in/out/body syntax is too noisy to be worth using IMO.
Re: getting started with std.csv
On Tuesday, 7 April 2015 at 11:36:54 UTC, gjansen wrote:
dmd -O (2.066.1) and gdc -O3 (4.9.2)
But... as I tried to convey, I was comparing apples to oranges.
I have now rewritten the D test simply using split(',') instead
of csvReader, to be more similar to the python test, and it
runs about 2x faster in D with dmd and about 4x faster with gdc
compared to Python 3.4.3. :-)
On Tuesday, 7 April 2015 at 10:47:14 UTC, John Colvin wrote:
On Tuesday, 7 April 2015 at 09:44:11 UTC, gjansen wrote:
Many thanks for the feedback yazd! I've tested the approach
with a large csv file and it works fine. Unfortunately
csvReader seems very convenient but it is no speed daemon. To
my dismay it was much slower (about 4x) than a simple
approach I am using in Python, which is essentially
equivalent to chomp(line).split(','). I guess I'll have to
keep studying and learning. Thx again.
What compiler are you using? What compilation flags?
also consider:
-inline and -release
for dmd and
-frelease
for gdc
With gdc, if you are building for a specific cpu family (e.g.
broadwell) -march= can provide improvements. -march=native
chooses the same as the host machine.
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413
--- Comment #1 from Kenji Hara k.hara...@gmail.com ---
(In reply to Sönke Ludwig from comment #0)
---
/// This function is here to aid in making your
/// software do cool stuff.
void foo() {}
---
It's equivalent with:
---
/**
This function is here to aid in making your
software do cool stuff.
*/
void bar() {}
---
DMD lexer concatenates the continuous ddoc line comments like paragraphs. The
blank line is inserted to separate two one-liner paragraphs.
--
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 11:16:56 UTC, Jacob Carlborg wrote: On 2015-04-07 10:33, John Colvin wrote: (parentheses are optional for all function calls), Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well. Sorry, yes my mistake
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
@property isn't really about parentheses-less calls
(parentheses are optional for all function calls), it's more
for this sort of thing:
[snip]
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
This is *really* cool and very useful on microcontrollers and is
superior to C's bit-fields.
Imagine that your microcontroller has 24 GPIO pins.
Such pins are usually grouped in 'ports', for instance Port A and
Port B.
Each port could for instance support up to 32 pins: PA0 ... PA31
and PB0 ... PB31.
But there's a problem here: Our microcontroller has only 24 pins,
and our microcontroller vendor chose to make the following pins
available to us:
PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28
PB0 ... PB3, PB8 ... PB12
Every developer will think this is annoying. We want to write a
byte to a port, but it has to be converted first.
If just incrementing a value, one could do as follows:
PortB = (PortB | 0x00f0) + 1;
... oposite for decrementing:
PortB = (PortB 0xff0f) - 1;
But the @property can make all this transparent, so our sources
become very easy to overview and understand.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 14:20:58 UTC, Jens Bauer wrote:
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
@property isn't really about parentheses-less calls
(parentheses are optional for all function calls), it's more
for this sort of thing:
[snip]
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
This is *really* cool and very useful on microcontrollers and
is superior to C's bit-fields.
Imagine that your microcontroller has 24 GPIO pins.
Such pins are usually grouped in 'ports', for instance Port A
and Port B.
Each port could for instance support up to 32 pins: PA0 ...
PA31 and PB0 ... PB31.
But there's a problem here: Our microcontroller has only 24
pins, and our microcontroller vendor chose to make the
following pins available to us:
PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28
PB0 ... PB3, PB8 ... PB12
Every developer will think this is annoying. We want to write a
byte to a port, but it has to be converted first.
If just incrementing a value, one could do as follows:
PortB = (PortB | 0x00f0) + 1;
... oposite for decrementing:
PortB = (PortB 0xff0f) - 1;
But the @property can make all this transparent, so our sources
become very easy to overview and understand.
and, for convenience there is
http://dlang.org/phobos/std_bitmanip.html#.bitfields
Re: DIP76: Autodecode Should Not Throw
On Tue, Apr 07, 2015 at 09:10:32AM +, Vladimir Panteleev via Digitalmars-d wrote: [...] I think the correct solution to that is to kill auto-decoding :) Then all decoding is explicit, and since it is explicit, it is trivial to allow specifying the desired behavior upon encountering invalid UTF-8. I used to be pro-autodecoding... nowadays, I'm starting to lean towards killing it. This is another nail in the coffin. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Implementing cent/ucent...
Hi all! I started to work on cent/ucent support in LDC (and possible in upstream DMD). Here is the current state: 1) The pull request https://github.com/ldc-developers/ldc/pull/891/files implements cent/ucent based on the upcoming major LDC release (branch merge-2.067). It is usable but relies on GCC because it uses the __int128 data type. My next step is to implement a synthetic int128_t type to enable support on all platforms. Up to now I tested only on Linux/x86_64. 2) I already submitted some pull request for DMD, Druntime and Phobos to enable cent/ucent support. How to continue? As soon as I got it working on all compiler environment I like to create an upstream pull request. (May take some time because I am now busy with other tasks.) But: I am not going to extend the DMD backend! This has 2 consequences. First, we need to decide how to integrate the code. (Do we want to clutter the code with #if WANT_CENT as I currently do? Should we wait for DDMD?) Second, someone needs to work on the DMD backend if DMD should support cent/ucent, too. If you like to help: - clone test - Druntime/Phobos should support cent/ucent. I already updated/created some modules but more work is needed here - add support to the DMD backend Regards, Kai
Re: D1: Out of memory problems
On Tuesday, 7 April 2015 at 09:03:19 UTC, Kagamin wrote: For example if you slice the original string, it will be preserved in memory. That's why parsers keep parsed substrings by duplicating them - this can result in smaller memory footprint. H... Will you be able to give me an example of what is bad and then fix that bad to a good? This may be my problem...
Re: D1: Out of memory problems
On Tuesday, 7 April 2015 at 08:58:31 UTC, Kagamin wrote:
Depends on how you fill aTUs.
Ok, I will bite... ;-)
I have the wText string which could be 20 mgs or so, I start
finding pieces of data like this,
wText = wText[std.string.find(wText,/ut) + 5 .. $];
so, everything before /ut, including it, will be thrown out,
correct? So, I continue like this, until I find a piece of the
string that I want, and then, I fill the aTUs, like this,
aTUs = AddToTrackerRepeat(aTUs, source, fn, 1, target);
where:
source is a part of the string wanted
fn is the file name that the string was found
1 is a count
target is the other set of string wanted
And these are the other pieces missing:
TUCount [char[]] AddToTrackerRepeat(TUCount[char[]] T, char[]
tu, char[] f, int add, char[] target)
{
// target = target
// f = filename
// tu = translation unit
// add = amount to be added
if ((tu in T) == null)
{
T[tu] = new TUCount();
T[tu].Count = 0;
T[tu].File[f] = 0;
}
T[tu].Count += add;
T[tu].File[f] += add;
T[tu].Target[f ~ \t ~ std.string.toString(T[tu].File[f]) ]
= target;
return T;
}
class TUCount
{
int[char[]] File;
char[][char[]] Target;
int Count;
}
Re: Shall I use immutable or const while passing parameters to functions
On Tuesday, 7 April 2015 at 15:11:39 UTC, tcak wrote:
I have data in memory, and I want a function to take a part of
data for processing only. It will only read and won't change.
char[] importantData;
With Immutable,
void dataProcessor( string giveMeAllYourData ){}
dataProcessor( cast( immutable )( importantData[5 .. 14] ) );
With Const,
void dataProcessor( in char[] giveMeAllYourData ){}
dataProcessor( cast( const )( importantData[5 .. 14] ) );
(Code with const wasn't tested)
Which one is better? I didn't understand it very well in
http://dlang.org/const3.html this page.
const means I will not modify this via this variable and
immutable means no one will modify this from anywhere
Don't cast to immutable unless you are sure what you are doing.
Immutable is a strong guarantee, it's easy to break it by
accident if you're casting things. The safest way of getting an
immutable array is with the .idup property.
You don't have to cast to const most of the time. mutable is
implicitly convertible to const:
void foo(const int[] a){}
void main()
{
int[] a = [1,2,3,4];
foo(a);
foo(a[0..2]);
}
Also, see https://archive.org/details/dconf2013-day01-talk02
In general, immutable in an API allows greater freedom for the
implementation, const allows for greater freedom/convenience for
the API user. Which is more important depends on your exact
problem.
Re: Why I'm Excited about D
On 4/6/15 4:51 PM, Adam Hawkins wrote: Hello everyone, this is my first post on the forum. I've been investigating the language for the past few weeks. I was able to complete my first useful program thanks to very helpful people in #d on IRC . The experience made me very interested in the language and improving the community around it. [snip] http://www.reddit.com/r/programming/comments/31rdp1/excited_about_d/ https://twitter.com/D_Programming/status/585472101349462020 https://www.facebook.com/dlang.org/posts/1046466315367049 Share away! Andrei
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #15 from Iain Buclaw ibuc...@gdcproject.org --- (In reply to yebblies from comment #14) (In reply to Martin Nowak from comment #9) If you really think we should fix this, then a time limit for CTFE execution might be feasible. An iteration limit would be better than a time limit, because it will not be dependent on environmental conditions. This would need to be configurable from the command line etc. The compilation would terminate with a nice stack trace, making it easy to debug. So then you just need to decide what is a suitable iteration limit, short.max? ushort.max? --
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #16 from Jens Bauer jens-bugzi...@gpio.dk --- (In reply to Iain Buclaw from comment #15) So then you just need to decide what is a suitable iteration limit, short.max? ushort.max? If it's just to make sure that we're not stuck forever, the size of the returned argument might be suitable. I believe this is very much a matter of opinion, though. But consider this. Combining with my previous idea of checking the exit-conditions. All sources for the exit-conditions should be saved (the stack would be fine): All minimum values for the exit conditions All maximum values for the exit conditions A minimumHit counter A maximumHit counter Each time the same minimum for all exit conditions are hit, then the minimumHit counter is incremented. If a new minimum is found, the minimumHit counter is cleared. Same thing for the maximumHit counter. Now if any of those two counters reach a value above - say 10, then we'll exit the loop. As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely maximum limit'. This is just an idea, but I believe it would be fairly good at catching more than 99% of the lockups. --
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 16:39:39 UTC, Jens Bauer wrote: :C - :D Even better (includes the meaning of '=' in place of 'when'): =C - =D
alias this of non-public member
Hi!
Excuse me if this is obvious, but I can't recall coming across
anything similar and a quick search returns nothing relevant:
struct Foo {
}
struct FooWrapper {
alias x_ this;
private Foo* x_; // doesn't work, as x_ is private
}
Basically, I want x_ to never be visible, except through the
alias this mechanism, at which point it should instead be seen
as public.
Assuming something like this is not already possible in a clean
way, I would like to suggest a tiny(I think) addition to the
language:
struct FooWrapper {
public alias x_ this; // overrides the visibility through the
alias;
private Foo* x_;
}
While I think this would be useful for the language, the reason I
want such a wrapper, is because I want to give opIndex, toString,
to a pointer, or, in fact just value semantics, while keeping the
rest of the interface through the pointer.
I thought about using a class instead of a struct pointer, but I
am not sure about the memory layout for classes, nor about the
efficiency of overriding Object's methods, so I didn't want to
risk making it any less efficient. If someone could shed some
light about D's class memory layout and general performance
differences to a simple struct (or a C++ class for that matter),
that would also be great. In general, more information about
these sort of things would be great for us also-C++ programmers.
:)
Re: Reggae v0.0.5 super alpha: A build system in D
On Tuesday, 7 April 2015 at 08:25:02 UTC, Dicebot wrote: See, the problem with this approach is that you can trivially get out of 1GB of memory with DMD even when compiling single module, all you need is to do enough compile-time magic. Separate compilation here delays the issue but does not actually solve it. Yeah, absolutely agree. But at the moment separate compilation is the most forgiving one. Like, if it doesn't work - anything else won't work either. And given that personally I don't recognize the (possibly) increased compilation time as an issue, it's the solution that works for me. If any effort is to be put into supporting this scenario (on-server compilation), it is better to be put in reducing actual memory hog of compiler, not supporting another workaround. Agreed, too. The whole forget about frees approach sounds a little too controversial to me. Especially, after I have faced the dark side of it. So, I'm all for improving in that regard. But it seems like it's not recognized as a (high-priority) issue at the moment. So, we (the users) have to live with that. Also you can still achieve the similar profile by splitting your project in small enough static libraries, so it is not completely out of question. As I described, my project was just a couple of files. Building vibe.d was the actual problem. I don't think it is feasible to expect that a user of a library will start splitting it into small enough libraries, when faced with this problem. A more structured approach is needed.
Re: Shall I use immutable or const while passing parameters to functions
If you're just looking at the data, use const. immutable becomes more important if it is shared across threads or stored for later. Functions that accept const will work with almost anything you pass to it.
Re: UFCS and overloading
On Tuesday, 7 April 2015 at 14:46:52 UTC, cym13 wrote:
EDIT: mis-formatted previous snippet
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter
with this lambda function
.map!(s = s.to!double) // Map the strings to doubles
.array // Sorting needs random access
.sort!((a, b) = a b) // Another lambda
.take(10) // Applyable to any range
.writeln;
}
Yup, I get that, still does not explain why UFCS can't extend
overload set. Especially if there would be no conflict wrt to
overload of method vs free function.
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #3 from Kenji Hara k.hara...@gmail.com --- (In reply to Sönke Ludwig from comment #2) Do you know if that been a concious decision or is it just an artefact of the implementation? I don't think it makes much sense as it is. Personally I always use /** */ style comments, but anyone using /// is going to have issues with it. At least http://dlang.org/ddoc says nothing about the case. It would be an artifact of the current dmd implementation, if there's no discussion in the old D forum (including digitalmars.d). But I think the concatenation like paragraphs is not bad. --
Shall I use immutable or const while passing parameters to functions
I have data in memory, and I want a function to take a part of
data for processing only. It will only read and won't change.
char[] importantData;
With Immutable,
void dataProcessor( string giveMeAllYourData ){}
dataProcessor( cast( immutable )( importantData[5 .. 14] ) );
With Const,
void dataProcessor( in char[] giveMeAllYourData ){}
dataProcessor( cast( const )( importantData[5 .. 14] ) );
(Code with const wasn't tested)
Which one is better? I didn't understand it very well in
http://dlang.org/const3.html this page.
DMD AST Docs/Reference or Dumper?
I'm trying to add some compile-time function generation to dmd, but wasn't sure exactly how to click all the little legos together. Is there any documentation or reference for the DMD AST? Or maybe some examples somewhere of what an AST may look like for a given function? As a last resort, I was about to start converting the ToJsonVisitor to a ToAstDumpVisitor, but as you may have guessed, I am not particularly excited about this venture. Does source code exist anywhere for this already? Thanks
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #4 from Sönke Ludwig slud...@outerproduct.org --- Just that concatenation as paragraphs instead of concatenation as lines precludes the use of this documentation style: /// This is the summary, possibly going /// over multiple lines. /// /// A large paragraph /// of text also /// gets split /// /// --- /// as well as code blocks behave awkwardly /// --- But it seems like maybe not many have tried to use this style in the past. --
Wanted: Review manager for std.data.json
Anyone up to this? The issues of the previous discussion [1] have all been addressed now more or less, so the package is ready for a more thorough review. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ [1]: http://forum.dlang.org/thread/lt5s76$is$1...@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 16:29:40 UTC, Walter Bright wrote: I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); should be: assert(Adam Hawkins == myName()); -It already is. :) By the way; the reason to switch from C to D can be put *very* simple: :C - :D ... or if you prefer the longer version: :-C - :-D
Re: Shall I use immutable or const while passing parameters to functions
tcak:
void dataProcessor( string giveMeAllYourData ){}
dataProcessor( cast( immutable )( importantData[5 .. 14] ) );
With Const,
void dataProcessor( in char[] giveMeAllYourData ){}
dataProcessor( cast( const )( importantData[5 .. 14] ) );
Don't cast to const/immutable unless you have a good reason to do
it, and you know what you are doing (and most times you don't
know it).
More generally, minimize the number of cast() in your D programs.
You can use a search to count how many cast( there are in your
whole D codebase, and you can try to reduce that number.
Bye,
bearophile
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 06:28:49 UTC, Jacob Carlborg wrote: vibe.d has a template system. It's based on Jade, which seems to be based on Haml. Aye, though it is compile time rather than runtime which hurts the edit/run cycle - you have to recompile, redeploy (maybe), and restart just to see a quick text change. In my web projects. I used compile time stuff sometimes too, but the runtime loading ultimately won out for the ease of editing by me and by the frontend team - they can edit html too without needing to worry about rerunning a compiler.
Re: Why I'm Excited about D
On 4/6/2015 4:51 PM, Adam Hawkins wrote: Hello everyone, this is my first post on the forum. I've been investigating the language for the past few weeks. I was able to complete my first useful program thanks to very helpful people in #d on IRC . The experience made me very interested in the language and improving the community around it. I'm primarily Ruby developer (been so about the last 7-8 years) doing web stuff with significant JavaScript work as well. I wrote a blog post on why I'm excited about D. You can read it here: http://hawkins.io/2015/04/excited-about-d/. I've been reading the forums here so I can see that there is a focus on improving the marketing for the language and growing the community. I see most of the effort is geared towards C++ programmers, but have you considered looking at us dynamic languages folk? I see a big upside for us. Moving from Ruby to D (my case) gives me power performance. I still have OOP techniques but I still have functional things like closures and all that good stuff. Only trade off in the Ruby case is metaprogramming. All in all I think there is a significant value promise for those of us doing backend services for folks like me. Regardless, I figured it might be interesting to hear about some experience coming to the language from a different perspective. Cheers! This is a nice article, thanks! I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); should be: assert(Adam Hawkins == myName());
Re: Why I'm Excited about D
On 2015-04-07 18:06, Adam D. Ruppe wrote: Aye, though it is compile time rather than runtime which hurts the edit/run cycle - you have to recompile, redeploy (maybe), and restart just to see a quick text change. Oh, right, that was what he meant with runtime :) -- /Jacob Carlborg
Re: DIP76: Autodecode Should Not Throw
On 4/7/2015 5:04 AM, Abdulhaq wrote: On Tuesday, 7 April 2015 at 03:17:26 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP76 The DIP lists the benefits but does not mention any cons. A con that I can see is that it is violating the 'fail fast' principle. By silently replacing data the developer will be presented with a probably-hard-to-debug problem later down the application lifecyle (probably in an unrelated area), wasting developer time. On the other hand, if there's any place where people demand the highest performance, it's string processing.
Re: dsource.org moved
I haven't been active on the newsgroups lately, so lose track of what's going on. Has anything happened? Just now I tried to commit to the bindings project on dsource, but got an error POST request on '/projects/bindings/!svn/me' failed: 500 Internal Server Error Has it been doing this for a long time? Or is it just a temporary problem? Bindings is certainly a project that needs to be kept alive, whether here or somewhere else, but either way it needs to be possible to commit to it. There's already a mirror of bindings on GitHub. https://github.com/CS-svnmirror/dsource-bindings I don't know if it would be reasonable to convert this into the live bindings repository. The name 'CS-svnmirror/dsource-bindings' implies that it's a mirror of the dsource repo - can the name be changed? Or would we need to create a new repo on GitHub to carry on where the dsource one left off? Moreover, I haven't taken the time to get to know GitHub. I've just realised that at least it has a wiki facility. Is it structured in basically the same way as the dsource wiki? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #17 from Jens Bauer jens-bugzi...@gpio.dk --- (In reply to Jens Bauer from comment #16) As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely maximum limit'. ... and if the 32-bit counter wraps, then an error message should be given to the user, for instance: Error: Please write better code. ;) --
Re: [DerelictOrg] Forum down ?
Done On Tuesday, 7 April 2015 at 10:50:35 UTC, Namespace wrote: On Tuesday, 7 April 2015 at 10:48:38 UTC, ParticlePeter wrote: Hi, I think I have a bug report for DerelictGL3, but cannot find the related Forum ( http://dblog.aldacron.net/forum/index.php ), is it still in the process of being moved ? Regards, ParticlePeter Post it there: https://github.com/DerelictOrg/DerelictGL3/issues
Re: Why I'm Excited about D
On 4/7/2015 9:28 AM, Walter Bright wrote: I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); er, the example is: assert(Adam Hawkins = myName()); should be: assert(Adam Hawkins == myName());
Re: Questions about phobos additions mentioned in 2015H1 vision document
On Monday, 6 April 2015 at 03:19:03 UTC, Rikki Cattermole wrote: On that note, anyone willing to help create and ODBC host via Derelict or will I be doing something like that? I don't understand this sentence. :/
Re: Questions about phobos additions mentioned in 2015H1 vision document
Andrei, if vibed will include in DMD distribution, would it's mean that common libs (like json) will be merged with DMD? I think it would very rational step.
Re: DIP76: Autodecode Should Not Throw
On Tuesday, 7 April 2015 at 09:21:52 UTC, Walter Bright wrote: On 4/7/2015 2:10 AM, Vladimir Panteleev wrote: I think the correct solution to that is to kill auto-decoding :) Then all decoding is explicit, and since it is explicit, it is trivial to allow specifying the desired behavior upon encountering invalid UTF-8. I agree autodecoding is a mistake, but we're stuck with it. I don't think we are stuck with it. I think we can change it. I think a lot of the automatic decoding happens inside of Phobos, while people care mostly about the boundaries of the API. If we do get rid of it, then as Vladimir says, you can opt in to whether or not you want a non-throwing conversion, or a throwing one. I was going to write about how the auto decoding doesn't solve the problem of comparing strings, given that you need to look at ranges of characters, subject to normalisation, unless you're dealing with just ASCII. I think all of that has been said to death, though. I think it's possible for us to get rid of automatic decoding.
Re: Fun project - faster associative array algorithm
On Tuesday, 7 April 2015 at 17:25:00 UTC, Walter Bright wrote: The current D associative array algorithm https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d uses an array of buckets with a linked list attached to the buckets to resolve collisions. Linked lists are perhaps the worst (i.e. slowest) data structure possible on modern CPUs with memory caches. A possible cache-friendly replacement would be an array of buckets with local probing to resolve collisions. D programs are often heavily dependent on associative arrays, so this could be a big win for us. And it's a fun project, too. Any takers? Interestingly, https://github.com/D-Programming-Language/dmd/blob/master/src/root/stringtable.c uses quadratic probing instead of linked lists, but this is not cache friendly, either. I have already been experimenting with this myself actually. My hashmap now uses a bucket array with quadratic probing. I was just following Martin Nowak's advice. My code for it is here. https://github.com/w0rp/dstruct/blob/master/source/dstruct/map.d I have a benchmark program available in my repository for testing it against the druntime version. It doesn't amaze me at the moment, as it's slightly faster for integers, and slightly slower for strings at the moment. I would appreciate any advice on it. I'm sure someone will look at my code and say, Noo! Don't do that!
Re: Why I'm Excited about D
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
Re: Release D 2.067.0
On 03/25/2015 10:38 PM, weaselcat wrote: Anyone know if there's been any comparisons of different heapSizeFactor values? Primarly, compared to the default 2, 1.5 or 1.618. has anyone working on the GC actually done any comparisons of the new options? Yes, we compared different values and 2 was a good compromise. Higher values will result in less collections but use more memory, which lower values will trigger more collections (slowing down your program) while requiring less memory.
