Re: Derelict-GL3 Error

[Jerry via Digitalmars-d]

Don't use glGetError() it was such a horrible design decision to 
use that for debugging. A better way to debug was introduced.


https://www.khronos.org/opengl/wiki/Debug_Output

Re: Unexpected behavior when using both alias this and object pointer

[xiren7 via Digitalmars-d-learn]

Thanks. Ali.
My previous post is not clear that I have to store class 
reference(object pointer) in void*.


My actual code is try to use libuv in D.

// genarated from uv.h, only two fields is used: 'data', 'type'.
// the document of 'data': "Space for user-defined arbitrary 
data. libuv does not use this field".
// uv_timer_t is the subclass of uv_handle_t in C. (uv_timer_t 
has all the fields defined in uv_handle_t)

struct uv_handle_t {align(8):
union {
struct {void* data; void* _; uv_handle_type type;}
ubyte[96] _payload;
}
}
struct uv_timer_t {align(8):
union {
struct {void* data; void* _; uv_handle_type type;}
ubyte[160] _payload;
}
}
...

// try to resemble the libuv object defined in C.
struct UVHandle {
uv_handle_t _uvHandle;
// subclass uv_handle_t
alias _uvHandle this;

void close() { // uv_close() }
bool isClosing() { // uv_is_closing() }
...
}

// define Timer as 'final class', in order to force Timer 
allocated in gc.

final class Timer {
UVHandle* uvHandle
// subclass UVHandle
alias uvHandle this;
...

this()
{
// malloc memory(nogc) for uv_timer_t.
uvHandle = malloc(uv_timer_t.sizeof)

// store the timer object reference in 'data',
// but 'alias uvHandle this' also overrides 'cast',
// this is the problem described as my previous post.
uvHandle.data = cast(void*) this;
}
~this() { free(uvHandle); }

void start(...) { // uv_timer_start(this.uvHandle, ...) }
void stop() { // uv_timer_stop(this.uvHandle) }
...
}

My current solution is using 'mixin template' instead of 'alias 
this' as the way to subclass:


mixin template UVHandle() { ... }
public final class Timer {
mixin UVHandle;
...
}

Re: GNU License warning:

[Joakim via Digitalmars-d]

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 01:27:02 UTC, Chris Wright wrote:

[...]


That makes no sense(it's obvious by the definition of 
derivative so you are not saying anything meaningful/useful). 
Obviously if you build an independent work you are free to 
chose a license and no one building any work off of yours or 
not can cause you problems.


[...]


I agree with you that the GPL is badly written, but we mostly 
don't use it, basically only for the gdc compiler itself, so not 
a big deal here.

Merging two arrays in a uniform order

[aberba via Digitalmars-d-learn]

Unlike array1 + array2, how can i merge arrays such that:

[a1, a1, a2, a1, a1, a2, a1] //uniform order

where a1 = child of array1,
a2 = child of array2

using a built-in function/algorithm (is/are there anything(s) in 
Phobos for this?). No manual approach.

Re: Vision document for H1 2017

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, January 13, 2017 05:33:07 Chris Wright via Digitalmars-d-announce 
wrote:
> On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via
>
> Digitalmars-d-announce wrote:
> > I don't see how it possibly could given how dynamic arrays work in D. It
> > would have to have some sort of reference counting mechanism, which
> > would likely be a nightmare with slicing
>
> On that topic, D's arrays would play nicer with both refcounting *and*
> modern garbage collectors if they were structured as base, offset, length
> instead of start, length. You could put metadata just before the start of
> the array, including the reference count.

It's actually really nice as well as performant for D's dynamic arrays to be
the way that they are. Adding any kind of reference count into them would
add overhead as well as not play nicely when you're doing stuff like slicing
pointers or static arrays, which should definitely not be ref-counted. If
you're willing to use the GC, they way that D's dynamic arrays work right
now is fantastic. And even if you're not willing to use the GC, the way they
work is great if you have other code managing their memory appropriately and
just don't use the concatentation or appending operations. Plenty of code
would not want any ref-counting to be going on when passing a dynamic array
around.

Having a ref-counted object that's like an array in addition to D's current
dynamic arrays would be fine and great for some programs, but I sure
wouldn't want to lose what we have now.

- Jonathan M Davis

Re: It is still not possible to use D on debian/ubuntu

[Elronnd via Digitalmars-d]

On Thursday, 12 January 2017 at 09:20:42 UTC, Russel Winder wrote:

DMD is not packaged by Debian or Fedora.

GDC is packaged by Debian but is not packaged by Fedora.


There are RPMs available at dlang.org, and it's trivial to 
compile GDC.

Re: Vision document for H1 2017

[Chris Wright via Digitalmars-d-announce]

On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via
Digitalmars-d-announce wrote:
> I don't see how it possibly could given how dynamic arrays work in D. It
> would have to have some sort of reference counting mechanism, which
> would likely be a nightmare with slicing

On that topic, D's arrays would play nicer with both refcounting *and* 
modern garbage collectors if they were structured as base, offset, length 
instead of start, length. You could put metadata just before the start of 
the array, including the reference count.

[Issue 13017] opEquals for null std.typecons.Nullable

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13017

--- Comment #5 from Jonathan M Davis  ---
https://github.com/dlang/phobos/pull/5032

--

[Issue 13017] opEquals for null std.typecons.Nullable

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13017

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
Blast it. The current behavior is _extremely_ annoying once you start having
member variables which are Nullable. You're forced to implement opEquals to
work around this.

--

Re: MSVC path on windows

[Ryan via Digitalmars-d-learn]

On Friday, 13 January 2017 at 03:21:52 UTC, Jeremy DeHaan wrote:

I've also thought of parsing the PATH to figure out where dmd 
is installed and extract the info from the sc.ini file.


I have both VS2013 and VS2015 installed. I have to use a project 
specific sc.ini file to match each project to the VS 
compiler/linker that was used to generate the C libraries it 
depends on.


The point is, people may have several versions of MSVC installed, 
so I think parsing the sc.ini file would be the safest way to go, 
because it will tell you the linker DMD will ultimately use. The 
other variables will just tell you what is installed. Also, 
depending on the shell you use, those environment variables may 
not be reliably set. Which is why Microsoft provides a few 
shortcuts for the different toolchain's (e.g.32 vs 64 bit) 
terminals.

Re: Vision document for H1 2017

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, January 12, 2017 21:57:37 Andrew Browne via Digitalmars-d-
announce wrote:
> On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu
>
> wrote:
> > We release a brief Vision document summarizing the main goals
> > we plan to pursue in the coming six months. This half we are
> > focusing on three things: safety, lifetime management, and
> > static introspection.
> >
> > https://wiki.dlang.org/Vision/2017H1
> >
> >
> > Andrei
>
> Is there a design document for how D will achieve safety with
> nogc?
> How does D plan to prevent leaks, use-after-free, double-free
> bugs when not using the GC?

Part of the reason that we have the GC in D is because of the safety
guarantees that you can have with a GC that you can't have with mechanisms
like malloc and free. Some amount of @nogc code can be @safe, but some of it
will never be able to be @safe. e.g. the very nature of malloc and free
makes @safe impossible in the general case. It's trivial for a piece of code
to free something that's currently in use by other code. If they're
constrained within a ref-counting system, then @safety becomes more
possible, but even then, when you have to start worrying about stuff like
weak references in order to get around circular reference problems, it gets
dicey if not impossible to make it fully @safe. It might be possible to
guarantee safety if you have a whole bunch of extra constraints like Rust
does with its borrowing stuff, but we're not going to add something like
that to D, because it's too complicated on top of everything else that we
already have.

I fully expect that certain idioms will be in place to help maintain @safety
in @nogc code, but to some extent, by abandoning the GC, you're abandoning
@safety - or at least you're making a lot more of your code need to be
@trusted, and you can rely less on the compiler to guarantee @safety for
you. Taking the freeing of memory out of the hands of the programmer like
happens with the GC is _huge_ in guaranteeing the memory safety of code.

> Will @nogc also have first class support in the language?

And what do you mean my first class support? Some features require the GC,
and I wouldn't expect it to ever be otherwise. Giving up the GC means giving
up on certain features. We don't want that list to be longer that it needs
to be, but some stuff fundamentally needs the GC to do what it does.

> Afaik the GC is currently needed for language features like array
> concatenation. Will features like array concatentation still work
> with @nogc?

I don't see how it possibly could given how dynamic arrays work in D. It
would have to have some sort of reference counting mechanism, which would
likely be a nightmare with slicing and certainly does not at all play well
with how low level D arrays are. We may very well get some sort of
ref-counted array type that has concatenation, but it would be a library
construct rather than in the language, because it doesn't need to be in the
language, and the built-in arrays would not be affected by it.

> GC allocations have a keyword 'new' (afaik 'new' currently never
> means anything other than GC allocation). Will we be able to do
> @nogc allocations by the 'new' keyword?

I very much doubt it. Constructing objects into memory is done via emplace,
which is a library construct, and there's really no need for it to be in the
language. As it is, if we were doing things from scratch, new probably
wouldn't even be a keyword. It would likely be a library construct in
druntime, because D is powerful enough that new doesn't need to be in the
language to do what it does. And in general, at this point, Walter and
Andrei don't want to put stuff in the language unless it actually needs to
be there. If it can be done with a library, it will be done with a library.
The only reason that they decided that we needed some sort of ref-counting
mechanism in the language is because they decided that it wasn't actually
possible to make it fully @safe without it being part of the language. And
even then, I'm not sure that the intention is that the ref-counting
mechanism use anything other than the GC. It's not yet clear what it's going
to look like, but previously, the talk was using the GC to take care of
circular references, which would mean that the memory was still GC-allocated
even if it were ref-counted. We'll have to wait and see though.

> Is the same code always expected to work with/without @nogc?

That would depend entirely on the code. std.experimental.allocator has a GC
allocator. So, code that is designed around it could work with the GC or
without. But the whole mechanism of newing something up and then not
worrying about ownership which happens by default with the GC doesn't play
at all nicely with how memory has to be managed via other mechanisms like
malloc and free. I don't think that it's at all reasonable to expect that
code that is written with the idea that its memory will be managed by the GC
will also work without the 

MSVC path on windows

[Jeremy DeHaan via Digitalmars-d-learn]

I'm trying to automate a build process for a project of mine, and 
I want to get the path to the MSVC toolchain DMD is using. I 
don't want to hard code any paths that may not work on some 
people's set-ups.


I know there are some environmental variables such as 
VS140COMNTOOLS, VS120COMNTOOLS, etc. Are these reliable to get 
the location for some MSVC toolchain?


I've also thought of parsing the PATH to figure out where dmd is 
installed and extract the info from the sc.ini file. Am I being 
ridiculous?

Re: GNU License warning:

[Ignacious via Digitalmars-d]

On Friday, 13 January 2017 at 01:27:02 UTC, Chris Wright wrote:
You offer an API and someone decides to build on it using the 
GPL -- no trouble there; your work is not a derivative of 
theirs, so their copyright cannot place restrictions on your 
work.


That makes no sense(it's obvious by the definition of derivative 
so you are not saying anything meaningful/useful). Obviously if 
you build an independent work you are free to chose a license and 
no one building any work off of yours or not can cause you 
problems.


You build against an open standard and the only implementation 
is GPL -- your work is a derivative of the standard, not 
necessarily the GPL'd work.


That depends. The standard could be GPL's too. Anything can be 
copyrighted and licensed how the creator wants as long as it is 
legal. In any case, that says nothing about a single work.


You build against an open standard with an MIT licensed 
implementation and someone else builds a GPL implementation -- 
no trouble there; your work is not a derivative of theirs, so 
their copyright cannot place restrictions on your work.


You haven't really said anything relevant to the post.

The issue is with how the GPL defines proper use of pre-existing 
works. The ultimately point is that they arbitrarily decide how a 
work uses another based on "fork and exec" and "library". My 
point is that those are ultimately artificial because whether we 
call a function/app through a library or through a command line, 
they are effectively the same(the difference being 
performance/convenience, which is the whole point of loading a 
library vs using the command line).


They admit this in the gpl FAQ(if you read it you will see) but 
the fact that they still create arbitrary division suggests the 
license is somewhat meaningless/incompetent.


Licenses should be more specific in their terminology and their 
behaviors and effects rather than using arbitrary divisions.


Also, while not proof, the fact that the majority of donations to 
the foundation go to the lawyers(if true) also suggest that it is 
somewhat of a scam(at the very least, something is fishy).

Re: GNU License warning:

[Chris Wright via Digitalmars-d]

You offer an API and someone decides to build on it using the GPL -- no 
trouble there; your work is not a derivative of theirs, so their 
copyright cannot place restrictions on your work.

You build against an open standard and the only implementation is GPL -- 
your work is a derivative of the standard, not necessarily the GPL'd work.

You build against an open standard with an MIT licensed implementation  
and someone else builds a GPL implementation -- no trouble there; your 
work is not a derivative of theirs, so their copyright cannot place 
restrictions on your work.

[Issue 9290] Ability to modify immutable struct members in static array assignment

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9290

Martin Krejcirik  changed:

   What|Removed |Added

Summary|Ability to modify immutable |Ability to modify immutable
   |as static array assignment  |struct members in static
   |is allowed when it must not |array assignment

--- Comment #1 from Martin Krejcirik  ---
https://github.com/dlang/dmd/pull/6435

--

Re: Vision document for H1 2017

[Andrew Browne via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


Is there a design document for how D will achieve safety with 
nogc?
How does D plan to prevent leaks, use-after-free, double-free 
bugs when not using the GC?


Will @nogc also have first class support in the language?
Afaik the GC is currently needed for language features like array 
concatenation. Will features like array concatentation still work 
with @nogc?
GC allocations have a keyword 'new' (afaik 'new' currently never 
means anything other than GC allocation). Will we be able to do 
@nogc allocations by the 'new' keyword?


Is the same code always expected to work with/without @nogc?

Re: Unexpected behavior when using both alias this and object pointer

[Ali Çehreli via Digitalmars-d-learn]

Hiding a Foo right after Impl can be a solution. However, you need to 
pass 't', not '' to the C function because


- Although it may be unexpected, cast(void*) is the specified way of 
getting the address of a class object


- Taking the address of a class reference (which 't' is one), is just 
the address of the reference itself


So, you either have to do something similar to the following or pass 
void* to the C function.


import std.stdio: writeln;
import core.stdc.stdlib: malloc;

struct Impl {
ubyte[8] payload;
}

struct ImplWithOwner {
Impl impl;
Foo owner;
}

class Foo {
ImplWithOwner *io;

Impl *payload() {
// Guaranteed by D for structs:
assert(cast(void*)io == cast(void*));
return 
}

alias payload this;

this() {
io = cast(ImplWithOwner*) malloc(Impl.sizeof);
io.owner = this;
}
}

static Foo asFoo(Impl* p) {
return (cast(ImplWithOwner*)p).owner;
}

extern(C)
void actual_C_function(Impl* data, void function(Impl*) callback) {
data.payload[0] = 42;
callback(data);
}

extern(C)
void myCallback(Impl* p) {
auto foo = p.asFoo;
assert(foo.io.impl.payload[0] == 42);
}

void main() {
auto t = new Foo();
actual_C_function(t, );
}

Ali

Re: Is there a way to get a compile-time list of all user classes?

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 12 January 2017 at 20:58:33 UTC, Max wrote:
I would like to get as a result a list of all classes that 
implement a specific user interface. Is there a way to do this?


Not at compile time, it is possible there are child classes in 
separately compiled modules or libraries (or even runtime 
plugins).

[Issue 16278] [REG2.067] undefined reference when class template is instantiated only in 'is' expression

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16278

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6351

--

Is there a way to get a compile-time list of all user classes?

[Max via Digitalmars-d-learn]

Hello,

I would like to get as a result a list of all classes that 
implement a specific user interface. Is there a way to do this?

[Issue 16598] [REG2.069] ICE with void ternary + finalizers

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16598

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6434

--

Re: GNU License warning:

[bachmeier via Digitalmars-d]

On Thursday, 12 January 2017 at 17:35:23 UTC, Ignacious wrote:

I think a license should exist that EXPLICITLY states what one 
can do with the source code and binary and what they are.


I'm not sure about what your point is with this. The GPL is 
pretty explicit about what you can do with the code. No software 
license cannot define "derivative work". That is a question of 
law.

[Issue 17083] final switch(bool) should be lowered at least to a simple if else

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17083

--- Comment #2 from b2.t...@gmx.com ---
I've seen you closed. However it is almost done in
StatementSwitchVisitor.visit(SwitchStatement ss)BreakStatement to remove in 
each case:


@@ -1987,10 +1987,11 @@ else
 ss.condition = ss.condition.semantic(sc);
 ss.condition = resolveProperties(sc, ss.condition);

 Type att = null;
 TypeEnum te = null;
+Type tb = ss.condition.type;
 while (ss.condition.op != TOKerror)
 {
 // preserve enum type for final switches
 if (ss.condition.type.ty == Tenum)
 te = cast(TypeEnum)ss.condition.type;
@@ -2146,12 +2147,82 @@ else
 {
 sc.pop();
 return setError();
 }

-sc.pop();
 result = ss;
+
+if (!te && tb && tb.ty == Tbool && ss.isFinal && ss.cases.dim == 2 &&
+cast(EqualExp) ss.condition)
+{
+EqualExp eq = cast(EqualExp) ss.condition;
+
+if (auto e = eq.toBoolean(sc))
+{
+CompoundStatement true_;
+CompoundStatement false_;
+
+dinteger_t c;
+foreach (cs; *ss.cases)
+{
+dinteger_t v = cs.exp.toInteger;
+if (v != 0)
+{
+true_ = cast(CompoundStatement) cs.statement;
+}
+else
+{
+false_ = cast(CompoundStatement) cs.statement;
+}
+c++;
+}
+if (true_ && false_)
+{
+void removeThisSwitchBreaks(CompoundStatement cs)
+{
+if (cs.statements is null)
+return;
+// TODO: remove breaks;
+}
+removeThisSwitchBreaks(true_);
+removeThisSwitchBreaks(false_);
+
+result = new IfStatement(ss.loc, null, ss.condition,
+true_, false_, false_.loc);
+}
+else ss.error("final switch(bool) cannot be converted to a
IfStatement");
+}
+}
+
+sc.pop();
 }

 override void visit(CaseStatement cs)
 {
 SwitchStatement sw = sc.sw;



Isn't this reasonable ?

--

GNU License warning:

[Ignacious via Digitalmars-d]

https://www.gnu.org/licenses/gpl-3.0.en.html
https://www.gnu.org/licenses/gpl-faq.html


http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Please%20Stop%20Using%20GNU%20Licenses
http://gng.z505.com/cult.htm


And, I should point out:


"If I write a plug-in to use with a GPL-covered program, what 
requirements does that impose on the licenses I can use for 
distributing my plug-in? (#GPLAndPlugins)


It depends on how the program invokes its plug-ins. If the 
program uses fork and exec to invoke plug-ins, then the plug-ins 
are separate programs, so the license for the main program makes 
no requirements for them.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. This means 
you must license the plug-in under the GPL or a GPL-compatible 
free software license and distribute it with source code in a 
GPL-compliant way.


If the program dynamically links plug-ins, but the 
communication between them is limited to invoking the ‘main’ 
function of the plug-in with some options and waiting for it to 
return, that is a borderline case.
Can I apply the GPL when writing a plug-in for a non-free 
program? (#GPLPluginsInNF)


If the program uses fork and exec to invoke plug-ins, then 
the plug-ins are separate programs, so the license for the main 
program makes no requirements for them. So you can use the GPL 
for a plug-in, and there are no special requirements.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. This means 
that combination of the GPL-covered plug-in with the non-free 
main program would violate the GPL. However, you can resolve that 
legal problem by adding an exception to your plug-in's license, 
giving permission to link it with the non-free main program.


See also the question I am writing free software that uses a 
non-free library.
Can I release a non-free program that's designed to load a 
GPL-covered plug-in? (#NFUseGPLPlugins)


It depends on how the program invokes its plug-ins. For 
instance, if the program uses only simple fork and exec to invoke 
and communicate with plug-ins, then the plug-ins are separate 
programs, so the license of the plug-in makes no requirements 
about the main program.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. In order to 
use the GPL-covered plug-ins, the main program must be released 
under the GPL or a GPL-compatible free software license, and that 
the terms of the GPL must be followed when the main program is 
distributed for use with these plug-ins.


If the program dynamically links plug-ins, but the 
communication between them is limited to invoking the ‘main’ 
function of the plug-in with some options and waiting for it to 
return, that is a borderline case.


Using shared memory to communicate with complex data 
structures is pretty much equivalent to dynamic linking.


See also the question I am writing free software that uses a 
non-free library."


Essentially they draw an imaginary line between using "fork and 
exec" vs linking.



"If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins"


And so we are in the realm of belief.

As we all know here that every computer program ran on a computer 
is connected by nested "data structures"... so fork and exec are 
just dereferencing linking

by an extra step.

What happens, when in the future, OS's use some other mechanism 
for execution? Is there really any difference between 
exec("app.exe") and LoadLibrary("app.dll")? (I don't mean an 
imginary difference created in the mind by obfuscated data 
structures. I'm talking about a fundamental difference(besides 
performance))



There is a lot of arbitrary language in the GNU license and the 
fact that it was created by lawyers for lawyers(see 
http://gng.z505.com/cult.htm. I realize the link looks a bit 
crackpotish but it has a lot of relevant points and if the 
numbers are right, shows more than enough proof).



As usual, it comes down to who has the biggest bank roll and 
smartest lawyers to obfuscate the issues. The push for free 
software is becoming a nonsensical pursuit like most other human 
behaviors.


I think a license should exist that EXPLICITLY states what one 
can do with the source code and binary and what they are.

[Issue 17085] [std.traits] Documentation for all traits under SomethingTypeOf missing

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17085

m.bier...@lostmoment.com changed:

   What|Removed |Added

URL|http://dlang.org/phobos/|http://dlang.org/phobos/std
   ||_traits.html

--

Re: libgmp deimos library

[Nordlöw via Digitalmars-d]

On Thursday, 12 January 2017 at 09:19:26 UTC, Russel Winder wrote:

Is the intention for this to stand with or replace std.bigint ?


I have no plan yet. I'm just gonna work on it for fun until it 
covers most of GNU MP. Pull requests are very welcome.

Re: Vision document for H1 2017

[Guillaume Chatelet via Digitalmars-d-announce]

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 :(

[Issue 16346] Enum used as a constructor evaluates to the underlying type, not to the enum type.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16346

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6431

--

Re: Vision document for H1 2017

[Nick Treleaven via Digitalmars-d-announce]

On Thursday, 12 January 2017 at 09:54:08 UTC, Mark wrote:

I think the "D for C++ programmers" page could use a revamp:

https://dlang.org/cpptod.html

At the moment it mainly explains where and how D differs from 
C++. Whoever reads it may be ready to write C++ code in D, but 
this seems pointless and may give the impression that D is just 
C++ with a different syntax plus a few minor features (strong 
typedef and the scope statement). The page doesn't mention D's 
dynamic arrays, associative arrays, ranges, UFCS, function 
attributes and so on).


It's intended to help C++ programmers switch to D, not as a 
comparison. It also links to:


https://dlang.org/ctod.html

which does mention arrays and various other small things.

(I noticed some minor things to fix and submitted a pull request).

One idea on my mind is providing various (honest, not 
specifically tailored) examples of C++ code that aims to solve 
a certain problem, and how the same problem can be solved in D 
in a better way (in some sense). I've seen this done 
effectively with Java vs. Scala.


Sounds good. I think this thread is for big issues that need core 
focus though, anyone here can and should submit documentation.

[Issue 17083] final switch(bool) should be lowered at least to a simple if else

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17083

uplink.co...@googlemail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--

Unexpected behavior when using both alias this and object pointer

[xiren7 via Digitalmars-d-learn]

The problem and the code:

import std.stdio: writeln;
import core.stdc.stdlib: malloc;

struct Impl {
ubyte[8] payload;
}

class Foo {
Impl *impl;
alias impl this;

this()
{
impl = cast(Impl*) malloc(Impl.sizeof);
}
}

class Foo2 {
ubyte[8] payload;
}

void main()
{
// alias T = Foo2;
alias T = Foo;

auto t = new T();

// what I want to do is:
// 1. cast t as pointer
// 2. passe the pointer to a extern(C) callback function
// 3. cast the pointer back to t in extern(C) callback 
function

// 4. accesse the payload field
auto payload = (cast(T) cast(void*) t).payload; // -> crashs

// the right way to get the address of the t object
writeln(*cast(void**) );  // -> 278E3373000

// the unexpected behavior
// the obvious(but wrong) way to get the address of the t 
object

writeln(cast(void*) t); // -> 278E164DAB0

// because of alias this
// cast(void*) t == cast(void*) t.payload
writeln(cast(void*) t.payload); // -> 278E164DAB0
}

My question is should let the compiler generate a warning about 
this unexpected(maybe) behavior?

Re: Primality test function doesn't work on large numbers?

[Timon Gehr via Digitalmars-d-learn]

On 10.01.2017 04:02, Elronnd wrote:

Thank you!  Would you mind telling me what you changed aside from pow()
and powm()?


1. This code:

// make 2^a = integer-1
while ((integer-1)%(pow(bigint(2), a))!=0)
a--;
m = (integer-1) / pow(bigint(2), a);

a starts out as integer-1, so this computes many big powers of two if 
integer-1 has only a few factors of 2 (which is very likely if integer 
is a random number), so I changed this to:


for(m=integer-1;m%2==0;m/=2,++a){}

where a starts from 0. Now it just counts the factors of two and m is 
computed on the fly.


2. There was a bug in the Miller-Rabin implementation. (There are two 
cases where the function should return false. Only one was present.)




diff isn't giving me readable results, since there was some
other stuff I trimmed out of the original file.  Also, while this is a
*lot* better, I still get some lag generating 1024-bit primes and I
can't generate larger primes in a reasonable amount of time.  Maybe my
genbigint() function is to blame?  It isn't efficient:

bigint genbigint(int numbits) {
bigint tmp;
while (numbits --> 0) {
tmp <<= 1;
tmp += uniform(0, 2);
}
return tmp;
}


This should be quite fine, as its running time is linear in numbits 
(when rejection sampling to get into the right range, the running time 
will still be linear in numbits in expectation). I would expect that the 
problem is pow and powm, as for the typical bases, exponents and moduli 
you use, they have running time 
Ω((log(modulus)+log(exponent))*log(exponent)). The actual asymptotic 
running time is significantly more than this bound, as multiplication is 
done using Karatsuba.



Maybe you can get a relevant speedup by using a different bigint 
implementation. The std.bigint documentation says that it is optimized 
for numbers up to ~1000 decimal digits and that you should probably use 
GMP for larger numbers. https://dlang.org/phobos/std_bigint.html

GMP also has implementations of pow and powm built-in.


Other than that:

1. You can save a constant factor of time in genbigint by generating 
more than one bit at a time. (But I don't think this is the bottleneck.)


2. Generating only odd candidates should give you a factor of two.

3. In mrprime, you should check other small primes other than 2, as a 
random number is likely to have a small prime factor.



If what you need is some fast black-box to generate large primes, you 
can probably use existing libraries.

Re: Gui in D: I miss this project

[aberba via Digitalmars-d]

On Thursday, 12 January 2017 at 07:43:18 UTC, lobo wrote:

On Thursday, 12 January 2017 at 07:24:43 UTC, aberba wrote:

On Wednesday, 11 January 2017 at 15:33:36 UTC, Sai wrote:


After all, when someone wants a cross platform D GUI library, 
the ONLY current usable choice is DLangUI.




I disagree. There is no need for a pure D GUI library. It is a 
lot of work for little value and we'd be better off with 
improved C++ interop first.


I have several cross platform projects in industry now running 
on GtkD. It works out of the box on Linux and was trivial to 
get going on Windows and Mac. It is built on a stable base and 
has a D api that is easy to use.


GtkD could use some more hands to really improve the D 
experience so I'd argue that project would be better suited to 
immediate D foundation support (after C++ interop of course).


bye,
lobo


Gtk doesn't focus much in cross platform support. Its written in 
C so no c++.


DlangUI is Pure D so future prof when gtk makes hard decisions. 
DlangUI is the closest you can get ATM. Its architecture is quite 
powerful and flexible with multiple backends. Its will work on 
Android. Plus its ready.


It could use more hands on deck to improve.

Re: Auto recursive function

[thedeemon via Digitalmars-d-learn]

On Wednesday, 11 January 2017 at 19:23:10 UTC, Razvan Nitu wrote:

Hi,

I am currently trying to create a function 
makeMultidimensionalArray which allocates memory for a 
multidimensional array.


You were very close to the answer:

auto makeMultidimensionalArray(int N, T, Allocator)(auto ref 
Allocator alloc, size_t[N] lengths)

{
static if (lengths.length == 1)
{
return makeArray!T(alloc, lengths[0]);
}
else
{
alias E = typeof(makeMultidimensionalArray!(N-1,T)(alloc, 
lengths[1..$]));

auto ret = makeArray!E(alloc, lengths[0]);
foreach (ref e; ret)
e = makeMultidimensionalArray!(N-1, T)(alloc, 
lengths[1..$]);

return ret;
}
}


The key point is that return type depends on length of "lengths" 
array (dimensionality), so if this length is only known at 
runtime this is a dependent type, something D lacks (you'll need 
Idris or Agda for those). In D return type must be known at 
compile time and hence the length of "lengths" must be a compile 
time argument. With such argument everything compiles smoothly.

Re: Alexa Skill written in D

[Chris via Digitalmars-d-announce]

On Wednesday, 11 January 2017 at 19:26:06 UTC, Walter Bright 
wrote:

On 1/11/2017 2:09 AM, Chris wrote:

On Sunday, 8 January 2017 at 22:54:58 UTC, Walter Bright wrote:

Yes. I can't because anything I post gets autobanned.

Why is that?


Probably because I posted links to articles I wrote myself. I 
didn't know at the time it was against their rules.


In that case it might help to talk to them and explain that you 
weren't aware of that rule at the time. It will also clear your 
name in case anyone wants to attack you personally ("Walter 
Bright how got banned from ...").

Re: Vision document for H1 2017

[Mark via Digitalmars-d-announce]

On Sunday, 8 January 2017 at 00:15:23 UTC, Seb wrote:

On Saturday, 7 January 2017 at 23:33:45 UTC, Benjiro wrote:
Maybe something to add ( for new users ) is something similar 
to:


http://rustbyexample.com/

Easy to use, lots of information, simple tasks that involve 
interaction for the user, feedback on success.


Do you know about the existing Dlang Tour?

https://tour.dlang.org

PRs/Issues to improve it are welcome

Its translation into a couple of languages is WIP:

https://github.com/dlang-tour


I think the "D for C++ programmers" page could use a revamp:

https://dlang.org/cpptod.html

At the moment it mainly explains where and how D differs from 
C++. Whoever reads it may be ready to write C++ code in D, but 
this seems pointless and may give the impression that D is just 
C++ with a different syntax plus a few minor features (strong 
typedef and the scope statement). The page doesn't mention D's 
dynamic arrays, associative arrays, ranges, UFCS, function 
attributes and so on). The tour does mention these features 
(under "D's gems") so maybe some of its contents can be used to 
extend the "D for C++" page.


One idea on my mind is providing various (honest, not 
specifically tailored) examples of C++ code that aims to solve a 
certain problem, and how the same problem can be solved in D in a 
better way (in some sense). I've seen this done effectively with 
Java vs. Scala.

mysql user definde functions (UDF) in D

[Martin Tschierschke via Digitalmars-d]

I am wondering has anybody tried to do it with D?

http://dev.mysql.com/doc/refman/5.5/en/adding-udf.html

By looking on the processing chain for rendering a web page, 
based on mysql data,
I thought it would be very efficient, to let mysql deliver the 
datasets already rendered as html using a template engine like 
vibe.d diet templates.


At the end of this integration process even the web server could 
be integrated in the db engine. I know this has been done as 
prove of concept for an other (db) system to deliver json data 
via http.


Any suggestion?

Regards mt.

Re: It is still not possible to use D on debian/ubuntu

[Russel Winder via Digitalmars-d]

On Thu, 2017-01-12 at 04:43 +, Elronnd via Digitalmars-d wrote:
> On Monday, 2 January 2017 at 11:15:02 UTC, Russel Winder wrote:
> > On Sun, 2017-01-01 at 16:04 -0800, Walter Bright via 
> > Digitalmars-d wrote:
> > > On 1/1/2017 3:55 PM, deadalnix wrote:
> > 
> > On Debian and Fedora DMD is not an option
> > GDC is on Debian but seemingly not on Fedora.
> 
> I run DMD and GDC both on fedora.  I'm not sure why you think 
> they're not there.

DMD is not packaged by Debian or Fedora.

GDC is packaged by Debian but is not packaged by Fedora.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: libgmp deimos library

[Russel Winder via Digitalmars-d]

On Wed, 2017-01-11 at 18:32 +, Nordlöw via Digitalmars-d wrote:
[…]
> Great. I'll merge mine and your's stuff and put it in
> 
> https://github.com/nordlow/gmp-d.git
> 
[…]

Is the intention for this to stand with or replace std.bigint ? 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Auto recursive function

[Bauss via Digitalmars-d-learn]

On Thursday, 12 January 2017 at 00:30:33 UTC, Ignacious wrote:
On Wednesday, 11 January 2017 at 19:23:10 UTC, Razvan Nitu 
wrote:

[...]



If you change the return type to a void* your code basically 
works.



void* makeMultidimensionalArray(T, Allocator)(auto ref 
Allocator alloc, size_t[] lengths)

{
if (lengths.length == 1)
{
int x = 0x01FEEF01;
return cast(void*)makeArray!T(alloc, lengths[0], x);
}
else
{
alias E = typeof(makeMultidimensionalArray!T(alloc, 
lengths[1..$]));


auto ret = makeArray!E(alloc, lengths[0]);
foreach (ref e; ret)
e = makeMultidimensionalArray!T(alloc, 
lengths[1..$]);

return cast(void*)ret;
}
}

The problem is that then you need to cast back and that 
essentially results in the original problem. Can be done but 
probably gonna have to use string mixins.


That isn't a solution and will probably introduce other bugs.

As soon as you have to result to using void* is an indication of 
bad design IMO, because it leads to very unsafe possibilities.