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
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
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() {
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
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:
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
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
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];
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
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:
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
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
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
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;
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
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);
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
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.
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'
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
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
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
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
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
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 re
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
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
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
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
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
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
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
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?
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
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
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?
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.
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
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
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
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
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
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.
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)(*);
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:
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);
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
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
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++
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 ^__^
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:
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 :)
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?
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
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!
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:
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
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/
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
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
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
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
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
static make() {
The return type is missing for the make() function:
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));
}
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..
$ 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],
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?
-
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 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
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
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
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;
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
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
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
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
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.
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
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 !
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
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
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))
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.
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 :)
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
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,
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
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
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
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()
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.
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
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 ?
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 ?
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
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:
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 :
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
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
1 - 100 of 148 matches
Mail list logo
