Andrei Alexandrescu:
We've just enabled warnings as errors in our build system at
work and suddenly:
It's much better to enable warnings since day -1, that means the
day before you start creating your D project.
That's why I'd like D compilers to have warnings active on
default and to have
Walter Bright:
Valgrind is an incredibly useful tool, but programs run
terribly slowly under it.
On the other hand the C/C++ world in the last years has seen
numerous advancements that D should keep an eye on. If you look
at the latest versions of LLVM-Clang and GCC you see various
sanitizers
Paulo Pinto:
Except, as far as I am aware, they only work on GNU/Linux and
Mac OS X, leaving out all other operating systems out there.
Is -fsanitize=integer not available in the Windows version of
Clang?
Perhaps it's a good idea to create something similar to the
sanitizers (the memory
Dicebot:
Funny, I can reproduce up to 2.063.2, but not after that.
I think it was removed because detection implementation was not
mature enough and resulted in confusing behavior for corner
cases. You have already already spotted one ;)
So much work to put that warning in... -.-
Bye,
Andrei Alexandrescu:
This doesn't quite explain much. -- Andrei
Look at the issue:
https://issues.dlang.org/show_bug.cgi?id=7444
Bye,
bearophile
Walter Bright:
That's what @safe is for.
I think those sanitizers (but the integer-related one) are meant
to help D programmers catch bugs in @system code.
Bye,
bearophile
Walter Bright:
http://wiki.dlang.org/DIP60
Given the current strong constraints in the directions of D
design, I like it.
But in DIPs I suggest to also write a list of the advantages of a
proposal, and a list of all the disadvantages.
In this ER I suggested a @noheap, that is meant to
Steven Schveighoffer:
On the left hand side, the [] operator is special *for arrays*
in that it denotes you want to do an element-wise copy. On the
right hand side, this is not the case, [] is simply an
operator. It's a no-op if the rhs is an array, since [] just
gets the array again.
Walter Bright:
What little remains is often @system for performance reasons,
where you'd turn off a sanitizer anyway.
You are wrong. Both integer overflow sanitizers and those various
modern memory/address sanitizers are not meant to be used in the
final release of the code. They are meant
Walter Bright:
Such cost would take away from other improvements to D that
would be far more valuable.
But I agree with this. In this moment there are more important
things to do (like finishing synchronized, scope, SIMD, vector
operations, operator
overloading, dynamic libraries, GC, and
Meta:
//TypeTuple or just bare list?
alias everything = TypeTuple!(@safe, nothrow, pure, @gc(false));
or
alias everything(Attrs...) = Attrs;
I think that the Microsoft language with effect algebra
(Bearophile has mentioned it before) does this. E.g., pure is
actually:
alias pure: noeffects
JN:
I doubt @nogc will change anything, people will just start
complaining about limitations of @nogc
Having a way to say this piece of program doesn't cause heap
activity is quite useful for certain piece of code. It makes a
difference in both performance and safety.
But not being able to
Walter Bright:
Not practical. malloc() is only one way of allocating memory -
user defined custom allocators are commonplace.
OK, then I'll have to close my ER about @noheap.
Bye,
bearophile
Peter Alexander:
* Does @nogc = nothrow? If I'm not mistaken, throw must
through a GC-allocated Throwable.
* If the above is true, does that mean exceptions cannot be
used at all in @nogc code?
This should work:
void foo() @nogc nothrow {
static const err = new Error(error);
throw
Stefan Frijters:
First of all, thank you very much for making such nice
additions to D available for general use. I finally got around
to giving this a spin.
Recently I've shown a possible usage example of the
multidimensional arrays indexing and slicing syntax:
Peter Alexander:
err.setError(badthing happened);
And that is usually written:
err.msg = badthing happened;
Bye,
bearophile
Peter Alexander:
(I assume that nothrow isn't meant to be there?)
In D nothrow functions can throw errors.
You could do something like this:
void foo() @nogc
{
static err = new Error();
if (badthing)
{
err.setError(badthing happened);
throw err;
}
}
To be
Walter Bright:
malloc is hardly the only problem people will encounter with
realtime callbacks. You'll want to avoid disk I/O, network
access, etc., too.
It seems a good idea to offer a way to extend the type system
with new semantically meaningful annotations in user code. (Koka
language
Walter Bright:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
If I have this program:
__gshared int x = 5;
int main() {
int[] a = [x, x + 10, x * x];
return a[0] + a[1] + a[2];
}
If I compile with all optimizations DMD
Adam D. Ruppe:
What I want is a __trait that scans for all call expressions in
a particular function and returns all those functions.
Then, we can check them for UDAs using the regular way and
start to implement library defined things like @safe, @nogc,
etc.
This is the start of a nice
Is it possible to compile this main with a future version of
ldc2 if I compile the code with full optimizations?
Sorry, I meant to ask if it's possible to compile this main with
a @nogc applied to it if I compile it with ldc2 with full
optimizations.
Bye,
bearophile
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is not flexible enough. So probably
the problem needs to be
Walter Bright:
I know that you bring up the array literal issue and gc a lot,
but this is simply not a major issue with @nogc. The @nogc will
tell you if it will allocate on the gc or not, on a case by
case basis, and you can use easy workarounds as necessary.
Assuming you have seen my
Kapps:
That code is not @nogc safe, as you're creating a dynamic array
within it. The fact that LDC2 at full optimizations doesn't
actually allocate is simply an optimization and does not affect
the design of the code.
Walter has answered to another person:
The @nogc will tell you if it
Kapps:
That code is not @nogc safe, as you're creating a dynamic array
within it. The fact that LDC2 at full optimizations doesn't
actually allocate is simply an optimization and does not affect
the design of the code.
I've added the opposite of what you say in the DIP. So Walter can
fix
Kapps:
Flags such as -O are specifically not supposed to change
program behaviour. This being the case would completely discard
that and allow code to be compiled only with a single compiler.
OK.
Honestly, I think expecting that code to be allowed to use
@nogc is a huge mistake and
Walter Bright:
dmd could do a better job of escape analysis, and do this
automatically.
Timon has kindly fixed the wrong part I wrote in the DIP60. But
if we introduce some basic escape analysis required by all
conformant D compilers, then the @nogc attribute can be applied
to some
Jacob Carlborg:
toUpperInPlace should be removed. It cannot work reliable in
place.
Better to move it in std.ascii instead of removing it.
Bye,
bearophile
Timon Gehr:
In which case? In case some version of LDC2 is able to avoid
the heap allocation using full optimizations? :o)
Please take a look, I have just added one more note in the
optimizations section:
http://wiki.dlang.org/DIP60#Behaviour_in_presence_of_optimizations
Bye,
bearophile
Daniel Murphy:
I prefer the old ones mainly because
You can't remove the new ones, and you can't keep two different
operator overloading systems in a language.
Bye,
bearophile
Brian Schott:
We have alias a = b; and alias b a;, so there's precedent
for having two ways of doing exactly the same thing.
I've just filed a bug report:
https://issues.dlang.org/show_bug.cgi?id=12615
Bye,
bearophile
H. S. Teoh:
The question is, is there a way to take a slice of the static
array, set
the length to zero, and append to it with ~= such that when it
runs out
of space in the static buffer, it will reallocate a longer
array on the
GC heap? Or is this a bad idea?
I suggested to add this to
In most languages (even in D) there are testing tools based
QuickCheck, that is a important alternative (or an extra tool to
use) to the normal unittesting:
http://en.wikipedia.org/wiki/QuickCheck
The programmer writes assertions about logical properties that a
function should fulfill, then
Jacob Carlborg:
I believe that for aliasing function pointers only the latter
syntax works.
It's a bug that needs to be fixed before the deprecation of old
style alias syntax...
Bye,
bearophile
Suliman:
It would be very nice to add to dlang wiki comparison woth
Python, to show that D code can be easy as Python.
In the Rosettacode site there are around one thousand Python-D
comparisons.
Bye,
bearophile
Walter Bright:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Currently this code doesn't compile because the lambda allocates
the closure on the heap:
void main() @nogc {
import std.algorithm: map;
int[3] data = [1,
Andrei Alexandrescu:
Guess we could link from dlang.org to some. -- Andrei
A simpler solution is to to just link to this page, that contains
the links to all pages that contain D entries:
http://rosettacode.org/wiki/Category:D
Bye,
bearophile
Walter Bright:
Pointing out these issues is exactly what @nogc is designed to
do.
Right.
Can't is a bit strong of a word. Needing a workaround that is
perhaps a bit ugly is more accurate. For your example,
enum int x = 3;
will solve the issue.
In most cases that x is a run-time
Suliman:
It's much better to add best examples at wiki.dlang.org
I am updating the examples on Rosettacode almost daily (example:
I am currently modifying tens of entries to use @nogc). So you
Suliman do you want to keep updating the dwiki to follow the very
frequent changes in the
Steven Schveighoffer:
I don't think this is a very good idea. The code should likely
build with the latest released compiler.
Yes, sorry, I know this could cause some troubles, but if you
think hard about the situation, you will see that this is
currently the best (or less bad) solution. It
Steven Schveighoffer:
I don't think this is a very good idea. The code should likely
build with the latest released compiler.
Oh, if you want to help rosettacode efforts, then try to fix this
entry:
http://rosettacode.org/wiki/Parallel_calculations#D
Bye,
bearophile
Walter Bright:
I've recently seen some academic research PDF's where the font
is so small that even if I go full screen on them they are very
hard to read.
Some combinations of PDF readers and PDF files support reflow, so
later you can also increase the zoom. Another solution is to buy
a
Walter Bright:
Pointing out these issues is exactly what @nogc is designed to
do.
Using @nogc is like putting your code under a newly invented
microscope, it allows to see things that I missed before :-)
Bye,
bearophile
Dicebot:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a core language
feature.
This problem was underlined during
This is one of the largest problems left in the implementation of
D purity:
https://issues.dlang.org/show_bug.cgi?id=9148
One example of the refused code:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
}
void main() {}
Bye,
bearophile
Walter Bright:
The @nogc logic is entirely contained in the front end, and is
not affected by back end logic.
Thank you for your answer and sorry for me being sometimes too
much nervous.
So the problem I was alarmed about doesn't exists.
Some time ago I have filed this ER:
Walter Bright:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions
and declarations in namespaces. Currently, there is no support
in D to call C++ functions in namespaces. The primary issue is
that the name mangling doesn't match. Need a simple and
Jonathan M Davis:
However, I'm not sure that treating it as weakly pure buys
us anything except in the case where we're trying to make
the outer function pure as well.
Here is a bit more realistic example of the problem, currently
this (rather common) code doesn't compile:
import
If I am not missing some more point, what is the best solution?
Before this question gets lost, I'd like to receive some kind of
answer.
Thank you,
bearophile
Walter Bright:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
It looks worse, so
ketmar:
this code: std.conv.parse!byte(-128) throws error: Overflow
in integral conversion. but this is obviously not true, as
signed byte can hold such value.
the question is: is it bug, or it's intended behavior to limit
signed integrals to values which can be safely abs()ed?
This code
Andrei Alexandrescu:
Destruction is as always welcome. I plan to get into tracing
tomorrow morning.
How easy is to implement a OS-portable (disk-backed) virtual
memory scheme using std.allocator? :-) Is it a good idea to
include one such scheme in std.allocator?
Bye,
bearophile
Andrei Alexandrescu:
I just added MmapAllocator:
http://erdani.com/d/phobos-prerelease/std_allocator.html#.MmapAllocator
If anyone would like to add a Windows implementation, that
would be great.
So it's not using this portable module?
http://dlang.org/phobos/std_mmfile.html
Bye,
Andrei Alexandrescu:
- zeroesAllocations is true if the allocator automatically sets
freshly allocated memory to zero
In some cases there is a need for a certain zeroing, even when
memory is deallocated:
https://issues.dlang.org/show_bug.cgi?id=10661
This can be added.
In some case there
Chris:
Especially in the scientific community Python is popular
because one can protoype very fast, test things etc. However,
as the code base grows it becomes more and more obvious that
Python is too slow and doesn't scale very well.
Julia seems to be gaining many users, it's a language
Paulo Pinto:
Pascal expatriates like myself won't consider indexes from 1 a
design mistake. :)
What's the good of having all arrays always start from index 1
(this is different from Ada, where you can choose the indexing
range and type)?
Bye,
bearophile
Nick Sabalausky:
VB6 let you choose your starting index, too. It was rarely
useful and constantly made array-handling code a pain in the
ass. Of course, VB made pretty much everything a PITA...(I used
to work at a VB6 house. *shudder*)
(As far as I know, and I am ignorant about Julia) in
Andrea Fontana:
If I'm right, index should be a compile-time value.
Right. Because tuples in general don't contain N values of the
same type (as in your case), so the compiler has to know
statically the index to compute their position efficiently.
Further similar questions are better
Through Reddit I've found a nice blog post, Using Static
Analysis And Clang To Find Heartbleed:
http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/
The part about the range analysis is nice:
Ranges of symbol values:
conj_$2{int} : { [-2147483648, -2],
John Colvin:
Any reason why this needs language support? I haven't tried it,
but I can't see why it can't be trivially done in a library.
I don't yet know the answer. I have to think more about the
topic, and to try to implement something in library code. And
then I can judge (a bit) if the
Steven Schveighoffer:
On Tue, 15 Apr 2014 13:46:11 -0400, bearophile
What do you think are the reasons I suggested the enhancement
for?
To make people write code the way you like? :)
Honestly, it's like you require someone to call a function like:
T foo(T)(T t){return t;}
Just so you can
Andrei Alexandrescu:
On 4/29/14, 11:08 AM, bearophile wrote:
In Phobos there are awkward names like walkLength
Love it. -- Andrei
The name like walkLength was chosen (by you?), instead of a
more natural name like length (or even a nice, short, clean,
readable, handy and easer to write
Nick Sabalausky:
On 4/29/2014 9:38 PM, Narrator wrote:
fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self
That looks like line noise.
In D there is a lambda syntax:
auto F = (in int x) = x ^^ 2;
void main() {
int y;
auto G = (in int x) = x + y;
pragma(msg, typeof(F));
Below you can find some musings, that perhaps just show my
ignorance of C++11.
The topic is partially related to the of C++11:
http://en.wikipedia.org/wiki/C%2B%2B11#Rvalue_references_and_move_constructors
Sometimes I have to compute hash digests, or to return small but
fixed amounts of data
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in
parallel
In D we have strong purity to make more safe to run code in
parallel:
pure unittest {}
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional
Andrei Alexandrescu:
Subsequently the GC should be within its rights to deallocate
any memory within the first and last 250 integers allocated,
even though in theory the user may get to them by using pointer
arithmetic.
Such use of point arithmetic is not uncommon.
I think the current GC
monarch_dodra:
If we do name the unittests, then can we name them with
strings? No need to polute namespace with ugly symbols.
Are UDAs enough?
@uname(foo) unittest {}
What I'd like is to tie one or more unittests to other entities,
like all the unittests of a specific function.
Bye,
Andrei Alexandrescu:
Where does 90% come from? On the contrary, it seems to me
unique references are rather rare and fleeting. -- Andrei
I think unique references (linear types) are used rather commonly
among the reference types of Rust.
Bye,
bearophile
Walter Bright:
Actually, I think inference of the ability to implicitly and
safely convert from mutable to immutable or shared to be very
powerful. I also think it is superior than requiring the user
to add ever more annotations, which some research (and my
experience) shows that users are
Andrei Alexandrescu:
We're considering deprecating ~this() for classes in the future.
Such changes could happen in parallel to the (planned?) removal
of some of the methods of Object.
Bye,
bearophile
Walter Bright:
On 4/30/2014 8:54 AM, bearophile wrote:
I'd also like some built-in way (or partially built-in) to use
a module only as
main module (to run its demos) or as module to be imported.
This problem is
solved in Python with the if __name__ == __main__: idiom.
dmd foo.d
marwy:
There are two threads that came up lately, where people compare
their language's speed.
1) http://codegolf.stackexchange.com/q/26323
2) http://codegolf.stackexchange.com/q/26371 (this one is newer)
Both of them still lack the D lang.
Anyone up for a little pissing contest? ;-).
And a D solution for the second contest, still for LDC2 compiler,
translated from C++ code by ilmale:
http://dpaste.dzfl.pl/f029aa2c0a46
Timing comparisons are welcome.
Bye,
bearophile
Temtaime:
I think it's need to have -w64(or other name, offers ?) flag
that warns if code may not compile on other archs.
It's a problem and I'd like some way to compiler help solving
such problems.
I suggested this, that was refused (I don't remember who reopened
it):
Walter Bright:
You've already got it working with version, that's what version
is for. Why add yet another way to do it?
Because I'd like something better. It's an idiom that I have used
many times (around 15-20 times). I'd like the compiler (or build
tool) to avoid me to specify two times
Temtaime:
I think it's need to have -w64(or other name, offers ?) flag
that warns if code may not compile on other archs.
Some of the things it has to guard against:
void main() {
size_t x;
ptrdiff_t y;
uint r1 = x; // warn
int r2 = x; // warn
uint r3 = y; // warn
Any one interested in writing a little paper about D language
used for medium-integrity software systems? :-)
http://lambda-the-ultimate.org/node/4943
http://sigada.org/conf/hilt2014/
While D isn't Ada, I think it's plenty better than using C plus
the handcuffs
Idan Arye:
today I've seen a question in Stack Exchange's Programmers
board that raises a point I don't recall being discussed here:
This program:
class A {
immutable int x;
this() {
foo();
x = 1;
x = 2;
}
void foo() {
auto y = x;
}
}
void
Jonathan M Davis:
Idan Arye:
We are all sick and tired of this debate, but today I've seen a
question in Stack Exchange's Programmers board that raises a
point I don't recall being discussed here:
Yeah, I brought this up before, and it's one of the reasons why
I'm against non-nullable by
Paulo Pinto:
http://cgo.org/cgo2014/conference/program/
Very nice, thank you. Will read.
Bye,
bearophile
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language visible.
Here are my solutions:
Suliman:
Here on Forum I had found 2 interesting link. I decided to put
it's here. Maybe it would be helpful
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
Meta:
Your C++ translation: ~277ms
Your second version: ~2.34ms/round
Both D programs are translations of C++ programs.
LDC might do a better job with this.
I have developed those two programs using ldc2, so the usage of
ldc2 is encouraged, and inlining is necessary for both programs.
The Nimrod version partially unrolls the recursion 4 times. How
hard is this to do in D?
http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge
Bye,
bearophile
Paulo Pinto:
http://cgo.org/cgo2014/conference/program/
I like the Partial escape analysis for Java (the compiler doesn't
heap allocate an object only in the most frequent code paths
inside a function), and optimization usable for D too:
If we keep class destructors in D, is it a good idea to require
them to be @nogc?
This post comes after this thread in D.learn:
http://forum.dlang.org/thread/vlnjgtdmyolgoiofn...@forum.dlang.org
Bye,
bearophile
Walter Bright:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
If I am not wrong, all this is needed here is a boolean
compile-time flag, like __is_main_module. I think this is a
small
Jonathan M Davis:
Just because something is done in
python does not mean that it is appropriate for D or that it
requires adding features to D in order to support it.
I agree. On the other hand now I have years of experience in both
language and I still have this need in D.
It makes no
Jonathan M Davis:
Honestly, I wouldn't even consider distributing something that
was only a
single module in size unless it were on the scale of
std.datetime, which we've
generally agreed is too large for a single module.
So, a single module
wouldn't have enough functionality to be worth
Meta:
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package
as easy as editing a JSON file (and it scales such that you can
download a project of any size this way).
Having package manager(s) in Python doesn't make
Andrei Alexandrescu:
I think the needs to support BigInt argument is not a blocker
- we can release std.rational to only support built-in
integers, and then adjust things later to expand support while
keeping backward compatibility. I do think it's important that
BigInt supports appropriate
Andrei Alexandrescu:
So I'm looking at creation functions and in particular creation
functions for arrays.
1. Follow the new int[n] convention:
auto a = allok.make!(int[])(42);
assert(a.length == 42);
assert(a.equal(repeat(0, 42));
2. Follow the [ literal ] convention:
auto a =
Adam D. Ruppe:
I guess if it takes an input range with lengths though it could
just as well do alloc.make(repeat(0).take(45))
This is OK if make recognizes the repeat.take type statically
and uses this information to allocate the array efficiently. In
general such pattern recognition tricks
Adam D. Ruppe:
I don't think it needs any special beyond hasLength!T so it can
allocate it all in one go, so it wouldn't be specialized on
Take specifically, just anything with an explicit length
property.
If you know that the item is always the same (coming from a
repeat) can't you
Paulo Pinto:
Java Azul VM GC was already handling 1 TB in 2010.
http://qconsf.com/sf2010/dl/qcon-sanfran-2010/slides/GilTene_GCNirvanaHighThroughputAndLowLatencyTogether.pdf
GC is not the only way of doing automatic memory management, but
this ongoing discussion steams more from D's current
Brad Anderson:
I like Adam's input range idea. It gives you the best of both
worlds, I think. It clears the conflict between ints and lengths
using an interface.
I don't like it a lot. I think I'd like two differently named
functions. I am not sure.
One last thought. If array() accepted
Mason McGill:
Other implementations can choose to always evaluate it to .
Other implementations have to give the ddostring as well.
In D modules too have a ddoc string.
Regarding comments on single variables, like this, I think they
can be ignored for the moment, and added later with the
Paulo Pinto:
You can think of Julia as a dynamic language similar to Python,
with optional typing and for such a young language, a quite
good JIT compiler backed by the LLVM backend.
Unlike dynamic languages, at running time all variables are
strongly typed.
Bye,
bearophile
Chris:
That would increase the security during runtime (plugins,
libraries, crackers).
Yes, and also gives almost native performance.
Bye,
bearophile
Dejan Lekic:
One can argue that every modern JIT achieves almost native
performance ...
OK. Then for Julia remove the almost :-)
Bye,
bearophile
1 - 100 of 1477 matches
Mail list logo
