Re: pfft 0.1
jerro: I'm announcing the release of pfft, a fast FFT written in D. Everything looks nice. Are you using "in", pure/nothrow/immutable/const enough? Is it worth changing the Phobos API to something similar to this API? Bye, bearophile
Re: pfft 0.1
jerro: Are all your benchmarks done on a 64 bit system? I think what Phobos does in this case is wrong. The fact that one class works on all floating point types results in very poor precision when the data consists of doubles or reals. I guess that precomputed tables are stored as floats. You could only fix that by saving them as reals, but that would probably hurt performance quite a lot. The fact that one instance can be used for multiple sizes would be a problem if we wanted to change an implementation since not all FFT implementation can use one precomputed table for different data sizes. If you are right and this is a problem, are Andrei and others accepting to change this little part of Phobos? If the answer is positive, are you interested in creating a GIT patch that changes that? Bye, bearophile
Re: pfft 0.1
jerro: I haven't talked to Andrei or others about changing it, but I am willing to write a patch that changes the API, if it would be decided that would be the best thing to do. Given your willingness to work, and the days since you wrote that, maybe we have to write this little proposal again in the main D newsgroup. Bye, bearophile
Re: Pull freeze
Jacob Carlborg: You completely missed the point. The point was not which VCS we use, it was how we're using it. Yeah, Walter has missed the point, but you aren't helping much. Why don't you give links that explain what a Git workflow is, in general? Or you explain the situation yourself. This is not entry-level, so something simpler is probably needed: http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf Bye, bearophile
Re: dmd 1.075 and 2.060 release
Walter Bright: Another big pile of bug fixes. More contributors than ever! And there is the first step of this change too: http://d.puremagic.com/issues/show_bug.cgi?id=6652 Bye, bearophile
Re: 2.060 on reddit
Caligo: When are allocators going to be ready? Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking changes, so even small API improvements of Phobos stuff written last year are refused. See as example: http://d.puremagic.com/issues/show_bug.cgi?id=8467 So Phobos stuff once created is almost set in stone. This means that in practice the Phobos APIs should be perfect on the first try. So better to not rush things, and do things right. Bye, bearophile
Re: gfm, kitchen-sink multimedia library
ponce:
http://github.com/p0nce/gfm
Some of those things are at home in Phobos.
Maybe there are ways to improve this ucent mul (avoiding magic
constants, using foreach, using size_t, maybe with asm too and
__ctfe):
else static if (op == "*")
{
uint[4] a = toParts();
uint[4] b = y.toParts();
this = 0;
for(size_t i = 0; i < 4; ++i)
for(size_t j = 0; j < 4 - i; ++j)
this += self(cast(ulong)(a[i]) * b[j]) << (32
* (i + j));
}
Bye,
bearophile
Re: NaNs Just Don't Get No Respect
Walter Bright: http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723 You have omitted the detail that double.nan !is double.init. On a more general note, I know many professionals in other fields that never write small articles about what they are doing. So is it normal just for programmers to write (small) articles like this? I write them, and other programmers I know write similar things. Maybe to program you need (among other things) active linguistic centers in the brain :-) Bye, bearophile
Re: NaNs Just Don't Get No Respect
F i L: Why would it matter what is "normal"? It matters to me because I am curious. Why aren't my friends that work or study chemistry writing free small online articles like my programmer&CS friends do? Maybe it's systematic differences in their brain brain? Or it's just more easy to talk about coding compared to botany and chemistry and making engines? Or maybe programmers don't know what they are doing? Or maybe it's just I am not looking in the right places? :-) Bye, bearophile
Re: NaNs Just Don't Get No Respect
F i L: It's flawed because condition2 relies upon condition1 to Some people suggest: http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/c5uzt46 Regarding that Reddit thread in general, most people there seem quite ignorant about NaNs, so this little article was a small improvement. Bye, bearophile
Re: NaNs Just Don't Get No Respect
Another sub-thread that shows a very important thing, that's missing: http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/c5v1u0y Bye, bearophile
Re: NaNs Just Don't Get No Respect
Walter Bright:
Oh come on. That's called a "user defined type."
This D code compiles and it throws an "Enforcement failed"
Exception at runtime:
import std.typecons: Nullable;
void main() {
Nullable!int x;
int y = x;
}
With a different type system the compiler makes sure at
compile-time that x is not empty (this means the compiler makes
sure in no code paths x is used before testing it contains
something), avoiding the run-time exception.
Bye,
bearophile
Re: NaNs Just Don't Get No Respect
Peter Alexander:
It's tricky. The only way (that I'm aware of) to get it to
return NaN is to explicitly test for NaN, introducing overhead
that is unnecessary 99.9% of the time.
Unfortunately this is one of those situations where D's design
goals of efficiency and safety are at odds. You can't have it
both ways.
Few possibilities:
1) Add a second NaN-aware function pair nmax()/nmin();
2) Add a debug{} inside min()/max(), where NaNs are managed;
3) Introduce a if(version=NaNAware){} block inside the normal
max()/min() and other Phobos functions, to be used when you want
more NaN-correct results.
I prefer the third idea, but this probably requires a
recompilation of Phobos.
Bye,
bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: I would like to share with you, Beta version of http://dpaste.dzfl.pl/ At the moment gives a 403 error :-( Bye, bearophile
Re: Walter charms the audience at Sioux
Andrei Alexandrescu: http://sioux.eu/en/hot-or-not/d-programming-language.html At page 90 of the slides there is: Coming Soon ... Classic example: NonNull!(T) We'll use it to see if it's good enough (and if for it some shorter syntax sugar is needed). Validated data: Validated!(T) What's this? Maybe someone of the D community is willing to prettify Walter slides before he does the talks. I think this will help give D endavour and community a bit more professional/refined look. Bye, bearophile
Re: Walter charms the audience at Sioux
Jonathan M Davis: I'd expect that its lack of adoption is primarily a marketing issue. For people to adopt D there are factors more important than marketing: lack of tools, vendors support, libraries, schools and courses, the presence of competing languages, people that don't want to learn another language, unwillingness in betting in a language created by a little group of people, frequency of bugs in D/compiler, unfinished feel of some part of the language, lack of lot of stuff in Phobos, etc. Bye, bearophile
Re: Walter charms the audience at Sioux
Walter Bright: I like the plain jane look, and do not think it is unprofessional. A part of me thinks the outlook of those slides is not "shiny-professional", just compare your slides with the first and last slides in that Pdf probably added by the conference organizers, with refined graphics, etc: http://sioux.eu/en/hot-or-not/downloads/doc_download/80-walter-bright-d-programming-language.html On the other hand I like that plain look myself :-) I love simple readable things, my slides look equally plain and simple. Bye, bearophile
Re: Social Influence on Language Adoption
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/yon3i/social_influences_on_language_adoption_pdf/ Some people on Lambda the Ultimate have criticized the quality of the sources of the data, but despite those sources not looking the best, I think the data is acceptable: http://lambda-the-ultimate.org/node/4593 One of the things said by the paper is: Result 8. Curriculum matters more than college major in predicting which sorts of languages programmers know. This result implies that adherents of a particular language family, such as functional or logic programming, should emphasize introducing developers to these concepts and languages while they are still in school. While developers may be willing to learn new languages throughout their career, they do not appear nearly so inclined to learn new paradigms.< At the university closest to me I see many various CS teachers pushing hard for functional languages (but some courses require languages like C or even assembly). So maybe future students will be less willing to use imperative/OOP languages. Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: But I moved it by hand, seems to be working good again. Thank you. I have seen that some times it "loses" the selections: if I select a certain "Expiration" or "Others" I'd like it to keep the same choice in my successive pastes in the same session. Bye, bearophile
Re: Wrote a blog post about CTFE and D
Danny Arends:
http://www.dannyarends.nl/index.cgi?viewDetailed=00029
struct Coord(T : float){
T[] d = [1.0, 0.0];
Maybe better ==>
struct Coord(T) if (isFloatingPoint!T) {
T[2] d = [1.0, 0.0];
(isFloatingPoint is in std.traits)
Bye,
bearophile
Re: OT: Speed reading
Walter Bright: Speed reading works fine when reading a bestseller novel. It's a complete failure at reading intellectually dense material. But if the novel you have speed read was very good you have missed most of the enjoyment. It's like eating a very good traditional handmade ice cream: if you gulp it down in few seconds you miss most of the point of eating it :) Better to read one good novel slowly and appreciate and understand it well, than quickly read three of them, and forget them in few weeks. Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: Thank you for your suggestions! :-) To send a paste both codepad and ideone use "Submit", I find that word more natural than the "Save" used by DPaste, because most times what I want is the code to run. Also, my monitor has a largish font, so paste lines don't have too many columns. So have you tried to put the "Paste settings" on something like a horizontal ribbon at the top of the screen (like an actual program), and leave full width to the lines of code? Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: I wanted to keep distinction between 2 different features: Save - saving and (if checked) running code Compile (for registered users) - running code without saving paste itself Not sure if Submit won't clear that distinction I see. Would it be too much effort if I would ask for screenshot? Probably it's better to show you a screenshot on IRC. I could ensure that 120 characters fits in one row (when default font is used). I probably use a little larger fonts, so there are less columns. Generally you can't design a site assuming everyone uses/sees the same font size. See you, bearophile
Re: Yaw, Pitch and Roll with D 2.0
Danny Arends:
Another post: http://www.dannyarends.nl/?viewDetailed=00030
pure mat!(T)[3][] gen_rotationmatrices(T = float)(){
I suggest to write something like this (note the casing and other
details):
Mat!T[3][] genRotationMatrices(T = float)() pure {
tmp += mixin('A[i][k] '~op~' B[k][j]');
This seems OK, but it looks a bit convoluted. Maybe something
like this works (untested):
tmp += A[i][k].opBinary!op(B[k][j]);
pure auto yaw(int deg){
deg = degreeloop(deg);
return cast(matrix)rmatrix[deg][YAW];
}
I suggest generally to try to avoid casts, where possible.
Bye,
bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
One problems I see is the "Raw" view shows me the code with no indentations at all (and in proportional font, this is not good). Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: Done. Thank you for your suggestions! The selection of "Comments allowed" seems to get lost still every time. Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: What do you mean by proportional font? A proportional font has character glyphs of different width, like Arial, where a "i" is takes less horizontal space than "W". Bye, bearophile
Re: Another go at the Next Big Language
Michal Minich: http://dave.cheney.net/2012/09/03/another-go-at-the-next-big-language Hacker news discussion http://news.ycombinator.com/item?id=4468731 Reddit http://www.reddit.com/r/golang/comments/z9ltl/another_go_at_the_next_big_language/ An interesting quotation from the various threads: The nbl doesn't exist yet. It has to make the mediocre corporate developer much more productive as java did over c++. Nothing can do that as of now. There are several technically superior languages compared to java but that isn't what is needed to be the nbl.< Another quotation: The next big language [...] it'll be something that builds profiling and unit testing and better source control support right into the language, compiler, and tools.< That's interesting, but how do you add some source control support in a language? I remember only things like #region #endregion of C# that are for the IDE: http://msdn.microsoft.com/it-it/library/9a1ybwek%28v=vs.80%29.aspx Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Benjamin Thaut: But still in the GC version you have the problem that way to many parts of the language allocate and you don't event notice it when using the GC. Maybe a compiler-enforced annotation for functions and modules is able to remove this problem in D. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Benjamin Thaut: http://3d.benjamin-thaut.de/?p=20#more-20 Regardind your issues list, most of them are fixable, like the one regarding array literals, and even the one regarding the invariant handler. But I didn't know about this, and I don't know how and if this is fixable: The new statement will not free any memory if the constructor throws a exception.< Insights welcome. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Iain Buclaw:
Most of the array allocation cases we are talking about are like:
void main() {
int[3] a = [1, 2, 3]; // fixed size array
}
That currently produces, with DMD:
__Dmain:
L0: sub ESP, 010h
mov EAX, offset FLAT:_D12TypeInfo_xAi6__initZ
push EBX
push 0Ch
push 3
push EAX
call near ptr __d_arrayliteralTX
add ESP, 8
mov EBX, EAX
mov dword ptr [EAX], 1
mov ECX, EBX
push EBX
lea EDX, 010h[ESP]
mov dword ptr 4[EBX], 2
mov dword ptr 8[EBX], 3
push EDX
call near ptr _memcpy
add ESP, 0Ch
xor EAX, EAX
pop EBX
add ESP, 010h
ret
There is also the case for dynamic arrays:
void main() {
int[] a = [1, 2, 3];
// use a here
}
But this is a harder problem, to leave for later.
this infact caused many strange SEGV's in quite
a few of my programs (most are parsers / interpreters, so
things that
go down *heavy* nested into itself, and it was under these
circumstances that array literals on the stack would go corrupt
in one
way or another causing *huge* errors in perfectly sound code).
Do you know the cause of such corruptions? maybe they are caused
by other compiler bugs...
And what to do regarding those exceptions in constructors? :-)
Bye,
bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Iain Buclaw: I think it was mostly due to that you can't tell the difference between array literals that are to be assigned to either dynamic or static arrays (as far as I can tell). I see. I do believe that the issues surrounded dynamic arrays causing SEGVs, and not static (I don't recall ever needing the use of a static array :-). I use fixed size arrays all the time in D. Heap-allocated arrays are overused in D. They produce garbage and in lot of cases they are not needed. Using them a lot is sometimes a bad habit (if you are writing script-like programs they are OK), that's also encouraged by making them almost second-class citizens in Phobos (and druntime, using them as AA keys causes performance troubles). If you take a look at Ada language you see how much static/stack-allocated arrays are used. In high performance code they help, and I'd like D programmers and Phobos devs to give them a little more consideration. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
If you take a look at Ada language you see how much static/stack-allocated arrays are used. In high performance code they help, and I'd like D programmers and Phobos devs to give them a little more consideration. Also, the lack of variable length stack allocated arrays in D forces you to over-allocate, wasting stack space, or forces you to use alloca() that is bug-prone and makes things not easy if you need a multi dimensional array. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Walter Bright: I'd like it if you could add some instrumentation to see what accounts for the time difference. I presume they both use the same D source code. Maybe that performance difference comes from the sum of some metric tons of different little optimizations done by the GCC back-end. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Walter Bright: No code gen changes whatsoever were needed. In that case I think I didn't specify what subsystem of the D compiler was not "good enough", I have just shown a performance difference. The division was slow, regardless of the cause. This is what's important for the final C/D programmer, not if the cause is a badly written division routine, or a bad/missing optimization stage. And regarding divisions, currently they are not optimized by dmd if divisors are small (like 10) and statically known. Bye, bearophile
Re: Epoll for D2
Adil: https://github.com/adilbaig/Epoll-D2 ev.events = EPOLL_EVENTS.IN | EPOLL_EVENTS.HUP | EPOLL_EVENTS.ERR; In D enums are kind of (but not really) strongly typed, so writing them all in UPPERCASE is often a bad practice. So something more similar to this seems nicer: ev.events = EpollEvents.in | EpollEvents.hupx | EpollEvents.error; epoll.add(int file_descriptor, ev); Is this correct D syntax? Bye, bearophile
Re: Epoll for D2
Adil Baig:
"are kind of (but not really) strongly typed" - I didnt know
that. How?
D allows code like:
enum Foo { V1 = 10 }
void main() {
assert(Foo.V1 == 10);
}
But C++11 enums are strongly typed, and similar code is a
compilation error:
enum class Foo { V1 = 10 };
int main() {
int b = Foo::V1 == 10;
}
Maybe Walter thinks that in similar cases forcing the usage of
cast(int) introduces some risks that are not worth, so he has
designed enums half-strongly typed. D contains several other
equally mysterious design decisions :-)
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=3999
I'm thinking
Events.* ; Events.IN, Events.HUP etc. Succinct and fairly
obvious. Looks good?
What about Events.in, Events.hup, etc? :-)
Bye,
bearophile
Re: Epoll for D2
What about Events.in, "in" is a keyword... sorry. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
SomeDude: It's a bad solution imho. Monitoring the druntime and hunting every part that allocates until our codebase is correct like Benjamen Thaut is a much better solution Why do you think such hunt is better than letting the compiler tell you what parts of your program have the side effects you want to avoid? Bye, bearophile
D @ ICFP 2012
Kazuhiro Inaba ("Dark Integers" Team) has reached position 6 in
the prestigious ICFP 2012, it's not bad:
http://www.kmonos.net/repos/icfpc12/wiki?name=icfpc12
Code:
http://www.kmonos.net/repos/icfpc12/dir?ci=tip
Info on the contest and its results:
http://www.youtube.com/watch?v=5TCqUU3-GT0
http://icfpcontest2012.wordpress.com/
The winning entry was in C++, by "Frictionless Bananas" team:
http://www.sawicki.us/icfp/2012/
The C++ code contains some interesting parts:
To represent multiple states efficiently, my program stores
diffs between states. Only one full grid is stored at a time.
Executing a robot command updates the grid and produces a diff
that represents the changes needed to restore the previous
state. Applying the diff will undo the changes and produce the
opposite diff that can be used to redo the changes. An entire
tree of states can be represented by storing each state as a
diff from an earlier state in the tree. To improve the
performance when reconstructing a desired state from diffs,
several diffs can be merged together to produce a diff that will
undo or redo several robot commands at once. My program merges
diffs in such a way that n commands can be undone/redone by
applying O(log n) diffs.<
To avoid the exponentially increasing size of the state space,
states are grouped into buckets with similar characteristics.
Only the first state to be reached in a given bucket is kept;
other states in the same bucket are discarded and not explored
further.<
The C++ code, it's nice, about 67 KB:
http://www.sawicki.us/icfp/2012/submission2.tar.gz
Bye,
bearophile
Re: Slides from LASER 2012
Andrei Alexandrescu: In particular, Martin has been quite impressed with our approach to purity and immutability. We are considering a collaboration with one of his students on a paper to formalize the approach and possibly adapt it to Scala. Formalizing D purity is probably possible, but it already has many special cases, and few more are coming (see Bugzilla on this)! Regarding cross pollination with Scala: despite I generally don't like lazy lists in high-performance code, in many other kinds of code they are very handy, as in Haskell, Perl6 and Scala (in Scala they are named purely functional lazy streams). If you take a look at Python/Scala/C# code that generates values lazily, the Range-based version in D is sometimes several times longer, much more easy to get wrong, harder to write, etc. This is Haskell code to test if just the leaves of two binary trees contain the same data, this code is lazy: data Tree a = Leaf a | Node (Tree a) (Tree a) fringe :: Tree a -> [a] fringe (Leaf x) = [x] fringe (Node n1 n2) = fringe n1 ++ fringe n2 sameFringe :: (Eq a) => Tree a -> Tree a -> Bool sameFringe t1 t2 = fringe t1 == fringe t2 Doing the same thing in D, using ranges, is possible, but the code is ten times longer or more: http://rosettacode.org/wiki/Same_Fringe#Strong_Lazy_Version Similar code is possible in Scala (and in this case most of the saving of lines of code doesn't come from pattern matching and algebraic data types, but from the good support for lazy lists/streams). This kind of code is very common, even when you aren't coding in functional style. So, these are the slides I've used (though of course they don't tell much of the story). http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf Thank you for the slides. I hope we'll have the range-based min(), and argmin/argmax in Phobos :-) At page 33: auto m = s.argmin!((x) => x.length); This isn't compiled with -property. So what's the right way to write D code? In Python to avoid that lambda there is a len() global function, that just calls the __len__ attribute/property of collections and objects. So an equivalent Python version is: auto m = s.argmin!len; Bye, bearophile
Re: Slides from LASER 2012
Timon Gehr:
mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };
DynRange!T fringe(T)(Tree!T t){
return t.match!(
(Leaf l) => cons(l.x, empty),
(Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
);
}
bool sameFringe(T)(Tree!T t1, Tree!T t2){
return equal(t1.fringe, t2.fringe);
}
for suitable definitions of ADT, DynRange/dynRange, cons and
empty. So
those would be nice additions to Phobos. Obviously this would
look even
better:
mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };
DynRange!T fringe(T)(Tree!T t) => t.match!(
(Leaf l) => cons(l.x, empty),
(Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
);
bool sameFringe(T)(Tree!T t1, Tree!T t2) => t1.fringe ==
t2.fringe;
And thank you for the code example.
Bye,
bearophile
Re: Slides from LASER 2012
Timon Gehr: Formalising it is not hard, I am not sure of this, given the amount of special cases it already has. The number of lines equals the Haskell example in this case. Interestingly, you have opened an enhancement request on this and then argued against it. I am not against it, it's a nice syntax. But I think there are more useful things to change/add, like syntax to destructure tuples, that I need every 20 lines of code or so. When you put out many suggestions, I think it's important to specify what you think is more important and what's less important. There is no 'right' way. So we don't agree even on what we have to agree :-) And having multiple correct ways to do something is often bad :-( Bye, bearophile
Re: Slides from LASER 2012
Timon Gehr:
mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };
DynRange!T fringe(T)(Tree!T t){
return t.match!(
(Leaf l) => cons(l.x, empty),
(Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
);
}
bool sameFringe(T)(Tree!T t1, Tree!T t2){
return equal(t1.fringe, t2.fringe);
}
What's the purpose of the dynRange suffix here?
(Node n) => chain(n.a.fringe, n.b.fringe).dynRange
Maybe a "~" operator can be defined for such dynRanges, to avoid
the chain().
Bye,
bearophile
Re: Slides from LASER 2012
Timon Gehr: chain has type Result. dynRange takes an arbitrary range and transforms it into a range with the same value/vs reference behaviour whose static type depends only on the element type. I see. So that chain() is the normal chain of Phobos :-) (But is DynRange a lazy stream/sequence? This is the most important thing, because creating an eager linked list is kind of easy already, and misses the main point of my "request".) Bye, bearophile
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
Mike Wey: -m32 and -m64 ? i'ts what dmd uses on linux. Are those usable on DMD-Windows64 too? Bye, bearophile
Re: Component Programming in D
ixid: The article contains a bug due to the pernicious behaviour of seedless reduce. Hopefully Walter will be able to fix the article. Bye, bearophile
Re: Remus
Namespace: - Not null references - Stack instances (also known as scope instances) - Namespaces - Safe Null invocation Planned further still: memoize for functions and methods as well as ref counted instances. Similar efforts are useful almost as the Haskell GHC compiler extensions: to allow the community to try to use features not yet present in the language, to judge them better, allowing to understand if they are worth putting in the language, and trying few alternative implementation ideas looking for the best one of them. But to do this well, people need to understand such extensions very well. So instead of just offering the source code and one uncommented example, I suggest to explain each feature, why they are present, what design choices you have taken and why, and how to use them in some common cases, with few specific examples. This will make your work useful for the development of the mainstream D too. Bye, bearophile
Re: Remus
Namespace:
Not Null references:
I chose this syntax: int& b = a; because I like it in C++. This
syntax is recognized by Remus and is converted to: Ref!(int) b
= a;
If you must give a reference to a function or other things like
that, you can write:
[code]
Foo obj = new Foo();
some_function(@obj)
[/code]
instead of
[code]
Foo obj = new Foo();
{
Foo& robj = obj;
some_function(robj);
}
This seems far from being well designed not-nullable
pointers/class references :-(
[/code]
Namespaces: You can declare a namespace this way:
[code]
namespace io {
void print() {
writeln("foo");
}
}
[/code]
you _cannot_ use it without explicit "use" statement (will
maybe change). So you must write
[code]use io;[/code] to use _all_ methods from "io", or, like
import, [code]use io : print[/code] or [code]use io : write =
print;[/code]
"use" statements are converted to one or more alias' and
namespaces to (mixin) templates.
But what are they useful for?
Stack Instances:
There aren't many words for: if you need a stack instance,
write: local Foo f = new Foo(); it's more or less the same as
scope.
scope was removed for certain reasons, are those reasons not
valid for "local"?
Bye,
bearophile
Re: D1 & D2 alpha's for Win64
Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip Be the first kid on your block to build a dmd Win64 app! The changelog section is not in good state, it misses parts and newlines. Bye, bearophile
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
I suggest to compile with -g (or equivalent), to produce good stack traces.
Re: GC vs. Manual Memory Management Real World Comparison
I use this GC thread to show a little GC-related benchmark. A little Reddit thread about using memory more compactly in Java: http://www.reddit.com/r/programming/comments/120xvf/compact_offheap_structurestuples_in_java/ The relative blog post: http://mechanical-sympathy.blogspot.it/2012/10/compact-off-heap-structurestuples-in.html So I have written a D version, in my test I have reduced the amount of memory allocated (NUM_RECORDS = 10_000_000): http://codepad.org/IhHjqUua With this lower memory usage the D version it's more than twice faster than the compact Java version that uses the same NUM_RECORDS (0.5 seconds against 1.2 seconds each loop after the first two ones). In D I have improved the loops, I have used an align() and a minimallyInitializedArray, this is not too much bad. But in the main() I have also had to use a deprecated "delete", because otherwise the GC doesn't deallocate the arrays and the program burns all the memory (setting the array to null and using GC.collect() isn't enough). This is not good. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
Rob T: Is this happening with dmd 2.060 as released? I'm using 2.061alpha git head, but I guess the situation is the same with dmd 2.060. The code is linked in my post, so trying it is easy, it's one small module. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
But in the main() I have also had to use a deprecated "delete", And setting trades.length to zero and then using GC.free() on its ptr gives the same good result. Bye, bearophile
Re: GC vs. Manual Memory Management Real World Comparison
And with the usual optimizations (struct splitting) coming from talking a look at the access patterns, the D code gets faster: http://codepad.org/SnxnpcAB Bye, bearophile
Re: Remus
Namespace: Not interested, huh? Funny, that I had not expected. Maybe they appreciate more something that improves the life of regular D programmers. There are many possible ways to do that, like trying to design features that quite probably will be added to D, or trying library ideas that will become part of Phobos, trying new GC features, trying new Phobos modules, and so on and on. Otherwise you risk creating another Delight (http://delight.sourceforge.net/ ) that no one uses, it's just a waste of time for you too. Bye, bearophile
Re: Remus
Namespace:
or other suggest other features that they would like
to see in remus. I look forward to suggestions. :)
There is a D problem that in my opinion is worth exploring.
Usually I prefer const/immutable variables/collections, but there
are several different situations where this is hard to do. In
some cases to do this you even have to create a function in-place
that is called in-place, that creates an array, returns it, and
the result is assigned to const. There are other different
situations.
One other case is at global scope:
immutable foo = bar + baz
where {
auto foo = ...;
auto baz = ...;
};
Bye,
bearophile
Re: Remus
Namespace:
When did you use something like this?
Now and then :-)
In this case you could take a function that assign foo:
Usually in that case I use the module "static this". But the point
immutable foo;
void assignFoo() {
string bar, barz; // ...
foo = bar + baz;
}
or not?
That doesn't work because foo has no type, and because you can
only initialize immutable global variables inside the "static
this".
But the main point of what I was saying is not that it's
impossible to do some things, most times there is already some
way to do it in D.
I was saying that the current ways to assign immutable
values/collections is sometimes not handy in D. So Remus seems
the right place to experiment several different ideas to improve
those situations. A "where" is just one of the different
possibilities.
Bye,
bearophile
Re: User Defined Attributes
For the syntax maybe it's better something like @() instead of
[], so it becomes more greppable and more easy to tell apart
visually from the array literals:
@(1, "xx", Foo) int x;
Supporting annotations for function arguments is probably an
important sub-feature.
Yesterday I was discussing about the bug-prone nature of foreach
loops on a struct array, and one of the solutions I've suggested
was a user-defined annotation for the programmer to denote that
she wants to modify just the copy:
struct Foo {}
Foo[10] foos;
foreach (@copy f; foos) { ... }
With UDA syntax:
foreach ([Copy] f; foos) { ... }
Or:
foreach (@(Copy) f; foos) { ... }
But I think there's no way to tell the compiler to give a
compile-time error if such annotation is not present there
(unless there's "ref").
-
Gor Gyolchanyan:
@flags enum A { ... }
the "flags" attribute would replace the declaraction of A with
another enum declaration with the same name and same members,
but with replaced initialization and would static assert(false,
"flags enum can't have initializers") if any initializers are
given.
I appreciate your idea (I think of user-defined attributes also
as ways to extend the type system), But I know the engineer in
Walter prefers extra-simple ideas, so maybe your idea will not be
accepted :-) But let's see.
Bye,
bearophile
Re: User Defined Attributes
Walter Bright:
First of all, assume I know how to use and abuse foreach in all
the common and uncommon cases. So in this discussion we can
assume we both know well enough what we are talking about. What I
am discussing about is a real problem in real D code, a bug-prone
characteristic of foreach. We may accept the situation like it
is, and do nothing, or we may want to improve the situation. But
this doesn't change the fact that there is a problem in the D
design of foreach loops when you scan an array of structs. This
problem is recognized by several other persons in the D
community, it's not a creation of my mind.
That said, let me try again to explain the problem.
// Case3 (uncommon)
void main() {
auto data = [0, 1, 2, 3];
foreach (@copy x; data)
writeln(++x);
}
x is a value type, and it is already copied. And if you did
want to copy it,
foreach (x; data)
{ auto copy = x;
writeln(++copy);
}
I don't see what the annotation buys you, even if it could be
made to work.
The point of Case3 is not that I want to copy it again. The
annotation by itself buys you nothing. But he annotation is not
meant to be the only change in D. There are two changes that need
to happen at the same time:
Change1) Make this a compile-time error, this means if you write
this code, the compiler refuses your code statically. So "x"
despite not being const is like being const, because the compiler
does not let you modify it inside the loop, if you try, it gives
you an error (so maybe it's simpler to implement this Change1
really as putting "const" on default on x even if you don't write
"const" there. C# language is designed this way!):
auto data = [1, 2, 3];
foreach (x; data)
x++; // compilation error here
Change2) Introduce an annotation like @mutable to denote Case3 (I
have replaced @copy with @mutable to make this explanation more
clear for you, so maybe @mutable is really a better name for this
idea). This means this is accepted, it's like saying that x is
not const:
foreach (@mutable x; data)
writeln(++x); // OK
Why I have suggested this pair of changes? The only purpose of
those two changes is to remove one bug-prone situation from D
code.
The situation is this:
struct Foo { int x; }
auto data = [Foo(1), Foo(2), Foo(3)];
foreach (f; data)
f.x++;
What is the programmer trying to write there? Was she trying to
change the structs inside data (Case2)? Or was she trying to
modify just their copy (Case3)?
The problem is that usually programmers want Case1 or Case2, they
most times do not want to write a Case3. But it's very easy to
forget "ref". So the programmer wants to write a Case2 but often
writes a Case3 by mistake.
The combined presence of Change1 and Change2 removes this source
of errors. Because now if you forget "ref" the compiler refuses
your code statically. If you want Case3 you add a @copy. In most
cases you really meant to use a Case2 so you add "ref" and the D
compiler has caught your bug!
If you were trying to write a Case1 you didn't put inside the
loop code that modifies the struct, so the error of Change1 is
not triggered and you need no @copy nor ref.
I have written probably 250_000+ lines of good-quality D1/D2
code, and bugs like this are still present in my code, so I'd
like to remove them from D once and for all:
struct Foo { int x; }
auto data = [Foo(1), Foo(2), Foo(3)];
foreach (f; data)
f.x++;
Bye,
bearophile
Re: User Defined Attributes
Walter Bright: But I'm not sure at this point if that is the right thing to do. Why? [If you decide to restrict UDAs, then later it will be easy to extend them, it will not break code. While doing the opposite break code. It's you the one that has taught me to design things this way :-) ] Bye, bearophile
Re: Remus
Another interesting possible feature for Remus: as the usage of
immutable structs becomes more common in D code, it becomes more
useful a syntax to create an updated struct. Similar syntax is
present in F# and other functional languages.
struct Foo { int first, second, third; }
immutable f1 = Foo(10, 20, 30);
Current syntax:
immutable f2a = Foo(f1.first, 200, f1.third);
A possible syntax:
immutable f2b = Foo(f1 with second = 200);
Bye,
bearophile
Re: User Defined Attributes
Walter Bright: (I know this sub-discussion is a bit OT, but not too much, and I think it's not wasted time.) But D does not require that. It's up to the programmer.< Oh, but the use of "newtype" is not required in Haskell; programmers are free to use it, or to use normal basic types as Int, Integer, Double, etc. Probably newtype is not that useful in little programs. And even in larger programs it's better to not use it too much. And the use of that "using" in a newtype is not standard Haskell, it's a GHC compiler extension to the language, that you have to ask with a compilation switch or an annotation inside the code. That "using" attached to a newtype allows you to both use a newtype like its base type (like the underlying Int), or to choose where the newtype must not do what its base type is able to do (this technically means what typeclasses it conforms to or not). I think D Typedef should allow something similar, despite D has no typeclasses. As an example, currently D Typedef is kind of useless if you want to use it to define a new array type. Bye, bearophile
Re: User Defined Attributes
Walter Bright: D's typedef is deprecated, as nobody could figure out what it was good for or properly define its semantics. Look better, in both my last posts "Typedef" was std.typecons.Typedef. Bye, bearophile
Static typing, contracts, unit tests and more
(Sorry for the duplicated post, I have realized it's better to show this here than D.learn) Notes about some ways to write code and avoid some mistakes. http://www.reddit.com/r/programming/comments/138j4t/static_typing_contracts_unit_tests_and_more/ Bye, bearophile
Re: [OT] Clang seems to implement modules
Jacob Carlborg: I just read the slides of a talk from that latest LLVM Developers' Meeting. It's a talk about modules by Doug Gregor from Apple. It seems that they already have started to implement this new feature in Clang. It's from the conference I have recently linked two slide packs here. The slides you refer are: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf Bye, bearophile
Re: [OT] Clang seems to implement modules
Walter Bright: CTFE is still slow, I don't agree. Given that what's run at compile-time is statically typed code that's easy to optimize, then with techniques that are simpler that ones used by LuaJIT CTFE or JavaScript V8 JIT (that work on dynamically tyed code, that requires lot of work to optimize well), it is able to become almost as fast as regular D code (such JITs compile only if a computation/loop takes a large enough amount of time, otherwise they interpret efficiently). Bye, bearophile
Re: Remus
Namespace:
- scope arrays: like static arrays,
I think they are fully implementable in library code. Maybe
Phobos Array already does that fully.
While Variable Length Arrays allocated on the heap can't be
implemented with a nice syntax in library code, so I think they
are more fit for a built-in implementation (but they need new
syntax and they are more complex to implement).
- lazy const: Just a spontaneous idea: I have often variables,
which aren't initialize in the CTor, but they are initialized
only once, and then they should be constant. That isn't
possible yet. Therefore I whish something like: lazy const var;
This is a quite common need, like when you want to perform a
costly computation only once. Maybe there is even an enhancement
request in Bugzilla.
I understand why this is named "lazy const" but this code is
currently accepted:
void foo(lazy const int x) {}
void main() {}
So to avoid confusion I suggest to give a different name to this
feature. One possibility is to use a new keyword, like a
"monoassignable" :-)
How did you implement this feature? If done well, with a good
enough name, it's even possible to make a pull request in the
main D compiler with just this feature.
- And of course: not-null references. There is not much to
say. Current syntax idea comes from C++: Foo& f = other_f;
Probably this requires far more design to be done well enough.
I suggest to write/adapt several small programs with your new
features (like from here:
http://rosettacode.org/wiki/Category:D), and to try them to see
how useful they are.
Bye,
bearophile
Re: Remus
While Variable Length Arrays allocated on the heap can't be I meant stack, sorry. Bye, bearophile
Re: Remus
Namespace: I will write a struct and replace 'readonly ...' with an instance of ReadOnly!(...) ... OK. What do you mean with 'how useful'? It means to try to use your feature(s) to rewrite/modify several of those little programs, and then take at how much frequently you use those new features, what advantages they give you, and so on. An usability experiment. Bye, bearophile
Re: Remus
Namespace: A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts. I put some partial notes here: http://d.puremagic.com/issues/show_bug.cgi?id=4571 See in particular: http://research.microsoft.com/pubs/67461/non-null.pdf Bye, bearophile
Re: [OT] Three Optimization Tips for C++
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ I appreciate such slides and videos, thank you for sharing. But If possible I'd like a link to the slides in a place where I don't have to register to download them. I have also just seen this other slides pack from Jordan DeLong, it is very interesting, it's about a topic that is usually regarded as one of the strongest points of functional languages (that is using types to "make illegal states unrepresentable"): http://www.reddit.com/r/cpp/comments/1571m9/facebook_nyc_tech_talk_jordan_delong_using/ Bye, bearophile
Re: Amber
Lars Ivar Igesund: Project page: https://bitbucket.org/larsivi/amber Seems a good idea to test some alternative designs, alternative features and alternative ideas. What are the differences (present or planned) between D1 and Amber? Bye, bearophile
Re: Amber
Kelly: Might be incomplete, but here is the start of a list: https://bitbucket.org/larsivi/amber/wiki/Diff_D1 Thank you for the link, it's an interesting list of differences. Some comments: No comma expression We have had some discussions to disallow the comma operator in D2 too. No foreach_reverse. I love foreach_reverse. It makes my code simpler and more readable, and avoids me some bugs. Omitting override is an error. This will happen in D2 too. Array literals don't necessarily allocate, so auto a = [1, 2]; a[0] = 2; may segfault. Do you mean cause stack overflow? Both Go and Rust languages avoid this in most cases using segmented stacks. No C-style arrays I'd like them to go in a state of perpetual deprecation, because they are handy when I port C code to D, but at the end, in later stages of the porting, I prefer to use only one style of array declarations in my code. At least in D2 I'd like D to disallow mixing C style arrays with D style ones: int[] c[5]; http://d.puremagic.com/issues/show_bug.cgi?id=5807 Bye, bearophile
Re: Runtime code reloading in D, part 1
Benjamin Thaut: http://3d.benjamin-thaut.de/?p=25 The pointer to the RTTI information for each member is a workaround for a strange bug I encountered. For POD structs the rtInfo template will be instancated, but for some reason you can not query the results at runtime. It is possible that the linker stripps the information away but I could not yet investigate this issue further. If I can not query the RTTI information at runtime I fallback to the RTTI info pointer stored in the “next” member of thMemberInfo.< This seems one of the situations where knowing "why" is almost more important than "doing": understanding the cause, and maybe even fixing it, will help future D programmers. Bye, bearophile
Re: D 1.076 and 2.061 release
Walter Bright: http://www.digitalmars.com/d/download.html Is this link correct? https://github.com/downloads/D-Programming-Language/dmd/dmd.2.061.zip Bye, bearophile
Re: D 1.076 and 2.061 release
In the D2 changelog the "Phobos Bugs Fixed" seems empty.
Also there are issues like this one that don't give enough info:
http://d.puremagic.com/issues/show_bug.cgi?id=9219
I think in the Changelog a little summary of the biggest changes
("Release highlights") is useful to have.
Another useful thing for the changelog is like the "Porting to
Python x.x" here:
http://docs.python.org/3.3/whatsnew/3.3.html
It explains what needs to be modified in user code to use the new
language release.
Bye,
bearophile
Re: D 1.076 and 2.061 release
Are you going to remove the D1 compiler parts of code in the D2 compiler source code? A leaner source base will help. Also this transitional moment seems a good moment to rename the ".c" suffix of the frontend+backend C++ files to ".cpp" or something like that. I have to warn people that if they want to suddenly switch from 2.060 to 2.061 with no intermediate steps, probably some of their code will break, and they will have to work to fix it. Bye, bearophile
Re: D 1.076 and 2.061 release
Jonathan M Davis: Why? Because the two numbers "2.060" and "2.061" look very very similar, so people that see them risk thinking they are just two nearly identical releases of the same compiler. But many months have passed between those two versions, many bugs have being removed, several features have being introduced, and so on (just look at the difference in the zip size between the two versions), so it's better for the users to be aware that some probably some user code will need to be fixed or improved to run on the 2.061. Bye, bearophile
Re: D 1.076 and 2.061 release
Jonathan M Davis: And how is that any different from any other release? How much time used to pass between two adjacent releases, in past? Bye, bearophile
Re: D 1.076 and 2.061 release
deadalnix: I still have code broken all over the place. D2 is getting its corner case problems sorted out and fixed, but this still causes some breakage in user code. As more people use D2, issues are found, discussed and fixed, the breakages will get more and more uncommon. Bye, bearophile
Re: Runtime code reloading in D, part 1
Benjamin Thaut: In Summary it feels to me that GC free D is not important to the community or the active contributors. I think it will become more important for them, in future. At the moment the work is mostly on finishing immutability, purity, shared, and other parts of the core language, and working on process characteristics (like GIT workflows) that are needed to make everything else work efficiently. they have nice productivity features like runtime code changing through the VM Some of those productivity features are important, and despite D doesn't run on a virtual machine I think some of them can be added to D, once enough attention and work is given on them. Bye, bearophile
On Rust [OT]
A good talk (it's short, 30 minutes long) about the Rust language: http://www.infoq.com/presentations/Rust It doesn't cover lot of stuff, just the essential things. Bye, bearophile
Re: On Rust [OT]
The slides: https://speakerd.s3.amazonaws.com/presentations/505f7d17ccf4a50002011800/emerging-languages.pdf Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
Walter Bright:
http://fgda.pl/post/8/a-look-at-the-d-programming-language
From the article:
if you only count the natively-compiled ones that could be used
instead of C++ and have a similarly looking code. D is the best
fit in this category, if not the only fit.1
There is also Rust.
if (!tmp) throw new Exception("Memory allocation failed");
The error for memory overflow isn't immediate to find.
The garbage collector in D isn't very fast and stops the
world (halts other threads).
A Rust GC doesn't need to stop more than one thread.
Bye,
bearophile
Re: A look at the D programming language by Ferdynand Górski
thedeemon: I had the impression that Rust was at embryonic stage Beside reading/seeing some tutorials, blog posts and talks, I have used Rust only for little experiments, so I don't know a lot about it. Compared to D it's less finished, but at version 0.5 most of its parts/syntax seems designed, and its compiler is self-hosted, so the language is already usable for largish experiments. At Mozilla there are several persons working on it. Bye, bearophile
Re: Announcement: "preapproved" tag added to bugzilla
Andrei Alexandrescu: We will follow later today with a preapproved enhancement request. (Of course, we will also preapprove enhancements written by others, too.) I don't remember of other language communities doing this, but it seems a nice idea :-) Bye, bearophile
Re: Announcement: "preapproved" tag added to bugzilla
Leandro Lucarella: And given how D community works, seems to make more sense to put "Improvement Proposals" in bugzilla directly. The only drawback I see on this is maybe big improvement proposals get less visibility and are not easily differentiable from minor enhancements or even bugs. Let's see one of more of such pre-approved ER, and we'll see how much good this idea is in practice. Regarding visibility, it's easy to write a page in the site that links to each one of them. Bye, bearophile
Re: DPaste is going down
nazriel: Costs of keeping Dpaste alive are a bit too high for pure student like me ;) I guess you meant strongly pure student. Is the asm generated lazily? I will put Dpaste website and backend source code on Github soon, so if someone would like to pick up the project, be my guest. Is it possible to put it in a subpage of the dlang site? Bye, bearophile
Re: DPaste is going down
nazriel: Not yet. Was on my todo list. Asm was generated and saved do DB and then displayed in website on each request - but then I realized it was generating a bit too much transfer. But I will improve this before posting code on GH Making it lazy will decrease the site costs. An useful missing feature is a way to specify compilation switches (like -wi or -O or -inline). Sometimes I find compiler bugs that are triggered only by specific compilation switches (like -inline), and I was not able to try/see those errors on dpaste. Be proud, you have created a small thing that people like, andmay be they will keep your work alive elsewhere. Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
Chris: or indentation (t)errors (Python) In practice Python usually decreases the number of indentation-related bugs, even considering the "dangling else" warning we have added to D, because indentation and block nesting are the same thing, it's more DRY :-) Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
1100110: Thats so funny I forgot to laugh. One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability). Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
Chris: Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length). and the fact that one missing white space (a typo after deleting a line) screws up the whole script is just annoying. It's a small price to pay for increased code readability. And if I see one missing white space in D code, I fix it right now, so there is not a lot of difference. The Python indentation terror is a peculiar personal preference enshrined in the language's syntax. It's simply not my style. Curiously the Python significant syntax was the motive for me to start using Python in the first place, years ago. I was looking right for that, being fed up of begin-end, curly braces, and those code reading mistakes I was talking about. Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
Paulo Pinto: Source code is available at GitHub, https://github.com/maximecb/Higgs The code seems to miss the usage of contracts, foreach loops on numerical intervals, final switch, toString with sink, text() function, enum for compile-time constants, most const arguments, const on methods. Generally when you see several projects with the same "utility", it often means it should be in Phobos. So maybe something like this should be in Phobos: https://github.com/maximecb/Higgs/blob/master/source/util/misc.d Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
Paulo Pinto: More information on her blog, http://pointersgonewild.wordpress.com/2013/01/31/visiting-mozilla/ I like the slides because they don't contain a page titled "Why D?" nor they talk about D: http://pointersgonewild.files.wordpress.com/2013/01/higgs-presentation.pdf Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
deadalnix: The code seems to miss the usage of contracts, foreach loops on numerical intervals, final switch, toString with sink, text() function, enum for compile-time constants, most const arguments, const on methods. My experience tells me that this is probably a good idea if you don't want to run into weirdland. Among those things I have listed, probably the only ones that give a little of troubles are const on methods. The author has used asserts at the beginning of methods, outside a the pre-condition, this is silly. Not using foreach loops on numerical intervals is a waste of fingers and increases the risk of mistakes, final switches often help you, text() is shorter than to!string(), const arguments are usually handy to avoid some troubles and make function/method signatures more informative. Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
Dejan Lekic: In real projects people do the job as best as they can at the moment, But often there's also some need for: http://en.wikipedia.org/wiki/Code_review Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
Nick Sabalausky: Why is it silly? (Genuine question) "Silly" wasn't the right word, sorry. But generally if a language offers you a clean feature (D contract programming is designed clean enough) it's better to use it, when you clearly need it. In D you can live without D contract programming, but is useful, and it's better to know it. (I'd also like Phobos to replace most of its usages of enforce() with asserts inside contracts.) Bye, bearophile
Re: Higgs, a JavaScript JIT done in D
Peter Alexander:
I don't use D contracts, even though I use asserts.
I find that adding contracts bloats my code quite a lot, making
it less readable.
real log(real x)
in
{
assert(x > 0);
}
body
{
return ...;
}
v.s.
real log(real x)
{
assert(x > 0);
return ...;
}
As far as I'm aware there is no difference except when
inheritance is involved, so it's an easy choice for me.
If you have to create some temporary values (or to perform some
computation) for your asserts you probably want to put this code
inside a {} to avoid such names to spill inside the body of the
function.
There are also post-conditions, that catch all the returns you
have in your function, unlike free asserts.
There are also loop invariants, missing in D contract programming:
http://d.puremagic.com/issues/show_bug.cgi?id=9300
Also, a well designed language enforces pre and post conditions
to not mutate values (this is an ongoing discussion in D:
http://d.puremagic.com/issues/show_bug.cgi?id=9408 ), and offers
you the "old" (prestate) feature only inside contracts (missing
still in D contract programming). Contracts also make life a
little simpler for static analysis tools (that aren't yet
available in D).
So the better contract programming is implemented in a language
(and its tools), the more useful it is compared to using free
asserts.
Bye,
bearophile
Karpov, Walter and D
Maybe I missed this in the D newsgroups, "The D language comes to help" by Andrey Karpov, Walter Bright. Andrey Karpov takes the ten most common bugs found by his static analysis tool, and asks Walter how D faces each one of those ten classes of problems. The resulting text is interesting: http://www.viva64.com/en/b/0182/ Below some comments about the text. V547/V560: The unsigned<0 is usually a bug when it appears in top level code. However, it can legitimately appear as a boundary case inside of generic code.< Then maybe it's possible to warn/error only about those comparisons that are _not_ inside a template. It can also be used in code that tests if a type is unsigned, as in -(T)1<0. So I'm a bit uncomfortable in declaring it as always wrong.< I think the idiomatic way to do that in D is isSigned!T. I think making that "-(T)1<0" useless is a small price to pay. (I have found some signedness-related bugs in my D code converting pieces of it to C and compiling it with GCC with its signed-unsigned mixing warnings). - - - - - - - - - - V595: I can't think of a case where this might be done legitimately. But it does take some decent data flow analysis to be sure there are no intervening modifications of buf.< Is it worth doing that in D? Maybe the answer is positive. (Rust (and other recent languages) avoids this problem in another way, using not nullabile pointers and introducing pattern matching). - - - - - - - - - - V501: it's a common bug. But I agree it's not easy to avoid it reliably in a compiler. That's why static analysis tools often return probabilities of errors, instead of just bad/good. - - - - - - - - - - V512/V579 and V557: some languages are able to avoid most of such problems using very refined type systems (dependent typing), but this adds a significant amount of complexity to both the language and to the programming. Maybe "liquid typing" is (will be) able to do it without an excessive amount of work for the programmer. - - - - - - - - - - V567/V610: I think there is some work left to do on this in D, but it's going to be fixed. Maybe there is no entry on that in Bugzilla. - - - - - - - - - - V597: this shows an example where a buffer is zeroed for security reasons, despite it's never used again by the user code (because it risks being used by external code). Being able to remove dead assignments is a very important compiler optimization. They come up when instantiating generic code and inlining functions, and as the consequence of performing other optimizations. In C you should be able to force the dead assignment to happen by declaring the target to be volatile. The only way to force a dead assignment in D to happen is to write it using inline assembler.< Using assembly to clear a buffer is possible, but it's not so elegant. Maybe it's possible to add an annotation to D, like @keep, to stop the optimizer from removing something that is desired. Maybe this is not too much hard to implement. - - - - - - - - - - V519: Double assignment is a form of dead assignment, and my comment on it is the same as for (7).< This case is very different from case V597. This is more similar to V501. This is a matter of spotting duplicated assignments, because they are sometimes bugs. - - - - - - - - - - V576: D has enough features to avoid this kind of bug, but currently it's not doing it: I think Phobos should add functions like writecfln!"%d %f(10, 5.5), to catch at compile-time a wrong formatting string. Someone has already partially implemented those functions in D. - - - - - - - - - - V530: D does not have anything specific saying that a function's return value must be used. In my experience, return values that get ignored are often error codes, and D encourages the use of exceptions to indicate errors rather than error codes.< GCC-C has a function attribute to warn against not using a function result. Adding a @use_result to D is an option, and maybe it's not too much hard to implement. But I agree it's not a very common need in D. In one case I have written: arr.delete(5); Instead of the correct: arr = arr.delete(5); Here not using the result of std.algorithm.delete is often a bug. But maybe it's not always a bug. On the other hand a significant part of the computing world seems to go in the opposite direction, embracing JavaScript more and more, and (despite TypeScript) mostly ignoring all the care about the enforcement of static correctness: http://developers.slashdot.org/story/13/02/04/1819231/gnome-goes-javascript Bye, bearophile
