On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications to
DMD's backend that are needed are out of reach for me right now.
If you're willing to build your own druntime, you may be able
to get by.
I'd prefer a solution th
On Thursday, 17 September 2015 at 01:35:42 UTC, Leandro T. C.
Melo wrote:
An alternative would be a LL parser generator. I think ANTLR
added a C++ target, but I don't know how mature it is.
I used C++ target of ANTLR like 13 years ago and it was fine. So
I suppose it should be mature now. ;)
On Thursday, 17 September 2015 at 01:38:02 UTC, Adam D. Ruppe
wrote:
Did you take a look at
https://github.com/Hackerpilot/libdparse/tree/master already?
Yes. libdparse and/or SDC's parser seems like some good places to
start.
I have written some poll questions concerning the design
trade-offs involved in making a good `SafeInt`/`CheckedInt` type.
They are about the actual semantics of the API, not the
internals, nor bike-shedding about names.
(`SafeInt` and `CheckedInt` are integer data types which use
`core.check
Did you take a look at
https://github.com/Hackerpilot/libdparse/tree/master already?
Hi D enthusiasts,
I'm developing a multi-language code modelling engine. The heart of
the project is a language-unifying AST, a generic pipeline of binding,
type checking, code completion, etc, and hooks that allow each
language to plug-in their specific behavior where needed. Also, the
library is
On Wed, Sep 16, 2015 at 08:06:42PM +, deadalnix via Digitalmars-d wrote:
[...]
> When you have a floating point unit, you get your 32 bits you get 23
> bits that go into the mantissa FU and 8 in the exponent FU. For
> instance, if you multiply floats, you send the 2 exponent into a
> adder, you
On Wednesday, 16 September 2015 at 22:29:46 UTC, ponce wrote:
Context: On OSX, a C program can load a D shared library but
once unloaded the next dlopen will crash, jumping into a
callback that doesn't exist anymore.
I've filed it here:
https://issues.dlang.org/show_bug.cgi?id=15060
It loo
Context: On OSX, a C program can load a D shared library but once
unloaded the next dlopen will crash, jumping into a callback that
doesn't exist anymore.
I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15060
It looks like this was known and discussed several times already:
http:
On Wednesday, 16 September 2015 at 09:52:23 UTC, ixid wrote:
On Wednesday, 16 September 2015 at 06:44:30 UTC, nazriel wrote:
On Wednesday, 16 September 2015 at 05:54:03 UTC, Andrei
Amatuni wrote:
maybe I'm doing something wrong...but the output of running
the default code snippet on the dlang.o
On Wednesday, 16 September 2015 at 21:12:11 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:53:37 UTC, deadalnix
wrote:
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know, w
On Wednesday, 16 September 2015 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know, when you have no idea what you are talking about,
you can just move on to som
On Wednesday, 16 September 2015 at 20:35:16 UTC, Wyatt wrote:
On Wednesday, 16 September 2015 at 08:53:24 UTC, Ola Fosheim
Grøstad wrote:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a company ca
On 09/16/2015 09:49 AM, nazriel wrote:
1-2 days more and we will be done with it so IMHO no need take any
additionals steps for it right now.
That's great, thanks for doing this. What is the current status with
regard to making the online compilation infrastructure publicly
accessible and imp
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know, when you have no idea what you are talking about,
you can just move on to something you understand.
Ah, nice move. Back to your usual habits?
On 9/16/2015 7:16 AM, Bruno Medeiros wrote:
On 28/08/2015 22:59, Walter Bright wrote:
People told me I couldn't write a C compiler, then told me I couldn't
write a C++ compiler. I'm still the only person who has ever implemented
a complete C++ compiler (C++98). Then they all (100%) laughed at me
On Wednesday, 16 September 2015 at 08:53:24 UTC, Ola Fosheim
Grøstad wrote:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a company called Rex Computing that are
looking at unum:
Oh hey, I remem
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix wrote:
You know, when you have no idea what you are talking about, you
can just move on to something you understand.
Ah, nice move. Back to your usual habits?
Prefetching would not change anything here. The problem come
from variable
On Wednesday, 16 September 2015 at 19:40:49 UTC, Ola Fosheim
Grøstad wrote:
You can load continuously 64 bytes in a stream, decode to your
internal format and push them into the scratchpad of other
cores. You could even do this in hardware.
1/ If you load the worst case scenario, then your p
On Wednesday, 16 September 2015 at 19:21:59 UTC, deadalnix wrote:
No you don't. Because the streamer still need to load the unum
one by one. Maybe 2 by 2 with a fair amount of hardware
speculation (which means you are already trading energy for
performances, so the energy argument is weak). The
On Wednesday, 16 September 2015 at 14:11:04 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix
wrote:
The energy comparison is bullshit. As long as you haven't
loaded the data, you don't know how wide they are. Meaning you
need either to go pessimistic an
On Wednesday, 16 September 2015 at 18:41:33 UTC, Ola Fosheim
Grøstad wrote:
I don't think this is possible to establish in the general
case. Wouldn't this require a full theorem prover? I think the
only way for that to work is to fully unroll all loops and hope
that a theorem prover can deal wi
On 09/16/2015 11:56 AM, qznc wrote:
Is there an overview of D user groups somewhere?
There is one in Berlin and one in the Valley, apparently. Walter
participates in the Cpp group in Seattle or something, if I remember
correctly.
If a Meetup group happens to list the right keywords (topics?) t
Is there an overview of D user groups somewhere?
There is one in Berlin and one in the Valley, apparently. Walter
participates in the Cpp group in Seattle or something, if I
remember correctly.
On 09/16/2015 10:17 AM, Don wrote:
So:
...
* There is no guarantee that it would be possible to implement it in
hardware without a speed penalty, regardless of how many transistors you
throw at it (hardware analogue of Amdahl's Law)
https://en.wikipedia.org/wiki/Gustafson's_law :o)
On Wednesday, 16 September 2015 at 18:01:29 UTC, Marc Schütz
wrote:
typestate(alias owner) {
this.owner := owner; // re-alias operator
this.owner.refcount++;
}
I don't think this is possible to establish in the general case.
Wouldn't this
On 09/16/2015 10:46 AM, deadalnix wrote:
On Saturday, 11 July 2015 at 18:16:22 UTC, Timon Gehr wrote:
On 07/11/2015 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
http://www.amazon.com/End-Error-Computing-Chapman-
On Wednesday, 16 September 2015 at 17:15:55 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 17:03:14 UTC, Marc Schütz
wrote:
On Tuesday, 15 September 2015 at 21:44:25 UTC, Freddy wrote:
On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
Rust style memory managemen
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix wrote:
Also, predictable size mean you can split your dataset and
process it in parallel, which is impossible if sizes are random.
I don't recall how he would deal with something similar to cache
misses when you have to promote or de
On Wednesday, 16 September 2015 at 17:15:55 UTC, Ola Fosheim
Grøstad wrote:
dostuff(r);
(File f, FileRef r) = f.unborrow(r);
Of course, files are tricky since they can change their state
themselves (like IO error). Doing that statically would require
some kind of branching mechanism with a t
On Wednesday, 16 September 2015 at 17:03:14 UTC, Marc Schütz
wrote:
On Tuesday, 15 September 2015 at 21:44:25 UTC, Freddy wrote:
On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
Rust style memory management in a library
Wait nevermind about that part, it's harder than I thought.
On Tuesday, 15 September 2015 at 21:44:25 UTC, Freddy wrote:
On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
Rust style memory management in a library
Wait nevermind about that part, it's harder than I thought.
Yeah, I thought about type-states as a way of implementing
borrowi
On Tue, Sep 15, 2015 at 07:08:01AM +0200, Daniel Kozák via Digitalmars-d wrote:
>
> http://dlang.org/changelog/2.067.0.html#gc-options
[...]
Wow that is obscure. This really needs to go into the main docs so
that it can actually be found...
T
--
People demand freedom of speech to make up for
On Wednesday, 16 September 2015 at 16:24:49 UTC, Idan Arye wrote:
No need for `reinterpret_cast`. The `close` function is
declared in the same module as the `File` struct, so it has
access to it's private d'tor.
True, so it might work for D. Interesting.
On Wednesday, 16 September 2015 at 15:57:14 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 15:34:40 UTC, Idan Arye
wrote:
Move semantics should be enough. We can declare the destructor
private, and then any code outside the module that implicitly
calls the d'tor when the var
On Wednesday, 16 September 2015 at 16:12:03 UTC, Kagamin wrote:
On Wednesday, 16 September 2015 at 13:54:36 UTC, Andrea Fontana
wrote:
I mean: to check some frequencies of common d keywords/combo
like "class", "struct", "int", "float", "if(" "while(", "(int
", "(float ", etc that are not common
On Wednesday, 16 September 2015 at 13:54:36 UTC, Andrea Fontana
wrote:
I mean: to check some frequencies of common d keywords/combo
like "class", "struct", "int", "float", "if(" "while(", "(int
", "(float ", etc that are not common in plain english used by
spammers...
Solving dcaptcha costs m
On Wednesday, 16 September 2015 at 15:34:40 UTC, Idan Arye wrote:
Move semantics should be enough. We can declare the destructor
private, and then any code outside the module that implicitly
calls the d'tor when the variable goes out of scope will raise
a compilation error. In order to "get rid
On Wednesday, 16 September 2015 at 14:34:05 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 10:31:58 UTC, Idan Arye
wrote:
What's wrong with two `open()`s in a row? Each will return a
new file handle.
Yes, but if you do it by mistake then you don't get the
compiler to check
On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros
wrote:
Me and other people from D community: "ok... now we have a new
half-baked functionality in D, adding complexity for little
value, and put here only to please people that are extremely
unlikely to ever be using D whatever any
On 02/09/2015 19:58, Walter Bright wrote:
On 8/29/2015 12:37 PM, Laeeth Isharc wrote:
In my experience you can deliver
everything people say they want, and then find it isn't that at all.
That's so true. My favorite anecdote on that was back in the 1990's. A
friend of mine said that what he an
On Wednesday, 16 September 2015 at 10:31:58 UTC, Idan Arye wrote:
What's wrong with two `open()`s in a row? Each will return a
new file handle.
Yes, but if you do it by mistake then you don't get the compiler
to check that you call close() on both. I should have written
"what if you forget cl
This piece of code (which I reduced with dustmite) gives me the
following error when I try to compile it:
$ rdmd -main parser.d parser.d(28): Error: circular
initialization of isInputRange
parser.d(31): Error: template instance
std.meta.staticMap!(handler, ArrayReader*) error instantiating
par
On 28/08/2015 22:59, Walter Bright wrote:
People told me I couldn't write a C compiler, then told me I couldn't
write a C++ compiler. I'm still the only person who has ever implemented
a complete C++ compiler (C++98). Then they all (100%) laughed at me for
starting D, saying nobody would ever use
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix wrote:
The energy comparison is bullshit. As long as you haven't
loaded the data, you don't know how wide they are. Meaning you
need either to go pessimistic and load for the worst case
scenario or do 2 round trip to memory.
That real
On Wednesday, 16 September 2015 at 13:46:07 UTC, nazriel wrote:
On Wednesday, 16 September 2015 at 06:52:57 UTC, Ola Fosheim
Grøstad wrote:
How about just using a single click recaptcha:
https://www.google.com/recaptcha/intro/index.html
Used that before - still was getting spam.
As Vladimir
On Wednesday, 16 September 2015 at 10:17:21 UTC, Dmitry Olshansky
wrote:
On 16-Sep-2015 09:44, nazriel wrote:
On Wednesday, 16 September 2015 at 05:54:03 UTC, Andrei
Amatuni wrote:
maybe I'm doing something wrong...but the output of running
the
default code snippet on the dlang.org homepage is
On Wednesday, 16 September 2015 at 06:52:57 UTC, Ola Fosheim
Grøstad wrote:
How about just using a single click recaptcha:
https://www.google.com/recaptcha/intro/index.html
Used that before - still was getting spam.
As Vladimir mentioned - it costs 0.001$ to get Captcha solved :)
On Wednesday, 16 September 2015 at 10:17:21 UTC, Dmitry Olshansky
wrote:
On 16-Sep-2015 09:44, nazriel wrote:
On Wednesday, 16 September 2015 at 05:54:03 UTC, Andrei
Amatuni wrote:
maybe I'm doing something wrong...but the output of running
the
default code snippet on the dlang.org homepage is
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:
UFCS is good but there are two huge problems:
- code completion in IDE. It'will never work.
Is is possible.
DCD plans to support it:
https://github.com/Hackerpilot/DCD/issues/13
I agree that this is a big issue, though, and is on
On Wednesday, 16 September 2015 at 06:25:59 UTC, Ola Fosheim
Grostad wrote:
On Wednesday, 16 September 2015 at 05:51:50 UTC, Tobias Müller
wrote:
Ola Fosheim Grøstad
wrote:
On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller
wrote:
There's a Blog post somewhere but I can't find it at
On 16-Sep-2015 09:44, nazriel wrote:
On Wednesday, 16 September 2015 at 05:54:03 UTC, Andrei Amatuni wrote:
maybe I'm doing something wrong...but the output of running the
default code snippet on the dlang.org homepage is:
"unable to fork: Cannot allocate memory"
not a good look
Thank you fo
On Wednesday, 16 September 2015 at 06:44:30 UTC, nazriel wrote:
On Wednesday, 16 September 2015 at 05:54:03 UTC, Andrei Amatuni
wrote:
maybe I'm doing something wrong...but the output of running
the default code snippet on the dlang.org homepage is:
"unable to fork: Cannot allocate memory"
no
On Wednesday, 16 September 2015 at 08:17:59 UTC, Don wrote:
I'm not convinced. I think they are downplaying the hardware
difficulties. Slide 34:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a com
On Saturday, 11 July 2015 at 18:16:22 UTC, Timon Gehr wrote:
On 07/11/2015 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
http://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868/ref=sr_1_1?s=b
On Wednesday, 16 September 2015 at 08:17:59 UTC, Don wrote:
On Tuesday, 15 September 2015 at 11:13:59 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
http://sites.ieee.org/scv-
On Tuesday, 15 September 2015 at 11:13:59 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
That's a pretty
57 matches
Mail list logo
