On Sunday, 7 December 2014 at 19:13:42 UTC, Stefan Koch wrote:
I'd like to announce that I am going to be writing a C-compiler
in D.
I will shoot videos of my progress, and I will explain how a
compiler really works.
I would be very interested in the videos, can't wait. :)
On Monday, December 8, 2014, Stefan Koch via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Please tell me what you think if that announcement, and feel free to ask
anything you
Please do post updates here. I think it would be a great show-casing of D's
capabilities.
Plotcli is a command line application (written in D) that can
create plots from text/csv files and from piped data, making it
useful during data analysis. Plotcli works best in combination
with other command line tools such as awk. Plotcli will ignore
any lines it does not understand, so it is
First two videos are up
think of them as beta quality!
https://www.youtube.com/watch?v=aeBSsuCCRFo
and
https://www.youtube.com/watch?v=crQk929crCE
On Monday, 8 December 2014 at 16:28:24 UTC, Stefan Koch wrote:
First two videos are up
think of them as beta quality!
https://www.youtube.com/watch?v=aeBSsuCCRFo
and
https://www.youtube.com/watch?v=crQk929crCE
The quality is completely shot for both audio and video. The text
is very fuzzy
On Monday, 8 December 2014 at 17:26:59 UTC, John Colvin wrote:
...The text is very fuzzy even in 720p and the audio has been
subject to some extreme lossy compression.
I don't know... in 720p I can't complain about the text but on
the otherwise in 480 is really a bit fuzzy.
Well as a
On Monday, 8 December 2014 at 17:26:59 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 16:28:24 UTC, Stefan Koch wrote:
First two videos are up
think of them as beta quality!
https://www.youtube.com/watch?v=aeBSsuCCRFo
and
https://www.youtube.com/watch?v=crQk929crCE
The quality is
On Monday, 8 December 2014 at 19:35:54 UTC, Stefan Koch wrote:
On Monday, 8 December 2014 at 17:26:59 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 16:28:24 UTC, Stefan Koch wrote:
First two videos are up
think of them as beta quality!
https://www.youtube.com/watch?v=aeBSsuCCRFo
and
On 8 December 2014 at 19:35, Stefan Koch via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Monday, 8 December 2014 at 17:26:59 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 16:28:24 UTC, Stefan Koch wrote:
First two videos are up
think of them as beta
On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote:
I want to do a C backend first.
Building an LLVM Backand out of that is a small step.
There is already a very popular C to C compiler out there. It is
called cat, and come out of the box with any UNIX like system.
On Monday, 8 December 2014 at 21:04:17 UTC, John wrote:
On Monday, 8 December 2014 at 19:35:54 UTC, Stefan Koch wrote:
think of them as beta quality!
You may have to either pause when you need to cough and sneeze
or just edit that out. I am interested in this topic but the
horrible
As a result, it is impossible to use thing like bitfields in
templates.
I'm trying to do something like
struct MySuperStruct(E) {
enum DataSize = ulong.sizeof * 8 - EnumSize!E;
import std.bitmanip;
mixin(bitfields!(
E, kind, EnumSize!E,
On 12/2/2014 2:00 PM, H. S. Teoh via Digitalmars-d wrote:
4) This isn't the end of the story. There's also this lovely bug:
https://issues.dlang.org/show_bug.cgi?id=1238
which, as its number should tell you, has been around for a LONG time.
Executive summary:
// mymod.d
On Sun, 2014-12-07 at 21:36 +, John Colvin via Digitalmars-d wrote:
[…]
Got an example? I'd be interested to see a numerical-code example
where the JVM can beat the llvm/gcc backends on a real
calculation (even if it's a small one).
π by quadrature (it's just a single loop) can show
On 12/2/2014 2:00 PM, H. S. Teoh via Digitalmars-d wrote:
However, there are major issues with scoped imports currently,
that make this otherwise ideal solution less-than-ideal, which stem from
the way 'import' is implemented in D. When the compiler encounters an
'import' statement, what it
On Sun, 2014-12-07 at 13:57 -0800, Ziad Hatahet via Digitalmars-d wrote:
Are you referring to: http://openjdk.java.net/jeps/169 ?
That is one part of it, but it alone will not achieve the goal.
--
Russel.
=
Dr
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name uword seems better).
Bye,
bearophile
On 2014-12-05 03:47, ketmar via Digitalmars-d wrote:
and what i also can't grok is test-driven developement. ah, we spent
alot of time writing that tests that we can't even run 'cause we didn't
start working on the actual code yet. it's splendid! we didn't start
the real work yet and we are
I thought I could make this work, but it's a problem. There are two meanings for
scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
scope T func(); // the function returns a 'scope' T
I have some ideas, but don't particularly like any of them. But I
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There are
two meanings for scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
scope T func(); // the function returns a 'scope' T
On 8/12/2014 10:45 p.m., Walter Bright wrote:
I thought I could make this work, but it's a problem. There are two
meanings for scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
T func() scope(this);
or:
T func(scope(this), ARGS);
It is theoretically
On 2014-12-05 10:27, Paulo Pinto wrote:
Yes, but they cannot test everything. GUI code is specially ugly as it
requires UI automation tooling.
They do exist, but only enterprise customers are willing to pay for it.
It depends on what you mean with GUI. I've been using Capybara with
On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There
are two meanings for scope when attached to a function:
T func() scope; // the 'this' pointer is
On 2014-12-07 15:20, Dicebot wrote:
To give some examples from personal experience of what frustrates me in
typical OOP testing approach:
Imagine we have a simple cache class that internally communicates with
external dht:
class Cache
{
private DhtClient client;
this(string addr) {
On 2014-12-07 11:52, Sebastiaan Koppe wrote:
I am curious how you would write tests without mocks.
It depends on how the code looks like. With code that has no external
dependencies, i.e. no networking, I usually assume that the entire
system works 100% correctly except for the part of the
On Monday, 8 December 2014 at 10:19:03 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
I'm arguing for ages that qualifier before the return type
qualify the return type, and the one after the implicit
argument. I stand by this.
Agreed.
FWIW: I'm in the
On 12/8/2014 1:52 AM, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There are two meanings
for scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
scope T func();
On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 01:38, John Colvin пишет:
On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 00:36, John Colvin пишет:
On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky
wrote:
06-Dec-2014
On 2014-12-06 16:11, Russel Winder via Digitalmars-d wrote:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript
And then something like PhantomJS [1], a headless browser, to run the
tests in.
[1] http://phantomjs.org
--
/Jacob Carlborg
On 12/8/2014 1:52 AM, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There are two meanings
for scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
scope T func();
On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
On 12/8/2014 1:52 AM, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright
wrote:
I thought I could make this work, but it's a problem. There
are two meanings
for scope when attached to a function:
T
On Monday, 8 December 2014 at 10:34:42 UTC, Walter Bright wrote:
On 12/8/2014 1:52 AM, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright
wrote:
I thought I could make this work, but it's a problem. There
are two meanings
for scope when attached to a function:
T
On 12/8/2014 2:44 AM, Marc Schütz schue...@gmx.net wrote:
On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
Another problem with that is:
void func(scope T delegate() dg);
Playing the devil's advocate:
void func(scope(T delegate()) dg);
void func(scope(T)
On 12/8/2014 2:43 AM, Marc Schütz schue...@gmx.net wrote:
On Monday, 8 December 2014 at 10:34:42 UTC, Walter Bright wrote:
On 12/8/2014 1:52 AM, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There are
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 01:38, John Colvin пишет:
On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 00:36, John Colvin пишет:
On Sunday, 7
On 4 December 2014 at 13:47, Russel Winder via Digitalmars-d
digitalmars-d@puremagic.com wrote:
It's an argument for Java over Python specifically but a bit more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
On Sunday, 7 December 2014 at 23:22:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Dec 07, 2014 at 04:58:23PM +, via Digitalmars-d
wrote:
On Sunday, 7 December 2014 at 16:08:27 UTC, H. S. Teoh via
Digitalmars-d
wrote:
Hahaha... you're right, I'm not thinking straight. OK, so
it's
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name uword seems
better).
YES.
And I want a signed variant of this (instead of the ugly
ptrdiff_t):
I want to
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There are
two meanings for scope when attached to a function:
T func() scope; // the 'this' pointer is 'scope'
scope T func(); // the function returns a 'scope' T
On Monday, 8 December 2014 at 11:40:25 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 11:02:21 UTC, Rene Zwanenburg
wrote:
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 01:38, John Colvin
On Monday, 8 December 2014 at 11:02:21 UTC, Rene Zwanenburg wrote:
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 01:38, John Colvin пишет:
On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry
On Mon, 08 Dec 2014 11:37:00 +
Dominikus Dittes Scherkl via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea.
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 01:38, John Colvin пишет:
On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 00:36, John Colvin пишет:
On Sunday, 7
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
After changing the benchmark to more carefully measure the
integration function (ldc was unfairly taking advantage of
knowing a and b at compile-time), scala does indeed win by a
small margin.
I wonder what it's managing to
On Monday, 8 December 2014 at 12:09:20 UTC, Kagamin wrote:
On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
After changing the benchmark to more carefully measure the
integration function (ldc was unfairly taking advantage of
knowing a and b at compile-time), scala does indeed
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name uword seems
better).
The char, wchar (word char) and dchar (double word char) types
seem to disagree. The
On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 11:37:00 +
Dominikus Dittes Scherkl via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly
On Mon, 08 Dec 2014 14:00:25 +
Jonathan Marler via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 11:37:00 +
Dominikus Dittes Scherkl via Digitalmars-d
digitalmars-d@puremagic.com
On Mon, 08 Dec 2014 13:49:30 +
Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name
On Mon, 08 Dec 2014 13:49:30 +
Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name
So, nobody is in favor of extending the shared attribute for heap storage?
On Monday, 8 December 2014 at 14:29:09 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 14:00:25 +
Jonathan Marler via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 11:37:00 +
On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:
So, nobody is in favor of extending the shared attribute for
heap storage?
I think people are a bit distracted with the scope proposal at
the moment.
On 12/5/14 6:09 PM, Walter Bright wrote:
On 12/4/2014 1:32 PM, Steven Schveighoffer wrote:
On 12/4/14 3:58 PM, Walter Bright wrote:
On 12/4/2014 7:25 AM, Steven Schveighoffer wrote:
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) lifetime(bar())
I'm
On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote:
[...]
As with any of these situation the convoluted hardcoded for a specific
processor code, especially assembly language will always win. I don't
care about that, I care about the fastest comprehensible code that
On 12/5/14 3:55 PM, Walter Bright wrote:
On 12/5/2014 7:27 AM, Steven Schveighoffer wrote:
Can someone who knows what this new feature is supposed to do give
some Ali
Çehreli-like description on the feature? Basically, let's strip out
the *proof*
in the DIP (the how it works and why we have
On Monday, 8 December 2014 at 08:25:36 UTC, deadalnix wrote:
As a result, it is impossible to use thing like bitfields in
templates.
I'm trying to do something like
struct MySuperStruct(E) {
enum DataSize = ulong.sizeof * 8 - EnumSize!E;
import std.bitmanip;
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 13:49:30 +
Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Personally, when I face the need for a size_t, I usually can
(and do) use auto instead. And even if I have to spell
On Monday, 8 December 2014 at 15:12:51 UTC, Steven Schveighoffer
wrote:
I think you should eliminate scope returns then. They are not
useful. I can't think of a single reason why a newly allocated
via GC or global reference return should have to be restricted
to exist only within the
On Mon, Dec 08, 2014 at 12:34:07AM -0800, Walter Bright via Digitalmars-d wrote:
On 12/2/2014 2:00 PM, H. S. Teoh via Digitalmars-d wrote:
However, there are major issues with scoped imports currently,
that make this otherwise ideal solution less-than-ideal, which stem from
the way 'import' is
On 12/7/14 4:29 PM, Walter Bright wrote:
On 12/7/2014 6:12 AM, Dicebot wrote:
But from existing cases it doesn't seem working good enough. For
example, not
being able to represent idiom of `scope ref int foo(scope ref int x) {
return x;
}` seems very limiting.
scope ref int foo(ref int x);
FWIW, I picked hp D ~2 months ago, and my first project was a
reflection library, so I've had a chance to deal with most of the
language features at least once so far. The naming and presence
of legacy C++ was a little strange, but I would leave it at that.
What was by FAR the most
On Mon, Dec 08, 2014 at 11:22:45AM +, Chris via Digitalmars-d wrote:
[...]
What I gather from all the posts about code reviews and testing is
that it's a solid mess out there, and the bigger the company the
bigger the mess. I'm pretty much the only guy who works on the code at
the moment
On 12/8/14 10:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Monday, 8 December 2014 at 15:12:51 UTC, Steven Schveighoffer wrote:
I think you should eliminate scope returns then. They are not useful.
I can't think of a single reason why a newly allocated via GC or
global
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name uword seems
better).
Bye,
bearophile
As a legacy from 16-bit era word is ushort.
I use intp and uintp.
On 12/05/2014 09:15 AM, Shammah Chancellor wrote:
I didn't notice a D meetup group in SF. Is anyone else in here
interested in doing something like this once a month?
We could have a video cast over to the Berlin meetup :).
On 12/07/2014 02:02 PM, Russel Winder via Digitalmars-d wrote:
I wonder if Copr could be used to create a Fedora project repository
for all the D bits and pieces in the way that D-Apt does things for
Debian?
https://fedorahosted.org/copr/wiki/UserDocs
Is it really worth the effort?
We're
On 12/07/2014 02:02 PM, Russel Winder via Digitalmars-d wrote:
I wonder if Copr could be used to create a Fedora project repository
for all the D bits and pieces in the way that D-Apt does things for
Debian?
https://fedorahosted.org/copr/wiki/UserDocs
There is a dmd.spec by Dejan Lekic, btw.
On 12/03/2014 09:36 PM, Jordi Sayol via Digitalmars-d wrote:
El 03/12/14 a les 19:49, Martin Nowak via Digitalmars-d ha escrit:
On 12/03/2014 02:01 AM, Brad Anderson wrote:
Why use the DigitalMars FTP?
http://downloads.dlang.org/ is the official place for them.
We should convince Brad to
On Monday, 8 December 2014 at 16:04:42 UTC, Steven Schveighoffer
wrote:
On 12/8/14 10:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Monday, 8 December 2014 at 15:12:51 UTC, Steven
Schveighoffer wrote:
I think you should eliminate scope returns then. They are not
useful.
I
On Sunday, 7 December 2014 at 21:29:50 UTC, Walter Bright wrote:
On 12/7/2014 6:12 AM, Dicebot wrote:
But from existing cases it doesn't seem working good enough.
For example, not
being able to represent idiom of `scope ref int foo(scope ref
int x) { return x;
}` seems very limiting.
On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
I thought I could make this work, but it's a problem. There
are two meanings for scope when attached to a function:
T func() scope; // the 'this' pointer is
I want to do bounds checking of 2 (4 on avx) ulongs (64-bit) at a time.
ulong2 vval = [v0, v1];
ulong2 vlow = [low, low];
ulong2 vhigh = [high, high];
int res = PMOVMSKB(vval = vlow vval vhigh);
I figured out sort of a solution, but it seems way too complicated,
because there is only signed
On Monday, 8 December 2014 at 15:07:48 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:
So, nobody is in favor of extending the shared attribute for
heap storage?
I think people are a bit distracted with the scope proposal at
the moment.
Yes, there are
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
Usually (scalar) I'd use this, which makes use of unsigned wrap
to safe one conditional
immutable size = cast(ulong)(vhigh - vlow);
if (cast(ulong)(v0 - vlow) size) {}
if (cast(ulong)(v1 - vlow) size) {}
over
if (v0 = vlow v0
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
I want to do bounds checking of 2 (4 on avx) ulongs (64-bit) at
a time.
ulong2 vval = [v0, v1];
ulong2 vlow = [low, low];
ulong2 vhigh = [high, high];
int res = PMOVMSKB(vval = vlow vval vhigh);
I figured out sort of a
On Monday, 8 December 2014 at 16:25:22 UTC, Dicebot wrote:
On Sunday, 7 December 2014 at 21:29:50 UTC, Walter Bright wrote:
On 12/7/2014 6:12 AM, Dicebot wrote:
But from existing cases it doesn't seem working good enough.
For example, not
being able to represent idiom of `scope ref int
Using the fact that a negative 64-bit integer is also a negative
32-bit integer when truncated, you could use 2x SSE2 32-bit
comparison.
- one for [v0 , v1] - [vlow, vlow] compared to [0, 0] (result
should be = 0, signed comparison)
- one for [v0 , v1] - [vhigh, vhigh] compared to [0, 0]
On Monday, 8 December 2014 at 16:57:20 UTC, ponce wrote:
Using the fact that a negative 64-bit integer is also a
negative 32-bit integer when truncated,
Oops. This assumption is wrong.
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
I want to do bounds checking of 2 (4 on avx) ulongs (64-bit) at
a time.
ulong2 vval = [v0, v1];
ulong2 vlow = [low, low];
ulong2 vhigh = [high, high];
int res = PMOVMSKB(vval = vlow vval vhigh);
I figured out sort of a
On 2014-12-08 11:36 AM, Dicebot wrote:
On Monday, 8 December 2014 at 15:07:48 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:
So, nobody is in favor of extending the shared attribute for heap
storage?
I think people are a bit distracted with the scope
On Mon, Dec 08, 2014 at 02:52:52AM -0800, Walter Bright via Digitalmars-d wrote:
On 12/8/2014 2:44 AM, Marc Schütz schue...@gmx.net wrote:
On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
Another problem with that is:
void func(scope T delegate() dg);
Playing the devil's
On 05.12.14 21:55, Walter Bright wrote:
It means that this code will be safe:
void foo(scope int* p);
p = malloc(n);
foo(p);
free(p);
The rest is all the nuts and bolts of making that work.
If it is main goal, opposite looks more natural.
void foo(int* p);
void
On 12/8/14 11:27 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Monday, 8 December 2014 at 16:04:42 UTC, Steven Schveighoffer wrote:
On 12/8/14 10:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Monday, 8 December 2014 at 15:12:51 UTC, Steven Schveighoffer wrote:
On Monday, 8 December 2014 at 17:05:09 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
I want to do bounds checking of 2 (4 on avx) ulongs (64-bit)
at a time.
ulong2 vval = [v0, v1];
ulong2 vlow = [low, low];
ulong2 vhigh = [high, high];
int res =
There is a module called std.stdint located here:
http://dlang.org/phobos/std_stdint.html
but it doesn't appear in the documentation index here:
http://dlang.org/phobos/index.html
Not only that but when looking at the source it's just publicly
importing core.stdc.stdint.
What's the deal
On 2014-12-08 11:44 AM, Martin Nowak wrote:
This is for the most performance critical instructions during GC marking.
If we can come up with some good SIMD this will result in a good speedup.
Yesterday I was surprised to learn that my unsigned wrap trick actually
slowed down some GC benchmarks
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via
Digitalmars-d wrote:
Hello.
i don't like `size_t`. for many month i avoied using it
wherever that
was possible, 'cause i feel something wrong with it.
size_t is not too bad, it's not as alien as you may think as
there is also
bitwise:
I would quote a few of these error messages, but I wouldn't be
able to reproduce them, as I have no idea why they occurred in
the first place..
You don't need to know what caused them, you have to copy your
code, minimize it progressively keeping the error message
unchanged, and
On Monday, 8 December 2014 at 16:57:44 UTC, Marc Schütz wrote:
Two issues immediately pop up:
1) scope is not transitive thus it doesn't work at all - you
still can store slice of `scope string` as only actual
ptr+length struct is protected.
2) even if it worked, existing definition of
On Monday, 8 December 2014 at 17:38:42 UTC, bearophile wrote:
bitwise:
I would quote a few of these error messages, but I wouldn't be
able to reproduce them, as I have no idea why they occurred in
the first place..
You don't need to know what caused them, you have to copy your
code,
On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
I'm arguing for ages that qualifier before the return type
qualify the return type, and the one after the implicit
argument. I stand by this.
Simple (== easy to remember), and already widely used. I agree.
In addition, for the
On 12/08/2014 11:11 AM, Martin Nowak wrote:
On 12/07/2014 02:02 PM, Russel Winder via Digitalmars-d wrote:
I wonder if Copr could be used to create a Fedora project repository
for all the D bits and pieces in the way that D-Apt does things for
Debian?
It seems that D3 is already available:
https://github.com/mbostock/d3
;-)
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp:
On 12/8/2014 8:32 AM, Dicebot wrote:
This and also another reason why storage classes seem to me inferior to type
qualifiers in general.
You might change your mind after reading the C++ language spec and noting how
ref types are a special rule in everything!
On 8 December 2014 at 16:06, Martin Nowak via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/05/2014 09:15 AM, Shammah Chancellor wrote:
I didn't notice a D meetup group in SF. Is anyone else in here
interested in doing something like this once a month?
We could have a video cast
On Monday, 8 December 2014 at 17:21:00 UTC, Gary Willoughby wrote:
There is a module called std.stdint located here:
http://dlang.org/phobos/std_stdint.html
but it doesn't appear in the documentation index here:
http://dlang.org/phobos/index.html
Not only that but when looking at the source
On 12/08/2014 02:18 PM, Russel Winder via Digitalmars-d wrote:
It seems that D3 is already available:
https://github.com/mbostock/d3
;-)
Messes with me every time people I work with talk about data visualization...
--
Matt Soucy
http://msoucy.me/
signature.asc
Description: OpenPGP
On 12/8/2014 8:25 AM, Dicebot wrote:
2) even if it worked, existing definition of scope return value makes it
impossible to use in typical idiomatic pipeline: `file.byLine.algo1.algo2`.
Either algoX is defined to take `scope ref` and thus can't return it or it is
defined to take `ref` and can't
On 2014-12-08 18:20, Gary Willoughby wrote:
There is a module called std.stdint located here:
http://dlang.org/phobos/std_stdint.html
but it doesn't appear in the documentation index here:
http://dlang.org/phobos/index.html
Not only that but when looking at the source it's just publicly
1 - 100 of 202 matches
Mail list logo