Re: Implement the "unum" representation in D ?

[Nick B via Digitalmars-d]

On Tuesday, 20 September 2016 at 22:52:57 UTC, Nic Brummell wrote:
If anyone is still interested in this concept whatsoever, we 
are holding a mini-workshop on the current developments of 
Unums at the University of California Santa Cruz on Oct 24th.  
We'd love to have some participation from interested parties, 
including presentations on any attempts to implement (in D?) 
etc.  Please see https://systems.soe.ucsc.edu/2016-symposium or 
contact me via here.  Nic.




Nic

Thanks for the heads up.  John Gustafson will have the best 
understanding as to the progress to implement this in "C" I 
believe.  Perhaps you could post back an update after the 
conference ?


Nick

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #20 from Andrei Alexandrescu  ---
(In reply to Martin Nowak from comment #17)
> Not allowing to put any class into read-only segments, just b/c someone
> might want to synchronize on it, is not very convincing.
> Also remember that we wanted to get rid of the extra 8-byte for monitor
> unless explicitly requested
> http://forum.dlang.org/post/xpliectmvwrwthamq...@forum.dlang.org.

Fair enough.

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #19 from Andrei Alexandrescu  ---
(In reply to Martin Nowak from comment #18)
> (In reply to Andrei Alexandrescu from comment #13)
> > Can someone produce an example in which invariants promised by D's system
> > are broken?
> 
> Just look at core.sync, none of the methods can be implemented const or
> pure, still they get called from const/pure code.

That's not a problem, the runtime is expected to contain nonportable code.

--

Re: Why I am switching to Go

[dewitt via Digitalmars-d]

On Wednesday, 21 September 2016 at 01:15:22 UTC, deadalnix wrote:

On Tuesday, 20 September 2016 at 20:59:18 UTC, wobbles wrote:
I would say otherwise. I've built multiple sites in vibe-d, so 
I probably wouldn't need them, but having a vibe-d specific 
beginner tutorial from start to end of a project would be 
great.




Tutorial != doc.


I agree and if you know web development and have done any 
significant development vibe should not be hard to learn off the 
docs.  If the OP was to say anything about ecosystem then yes Go 
maybe a better option for the OP.  I don't think vibe is bad but 
ecosystem is more lacking for the developer who just wants stuff 
to work and not put in the leg work on fixing bugs/features in 
various pieces of the development of web applications.

Re: D and math, can you isolate this ?

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 12:35:18 UTC, Basile B. wrote:
I've recently started an easing/interpolation family of 
function in my D user library. It's based on something I know 
well since I've already used them in 2012 in a VST plugin 
called GrainPlot (RIP).


However for one of the function, I can't manage to get the 
inverse.


A function that's fully implemented:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L598
- f(x,c) = x*x*x - x*x*c + x*c;
- c(f(0.5)) = 4 * (y - 0.125));

Another:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L749
- f(x,c) = pow(x, c);
- c(f(0.5)) = log(y) / log(0.5));

The problem is here:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L849
- f(x,c) = 1.0 - pow(1.0 - pow(x, 2.0/c), c * 0.5);
- c(f0.5)) = ?

Which means that I ask you if you can isolate c for

y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);

y is always f(0.5,c)


So if we rearrange and take the logs of both sides and divide by 
c we get


2*log(1-y)/c = log(1-2^(-2/c))

and then that we have one occurrence of c on each side do an 
iterative back substitution to find the intersection given that 
you know for y=0.5 ,c = 2.
We used this method for finding voltages and currents in circuits 
with semiconductors.

Re: Why I am switching to Go

[deadalnix via Digitalmars-d]

On Tuesday, 20 September 2016 at 20:59:18 UTC, wobbles wrote:
I would say otherwise. I've built multiple sites in vibe-d, so 
I probably wouldn't need them, but having a vibe-d specific 
beginner tutorial from start to end of a project would be great.




Tutorial != doc.

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #18 from Martin Nowak  ---
(In reply to Andrei Alexandrescu from comment #13)
> Can someone produce an example in which invariants promised by D's system
> are broken?

Just look at core.sync, none of the methods can be implemented const or pure,
still they get called from const/pure code.
In fact Object.Monitor simply declares that lock/unlock doesn't need to have
any attributes
https://github.com/dlang/druntime/blob/e9c7878928330aa34e6ba5c5863ed5507e02248e/src/object.d#L97-L101,
but synchronized forges guarantees that aren't there.

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #17 from Martin Nowak  ---
(In reply to Andrei Alexandrescu from comment #15)
> That's not the case. The compiler knows the object has mutable metadata and
> won't allow placing it in read-only pages.

Not allowing to put any class into read-only segments, just b/c someone might
want to synchronize on it, is not very convincing.
Also remember that we wanted to get rid of the extra 8-byte for monitor unless
explicitly requested
http://forum.dlang.org/post/xpliectmvwrwthamq...@forum.dlang.org.

Turning synchronized into a lowering for lock/unlock (with monitor support as
fallback) would not only allow correct attribute inference (w/o making global
decisions for everyone, @nogc, ...), it's also a less overhead for the
core.sync classes to not go through the virtual monitor indirections [¹].

[¹]:
https://github.com/dlang/druntime/blob/15a227477a344583c4748d95492703901417f4f8/src/rt/monitor_.d#L59

--

Re: What exactly does the compiler switch -betterC do?

[Anonymouse via Digitalmars-d-learn]

On Monday, 20 June 2016 at 06:35:32 UTC, Jacob Carlborg wrote:

On 2016-06-19 21:53, Gary Willoughby wrote:
When compiling, what exactly does the -betterC flag do? The 
command help
says "omit generating some runtime information and helper 
functions" but

what does this really mean? Is there any specifics somewhere?


It is intended to allow you to link an application without 
druntime. [...]


What is the equavilent in gdc and ldc?

[Issue 16515] Linker Error When Using -debug

[via Digitalmars-d-bugs]

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

--- Comment #1 from gyroh...@gmail.com ---
The linker being for "test.v.init", it seems it is trying to create
"test.q.init" but can't as it can't find the symbol for "test.v.init". Though
it shouldn't be constructing "test.q.init" anywhere, removing "-debug" from the
compiler option fixes the issue.

--

[Issue 16516] New: Linker Error for ModuleInfo

[via Digitalmars-d-bugs]

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

  Issue ID: 16516
   Summary: Linker Error for ModuleInfo
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: gyroh...@gmail.com

Created attachment 1615
  --> https://issues.dlang.org/attachment.cgi?id=1615=edit
attached file

Not exactly sure why this is being caused, but I don't think it should be a
linker problem. I get this linker error:

Error 42: Symbol Undefined _D4test6second1t12__ModuleInfoZ 

I've tried to narrow it down as much as possible. Removing any import from any
file in import/source/test/ seems to fix the issue.

--

Re: Append const to array

[Yuxuan Shui via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 22:38:33 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 20, 2016 22:23:08 Yuxuan Shui via 
Digitalmars-d-learn wrote:

struct A {
  ulong[] x;
}
struct B {
  ulong x;
}
void main() {
  B[] b;
  const(B) xx = B(1);
  b ~= xx; // Works

  A[] c;
  const(A) yy = A([1]);
  c ~= yy; // Does not
}

What gives?


const(A) means that the ulong[] inside is const(ulong[]). When 
yy is copied
to be appended to c, it goes from const(A) to A, which means 
that
const(ulong[]) would need to be sliced and and set to ulong[], 
which would
violate const, because it would mean that the last element in c 
could mutate
then elements of its x, which would then mutate the elements in 
yy.


- Jonathan M Davis


That makes sense, thanks.

Re: Why I am switching to Go

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 20 September 2016 at 22:17:26 UTC, WhatMeWorry wrote:

On Tuesday, 20 September 2016 at 20:35:49 UTC, Daniel Koz
wrote:



Dne 20.9.2016 v 22:01 Karabuta via Digitalmars-d napsal(a):

[...]
Nothing of this is specific for vibe.d, so I do not see any 
reason to have doc about this in vibe.d


Could he be asking for little examples of the above bullets?  
Maybe small working examples online?


It would help a lot just to pull out the unit tests and add a few 
comments and put them up on web under sample usage...   I 
suggested to Sonke before,  but there's always a lot to do.

Re: Implement the "unum" representation in D ?

[Nic Brummell via Digitalmars-d]

If anyone is still interested in this concept whatsoever, we are 
holding a mini-workshop on the current developments of Unums at 
the University of California Santa Cruz on Oct 24th.  We'd love 
to have some participation from interested parties, including 
presentations on any attempts to implement (in D?) etc.  Please 
see https://systems.soe.ucsc.edu/2016-symposium or contact me via 
here.  Nic.



On Saturday, 20 February 2016 at 23:38:52 UTC, Nick B wrote:

On Saturday, 20 February 2016 at 23:25:40 UTC, Nick B wrote:

On Wednesday, 17 February 2016 at 16:35:41 UTC, jmh530 wrote:

On Wednesday, 17 February 2016 at 08:11:21 UTC, Nick B wrote:




Having just looked at the slides again, I believe this will 
break compatibility with std.math, (for example it throws out 
NaN), just as D has broken full compatibility with all of C++.


UNUM II  is also proposing to break completely from IEEE 754 
floats and gain Computation with mathematical rigor ...


Can anyone tell me who are the maths experts, and hard science 
users, around here ?



Nick

Re: Why I am switching to Go

[jmh530 via Digitalmars-d]

On Tuesday, 20 September 2016 at 21:19:49 UTC, Daniel Kozak wrote:


My fault. I was speaking about doc (API), I do not say anything 
about tutorial and so on. Yes I belive having more tutorials 
and howtos it is a good thing.


I don't think anyone would disagree wrt tutorials and how tos. I 
don't think anyone has mentioned D Web Development, which the OP 
might find a good source.

[Issue 16423] ModuleInfo missing when linking to static lib with classes

[via Digitalmars-d-bugs]

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

--- Comment #4 from Martin Nowak  ---
Another rather obvious solution is to tell the linker to include the whole
archive, sensibly named --whole-archive/--no-whole-archive for ld.

Unfortunately dmd currently reorders linker flags (see issue 15574), so the
following doesn't work.

  -L--whole-archive mystaticlib.a -L--no-whole-archive

Instead you'll have to invoke cc for linking yourself atm.

--

Re: Append const to array

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 20, 2016 22:23:08 Yuxuan Shui via Digitalmars-d-learn 
wrote:
> struct A {
>   ulong[] x;
> }
> struct B {
>   ulong x;
> }
> void main() {
>   B[] b;
>   const(B) xx = B(1);
>   b ~= xx; // Works
>
>   A[] c;
>   const(A) yy = A([1]);
>   c ~= yy; // Does not
> }
>
> What gives?

const(A) means that the ulong[] inside is const(ulong[]). When yy is copied
to be appended to c, it goes from const(A) to A, which means that
const(ulong[]) would need to be sliced and and set to ulong[], which would
violate const, because it would mean that the last element in c could mutate
then elements of its x, which would then mutate the elements in yy.

- Jonathan M Davis

Append const to array

[Yuxuan Shui via Digitalmars-d-learn]

struct A {
ulong[] x;
}
struct B {
ulong x;
}
void main() {
B[] b;
const(B) xx = B(1);
b ~= xx; // Works

A[] c;
const(A) yy = A([1]);
c ~= yy; // Does not
}

What gives?

[Issue 16515] New: Linker Error When Using -debug

[via Digitalmars-d-bugs]

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

  Issue ID: 16515
   Summary: Linker Error When Using -debug
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: gyroh...@gmail.com

Created attachment 1614
  --> https://issues.dlang.org/attachment.cgi?id=1614=edit
proj

I get a linker error for "test.v" even though "test.q" is never used. If you
remove the "test.v" member from "test.q" then the linker error no longer
happens.

struct Q(_T)
{
V!(1, _T) v; // removing this fixes link error
}

--

[Issue 16423] ModuleInfo missing when linking to static lib with classes

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Nowak  ---
It goes against the intention of static libraries to drag unused classes and
module into a binary, and that also goes against our permanent fight against
giant binaries.
In fact there is issue 14555 and a PR (https://github.com/dlang/dmd/pull/4638)
in the adverse direction.

If you really want to drag in all classes from a static library, one approach
is to reference all of them from a common module.
Having an explicit list of all classes kind of contradicts the purpose of
Object.factory, but I don't see how we can easily achieve both.

Another approach is to generate object files for each module and explicitly
link against all of them (the linker won't discard object files).

Dub supports this as --build-mode=singleFile IIRC.

Yet another approach is to use shared libraries instead.

--

Re: Why I am switching to Go

[WhatMeWorry via Digitalmars-d]

On Tuesday, 20 September 2016 at 20:35:49 UTC, Daniel Kozak wrote:



Dne 20.9.2016 v 22:01 Karabuta via Digitalmars-d napsal(a):

[...]
Nothing of this is specific for vibe.d, so I do not see any 
reason to have doc about this in vibe.d


Could he be asking for little examples of the above bullets?  
Maybe small working examples online?

Re: Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 20 September 2016 at 14:41:19 UTC, Bastiaan Veelo 
wrote:

The entry for 2.071.2 seems to be missing in the side panel.


Right, my mistake, even more manual maintenance.
We should really finish the tooling support for changelogs.

https://github.com/dlang/dlang.org/pull/1483

BTW, everyone is free to submit fixes for such issues, in the 
longterm this scales much better than having many people tell me 
what to do ;).

Re: Why I am switching to Go

[Daniel Kozak via Digitalmars-d]

Dne 20.9.2016 v 22:59 wobbles via Digitalmars-d napsal(a):


On Tuesday, 20 September 2016 at 20:35:49 UTC, Daniel Kozak wrote:



Dne 20.9.2016 v 22:01 Karabuta via Digitalmars-d napsal(a):

On Tuesday, 20 September 2016 at 19:47:12 UTC, WebFreak001 wrote:

On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is dying 
suggests that putting any effort in to it will be a waste. Go, 
OTH, has tons of frameworks, most are actively support, very well 
documented(beego, revel, etc), and feature rich.


What is vibe.d missing? It works great for me and the documentation 
is great imo too because it has everything I need. I use vibe.d at 
the company I work at and I use it for all my websites. I never had 
any problems with it


Lets me say from a beginners perspective,
* How do I build a file upload form (single and multiple file uploads)
* How do I work with mongoDB to do CRUD.
* How do I use the Web API beyond hello world!
* Form validation?
* Data sanitization?
* How do I structure my application for real-world (reusable and 
maintainable code) e.g for a simple blog, simple CMS etc. :)

...

Some of these things may seem easy to figure-out but can be 
difficult for a beginner unless he/she has a copy of Kai's book at 
the moment (D Web Development) :)
Nothing of this is specific for vibe.d, so I do not see any reason to 
have doc about this in vibe.d


I would say otherwise. I've built multiple sites in vibe-d, so I 
probably wouldn't need them, but having a vibe-d specific beginner 
tutorial from start to end of a project would be great.


Sonke wrote a good blog post a while back with a chat system, and 
there's a new blogger using vibe too. But we could do with more.
I guess I should take that up maybe. Not sure if I have the time 
though, and I don't  have a whole pile of interest in blogging...


My fault. I was speaking about doc (API), I do not say anything about 
tutorial and so on. Yes I belive having more tutorials and howtos it is 
a good thing.

Re: Why I am switching to Go

[wobbles via Digitalmars-d]

On Tuesday, 20 September 2016 at 20:35:49 UTC, Daniel Kozak wrote:



Dne 20.9.2016 v 22:01 Karabuta via Digitalmars-d napsal(a):
On Tuesday, 20 September 2016 at 19:47:12 UTC, WebFreak001 
wrote:
On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller 
wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is 
dying suggests that putting any effort in to it will be a 
waste. Go, OTH, has tons of frameworks, most are actively 
support, very well documented(beego, revel, etc), and 
feature rich.


What is vibe.d missing? It works great for me and the 
documentation is great imo too because it has everything I 
need. I use vibe.d at the company I work at and I use it for 
all my websites. I never had any problems with it


Lets me say from a beginners perspective,
* How do I build a file upload form (single and multiple file 
uploads)

* How do I work with mongoDB to do CRUD.
* How do I use the Web API beyond hello world!
* Form validation?
* Data sanitization?
* How do I structure my application for real-world (reusable 
and maintainable code) e.g for a simple blog, simple CMS etc. 
:)

...

Some of these things may seem easy to figure-out but can be 
difficult for a beginner unless he/she has a copy of Kai's 
book at the moment (D Web Development) :)
Nothing of this is specific for vibe.d, so I do not see any 
reason to have doc about this in vibe.d


I would say otherwise. I've built multiple sites in vibe-d, so I 
probably wouldn't need them, but having a vibe-d specific 
beginner tutorial from start to end of a project would be great.


Sonke wrote a good blog post a while back with a chat system, and 
there's a new blogger using vibe too. But we could do with more.
I guess I should take that up maybe. Not sure if I have the time 
though, and I don't  have a whole pile of interest in blogging...

Scitools & D support?

[Robert M. Münch via Digitalmars-d]

Hi, not sure if any of you know this "understand" tool from [1]? It's 
pretty cool if you need to get into legacy or foreign code bases fast. 
IMO it would be great if they would add D as well.


I'm not sure if I have the full overview about all libs, etc. that can 
help parsing D code and/or rule sets for semantic, syntactic checks 
etc. But I can imagine if we collect a good bunch of information for 
them, the chances might be pretty high that it will be added.



They are currently supporting (from their web-site);

Ada: Understand supports Ada83, Ada95, Ada05 and Ada2012 code 
separately, or in combination.


Assembly Understand currently supports Coldfire 68k and JIPSE MIL-STD-1750A

C/C++: Understand analyzes K or ANSI C source code and most 
constructs of the C++ language. Understand works with any C compiler, 
and has been tested with most of the popular ones. Note that C++ 
templates are now supported using the strict parser in Understand. 
Objective C, Objective C++, C++11, and C++14 are also supported using 
the strict parser


C#: Understand supports all versions up to and including 4.0.

FORTRAN: Understand supports FORTRAN 77, FORTRAN 90, FORTRAN 95, and 
FORTRAN 2003 in both free and fixed format. Extensions supported 
include Harris FORTRAN and DEC FORTRAN. We often expand Understand to 
support common compiler extensions. If you find that the compiler 
extensions you are using are not currently supported, contact us at 
supp...@scitools.com.


Java: Understand supports most of JDK 1.3, 1.4, 5, 6, and 7. 
Specifically, the generics introduced in JDK 5 are not currently 
supported. Source code containing generics may be analyzed but generics 
information will be ignored.


JOVIAL: JOVIAL73 and JOVIAL3 are supported.

Delphi/Pascal: Understand supports all versions of Embarcadero’s Delphi 
language and Embarcadero’s Turbo Pascal language. It also supports ISO 
7185: 1990 (also known as Unextended Pascal) with HP Pascal extensions. 
You can also enable support for Ingres embedded SQL statements.


PL/M: The standard version for PL/M 80/86 is supported.

VHDL: We support VHDL-87, VHDL-93, and VHDL-2001.

Cobol: Understand supports COBOL 85.

Web Languages: Understand supports PHP, HTML, CSS, and JavaScript. XML 
is also a supported language that Understand provides several metrics 
for: counts for total lines, code lines, blank lines, and comment lines.


Python: Understand supports Python Version 2 and Python Version 3.


[1] https://scitools.com

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: SQLite-D goes beta!

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 20 September 2016 at 20:34:19 UTC, Karabuta wrote:


Great work! Can't wait to see sample code :)


It's in app.d
also see test.d

Re: Why I am switching to Go

[Daniel Kozak via Digitalmars-d]

Dne 20.9.2016 v 22:01 Karabuta via Digitalmars-d napsal(a):

On Tuesday, 20 September 2016 at 19:47:12 UTC, WebFreak001 wrote:

On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is dying 
suggests that putting any effort in to it will be a waste. Go, OTH, 
has tons of frameworks, most are actively support, very well 
documented(beego, revel, etc), and feature rich.


What is vibe.d missing? It works great for me and the documentation 
is great imo too because it has everything I need. I use vibe.d at 
the company I work at and I use it for all my websites. I never had 
any problems with it


Lets me say from a beginners perspective,
* How do I build a file upload form (single and multiple file uploads)
* How do I work with mongoDB to do CRUD.
* How do I use the Web API beyond hello world!
* Form validation?
* Data sanitization?
* How do I structure my application for real-world (reusable and 
maintainable code) e.g for a simple blog, simple CMS etc. :)

...

Some of these things may seem easy to figure-out but can be difficult 
for a beginner unless he/she has a copy of Kai's book at the moment (D 
Web Development) :)
Nothing of this is specific for vibe.d, so I do not see any reason to 
have doc about this in vibe.d

Re: SQLite-D goes beta!

[Karabuta via Digitalmars-d-announce]

On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote:
It is my pleasure to announce that I now consider SQLite-D to 
be in Beta stage.
The reader is now stable enough to read all the test tables I 
have been given.


The fact that it took around 20 minutes to complete index-tree 
support convinced mt that I have chosen a solid design.


I have received the request to add examples and documentation 
to sqlite-d.

And I will do so as time permits.

This project will be boost licensed.

So don't be shy :)

https://github.com/UplinkCoder/sqlite-d


Great work! Can't wait to see sample code :)

Re: Why I am switching to Go

[Daniel Kozak via Digitalmars-d]

Dne 20.9.2016 v 22:00 cym13 via Digitalmars-d napsal(a):


On Tuesday, 20 September 2016 at 19:47:01 UTC, jmh530 wrote:

On Tuesday, 20 September 2016 at 19:16:04 UTC, cym13 wrote:


What exactly makes you think vibe is dying?


His first post is from 6 days ago, so I would guess that he doesn't 
seem to have much of a sense of its history.


Which makes him the perfect example of beginner with a newcommer's 
look :)

Or a troll :). But I guess the first one is right

Re: SQLite-D goes beta!

[Eugene Wissner via Digitalmars-d-announce]

On Tuesday, 20 September 2016 at 16:53:23 UTC, Stefan Koch wrote:

On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote:
It is my pleasure to announce that I now consider SQLite-D to 
be in Beta stage.
The reader is now stable enough to read all the test tables I 
have been given.


The fact that it took around 20 minutes to complete index-tree 
support convinced mt that I have chosen a solid design.


I have received the request to add examples and documentation 
to sqlite-d.

And I will do so as time permits.

This project will be boost licensed.

So don't be shy :)

https://github.com/UplinkCoder/sqlite-d


It took a few months for me to get to the point, but now it is 
officially boost licensed.


I want just let you know that native sqlite is absolute great. I 
maintain a packagekit backend for slackware linux and it takes 
advantage of sqlite. It is currently written in C with glib but i 
want to add some D later. So many thanks for your work!

Re: Why I am switching to Go

[Karabuta via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:47:12 UTC, WebFreak001 wrote:
On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller 
wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is 
dying suggests that putting any effort in to it will be a 
waste. Go, OTH, has tons of frameworks, most are actively 
support, very well documented(beego, revel, etc), and feature 
rich.


What is vibe.d missing? It works great for me and the 
documentation is great imo too because it has everything I 
need. I use vibe.d at the company I work at and I use it for 
all my websites. I never had any problems with it


Lets me say from a beginners perspective,
* How do I build a file upload form (single and multiple file 
uploads)

* How do I work with mongoDB to do CRUD.
* How do I use the Web API beyond hello world!
* Form validation?
* Data sanitization?
* How do I structure my application for real-world (reusable and 
maintainable code) e.g for a simple blog, simple CMS etc. :)

...

Some of these things may seem easy to figure-out but can be 
difficult for a beginner unless he/she has a copy of Kai's book 
at the moment (D Web Development) :)

Re: Why I am switching to Go

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:47:01 UTC, jmh530 wrote:

On Tuesday, 20 September 2016 at 19:16:04 UTC, cym13 wrote:


What exactly makes you think vibe is dying?


His first post is from 6 days ago, so I would guess that he 
doesn't seem to have much of a sense of its history.


Which makes him the perfect example of beginner with a 
newcommer's look :)

Re: Why I am switching to Go

[WebFreak001 via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is dying 
suggests that putting any effort in to it will be a waste. Go, 
OTH, has tons of frameworks, most are actively support, very 
well documented(beego, revel, etc), and feature rich.


What is vibe.d missing? It works great for me and the 
documentation is great imo too because it has everything I need. 
I use vibe.d at the company I work at and I use it for all my 
websites. I never had any problems with it

Re: Why I am switching to Go

[jmh530 via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:16:04 UTC, cym13 wrote:


What exactly makes you think vibe is dying?


His first post is from 6 days ago, so I would guess that he 
doesn't seem to have much of a sense of its history.

Re: Using Libraries

[Karabuta via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 15:38:55 UTC, Darren wrote:
On Tuesday, 20 September 2016 at 15:07:53 UTC, rikki cattermole 
wrote:



Ok lets start at the very beginning...


I think I need to start before that, haha.

I might need more of a step-by-step guide.  I'm a complete 
beginner to programming, not just D.  I worked through 
Programming in D, where I was just compiling with dmd, then 
when I decided to learn OpenGL I seem to be using dub for 
everything.


There have been a few libraries I've wanted to use but couldn't 
because they didn't have a pre-compiled binary, which is all 
I've been able to get working through sheer trial and error.  
Some sites say to use things like CMake and cygwin, but I'm 
uncomfortable using things I have no idea about.


Dub is like a package manager for D (like what npm is to 
node.js). All dub libraries are hosted at code.dlang.org. When 
you see a library at code.dlang.org you want to use, you could 
either type "dub install packagename" whilst in the dub project 
ROOT or specify dependencies in the dub.json file.
You can then run "dub run" which will take care of fetching and 
building dependencies/libraries from code.dlang.org (including 
linking and running the binary).


For example, there is a web framework called vibe.d. If I want to 
use vide.d, I can specify dependencies as;


dependencies: {
"vide-d":"^0.7.29"
}


In my app.d file (which is available for any dub project created 
using "dub init projectname") I can import vibe.d using;


import vide.d;
void main() {
...
}

I can now compile and run the program with "dub run" or "dub 
build" to only build and link without running.

setting fields of object using traits

[Ram_B via Digitalmars-d-learn]

I'm trying to set fields of object from JSON with traits library. 
How i can to it properly?


import std.stdio;
import std.json;
import std.traits;
import std.meta:  Alias;

class Obj{
void fromJSON(this T)(JSONValue j){
foreach(field; FieldNameTuple!T){
alias member = Alias!(__traits(getMember, T, field));
static if (__traits(hasMember, member, "fromJSON")){
member.fromJSON(j[field]);
} else {
member = j[field];
}
}
}
}

class A : Obj{
int a,b;
C c;
this(){
c = new C();
}

}

class C : Obj{
int a;
this(){
a = 0;
};
}

int main(string[] argv)
{
string s = "{\"a\": 1, \"b\": 2, \"c\": {\"a\": 3} }";
JSONValue j = parseJSON(s);
A a = new A();
a.fromJSON(j);
writeln(a.b);
readln();
return 0;
}

main.d(14): Error: need 'this' for 'a' of type 'int'
main.d(14): Error: need 'this' for 'b' of type 'int'
main.d(12): Error: template main.Obj.fromJSON cannot deduce 
function from argument types !(c)(JSONValue), candidates are:

main.d(8):main.Obj.fromJSON(this T)(JSONValue j)
main.d(41): Error: template instance main.Obj.fromJSON!(A) error 
instantiating

Re: Why I am switching to Go

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:16:04 UTC, cym13 wrote:

What exactly makes you think vibe is dying?


it lacks the documentation?

Re: thisExePath purity

[crimaniak via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 13:35:27 UTC, Steven 
Schveighoffer wrote:
Yes, but if your code does instantiate it, it is called, even 
if you don't ever call the function that calls it.
Yes, it's not ideal but better then just global variable and 
static block - it's called in any case, even if variable is not 
used at all.


Ideal solution will be something like attribute for static block 
leading to make it optional, so module will not be included if no 
usage of other symbols found. But I don't know way how to make it 
so template is used.


Note that if you don't import the module that contains the 
static ctor, it should be trimmed by the linker.
 Let's imagine linker can trim even imported module with static 
ctor, if we have something like:


immutable string executablePath;

@local shared static this()
{
import std.file : thisExePath;
executablePath = thisExePath();
}

and there is no references to executablePath. Here it would be 
useful, I think. Attribute @local (or @module? the name does not 
matter) mean this block used only to init other symbols in this 
module so it can be skipped if no references.



I would absolutely caution you from putting static this() 
inside any template. Unfortunately, due to the way D generates 
these static constructors, any module that uses staticMemoize, 
or *imports a module that uses it*, will be marked as having a 
static constructor, and will potentially create cycles.
 Please be more detail about cycles. Do you mean something like 
this? https://isocpp.org/wiki/faq/ctors#static-init-order

Re: Why I am switching to Go

[Daniel Kozak via Digitalmars-d]

Dne 20.9.2016 v 21:14 Intersteller via Digitalmars-d napsal(a):

Vibe.d looks great on the surface but lack of documentation, commonly 
used functionality, and that it looks like it is dying suggests that 
putting any effort in to it will be a waste. Go, OTH, has tons of 
frameworks, most are actively support, very well documented(beego, 
revel, etc), and feature rich.


If I am going to put any work in to something, I want to make sure 
that I can depend on it in the future. It doesn't look like this is 
the case with vibe.d. Hopefully vibe.d will not die and will mature 
enough in the future so it actually provides a good alternative to the 
current web frameworks.
Ok, can you link some of your request about what missing on vibe.d? It 
is easy to say this framework does not support this. this framework has 
bad doc and so on. But these are statements without any proof. So this 
post does not have any value until you add some specifics. It would be 
nice if you share what exactly do you miss from vibe.d and what doc need 
to be improved. For eg. from my POV vibe.d doc is ok and there is 
everything I need (OK I would prefer better async-event lib, but AFAIK 
Sonke works on a new one)

Re: Emplace vs closures

[Timon Gehr via Digitalmars-d]

On 19.09.2016 15:52, ag0aep6g wrote:

On 09/19/2016 02:55 PM, Timon Gehr wrote:

This works:
import std.stdio;
void main(){
int x=3;
enum l=()=>x;
writeln(x);
}

I.e. l has the correct runtime context even though it is a static value.


Enums are a special kind of static value, though. Can't do that with
`static` instead of `enum`. Enums (often?) don't manifest until they're
used. Could .init work that way?


Maybe -- and local template instantiation should work for all arguments 
that require it. Then we would not have this issue. But fixing .init for 
local structs breaks code.

[Issue 16514] std.socket methods are const, and thus cannot be overriden for SSLSocket, for example

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16514] New: std.socket methods are const, and thus cannot be overriden for SSLSocket, for example

[via Digitalmars-d-bugs]

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

  Issue ID: 16514
   Summary: std.socket methods are const, and thus cannot be
overriden for SSLSocket, for example
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

commit 1fc5f9b34ca9bb333ee429ab2ca39e07c3304f01 made most of virtual methods of
std.socket `const`, and now it is not possible to do any internal housekeeping
in overriden methods. bind, connect, listen, accept...

this should be reverted.

--

Re: Why I am switching to Go

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 19:14:41 UTC, Intersteller wrote:
Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is dying 
suggests that putting any effort in to it will be a waste. Go, 
OTH, has tons of frameworks, most are actively support, very 
well documented(beego, revel, etc), and feature rich.


If I am going to put any work in to something, I want to make 
sure that I can depend on it in the future. It doesn't look 
like this is the case with vibe.d. Hopefully vibe.d will not 
die and will mature enough in the future so it actually 
provides a good alternative to the current web frameworks.


What exactly makes you think vibe is dying?

Re: thisExePath purity

[crimaniak via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 09:14:39 UTC, Marc Schütz wrote:

Have a look at `std.concurrency.initOnce`:
https://dlang.org/phobos/std_concurrency.html#.initOnce

But you will still need to use assumePure() for calling 
`thisExePath`, and it might do other things that are impure...


Yes, it's near but in this case I try to fix purity, so any 
variants of lazy initialization is not applicable here.

Why I am switching to Go

[Intersteller via Digitalmars-d]

Vibe.d looks great on the surface but lack of documentation, 
commonly used functionality, and that it looks like it is dying 
suggests that putting any effort in to it will be a waste. Go, 
OTH, has tons of frameworks, most are actively support, very well 
documented(beego, revel, etc), and feature rich.


If I am going to put any work in to something, I want to make 
sure that I can depend on it in the future. It doesn't look like 
this is the case with vibe.d. Hopefully vibe.d will not die and 
will mature enough in the future so it actually provides a good 
alternative to the current web frameworks.

Re: thisExePath purity

[crimaniak via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 04:26:05 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 20, 2016 04:17:21 crimaniak via 
Digitalmars-d-learn wrote:

 static shared immutable ReturnType!T value;


I would point out that immutable is implicitly shared, so 
there's no reason to put shared on an immutable variable. 
However, you _do_ want to put shared on a static constructor 
that initializes an immutable variable so that it's only run 
once for the program instead of once per thread (the compiler 
really should enforce that, but there's a longstanding bug that 
allows you to reinitialize an immutable variable by not putting 
shared on the static constructor and starting multiple threads).

 Ok, I got it. Thanks.

Re: The removal of inactive forum groups

[Laeeth Isharc via Digitalmars-d]

On Sunday, 18 September 2016 at 13:17:33 UTC, Dennis Ritchie 
wrote:

Hi, all
It seems to me that a group of `Beta` should be removed> 
because the last activity in this group dated November 30, 2015:

https://forum.dlang.org/post/565bc28c.8080...@dawg.eu

Group `Study` is also not very active, so it would be logical 
to move it higher than it is situated now, or otherwise 
reorganize the forum. Of course, at the very bottom of the 
forum group is doomed to `extinction`.


Any thoughts?


Keeping things tidy matters more than it might seem because of 
the impression it makes on others.   So I agree.

Re: D and math, can you isolate this ?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Sep 20, 2016 at 09:22:19AM -0700, H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Tue, Sep 20, 2016 at 12:35:18PM +, Basile B. via Digitalmars-d-learn 
> wrote:
> [...]
[...]
> > Which means that I ask you if you can isolate c for
> > 
> > y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);
> > 
> > y is always f(0.5,c)
[...]
> That probably means the inverse cannot be expressed in terms of
> elementary functions. Probably the only thing you can do is to use
> some kind of numerical approximation, like some form of Newton's
> method or some such, to find the value of c.
[...]

It may be analytically very hard to solve this equation, but it's
probably not so hard to solve numerically. Based on the graph of the
equation produced by Wolfram Alpha, it seems that y must always lie
between 0 and 1, and that it has a horizontal asymptote at y=1.  At
around c=6 or thereabouts, y becomes very close to 1.  The value of c
for y=0.5 is approximately 2, so that seems like a good initial guess
for an iterative method.

So if y<0 or y>1, return NaN. If y=1, return +inf. Otherwise, use an
iterative method with a starting value of c=2. Because of the horizontal
asymptote at y=1, though, values of c much greater than 6 will probably
be quite inaccurate, so hopefully your application doesn't depend on the
exact value in that case!


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

Re: SQLite-D goes beta!

[Stefan Koch via Digitalmars-d-announce]

On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote:
It is my pleasure to announce that I now consider SQLite-D to 
be in Beta stage.
The reader is now stable enough to read all the test tables I 
have been given.


The fact that it took around 20 minutes to complete index-tree 
support convinced mt that I have chosen a solid design.


I have received the request to add examples and documentation 
to sqlite-d.

And I will do so as time permits.

This project will be boost licensed.

So don't be shy :)

https://github.com/UplinkCoder/sqlite-d


It took a few months for me to get to the point, but now it is 
officially boost licensed.

Re: Emplace vs closures

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 14:00:00 UTC, Steven 
Schveighoffer wrote:

On 9/20/16 4:08 AM, cym13 wrote:
On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
Schveighoffer wrote:

[...]


I beg to defer, null pointer dereference is certainly not safe 
in the
general case. In many cases it lead to code execution or 
privilege
escalation. See for example CVE-2008-568 [1] for an example in 
kernel

space or CVE-2009-0385 [2] in user space.


In kernel space, yes. So don't do this in your D kernel :)

In user space, the chance is very unlikely. It requires a 
function context to be larger than the reserved page space, and 
accessing a function context variable outside that space.


Not impossible, but very very unlikely. And beyond the control 
of the exploiter.


The idea is that you are really trying to call a function in a 
part of
memory that is not mapped, but if you are able to map the zero 
page and
control what function pointer is present there then it is 
exploitable.
I'd like people to get away from the idea that null pointer 
dereference
is safe, it's not. In most cases it's not exploitable but 
that's

definitely not a safe spot.


Dereferencing a null pointer is perfectly safe in user space 
(where you can't map the zero page). Indexing a null pointer is 
not. In this case, we are indexing a null pointer, so there is 
the potential for abuse, but very very small.


Note that not all operating systems disallow mapping the zero 
page (although they admitedly should). And yes the potential for 
abuse is small, I've just getting annoyed at dangerous 
generalities.


In that specific case I don't think it should be treated as a 
security issue in the general case although it could become one 
if used in an  unfavorable environment.


I'm still not sure that emplace on an inner struct is a thing 
we need to allow, especially when it's known that the context 
pointer will be invalid. Maybe we should only allow if called 
via a different name, to prevent unwitting uses.


-Steve

Re: D and math, can you isolate this ?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 16:22:19 UTC, H. S. Teoh wrote:
On Tue, Sep 20, 2016 at 12:35:18PM +, Basile B. via 
Digitalmars-d-learn wrote: [...]

The problem is here:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L849
- f(x,c) = 1.0 - pow(1.0 - pow(x, 2.0/c), c * 0.5);
- c(f0.5)) = ?

Which means that I ask you if you can isolate c for

y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);

y is always f(0.5,c)


I couldn't manage to solve it.  Nested exponentials are very 
nasty to invert. :-(  At first, I thought it might be solvable 
in terms of the Lambert W function (aka ProductLog) but I 
couldn't manage to get the equation into the right form.  Then 
I checked on Wolfram Alpha and it says "no result found in 
terms of standard mathematical functions".


That probably means the inverse cannot be expressed in terms of 
elementary functions. Probably the only thing you can do is to 
use some kind of numerical approximation, like some form of 
Newton's method or some such, to find the value of c.



T


Thanks for trying, you're not the first to tell me about the 
Newton's method...

Re: D and math, can you isolate this ?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Sep 20, 2016 at 12:35:18PM +, Basile B. via Digitalmars-d-learn 
wrote:
[...]
> The problem is here:
> https://github.com/BBasile/iz/blob/master/import/iz/math.d#L849
> - f(x,c) = 1.0 - pow(1.0 - pow(x, 2.0/c), c * 0.5);
> - c(f0.5)) = ?
> 
> Which means that I ask you if you can isolate c for
> 
> y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);
> 
> y is always f(0.5,c)

I couldn't manage to solve it.  Nested exponentials are very nasty to
invert. :-(  At first, I thought it might be solvable in terms of the
Lambert W function (aka ProductLog) but I couldn't manage to get the
equation into the right form.  Then I checked on Wolfram Alpha and it
says "no result found in terms of standard mathematical functions".

That probably means the inverse cannot be expressed in terms of
elementary functions. Probably the only thing you can do is to use some
kind of numerical approximation, like some form of Newton's method or
some such, to find the value of c.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the 
beginning of wisdom.

Re: consequences of removing semicolons in D like in Python

[jmh530 via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:36:42 UTC, Chris wrote:


Then try to compile Phobos and a variety of D projects on 
Github and publish the results. It'd be interesting to see what 
problems you encounter. Then you might write a tool like dfix 
that fixes the source code so that ";"-less code is parsed 
properly etc. But is it really worth it?


If you look at the github page, it seems that it already has this 
ability, with some qualifications.

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:53:20 UTC, eugene wrote:

On Tuesday, 20 September 2016 at 15:46:58 UTC, Chris wrote:
You come across as if you had set your heart on removing 
semicolons.


i didn't set my heart on removing semicolons, the topic is 
"consequences of removing semicolons..."


There's only one way to find out :-) Nobody has ever done it 
before afaik.

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:46:58 UTC, Chris wrote:
You come across as if you had set your heart on removing 
semicolons.


i didn't set my heart on removing semicolons, the topic is 
"consequences of removing semicolons..."

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:42:58 UTC, eugene wrote:

On Tuesday, 20 September 2016 at 15:36:42 UTC, Chris wrote:

But is it really worth it?


this was my question at the beginning of the thread


You come across as if you had set your heart on removing 
semicolons.

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:36:42 UTC, Chris wrote:

But is it really worth it?


this was my question at the beginning of the thread

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:36:42 UTC, Chris wrote:

On Tuesday, 20 September 2016 at 15:31:21 UTC, eugene wrote:

On Tuesday, 20 September 2016 at 15:28:51 UTC, Chris wrote:
Anyway, why don't you grab the compiler and make a version 
that accepts line breaks and ";" - and see what happens?


yes, i've written about it in the thread before


Then try to compile Phobos and a variety of D projects on 
Github and publish the results. It'd be interesting to see what 
problems you encounter. Then you might write a tool like dfix 
that fixes the source code so that ";"-less code is parsed 
properly etc. But is it really worth it?


It'd be interesting, because it would finally provide data for 
the ever-recurring question of whether to have semicolons or not.


¿How would you handle cases like

debug { writeln("Error"); return; }

of just

debug { writeln("Error"); }

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:31:21 UTC, eugene wrote:

On Tuesday, 20 September 2016 at 15:28:51 UTC, Chris wrote:
Anyway, why don't you grab the compiler and make a version 
that accepts line breaks and ";" - and see what happens?


yes, i've written about it in the thread before


Then try to compile Phobos and a variety of D projects on Github 
and publish the results. It'd be interesting to see what problems 
you encounter. Then you might write a tool like dfix that fixes 
the source code so that ";"-less code is parsed properly etc. But 
is it really worth it?

Re: Using Libraries

[Darren via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 15:07:53 UTC, rikki cattermole 
wrote:



Ok lets start at the very beginning...


I think I need to start before that, haha.

I might need more of a step-by-step guide.  I'm a complete 
beginner to programming, not just D.  I worked through 
Programming in D, where I was just compiling with dmd, then when 
I decided to learn OpenGL I seem to be using dub for everything.


There have been a few libraries I've wanted to use but couldn't 
because they didn't have a pre-compiled binary, which is all I've 
been able to get working through sheer trial and error.  Some 
sites say to use things like CMake and cygwin, but I'm 
uncomfortable using things I have no idea about.

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:28:51 UTC, Chris wrote:
Anyway, why don't you grab the compiler and make a version that 
accepts line breaks and ";" - and see what happens?


yes, i've written about it in the thread before

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Tuesday, 20 September 2016 at 15:07:31 UTC, eugene wrote:


one doesn't parse a sentence when one reads it, one translates 
a sentence into images; why do you compare native speech 
sentences with a programming language statements?


one doesn't parse a sentence when one reads it
one translates a sentence into images
why do you compare native speech sentences with a programming 
language statements


Yes and no. Of course it's like an image (i.e. you see it), but 
commas, colons, fullstops etc. _help_ you to find your way around 
in the text and sometimes even help to disambiguate. You'll 
notice this in the comment section under newspaper articles: 
sometimes it's hard to understand a sentence at first reading, 
when people leave out commas where they would make sense. So you 
have to re-analyze the sentence. E.g.:


"I was talking to Joan and Peter went to the shop to buy some 
sweets."

vs.
"I was talking to Joan, and Peter went to the shop to buy some 
sweets."


I'm sure someone can find an example where a sentence would be 
ambiguous without proper punctuation.


Anyway, why don't you grab the compiler and make a version that 
accepts line breaks and ";" - and see what happens?

Re: Chennai Meetup

[Chennai Danatic via Digitalmars-d-announce]

On Monday, 5 September 2016 at 15:29:59 UTC, Chennai Danatic 
wrote:

Hey, I have set up a Meetup group for Chennai, India:

http://www.meetup.com/Chennai-D/

I am not sure about the location/time of the first meeting, 
maybe OMR or Alwarpet in a week or two, or what to do, other 
than discuss our use of D.  If you're interested, please say 
which of those locations works better for you, in the comments 
for the event on Meetup, and if you want to present something 
about your use of D.


A time and place for this meetup is now set, this Saturday.  
There will be a talk introducing D.  Please RSVP if you will 
attend:


http://www.meetup.com/Chennai-D/events/233886704/

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 14:19:50 UTC, Nick Sabalausky 
wrote:
Just like you parse a sentence when you read it by noticing the 
spaces defining where words are. And the commas separating 
sections of a sentence, and periods/capitalization separating 
the sentences, in-sentence capitalization signaling proper 
nouns, etc. All of those are *technically* unnecessary too, but 
notice how much harder it is to read (ie, "parse") when they're 
absent.




one doesn't parse a sentence when one reads it, one translates a 
sentence into images; why do you compare native speech sentences 
with a programming language statements?


one doesn't parse a sentence when one reads it
one translates a sentence into images
why do you compare native speech sentences with a programming 
language statements

Re: Using Libraries

[rikki cattermole via Digitalmars-d-learn]

On 21/09/2016 3:01 AM, Darren wrote:

Hey, all

I keep hitting roadblocks and that's mainly due to not knowing how to
include libraries.  So far I've been getting by with downloading .dll's
and including the necessary dependencies in the dub.json file and having
that build/run my project.  I'm sure I'm making a mess of that, too, but
it works and now I need to learn how to include static libraries (and
probably understand github and other dub features).

Right now, for example, I want to use the gl3n package:
https://github.com/Dav1dde/gl3n

What do I need in order to build libraries, and have dub include them
when I import modules?   Can I keep all of the libraries in one place so
I'm not copy-pasting them (like in lib and bin folders that I keep seeing)?

As you can tell, I'm still very new to all of this and I have no idea
where to start.  Thank you for your time!


Ok lets start at the very beginning with straight dmd.

You have a total of two things you can pass in, an import directory and 
source files.
Source files are compiled in and import directories are basically a way 
to tell the compiler that certain symbols can exist but it won't create 
them.


Now from this you abstract away into dependencies such as packages / 
subpackages.
This is where dub comes in, it will fetch (known) projects with dub 
definition files (dub.json/sdl), place them into a folder under your 
profile directory and allow you to build against them and automatically 
provide them as import directories as required.


So how do you do that? Simple.

"dependencies": {
"mypackage": ">=0.0.0"
}

Inside of a dub.json file (sdl is a little different check 
code.dlang.org for more help on the subject).

Using Libraries

[Darren via Digitalmars-d-learn]

Hey, all

I keep hitting roadblocks and that's mainly due to not knowing 
how to include libraries.  So far I've been getting by with 
downloading .dll's and including the necessary dependencies in 
the dub.json file and having that build/run my project.  I'm sure 
I'm making a mess of that, too, but it works and now I need to 
learn how to include static libraries (and probably understand 
github and other dub features).


Right now, for example, I want to use the gl3n package: 
https://github.com/Dav1dde/gl3n


What do I need in order to build libraries, and have dub include 
them when I import modules?   Can I keep all of the libraries in 
one place so I'm not copy-pasting them (like in lib and bin 
folders that I keep seeing)?


As you can tell, I'm still very new to all of this and I have no 
idea where to start.  Thank you for your time!

Re: Replace/Rename DWT forum with GUIs forum?

[Basile B. via Digitalmars-d]

On Tuesday, 20 September 2016 at 14:39:23 UTC, Sai wrote:

On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote:
I would like to suggest that the existing DWT forum be renamed 
or replaced with a more generic GUIs forum. As far as I can 
tell, the DWT forum doesn't get much traffic these days and I 
don't believe any of the current GUI options for D are 
sufficiently popular to warrant their own specific forum.


While I primarily work with and have an interest in GtkD, I'm 
interested in posts with regards to all of the available GUI 
options (GtkD, DLangUI, etc) for D since I have general 
interest in desktop applications. I think grouping everything 
in one forum, similar to what is done for IDEs and Debuggers, 
would bring together posts and people that share a common 
interest.


Indeed, now that there are few good quality gui libs, we must 
rename the forum to GUIs, DWT is too specific and I wonder how 
many people even know what DWT is.


Renaming is not an option. A new one is more simple.

Re: Release 2.071.2

[Bastiaan Veelo via Digitalmars-d-announce]

On Monday, 19 September 2016 at 11:08:33 UTC, Martin Nowak wrote:

Also see the changelog for more details.

http://dlang.org/changelog/2.071.2.html


Thanks!

The entry for 2.071.2 seems to be missing in the side panel.

Bastiaan.

Re: Replace/Rename DWT forum with GUIs forum?

[Sai via Digitalmars-d]

On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote:
I would like to suggest that the existing DWT forum be renamed 
or replaced with a more generic GUIs forum. As far as I can 
tell, the DWT forum doesn't get much traffic these days and I 
don't believe any of the current GUI options for D are 
sufficiently popular to warrant their own specific forum.


While I primarily work with and have an interest in GtkD, I'm 
interested in posts with regards to all of the available GUI 
options (GtkD, DLangUI, etc) for D since I have general 
interest in desktop applications. I think grouping everything 
in one forum, similar to what is done for IDEs and Debuggers, 
would bring together posts and people that share a common 
interest.


Indeed, now that there are few good quality gui libs, we must 
rename the forum to GUIs, DWT is too specific and I wonder how 
many people even know what DWT is.

Re: consequences of removing semicolons in D like in Python

[Nick Sabalausky via Digitalmars-d]

On 09/20/2016 08:20 AM, eugene wrote:

On Tuesday, 20 September 2016 at 12:00:00 UTC, bachmeier wrote:

Without the semicolons, I have to parse the code myself


could you, please, explain, why do you parse code yourself?


That's what happens in the brain when you read code. He's not talking 
about actual LR/LL/etc parsing here, but the mental equivalent. Just 
like you parse a sentence when you read it by noticing the spaces 
defining where words are. And the commas separating sections of a 
sentence, and periods/capitalization separating the sentences, 
in-sentence capitalization signaling proper nouns, etc. All of those are 
*technically* unnecessary too, but notice how much harder it is to read 
(ie, "parse") when they're absent.


thats what happens in the brain when you read code hes not talking about 
actual lr ll etc parsing here but the mental equivalent just like you 
parse a sentence when you read it by noticing the spaces defining where 
words are and the commas separating sections of a sentence and periods 
capitalization separating the sentences in sentence capitalization 
signaling proper nouns etc all of those are technically unnecessary too 
but notice how much harder it is to read ie parse when theyre absent

Re: Emplace vs closures

[Steven Schveighoffer via Digitalmars-d]

On 9/20/16 4:08 AM, cym13 wrote:

On Monday, 19 September 2016 at 14:22:16 UTC, Steven Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:


What I'd like to know: is this usage widespread? Should we forbid it for
the sake of security?


No. There is no security concern here. You are dereferencing a null
pointer, which is perfectly safe.



I beg to defer, null pointer dereference is certainly not safe in the
general case. In many cases it lead to code execution or privilege
escalation. See for example CVE-2008-568 [1] for an example in kernel
space or CVE-2009-0385 [2] in user space.


In kernel space, yes. So don't do this in your D kernel :)

In user space, the chance is very unlikely. It requires a function 
context to be larger than the reserved page space, and accessing a 
function context variable outside that space.


Not impossible, but very very unlikely. And beyond the control of the 
exploiter.



The idea is that you are really trying to call a function in a part of
memory that is not mapped, but if you are able to map the zero page and
control what function pointer is present there then it is exploitable.
I'd like people to get away from the idea that null pointer dereference
is safe, it's not. In most cases it's not exploitable but that's
definitely not a safe spot.


Dereferencing a null pointer is perfectly safe in user space (where you 
can't map the zero page). Indexing a null pointer is not. In this case, 
we are indexing a null pointer, so there is the potential for abuse, but 
very very small.


I'm still not sure that emplace on an inner struct is a thing we need to 
allow, especially when it's known that the context pointer will be 
invalid. Maybe we should only allow if called via a different name, to 
prevent unwitting uses.


-Steve

Re: D and math, can you isolate this ?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 12:35:18 UTC, Basile B. wrote:
I've recently started an easing/interpolation family of 
function in my D user library. It's based on something I know 
well since I've already used them in 2012 in a VST plugin 
called GrainPlot (RIP).


However for one of the function, I can't manage to get the 
inverse.

[...]
The problem is here:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L849
- f(x,c) = 1.0 - pow(1.0 - pow(x, 2.0/c), c * 0.5);
- c(f0.5)) = ?

Which means that I ask you if you can isolate c for

y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);

y is always f(0.5,c)


If you don't understand, these function have a control point, for 
"parabol" and "pow" it's easy to get the c Coefficient that 
manages the slope. But for the ellipse (aka the super ellipse) 
it's a math nightmare )


For example is use the three functions in the same order 
(parabol, pow, ellipse):


http://sendvid.com/ygti5jmr

for the ellipse you can see that the mouse position is not in 
sync with the control point at the middle...it's the problem.


I need to isolate c when "y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c 
* 0.5)".

I know it's hard...otherwise I wouldn't ask ;]

Re: thisExePath purity

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/20/16 12:17 AM, crimaniak wrote:

Hi and thanks all!

On Tuesday, 20 September 2016 at 00:43:10 UTC, Jonathan M Davis wrote:


immutable string executablePath;

shared static this()
{
import std.file : thisExePath();
executablePath = thisExePath();
}


This code is good for my needs but I start to think about how to call
thisExePath only if it is really used and come to this solution:

import std.traits: ReturnType, Parameters;

string staticMemoize(alias T, Parms = Parameters!T)() pure
{
struct Holder(alias T)
{
static shared immutable ReturnType!T value;
shared static this(){ value = T(Parms); }
}

return Holder!T.value;
}

unittest
{
import std.file : thisExePath;
assert(staticMemoize!thisExePath == thisExePath);
}

Something like this. Need to refine about input parameters, but I hope,
idea is clear.
Unlike the function memoize from phobos staticMemoize really pure. And
unlike proposed solution with ordinary variable staticMemoize is lazy,
because no call - no instantiation.


Yes, but if your code does instantiate it, it is called, even if you 
don't ever call the function that calls it.


Note that if you don't import the module that contains the static ctor, 
it should be trimmed by the linker.


I would absolutely caution you from putting static this() inside any 
template. Unfortunately, due to the way D generates these static 
constructors, any module that uses staticMemoize, or *imports a module 
that uses it*, will be marked as having a static constructor, and will 
potentially create cycles.


-Steve

D and math, can you isolate this ?

[Basile B. via Digitalmars-d-learn]

I've recently started an easing/interpolation family of function 
in my D user library. It's based on something I know well since 
I've already used them in 2012 in a VST plugin called GrainPlot 
(RIP).


However for one of the function, I can't manage to get the 
inverse.


A function that's fully implemented:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L598
- f(x,c) = x*x*x - x*x*c + x*c;
- c(f(0.5)) = 4 * (y - 0.125));

Another:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L749
- f(x,c) = pow(x, c);
- c(f(0.5)) = log(y) / log(0.5));

The problem is here:
https://github.com/BBasile/iz/blob/master/import/iz/math.d#L849
- f(x,c) = 1.0 - pow(1.0 - pow(x, 2.0/c), c * 0.5);
- c(f0.5)) = ?

Which means that I ask you if you can isolate c for

y = 1.0 - pow(1.0 - pow(0.5, 2.0/c), c * 0.5);

y is always f(0.5,c)

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Tuesday, 20 September 2016 at 12:00:00 UTC, bachmeier wrote:

Without the semicolons, I have to parse the code myself


could you, please, explain, why do you parse code yourself?

Re: consequences of removing semicolons in D like in Python

[bachmeier via Digitalmars-d]

On Tuesday, 20 September 2016 at 11:24:29 UTC, eugene wrote:

On Monday, 19 September 2016 at 20:42:22 UTC, jmh530 wrote:
I don't see a reason to make that sort of change within the D 
language or DMD, especially when something like Delight exists 
and probably accomplishes exactly what the OP had wanted.




Delight is not what i meant, i meant something like this:

module test
import std.stdio

void main() {
write("Hello");
writeln("world")
}


Without the semicolons, I have to parse the code myself, which 
makes it harder to read. Do that with 1000 lines of code and it 
gives me a headache. I have written many tens of thousands of 
lines of R code and hate the lack of semicolons. This is purely a 
matter of preference.

Re: consequences of removing semicolons in D like in Python

[eugene via Digitalmars-d]

On Monday, 19 September 2016 at 20:42:22 UTC, jmh530 wrote:
I don't see a reason to make that sort of change within the D 
language or DMD, especially when something like Delight exists 
and probably accomplishes exactly what the OP had wanted.




Delight is not what i meant, i meant something like this:

module test
import std.stdio

void main() {
write("Hello");
writeln("world")
}

[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

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

--- Comment #4 from Martin Nowak  ---
(In reply to uplink.coder from comment #2)
> Hash collisions will happen!
> We need a way to speed up those equals compares in rootObject.
> I'll look if I can find a good way to gradually remove the virtual calls.

This whole RootObject hashing/comparison is a kludge when we can cheaply
generate a unique string.

>   IsVariable!(Simulated_Object_966)
>   IsMemberVariable!(Simulated_Object_975)
>   isSomeFunction!(Simulated_Object_573)
> 
> Those SHOULD produce the same hash they work on the same types!

Yes right, only the arguments are part of the hash.

> I am of the impression that template-inlining can help here.

True for isSomeFunction and it does work, the other 2 take alias parameters
(via variadic arguments) and create one instance per object (w/ the same hash).

--

[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

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

--- Comment #3 from Martin Nowak  ---
Managed to speed up the test case from 1.8s to 1.2s, almost completely
eliminating the lookup cost.
Still need to fix a few issues, the cppmangler thinks member variables are
static, we might not want to fill the idPool with unused identifiers (would
save some memory to just compute the hash), needs some more testing whether the
mangling is really bijective, if so we could only hash the string and ditch the
TemplateInstance.compare code.

--

[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

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

--- Comment #2 from uplink.co...@googlemail.com ---
Hash collisions will happen!
We need a way to speed up those equals compares in rootObject.
I'll look if I can find a good way to gradually remove the virtual calls. 

  IsVariable!(Simulated_Object_966)
  IsMemberVariable!(Simulated_Object_975)
  isSomeFunction!(Simulated_Object_573)

Those SHOULD produce the same hash they work on the same types!
I am of the impression that template-inlining can help here.

--

[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||goober...@gmail.com,
   ||uplink.co...@googlemail.com

--- Comment #1 from Martin Nowak  ---
It's the horrible hash that is causing the performance issue.
Arguments as widely different than

  genericIndexOf!(CPPMethods, ushort, int, uint, long, ulong)
  genericIndexOf!(VTable, ushort, int, uint, long, ulong)

produce the same hash.

>From the 88.3K lookups, 7900 have the hash 1 (one).

The test code that triggered the issue contains 1K instances of

  VariableDescriptor!(tonsofsimulatedobjects, SimulatedEntity,
"Simulated_Object_1063")
  VariableDescriptor!(tonsofsimulatedobjects, SimulatedEntity,
"Simulated_Object_1064")

and lots of instances like

  IsVariable!(Simulated_Object_963)
  IsMemberVariable!(Simulated_Object_973)
  isSomeFunction!(Simulated_Object_571)
  IsVariable!(Simulated_Object_964)
  IsMemberVariable!(Simulated_Object_974)
  isSomeFunction!(Simulated_Object_572)
  IsVariable!(Simulated_Object_966)
  IsMemberVariable!(Simulated_Object_975)
  isSomeFunction!(Simulated_Object_573)

all producing the same hash.
With such a crappy hash the behavior degrades back to the old linear search.

I'll try to replace this with the mangling suffix (.getIdent) instead which
should be both simpler and effective, given that all mangling bugs are fixed.

--

Re: thisExePath purity

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 04:17:21 UTC, crimaniak wrote:

Hi and thanks all!

On Tuesday, 20 September 2016 at 00:43:10 UTC, Jonathan M Davis 
wrote:



immutable string executablePath;

shared static this()
{
import std.file : thisExePath();
executablePath = thisExePath();
}


This code is good for my needs but I start to think about how 
to call thisExePath only if it is really used and come to this 
solution:


import std.traits: ReturnType, Parameters;

string staticMemoize(alias T, Parms = Parameters!T)() pure
{
struct Holder(alias T)
{
static shared immutable ReturnType!T value;
shared static this(){ value = T(Parms); }
}

return Holder!T.value;
}

unittest
{
import std.file : thisExePath;
assert(staticMemoize!thisExePath == thisExePath);
}

Something like this. Need to refine about input parameters, but 
I hope, idea is clear.
Unlike the function memoize from phobos staticMemoize really 
pure. And unlike proposed solution with ordinary variable 
staticMemoize is lazy, because no call - no instantiation.


Have a look at `std.concurrency.initOnce`:
https://dlang.org/phobos/std_concurrency.html#.initOnce

But you will still need to use assumePure() for calling 
`thisExePath`, and it might do other things that are impure...

Re: Release 2.071.2

[Dechcaudron via Digitalmars-d-announce]

On Monday, 19 September 2016 at 11:08:33 UTC, Martin Nowak wrote:

Glad to announce D 2.071.2.

-Martin


You guys are amazing! I love D and I love you all!

Re: What blogs about D do you read?

[sarn via Digitalmars-d-learn]

Don't forget the Planet D aggregator :)
http://planet.dsource.org/

Here's my contribution:
https://theartofmachinery.com/tags/dlang/

Re: Emplace vs closures

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 08:23:04 UTC, John Colvin wrote:

On Tuesday, 20 September 2016 at 08:08:16 UTC, cym13 wrote:
On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:

What I'd like to know: is this usage widespread? Should we 
forbid it for

the sake of security?


No. There is no security concern here. You are dereferencing 
a null pointer, which is perfectly safe.


-Steve


I beg to defer,


You mean differ, right?


Hmm... yes, sorry.

null pointer dereference is certainly not safe in the general 
case. In many cases it lead to code execution or privilege 
escalation. See for example CVE-2008-568 [1] for an example in 
kernel space or CVE-2009-0385 [2] in user space.


The idea is that you are really trying to call a function in a 
part of memory that is not mapped, but if you are able to map 
the zero page and control what function pointer is present 
there then it is exploitable. I'd like people to get away from 
the idea that null pointer dereference is safe, it's not. In 
most cases it's not exploitable but that's definitely not a 
safe spot.


That being said I don't think it should be the burden of the 
library or language to deal with this for the reasons you 
exposed.


[1] http://www.trapkit.de/advisories/TKADV2008-015.txt
[2] http://www.trapkit.de/advisories/TKADV2009-004.txt


Interesting, hadn't seen this stuff before. There is also the 
matter of large offsets taking you to accessible memory, such 
as you might get with a null pointer to a very large struct.


Another interesting case is the Firefox debug offset. On x86 the 
address space was scarce so nothing could be mapped in userspace 
above 0xe000 IIRC. Firefox devs decided to use the address 
0xefefefef to cause a clear segfault easy to hook in order to 
ease debugging. When Firefox was ported to x86_64 this range 
became available, so an attack was to setup that address and 
cause an error leading to a debug segfault and code execution. I 
think the fix was to used 0xfefefefe instead but I'm not sure.


Anyway segfaults aren't safe, they should be avoided and 
controlled when possible. It's always better to manage the error.

Re: What blogs about D do you read?

[Saurabh Das via Digitalmars-d-learn]

On Monday, 19 September 2016 at 19:36:22 UTC, Karabuta wrote:

On Monday, 19 September 2016 at 19:29:25 UTC, A D dev wrote:

On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote:

Hi list,

What blogs about D do you read?


To be more clear:

- what blogs that include posts on D, would you recommend to a 
D beginner?


Thanks.


I have one here on Vibe.d for beginners 
https://laberba.github.io/2016/hello-world-app-with-the-vibe.d-web-framework/


I will be writing more for-beginners blogs in the coming few 
weeks.


You blog looks gorgeous. Absolutely beautiful!

Re: Emplace vs closures

[John Colvin via Digitalmars-d]

On Tuesday, 20 September 2016 at 08:08:16 UTC, cym13 wrote:
On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:

What I'd like to know: is this usage widespread? Should we 
forbid it for

the sake of security?


No. There is no security concern here. You are dereferencing a 
null pointer, which is perfectly safe.


-Steve


I beg to defer,


You mean differ, right?

null pointer dereference is certainly not safe in the general 
case. In many cases it lead to code execution or privilege 
escalation. See for example CVE-2008-568 [1] for an example in 
kernel space or CVE-2009-0385 [2] in user space.


The idea is that you are really trying to call a function in a 
part of memory that is not mapped, but if you are able to map 
the zero page and control what function pointer is present 
there then it is exploitable. I'd like people to get away from 
the idea that null pointer dereference is safe, it's not. In 
most cases it's not exploitable but that's definitely not a 
safe spot.


That being said I don't think it should be the burden of the 
library or language to deal with this for the reasons you 
exposed.


[1] http://www.trapkit.de/advisories/TKADV2008-015.txt
[2] http://www.trapkit.de/advisories/TKADV2009-004.txt


Interesting, hadn't seen this stuff before. There is also the 
matter of large offsets taking you to accessible memory, such as 
you might get with a null pointer to a very large struct.

Re: Emplace vs closures

[cym13 via Digitalmars-d]

On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:

What I'd like to know: is this usage widespread? Should we 
forbid it for

the sake of security?


No. There is no security concern here. You are dereferencing a 
null pointer, which is perfectly safe.


-Steve


I beg to defer, null pointer dereference is certainly not safe in 
the general case. In many cases it lead to code execution or 
privilege escalation. See for example CVE-2008-568 [1] for an 
example in kernel space or CVE-2009-0385 [2] in user space.


The idea is that you are really trying to call a function in a 
part of memory that is not mapped, but if you are able to map the 
zero page and control what function pointer is present there then 
it is exploitable. I'd like people to get away from the idea that 
null pointer dereference is safe, it's not. In most cases it's 
not exploitable but that's definitely not a safe spot.


That being said I don't think it should be the burden of the 
library or language to deal with this for the reasons you exposed.


[1] http://www.trapkit.de/advisories/TKADV2008-015.txt
[2] http://www.trapkit.de/advisories/TKADV2009-004.txt

DMD sources: convert glue.c to glue.d

[Walter Bright via Digitalmars-d]

https://github.com/dlang/dmd/pull/6138

This is just another file in the ongoing process to convert DMD from C++ to D. 
It shows that relatively pedestrian C++ code can convert to D with few 
difficulties. There's a 1:1 correspondence between the two, and most edits are 
simply replacing -> and :: with .


Note that no attempt is made to fix anything, change to idiomatic D, improve 
comments, etc. It's a rote translation only.