Re: Efficiently streaming data to associative array
On Wednesday, 9 August 2017 at 10:00:14 UTC, kerdemdemir wrote:
As a total beginner I am feeling a bit not comfortable with
basic operations in AA.
First even I am very happy we have pointers but using pointers
in a common operation like this IMHO makes the language a bit
not safe.
Second "in" keyword always seemed so specific to me.
I think I will use your solution "ref Value
GetWithDefault(Value)" very often since it hides the two things
above.
You don't need this most of the time, if you already have the
correct type it's easy:
size_t[string][string] indexed_map;
string a, b; // a and b are strings not char[]
indexed_map[a][b] = value; // this will create the AA slots if
needed
In my specific case the data is streamed from stdin and is not
kept in memory.
byLine returns a view of the stdin buffer which may be replaced
at the next for-loop iteration so I can't use the index operator
directly, I need a string that does not change over time.
I could have used this code:
void main() {
size_t[string][string] indexed_map;
foreach(char[] line ; stdin.byLine) {
char[] a;
char[] b;
size_t value;
line.formattedRead!"%s,%s,%d"(a,b,value);
indexed_map[a.idup][b.idup] = value;
}
indexed_map.writeln;
}
It's perfectly ok if data is small. In my case data is huge and
creating a copy of the strings at each iteration is costly.
Re: Efficiently streaming data to associative array
On Tuesday, 8 August 2017 at 16:00:17 UTC, Steven Schveighoffer
wrote:
On 8/8/17 11:28 AM, Guillaume Chatelet wrote:
Let's say I'm processing MB of data, I'm lazily iterating over
the incoming lines storing data in an associative array. I
don't want to copy unless I have to.
Contrived example follows:
input file
--
a,b,15
c,d,12
Efficient ingestion
---
void main() {
size_t[string][string] indexed_map;
foreach(char[] line ; stdin.byLine) {
char[] a;
char[] b;
size_t value;
line.formattedRead!"%s,%s,%d"(a,b,value);
auto pA = a in indexed_map;
if(pA is null) {
pA = &(indexed_map[a.idup] = (size_t[string]).init);
}
auto pB = b in (*pA);
if(pB is null) {
pB = &((*pA)[b.idup] = size_t.init
}
// Technically unneeded but let's say we have more than 2
dimensions.
(*pB) = value;
}
indexed_map.writeln;
}
I qualify this code as ugly but fast. Any idea on how to make
this less ugly? Is there something in Phobos to help?
I wouldn't use formattedRead, as I think this is going to
allocate temporaries for a and b.
Note, this is very close to Jon Degenhardt's blog post in May:
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/
-Steve
I haven't yet dug into formattedRead but thx for letting me know
: )
I was mostly speaking about the pattern with the AA. I guess the
best I can do is a templated function to hide the ugliness.
ref Value GetWithDefault(Value)(ref Value[string] map, const
(char[]) key) {
auto pValue = key in map;
if(pValue) return *pValue;
return map[key.idup] = Value.init;
}
void main() {
size_t[string][string] indexed_map;
foreach(char[] line ; stdin.byLine) {
char[] a;
char[] b;
size_t value;
line.formattedRead!"%s,%s,%d"(a,b,value);
indexed_map.GetWithDefault(a).GetWithDefault(b) = value;
}
indexed_map.writeln;
}
Not too bad actually !
Efficiently streaming data to associative array
Let's say I'm processing MB of data, I'm lazily iterating over
the incoming lines storing data in an associative array. I don't
want to copy unless I have to.
Contrived example follows:
input file
--
a,b,15
c,d,12
...
Efficient ingestion
---
void main() {
size_t[string][string] indexed_map;
foreach(char[] line ; stdin.byLine) {
char[] a;
char[] b;
size_t value;
line.formattedRead!"%s,%s,%d"(a,b,value);
auto pA = a in indexed_map;
if(pA is null) {
pA = &(indexed_map[a.idup] = (size_t[string]).init);
}
auto pB = b in (*pA);
if(pB is null) {
pB = &((*pA)[b.idup] = size_t.init);
}
// Technically unneeded but let's say we have more than 2
dimensions.
(*pB) = value;
}
indexed_map.writeln;
}
I qualify this code as ugly but fast. Any idea on how to make
this less ugly? Is there something in Phobos to help?
Re: [OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.
On Monday, 31 July 2017 at 23:51:57 UTC, deadalnix wrote: This man is a superhero. Actually this guy is Cypher (https://g.co/kgs/NMRPQU), he's just back from the Matrix :D
Re: [OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.
On Monday, 31 July 2017 at 23:51:57 UTC, deadalnix wrote: On Monday, 31 July 2017 at 07:17:33 UTC, Guillaume Chatelet wrote: Some people here might find this interesting: https://github.com/xoreaxeaxeax/sandsifter White paper here: https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf This man is a superhero. See also https://www.youtube.com/watch?v=lR0nh-TdpVg for in hardware privilege escalation and https://www.youtube.com/watch?v=HlUe0TUHOIc . We should consider building a shrine for this guy. I knew him for https://github.com/xoreaxeaxeax/movfuscator - the program that turns every programs into a sequence of MOV instructions. I'm only halfway through the first video. It's *super* interesting. Thx for sharing!
[OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.
Some people here might find this interesting: https://github.com/xoreaxeaxeax/sandsifter White paper here: https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf
Re: Error on negating unsigned types
On Tuesday, 11 July 2017 at 20:05:43 UTC, Johan Engelen wrote: On Tuesday, 11 July 2017 at 20:02:07 UTC, Johan Engelen wrote: On Tuesday, 11 July 2017 at 19:57:06 UTC, Johan Engelen wrote: On Tuesday, 11 July 2017 at 19:46:00 UTC, Johan Engelen wrote: [...] Also this nice hackery would need a workaround: ``` if ((y&(-y))==y) ``` http://www.exploringbinary.com/ten-ways-to-check-if-an-integer-is-a-power-of-two-in-c/ "The two’s complement of x is computed with ~x + 1, which inverts the bits of x and adds 1 (~x + 1 is equivalent to -x, but negation is technically illegal for an unsigned integer)." Codegen is the same for both: https://godbolt.org/g/JiHiEe So Phobos's `if ((y&(-y))==y)` can be rewritten to `if ((y&(~y+1))==y)` without consequence. Interestingly returning a bool saves one register and a XOR.
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 09:00:47 UTC, Andrea Fontana wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
From the programmer's point of view the original code makes
sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
or:
ubyte[256] data;
foreach(ubyte i; 0..256) {
ubyte x = data[i];
}
Yes. Much better. What's the rewrite in this case? Using a size_t
internally and casting to ubyte?
Foreach loops on static arrays error message
I stumbled upon https://issues.dlang.org/show_bug.cgi?id=12685
In essence:
ubyte[256] data;
foreach (ubyte i, x; data) {}
Error: index type 'ubyte' cannot cover index range 0..256
`ubyte` can clearly hold a value from 0 to 255 so it should be
ok. No need for 256 ?!
So I decided to fix it https://github.com/dlang/dmd/pull/6973
Unfortunately when you think about how foreach is lowered it
makes sense - but the error message is misleading.
The previous code is lowered to:
ubyte[256] data;
for (ubyte i = 0 ; i < 256 ; ++i) {
ubyte x = data[i]
}
`i < 256` is always true, this would loop forever.
Questions:
- What would be a better error message?
- How about a different lowering in this case?
From the programmer's point of view the original code makes sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
Re: Suboptimal array copy in druntime?
On Sunday, 16 April 2017 at 11:25:15 UTC, Nicholas Wilson wrote: On Sunday, 16 April 2017 at 10:33:01 UTC, Stefan Koch wrote: On Sunday, 16 April 2017 at 10:08:22 UTC, Guillaume Chatelet wrote: I was looking at the _d_arrayassign family functions in druntime: https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L47 https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L139 [...] Nope. Those are valid points. Templatizing the code is the way to go. Indeed. See also http://dconf.org/2017/talks/cojocaru.html Sweet! Glad to see this is being worked on :)
Suboptimal array copy in druntime?
I was looking at the _d_arrayassign family functions in druntime: https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L47 https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L139 The code seems suboptimal for several reasons: 1. memcpy is more efficient on big arrays than iterating on a few bytes because it can use mmx/sse/avx. I would naturally memcpy the whole array and postblit/destroy individual elements separately. 2. ti.destroy and ti.postblit are always called but they might do nothing, since the code is not templated the compiler can't eliminate the calls. How about caching in TypeInfo if the type has a non empty destructor / postblit and do: if(ti.hasDestroy) for(element : dst_array) ti.destroy(element); memcpy(dst_array, src_array); if(ti.hasPostBlit) for(element : dst_array) ti.postblit(element); Granted that worse case we iterate the array several time, we could fallback to the current implementation if both are set. Did I miss something?
Re: Floating point constant folding
On Friday, 3 March 2017 at 22:35:15 UTC, Johan Engelen wrote: Clang without/with optimizations turned on: ❯ clang++ float.cpp && ./a.out 1.0011920928955078125 ❯ clang++ float.cpp -O3 && ./a.out 1 -Johan Thx Johan I should have checked... My point is moot then. -- "welcome to the magician world" - Don Clugston | DConf2016
Floating point constant folding
Context:
http://forum.dlang.org/post/qybweycrifqgtcsse...@forum.dlang.org
--- prints 1 ---
void main(string[] args)
{
import std.stdio;
import core.stdc.fenv;
fesetround(FE_UPWARD);
writefln("%.32g", 1.0f + float.min_normal);
}
---
--- prints 1.0011920928955078125 ---
void main(string[] args)
{
import std.stdio;
import core.stdc.fenv;
fesetround(FE_UPWARD);
float x = 1.0f;
x += float.min_normal;
writefln("%.32g", x);
}
---
Considering the floating point operations have a runtime
component, it seems to me that constant folding is not allowed to
occur in the first example. For example, it does not occur in the
following C++ snippet:
---
#include
#include
#include
int main(int, char**) {
std::fesetround(FE_UPWARD);
printf("%.32g\n", std::numeric_limits::denorm_min() +
1.0f);
return 0;
}
---
Thoughts?
Re: Floating point rounding
On Thursday, 2 March 2017 at 21:34:56 UTC, ag0aep6g wrote:
On 03/02/2017 10:10 PM, Guillaume Chatelet wrote:
On Thursday, 2 March 2017 at 20:30:47 UTC, Guillaume Chatelet
wrote:
Here is the same code in D:
void main(string[] args)
{
import std.math;
FloatingPointControl fpctrl;
fpctrl.rounding = FloatingPointControl.roundUp;
writefln("%.32g", float.min_normal + 1.0f);
}
Execution on my machine yields:
dmd -run test_denormal.d
1
Did I miss something?
This example is closer to the C++ one:
void main(string[] args)
{
import core.stdc.fenv;
fesetround(FE_UPWARD);
writefln("%.32g", float.min_normal + 1.0f);
}
It still yields "1"
This prints the same as the C++ version:
void main(string[] args)
{
import std.stdio;
import core.stdc.fenv;
fesetround(FE_UPWARD);
float x = 1.0f;
x += float.min_normal;
writefln("%.32g", x);
}
Soo, a bug/limitation of constant folding?
With FloatingPointControl it still prints "1". Does
FloatingPointControl.rounding do something different than
fesetround? The example in the docs [1] only shows how it
changes rint's behavior.
[1] http://dlang.org/phobos/std_math.html#.FloatingPointControl
Thx for the investigation!
Here is the code for FloatingPointControl
https://github.com/dlang/phobos/blob/master/std/math.d#L4809
Other code (enableExceptions / disableExceptions) seems to have
two code path depending on "version(X86_Any)", rounding doesn't.
Maybe that's the bug?
Re: Floating point rounding
On Thursday, 2 March 2017 at 20:30:47 UTC, Guillaume Chatelet
wrote:
Here is the same code in D:
void main(string[] args)
{
import std.math;
FloatingPointControl fpctrl;
fpctrl.rounding = FloatingPointControl.roundUp;
writefln("%.32g", float.min_normal + 1.0f);
}
Execution on my machine yields:
dmd -run test_denormal.d
1
Did I miss something?
This example is closer to the C++ one:
void main(string[] args)
{
import core.stdc.fenv;
fesetround(FE_UPWARD);
writefln("%.32g", float.min_normal + 1.0f);
}
It still yields "1"
Floating point rounding
I would expect that (1.0f + smallest float subnormal) > 1.0f when
the Floating Point unit is set to Round Up.
Here is some C++ code:
#include
#include
#include
int main(int, char**) {
std::fesetround(FE_UPWARD);
printf("%.32g\n", std::numeric_limits::denorm_min() +
1.0f);
return 0;
}
Execution on my machine yields:
clang++ --std=c++11 test_denormal.cc && ./a.out
1.0011920928955078125
Here is the same code in D:
void main(string[] args)
{
import std.math;
FloatingPointControl fpctrl;
fpctrl.rounding = FloatingPointControl.roundUp;
writefln("%.32g", float.min_normal + 1.0f);
}
Execution on my machine yields:
dmd -run test_denormal.d
1
Did I miss something?
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu wrote: On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote: C++ integration has disappeared? Is this now "done"? We have a student on that. I've added a line for that to the doc. -- Andrei I did a lot of work on C++ name mangling for D so feel free to introduce me to the student. I can probably save her/him a lot of time. After *many* attempts it seems the only way to get this right is to look at how clang does it and replicate the logic (starting point https://github.com/llvm-mirror/clang/blob/google/stable/include/clang/AST/Mangle.h) The state of my research on mangling so far are summed up here https://github.com/gchatelet/gcc_cpp_mangling_documentation I also have a bunch of failed experiments branches: - https://github.com/gchatelet/dmd/tree/new_cpp_mangle - https://github.com/gchatelet/dmd/tree/new_cpp_mangle2 - https://github.com/gchatelet/dmd/tree/new_cpp_mangling2 - https://github.com/gchatelet/dmd/tree/more_mangling_tests Unfortunately I couldn't spend more time on this :(
Re: libgmp deimos library
On Wednesday, 11 January 2017 at 11:34:55 UTC, Andrew Hall wrote: Cheers, I've done as you suggest, and 'libgmp' is registered under DUB. Feel free to have a look at the code because this is the first binding I've written in D. That said, it does have a test suite (unit tests) that do work. What is the procedure for being accepted by Deimos? Can you add the dub component to the "Development library" -> "D language binding" category? Also you should probably post about your library on the "Announce" list. I'm not at all an expert on D bindings, I found the following links: - This page explains the procedure: http://wiki.dlang.org/D_binding_for_C - But this one too: http://dlang.org/spec/interfaceToC.html - This page seems out of date: https://wiki.dlang.org/Bindings. - And most bindings are discoverable through https://code.dlang.org/?sort=updated=library.binding The old way seems to gather all bindings under https://github.com/D-Programming-Deimos. The new way seems to use https://code.dlang.org/. Is someone aware of an official position on this?
Re: libgmp deimos library
On Wednesday, 11 January 2017 at 10:29:26 UTC, Andrew Hall wrote: I've been writing D bindings for GMP and I was wondering if they warrant inclusion in the Deimos git repo. I know Dlang has bignum, but GMP is still the fastest library for extremely large numbers. The repos is in 'Deimos' format so if you care to use it, please tell me how to proceed. https://github.com/andrew-m-h/libgmp FYI I wrote a MPFR Deimos binding: https://github.com/gchatelet/deimos-mpfr MPFR relies on GMP so I had to create this file: https://github.com/gchatelet/deimos-mpfr/blob/master/source/deimos/gmp.d If you register your project on https://code.dlang.org/ I'll be able to depend on your project and reuse your bindings.
Deimos bindings for MPFR
I just created D bindings[1] for the MPFR library[2]. It also contains a D type[3] that wraps call to the library. --- 1. http://code.dlang.org/packages/deimos-mpfr 2. http://www.mpfr.org/ 3. https://github.com/gchatelet/deimos-mpfr/blob/master/source/mpfrd.d
Re: Inline aggregate types
On Friday, 2 December 2016 at 11:11:30 UTC, Ethan Watson wrote: On Friday, 2 December 2016 at 10:16:17 UTC, Jacob Carlborg wrote: [...] I was attempting to support all methods. new class isn't the cleanest way of doing things either, so I decided I'd support all the things and let the user choose what they're comfortable with. [...] Do you plan on contributing this back to phobos? I also came across this exact same problem.
Re: [Semi OT] - "Garbage In, Garbage Out: Arguing about Undefined Behavior..."
On Saturday, 15 October 2016 at 00:11:35 UTC, deadalnix wrote: On Thursday, 13 October 2016 at 15:19:17 UTC, Guillaume Chatelet wrote: Pretty cool talk by Chandler Carruth on undefined behavior. It reminds me of a bunch of conversations than happened on this mailing list. I bet Walter will like it :) https://www.youtube.com/watch?v=yG1OZ69H_-o I was not very impressed to be honest. His argument is that this is an error, but really this isn't or people wouldn't be that mad at undefined behavior. Well you have to draw the line somewhere and defining it as an error makes sense to me. I think people are mad because they code something reasonable but it's UB. It's like being a good citizen and receiving a fine because a speed limit sign was hidden by a tree. It's hard not to be angry then. If your compiler could always point you at the error, you'd be much less angry because you'd be aware of the rule early. It may still be a stupid rule but at least you'd know. Unfortunately it's hard if not impossible to detect them. Some of them [1] are mitigated in D: Uninitialized scalar, Access out of bounds. But basic type computation UB are pervasive and exposed to the user directly. The difficulty comes from the impedance mismatch between the language semantics and the available hardware. That would solve the shift problem very nicely. As Chandler mentioned at the end of the talk, there are no real rationale for some of the UB and it would totally make sense to have them defined now. His argument about indices was also weak as it tells more about the need to use size_t rather than 32 bits indices when doing indices computation. Isn't size_t just an alias to unsigned int? Does the compiler treat it in a special way which would remove the need for overflow detection? 1. See http://en.cppreference.com/w/cpp/language/ub "undefined behavior - there are no restrictions on the behavior of the program. Examples of undefined behavior are memory accesses outside of array bounds, signed integer overflow, null pointer dereference, modification of the same scalar more than once in an expression without sequence points, access to an object through a pointer of a different type, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful."
[Semi OT] - "Garbage In, Garbage Out: Arguing about Undefined Behavior..."
Pretty cool talk by Chandler Carruth on undefined behavior. It reminds me of a bunch of conversations than happened on this mailing list. I bet Walter will like it :) https://www.youtube.com/watch?v=yG1OZ69H_-o
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 15:06:29 UTC, Manu wrote:
On 13 September 2016 at 00:37, Andrei Alexandrescu via
Regarding Phobos suitability: One thing I'd like to hear from
the community is the applicability of this work. I know very
little about colors (only the RGB was familiar from HTML etc,
but then there was no YUL), but that doesn't mean much. The
library is quite isolated from the rest of Phobos, e.g. a
stronger case would be made if there were some
std.experimental.canvas package which uses the color package.
Or at least a std.experimental.terminal package or something.
A good case for inclusion would motivate the presence of the
library as a catalyst for many user-level abstractions. --
Andrei
So, the main reason I wanted to push for this in phobos is
because
it's an enabler.
There is no multimedia in phobos at all. I think that's a
shame, and
this is a starting point. Any conceivable image based work
depends on
this as foundation. If pixel format types are phobos-supplied,
then D
image libraries will naturally be compatible, as opposed to
naturally
incompatible since every image library will otherwise
re-implement
their own colour types (and almost always incorrectly).
The thing about colours is, they're HARD to get right, but more
importantly, most programmers have no idea that it's actually a
hard
problem and won't tend to go looking for a lib for a colour
type (Ie,
struct { ubyte r, g, b;}... simple! *cough*). They probably
will use
it if it's in phobos though for compatibility reasons.
Image processing is super easy by contrast.
One of my first port-of-calls after this work would be a
graph/plot library... I'd use the hell out of that. I
constantly want to output data visualisations!
It also enables seamless interaction with realtime rendering
api's. Ie, if OpenGL/D3D/Vulkan bindings support phobos
supplied colour types, then image decoding libraries, and other
sources of image data become easy to render without any
requirement for adaptation. Rendering libs and image/video data
source libs are almost always separate, independent libraries.
We need to maximise probability that they are compatible out of
the gate.
I didn't want to touch 'images' in this work, because there are
countless subjective designs to present those API's, but I
don't think there's many competing designs for a colour
library, so it felt it was the best and most bang-for-buck
starting place overall.
Also, I think this has very high synergy with ndslice. I think
ndslice + color is the foundation for image processing, or at
least image data transport.
+1
It's simply amazing how the concept of color is well understood
by everyone and yet utterly hard to understand in the details.
Color is a Universe in itself! Just have a look at Metamerism(1)
(colors that look the same but aren't), Human Tetrachromacy(2)
(some people - mostly women - perceive more colors than others).
I'm not even scratching the surface: it connects with everything:
Physics, Physiology, Art, Entertainement, Evolution(3)...
Having a high quality Color API in Phobos is a differentiator and
an enabler: think Raytracer, image batch processing, scientific
analysis, interactions with GUI or rendering APIs.
I think it's an important addition to Phobos - I might be biased
though :-P
1. https://en.wikipedia.org/wiki/Metamerism_(color)
2. https://en.wikipedia.org/wiki/Tetrachromacy#Humans
3. https://www.youtube.com/watch?v=qrKZBh8BL_U
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 14:12:35 UTC, Manu wrote: On 12 September 2016 at 21:31, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote: [...] Actually, I spent quite some time stressing about dynamic range. Trouble is, there's no real format spec's relating to dynamic range, it tends to be by convention. I'm not sure what the API would look like, so I haven't approached that problem. It's very easy to do the transform yourself, I don't really think it needs to be part of the type, particularly since there's no conventional way to express it. Note also that I didn't do any YUV formats (this case you discuss is usually related to older broadcast formats)... didn't know if they'd be particularly useful to people. At least, it's not in my initial offering. Yes I agree, as you and Marco said: I think it's best to leave it to clients of the API.
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews. I added packed-RGB support, including weird micro-float and shared-exponent formats. They're important for interacting with any real-time rendering libraries. There is only one texture format I'm aware of that isn't supported, and that is u7e3 floats, only available on Xbox360 ;) Chromatic adaptation functions are in. I've done a tidy/reorg pass. I'm not sure what else should be in the scope of this lib. PR: https://github.com/dlang/phobos/pull/2845 dub: https://code.dlang.org/packages/color docs: http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html - Manu And also, do you handle limited (16-235) to full dynamic range (0-255) conversions? It's a setting some acquisition/graphic card allow. https://wiki.videolan.org/VSG:Video:Color_washed_out/ From this page as well http://www.digitalpreservation.gov/formats/fdd/fdd000352.shtml "Video and wide range. The ITU-R specifications support values for Y, Cb, and Cr that conform to what is sometimes called "video range," "legal range," or "studio swing" levels. Expressed in terms of 8-bit tonal range values, video range has a 16-235 levels for Y and 16-240 levels for Cr and Cb. The term video range is used to contrast with "wide range" or "super white " values from 0 to 255, sometimes used when video signals are created using computer-based graphics applications."
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 09:09:29 UTC, Manu wrote: I thought about it, but it added (even more) complexity, and I'm not really sure it's the MO of a color lib to worry about the endian-ness of storage. I could support "_le"/"_be" suffix on the PackedRGB format string, but then you have to also specify the word size, ie, is the packed color 32bit words (eg, 11,11,10) or 16bit words (16f,16f,16f,16f)? It's only really practically applicable to PackedRGB, so I wonder why just one color type should worry about it, but not all the others... Consider an unpacked RGB with 16bit elements... that may also suffer endian problems, but RGB is a runtime type, not a storage type, which means it doesn't have a pack/unpack process... so there's no meaningful palace to do it. Yep I totally understand the rationale - I've been there too :) I don't think it belong to Color but maybe Buffer(1) could be templated on endianness? Buffer is indeed the place where you deal with storage. If you don't want to add it to the library I think you should add a paragraph in the documentation explaining why it's not in there and how people can overcome it (copy + change endianness or use an adapter?). Also, it would be nice to have some code snippets in the documentation. Last thing, for the white points you didn't specify which CIE standard observer(2) version you used: CIE 1931 2° Standard Observer or CIE 1964 10° Standard Observer? IIRC the standard illuminant are not the same depending on the observer. 1. http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color/packedrgb/buffer.html 2. https://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews. I added packed-RGB support, including weird micro-float and shared-exponent formats. They're important for interacting with any real-time rendering libraries. There is only one texture format I'm aware of that isn't supported, and that is u7e3 floats, only available on Xbox360 ;) Chromatic adaptation functions are in. I've done a tidy/reorg pass. I'm not sure what else should be in the scope of this lib. PR: https://github.com/dlang/phobos/pull/2845 dub: https://code.dlang.org/packages/color docs: http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html - Manu Looks pretty good to me. Quick question though. Do you handle endianness? DPX might be a dead file format but it's main usage relies on 10bits packed RGB into 32 bits (last two bits are discarded or alpha) but it can be either little or big endian. Good job on the library though!
Re: DIP1000: Scoped Pointers
On Saturday, 13 August 2016 at 20:50:53 UTC, Joseph Rushton
Wakeling wrote:
The TL;DR here is that I'm concerned about having a solution
for random number generators and random algorithms that (i)
allows them to be stack-allocated, (ii) ensures that their
internal state is not accidentally copied by value, and (iii)
allows them to work effectively with (input) range semantics.
Isn't it what a scoped class is supposed to provide?
class Rnd {}
void foo() {
scope rnd = new Rnd; // reference semantic and stack allocated
}
Re: [OT] The coolest (literally) desktop machine I've ever had
On Friday, 12 August 2016 at 19:13:12 UTC, Andrei Alexandrescu wrote: I was using a large Lenovo Y70-70 laptop as a pseudo-desktop machine and additional monitor. It's quite powerful, but its fans would run at all times. Getting really tired of that, I googled for the better part of an afternoon for "fanless desktop" and it turns out it's much harder to find one than I'd initially thought. (Slow fanless machines are easy to find, but I was looking for one as powerful as any desktop.) [...] Also Puget System makes some pretty awesome machines - not fanless but still absolutely quiet. https://www.pugetsystems.com/serenity.php They don't ship to France but they give the parts references so I basically built one myself. I'm really happy about it. It's on 24/7 in my bedroom and I can't ear it while sleeping.
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid Also: Intel(R) Atom(TM) CPU 230 @ 1.60GHz https://gist.github.com/gchatelet/d3d347e4630ec2567eae7fe0391a9316
Re: new cpuid is ready for comments
On Tuesday, 12 July 2016 at 13:23:46 UTC, Ilya Yaroshenko wrote: On Tuesday, 12 July 2016 at 12:46:26 UTC, Guillaume Chatelet wrote: On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are? Hello Guillaume, The data come from CPUID x86/x86_64 instruction. I have fixed bugs for AMD yesterday. Information for Intel and AMD processors should be reliable. But I am not sure about Cache and TLB information for virtual machines and other vendors. You can use cpuid.x86_any._cpuid [1] to get any information that is not presented. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#._cpuid Thx Ilya, I was discussing this a few colleagues. I'm quoting one of them here with his permission: "It doesn't seems that a userland library like this has any possibility to solve the root problem on Android/ARM. It's a twofold problem: 1. On ARM, the registers containing CPU identification and cache structure information, are privileged. See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html etc... (more such registers listed in the left pane on that page) Thus it is up to the operating system to expose this information to userspace. That takes us to the second part of the problem: 2. As far as I know, Android does not expose either CPU identification or cache structure information to userspace. Please do correct me if I'm wrong and this library found a way around that --- but from a cursory look at the cpuid library code, it does not have an ARM implementation at the moment?"
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are?
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid Looks good! Here are my results (I added a `cat /proc/cpuinfo` for the record) https://gist.github.com/gchatelet/31a8cf41ba1d888c1efaef314d6a0c97
Re: Should we add another SmallArray to DMD?
On Thursday, 7 July 2016 at 07:56:44 UTC, Stefan Koch wrote: On Thursday, 7 July 2016 at 06:39:19 UTC, Guillaume Chatelet wrote: On Tuesday, 5 July 2016 at 19:41:18 UTC, Guillaume Chatelet wrote: DMD currently provides the Array type: https://github.com/dlang/dmd/blob/master/src/root/array.d [...] Walter, Daniel, Thoughts? I guess a few number of the perf difference this can make would be helpful. It's not so much about performance gain (although it wouldn't hurt). It's more about codebase sanity: idiomatic D, documentation, tests. I think it's currently hard to contribute to DMD. Sure it improved a lot with the migration to D but it still bears the marks of the past.
Re: Should we add another SmallArray to DMD?
On Tuesday, 5 July 2016 at 19:41:18 UTC, Guillaume Chatelet wrote: DMD currently provides the Array type: https://github.com/dlang/dmd/blob/master/src/root/array.d [...] Walter, Daniel, Thoughts?
Re: First dmd nightly shipping with dub
On Wednesday, 6 July 2016 at 09:28:44 UTC, Martin Nowak wrote: This is the first nightly dmd build that includes dub binaries. http://nightlies.dlang.org/dmd-2016-07-06/ They will also be part of the upcoming 2.072.y releases. We will sync the dub and dmd release cycles, but not the versioning. Pretty cool!
Should we add another SmallArray to DMD?
DMD currently provides the Array type: https://github.com/dlang/dmd/blob/master/src/root/array.d It is primarily designed to interact with C++. It provides the small array optimization which is good, but its stack space is one element and cannot be changed, making it not suitable for small string buffers. As a matter of fact we also have OutBuffer which reimplements the allocation strategy a second time (with no small string optimization) https://github.com/dlang/dmd/blob/master/src/root/outbuffer.d It is also quite old, not tested (at least I didn't find them), and does not follow D idioms. Also note that because Array is "extern (C++)", it's not possible to add SMALLARRAYCAP as a template parameter (bug in the C++ name mangler). Proposal: - As for LLVM, create a few tested D idiomatic facilities to use in the front end: SmallVector, SmallString to begin with. Here is a first take at SmallVector (no doc yet) https://gist.github.com/gchatelet/876adfb59abe1dda58ba24d63d4e418d I'm half convinced for now so I would like some feedback before investing more time.
Re: Cpp/D interface semantic
On Sunday, 26 June 2016 at 14:48:00 UTC, Guillaume Chatelet wrote: Johan I saw you created a few bugs for C++ name mangling. Can you assigne the one for Linux to me. I'm redesigning the algorithm and I need as many corner cases as possible. Note: I'm only touching the 'Linux' C++ mangling code, so I'm only interested C++ mangling issues on the following platform: TARGET_LINUX, TARGET_OSX, TARGET_FREEBSD, TARGET_OPENBSD, TARGET_SOLARIS.
Re: Cpp/D interface semantic
On Sunday, 26 June 2016 at 09:28:19 UTC, Johan Engelen wrote: On Sunday, 26 June 2016 at 07:51:16 UTC, Guillaume Chatelet wrote: This is fine in the case where E is a D interface because of reference semantics: it should be passed by pointer. But, in the case where an extern(C++) function calls an extern(C++) type should it be value semantic - as it is in C++ - or reference semantic - as it is in D? I think the semantics should be D, so e.g. reference semantics for an extern(C++) class. (This is all over ddmd source: many front-end classes are extern(C++)). A related PR: https://github.com/dlang/dmd/pull/5875 Sounds good to me. Johan I saw you created a few bugs for C++ name mangling. Can you assigne the one for Linux to me. I'm redesigning the algorithm and I need as many corner cases as possible. Current test set is here: https://github.com/gchatelet/dmd/tree/new_cpp_mangling2/test/mangling
Cpp/D interface semantic
This is currently part of the dmd test suite [1]:
extern (C++) interface E
{
int bar(int i, int j, int k);
}
extern (C++) int callE(E);
static assert (callE.mangleof == "_Z5callEP1E");
The last line checks that callE() will pass its argument by
pointer.
This is fine in the case where E is a D interface because of
reference semantics: it should be passed by pointer.
But, in the case where an extern(C++) function calls an
extern(C++) type should it be value semantic - as it is in C++ -
or reference semantic - as it is in D?
Thoughts?
--
1.
https://github.com/dlang/dmd/blob/master/test/compilable/cppmangle.d#L102
Re: Need DMD AST expertise
On Tuesday, 21 June 2016 at 19:42:54 UTC, Elie Morisse wrote:
On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet
wrote:
[...]
The templated function is the child symbol of the
TemplateDeclaration which shares the same name i.e
[...]
Thx Elie! It helps :)
I came up with this quick and dirty piece of code to get the
parameters from the template declaration and the function
declaration:
code:
auto declaration =
cast(TemplateDeclaration)templateInstance.tempdecl;
assert(declaration);
printf("TemplateDeclaration %x\n", declaration);
foreach(parameter; *declaration.parameters) {
printf("Parameter %s\n", parameter.ident.toChars());
}
if (declaration.onemember) {
FuncDeclaration fd =
declaration.onemember.isFuncDeclaration();
if (fd && fd.type) {
TypeFunction tf = cast(TypeFunction)fd.type;
assert(tf);
printf("TypeFunction %x\n", tf);
if(tf.next) printf("Parameter return %s\n",
tf.next.toChars());
if(tf.parameters) foreach(parameter; *tf.parameters) {
printf("Parameter %s\n", parameter.type.toChars());
}
}
}
input:
extern(C++) C foo(A, B, C)(B, A);
output:
TemplateDeclaration 764f76b0
Parameter A
Parameter B
Parameter C
TypeFunction 764f7370
Parameter return C
Parameter B
Parameter A
It works as expected. I still need to do the mapping and handle
subtleties like this but I'm on the right track.
extern(C++) ref C foo(A, B, C)(B*, const(A)*);
Thx!
Re: Need DMD AST expertise
On Tuesday, 21 June 2016 at 09:13:26 UTC, Jacob Carlborg wrote: On 2016-06-21 09:45, Guillaume Chatelet wrote: AFAIK basic types are instantiated once and reused: https://github.com/dlang/dmd/blob/b67694a0d74437d3a1581da2b9f1b785dc7b3c88/src/mtype.d#L861 So comparing pointers wouldn't work. Yeah. I'm just guessing here :). Sorry, I don't think I can help you. Thx anyways! I'll continue my journey [1] :) 1. https://cdn.meme.am/instances/39916320.jpg
Re: Need DMD AST expertise
On Tuesday, 21 June 2016 at 06:25:26 UTC, Jacob Carlborg wrote: On 2016-06-20 22:52, Guillaume Chatelet wrote: [...] A guess: "tiargs" is the types of the values passed to the template. "tdtypes" is the types the template is instantiated with. void foo(T)(T* a); int b; foo!(int)(*); "tiargs" is "int*" and "tdtypes" is "int". But this can easily be confirmed using some printf debugging. [...] Are the types the same objects so you can compare by just comparing the pointers? AFAIK basic types are instantiated once and reused: https://github.com/dlang/dmd/blob/b67694a0d74437d3a1581da2b9f1b785dc7b3c88/src/mtype.d#L861 So comparing pointers wouldn't work.
Re: More suggestions for find()
On Monday, 20 June 2016 at 16:09:21 UTC, qznc wrote: On Monday, 20 June 2016 at 13:27:59 UTC, Jack Stouffer wrote: On Monday, 20 June 2016 at 12:34:55 UTC, qznc wrote: On Sunday, 19 June 2016 at 10:38:27 UTC, qznc wrote: On Saturday, 18 June 2016 at 18:54:28 UTC, Andrei Alexandrescu wrote: [...] Compare with memmem. That is 4x faster than the current stuff. I guess vector instructions are key. There is a branch in my repo. More like 2x after looking again Cool :) What are the chances of getting this in Phobos? Low. It requires the GNU libc to link against. We don't want that dependency. We cannot port it directly since it is GPL code. It is even more of a special case, since it only works for the == predicate. I'm not sure about the vector instructions it requires. What we need is a clean room implementation of the two way string matching algorithm with vector instructions? Maybe there's some inspiration to get from the source code: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/memmem.c;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/str-two-way.h;hb=HEAD
Re: Need DMD AST expertise
On Monday, 20 June 2016 at 18:59:09 UTC, Jacob Carlborg wrote: On 2016-06-20 14:33, Guillaume Chatelet wrote: Problem 2: -- Template arguments that are of basic types are mangled in a special way which requires to understand which 'int' is which. extern(C++) A foo(A, B)(B, A, B); static assert(foo!(int,int).mangleof == "_Z3fooIiiET_T0_S0_S1_"); In the example above the first 'int' is not the same as the second one, it's a distinct substitution. Question: - - How can I know which is which since from the AST perspective, the FunDeclaration's Parameters are just TypeBasic 'int'? Not sure I understand the question. Sorry about not being too clear. Are you saying that the two integers are mangled differently because there are two template parameters? Yes exactly. I'm guessing you need to look at the template declaration to get more information about the template parameters. The TemplateInstance [1] gives me `tiargs` and `tdtypes`. // Array of Types/Expressions of template // instance arguments [int*, char, 10*10] Objects* tiargs; // Array of Types/Expressions corresponding // to TemplateDeclaration.parameters // [int, char, 100] Objects tdtypes; I'm using `tiargs` right now (I'm not really sure what `tdtypes` is). AFAIU I can access TemplateDeclaration from TemplateInstance through `tempdecl` even though it's stored as a Dsymbol. I'll have a look at `parameters` from TemplateDeclaration [2] but I still need to match it to the function arguments somehow. The following example illustrates the process of pairing the int to the template parameter. extern(C++) B foo(A, B)(*B, ref const A); foo!(int, int) => int foo(*int, ref const int); ^^ ^^ ^ 12 21 2 1. https://github.com/dlang/dmd/blob/master/src/dtemplate.d#L5895 2. https://github.com/dlang/dmd/blob/master/src/dtemplate.d#L406
Re: Need DMD AST expertise
On Monday, 20 June 2016 at 14:42:22 UTC, Jacob Carlborg wrote: On 2016-06-20 16:06, Guillaume Chatelet wrote: Thx Johan. I'm confused though: `FuncDeclaration.linkage` is the linkage for the function (which I already know is C++ function since I'm mangling it) but I need the linkage for the Parameter. Parameter has a Type but I can't get the linkage from here. What did I miss? 1. Check if the type is a class. There's a field "ty" in Type 2. If it's a class, cast it to TypeClass 3. TypeClass has a field "sym" of type ClassDeclaration 4. ClassDeclaration has three fields: "com", "cpp" and "objc". I think these fields indicate if the class declaration has extern(C++), extern(Objective-C) and so on. If none of them are true, it's standard extern(D) Pretty cool. Thx Jacob! Anyone has a suggestion for my second problem? If not I'll have to do some kind of mapping between the template args and the parameters...
Re: Need DMD AST expertise
On Monday, 20 June 2016 at 13:50:45 UTC, Johan Engelen wrote: On Monday, 20 June 2016 at 12:33:31 UTC, Guillaume Chatelet wrote: class Expression; extern(C++) void foo(Expression); Question: - - How to I get the linkage for Expression from a FunDeclaration? This will ensure the added indirection is put only for the D classes, not the C++ ones. I tried looking at Parameter, ClassDeclaration or TypeClass but couldn't find it. A FuncDeclaration is a Declaration, which contains the field `LINK linkage;`. That's the one you want. -Johan Thx Johan. I'm confused though: `FuncDeclaration.linkage` is the linkage for the function (which I already know is C++ function since I'm mangling it) but I need the linkage for the Parameter. Parameter has a Type but I can't get the linkage from here. What did I miss?
Need DMD AST expertise
Context: I'm working on a more correct implementation of the C++ name mangling for Linux/OSX. This is needed for the integration with C++/STL. Problem 1: -- In the following D code 'Expression' is a D class, 'foo' is a C++ function, its argument must be mangled as a pointer to Expression because D has reference semantic (whereas C++ has value semantic). class Expression; extern(C++) void foo(Expression); Question: - - How to I get the linkage for Expression from a FunDeclaration? This will ensure the added indirection is put only for the D classes, not the C++ ones. I tried looking at Parameter, ClassDeclaration or TypeClass but couldn't find it. Problem 2: -- Template arguments that are of basic types are mangled in a special way which requires to understand which 'int' is which. extern(C++) A foo(A, B)(B, A, B); static assert(foo!(int,int).mangleof == "_Z3fooIiiET_T0_S0_S1_"); In the example above the first 'int' is not the same as the second one, it's a distinct substitution. Question: - - How can I know which is which since from the AST perspective, the FunDeclaration's Parameters are just TypeBasic 'int'? Thx in advance!
Re: Interest in Paris area D meetups?
On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: On Wednesday, 8 June 2016 at 16:40:53 UTC, Claude wrote: On Wednesday, 1 June 2016 at 20:33:40 UTC, Guillaume Chatelet wrote: On Wednesday, 1 June 2016 at 19:25:13 UTC, Claude wrote: [...] Two sounds like a good start ^__^ We can start with a beer somewhere :) Yeah great! I'm up for a beer. I work near Gare de l'Est. We can have a drink after work-time (I'm available around 19h), and share about what we think about that evil auto-decode. Is it ok for you ? Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? In case someone else wants to join. This has been postponed to next week. Wednesday 22nd same place, same time.
Re: Interest in Paris area D meetups?
On Thursday, 9 June 2016 at 16:27:41 UTC, Claude wrote: On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great! FYI my email address: chatelet.guillaume at gmail
Re: Interest in Paris area D meetups?
On Wednesday, 8 June 2016 at 16:40:53 UTC, Claude wrote: On Wednesday, 1 June 2016 at 20:33:40 UTC, Guillaume Chatelet wrote: On Wednesday, 1 June 2016 at 19:25:13 UTC, Claude wrote: On Wednesday, 18 May 2016 at 15:05:21 UTC, Guillaume Chatelet wrote: I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Sorry for the later reply, but yes, I'd be interested by a meetup in Paris. Anyone else? Two sounds like a good start ^__^ We can start with a beer somewhere :) Yeah great! I'm up for a beer. I work near Gare de l'Est. We can have a drink after work-time (I'm available around 19h), and share about what we think about that evil auto-decode. Is it ok for you ? Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00?
Re: Interest in Paris area D meetups?
On Wednesday, 1 June 2016 at 19:25:13 UTC, Claude wrote: On Wednesday, 18 May 2016 at 15:05:21 UTC, Guillaume Chatelet wrote: I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Sorry for the later reply, but yes, I'd be interested by a meetup in Paris. Anyone else? Two sounds like a good start ^__^ We can start with a beer somewhere :)
Re: Dealing with Autodecode
On Wednesday, 1 June 2016 at 01:36:43 UTC, Adam D. Ruppe wrote: I have a better one, that we discussed on IRC last night: 1) put the string overloads for front and popFront on a version switch: D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE QUALITY WITH A SIMPLE MIGRATION PATH 2) After a while, we swap the version conditions, so opting into it preserves the old behavior for a while. 3) A wee bit longer, we exterminate all this autodecoding crap and enjoy Phobos being a smaller, more efficient library. +1
Re: Sociomantic's short DConf2016 video
On Tuesday, 24 May 2016 at 11:06:45 UTC, Leandro Lucarella wrote: For the ones that missed it (and the ones that didn't too), here is a short video about the conference. https://vimeo.com/167235872 Neat!
Re: Interest in Paris area D meetups?
On Thursday, 19 May 2016 at 06:50:58 UTC, chmike wrote: On Wednesday, 18 May 2016 at 15:05:21 UTC, Guillaume Chatelet wrote: I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Feel free to add yourself to the map: https://www.google.com/maps/d/edit?mid=1euIpoA6stFHlmIk1m9qbVHwP_64 Hello, great initiative. I would be interested in a french meetup, but in Marseille (south of France). How do I add myself on the map ? I'm using an iPad and could find the method. You need to click on the pin (under the search bar) and then click on the map. Just add your name (I also added my github username in parenthesis). Let's see how many people in France are interested.
Interest in Paris area D meetups?
I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Feel free to add yourself to the map: https://www.google.com/maps/d/edit?mid=1euIpoA6stFHlmIk1m9qbVHwP_64
Re: Always false float comparisons
On Thursday, 12 May 2016 at 16:20:05 UTC, Walter Bright wrote: On 5/12/2016 9:15 AM, Guillaume Chatelet wrote: Well maybe it was a disaster because the problem was only half solved. It looks like Perl 6 got it right: https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/ Perl isn't a systems programming language. A systems language requires access to code units, invalid encodings, etc. Nor is Perl efficient. There are a lot of major efficiency gains by not autodecoding. [Sorry for the OT] I never claimed Perl was a systems programming language nor that it was efficient, just that their design looks more mature than ours. Also I think you missed this part of the article: "Of course, that’s all just for the default Str type. If you don’t want to work at a grapheme level, then you have several other string types to choose from: If you’re interested in working within a particular normalization, there’s the self-explanatory types of NFC, NFD, NFKC, and NFKD. If you just want to work with codepoints and not bother with normalization, there’s the Uni string type (which may be most appropriate in cases where you don’t want the NFC normalization that comes with normal Str, and keep text as-is). And if you want to work at the binary level, well, there’s always the Blob family of types :)." We basically have "Uni" in D, no normalized nor grapheme level.
Re: Always false float comparisons
On Thursday, 12 May 2016 at 15:55:52 UTC, Walter Bright wrote: This reminds me of all the discussions around trying to hide the fact that D strings are UTF-8 code units. The ultimate outcome of trying to make it "make sense" was the utter disaster of autodecoding. Well maybe it was a disaster because the problem was only half solved. It looks like Perl 6 got it right: https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/
Re: LDC 1.0.0-beta1 has been released! Please help testing!
On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote: Hi everyone, LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. The 1.0 release will be a major milestone. Please help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org Regards, Kai Why does it requires libconfig.so.8? Could you static link it?
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei I'll take off early on Friday and will miss the last talk, with this one hour shift I'll probably miss the last two talks ... But hey they'll be recorded right?
Re: Beta D 2.071.0-b1
On Thursday, 24 March 2016 at 01:49:25 UTC, Martin Nowak wrote: First beta for the 2.071.0 release. This release comes with many import and lookup related changes and fixes. You might see a lot of deprecation warnings b/c of these changes. We've added the -transition=import switch and -transition=checkimports [¹] switches to ease updating existing code. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin [¹]: -transition=checkimports currently has a bug that creates false positive warnings about the $ symbols, this will be fixed in the next beta (Bugzilla 15825) Shouldn't this be part of the release ? https://issues.dlang.org/show_bug.cgi?id=15581
Re: @mutable
On Monday, 22 February 2016 at 18:03:03 UTC, Nick Treleaven wrote:
On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet
wrote:
static make() {
The return type is missing for the make() function:
I'm pretty sure static here works just like 'static auto'. In D
I think you can use storage classes (and even attributes) to
imply auto:
const foo(){return 5;}
assert(foo() == 5);
Ha right indeed it's probably going to work. It was just a bit
surprising.
Re: @mutable
static make() {
The return type is missing for the make() function:
AccessUnalignedMemory version
It came up on this thread a few days ago
https://github.com/D-Programming-Language/phobos/pull/3916#issuecomment-171373707
Some architectures do not allow unaligned loads/writes.
It would be nice to have a Version for this:
version (AccessUnalignedMemory)
{
foo(cast(ulong[])(ubyte)buffer));
}
else
{
// copy in an aligned buffer and then call foo
}
Questions:
- Is it worth the addition ?
- Does anyone has a better naming suggestion ?
- Where should we put such a definition ?
Re: Bug in csv or byLine ?
On Sunday, 10 January 2016 at 19:50:15 UTC, Tobi G. wrote: On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips wrote: On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote: The bug has been fixed... Do you have a link for the fix? Is there a BugZilla entry? Yes sure.. https://issues.dlang.org/show_bug.cgi?id=15545 and the fix at github https://github.com/D-Programming-Language/phobos/pull/3917 togrue Thx for the fix !
Bug in csv or byLine ?
$ cat debug.csv
timestamp,curr_property
2015-12-01 06:07:55,7035
$ cat process.d
import std.stdio;
import std.csv;
import std.algorithm;
import std.file;
void main(string[] args) {
version (Fail) {
File(args[1], "r").byLine.joiner("\n").csvReader.each!writeln;
} else {
readText(args[1]).csvReader.each!writeln;
}
}
$ dmd -run ./process.d debug.csv
["timestamp", "curr_property"]
["2015-12-01 06:07:55", "7035"]
$ dmd -version=Fail -run ./process.d debug.csv
["timestamp", "curr_property"]
["2015-12-01 06:07:55", "7035"]
core.exception.AssertError@std/algorithm/iteration.d(2027):
Assertion failure
??:? _d_assert [0x4633d3]
??:? void std.algorithm.iteration.__assert(int) [0x46d770]
??:? pure @property @safe dchar
std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char,
char).ByLine,
immutable(char)[]).joiner(std.stdio.File.ByLine!(char,
char).ByLine, immutable(char)[]).Result.front() [0x44eaf0]
??:? void std.csv.CsvReader!(immutable(char)[], 1,
std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char,
char).ByLine,
immutable(char)[]).joiner(std.stdio.File.ByLine!(char,
char).ByLine, immutable(char)[]).Result, dchar,
immutable(char)[][]).CsvReader.popFront() [0x44f7fc]
??:? void
std.algorithm.iteration.__T4eachS183std5stdio7writelnZ.each!(std.csv.CsvReader!(immutable(char)[], 1, std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result, dchar, immutable(char)[][]).CsvReader).each(std.csv.CsvReader!(immutable(char)[], 1, std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result, dchar, immutable(char)[][]).CsvReader) [0x4608f7]
??:? _Dmain [0x44bc93]
Any idea ?
Re: Bug in csv or byLine ?
On Friday, 8 January 2016 at 13:22:40 UTC, Tobi G. wrote: On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet wrote: On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote: No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? - DMD64 D Compiler v2.069.2 on Linux. - LDC 0.16.1 (DMD v2.067.1, LLVM 3.7.0) I ran it now under Linux/Ubuntu DMD64 D Compiler v2.069.2 But both still worked.. Are there some characters in your input data which are invalid and not displayed in the forum? (multiple empty lines after the actual csv data for example) togrue Indeed there's an empty line at the end of the csv. Interestingly enough if I try with DMD64 D Compiler v2.069, the Fail version runs fine but the normal version returns: std.csv.CSVException@/usr/include/dlang/dmd/std/csv.d(1246): Row 3's length 1 does not match previous length of 2.
Re: Bug in csv or byLine ?
On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote: No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? - DMD64 D Compiler v2.069.2 on Linux. - LDC 0.16.1 (DMD v2.067.1, LLVM 3.7.0) So if it works on windows I guess it's a problem with the File implementation. You could run DMD with the -g option. This will print often more useful output, if it fails. -g didn't bring much. core.exception.AssertError@std/algorithm/iteration.d(2027): Assertion failure ??:? _d_assert [0x4a9c33] ??:? void std.algorithm.iteration.__assert(int) [0x4b8048] /usr/include/dmd/phobos/std/algorithm/iteration.d:2027 pure @property @safe dchar std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result.front() [0x495330] /usr/include/dmd/phobos/std/csv.d:1018 void std.csv.CsvReader!(immutable(char)[], 1, std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result, dchar, immutable(char)[][]).CsvReader.popFront() [0x49608c] /usr/include/dmd/phobos/std/algorithm/iteration.d:881 void std.algorithm.iteration.__T4eachS183std5stdio7writelnZ.each!(std.csv.CsvReader!(immutable(char)[], 1, std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result, dchar, immutable(char)[][]).CsvReader).each(std.csv.CsvReader!(immutable(char)[], 1, std.algorithm.iteration.joiner!(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).joiner(std.stdio.File.ByLine!(char, char).ByLine, immutable(char)[]).Result, dchar, immutable(char)[][]).CsvReader) [0x4a5063] ./process.d:8 _Dmain [0x49226c]
Re: MurmurHash3
The last version of the code is available here and is feature complete AFAICT https://github.com/gchatelet/murmurhash3_d/blob/master/murmurhash3.d Last concern, I declared blockSize in bytes where std.digest.digest says it should be in bits. Why does it need to be bits ? It looks like HMAC (which needs it) is explicitly making sure it's always a multiple of 8 bits.
Re: We need a good code font for the function signatures on dlang.org
On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu wrote: I was looking at https://github.com/D-Programming-Language/dlang.org/pull/1169 and that bold sans serif proportional text for the code is just... well let's say it's time to replace it. What would be a good code font to use for those? Thanks, Andrei Maybe one of the monospace fonts here https://www.google.com/fonts From the about page https://www.google.com/fonts#AboutPlace:about "A web with web fonts is more beautiful, readable, accessible and open." ... "Our API service makes it easy to add Google Fonts to a website in seconds. The service runs on Google's servers which are fast, reliable and tested. Google provides this service free of charge." ... "All of the fonts are Open Source."
Re: MurmurHash3
On Sunday, 13 December 2015 at 12:44:06 UTC, Marc Schütz wrote: AFAICS this doesn't conform to the digest interface. For example, there should be a `finish` method that returns the hash as a static array (see the ExampleDigest [1]). The structs themselves do not but the alias at the beginning of the file make sure they do. alias MurmurHash3_x86_32 = Digester!SMurmurHash3_x86_32; alias MurmurHash3_x86_128 = Digester!SMurmurHash3_x86_128; alias MurmurHash3_x64_128 = Digester!SMurmurHash3_x64_128; More importantly, I believe your `put()` implementation only works if it is fed the entire data at once. I haven't tested it, but I believe that the following two calls will have a different result, while they should result in the same hash: hash.put([1,2,3,4,5,6]); vs hash.put([1,2,3]); hash.put([4,5,6]); I suspect this as well although I haven't tested. I'll add more tests and add the missing logic if needed.
Re: MurmurHash3
On Sunday, 13 December 2015 at 16:24:35 UTC, Guillaume Chatelet wrote: On Sunday, 13 December 2015 at 12:44:06 UTC, Marc Schütz wrote: [...] The structs themselves do not but the alias at the beginning of the file make sure they do. alias MurmurHash3_x86_32 = Digester!SMurmurHash3_x86_32; alias MurmurHash3_x86_128 = Digester!SMurmurHash3_x86_128; alias MurmurHash3_x64_128 = Digester!SMurmurHash3_x64_128; [...] I suspect this as well although I haven't tested. I'll add more tests and add the missing logic if needed. Fixed in last commit. Thx for the heads up Marc.
Re: MurmurHash3
On Saturday, 12 December 2015 at 02:59:21 UTC, Ilya wrote: Current version is suitable for arrays but not ranges or types. Few examples: 1. Compute hash of ulong. 2. Compute hash of all elements in matrix column (element are in different arrays). I have created output range API draft http://dpaste.dzfl.pl/a24050042758 Ilya I created https://github.com/gchatelet/murmurhash3_d and updated the code a bit. It conforms to the digest template interface, allows pushing ulong[2] and accept ranges. PR welcome :)
Re: MurmurHash3
On Friday, 11 December 2015 at 01:51:09 UTC, Ilya wrote: http://dpaste.dzfl.pl/1b94ed0aa96e#line-222 - seed is uint, can it be ulong? Done Mutmur hash has three stages: 1. Computation of hash for blocks (32bit or 128bit) 2. Compitation of hash for tail (remainder) 3. Finalization. I will be very happy, if step 1 will be represented as an output range. Then it can be used directly like reduce aggregator for ranges and multidimensional slices. Done Not thoroughly tested but updated for range and taking an ulong seed for MurmurHash3_x64_128: http://dpaste.dzfl.pl/1b94ed0aa96e Not sure I got what you meant about the optimized version. For the return value ? I haven't done any benchmarking yet.
MurmurHash3
Here is an implementation of MurmurHash [1] for D. http://dpaste.dzfl.pl/1b94ed0aa96e I'll do a proper pull request later on for addition to std.digest if the community feels like it's a valuable addition. Guillaume -- 1 - https://en.wikipedia.org/wiki/MurmurHash
C++ std::string, std::vector and name mangling
A while ago I proposed this PR [1] to add support for C++ std::string, std::vector to D. It's blocked on invalid name mangling for C++ templates [2]. I started fixing src/cppmangle.d [3] but it needs a complete rewrite. Because mangling rules are complex, I took some time to gather my findings here: https://github.com/gchatelet/gcc_cpp_mangling_documentation Once I know precisely how mangling works, I'll rewrite the linux/osx part of src/cppmangle.d. I'm short on spare time so if you're willing to help, drop me a line :) -- 1 - https://github.com/D-Programming-Language/druntime/pull/1316 2 - https://issues.dlang.org/show_bug.cgi?id=14178 3 - https://github.com/D-Programming-Language/dmd/blob/master/src/cppmangle.d
Re: GC on Rust: a serie of articles
On Wednesday, 18 November 2015 at 06:43:22 UTC, deadalnix wrote: http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how-does-gc-work/ http://blog.pnkfx.org/blog/2015/11/10/gc-and-rust-part-1-specing-the-problem/ Interesting. Thx for sharing.
Re: Lifetime study group
On Tuesday, 27 October 2015 at 02:56:56 UTC, Rikki Cattermole wrote: Is it possible to have a read only interface/receiving? Because I'm interested in the content, but not enough knowledge to actually talk about it. +1
Re: Lifetime study group
On Tuesday, 27 October 2015 at 09:48:21 UTC, Andrei Alexandrescu wrote: So I'll add you to the list then. Please add me to the list too. Thx !
Re: Vision
On Wednesday, 21 October 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote: On 10/21/2015 05:50 PM, Guillaume Chatelet wrote: For C++ vector and string I have a pull request available but it will not work until name mangling works correctly and the linux/OSX C++ name mangling is utterly broken (I don't know about windows). Also, exceptions. -- Andrei Yes you're right, that said having C++ work without exceptions would already be a huge step forward. A lot of companies (including Google) do not use exceptions.
Re: Vision
On Wednesday, 21 October 2015 at 20:50:29 UTC, Andrei Alexandrescu wrote: Better late than later. http://wiki.dlang.org/Vision/2015H2_(draft) Destroy. After we make this good I'll rename it and make it official. Andrei For C++ vector and string I have a pull request available but it will not work until name mangling works correctly and the linux/OSX C++ name mangling is utterly broken (I don't know about windows). I'm still reverse engineering some tricky cases but I'm getting there. I also made progress on rewriting the C++ name mangler in ddmd codebase. I don't have a lot of spare time so progress is slow, but I'm still on it.
Re: Idiomatic adjacent_difference
On Friday, 16 October 2015 at 11:38:35 UTC, John Colvin wrote:
import std.range, std.algorithm;
auto slidingWindow(R)(R r, size_t n)
if(isForwardRange!R)
{
//you could definitely do this with less overhead
return roundRobin(r.chunks(n), r.save.drop(1).chunks(n))
.filter!(p => p.length == n);
}
auto adjacentDiff(R)(R r)
{
return r.slidingWindow(2).map!"a[1] - a[0]";
}
Nice !
I wanted to use lockstep(r, r.dropOne) but it doesn't return a
Range :-/
It has to be used in a foreach.
Idiomatic adjacent_difference
Is there an idiomatic way to do: int[] numbers = [0, 1, 2, 3]; assert(adjacent_diff(numbers) == [1, 1, 1]); I can't find something useful in the std library.
Re: Idiomatic adjacent_difference
On Friday, 16 October 2015 at 12:03:56 UTC, Per Nordlöw wrote: On Friday, 16 October 2015 at 11:48:19 UTC, Edwin van Leeuwen wrote: zip(r, r[1..$]).map!((t) => t[1]-t[0]); And for InputRanges (not requiring random-access): zip(r, r.dropOne).map!((t) => t[1]-t[0]); That's neat. Thx guys :)
dmd AST class hierarchy as dot file
Not sure if it can be useful to someone else but I extracted the
dmd's class hierarchy as a DOT file:
digraph dlang_ast {
AddAssignExp -> BinAssignExp;
AddExp -> BinExp;
AddrExp -> UnaExp;
AggregateDeclaration -> ScopeDsymbol;
AliasDeclaration -> Declaration;
AliasThis -> Dsymbol;
AlignDeclaration -> AttribDeclaration;
AndAndExp -> BinExp;
AndAssignExp -> BinAssignExp;
AndExp -> BinExp;
AnonDeclaration -> AttribDeclaration;
ArrayExp -> UnaExp;
ArrayInitializer -> Initializer;
ArrayLengthExp -> UnaExp;
ArrayLiteralExp -> Expression;
ArrayScopeSymbol -> ScopeDsymbol;
AsmStatement -> Statement;
AssertExp -> UnaExp;
AssignExp -> BinExp;
AssocArrayLiteralExp -> Expression;
AttribDeclaration -> Dsymbol;
BinAssignExp -> BinExp;
BinExp -> Expression;
BlitExp -> AssignExp;
BoolExp -> UnaExp;
BreakStatement -> Statement;
CallExp -> UnaExp;
CaseRangeStatement -> Statement;
CaseStatement -> Statement;
CastExp -> UnaExp;
CatAssignExp -> BinAssignExp;
CatExp -> BinExp;
ClassDeclaration -> AggregateDeclaration;
ClassReferenceExp -> Expression;
CmpExp -> BinExp;
ComExp -> UnaExp;
CommaExp -> BinExp;
CompileDeclaration -> AttribDeclaration;
CompileExp -> UnaExp;
CompileStatement -> Statement;
ComplexExp -> Expression;
CompoundAsmStatement -> CompoundStatement;
CompoundDeclarationStatement -> CompoundStatement;
CompoundStatement -> Statement;
CondExp -> BinExp;
ConditionalDeclaration -> AttribDeclaration;
ConditionalStatement -> Statement;
ConstructExp -> AssignExp;
ContinueStatement -> Statement;
CtorDeclaration -> FuncDeclaration;
DVCondition -> Condition;
DebugCondition -> DVCondition;
DebugStatement -> Statement;
DebugSymbol -> Dsymbol;
Declaration -> Dsymbol;
DeclarationExp -> Expression;
DefaultInitExp -> Expression;
DefaultStatement -> Statement;
DelegateExp -> UnaExp;
DelegateFuncptrExp -> UnaExp;
DelegatePtrExp -> UnaExp;
DeleteDeclaration -> FuncDeclaration;
DeleteExp -> UnaExp;
DeprecatedDeclaration -> StorageClassDeclaration;
DivAssignExp -> BinAssignExp;
DivExp -> BinExp;
DoStatement -> Statement;
DollarExp -> IdentifierExp;
DotExp -> BinExp;
DotIdExp -> UnaExp;
DotTemplateExp -> UnaExp;
DotTemplateInstanceExp -> UnaExp;
DotTypeExp -> UnaExp;
DotVarExp -> UnaExp;
DsymbolExp -> Expression;
DtorDeclaration -> FuncDeclaration;
DtorExpStatement -> ExpStatement;
EnumDeclaration -> ScopeDsymbol;
EnumMember -> Dsymbol;
EqualExp -> BinExp;
ErrorExp -> Expression;
ErrorInitializer -> Initializer;
ErrorStatement -> Statement;
ExpInitializer -> Initializer;
ExpStatement -> Statement;
FileExp -> UnaExp;
FileInitExp -> DefaultInitExp;
ForStatement -> Statement;
ForeachRangeStatement -> Statement;
ForeachStatement -> Statement;
FuncAliasDeclaration -> FuncDeclaration;
FuncDeclaration -> Declaration;
FuncExp -> Expression;
FuncInitExp -> DefaultInitExp;
FuncLiteralDeclaration -> FuncDeclaration;
GotoCaseStatement -> Statement;
GotoDefaultStatement -> Statement;
GotoStatement -> Statement;
HaltExp -> Expression;
IdentifierExp -> Expression;
IdentityExp -> BinExp;
IfStatement -> Statement;
Import -> Dsymbol;
ImportStatement -> Statement;
InExp -> BinExp;
IndexExp -> BinExp;
IntegerExp -> Expression;
InterfaceDeclaration -> ClassDeclaration;
IntervalExp -> Expression;
InvariantDeclaration -> FuncDeclaration;
IsExp -> Expression;
LabelDsymbol -> Dsymbol;
LabelStatement -> Statement;
LineInitExp -> DefaultInitExp;
LinkDeclaration -> AttribDeclaration;
MinAssignExp -> BinAssignExp;
MinExp -> BinExp;
ModAssignExp -> BinAssignExp;
ModExp -> BinExp;
Module -> Package;
ModuleInitExp -> DefaultInitExp;
MulAssignExp -> BinAssignExp;
MulExp -> BinExp;
NegExp -> UnaExp;
NewAnonClassExp -> Expression;
NewDeclaration -> FuncDeclaration;
NewExp -> Expression;
NotExp -> UnaExp;
Nspace -> ScopeDsymbol;
NullExp -> Expression;
OnScopeStatement -> Statement;
OrAssignExp -> BinAssignExp;
OrExp -> BinExp;
OrOrExp -> BinExp;
OverDeclaration -> Declaration;
OverExp -> Expression;
OverloadSet -> Dsymbol;
Package -> ScopeDsymbol;
PeelStatement -> Statement;
PostBlitDeclaration -> FuncDeclaration;
PostExp -> BinExp;
PowAssignExp -> BinAssignExp;
PowExp -> BinExp;
PragmaDeclaration -> AttribDeclaration;
PragmaStatement -> Statement;
PreExp -> UnaExp;
PrettyFuncInitExp -> DefaultInitExp;
ProtDeclaration -> AttribDeclaration;
PtrExp -> UnaExp;
RealExp -> Expression;
RemoveExp -> BinExp;
ReturnStatement -> Statement;
ScopeDsymbol -> Dsymbol;
ScopeExp
Re: dmd AST class hierarchy as dot file
On Sunday, 20 September 2015 at 18:52:40 UTC, Andrei Alexandrescu wrote: On 09/20/2015 01:46 PM, David Nadlinger wrote: you seemed to assume that the GraphViz file by Guillaume represented the grammar structure, and I wanted to point out that it does not (at least not directly). Thanks, yah, so I assumed. I guess both would be useful! -- Andrei Added the rendered image to http://wiki.dlang.org/DMD_Source_Guide#Class_hierarchy
Re: dmd AST class hierarchy as dot file
On Sunday, 20 September 2015 at 17:26:22 UTC, Andrei Alexandrescu wrote: On 09/20/2015 05:26 AM, Guillaume Chatelet wrote: Not sure if it can be useful to someone else but I extracted the dmd's class hierarchy as a DOT file: [snip] That's great. I haven't used dot in a long time, any particular flags to invoke it etc? dot -Tpng dlang_ast.dot > dlang_ast.png dot -Tsvg dlang_ast.dot > dlang_ast.svg // great because `find` works in a browser It would be great to include the grammar graph build as an optional target in the dlang.org makefile so we can publish the resulting .gif on the site. Guillaume, could you put a PR together? As David mentioned I'm not sure it will be that useful. Probably only to people working directly in dmd. Interestingly enough, with ddmd I'm almost sure it can now be automatically generated at compile time by class introspection :)
Re: dmd AST class hierarchy as dot file
On Sunday, 20 September 2015 at 17:46:33 UTC, David Nadlinger
wrote:
which is not how the AST class hierarchy in the compiler looks.
This is not to say that having pretty pictures for both of them
can't be useful. However, you seemed to assume that the
GraphViz file by Guillaume represented the grammar structure,
and I wanted to point out that it does not (at least not
directly).
— David
Yes this is pretty dmd specific but since I'm trying (again) to
fix linux/OSX CPP name mangling I need a comprehensive
description of dmd's internals.
I'm also not convinced this is currently achievable. eg.
template void foo(A, B) {};
template void foo(int, int); // mangled as
_Z3fooIiiEvT_T0_
This template instantiation is mangled as `_Z3fooIiiEvT_T0_`.
First argument type is substituted with T_ (ie. first int which
is encoded i in the function).
Second argument type is substituted with T0_ (ie. second int
which is encoded i in the function).
dmd's internal will not create two different objects to represent
the type int. So when encoding the argument types you have int
and you can't know which one it is. Walter, if you have any idea
:) I'm still struggling to understand the semantic of the fields
of all the AST types.
This is important because is you reverse the arguments, then the
type is mangled as `_Z3fooIiiEvT0_T_` (Note the inversion of T_
and T0_).
template void foo(B, A) {};
template void foo(int, int); // mangled as
_Z3fooIiiEvT0_T_
Dmd master tests are failing with segmentation fault
Is this a known issue ? Why Auto Tester didn't catch it ? 0. OS: ArchLinux 64bits 1. Get clean dmd from master 2. make -f posix.mak AUTO_BOOTSTRAP=1 3. ./src/dmd DMD64 D Compiler v2.069-devel-b99a53f 4. make -f posix.mak test make[1]: Entering directory '/home/auser/dlang/dmd/test' Building d_do_test tool OS: linux Running runnable tests Makefile:137: recipe for target 'test_results/runnable/testbounds_on.d.out' failed make[2]: *** [test_results/runnable/testbounds_on.d.out] Segmentation fault (core dumped) Makefile:176: recipe for target 'start_runnable_tests' failed make[1]: *** [start_runnable_tests] Error 2 make[1]: Leaving directory '/home/auser/dlang/dmd/test' posix.mak:21: recipe for target 'test' failed make: *** [test] Error 2
Re: Dmd master tests are failing with segmentation fault
On Saturday, 19 September 2015 at 13:34:27 UTC, Guillaume Chatelet wrote: Is this a known issue ? Why Auto Tester didn't catch it ? It's coming from d_do_test, gdb gives this stacktrace. Program received signal SIGSEGV, Segmentation fault. 0x00460b64 in rt.deh_win64_posix.terminate() () (gdb) bt #0 0x00460b64 in rt.deh_win64_posix.terminate() () #1 0x00445578 in _d_throwc () #2 0x00409a00 in std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong, const(char[])) () #3 0x0040997d in std.exception.enforce!(Exception, bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) () #4 0x0044ef7b in std.stdio.File.LockingTextWriter.this(ref std.stdio.File) () #5 0x0044f080 in std.stdio.File.lockingTextWriter() () #6 0x0040771e in std.stdio.File.write!(immutable(char)[]).write(immutable(char)[]) () #7 0x0040769e in std.stdio.write!(immutable(char)[]).write(immutable(char)[]) () #8 0x00402d0e in d_do_test.usage() () #9 0x0040575c in D main () hmm so it's probably coming from druntime or phobos not being build with the correct dmd version...
Re: Dmd master tests are failing with segmentation fault
On Saturday, 19 September 2015 at 17:38:40 UTC, Guillaume Chatelet wrote: hmm so it's probably coming from druntime or phobos not being build with the correct dmd version... Indeed it was this, sorry for the noise.
Re: How many bytes in a real ?
On Tuesday, 25 August 2015 at 00:13:28 UTC, Xinok wrote: On Monday, 24 August 2015 at 21:55:40 UTC, Guillaume Chatelet wrote: On linux x86_64 : real.sizeof == 16 but it looks like only the first the first 10 bytes are used (ie. 80bits) Is there a way to know the real size of a real ? The best I can think of is to use the mant_dig property which returns the number of bits in the mantissa. http://dpaste.dzfl.pl/9889b3d0bd5b Thx for the proposal. I actually found this in std.math which confirms this is indeed a possibility. https://github.com/D-Programming-Language/phobos/blob/6681862b4e3a77004e8d6ec1f62cf6587e20f6d4/std/math.d#L228
How many bytes in a real ?
On linux x86_64 : real.sizeof == 16 but it looks like only the first the first 10 bytes are used (ie. 80bits) Is there a way to know the real size of a real ?
Re: How many bytes in a real ?
On Monday, 24 August 2015 at 21:58:48 UTC, rsw0x wrote: On Monday, 24 August 2015 at 21:55:40 UTC, Guillaume Chatelet wrote: On linux x86_64 : real.sizeof == 16 but it looks like only the first the first 10 bytes are used (ie. 80bits) Is there a way to know the real size of a real ? http://dlang.org/type.html largest FP size implemented in hardwareImplementation Note: 80 bits for x86 CPUs or double size, whichever is larger Yep I found this, I'd like to know this information at compile time.
Re: How many bytes in a real ?
On Monday, 24 August 2015 at 22:08:03 UTC, Guillaume Chatelet wrote: On Monday, 24 August 2015 at 21:58:48 UTC, rsw0x wrote: On Monday, 24 August 2015 at 21:55:40 UTC, Guillaume Chatelet wrote: On linux x86_64 : real.sizeof == 16 but it looks like only the first the first 10 bytes are used (ie. 80bits) Is there a way to know the real size of a real ? http://dlang.org/type.html largest FP size implemented in hardwareImplementation Note: 80 bits for x86 CPUs or double size, whichever is larger Yep I found this, I'd like to know this information at compile time. I actually found another way(1) but if someone knows how to get this information at compile time I'm still interested. Thx ! 1. https://github.com/D-Programming-Language/dmd/pull/4952
Re: std.experimental.color, request reviews
On Tuesday, 4 August 2015 at 14:24:47 UTC, Manu wrote: On 4 August 2015 at 21:01, Manu turkey...@gmail.com wrote: On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote: https://github.com/D-Programming-Language/phobos/pull/2845 I'm getting quite happy with it. I think it's a good and fairly minimal but useful starting point. It'd be great to get some reviews from here. Whats the status on this? This really should be easy to move into phobos, color is hard to mess up. I beg to differ; colour is VERY hard to mess up [...] *** I mean, VERY hard to _get right_! +1
Re: Implement Parse implementation like in Red
On Thursday, 30 July 2015 at 08:04:37 UTC, Suliman wrote: Red have very nice future called Parse http://www.red-lang.org/2013/11/041-introducing-parse.html Is it's possible to implement something like it in D/Phobos? You can have a look at Philippe Sigaud's Pegged : https://github.com/PhilippeSigaud/Pegged
Re: force inline/not-inline
On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote: I just started writing an emulator in D for some fun; I needed an application to case-study aggressive performance characteristics in hot-loop situations. I know this has come up time and time again, but I just want to put it out there again... if I were shipping this product, I would NEED forceinline + force-not-inline. I don't know if it's possible right now with GDC/LDC but did you try PGO+LTO ? Just curious.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 20:48:06 UTC, Walter Bright wrote: On 7/25/2015 11:40 AM, Tobias Müller wrote: I'm not convinced at all that checked exceptions (as implemented in Java, not C++) don't work. My suspicion is that the usual Java code monkey is just too sloppy to care and thus sees it more as a nuisance rather than the help that it is. Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java http://www.amazon.com/gp/product/0131002872/ This ? http://www.artima.com/intv/handcuffs.html
