Re: iopipe v0.0.4 - RingBuffers!

[Dmitry Olshansky via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer 
wrote:
OK, so at dconf I spoke with a few very smart guys about how I 
can use mmap to make a zero-copy buffer. And I implemented this 
on the plane ride home.


However, I am struggling to find a use case for this that 
showcases why you would want to use it. While it does work, and 
works beautifully, it doesn't show any measurable difference 
vs. the array allocated buffer that copies data when it needs 
to extend.


I’d start with something clinicaly synthetic.
Say your record size is exactly half of buffer + 1 byte. If you 
were to extend the size of buffer, it would amortize.


Basically:
16 Mb buffer fixed
vs
16 Mb mmap-ed ring

Where you read pieces in 8M+1 blocks.Yes, we are aiming to blow 
the CPU cache there. Otherwise CPU cache is so fast that 
ocasional copy is zilch, once we hit primary memory it’s not. 
Adjust sizes for your CPU.


The amount of work done per byte though has to be minimal to 
actually see anything.





in the buffer. But alas, it's roughly the same, even with large 
number of lines for context (like 200).


However, this example *does* show the power of iopipe -- it 
handles all flavors of unicode with one template function, is 
quite straightforward (though I want to abstract the line 
tracking code, that stuff is really tricky to get right). Oh, 
and it's roughly 10x faster than grep, and a bunch faster than 
fgrep, at least on my machine ;) I'm tempted to add regex 
processing to see if it still beats grep.


Should be mostly trivial in fact. I mean our first designs for 
IOpipe is where I wanted regex to work with it.


Basically - if we started a match, extend window until we get it 
or lose it. Then release up to the next point of potential start.




Next up (when my bug fix for dmd is merged, see 
https://issues.dlang.org/show_bug.cgi?id=17968) I will be 
migrating iopipe to depend on 
https://github.com/MartinNowak/io, which should unlock Windows 
support (and I will add RingBuffer Windows support at that 
point).


Enjoy!

https://github.com/schveiguy/iopipe
https://code.dlang.org/packages/iopipe
http://schveiguy.github.io/iopipe/

-Steve

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 05:10:08 UTC, Uknown wrote:

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, 
private is not applied because D wanted to avoid C++'s 
`friend` functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' 
( which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwsl...@forum.dlang.org


My point is, that adding sealed or anything else to classes, is a 
waste of time, cause a class is D, is not really a class at all.


A class in D, is some unprinciple pseudo-class, that cannot truly 
encapsulate itself any longer.

Re: Sealed classes - would you want them in D?

[Apocalypto via Digitalmars-d]

On Friday, 11 May 2018 at 05:10:08 UTC, Uknown wrote:

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
Whereas D makes it part of the implementation of 'the module' 
( which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwsl...@forum.dlang.org


If an encapsulation problem is highlighted again and again, may 
be it's time to acknowledge at least that there is a problem.

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, 
private is not applied because D wanted to avoid C++'s 
`friend` functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' ( 
which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwsl...@forum.dlang.org

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, private 
is not applied because D wanted to avoid C++'s `friend` 
functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' ( 
which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.

Re: Need help with the dmd package on NixOS

[Thomas Mader via Digitalmars-d]

On Wednesday, 9 May 2018 at 19:58:48 UTC, Thomas Mader wrote:

Now I wonder how something like that is possible.


My suspicion about the switch to glibc 2.27 being the problem was 
wrong.
I did a very timeconsuming bisection and found the problem commit 
to be the one which bumped binutils to 2.30.

Re: auto: useful, annoying or bad practice?

[KingJoffrey via Digitalmars-d]

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:


So I'm curious, what's the consensus on auto?


My rule, is when I can't be bothered typing it all out, or can't 
be bothered working out what it is I'm actually meant to type, 
then I use auto (or var).


i.e. I use it as a time saver, and that's all.

The exception to that rule, is when it's important to the person 
writing/reading that code, to known what type is being used (and 
that's a rather subjective decision). In most cases, the type 
declaration is for other reasons (i.e not human consumption).


btw. In 1969, John C. Reynolds published his paper/specification 
on GEDANKEN - a typeless programming language, and type 
declaration was simply not permitted.


(Gedanken is German for thought experiment, more or less)

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.492.9205=rep1=pdf

I wonder whether this is where languages will eventually end up 
again, in the future some time.

[Issue 18852] forum.dlang.org says down when redirect after posting

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from John Hall  ---
@Vladamir Thanks for fixing this. It's been driving me a bit nuts. I often get
the CAPTCHAs at home because I'm behind a VPN. I might get them at work too,
but really it's the VPN that is the big driver of it.

--

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 03:11:48 UTC, KingJoffrey wrote:
On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis 
wrote:

Idiomatic D tends to use classes rarely...


What is the basis for this assertion?


D tends to prefer structs with UFCS member functions rather than 
classes, because one rarely needs the reference semantics or 
inheritance. Also, classes are pretty inconvenient because they 
are hard to use without the GC.




On a separate issue, 'private' should mean private! (not 
kinda-private).


Let's not make D classes even more of joke.


`private` is for outside the module. Within the module, private 
is not applied because D wanted to avoid C++'s `friend` functions.

[Issue 18852] forum.dlang.org says down when redirect after posting

[d-bugmail--- via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Hardware|x86 |All
 Resolution|--- |FIXED
 OS|Windows |All

--- Comment #2 from Vladimir Panteleev  ---
Fixed:
https://github.com/CyberShadow/DFeed/commit/dc4cc60569975f1f5c893194a1cfc586790a09d6

Congratulations on being the first user to solve 10 CAPTCHAs and becoming the
first trusted user! You should see them no longer. (Hopefully, that was the
only bug in the trusted user implementation...)

--

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis wrote:

Idiomatic D tends to use classes rarely...


What is the basis for this assertion?

On a separate issue, 'private' should mean private! (not 
kinda-private).


Let's not make D classes even more of joke.

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[d-bugmail--- via Digitalmars-d-bugs]

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

alexanderheisterm...@gmail.com changed:

   What|Removed |Added

   Severity|normal  |critical

--

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #17 from alexanderheisterm...@gmail.com ---
This bug blocks certain Phobos functions from being @nogc as it involves the
destroy function. I am bumping the importance of this to critical status, as
the current workarounds I seen involves taking a sledge hammer approach, as it
forces the compiler to assume @nogc.

Here an example of what I was referring to.
https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

--

[Issue 13972] Make scoped, Unique, and RefCounted @nogc

[d-bugmail--- via Digitalmars-d-bugs]

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

alexanderheisterm...@gmail.com changed:

   What|Removed |Added

 CC||alexanderheistermann@gmail.
   ||com
 Depends on|14171   |15246


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=14171
[Issue 14171] Mark non-allocating GC functions as @nogc
https://issues.dlang.org/show_bug.cgi?id=15246
[Issue 15246] Destructor inheritance doesn't inherit attributes properly
--

[Issue 14171] Mark non-allocating GC functions as @nogc

[d-bugmail--- via Digitalmars-d-bugs]

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

alexanderheisterm...@gmail.com changed:

   What|Removed |Added

 Blocks|13972   |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=13972
[Issue 13972] Make scoped, Unique, and RefCounted @nogc
--

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[d-bugmail--- via Digitalmars-d-bugs]

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

alexanderheisterm...@gmail.com changed:

   What|Removed |Added

 Blocks||13972


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=13972
[Issue 13972] Make scoped, Unique, and RefCounted @nogc
--

Re: [DUB][DLS] building package dls doesn't finish

[Rubn via Digitalmars-d]

On Thursday, 10 May 2018 at 09:32:38 UTC, Kamil Koczurek wrote:

Hello,
I installed an atom extension for D support, but it requires 
dls package to be installed and built. When I fetch and attempt 
to build it (with --build=release) it just says that it's 
building and doesn't change even if I leave it running for 
several hours.

What can I do to fix it? Or do I just leave it overnight?

Ps. Sorry if it's a wrong section, it's my first time posting 
here.


Download ldc2 and use --compiler=ldc. DMD's optimization is 
incredibly slow with O(N!) time depending on what you are doing.


Try build the debug build to see if that is the issue. If your 
debug builds quickly then that was probably the issue. But in 
general you'd probably want to use LDC for tools you are going to 
be using.

Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 19:50:40 UTC, Nikos wrote:

In my dub.sdl file I have


configuration "python35" {
 subConfiguration "autowrap" "python35"
}


and I run


dub build --config=python35


which still tries to find python36. Why doesn't it look for 3.5?


Hi.  On my phone so can't copy paste.  Edit your dub.sdl under 
the python35 subconfiguration and change python 36 to python35.

[Issue 18852] forum.dlang.org says down when redirect after posting

[d-bugmail--- via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
Please report this at the forum's issue tracker:
https://github.com/CyberShadow/DFeed 

Thanks!

--

iopipe v0.0.4 - RingBuffers!

[Steven Schveighoffer via Digitalmars-d-announce]

OK, so at dconf I spoke with a few very smart guys about how I can use 
mmap to make a zero-copy buffer. And I implemented this on the plane 
ride home.


However, I am struggling to find a use case for this that showcases why 
you would want to use it. While it does work, and works beautifully, it 
doesn't show any measurable difference vs. the array allocated buffer 
that copies data when it needs to extend.


If anyone has any good use cases for it, I'm open to suggestions. 
Something that is going to potentially increase performance is an 
application that needs to keep the buffer mostly full when extending 
(i.e. something like 75% full or more).


The buffer is selected by using `rbufd` instead of just `bufd`. 
Everything should be a drop-in replacement except for that.


Note: I have ONLY tested on Macos, so if you find bugs in other OSes let 
me know. This is still a Posix-only library for now, but more on that 
later...


As a test for Ring buffers, I implemented a simple "grep-like" search 
program that doesn't use regex, but phobos' canFind to look for lines 
that match. It also prints some lines of context, configurable on the 
command line. The lines of context I thought would show better 
performance with the RingBuffer than the standard buffer since it has to 
keep a bunch of lines in the buffer. But alas, it's roughly the same, 
even with large number of lines for context (like 200).


However, this example *does* show the power of iopipe -- it handles all 
flavors of unicode with one template function, is quite straightforward 
(though I want to abstract the line tracking code, that stuff is really 
tricky to get right). Oh, and it's roughly 10x faster than grep, and a 
bunch faster than fgrep, at least on my machine ;) I'm tempted to add 
regex processing to see if it still beats grep.


Next up (when my bug fix for dmd is merged, see 
https://issues.dlang.org/show_bug.cgi?id=17968) I will be migrating 
iopipe to depend on https://github.com/MartinNowak/io, which should 
unlock Windows support (and I will add RingBuffer Windows support at 
that point).


Enjoy!

https://github.com/schveiguy/iopipe
https://code.dlang.org/packages/iopipe
http://schveiguy.github.io/iopipe/

-Steve

[Issue 18852] New: forum.dlang.org says down when redirect after posting

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18852
   Summary: forum.dlang.org says down when redirect after posting
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: john.michael.h...@gmail.com

In recent days/weeks, I started constantly getting a message after posting that

"forum.dlang.org is temporarily down for maintenance, and should be back up
shortly. Apologies for the inconvenience."

However, when I go back to forum.dlang.org it loads just fine and I can click
through to my post.

This is happening during the re-direct process. The post still shows up in the
forum (I know because I see it and people respond). However, all these posts
are still showing up in my drafts thing.

Also, I just posted at the same time as I was loading some other pages and all
the pages went to the maintenance thing.

--

Re: property += operator

[Mike Franklin via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 21:16:12 UTC, Jonathan M Davis wrote:

IIRC, there's a DIP for trying to make += work with just 
getters and setters, but I don't know if we're ever going to 
see anything like it in the language.


Yes, the DIP is here:  https://github.com/dlang/DIPs/pull/97

It's currently stalled while I elaborate on the merits, or lack 
thereof, of a library solution.  The best library implementation 
I've seen is 
https://forum.dlang.org/post/mqveusvzkmkshrzws...@forum.dlang.org


I'm exploring the idea of continuing with the DIP, or adding 
features (or removing limitations of the language) to make a 
library implementation more appealing.  IMO, it'd be great if we 
could add more composable primitives to the language, and get rid 
of quirky features like @property.


Mike

Re: Line breaks in JSON

[jmh530 via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 18:21:17 UTC, bachmeier wrote:

[snip]

I used replace("\\n", "\n")


Ah, I always forget the extra \.

Re: Building dmd/druntime on windows issue

[Seb via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 18:38:30 UTC, Andre Pany wrote:

Hi,

I follow the instructions from the wiki to build dmd/druntime 
from source on windows.

https://wiki.dlang.org/Building_under_Windows

[...]


Which DMD/druntime do you try to build?
IIRC there are some issues with the release ball, you should try 
the GitHub sources.

Also are you using DigitalMars make?
What environment variables did you set?

[Issue 18851] std.net.curl.post cannot be used with !ubyte

[d-bugmail--- via Digitalmars-d-bugs]

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

Eugene  changed:

   What|Removed |Added

   Keywords||trivial
URL||https://github.com/dlang/ph
   ||obos/blob/master/std/net/cu
   ||rl.d

--

[Issue 18851] New: std.net.curl.post cannot be used with !ubyte

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18851
   Summary: std.net.curl.post cannot be used with !ubyte
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: tech.vin...@gmail.com

In file 'curl.d':

T[] post(T = char)(const(char)[] url, string[string] postDict, HTTP conn =
HTTP())
if (is(T == char) || is(T == ubyte)) //ignoring
{
import std.uri : urlEncode;

return post(url, urlEncode(postDict), conn); //post!char by default
}


Correctly:

T[] post(T = char)(const(char)[] url, string[string] postDict, HTTP conn =
HTTP())
if (is(T == char) || is(T == ubyte))
{
import std.uri : urlEncode;

return post!T(url, urlEncode(postDict), conn);
}

--

Re: Sealed classes - would you want them in D?

[Jonathan M Davis via Digitalmars-d]

On Thursday, May 10, 2018 13:22:20 Piotr Mitana via Digitalmars-d wrote:
> Hello,
>
> I've recently thought of sealed classes (sealed as in Scala, not
> as in C#) and am thinking of writing a DIP for it. I decided to
> start this thread first though to gather some opinions on the
> topic.
>
> For those who never coded Scala and don't know sealed classes: a
> sealed class is a class which can be only extended in the same
> source file.
>
>  sealed class MyClass {}
>
> Translating to D, a sealed class would could only be extended in
> the same module. Additionally I would suggest
> "sealed(some.package) MyClass {}" syntax for classes that could
> only be extended in the particular package.
>
> In Scala an important value of sealed classes is that compiler
> knows that and can aid programmer in pattern matching by
> detecting the missed cases. However, there is another value I
> see: limiting the extension of classes.
>
> Some time ago I was working on a simple CQRS library and created
> an Entity class, where I wanted only a few specific subtypes for
> it. The library is built over a few defined entity types and user
> is not able to create their own types (should extend the
> particular subtype instead). Sealing the Entity class could
> enable me to define the closed set of subtypes and prevent new
> direct subtype creation outside the library.
>
> Combining sealed with final library developer can create a
> completely closed type hierarchy.
>
> Any thoughts on that proposal?

I think that the main thing is that the use case has to be strong enough to
merit complicating the language further by adding such a feature, and I
really don't know if the use case is really all that strong. My gut reaction
is that it's catering to a very specific and rare use case and as such would
not be worth adding, but I don't know. Idiomatic D tends to use classes
rarely, and I can't think of any situation where what you're describing
would ever have been useful to me, but that doesn't necessarily mean that
some people wouldn't find it really useful, and depending on how much value
it adds in such situations, it might be worth adding. Ultimately though, I
think that if you want to create a DIP for something like this, you're going
to need some very strong use cases where this is solving a real problem and
why the current situation is lacking. If it's a significant improvement in
enough situations, then you'll probably be able to get a DIP accepted, but
if it's just helping in some rare cases, I'd expect it to stand a low chance
of acceptance. Nothing stands out to me about the idea as being
fundamentally bad though.

- Jonathan M Davis

Re: property += operator

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 10, 2018 18:43:40 SrMordred via Digitalmars-d-learn wrote:
> struct T
> {
>  int x;
>  @property ref X(){ return x; }
>  @property X(int v)
>  {
>  x = v;
>  }
> }
>
> T t;
> t.X += 10;
>
> The setter 'x = v' are not executed because i´m returning the
> reference of x.
> And without the 'ref' the compiler complains because 'x' is not a
> lvalue.
>
> Any solution to make it work like native arr.length+=10 works?
>
> ( I Thought on returning a struct with "+=" operator but it is a
> strange solution )

Just in general, I would suggest that you not provide both a getter and a
setter if the getter returns by ref. If that's what you're doing, then just
use the getter as the setter. In general though, with getters and setters,
you can only get and set a value. Stuff like += won't work unless you return
by ref (which frequently makes having a function instead of just making the
variable public kind of pointless) or if you play games like returning an
object that overrides opOpAssign!"+" which gets kind of weird and
complicated, albeit sometimes reasonable and useful.

IIRC, there's a DIP for trying to make += work with just getters and
setters, but I don't know if we're ever going to see anything like it in the
language.

- Jonathan M Davis

Re: D'ish similar_text?

[Dgame via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 20:38:12 UTC, Vladimir Panteleev 
wrote:

On Thursday, 10 May 2018 at 20:32:11 UTC, Dgame wrote:

immutable size_t len = s1.length + s2.length;
percent = (len - distance) * 100.0 / len;


Note that this formula will give you only 50% similarity for 
"abc" and "def", i.e. two completely different strings. I 
suggest to divide by max(s1.length, s2.length) instead.


Hm, that does not work either. ABC and AZB have a different 
outcome with both. How can I calculate the percentage with 
levenshtein? It's rather simple with similar_text since it 
returns the amount of similar chars.

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 3:18 PM, Ali Çehreli wrote:

On 05/10/2018 01:03 PM, Dlang User wrote:

 >> this didn´t work either.
 >> note that 'f.data+= 2;' don't call the write property
 >
 > That's odd, it works on my machine (Windows 10 with V2.079.0 DMD 
compiler).


Try putting writeln expressions in the two functions to see which one 
gets called. ;)


Ali



Now, I see the problem. Sorry for the noise.

Re: How do you connect Python with D via socket, I'm still getting connection refused error

[Enjoys Math via Digitalmars-d-learn]

On Friday, 4 May 2018 at 13:52:29 UTC, Andy Smith wrote:

On Thursday, 3 May 2018 at 23:58:24 UTC, Enjoys Math wrote:

Error
-

[...]



Haven't run it, but two things to try...

On D side try adding listen after bind.

On python side. Don't think you need to call bind the client 
socket ( this may cause problems).


Cheers,

A.


That got it to work, nvm.

Re: A bit more Emscripten

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 08:32:07 UTC, Vladimir Panteleev 
wrote:
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev 
wrote:

https://github.com/CyberShadow/dscripten-tools


Progress update:

- std.stdio.writeln() works
- Using a D main() works (though unittests and static 
constructors still don't)

- WebAssembly output works!
- std.allocator works (at least, Mallocator + building-blocks 
do)


Very cool, Vladimir.  When I get time we will try to see if it's 
useful for some internal prototype tools.

Re: D'ish similar_text?

[Vladimir Panteleev via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 20:32:11 UTC, Dgame wrote:

immutable size_t len = s1.length + s2.length;
percent = (len - distance) * 100.0 / len;


Note that this formula will give you only 50% similarity for 
"abc" and "def", i.e. two completely different strings. I suggest 
to divide by max(s1.length, s2.length) instead.

Re: D'ish similar_text?

[Dgame via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 20:13:49 UTC, Vladimir Panteleev 
wrote:

On Thursday, 10 May 2018 at 20:08:04 UTC, Dgame wrote:

void similar_text_similar_str(char* txt1, size_t len1, char*


That looks like an implementation of Levenshtein distance. We 
have one in Phobos:


https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html


Oh, that could to work, thank you. I've just tested it quickly, 
but that code seems to produce the same results:



size_t similar_text2(in string s1, in string s2, out double 
percent) {

import std.algorithm: levenshteinDistance;

immutable size_t distance = s1.levenshteinDistance(s2);
immutable size_t len = s1.length + s2.length;
percent = (len - distance) * 100.0 / len;

return distance;
}

Re: property += operator

[Ali Çehreli via Digitalmars-d-learn]

On 05/10/2018 01:03 PM, Dlang User wrote:

>> this didn´t work either.
>> note that 'f.data+= 2;' don't call the write property
>
> That's odd, it works on my machine (Windows 10 with V2.079.0 DMD 
compiler).


Try putting writeln expressions in the two functions to see which one 
gets called. ;)


Ali

[Issue 18850] Template overload incorrectly results in recursive expansion error

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0aep6g  ---
(In reply to Jonathan Marler from comment #0)
> alias Foo = Foo!(T, T.init);

Just that line alone shows the same behavior. And that might make it more
obvious what's happening: In the struct body, "Foo" refers to the alias, not
the templates.

You can refer to the templates with `.Foo`:


struct Foo(T)
{
alias Foo = .Foo!(T, T.init);
}
struct Foo(T, T initialValue)
{
private T value = initialValue;
}
Foo!int n;


--

Re: D'ish similar_text?

[Vladimir Panteleev via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 20:08:04 UTC, Dgame wrote:

void similar_text_similar_str(char* txt1, size_t len1, char*


That looks like an implementation of Levenshtein distance. We 
have one in Phobos:


https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html

D'ish similar_text?

[Dgame via Digitalmars-d-learn]

I'm in need for some sort of string similarity comparision. I've 
found soundex but that didn't solved my needs. After some search 
I found a C implementation of similar_text, but that is quite 
ugly... I was able to let it work in D but it's still somewhat 
messy. Is there any D implementation of similar_text? Here's my 
current code which makes heavy use of pointer-arithmetic which 
makes it hard to understand.



void similar_text_similar_str(char* txt1, size_t len1, char* 
txt2, size_t len2, size_t* pos1, size_t* pos2, size_t* max) {

char* p, q;
char* end1 = txt1 + len1;
char* end2 = txt2 + len2;
size_t l;

*max = 0;
for (p = txt1; p < end1; p++) {
for (q = txt2; q < end2; q++) {
for (l = 0; (p + l < end1) && (q + l < end2) && (p[l] 
== q[l]); l++) { }

if (l > *max) {
*max = l;
*pos1 = p - txt1;
*pos2 = q - txt2;
}
}
}
}

size_t similar_text_similar_char(char* txt1, size_t len1, char* 
txt2, size_t len2) {

size_t sum;
size_t pos1, pos2, max;

similar_text_similar_str(txt1, len1, txt2, len2, , 
, );

if ((sum = max) != 0) {
if (pos1 && pos2)  {
sum += similar_text_similar_char(txt1, pos1, txt2, 
pos2);

}
if ((pos1 + max < len1) && (pos2 + max < len2)) {
sum += similar_text_similar_char(txt1 + pos1 + max, 
len1 - pos1 - max,

txt2 + pos2 + max, len2 - pos2 - max);
}
}

return sum;
}

size_t similar_text(in string s1, in string s2, out double 
percent) {
immutable size_t sim = similar_text_similar_char(s1.dup.ptr, 
s1.length, s2.dup.ptr, s2.length);

percent = sim * 200.0 / (s1.length + s2.length);

return sim;
}

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 2:50 PM, SrMordred wrote:

On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:

On 5/10/2018 1:43 PM, SrMordred wrote:

[...]


I am relatively new to D and I was under the impression that that was 
a limitation of @property functions.


But, re-reading the language reference, it gave this example (it 
returns something from the write property, which seems odd), I 
modified to add refs, and then it seems to work, but I am not sure if 
it is correct or not:


import std.stdio;

struct Foo
{
    @property ref int data() { return m_data; } // read property

    @property ref int data(int value) { return m_data = value; } // 
write property


  private:
    int m_data;
}

void main()
{
Foo f;
f.data = 5;
f.data++;
f.data+= 2;
writeln(f.data);

}


this didn´t work either.
note that 'f.data+= 2;' don't call the write property


That's odd, it works on my machine (Windows 10 with V2.079.0 DMD 
compiler).


I changed main to this:

void main()
{
Foo f;
writeln(f.data);
f.data = 5;
writeln(f.data);
f.data++;
writeln(f.data);
f.data+= 2;
writeln(f.data);
}


and then I get this output:

0
5
6
8

Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[Nikos via Digitalmars-d-announce]

In my dub.sdl file I have


configuration "python35" {
 subConfiguration "autowrap" "python35"
}


and I run


dub build --config=python35


which still tries to find python36. Why doesn't it look for 3.5?

Re: property += operator

[SrMordred via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:

On 5/10/2018 1:43 PM, SrMordred wrote:

[...]


I am relatively new to D and I was under the impression that 
that was a limitation of @property functions.


But, re-reading the language reference, it gave this example 
(it returns something from the write property, which seems 
odd), I modified to add refs, and then it seems to work, but I 
am not sure if it is correct or not:


import std.stdio;

struct Foo
{
@property ref int data() { return m_data; } // read property

@property ref int data(int value) { return m_data = value; 
} // write property


  private:
int m_data;
}

void main()
{
Foo f;
f.data = 5;
f.data++;
f.data+= 2;
writeln(f.data);

}


this didn´t work either.
note that 'f.data+= 2;' don't call the write property

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 1:43 PM, SrMordred wrote:

struct T
{
     int x;
     @property ref X(){ return x; }
     @property X(int v)
     {
     x = v;
     }
}

T t;
t.X += 10;

The setter 'x = v' are not executed because i´m returning the reference 
of x.

And without the 'ref' the compiler complains because 'x' is not a lvalue.

Any solution to make it work like native arr.length+=10 works?

( I Thought on returning a struct with "+=" operator but it is a strange 
solution )


I am relatively new to D and I was under the impression that that was a 
limitation of @property functions.


But, re-reading the language reference, it gave this example (it returns 
something from the write property, which seems odd), I modified to add 
refs, and then it seems to work, but I am not sure if it is correct or not:


import std.stdio;

struct Foo
{
@property ref int data() { return m_data; } // read property

@property ref int data(int value) { return m_data = value; } // 
write property


  private:
int m_data;
}

void main()
{
Foo f;
f.data = 5;
f.data++;
f.data+= 2;
writeln(f.data);

}

Class member variable initialization vs. C++ initializer lists, and weirder classes

[Evan via Digitalmars-d]

A discussion came up on Reddit about C++'s initializer lists, and 
I realized I didn't really know what other languages in the same 
space do for member initialization. I'm not looking to start a 
language war here; I'm asking out of curiosity/general knowledge.


I found a prior discussion on what D does [1], and I think the 
most relevant part is this (reduced slightly from the original):



   class MyClass {
   int d = 6;

   this(int val) {
   d = val;
   }
   }


You are correct that in the case of the [...] constructor,
two assignments effectively take place, d = 6, then d = 7.



In C++ terms, I would describe this as "d is first initialized to 
6, and then assigned to from 7".


However, if that's the only mechanism for "initializing" a class 
variable it seems to me like this would cause problems with:


* Classes that can't be default-initialized because they need 
some data to be provided
  not known until runtime and it is desired that there not be a 
way to construct an

  "empty" object; something like this C++:

class Person {
   string name;

   // no Person() provided
   Person(string n) { n = name; } // not "idiomatic c++", but 
works

};

class EmployeeRecord {
   Person person;

   // no this() provided
   EmployeeRecord(string name) : person(name) {} // no way to 
*not* use init-list

};

* Classes that can't be assigned. I'm having a harder time coming 
up with a good
  example here that would usefully be a member of another class, 
but some RAII
  objects could fit the bill. (For example, std::lock_guard is 
not copyable or

  assignable.)


How would these be handled in D? Do these concepts exist in some 
form? If so, how would you initialize them?


Evan


[1] https://forum.dlang.org/thread/jg9ajr$1iaq$1...@digitalmars.com

Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait

[Meta via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 12:55:36 UTC, Uknown wrote:

On Thursday, 10 May 2018 at 11:06:06 UTC, Per Nordlöw wrote:

On Wednesday, 9 May 2018 at 21:09:12 UTC, Meta wrote:
It's a context pointer to the enclosing 
function/object/struct. Mark the struct as static to get rid 
of it.


Ok, but why an extra void* for `S.tupleof` and not for 
`T.tupleof` which is also scoped inside a unittest?


I'm guessing T is a POD, so it doesn't need a context pointer, 
whereas S is not counted as a POD since a member function was 
@disabled.


Yes, exactly. From my tests, if you add _any_ member method to a 
struct, it becomes non-POD. When you think about it, this makes 
perfect sense, as there's no possible way to access anything 
through a context pointer if there is no executable code within 
the struct's scope.


As far an @disabled postblit:

Plain Old Data
A struct or union is Plain Old Data (POD) if it meets the 
following criteria:


it is not nested
it has no postblits, destructors, or assignment operators
it has no ref fields or fields that are themselves non-PO

https://docarchives.dlang.io/v2.079.0/spec/struct.html#POD

Now if you do this:

struct R
{
@disable this(this);
int* _ptr;
}
unittest
{
struct S
{
@disable this(this);
int* _ptr;
}
struct T
{
int* _ptr;
}
pragma(msg, "R: ", typeof(R.tupleof));
pragma(msg, __traits(allMembers, R));

pragma(msg, "S: ", typeof(S.tupleof));
pragma(msg, __traits(allMembers, S));

pragma(msg, "T: ", typeof(T.tupleof));
pragma(msg, __traits(allMembers, T));
}

It prints:

R: (int*)
tuple("__postblit", "_ptr", "__xpostblit", "opAssign")

S: (int*, void*)
tuple("__postblit", "_ptr", "this", "__xpostblit", "opAssign")

T: (int*)
tuple("_ptr")

So it looks like disabling a struct's postblit actually counts as 
having a __postblit and __xpostblit function (don't ask me why), 
in addition to a construction and opAssign... no idea why, and 
maybe this is a bug, but I bet there's a good reason for it.


Anyway, as per my first point, this means it'll need a context 
pointer unless you mark the struct as static.

Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[Nikos via Digitalmars-d-announce]

Interesting stuff.

In http://code.dlang.org/packages/autowrap it says:

"""
 Python versions

Since autowrap depends on PyD, the python version must be 
explicitly stated as a dub configuration and defaults to 3.6. To 
use another version, pass -c $CONFIG to dub where $CONFIG is one 
of:


python27
python34
python35
python36
"""

Could you please provide an example of how can I do this?

Thanks

Re: Sealed classes - would you want them in D?

[Jesse Phillips via Digitalmars-d]

On Thursday, 10 May 2018 at 15:18:56 UTC, Bastiaan Veelo wrote:

How about extending the behaviour of ‘private’, which means 
private except for this module, to ‘final’, which would then 
allow sub typing in the same module but not outside? It would 
not break any code. Are there downsides to such a change?


This was exactly my thought. It fits right in there with Walter's 
reasoning, you already have access to the module's code so rather 
than make you jump through hoops to access, lift the restriction 
within the module.


To rikki's complaint, it would have the same unfortunate side 
affect of people complaining that they can't control the source 
code within the module. It wouldn't be an exception to the rule 
though, it would follow the rule. (I guess it depends on what 
rule you look at)

property += operator

[SrMordred via Digitalmars-d-learn]

struct T
{
int x;
@property ref X(){ return x; }
@property X(int v)
{
x = v;
}
}

T t;
t.X += 10;

The setter 'x = v' are not executed because i´m returning the 
reference of x.
And without the 'ref' the compiler complains because 'x' is not a 
lvalue.


Any solution to make it work like native arr.length+=10 works?

( I Thought on returning a struct with "+=" operator but it is a 
strange solution )

Building dmd/druntime on windows issue

[Andre Pany via Digitalmars-d-learn]

Hi,

I follow the instructions from the wiki to build dmd/druntime 
from source on windows.

https://wiki.dlang.org/Building_under_Windows

Building dmd ends with following text:

---
copy ..\generated\windows\release\32\dmd.exe .
1 file copied.


make -fwin32.mak C=dmd\backend TK=dmd\tk ROOT=dmd\root 
MAKE="make" HOST_DC="dmd" MODEL=32 CC="dmc" LIB="lib" OBJ_MSVC="" 
clean

rmdir /s /q ..\generated
del dmd\msgs.h dmd\msgs.c
C:\D\dmd2\src\dmd\src\dmd\msgs.h cannot be found
del optabgen.exe parser_test.exe example_avg.exe
del ..\generated\windows\release\32\dmd.exe 
..\generated\windows\release\32\dmd_frontend.exe *.map *.obj *.exe

The system cannot find the given path.
---

If my understanding is correct, there are several issues:
- File dmd\msgs.h does not exist
- make deletes path "generated" which is needed in a further step.

There is a file "C:\D\dmd2\src\dmd\src\dmd.exe" created which 
seems to be the build result.


If I now try to build druntime it also fails, because the path 
"generated" does not exist:


---
..\dmd\generated\windows\release\32\dmd -conf= -c -o- -Isrc 
-Iimport -Hfimport\core\sync\barrier.di src\core\sync\barrier.d

Error: '..\dmd\generated\windows\release\32\dmd' not found
---

Kind regards
André

Re: Line breaks in JSON

[bachmeier via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 17:59:26 UTC, jmh530 wrote:
On Thursday, 10 May 2018 at 15:01:57 UTC, rikki cattermole 
wrote:

[snip]

You'll need to unescape them (which is pretty easy, a simple 
replacement here).


For reference, this is invalid json[0]:

```
{
"1
2
3 "
}
```

[0] https://jsonlint.com/


I don't see an unescape function in phobos and below doesn't 
seem to work


string msg2 = 
parseJSON(msg)["markdown"].to!string.replace("\n", " ");


I used replace("\\n", "\n")

[Issue 18850] New: Template overload incorrectly results in recursive expansion error

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18850
   Summary: Template overload incorrectly results in recursive
expansion error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

bug.d

struct Foo(T)
{
alias Foo = Foo!(T, T.init);
}
struct Foo(T, T initialValue)
{
private T value = initialValue;
}
Foo!int n;


> dmd -c file.d
bug.d(3): Error: template instance `Foo!(T, T.init)` recursive template
expansion
bug.d(9): Error: template instance `bug.Foo!int` error instantiating

--

Re: Line breaks in JSON

[jmh530 via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 15:01:57 UTC, rikki cattermole wrote:

[snip]

You'll need to unescape them (which is pretty easy, a simple 
replacement here).


For reference, this is invalid json[0]:

```
{
"1
2
3 "
}
```

[0] https://jsonlint.com/


I don't see an unescape function in phobos and below doesn't seem 
to work


string msg2 = parseJSON(msg)["markdown"].to!string.replace("\n", 
" ");

Disabling copy constructor and passing as rvalue

[ANtlord via Digitalmars-d-debugger]

Hello, everyone!

Short time ago I got a problem creating a container that is felt 
by structure instances of a structure type has disabled copy 
constructor. Actually it is felt by a rvalue instead of an 
instance. I realize that disabling of copying means denying to 
pass an instance by lvalue but there is passing by rvalue that 
means a container owns the instance and as far as I see it's 
supported by dmd.


So... does somebody know any way or any library that implemented 
containers that are able to store non-copyable instances passed 
by rvalue?


Thanks in advance!

[Issue 18743] ConditionalExpression and AssignExpression should require parentheses

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||pull
URL||https://github.com/dlang/dm
   ||d/pull/8237

--

Re: Sealed classes - would you want them in D?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 3:18 AM, Bastiaan Veelo wrote:

On Thursday, 10 May 2018 at 13:22:20 UTC, Piotr Mitana wrote:

Hello,

I've recently thought of sealed classes (sealed as in Scala, not as in 
C#) and am thinking of writing a DIP for it. I decided to start this 
thread first though to gather some opinions on the topic.


For those who never coded Scala and don't know sealed classes: a 
sealed class is a class which can be only extended in the same source 
file.


    sealed class MyClass {}

Translating to D, a sealed class would could only be extended in the 
same module. Additionally I would suggest "sealed(some.package) 
MyClass {}" syntax for classes that could only be extended in the 
particular package.


In Scala an important value of sealed classes is that compiler knows 
that and can aid programmer in pattern matching by detecting the 
missed cases. However, there is another value I see: limiting the 
extension of classes.


[...]

Combining sealed with final library developer can create a completely 
closed type hierarchy.


Any thoughts on that proposal?


How about extending the behaviour of ‘private’, which means private 
except for this module, to ‘final’, which would then allow sub typing in 
the same module but not outside? It would not break any code. Are there 
downsides to such a change?


You can already sub type with private. What you can't do is sub type 
with both private and final. It should remain this way.


Let's not go changing semantics of already understood language features. 
Exceptions to rules are not ok, nor will they be approved.

Re: Line breaks in JSON

[bachmeier via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 15:01:57 UTC, rikki cattermole wrote:

You'll need to unescape them (which is pretty easy, a simple 
replacement here).


For reference, this is invalid json[0]:

```
{
"1
2
3 "
}
```

[0] https://jsonlint.com/


So I see the answer is that I don't understand json. A search 
reveals that this is a common mistake.

[Issue 18176] std.numeric.gapWeightedSimilarity should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
Currently this function is designed to be @nogc. This can't be both @safe and
@nogc at the same time.

--

Re: Sealed classes - would you want them in D?

[Bastiaan Veelo via Digitalmars-d]

On Thursday, 10 May 2018 at 13:22:20 UTC, Piotr Mitana wrote:

Hello,

I've recently thought of sealed classes (sealed as in Scala, 
not as in C#) and am thinking of writing a DIP for it. I 
decided to start this thread first though to gather some 
opinions on the topic.


For those who never coded Scala and don't know sealed classes: 
a sealed class is a class which can be only extended in the 
same source file.


sealed class MyClass {}

Translating to D, a sealed class would could only be extended 
in the same module. Additionally I would suggest 
"sealed(some.package) MyClass {}" syntax for classes that could 
only be extended in the particular package.


In Scala an important value of sealed classes is that compiler 
knows that and can aid programmer in pattern matching by 
detecting the missed cases. However, there is another value I 
see: limiting the extension of classes.


[...]

Combining sealed with final library developer can create a 
completely closed type hierarchy.


Any thoughts on that proposal?


How about extending the behaviour of ‘private’, which means 
private except for this module, to ‘final’, which would then 
allow sub typing in the same module but not outside? It would not 
break any code. Are there downsides to such a change?

Re: Extend the call site default argument expansion mechanism?

[Paul Backus via Digitalmars-d]

On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote:

On 11/05/2018 2:33 AM, Yuxuan Shui wrote:

On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote:

But doing it with default argument expansion saves you 1 
allocation, has 1 less type, while being just as readable. I 
think that's a win.


class -> struct, now it is back to 1 allocation.


Even easier:

alias createDataStructure = (...) => new DataStructure(..., 
alloc);

Re: Line breaks in JSON

[rikki cattermole via Digitalmars-d-learn]

On 11/05/2018 2:56 AM, bachmeier wrote:
I'm using std.json for the first time. I want to download the contents 
of a markdown file from a web server. When I do that, the line breaks 
are escaped, which I don't want. Here's an example:


import std.conv, std.json, std.stdio;

void main() {
 string data =
"This is a paragraph
with line breaks
that shouldn't appear
when the file is loaded
in a text editor.";
   string msg = JSONValue(["markdown": data]).toString;
   string msg2 = parseJSON(msg)["markdown"].to!string;
   writeln(data);
   writeln(msg2);
}

Output:

This is a paragraph
with line breaks
that shouldn't appear
when the file is loaded
in a text editor.
"This is a paragraph\nwith line breaks\nthat shouldn't appear\nwhen the 
file is loaded\nin a text editor."


You'll need to unescape them (which is pretty easy, a simple replacement 
here).


For reference, this is invalid json[0]:

```
{
"1
2
3 "
}
```

[0] https://jsonlint.com/

Re: Extend the call site default argument expansion mechanism?

[Uknown via Digitalmars-d]

On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote:

On 11/05/2018 2:33 AM, Yuxuan Shui wrote:

On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

[...]


But doing it with default argument expansion saves you 1 
allocation, has 1 less type, while being just as readable. I 
think that's a win.


class -> struct, now it is back to 1 allocation.


Alternatively `scope`d classes would also work with dip1000

Line breaks in JSON

[bachmeier via Digitalmars-d-learn]

I'm using std.json for the first time. I want to download the 
contents of a markdown file from a web server. When I do that, 
the line breaks are escaped, which I don't want. Here's an 
example:


import std.conv, std.json, std.stdio;

void main() {
string data =
"This is a paragraph
with line breaks
that shouldn't appear
when the file is loaded
in a text editor.";
  string msg = JSONValue(["markdown": data]).toString;
  string msg2 = parseJSON(msg)["markdown"].to!string;
  writeln(data);
  writeln(msg2);
}

Output:

This is a paragraph
with line breaks
that shouldn't appear
when the file is loaded
in a text editor.
"This is a paragraph\nwith line breaks\nthat shouldn't 
appear\nwhen the file is loaded\nin a text editor."

[Issue 18178] std.path should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f6e4416a72a778bc6cd21fbefb6e72bfd9fb2976
Fix Issue 18178 - std.path should be usable in @safe

https://github.com/dlang/phobos/commit/7ab0e8c4dc013b10c9e54d0f971ea257d6760fd5
Merge pull request #6274 from JackStouffer/issue18178

Fix Issue 18178 - std.path should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18110] most of phobos should be @safe-ly useable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18178, which changed state.

Issue 18178 Summary: std.path should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18178

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Sealed classes - would you want them in D?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 2:43 AM, jmh530 wrote:

On Thursday, 10 May 2018 at 13:47:16 UTC, rikki cattermole wrote:

[snip]

Adding a keyword like sealed isn't desirable.

I'm trying to find fault of the concept, but it definitely is tough.

You basically want protected, but only for specific packages, 
otherwise final.


protected(foo, final)


My read was that he wants an escape hatch on final so that he can extend 
the type in a module and not have to worry about people in other modules 
extending them.


So if he has

module foo;

class A { }

final class B : A {    }

in one module, he wants to be able to create a new

final class C : B {    }

and keep class B as final so that no one else can extend it in another 
module.


You're right, I just didn't put it well.

My current thinking is something along the lines of:

modifier ( !|opt IdentifierList )
modifier ( !|opt IdentifierList , modifier )

Not quite correct grammar, but close enough.

So:

final(!mypackage)

would do what Piotr wants.

Re: Sealed classes - would you want them in D?

[jmh530 via Digitalmars-d]

On Thursday, 10 May 2018 at 13:47:16 UTC, rikki cattermole wrote:

[snip]

Adding a keyword like sealed isn't desirable.

I'm trying to find fault of the concept, but it definitely is 
tough.


You basically want protected, but only for specific packages, 
otherwise final.


protected(foo, final)


My read was that he wants an escape hatch on final so that he can 
extend the type in a module and not have to worry about people in 
other modules extending them.


So if he has

module foo;

class A { }

final class B : A {}

in one module, he wants to be able to create a new

final class C : B {}

and keep class B as final so that no one else can extend it in 
another module.

Re: Extend the call site default argument expansion mechanism?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 2:33 AM, Yuxuan Shui wrote:

On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

[...]


For things like this you can use the OOP Factory pattern, pseudocode:

class DataStructureFactory
{
  this(Allocator alloc)
  {
    this.alloc = alloc;
  }

  Allocator alloc;

  DataStructure createDataStructure(...)
  {
    return new DataStructure(..., alloc)
  }
}

DataStructureFactory factory = new DataStructureFactory(new 
SomeAllocator())

auto data1 = factory.createDataStructure(...)
auto data2 = factory.createDataStructure(...)
auto data3 = factory.createDataStructure(...)


But doing it with default argument expansion saves you 1 allocation, has 
1 less type, while being just as readable. I think that's a win.


class -> struct, now it is back to 1 allocation.

Re: Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 10 May 2018 at 14:30:49 UTC, Seb wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

So in D I can use default argument like this:

int f(int line=__LINE__) {}

[...]


Why not define a TLS or global variable like theAllocator?
Or if you know it at compile-time as an alias?


Because my proposal is better encapsulated. Definitions of 
expanded default arguments are scoped, so in the given example, 
you can have different __ALLOC__ in different scope, where 
different allocators might be needed.


My proposal is basically an alias, but an alias which is 
recognized by compiler as subtitution keywords for default 
arguments (like __LINE__, __FILE__).

Re: Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

[...]


For things like this you can use the OOP Factory pattern, 
pseudocode:


class DataStructureFactory
{
  this(Allocator alloc)
  {
this.alloc = alloc;
  }

  Allocator alloc;

  DataStructure createDataStructure(...)
  {
return new DataStructure(..., alloc)
  }
}

DataStructureFactory factory = new DataStructureFactory(new 
SomeAllocator())

auto data1 = factory.createDataStructure(...)
auto data2 = factory.createDataStructure(...)
auto data3 = factory.createDataStructure(...)


But doing it with default argument expansion saves you 1 
allocation, has 1 less type, while being just as readable. I 
think that's a win.

Re: Extend the call site default argument expansion mechanism?

[Seb via Digitalmars-d]

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

So in D I can use default argument like this:

int f(int line=__LINE__) {}

[...]


Why not define a TLS or global variable like theAllocator?
Or if you know it at compile-time as an alias?

Re: Extend the call site default argument expansion mechanism?

[JN via Digitalmars-d]

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

So in D I can use default argument like this:

int f(int line=__LINE__) {}

And because default argument is expanded at call site, f() will 
be called with the line number of the call site.


This is a really clever feature, and I think a similar feature 
can be useful in other ways.


Say I need to construct a bunch of data structure that takes an 
Allocator argument, I need to do this:


...
auto alloc = new SomeAllocator();
auto data1 = new DataStructure(..., alloc);
auto data2 = new DataStructure(..., alloc);
auto data3 = new DataStructure(..., alloc);
...

This looks redundant. But if we have the ability to define more 
special keywords like __LINE__, we can do something like this:


...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...

Is this a good idea?


For things like this you can use the OOP Factory pattern, 
pseudocode:


class DataStructureFactory
{
  this(Allocator alloc)
  {
this.alloc = alloc;
  }

  Allocator alloc;

  DataStructure createDataStructure(...)
  {
return new DataStructure(..., alloc)
  }
}

DataStructureFactory factory = new DataStructureFactory(new 
SomeAllocator())

auto data1 = factory.createDataStructure(...)
auto data2 = factory.createDataStructure(...)
auto data3 = factory.createDataStructure(...)

Re: Extend the call site default argument expansion mechanism?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 2:20 AM, Yuxuan Shui wrote:

On Thursday, 10 May 2018 at 14:17:50 UTC, rikki cattermole wrote:

On 11/05/2018 2:15 AM, Yuxuan Shui wrote:

[...]


Bad idea, too much magic.


This magic is already there in D. I just want to use it in a different way.


The magic is not already in there.

__LINE__ and __MODULE__ are special, they are constants recognized by 
the compiler and are immediately substituted if not specified.

Re: Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 10 May 2018 at 14:17:50 UTC, rikki cattermole wrote:

On 11/05/2018 2:15 AM, Yuxuan Shui wrote:

[...]


Bad idea, too much magic.


This magic is already there in D. I just want to use it in a 
different way.

Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

So in D I can use default argument like this:

int f(int line=__LINE__) {}

And because default argument is expanded at call site, f() will 
be called with the line number of the call site.


This is a really clever feature, and I think a similar feature 
can be useful in other ways.


Say I need to construct a bunch of data structure that takes an 
Allocator argument, I need to do this:


...
auto alloc = new SomeAllocator();
auto data1 = new DataStructure(..., alloc);
auto data2 = new DataStructure(..., alloc);
auto data3 = new DataStructure(..., alloc);
...

This looks redundant. But if we have the ability to define more 
special keywords like __LINE__, we can do something like this:


...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...

Is this a good idea?

Re: Extend the call site default argument expansion mechanism?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 2:15 AM, Yuxuan Shui wrote:

So in D I can use default argument like this:

int f(int line=__LINE__) {}

And because default argument is expanded at call site, f() will be 
called with the line number of the call site.


This is a really clever feature, and I think a similar feature can be 
useful in other ways.


Say I need to construct a bunch of data structure that takes an 
Allocator argument, I need to do this:


...
auto alloc = new SomeAllocator();
auto data1 = new DataStructure(..., alloc);
auto data2 = new DataStructure(..., alloc);
auto data3 = new DataStructure(..., alloc);
...

This looks redundant. But if we have the ability to define more special 
keywords like __LINE__, we can do something like this:


...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...

Is this a good idea?


Bad idea, too much magic.

Re: Sealed classes - would you want them in D?

[rikki cattermole via Digitalmars-d]

On 11/05/2018 1:22 AM, Piotr Mitana wrote:

Hello,

I've recently thought of sealed classes (sealed as in Scala, not as in 
C#) and am thinking of writing a DIP for it. I decided to start this 
thread first though to gather some opinions on the topic.


For those who never coded Scala and don't know sealed classes: a sealed 
class is a class which can be only extended in the same source file.


     sealed class MyClass {}

Translating to D, a sealed class would could only be extended in the 
same module. Additionally I would suggest "sealed(some.package) MyClass 
{}" syntax for classes that could only be extended in the particular 
package.


In Scala an important value of sealed classes is that compiler knows 
that and can aid programmer in pattern matching by detecting the missed 
cases. However, there is another value I see: limiting the extension of 
classes.


Some time ago I was working on a simple CQRS library and created an 
Entity class, where I wanted only a few specific subtypes for it. The 
library is built over a few defined entity types and user is not able to 
create their own types (should extend the particular subtype instead). 
Sealing the Entity class could enable me to define the closed set of 
subtypes and prevent new direct subtype creation outside the library.


Combining sealed with final library developer can create a completely 
closed type hierarchy.


Any thoughts on that proposal?


Adding a keyword like sealed isn't desirable.

I'm trying to find fault of the concept, but it definitely is tough.

You basically want protected, but only for specific packages, otherwise 
final.


protected(foo, final)

Re: Package method is not virtual and cannot override - a bug or a feature?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 10, 2018 11:52:38 Piotr Mitana via Digitalmars-d-learn 
wrote:
> Given this code:
>
> abstract class A
> {
>  package @property void x(int x);
>  package @property int x();
> }
>
> class B : A
> {
>  package @property override void x(int x) {}
>  package @property override int x() { return 0; }
> }
>
> void main() {}
>
> I get the following message:
>
> onlineapp.d(9): Error: function `onlineapp.B.x` package method is
> not virtual and cannot override
> onlineapp.d(10): Error: function `onlineapp.B.x` package method
> is not virtual and cannot override
>
> Why is that? If the access specifier is private, I can perfectly
> understand it - subclasses can't call the private method of
> parent class, so there's no need in making it virtual. For
> protected/public the code compiles. However, for the package
> protection it may happen that a subclass is in the same package
> (and just happened to me).
>
> Should I file a bug or is there a reason for such behavior?

I don't rememeber the reasoning at the moment, but it's most definitely not
a bug and is on purpose. There's probably a "won't fix" bug in bugzilla for
it if you go digging.

- Jonathan M Davis

Re: mofile - gettext library for D

[Bastiaan Veelo via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 10:57:25 UTC, FreeSlave wrote:
It was a real concern for me that there's no gettext-compatible 
package for D (at least I could not find one in dub registry), 
because it's kind of standard. So I made it myself.


mofile is similar to GNU gettext, but gettext and ngettext 
functions are implemented as member functions of MoFile struct.


This package features only .mo file parsing and getting 
translated messages (with support for plural forms). No 
bindtextdomain present (so no globals)


To produce .mo files you still use standard utilities like 
xgettext, msginit, msgmerge and msgfmt.


dub package: https://code.dlang.org/packages/mofile
github repo: https://github.com/FreeSlave/mofile


Great! Support for i18n is an important step towards world 
domination (in more than one ways).

Sealed classes - would you want them in D?

[Piotr Mitana via Digitalmars-d]

Hello,

I've recently thought of sealed classes (sealed as in Scala, not 
as in C#) and am thinking of writing a DIP for it. I decided to 
start this thread first though to gather some opinions on the 
topic.


For those who never coded Scala and don't know sealed classes: a 
sealed class is a class which can be only extended in the same 
source file.


sealed class MyClass {}

Translating to D, a sealed class would could only be extended in 
the same module. Additionally I would suggest 
"sealed(some.package) MyClass {}" syntax for classes that could 
only be extended in the particular package.


In Scala an important value of sealed classes is that compiler 
knows that and can aid programmer in pattern matching by 
detecting the missed cases. However, there is another value I 
see: limiting the extension of classes.


Some time ago I was working on a simple CQRS library and created 
an Entity class, where I wanted only a few specific subtypes for 
it. The library is built over a few defined entity types and user 
is not able to create their own types (should extend the 
particular subtype instead). Sealing the Entity class could 
enable me to define the closed set of subtypes and prevent new 
direct subtype creation outside the library.


Combining sealed with final library developer can create a 
completely closed type hierarchy.


Any thoughts on that proposal?

[Issue 18848] std.allocator: Regions are non-copyable, yet are passed around in examples

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 18849] std.allocator: AllocatorList uses deallocate and ignores return value in deallocateAll

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait

[Uknown via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 11:06:06 UTC, Per Nordlöw wrote:

On Wednesday, 9 May 2018 at 21:09:12 UTC, Meta wrote:
It's a context pointer to the enclosing 
function/object/struct. Mark the struct as static to get rid 
of it.


Ok, but why an extra void* for `S.tupleof` and not for 
`T.tupleof` which is also scoped inside a unittest?


I'm guessing T is a POD, so it doesn't need a context pointer, 
whereas S is not counted as a POD since a member function was 
@disabled.

Package method is not virtual and cannot override - a bug or a feature?

[Piotr Mitana via Digitalmars-d-learn]

Given this code:

abstract class A
{
package @property void x(int x);
package @property int x();
}

class B : A
{
package @property override void x(int x) {}
package @property override int x() { return 0; }
}

void main() {}

I get the following message:

onlineapp.d(9): Error: function `onlineapp.B.x` package method is 
not virtual and cannot override
onlineapp.d(10): Error: function `onlineapp.B.x` package method 
is not virtual and cannot override


Why is that? If the access specifier is private, I can perfectly 
understand it - subclasses can't call the private method of 
parent class, so there's no need in making it virtual. For 
protected/public the code compiles. However, for the package 
protection it may happen that a subclass is in the same package 
(and just happened to me).


Should I file a bug or is there a reason for such behavior?

[Issue 18849] std.allocator: AllocatorList uses deallocate and ignores return value in deallocateAll

[d-bugmail--- via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||and...@erdani.com

--

[Issue 18849] New: std.allocator: AllocatorList uses deallocate and ignores return value in deallocateAll

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18849
   Summary: std.allocator: AllocatorList uses deallocate and
ignores return value in deallocateAll
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

AllocatorList's deallocateAll has the code:

if (special)
{
special.deallocate(allocators);
}

This has the issues:

- The return value is ignored. If the deallocation failed, the failure should
be communicated to the caller. Currently, this causes a silent memory leak.

- Some allocators, such as Region, can deallocateAll, but cannot deallocate.
Ideally the complete inability to deallocate() should be detected at
compile-time, and such combinations rejected.

- The documentation of AllocatorList has two examples of using it with Region,
which will not work (leak memory) due to the above.

--

[Issue 18848] New: std.allocator: Regions are non-copyable, yet are passed around in examples

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18848
   Summary: std.allocator: Regions are non-copyable, yet are
passed around in examples
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net
CC: and...@erdani.com

Here is an example from
std.experimental.allocator.building_blocks.allocator_list.AllocatorList:

// Ouroboros allocator list based upon 4MB regions, fetched directly from
// mmap. All memory is released upon destruction.
alias A1 = AllocatorList!((n) => Region!MmapAllocator(max(n, 1024 * 4096)),
NullAllocator);

The example features a lambda returning a Region.

However, Regions cannot be copied, as they have a destructor which deallocates
everything. A comment in the implementation says:

/*
TODO: The postblit of $(D BasicRegion) should be disabled because such
objects
should not be copied around naively.
*/

(That's the only occurrence of BasicRegion in Phobos, so I assume that's just
an old name for Region.)

Though NRVO may make the verbatim example code behave correctly, it is fragile,
and small code modifications e.g. to work around issue 18848 can cause
difficult-to-debug problems (due to dangling pointers in other Region
instances).

--

Re: Binderoo additional language support?

[jmh530 via Digitalmars-d]

On Thursday, 10 May 2018 at 07:42:36 UTC, Laeeth Isharc wrote:


I made a start at writing a Jupyter library for writing kernels 
in D. Not sure how long it will be till its finished, but it is 
something in time we will need.  Note that one would then need 
to write a D kernel on top, but that bit should be easy.


Fantastic.

Re: DConf 2018 Livestream

[David Nadlinger via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 09:11:20 UTC, Walter Bright wrote:
This isn't the only time videos of my talks (and others) have 
been lost due to technical problems or simple screwups. I'm 
tired of this happening.


One hopes that the contract with the respective company providing 
A/V services would include penalties for that case (which could 
be funnelled into the foundation funds).


 — David

Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait

[Per Nordlöw via Digitalmars-d-learn]

On Wednesday, 9 May 2018 at 21:09:12 UTC, Meta wrote:
It's a context pointer to the enclosing function/object/struct. 
Mark the struct as static to get rid of it.


Ok, but why an extra void* for `S.tupleof` and not for 
`T.tupleof` which is also scoped inside a unittest?

Re: mofile - gettext library for D

[Andrea Fontana via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 10:57:25 UTC, FreeSlave wrote:
It was a real concern for me that there's no gettext-compatible 
package for D (at least I could not find one in dub registry), 
because it's kind of standard. So I made it myself.


mofile is similar to GNU gettext, but gettext and ngettext 
functions are implemented as member functions of MoFile struct.


This package features only .mo file parsing and getting 
translated messages (with support for plural forms). No 
bindtextdomain present (so no globals)


To produce .mo files you still use standard utilities like 
xgettext, msginit, msgmerge and msgfmt.


dub package: https://code.dlang.org/packages/mofile
github repo: https://github.com/FreeSlave/mofile


Good news!

mofile - gettext library for D

[FreeSlave via Digitalmars-d-announce]

It was a real concern for me that there's no gettext-compatible 
package for D (at least I could not find one in dub registry), 
because it's kind of standard. So I made it myself.


mofile is similar to GNU gettext, but gettext and ngettext 
functions are implemented as member functions of MoFile struct.


This package features only .mo file parsing and getting 
translated messages (with support for plural forms). No 
bindtextdomain present (so no globals)


To produce .mo files you still use standard utilities like 
xgettext, msginit, msgmerge and msgfmt.


dub package: https://code.dlang.org/packages/mofile
github repo: https://github.com/FreeSlave/mofile

[Issue 18847] New: std.allocator: Region uses .parent before it can be set

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18847
   Summary: std.allocator: Region uses .parent before it can be
set
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net
CC: and...@erdani.com

Here is one constructor of
std.experimental.allocator.building_blocks.region.Region:

static if (!is(ParentAllocator == NullAllocator))
this(size_t n)
{
this(cast(ubyte[])(parent.allocate(n.roundUpToAlignment(alignment;
}

If parent has state, then there is no way to set it before it is used in the
constructor.

There is a workaround: copy the contents of the constructor of the invoking
code, then use the constructor taking a buffer, and only then initialize the
parent. This is sub-ideal.

The constructor(s) should probably accept a parent argument as needed, or the
object should support deferred initialization.

--

[DUB][DLS] building package dls doesn't finish

[Kamil Koczurek via Digitalmars-d]

Hello,
I installed an atom extension for D support, but it requires dls 
package to be installed and built. When I fetch and attempt to 
build it (with --build=release) it just says that it's building 
and doesn't change even if I leave it running for several hours.

What can I do to fix it? Or do I just leave it overnight?

Ps. Sorry if it's a wrong section, it's my first time posting 
here.

Re: DConf 2018 Livestream

[rikki cattermole via Digitalmars-d-announce]

On 10/05/2018 9:11 PM, Walter Bright wrote:

On 5/3/2018 2:23 AM, Mike Parker wrote:
Yes, unfortunately some of the videos were lost. We should be good 
from here on out.


I gave the same talk again at Code Europe in Krakow. The video for that 
should appear on youtube in a month.


This isn't the only time videos of my talks (and others) have been lost 
due to technical problems or simple screwups. I'm tired of this 
happening. Next DConf we should have a backup camera sitting on a table.


I have used more expensive cameras while I was at high school than the 
ones used at DConf.


Can't we get an actually decent company to do recordings+streaming?
Surely we can.

Re: DConf 2018 Livestream

[Walter Bright via Digitalmars-d-announce]

On 5/3/2018 2:23 AM, Mike Parker wrote:
Yes, unfortunately some of the videos were lost. We should be good from here on 
out.


I gave the same talk again at Code Europe in Krakow. The video for that should 
appear on youtube in a month.


This isn't the only time videos of my talks (and others) have been lost due to 
technical problems or simple screwups. I'm tired of this happening. Next DConf 
we should have a backup camera sitting on a table.

Re: A bit more Emscripten

[Vladimir Panteleev via Digitalmars-d-announce]

On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote:

https://github.com/CyberShadow/dscripten-tools


Progress update:

- std.stdio.writeln() works
- Using a D main() works (though unittests and static 
constructors still don't)

- WebAssembly output works!
- std.allocator works (at least, Mallocator + building-blocks do)

Re: Binderoo additional language support?

[Laeeth Isharc via Digitalmars-d]

On Thursday, 10 May 2018 at 02:39:41 UTC, Paul O'Neil wrote:

On 05/09/2018 03:50 PM, Ethan wrote:

On Tuesday, 8 May 2018 at 14:28:53 UTC, jmh530 wrote:
I don't really understand what to use binderoo for. So rather 
than fill out the questionnaire, maybe I would just recommend 
you do some work on wiki, blog post, or simple examples.


Been putting that off until the initial proper stable release, 
it's still in a pre-release phase.


But tl;dr - It acts as an intermediary layer between a host 
application written in C++/.NET and libraries written in D. 
And as it's designed for rapid iteration, it also supports 
recompiling the D libraries and reloading them on the fly.


Full examples and documentation will be coming.


Would it make sense to build a REPL or Jupyter kernel on top of 
Binderoo?


I made a start at writing a Jupyter library for writing kernels 
in D. Not sure how long it will be till its finished, but it is 
something in time we will need.  Note that one would then need to 
write a D kernel on top, but that bit should be easy.

Re: D GPU execution module: A survey of requirements.

[Nicholas Wilson via Digitalmars-d]

On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:

On Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:

On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:

Hello,

I'm interested in writing a module for executing D code on 
GPUs. I'd like to bounce some ideas off D community members 
to see what this module needs do.


[...]


Check out https://github.com/libmir/dcompute


Welp... It's not quite what I would have envisioned, but seems 
to fill the role.


Thanks for pointing Dcompute out to me - I only found it 
mentioned in a dead link on the D wiki.


Time to find a new project...


It's not dead, it's just pining for the fjords^H^H^H^H  
hibernating waiting for me to finish undergrad (~7 weeks). You 
are more than welcome to join the development.


Nic

Re: Error: module `hello` is in file 'hello.d' which cannot be read

[phongkhamdakhoathegioi via Digitalmars-d-learn]

On Saturday, 5 May 2018 at 10:39:17 UTC, Alex wrote:

Thank you for you for your quick answer.

I think I allready tryed this, before asking, but ...

C:\>cd D\dmd2\sources

C:\D\dmd2\sources>dmd hello.d
Error: module `hello` is in file 'hello.d' which cannot be read
import path[0] = C:\D\dmd2\windows\bin\..\..\src\phobos
import path[1] = C:\D\dmd2\windows\bin\..\..\src\druntime\import

C:\D\dmd2\sources>


http://suckhoeytecongdong.blogspot.com/2018/05/phong-kham-khoa-huu-tho-lua-ao-co-that.html

[Issue 15099] C++ projects depend on D projects?

[d-bugmail--- via Digitalmars-d-bugs]

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

Manu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Manu  ---
I'm closing this, because it's supported by the new project system.

--

Re: `this` and nested structs

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 10, 2018 06:31:09 Mike Franklin via Digitalmars-d-learn 
wrote:
> On Thursday, 10 May 2018 at 06:22:37 UTC, Jonathan M Davis wrote:
> > Structs don't have that.
>
> Should they?

Honestly, I don't think that classes should have it, but changing it now
would break code (most notably, DWT). IMHO, it would have been far better to
make it explicit like it is in C++, especially since there's no technical
reason why it needs to be built in.

But regardless, when you consider how structs work, having a nested struct
inside a struct have a pointer to its outer struct would be a serious
problem, because the pointer would become invalid as soon as the struct was
moved, which happens quite frequently with structs in D when they're passed
around. Having a nested struct within a class have a reference to its parent
would be more debatable, but it would probably run afoul of how init works,
since the init value for the struct would have to be known at compile-time,
whereas the reference for the class couldn't be. And anyone who wants any
kind of reference to the outer class to be in the struct can just pass it to
the struct's constructor. Adding such a feature to structs would just be
unnecessary magic.

- Jonathan M Davis