On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
D is probably at the edge of what I can tollerate
complexity-wise. And we’ll get to simplify a few things soon I
believe.
There is the core of the problem.
Because you want to understand it all, therefore it must be
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
A key line from this paper
We now have about 150 cooks; that’s not a good way to get a
On Tuesday, 29 May 2018 at 04:41:33 UTC, Komplex wrote:
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
but that happened to the linux
On Tuesday, May 29, 2018 03:43:00 TheMightWarship via Digitalmars-d wrote:
> On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> > A cautionary tale we should all keep in mind.
> >
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
> >
> >
On Tuesday, 29 May 2018 at 02:46:03 UTC, Jonathan M Davis wrote:
On Monday, May 28, 2018 05:43:23 Simen Kjærås via
Digitalmars-d-learn wrote:
On Sunday, 27 May 2018 at 17:42:15 UTC, Sobaya wrote:
> I'd like to get symbols that have an UDA.
>
> But when the member is private, it is not obtained.
On Tuesday, 29 May 2018 at 04:49:34 UTC, Nicholas Wilson wrote:
On Tuesday, 29 May 2018 at 01:43:17 UTC, Mike Parker wrote:
In pdf.h, that CAPI macro is used in every function
declaration. That means that on Windows, all of the functions
have the __stdcall calling convention (which, in D,
On Tuesday, 29 May 2018 at 01:43:17 UTC, Mike Parker wrote:
In pdf.h, that CAPI macro is used in every function
declaration. That means that on Windows, all of the functions
have the __stdcall calling convention (which, in D, would be
extern(Windows)) and the standard cdecl calling convetion
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
but that happened to the linux kernel too, long ago?
and yet...it's everywhere..and
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://issues.dlang.org/show_bug.cgi?id=18905
--- Comment #3 from Walter Bright ---
https://github.com/dlang/dmd/pull/8304
--
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
On Monday, May 28, 2018 05:43:23 Simen Kjærås via Digitalmars-d-learn wrote:
> On Sunday, 27 May 2018 at 17:42:15 UTC, Sobaya wrote:
> > I'd like to get symbols that have an UDA.
> >
> > But when the member is private, it is not obtained.
> >
> > And I found a comment saying "Filtering
On 5/28/2018 6:54 PM, 12345swordy wrote:
No doubt that all this complexity is partially due to having a religious like
zeal when it comes to preserving backwards compatibility.
I mean create a new official file extension, so that it can make much needed
breaking changes on it.
For all the
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombinator.com/item?id=17172057
On Monday, 28 May 2018 at 21:05:00 UTC, Dr.No wrote:
On Monday, 28 May 2018 at 02:10:48 UTC, sarn wrote:
On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
What's likely the reason of the crash? mismatch between D and
C memory alignment?
From an ABI point of view, the raw pointers won't
On Thursday, 24 May 2018 at 18:51:31 UTC, Mike Franklin wrote:
I'm trying to find a way to declare a block of code `nothrow:`
when compiling with -betterC, but not `nothrow` when not
compiling with -betterC.
The solution is needed for this PR:
On 5/28/18 9:51 AM, James Blachly wrote:
Why are the class objects special in this case, and why does
`immutable(C)[]` not help? I believed that this defined a dynamic
array `c` which was itself mutable, the elements of which were immutable.
To build on what others have said, the key thing
On Monday, 28 May 2018 at 07:52:43 UTC, Adam Wilson wrote:
I understand that.
Sorry, not for nothing, but you obviously don't. For starters,
if you were familiar with the key derivation tools available
24hrs ago, you wouldn't have come up with PBKDF2 on PBKDF2. I
suggest slowing down a
https://issues.dlang.org/show_bug.cgi?id=18871
Mike Franklin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=18871
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #6
https://issues.dlang.org/show_bug.cgi?id=18880
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #4
On Monday, 28 May 2018 at 22:37:01 UTC, sarn wrote:
On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
[...]
Code using destroy() can still use destroy(). Otherwise,
__vdtor would be callable in the same way that __dtor and
__xdtor are.
[...]
Interesting... You don't mind me
On Monday, 28 May 2018 at 21:04:21 UTC, Dr.No wrote:
import std.parallelism : parallel;
foreach(t; parallel(arr))
{
if(!doSomething(t)) {
return false;
}
On Monday, 28 May 2018 at 21:04:21 UTC, Dr.No wrote:
import std.parallelism : parallel;
foreach(t; parallel(arr))
{
if(!doSomething(t)) {
return false;
}
On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
How is __vdtor is going to be called, via destroy or via
directly?
Code using destroy() can still use destroy(). Otherwise, __vdtor
would be callable in the same way that __dtor and __xdtor are.
The plan is to have a better, safer,
https://issues.dlang.org/show_bug.cgi?id=18884
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #2
this might help you,
https://dpaste.dzfl.pl/2cf844a11e3f
you can use them to generate the functions as strings.
import std.parallelism : parallel;
foreach(t; parallel(arr))
{
if(!doSomething(t)) {
return false;
}
}
It reuturns the run time error:
On Monday, 28 May 2018 at 02:10:48 UTC, sarn wrote:
On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
What's likely the reason of the crash? mismatch between D and
C memory alignment?
From an ABI point of view, the raw pointers won't care about
the memory structure they point to. The
On Monday, 28 May 2018 at 11:51:20 UTC, Simen Kjærås wrote:
On Monday, 28 May 2018 at 09:59:50 UTC, DigitalDesigns wrote:
Implementing interfaces can be a pain but are necessary.
I like to use abstract classes and provide a base
implementation. It would be cool if I could use D's awesome
On Monday, 28 May 2018 at 04:26:02 UTC, sarn wrote:
On Sunday, 27 May 2018 at 22:27:52 UTC, sarn wrote:
I've been thinking this through a bit, and here's what I've
got so far:
Here's a tweak that should be implementable without any
language changes:
Instead of trying to detect an empty
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar
wrote:
Now that D has a better C option I was wondering if it is
possible to create a small subset of D that can be used as
embedded JIT library. I would like to trim the language to a
small subset of D/C - only primitive types and
On 05/28/2018 11:47 AM, candle wrote:
Hey Folks.
I have a question about threading and how to close threads i don't need
anymore.
In the following code, i build 3 threads with spawn from the concurrency
module.
if one thread found the number, all others thread must stop search.
but i
sorry about my double post, but:
the receive in the search function, was first under (in) the
(guess =! searchFor) block, but it was the same effect. for
testing i have these writeln("test1 and 2").
writeln(guess) i have never seen.
is receive a loop itself ?
https://issues.dlang.org/show_bug.cgi?id=18868
--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/849155631cba3017566d3160cf15cb40584abf10
fix Issue 18868 - nondeterministic static ctor/dtor
Instead
https://issues.dlang.org/show_bug.cgi?id=18868
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Hey Folks.
I have a question about threading and how to close threads i
don't need anymore.
In the following code, i build 3 threads with spawn from the
concurrency module.
if one thread found the number, all others thread must stop
search.
but i have a big logical problem in my mind.
https://issues.dlang.org/show_bug.cgi?id=18892
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=18892
--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/6171f9e6980347b8678926034fb5757e513f0206
Fix Issue 18892 - Wrong type in error message for static
On Monday, 28 May 2018 at 13:51:49 UTC, James Blachly wrote:
Consider the below:
```
class C
{
int x;
}
struct S
{
int x;
}
void main()
{
immutable C[] c = [ new C(), new C()];
immutable S[] s = [ S(), S() ];
immutable int[] i = [ 1, 2 ];
auto x = c.dup;
On Monday, May 28, 2018 13:51:49 James Blachly via Digitalmars-d-learn
wrote:
> Consider the below:
>
> ```
> class C
> {
> int x;
> }
>
> struct S
> {
> int x;
> }
>
>
> void main()
> {
> immutable C[] c = [ new C(), new C()];
> immutable S[] s = [ S(), S() ];
> immutable
Consider the below:
```
class C
{
int x;
}
struct S
{
int x;
}
void main()
{
immutable C[] c = [ new C(), new C()];
immutable S[] s = [ S(), S() ];
immutable int[] i = [ 1, 2 ];
auto x = c.dup;
auto y = s.dup;
auto z = i.dup;
}
```
This fails to
https://issues.dlang.org/show_bug.cgi?id=18892
Mike Franklin changed:
What|Removed |Added
Keywords||pull
https://issues.dlang.org/show_bug.cgi?id=18866
--- Comment #4 from Simen Kjaeraas ---
> there would be absolutely no way of calling fun1() from within the
> WithStatement body
Sure there would. Assuming the same code as in comment 0, you would call the
global fun2 using
https://issues.dlang.org/show_bug.cgi?id=18866
RazvanN changed:
What|Removed |Added
CC|
On Monday, 28 May 2018 at 09:59:50 UTC, DigitalDesigns wrote:
Implementing interfaces can be a pain but are necessary.
I like to use abstract classes and provide a base
implementation. It would be cool if I could use D's awesome
meta features to extract the interface from the abstract class
On Sunday, 27 May 2018 at 16:00:15 UTC, Jonathan M Davis wrote:
On Sunday, May 27, 2018 16:28:56 Russel Winder via
Digitalmars-d-learn wrote:
[...]
Honestly, I'd suggest that folks never use in at this point.
There's zero benefit to it. In principle, in was supposed to be
const scope, but
Might be interesting to checkout to find some optimization potential:
https://github.com/dyu/ffi-overhead
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
On 28/05/2018 10:16 PM, Robert M. Münch wrote:
Might be interesting to checkout to find some optimization potential:
https://github.com/dyu/ffi-overhead
https://github.com/dyu/ffi-overhead/issues/5
https://issues.dlang.org/show_bug.cgi?id=3680
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
Implementing interfaces can be a pain but are necessary.
I like to use abstract classes and provide a base implementation.
It would be cool if I could use D's awesome meta features to
extract the interface from the abstract class then build it. This
requires some funky stuff which I'm not
https://issues.dlang.org/show_bug.cgi?id=15125
RazvanN changed:
What|Removed |Added
CC|
On 05/28/2018 12:14 AM, sarn wrote:
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote:
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three salts and
three lengths in the header. One for
On Thursday, 24 May 2018 at 18:51:31 UTC, Mike Franklin wrote:
I'm trying to find a way to declare a block of code `nothrow:`
when compiling with -betterC, but not `nothrow` when not
compiling with -betterC.
[...]
Not one now but, DIP 1012 will allow this as nothrow will become
a regular
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote:
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three
salts and three lengths in the header. One for the PBKDF2
KDK, one for the MAC
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three salts and
three lengths in the header. One for the PBKDF2 KDK, one for the MAC
key, and one for the encryption key.
HKDF-Expand doesn't need
On Sunday, 27 May 2018 at 20:38:25 UTC, Daniel Kozak wrote:
I would rewrite it to something like this:
template BTree(ValueT, KeyT = ValueT,alias KeyF =
unaryFun!"cast(const)a")
{
class BTree
{
This is roughly what I originally had, but it creates a number of
problems that I wanted
59 matches
Mail list logo