Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Ola Fosheim Grøstad: So, it will just fade way in the sea of JavaScript wannabe replacements. Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next. Perhaps next some kind of blend of Typescript and Dart will become part of a next JavaScript update :-) Bye, bearophile
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Ola Fosheim Grøstad: Downplaying other languages makes the D crowd look desperate... That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile
Re: let (x,y) = ...
Kagamin: Doesn't let normally declare a new variable? You are right, yours is a valid point... So tie could be a better name after all. Bye, bearophile
Re: let (x,y) = ...
Ola Fosheim Grøstad: Maybe change the name to tie: http://www.cplusplus.com/reference/tuple/tie/ ? I prefer let, it's much more traditional and descriptive. C++ standard library is often a bad example to follow... Bye, bearophile
Re: let (x,y) = ...
Mengu: that's a great example to show d's strength. thank you. It's also a great way to show what's missing in D syntax. Bye, bearophile
Re: let (x,y) = ...
Kagamin: Or even more obvious (VBA,TSQL): set (x,y,z) = [1,2,3]; I prefer to use set as in Python, to define sets: s = set([1, 2, 3]) 2 in s True Bye, bearophile
Re: This Week in D: Issue #4
It it a good idea to keep a weekly rhythm? Perhaps one issue every two, three or even four weeks is better at this stage of the D life. Bye, bearophile
Re: This Week in D, issue 1
Adam D. Ruppe: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html Seems good. Major Changes = They are weekly, so perhaps Changes is enough. If you can, add two or three little images to the page, like here: https://sergeytihon.wordpress.com/category/f-weekly/ Bye, bearophile
Re: D idioms list
ponce: I'm not familiar with the terse, range-heavy, UFCS style that has emerged from Phobos In Rosettacode I have inserted tons of examples of that coding style. An example, given a tuple of arbitrary length, with items all of the same type, how do you compute the total of its items? The last way I've invented is: myTuple[].only.sum It's also @nogc. But it causes a little of template bloat. Bye, bearophile
Re: GCCJIT Bindings for D
Iain Buclaw: Sure, what is that supposed to do? Iain. To print a classic image of the Mandelbrot Set (but Codepad seems down currently). Bye, bearophile
Re: GCCJIT Bindings for D
Iain Buclaw: 1.086s: bfgccjitd-runtime-O2 1.139s: bfgccjitd-runtime-O1 2.759s: bfgccjitd-O1 3.646s: bfgccjitd-O2 4.959s: bff-O2 Five times faster than bff is a lot :-) My best timings are usually around two times faster than bff. I guess gccjit is not an average JIT-tter. Bye, bearophile
Re: GCCJIT Bindings for D
Iain Buclaw: For a more practical example, I've added an example jit compiled brainf*** interpreter. https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d Here I have put a little program you can use as performance benchmark: http://codepad.org/hogVnlIS Bye, bearophile
Re: bessel[IJKY] functions
Ilya Yaroshenko: Ported from r-project: http://code.dlang.org/packages/bessel If you like to write the full path like std.math.isNaN, then you can also use static imports. Perhaps it's worth adding pre/post-conditions to the functions. The indentations probably have a mix of tabs and spaces and seem messed up. Is gamma_cody better/worse than std.mathspecial.gamma? Bye, bearophile
Re: forum.dlang.org is now using DCaptcha
Vladimir Panteleev: http://wiki.dlang.org/extensions/DCaptcha/demo.php Very nice, we can help spammers learn some D and become some day valid D developers :-) Bye, bearophile
Re: D is for Data Science
Tomer Rosenschtein: Awesome article. Paper of the week is a modest word for this. The D code is not good. Bye, bearophile
Re: D is for Data Science
CraigDillabaugh: Maybe not good by the standards of this group, but it does represent the efforts of someone doing 'real work', so I think it is worthwhile. Perhaps part of the cause of the low quality of the code in that blog post is the design of D language is not bondage enough. This worries me a little, because most D code I see in the wild is not good, and looks more like a Java/C++ mix. In Python culture there is a stronger pressure to write Pythonic code similar to Python code written by all other Python programmers. In the Go culture this is even stronger, there's even only one standard way to format code, and the language is simpler so there is less possibility for usage of alternative constructs (while in D you have often five ways to shoot the foot). From what I've seen the Rust culture is more bondage than D culture, in both surface look of code, and idioms, and I think this is good. Bye, bearophile
Re: D is for Data Science
weaselcat: I see array.sort is planned for future deprecation, what does future fall under? For us that activate warnings in dmd (because for a design mistake they are disabled on default, but hopefully this will be fixed in future) in the latest github version of the compiler it gives a warning if you use the built-in sort and reverse. Unfortunately the library reverse still needs to be fixed to return the array as the built-in reverse. Bye, bearophile
Re: D is for Data Science
Dmitry Olshansky: Why is File.byLine so slow? Seems to be mostly fixed sometime ago. Really? I am not so sure. Bye, bearophile
Re: D is for Data Science
Dmitry Olshansky: Which is 1:1 parity. Another myth busted? ;) There is still an open bug report: https://issues.dlang.org/show_bug.cgi?id=11810 Do you want also to benchmark that byLineFast that for me is usually significantly faster than the byLine? Bye, bearophile
Re: dfix 0.1.1
Brian Schott: https://github.com/Hackerpilot/dfix Sounds like a very good start :-) Bye, bearophile
Re: DMD v2.066.1-rc2
Andrew Edwards: The second release candidate for v2.066.1 is now available for testing. Binaries may be obtained at http://wiki.dlang.org/Beta_Testing/. Happy testing. In the site there is a link named DMD v2.067.0-b1. Perhaps it should be named DMD v2.067.0-a1 because it's an alpha version. Bye, bearophile
Re: Multiple alias this is coming.
IgorStepanov: I've created pull request, which introduces multiple alias this. Can someone show one or more usage cases? Thank you, bye, bearophile
Re: Multiple alias this is coming.
IgorStepanov: Do you ask about alias this or about it multiple usage. Multiple usage is similar to single, but multiple:) I meant the multiple usage. And none of your examples here are use cases :-( I'd like to see one use case, or more. Bye, bearophile
Re: Damncheck - a property-based testing library
George: I was hoping to get some feedback from the community regarding the quality of the code and if something can be written the D-way. I have also written a blog post about the process (http://blog.zakhour.me/post/d/damncheck-on-building-a-property-based-testing-library-for-d/) Eventually a QuickCheck-like library needs to become standard tool used to test most D projects. There are many other related ideas, like: http://www.cse.chalmers.se/~nicsma/quickspec.pdf Bye, bearophile
Re: D for the Win
Mike: Then I add change only #6 above, and remove the excessive function attributes, Maybe I'll make a pull request for it. I don't think users should have to decorate their code like a Christmas tree I don't agree, function attributes are not excessive, they are idiomatic in D. Bye, bearophile
Re: Fix #2529: explicit protection package #3651
Dicebot: All I want is that whatever decision Walter makes to happen sooner than in few years from now. There are other pending patches, like the support for the nice [$] syntax by Kenji. I keep thinking there's gotta be a way to do this without language changes. or I keep thinking there must be a better way than [$]. are the kind of standard answers Walter gives when he doesn't have time to think about some design (because he has time he usually needs only hours or very few days to implement features, like when he made UDAs or C++ namespeces). So I guess Walter is currently busy with something (like finishing the 2.066 release and its regressions, or developing Warp for Facebook, or something else), so you have to wait some time for him to come back to the language development side, to receive a good answer and a good solution. Bye, bearophile
Re: D for the Win
Andrei:
http://tomerfiliba.com/blog/dlang/
struct PascalString {
Field!ubyte length;
Also see if UDAs plus compile-time introspection is helpful.
auto stream = cast(ubyte[])\x05hello.dup;
Perhaps this is enough, and avoids one allocation:
immutable stream = \x05hello.representation;
Bye,
bearophile
Re: D 2.066 is out. Enjoy!
Vladimir Panteleev: I agree, I am also surprised that 2.066 was released despite the regressions. There is an apparently endless stream of regressions, I have found another today (https://issues.dlang.org/show_bug.cgi?id=13321 ). I think D is not yet at the stage of its development where it can hope to fix all the regressions. So if you try to wait for all regressions to be fixed, you never ship a compiler version, and this has serious disadvantages. So better to be a little more practical for now. 2.066 has took ages to come out, it was overdue. I hope 2.067 will come out much quicker. Bye, bearophile
Re: COFF support for Win32 merged
Jacob Carlborg: A pull request [1] by Rainer Schuetze which adds COFF support for Win32 has recently been merged by Walter. It seems to be enabled using the -m32mscoff flag. I have just recompiled dmd, but I don't see that new compiler switch (dmd 2.067). I am compiling in a wrong way? Bye, bearophile
Re: COFF support for Win32 merged
ketmar: are you sure that you compiled dmd for 32-bit windows? other versions seems to not have this flag. Yes, I am using a 32 bit Windows. Bye, bearophile
Re: COFF support for Win32 merged
ketmar: are you sure that you have latest git then? yes, i know that this is very silly question, but sometimes... ;-) OK, -m32mscoff works (probably I was using a wrongly written switch), but I don't see it listed among the other compiler switches. Bye, bearophile
Re: COFF support for Win32 merged
Andrei Alexandrescu: schwartzSort comes to mind -- Andrei forgot the smiley :o) -- Andrei Yeah that's an infamous example. Standard libraries should avoid too much hard to write identifiers. Bye, bearophile
Re: DConf 2014 Lightning Talks
Ali Çehreli: Ali Çehreli's (first speaker) slides are at http://acehreli.org/AliCehreli_assumptions.pdf It's a nice slides pack. Now in Phobos there's also assumeUTF (https://d.puremagic.com/issues/show_bug.cgi?id=10162 ). See also: https://issues.dlang.org/show_bug.cgi?id=9682 It essentially asks two functions (group and filter) to return a SortedRange if the input is a SortedRange, because those two functions don't change the items order. In Haskell you do such things using rewrite rules (https://www.haskell.org/ghc/docs/7.0.1/html/users_guide/rewrite-rules.html ). Those are two examples of conservation of assumptions (invariants). assumeUnique returns an immutable instead of a Unique!T struct. So after calling assumeUnique you can't mutate the items. An Unique!T wrapper (like std.typecons.Unique) allows you to mutate the items if the needs arises but also to keep their property of having no shared references. Some functions like sort() are able to conserve the property of uniqueness, so sorting an array of Unique should return a SortedRange!(Unique!T[]) or something like that. Another assumption that could be useful for Phobos is assumeAligned!(T[], 16), that specifies the assumption that a specific slice has its first item aligned to 16 bytes. This could be useful if you use SIMD instructions (time ago I have even suggested to put such array alignment inside the D type system, but I didn't raise much enthusiasm). Bye, bearophile
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Don: I think that approach is more convincing for functional languages than for D, especially if you are limited to a single return type. Hopefully someday we'll have good enough tuples in D (including their destructuring), this is similar to having multiple return values. Bye, bearophile
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Andrei Alexandrescu:
Just read the slides, very interesting.
There are many papers, books and articles around that explain the
same things, but that explanation is easy to understand even for
people not used to functional programming (as I still partially
am).
I think it would be interesting to experiment with an
Expected!T that holds an Algebraic!(T, Exception) as state,
In those slides as other member of the sum type they have used an
enumeration of possible error conditions (or at first even just
strings of the error messages), sometimes augmented with more
information, like:
| EmailNotValid of EmailAddress
| DbAuthorizationError of ConnectionString * Credentials
| SmtpTimeout of SmtpConnection
| SmtpBadRecipient of EmailAddress
template bind(alias fun) { ... }
such that given a function e.g.
int fun(string a, double b);
bind!fun is this function:
Expected!int bind!fun(Expected!string a, Expected!double b) {
if (a.sux || b.sux) return composeExceptions(a, b);
return fun(a.rox, b.rox);
}
There would also be bindNothrow:
Expected!int bindNothrow!fun(Expected!string a, Expected!double
b) {
if (a.sux || b.sux) return composeExceptions(a, b);
try return fun(a.rox, b.rox);
catch (Exception e) return e;
}
One of the main points of using those two railways is to avoid
exceptions.
but of course built-in tuple syntax and basic forms of pattern
matching
in switch (https://d.puremagic.com/issues/show_bug.cgi?id=596
) improve
the syntax and make the code more handy, handy enough to push
more D
programmers in using it.
No :o).
Are you saying you don't want built-in tuples and that you also
don't agree with the proposal in issue 596 and that you don't
agree that a better syntax doesn't make monads like those
actually handy to use? I don't understand what's controversial in
what I have written there.
From a syntax point of view issue 596 asks for an optional
onMatch method, and if you want a syntax to create variables in
switch cases. Plus support for structs and classes as variables
to switch on.
The use of Algebraic, Nullable and Expected is very different
(and safer) if you use them through pattern matching. The point
is not to ape the functional languages: currently in D Nullable
is not much safer (and not more handy) than using a null pointer.
Bye,
bearophile
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/ Despite Walter is used to pipeline programming, so the next step is to also handle failures and off-band messages in a functional way (without exceptions and global error values) with two parallel pipelines, here named Railway-Oriented Programming. This is one of the simplest introductions (and he can skip the slides 19-53) that I have found of this topic (that in the Haskell community is explained on the base of monads): http://www.slideshare.net/ScottWlaschin/railway-oriented-programming In Bugzilla there are already requests for some Railway-Oriented Programming: https://issues.dlang.org/show_bug.cgi?id=6840 https://issues.dlang.org/show_bug.cgi?id=6843 I think no language extensions are needed for such kind of programming, but of course built-in tuple syntax and basic forms of pattern matching in switch (https://d.puremagic.com/issues/show_bug.cgi?id=596 ) improve the syntax and make the code more handy, handy enough to push more D programmers in using it. For some examples of those things in a system language, this page shows some little examples of functional syntax for Rust: http://science.raphael.poss.name/rust-for-functional-programmers.html Bye, bearophile
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Despite Walter is Sorry, I meant to write, Now Walter is... Bye, bearophile
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
The talk was nice, and it's the chance I was waiting to ask a question to the speaker. I've read a very nice paper (+ slides) about using some specialized but simple type system rules to make less bug-prone the bit-twiddling kind of code, Bit-Level Types for High-Level Reasoning by Ranjit Jhala, Rupak Majumdar: http://goto.ucsd.edu/~rjhala/papers/bit_level_types_for_high_level_reasoning.html I'd like to use those ideas in D, they are useful for low-level or embedded programming. The D type system (and D syntax) seem enough to implement most of them without changes to the D language (or with small changes, but you can't tell before you have tried implementing them with the current language). So are those things a good addition to Phobos for your kind of programming? (additions to the language can be discussed later). Bye, bearophile
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
So are those things a good addition to Phobos for your kind of programming? (additions to the language can be discussed later). You can look at the slides for a quicker overview, or you can ask me here for a summary, if necessary. Bye, bearophile
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: Anyway, here's my thinking behind the opCall idea. One of the major shifts of the move to classes is that, suddenly, all of these entities have to be explicitly allocated. So creating a random number generator can't be @nogc? Bye, bearophile
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: What really matters to me is stuff like Sample and Cover, where we can readily expect that they may be called in inner loops of the program, and so having lots of allocations via new would be a big problem. So, it follows that the current helper functions (sample, cover, etc.) need to be rewritten at some point with this in mind. I think @nogc is a good improvement for D, despite Walter and other people (and I think Don) were very sceptical about it, because it's like a new lens that allows me to see important things about my code that I wasn't able to see before. Phobos has to be modified in many places to allow both usage patterns for people that want to write short clean code (that allocates automatically and lets the GC free), and performance-conscious people that need to avoid most or all heap allocations. What's unfortunate is that the @nogc attribute was not present for lot of time of development of Phobos, so several Phobos things now need to be modified and some old APIs could give problems. std.random2 should offers ways to be used as much as possible from @nogc code, see below. It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run. Even if the 1.0.0 release of std.random2 is not much @nogc, in my opinion it needs to have an API designed to allow it to be retrofitted cleanly and nicely for @nogc usages too. do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ? Preferably in a way that avoids the user having to explicitly indicate destruction? If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators. Bye, bearophile
Re: core.checkedint added to druntime
Walter Bright: https://github.com/D-Programming-Language/druntime/pull/839 Why aren't functions with ubyte/byte/short/ushort arguments included? -- Here Lionello Lunesu has suggested a __traits(valueRange, expression) for built-in values: http://forum.dlang.org/thread/lnrc8l$1254$1...@digitalmars.com Once such trait is working on checkedint values, can this help the compiler remove some useless tests and increase the performance of checked ints? it can be used to implement multi-precision integer arithmetic types. It looks very useful for the small value optimization for BigIntegers, to not allocate on the heap when the numbers are small, and switch to the heap allocation when they grow. If you use such improved bigintegers to write code that is not supposed to overflow the range of normal integers, you obtain code that is only moderately slower than using checkedints, but it also gives the correct results if some overflow has occurred :-) Bye, bearophile
Re: core.checkedint added to druntime
Walter Bright:
Because there is no ubyte/byte/short/ushort math in C, C++ or
D. There is only int/long math.
A little of ubyte math is present, perhaps for this you add
uinc, sinc, udec, sdec functions to core.checkedint that
support ubyte/byte/short/ushort types too:
void main() {
ubyte x = 100;
x++;
}
But you are right, in D if you sum two ubytes you get an int:
void main() {
ubyte x = 100;
ubyte y = 200;
pragma(msg, typeof(x + y)); // Prints int
}
Yet sometimes you want to perform safe math operations on
ubytes/bytes/shorts/ushorts, and keep the same type for the
results. So I presume a future Phobos Safe math based on
core.checkedint will need to check the ranges by itself, to allow
checked assignments back to the same types:
void main() {
Safe!ubyte x = 100;
Safe!ubyte y = 200;
Safe!ubyte z = x + y;
}
Bye,
bearophile
Re: DMD 2.066 Alpha
Steven Schveighoffer:
To that end, I thought we were moving towards a more scalable
solution: like !final or final!false or final(false), which
could be nice for metaprogramming.
This is a small problem:
void foo(in int x) {
auto y = x;
y++; // error
}
The current solution is long, requires a cast and is not fully
DRY (the 'x' name is repeated twice):
import std.traits;
void foo(in int x) {
Unqual!(typeof(x)) y = x;
y++;
}
!const is useful here (I assume !const to be the same as
!immutable):
void foo(in int x) {
!const y = x;
y++;
}
Bye,
bearophile
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
Dmitry Olshansky: Unless things improve dramatically CTFE code generation + An alternative and much faster JITter for LLVM, something like this could make CTFE on LDC2 very quick: http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/fast-jit-code-generation.pdf Bye, bearophile
Re: K-Nearest Neighbor + pointger alignments
Ali Cehreli:
I wonder what bearophile's response will be. ;)
Despite looking like a silly sequence of optimizations, I do have
some general comments on that text. Thanks to Kenji
(https://github.com/D-Programming-Language/dmd/pull/3650 ) this
code is now valid:
void foo(size_t N)(ref int[N] b) if (N == 4) {}
void main() {
int[5] a;
foo(a[1 .. $]);
}
The D type system is able to understand that if you slice away
the first item of an an array of 5 items, you produce a pointer
to an array of 4 items.
But the D static typing is not very strong (precise), D is not
yet using all the fruits given by static typing.
D throws away the compile-time knowledge about pointer
alignments, so if you write code like this without the 7 shorts
of padding, the program crashes at run-time, because of
misalignment:
uint distance(immutable ref short[nCols - 1] p1,
immutable ref short[nCols - 1] p2)
pure nothrow @nogc {
alias TV = short8;
enum size_t Vlen = TV.init.array.length;
assert(p1.length % Vlen == 0);
immutable v1 = cast(immutable TV*)p1.ptr;
immutable v2 = cast(immutable TV*)p2.ptr;
TV totV = 0;
foreach (immutable i; 0 .. p1.length / Vlen) {
TV d = v1[i] - v2[i];
totV += d * d;
}
uint tot = 0;
foreach (immutable t; totV.array)
tot += t;
return tot;
}
TLabel classify(immutable short[nCols][] trainingSet,
immutable ref short[nCols - 1] pixels)
pure nothrow @nogc {
auto closestDistance = uint.max;
auto closestLabel = TLabel.max;
foreach (immutable ref s; trainingSet) {
immutable dist = pixels.distance(s[1 .. $]);
if (dist closestDistance) {
closestDistance = dist;
closestLabel = s[labelIndex];
}
}
return closestLabel;
}
In this program there is all the information necessary to compute
simply at compile-time the alignment of v1 and v2 and generate a
compile-time error if you try to perform SIMD operations using
such unaligned pointers. I don't like D to throw away static
information that can be used to avoid run-time crashes, this is
the opposite of what is usually called a safe language.
D type system is able to keep the length of arrays at
compile-time, allowing data types like ushort[N], but in a system
language that allows such simple usage of SIMD with core.simd
it's also useful to encode in the pointer/array type the
alignment.
So this code should not compile:
uint distance(immutable ref short[nCols - 1] p1,
immutable ref short[nCols - 1] p2)
pure nothrow @nogc {
alias TV = short8;
enum size_t Vlen = TV.init.array.length;
assert(p1.length % Vlen == 0);
immutable v1 = cast(immutable TV*)p1.ptr;
immutable v2 = cast(immutable TV*)p2.ptr;
TV totV = 0;
foreach (immutable i; 0 .. p1.length / Vlen) {
TV d = v1[i] - v2[i];
totV += d * d;
While this should compile:
uint distance(immutable ref align(16) short[nCols - 1] p1,
immutable ref align(16) short[nCols - 1] p2)
pure nothrow @nogc {
alias TV = short8;
enum size_t Vlen = TV.init.array.length;
assert(p1.length % Vlen == 0);
immutable v1 = cast(immutable TV*)p1.ptr;
immutable v2 = cast(immutable TV*)p2.ptr;
TV totV = 0;
foreach (immutable i; 0 .. p1.length / Vlen) {
TV d = v1[i] - v2[i];
totV += d * d;
And now this function that calls distance should not compile:
TLabel classify(immutable short[nCols][] trainingSet,
immutable ref short[nCols - 1] pixels)
pure nothrow @nogc {
auto closestDistance = uint.max;
auto closestLabel = TLabel.max;
foreach (immutable ref s; trainingSet) {
immutable dist = pixels.distance(s[1 .. $]); // error
And now this should compile:
TLabel classify(immutable align(16) short[nCols][] trainingSet,
immutable ref align(16) short[nCols - 1] pixels)
pure nothrow @nogc {
auto closestDistance = uint.max;
auto closestLabel = TLabel.max;
foreach (immutable ref s; trainingSet) {
immutable dist = pixels.distance(s[8 .. $]);
And this should compile because std.file.read returns memory
allocated by the GC that is align(16):
align(16) immutable(short[nCols])[] readData(size_t nCols)(in
string fileName) {
return cast(typeof(return))std.file.read(fileName);
}
Where the alignment is not known at compile-time the D compiler
could add run-time alignment asserts in debug builds, to give
nice run-time error messages.
The simpler int[4] or int[] types are still valid and usable,
they could be align(1). If you think of them as align(16) you are
writing faith-based code when you use SIMD instructions.
Automatic variables (stack-allocated) too could allow alignment
annotations (perhaps ldc2 is already supporting this syntax):
void main() {
align(16) ubyte[60] ubs;
}
I discussed this topic another time in past:
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: Thanks in advance for all testing and feedback. I have appreciated to use this generator (but I am not yet sure how much good it is. I have seen it's fast and sufficiently good for some of my simpler purposes): http://en.literateprograms.org/R250/521_%28C%29 -- Is it worth having a fully pure generator that takes a constant state and returns the modified state? (The state should be small, so Mersenne Twister is not fit for this). Writing such generator is easy, but then how do you use it with the API of the functions of the random module? Bye, bearophile
Re: hap.random: a new random number library for D
Kagamin: Pass it by reference, I see no reason why MT can't be pure. I meant strongly pure :-) Bye, bearophile
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: However, I don't see any reason why one couldn't have a strongly pure function that purely transforms state, which could be wrapped by an RNG class So can you can generate random values in strongly pure functions with this? You can allocate the RNG class inside the function... If that's right, then is this simple strongly pure random generator worth adding to std.random2? Bye, bearophile
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
At about 40.42 in the Thoughts on static regex there is written even compile-time printf would be awesome. There is a patch about __ctWrite in GitHug, it should be fixed and merged. Bye, bearophile
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: Forgive me if I'm missing something obvious, but as it stands I don't see how the R250/521 algorithm you pointed me to can be strongly pure. Sorry, the R250/521 idea and the strongly pure idea are unrelated to each other. but wouldn't that be a memory allocation nightmare? For the strongly pure random generator we should choose a generator with a small internal state (let's say less than 5 CPU words, they get passed by immutable value). Bye, bearophile
Re: hap.random: a new random number library for D
Joseph Rushton Wakeling: I'll implement R250/521 for you, though. Please stop, I am not worth that, and I don't even know how much good that generator is. So for you it's better to focus on more important matters of the new random module. Extra generators can be added later if needed. It'd be interesting to see if this has any speed implications. Passing several cpu words by value for each generated value seems not very efficient. But this generator is for special situations, so a certain performance loss could be acceptable. And if the compiler is able to inline the functions, the data transfer overhead is removed, and most of the performance loss is restored (but I don't know if non-templated Phobos functions get inlined). Bye, bearophile
Re: Interview at Lang.NEXT
Burp: Do you also have so much testing code in haskell? I am still a newbie in Haskell, so my Haskell usage patterns are not significant (but if you still want an answer: from what I've seen so far I need so much time and thinking to craft every single line of Haskell code that later tests are less needed). Bye, bearophile
Re: Chuck Allison's talk is up
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/27e5d7/dconf_day_1_talk_3_a_real_d_in_programming/ The built-in can be deprecated. And the compromise solution is to return the result from the reverse() of Phobos. Sometimes breaking your the rules a little is the best thing to do. The Deque struct methods should be in camelCase (and possibly fulfill the range protocol). Bye, bearophile
Re: Interview at Lang.NEXT
Nick Sabalausky: to three lines of tests for every one line of real code is considered rapid development, My Python development is just development, it's not meant to be particularly rapid :-) And I don't think a 3:1 ratio is too much. Among the testing code I also count the doctests, the unittests, the other tests at higher level, the logic tests done with the Python version of QuickCheck, the contracts, the class/module invariants, the loop invariants, and the safety asserts spread in the code. Take a look at this: http://www.sqlite.org/testing.html As of version 3.8.0, the SQLite library consists of approximately 84.3 KSLOC of C code. (KSLOC means thousands of Source Lines Of Code or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1084 times as much test code and test scripts - 91452.5 KSLOC. In my D code I have an average 2.5 lines of testing code or every 1 line of D code, probably thanks to the stronger typing of D (and I think my D/Python code is less buggy than Phobos). Bye, bearophile
Re: Interview at Lang.NEXT
Meta: and there's always std.variant.Variant when you don't want to bother with them. How many good usages of D Variant do you know? Bye, bearophile
Re: Interview at Lang.NEXT
Adam D. Ruppe: Of course, sometimes the type still matters, Haskell programmers have a very different attitude toward types. They do a kind of type-driven programming, even in small programs. They lay down the data types (like the algebraic data types that describe the data structures of the problem), and then let the compiler, the type errors (and even a recent feature of the compiler named type holes) to write down the solutions and be guided toward correct code. This is kind of the opposite of trying to remove types using dynamic typing, and it's also far from the kind of strong static typing you see in Ada language. Bye, bearophile
Re: Interview at Lang.NEXT
Nick Sabalausky: In my experience, using heavy dynamic typing throughout a program creates far more work (mainly debugging) than it avoids. Even in tiny ~100 line programs, I've spent large amounts of time tracking down bugs a sane compiler would have immediately pointed out with a comparatively negligible amount of my effort spent on typing. I think often this happens because you are trying to write Python/Ruby code like you are using C++/Java, you assume the compiler will catch certain kinds of bugs. If you write Python with the kind of coding Python requires, taking more care of the things the Python interpreter is not able to spot for you, you will use much less time to debug Python code, and the overall coding time will be quite low. In Python you write 2-3 lines of tests every 1 line of code, and you test every functions for the corner cases you can think of. You don't write more than few 3-6 lines of code without testing them immediately. So for certain aspects you need more discipline to write Python, while for other things it needs less. For small and medium programs this leads to sufficiently correct Python code :-) It's usually quite hard to explain such differences in coding stile to people that are used to static typing. Bye, bearophile
Re: Real time captioning of D presentations
Walter Bright: what do you guys think? The caption I'd like to see is the name of the speaker during the live transmissions. Bye, bearophile
Re: Video of my LDC talk @ FOSDEM'14
Kai Nacke: In the same folder are also the videos of the other LLVM related talk. I have appreciated the An approach for energy consumption analysis of programs using LLVM talk, they even have an annotation that statically enforces a certain function to consume less than a specified amount of energy (expressed in pJ). The SPARK 2014: Hybrid Verification using Proofs and Tests talk is nice, but I have seen it already elsewhere. Bye, bearophile
Re: Video of my LDC talk @ FOSDEM'14
Walter Bright: Sigh, Windows can't open that file type. Install this: http://www.videolan.org/vlc/index.html Bye, bearophile
Re: DScanner is ready for use
Brian Schott: This is not valid. DMD and the grammar spec both do not allow this. This was changed weeks ago. Now D accepts that code. int items[5]; I don't support C-style declarations. DMD doesn't really support them either. (https://issues.dlang.org/show_bug.cgi?id=953) Then I suggest DScanner to support the half-C-declarations, because D compilers digests them just fine and they are very common in D code you will find in the wild. A code analyzer has to accept the real world code people write, otherwise it's much less useful :-) Bye, bearophile
Re: DScanner is ready for use
Brian Schott: You want tooling to support language features that aren't released? I think it's nice for a language tool to try to follow closely the improvements in the language. But you are right, the update rhythms of DScanner are left to you. Several people have indicated that they care about C-style declarations more than I do, and yet they still don't care enough to implement support for them and create a pull request. Sorry, I understand the feeling, I was just trying to help a little, underlying a missing part in DScanner. There are several open source projects I report bugs to, but I don't sent patched to. Bye, bearophile
Re: DScanner is ready for use
Brian Schott:
DScanner is a tool for analyzing D source code. It has the
following features:
...
https://github.com/Hackerpilot/Dscanner
I have just compiled it on Windows32 and tried it.
The compilation using the given bat has failed to link:
OPTLINK (R) for Win32 Release 8.00.15
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dscanner.obj(dscanner)
Error 42: Symbol Undefined
_D8analysis10ifelsesame15IfElseSameCheck6__ctorMFAyaZC8analysis10ifelsesame15IfElseSameCheck
dscanner.obj(dscanner)
Error 42: Symbol Undefined
_D8analysis12constructors16ConstructorCheck7__ClassZ
dscanner.obj(dscanner)
Error 42: Symbol Undefined
_D8analysis12constructors16ConstructorCheck6__ctorMFAyaZC8analysis12constructors16ConstructorCheck
dscanner.obj(dscanner)
Error 42: Symbol Undefined
_D8analysis10ifelsesame15IfElseSameCheck7__ClassZ
--- errorlevel 4
But I have built the DScanner successfully using the old bud
tool.
I have seen that this basic usage is not supported:
dscanner -s *.d
I have seen it doesn't support source code with unicode
identifiers or chars.
How do you enable/disable specific tests when you use -s?
This code gives four problems to Dscanner:
void main() {
auto x = float(5);
auto r = 1. + 2;
int items[5];
import std.stdio;
int.max.writeln;
}
In about 25_000 CLOC lines of my code DScanner has found several
usages of the old-style alias syntax, that I will fix. Plus it
has found three usages of the implicit string concatenation, and
two of them are (the same) bug! Andrei Alexandrescu was very
wrong to think that implicit string concatenation is a speck of
dust. I am not going to close down that enhancement request.
Bye,
bearophile
Re: Z80 Emulation Engine
ketmar:
sorry, it uses GDC @attribute(forceinline) feature, so you
need latest GDC to build it. it's not strictly necessary though
(speed optimizations?
Have you performed a benchmark with and without that attribute?
http://repo.or.cz/w/zymosis.d.git
In this kind of code computed gotos could help performance.
struct { ubyte c, b; };
Struct definitions in D don't end with the semicolon.
@property final void iff1 (int v) nothrow { riff1 = (v != 0); }
/** set interrupt flip-flop 1 */
I suggest to omit the space between the function name and its
arguments. And if you want you can also add an in:
... iff1(in int v) nothrow ...
{ rregR = ((rregR0x7f)+1)|(rregR0x80); }
Better to add spaces around those operators. And perhaps it's
better to use enum values instead of magic constants.
final void exec () {
ubyte opcode;
bool gotDD, trueCC;
int disp;
ubyte tmpB, tmpC, rsrc, rdst;
ushort tmpW = 0; /* shut up the compiler; it's wrong but
stubborn */
/* main loop */
while (rtstates rnext_event_tstate) {
if (rCallPager) pager();
if (rCheckBPs checkBP()) return;
rprevpc = rorgpc;
rorgpc = rpc;
/* read opcode -- OCR(4) */
opcode = fetchOpcode();
rprev_was_EIDDR = 0;
disp = gotDD = false;
rdd = rhl;
if (rhalted) { --rpc; continue; }
/* check for I[XY] prefix */
if (opcode == 0xdd || opcode == 0xfd) {
I suggest to add an empty line before the line of comment.
And I suggest to use 4 spaces as indent unit.
static __gshared ubyte parity_tbl[256];
Better to use the D syntax:
static __gshared ubyte[256] parity_tbl;
Bye,
bearophile
