Re: [OT] NNTP client and threading

[ketmar via Digitalmars-d]

Walter Bright wrote:

On 2/18/2017 2:11 PM, ketmar wrote:

Walter Bright wrote:
I'm curious about your client project. Can you post a link?

sure:
http://repo.or.cz/knntp.git




I'm curious what problem this solves that other nntp clients do not.
it perfectly fits my needs. i usually see little reason to "adapt" 
myself to something if i can write my own thingy. besides, writing code 
is fun.


i tried pan, snews, some other readers i forgot, and they aren't fit. i 
wanted the UI i did, i wanted twitlists i wrote, and so on. and i 
wanted reader written in D, 'cause i hate to work with a code in 
another language. ;-)




I see that its display is in text mode.
no. ;-) it looks like it, but it isn't. just take a closer look on 
screenshot: the font is proportional. but is was designed to look 
old-fashioned, yeah.



One nice thing about text mode is it works well on low-bandwidth 
connections. I've been heavily criticized for not using a graphical 
IDE, but I work a lot through remote connections, and I've never been 
able to get a remote desktop to work at a reasonable speed, even when 
it is in my house and the connection is not speed limited.

Text mode tools present no problems there.
tbh, most of my tools are console-based. but this time i wanted to do 
something with graphics. yet my terminal tastes still manifest 
'emselves, i guess.



for writing my code i am using my own terminal-based editor. it has 
support for simple syntax highlighting, but that's all: no fancy 
"integration" features, no "project management" (besides multiple edit 
buffers), no autocompletion. the only "advanced" thing it does is rdmd 
output parsing, so i can jump to error location with a single keypress. 
yet it is lightning fast. no, really, no slowdowns even with 25+ 
megabyte(!) files.


i am also using my own terminal emulator too. this one is in C, 'cause 
i didn't finished D rewrite yet. ;-)

How to get the type of a derived class in a method of its base class?

[Max Samukha via Digitalmars-d-learn]

class A {
this(T = this)() {
static assert(is(T == B));
}
}

class B {
}

auto b = new B;

Here, T becomes A, which may be reasonable but is completely 
useless. Is there a way to obtain the type of the class (or class 
instance reference) the method is called on?

mysql-native v1.0.0-rc4

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

One more update to the MySQL/MariaDB client lib, hopefully the last 
before v1.0.0 final.


This one actually includes quite a few more changes I wanted to get in 
as long as it's making the big leap up to v1.0.0 (see below).


For now, this still lives in a separate fork:
https://github.com/Abscissa/mysql-native-experimental

To use it:
$ git clone https://github.com/Abscissa/mysql-native-experimental.git
$ dub add-local path/to/mysql-native-experimental

And then, when you're doing using this preview:
$ dub remove-local path/to/mysql-native-experimental

Docs here:
http://semitwist.com/mysql-native-docs/v1.0.0-rc4/

I'm going to give this a week. If no fundamental, release-delaying 
issues/objections come up, and nobody speaks up that they could use more 
time to evaluate it, then on Feb 26 I'll merge this branch back over to 
the official mysql-native repo, and tag it as v1.0.0.




Changes in 'v1.0.0-rc4' since the previous preview, 'v0.2.0-preview3':

- Much more documentation improvement.

- Added a Prepared.sql getter, to retrieve the sql for a prepared 
statement. (Previously it was inaccessible.)


- ResultSet.asAA and ResultRange.asAA now return Variant[string] instead
of DBValue[string]. DBValue is no longer needed and now deprecated (as 
it was only used by `asAA` and Variant now handles null properly.)


- Fixed: Row.isNull(index) isn't a setter, so don't mark it @property 
(confuses the doc generator).


- Rename MySqlPool to MySQLPool to be consistent with other parts of the 
API.


- MySQLPool now supports vibe.d's ConnectionPool.maxConcurrency feature.

- Improved separation between internal ("mysql.protocol") and external 
interfaces.

  - No longer publicly imports internal-only symbols by default.
  - Renamed module `mysql.protocol.commands` to `mysql.commands`.
  - Renamed module `mysql.protocol.prepared` to `mysql.prepared`.
  - Moved `ParameterSpecialization` into `mysql.prepared` (was in 
`mysql.protocol.extra_types`).
  - Moved `ColumnSpecialization` into `mysql.commands` (was in 
`mysql.protocol.extra_types`).
  - Moved the other public-API members of `mysql.protocol.extra_types` 
into new modules `mysql.metadata` and `mysql.types`.
  - Split module "mysql.common" into two different modules: 
"mysql.exceptions" and "mysql.protocol.socket"


I also reorganized/rewrote the v1.0.0 changelog entry to be a bit more 
readable, so take a look at the overall changes from the previous 
release, v0.1.7, to this latest release candidate, v1.0.0-rc4


https://github.com/Abscissa/mysql-native-experimental/blob/master/CHANGELOG.md

Re: Converting multiple inheritance code into C ++ for D language

[Jean Cesar via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 19:45:45 UTC, biozic wrote:

On Saturday, 18 February 2017 at 19:05:14 UTC, Jean Cesar wrote:
This is exactly what I want this code I did to understand how 
would apply multiple inheritance in D, C # also process using 
interfaces but the difference from C # to D is that C # 
already in the base class you have to define it as interface. 
..


OK, but I guess you are aware that in this code, using 
interfaces and the pseudo-multiple-inheritance is pointless! 
You could just ditch them and use regular methods :)


Yes this code is useless because it will serve as a hello world 
using multiple inheritance or else I study the language in what 
it supports and does not support to have examples where I can 
base myself and have an idea of how to do just to even understand 
how to implement something like this .

Re: The end of curl (in phobos)

[Gavin via Digitalmars-d]

On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
wrote:

As discussed yesterday at DConf, curl in phobos must go.

The plan is as follows.

1. undocument everything curl related in may 2016
2. deprecate everything curl related in may 2017
3. delete everything curl related in may 2018
3.1 move curl stuff to undead

PR: https://github.com/dlang/phobos/pull/4283


Two of the most important modules in a standard library are 
containers & networking. In Phobos they are terrible. How about 
focusing on that than this nonsense? The Curl wrapper is about 
the only useful bit of networking code in the entire standard 
library. How on earth are you gonna compete with Go & Rust with 
useless container & networking modules?

Re: Hello, folks! Newbie to D, have some questions!

[Seb via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:
5. Supposing I devote the time and energy and get up to speed 
on D, would the core language team be welcoming if I feel like 
I can contribute?


Absolutely. Anyone is welcome to contribute. D is very much a 
volunteer effort. Also don't hesitate to point out (or even 
fix) any stumbling blocks you may encounter when starting out.


I can't add more to this than two pointers:

https://wiki.dlang.org/Starting_as_a_Contributor
https://wiki.dlang.org/Get_involved

Re: CTFE Status 2

[Moritz Maxeiner via Digitalmars-d]

On Sunday, 19 February 2017 at 01:52:07 UTC, Stefan Koch wrote:
On Saturday, 18 February 2017 at 22:40:44 UTC, Moritz Maxeiner 
wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:
Hi Guys, due to the old CTFE status thread getting to page 
30, I am now starting a new one.


[...]


Thank you for your continued work on this. I heavily rely on 
D's CTFE functionality and I try to read all your updates on 
it.


Hello Moritz,
D's ctfe functionality is almost complete.
This thread is not about ctfe as it is currently implemented.
I am working on/writing about a faster re-implementation of 
ctfe.


When my work is finished nothing will change functionality 
wise, it will just be much more efficient.


Hello Stefan,
my apologies if I wasn't clear: I'm aware that this isn't about 
adding anything new in terms of functionality, what I intended to 
imply with "heavily rely on" was that I use enough of it for it 
to be noticeable in compile time / memory consumption, which is 
why I'm very happy about potential speedup and/or memory 
consumption reduction in CTFE. One public example of that was 
llvm-d <2.0.

Re: The end of curl (in phobos)

[Matthias Klumpp via Digitalmars-d]

On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky 
wrote:

[...]
For some time I was a proponent of yanking stuff from Phobos 
into oblivion. Now I'm not. Stop breaking code. Yes, we should 
think harder before introducing libraries into Phobos but 
continuing on with removal of stuff just introduces the 
continuous churn for no adequate benefit.


What would anyone get from std.net.curl removal? Are you going 
to find all of D programs and patch them to use something else?


Yes, Phobos is full of historical accidents and cruft. I'm 
constantly tempted to propose Phobos v2 properly _designed_ 
(not *grown*) and without the junk. I really think it might be 
a good idea but only when we actually know what a proper design 
looks like.


Due to writing the AppStream metadata generator in D, which is an 
infrastructure piece of many Linux distributions, I have a fair 
bit of knowledge now about the problems people (especially 
newcomers who just want to scratch an itch and submit a quick 
patch) encounter when working with D code. The inconsistent 
standard library is - after compiler bugs - the biggest issue. 
Some people described Phobos as "PHP-esque" in terms of design, 
and I have to agree with them. Working with it is often 
unpleasant, and you can clearly see which parts of it were 
designed recently and which are "historical accidents".


Constantly shuffling stuff around in Phobos and adding/removing 
things will not solve the problem, it will just give newcomers a 
feeling of insecurity and make the language feel less mature.
Stunningly, a lot of projects write their own primitives instead 
of using Phobos (Vibe, lots of dub modules just providing 
containers, just now another general purpose utility library was 
announced on the forums, ...) which is a clear sign that Phobos 
isn't seen to be sufficient.


I think investigating to build a "Phobos2" standard library would 
be a very good idea - make it opt-in for a while, and then set a 
flag-date and switch, so people will only need to adjust their 
code once to jump on the new version, and don't constantly need 
to play catch with Phobos API breaks and riddle their code with 
version() and static if instructions to be able to compile with 
multiple Phobos and LDC/GDC/DMD versions.


Cheers,
Matthias

Carrying over a project from mono-D to Visual-D

[solidstate1991 via Digitalmars-d]

As Xamarin 5.10 suffers from very serious memory leaks when 
compiling (and I still haven't started to help out in the new 
mono-D thanks to I needed to cling back on an old version and 
there's no way using a new alongside the old), so I need an IDE 
replacement in the meanwhile to continue working on my projects. 
I once rebuilt my project to separate the editor and the engine, 
the engine itself is planned to be multi-platform (with plans to 
try to make it work on a cheap single-board ARM-based PC).

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Mike Parker via Digitalmars-d-announce]

On Saturday, 18 February 2017 at 16:43:43 UTC, Seb wrote:



Excellent idea!
AFAIK reddit doesn't like self posts that much.
Would someone be so kind to post this once the improvements are 
in?


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

(this PR disables the `assert` transformation for now and also 
changes the output to pre.

It will automatically be deployed once merged)


I'll do it. But before I do, I'll want to know that everything is 
working as intended. Post here with a green light and I'll post 
it during one of the peak periods.

Re: Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools in D" by Jon Degenhardt

[Mike Parker via Digitalmars-d-announce]

On Saturday, 18 February 2017 at 21:22:33 UTC, Jon Degenhardt 
wrote:


Regarding a blog post - I haven't talked to Mike Parker, if 
there's interest I'd be open to it.


Yes, there is interest. I was planning to contact you about this 
in my next round of queries. So I suppose now we can skip the 
query and get right to the details.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 02/18/2017 08:42 PM, Nick Sabalausky (Abscissa) wrote:


Or it might be better to just toss this in around the top of the CSS:

--
input, textarea {
 background-color: white;
 color: #333;
}
--



K, just tested it, works for me:

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

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Saturday, 18 February 2017 at 22:40:44 UTC, Moritz Maxeiner 
wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


[...]


Thank you for your continued work on this. I heavily rely on 
D's CTFE functionality and I try to read all your updates on it.


Hello Moritz,
D's ctfe functionality is almost complete.
This thread is not about ctfe as it is currently implemented.
I am working on/writing about a faster re-implementation of ctfe.

When my work is finished nothing will change functionality wise, 
it will just be much more efficient.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[Timothee Cour via Digitalmars-d]

> Doesn't add indentation:
>
> with (module_!"std.stdio, std.traits")
> void fun(T)(File input, T value)
> if (isIntegral!T);

* what is the implementation of `module_` ? `from` defined earlier
doesn't allow for multiple modules as in from!"std.stdio,
std.traits"`. But let's assume it can be done for now.

* when `with` covers multiple declarations, it adds indentation:
with(module_!"std.stdio"){
  declaration1;
  declaration2;
}

* when `with` covers a single one, it doesn't add indentation, but
then `::` can be used instead, with arguably simpler syntax:

`void fun(T)(std.stdio::File input, T value);`
vs
`with (module_!"std.stdio") void fun(T)(File input, T value);`


> with/module_ solves the UFCS member stand-in problem elegantly, how does your 
> proposal solve it?:
> with (module_!"std.range.primitives")
> void func(alias pred, R)(R range)
> if (isInputRange!R && is(typeof(pred(range.front)) == bool);
>
> .front has to refer to *either* a member or an imported UFCS function.

UFCS equally affects the `::`  proposal and the
`module_!""`-without-`with` proposal.

Besides the option of not using UFCS, we can actually use Alias for
this, as I've proposed a while ago in
http://forum.dlang.org/post/mailman.1002.1370829729.13711.digitalmars-d-le...@puremagic.com:

`with (module_!"std.range.primitives") ... pred(range.front)`
vs:
`... pred(range.Alias!(std.range.primitives::front))`

or, if a feature that I've proposed earlier in
http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmar...@puremagic.com
(support UFCS with fully qualified function names) is accepted, it
becomes even simpler:

`... pred(range.(std.range.primitives::front))`


To reiterate what I said earlier:

* `foo.bar::symol` is very well suited for the common case of 1-off
imports, ie when the import is only needed at a particular location.
This is a common case.

* If we want to cover multiple declarations, using something like
`with (module_!"std.stdio, std.traits")` makes sense and is more DRY.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 02/18/2017 11:48 AM, Seb wrote:

On Friday, 17 February 2017 at 16:07:37 UTC, Nick Sabalausky (Abscissa)
wrote:

1. This is pretty awesome.


Thanks a lot :)


2. Looks like someone forgot to set a foreground text color for the
output even though the background is set to white. This makes the
output text invisible for those using eye-friendly light-on-dark systems.


I am not sure I follow. Do you use a custom color scheme or plugin that
sets the body background color to black?


Dark system color scheme, nothing mucking with website CSSes or 
anything. Somewhat bizarrely/irritatingly, there are certain cases 
( and  to my knowledge, maybe others) where browsers 
inherit default color settings from the OS[1] instead of from a built-in 
browser-default CSS.


Since my OS is set up to default to (near-)white text on a (near-)black 
background, the browser decides "Oh, ok, I'll use white text on a black 
background for inputs and textareas." But then the site's CSS tells it 
to use a white background. And says nothing about text color. Browser 
says: "Ok! So, white text (system textbox default) on a white background 
(website CSS)!!"


[1] Browsers taking theme defaults from the OS was appropriate behavior 
back in HTML1 when the whole web was actually designed from the 
ground-up to automatically adapt to the machine being used. But not so 
much now that every site/page in the world uses its own theme and 
formatting system[2], and even the browser's own default css *mostly* 
(with, of course, these broken exceptions) separates itself from the OS, 
leaving occasionally broken readability.


[2] The site-chosen formatting system occasionally being one that 
attempts to partially adapt to the local machine, to varying degrees of 
success. Thanks, legacy of HTML2/4!


Did I mention I hate web browsers? ;)


What exactly would be the best way for you to resolve your problem?
Maybe you can even submit a PR yourself? - the CSS is here:

https://github.com/dlang/dlang.org/blob/master/css/style.css#L1611


I'm working out building the site locally right now so I can test 
(building it seems to be taking awhile), but:


Looks like the site is mostly using #333 for text color. You could just 
toss in "color: #333;" right next to "background: white;" for the 
d_code_output sections (might not matter for the div version, but 
wouldn't hurt either.) That should work.


Or it might be better to just toss this in around the top of the CSS:

--
input, textarea {
background-color: white;
color: #333;
}
--

Re: [OT] NNTP client and threading

[Walter Bright via Digitalmars-d]

On 2/18/2017 2:11 PM, ketmar wrote:

Walter Bright wrote:

On 2/18/2017 1:37 PM, ketmar wrote:

i think that we should have an article on wiki for client writers. no, really,
some knowledge is here but never written, so people like me have to figure it
out each time. not that there are so many client writers, of course, but... oh,
ok, i guess that i'll write a short summary on this later. ;-)

I'm curious about your client project. Can you post a link?


sure:

http://repo.or.cz/knntp.git
https://files.catbox.moe/wxga1k.png

it is really titled "dingo", not "knntp", but it is not possible to rename repos
on repo.or.cz. ;-)

but please note that it is not "pure D", i'm using my slightly modified
dmd/druntime/phobos fork. it is completely compatible with "vanilla", but i am
usually never "vanilizing" code that i'm not intending to announce/present to
other people. so you won't be able to build it out of the box (yet required
changes to "vanilize" it are minimal).

i added a screenshot, so you can make your eyes bleed without building my code. 
;-)

and i am now writing an email client, with the slightly modified dingo engine as
backend (and the same eye-bleeding frontend ;-).

it is also using Adam D. Ruppe's simpledisplay.d module to do all the low-level
gfx, and his email.d module to decode mime messages. and alot of my own "iv"
modules, of course.


I'm curious what problem this solves that other nntp clients do not. I see that 
its display is in text mode. One nice thing about text mode is it works well on 
low-bandwidth connections.


I've been heavily criticized for not using a graphical IDE, but I work a lot 
through remote connections, and I've never been able to get a remote desktop to 
work at a reasonable speed, even when it is in my house and the connection is 
not speed limited.


Text mode tools present no problems there.

Re: The end of curl (in phobos)

[Chris Wright via Digitalmars-d]

On Sat, 18 Feb 2017 21:41:51 +, ketmar wrote:

> Seb wrote:
>> So what's the consensus on this issue?
> 
> leave curl where it is now.
> 
> i am teh user. i have alot of code depending on std.net.curl. i hope
> that "we are not breaking user's code" motto is not just a PR slogan.

I've got a fair bit too.

Re: tanya library 0.2.0

[Seb via Digitalmars-d-announce]

On Saturday, 18 February 2017 at 15:51:59 UTC, Eugene Wissner 
wrote:

It isn't really a release announce, maybe a pre-release.

tanya is a general purpose library, used mostly for networking 
by me. It is an attempt to develop an alternative memory model 
for D; 100% of the library are usable in @nogc code.


Sounds really cool!


tanya contains an event loop, containers, an URL parsing 
routine and alternative TCP sockets implementation, multiple 
precision integer. The library is cross plattform, but not 
thread-safe yet.


Do you know about eventcore [1] (event loop abstraction)?
I hope that this will soon be submitted to Phobos as everyone 
seems to be brewing their own solution and I am _not_ looking 
forward to manage to find a way to run five event loops when I 
want to use fix different libraries.


[1] https://github.com/vibe-d/eventcore

The memory management is based on allocators. The allocators 
are one-way compatible with std.experimental.allocator, it 
means my allocators can be used with 
std.exeperimental.allocator but the std.experimental.allocator 
isn't usable with my lbirary (though it is pretty 
straightforward to write a wrapper for phobos allocators). 
tanya's allocators follow Bloomberg Allocator Model, see 
discussions on BDE Allocator Model for pro and contra.


From [2] and your API I get that the BDE API is:

virtual void* allocate(size_type size)
virtual void deallocate(void *address)

whereas you extended this by:

   int alignment()
   void[] allocate(in size_t size)
   bool deallocate(void[] p)
   bool reallocate(ref void[] p, in size_t size)
   bool reallocateInPlace(ref void[] p, in size_t size)

Well obviously the std.experimental.allocator protocol is more 
complicated:


uint alignment()
void[] allocate(size_t, TypeInfo ti = null)
void[] alignedAllocate(size_t n, uint a)
void[] allocateAll()
bool expand(ref void[], size_t);
bool reallocate(ref void[], size_t);
bool alignedReallocate(ref void[] b, size_t size, uint 
alignment);

Ternary owns(void[] b);
Ternary resolveInternalPointer(void* p, ref void[] result);
bool deallocate(void[] b);
bool deallocateAll();
Ternary empty();

However I would be very interested in hearing your reasons for 
not using it.
Keep in mind that std.experimental.allocator is supposed to be a 
general purpose library exactly to avoid everyone writing their 
own, incompatible Allocators ;-)

So please raise your voice as long as it's still in experimental!

[2] https://github.com/bloomberg/bde/wiki/BDE-Allocator-model

Re: The end of curl (in phobos)

[Seb via Digitalmars-d]

On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky 
wrote:
Yes, Phobos is full of historical accidents and cruft. I'm 
constantly tempted to propose Phobos v2 properly _designed_ 
(not *grown*) and without the junk. I really think it might be 
a good idea but only when we actually know what a proper design 
looks like.


You are not the only one!
Did you follow Ilya's proposal about a betterC modular standard 
library?


http://forum.dlang.org/post/phexetutyelrssyru...@forum.dlang.org

Unfortunately it died because of the fear of "balkanizing the 
community" with such a development...


(though I am not sure how it could be more "balkanized" as atm 
everyone seems to grow their own home-made libraries)

[Issue 17147] package build fails without useful info after upgrade to v2.073.0

[via Digitalmars-d-bugs]

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

igor.khasi...@gmail.com changed:

   What|Removed |Added

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

--

[Issue 17147] package build fails without useful info after upgrade to v2.073.0

[via Digitalmars-d-bugs]

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

--- Comment #1 from igor.khasi...@gmail.com ---
Fixed with 2.073.1

--

Re: The end of curl (in phobos)

[Dmitry Olshansky via Digitalmars-d]

On 2/18/17 10:20 PM, Seb wrote:

On Monday, 9 May 2016 at 10:44:13 UTC, ZombineDev wrote:

On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:

On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:

But given that std.net.curl handles stuff like SSL/TLS, we _can't_
actually replace all of its functionality - at least not without
adding a dependency on a different C library, since there's no way
that it's sane to do the crypto stuff ourselves without a crypto
expert, and even then, we should think twice about it. I could see
implementing the SSL/TLS protocols themselves but not the crypto
they use. If we replace std.net.curl, we likely should just provide
the basic HTTP functionality, and leave the rest to a dub package
that we move std.net.curl to.


Any chances that we can produce good crypto code over time? And
verify it with experts, of course.


https://github.com/etcimon/botan AFAIK, it is already used in
production by its author, in combination with libasync + vibe.d +
http2 for a full stack D solution.



So what's the consensus on this issue?
Can't we simply move std.net.curl and etc.c.curl to undead and just
_not_ include it in Phobos?
Anyone reasonable will use requests [1], vibe.d's async requestHTTP [2]
or their home-grown library anyways. As mentioned in another thread [3],
Phobos is bloated with "old" modules that wouldn't have made it through
today's review process.


For some time I was a proponent of yanking stuff from Phobos into 
oblivion. Now I'm not. Stop breaking code. Yes, we should think harder 
before introducing libraries into Phobos but continuing on with removal 
of stuff just introduces the continuous churn for no adequate benefit.


What would anyone get from std.net.curl removal? Are you going to find 
all of D programs and patch them to use something else?


Yes, Phobos is full of historical accidents and cruft. I'm constantly 
tempted to propose Phobos v2 properly _designed_ (not *grown*) and 
without the junk. I really think it might be a good idea but only when 
we actually know what a proper design looks like.


---
Dmitry Olshansky

Re: CTFE Status 2

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


[...]


Thank you for your continued work on this. I heavily rely on D's 
CTFE functionality and I try to read all your updates on it.

Re: scope with if

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 17 February 2017 at 20:06:19 UTC, berni wrote:

I wonder if it's possible to do something like this:


import std.stdio;

void main(string[] args)
{
   if (args[1]=="a")
   {
   write("A");
   scope (exit) write("B");
   }

   write("C");
}


I expected the output to be ACB not ABC.


Scope guards are documented here[1][2] and that example behaves 
according to the spec. You can reach what I understood to be your 
objective by implementing the desired functionality on top of a 
scope guard, though:


---
import std.stdio;

void main(string[] args)
{
void delegate()[] finalizers;
scope (exit) foreach (onExit; finalizers) onExit();

if (args.length >= 2 && args[1] == "a")
{
writeln("A");
finalizers ~= { writeln("B"); };
}

writeln("C");
}
---

Keep the following in mind, though[2]:
A scope(exit) or scope(success) statement may not exit with a 
throw, goto, break, continue, or return; nor may it be entered 
with a goto.

i.e. those finalizers must not throw.

On Friday, 17 February 2017 at 20:06:19 UTC, berni wrote:
I understand, that the scope ends at the end of the if, but I 
wonder, if it's possible to have a "conditional scope" or 
something like this.


As shown in the example above, if you want functionality that is 
not provided by the default scope guard behaviour you'll have to 
implement it on top of them.


[1] https://tour.dlang.org/tour/en/gems/scope-guards
[2] https://dlang.org/spec/statement.html#ScopeGuardStatement

Re: Hello, folks! Newbie to D, have some questions!

[berni via Digitalmars-d-learn]

I'm new here too (never heard of D before 2017).


c). The whole community seems infused with both the Feminism/SJW


I didn't tried out Rust, but that would draw me away too. 
(Incidentally it was a comment on alternatives for Rust, that 
pointed me to D.)


2. I am also curious as to what would be the best path for a 
complete beginner to D to learn it effectively?


I started with the online version of the book of Ali Çehreli but 
after a while I decided to buy it and was impressed on its size 
(more than 700 pages!). Meanwhile I'm halfway through.


At the same time I'm working on a project of mine, which I just 
started writing in C++ last december, because I couldn't find a 
better language and thought I had to bite the bullet. Meanwhile 
it's completely rewritten in D (but two lines of C code that I 
need to use a C-libraray). Whenever I came across a new concept 
in the book I tried to refactor that project using this concept.


This approach worked very well for me. (And I appreciate this 
Learn-forum, because else I'd not dare to ask my seemingly silly 
questions.)


You wrote:

... area thoroughly!The introspection ...


I just realised, how much I'm thinking in D allready when I saw 
this: At first glance I wondered, what this thoroughly-template 
is about... ;-)

Re: [OT] NNTP client and threading

[ketmar via Digitalmars-d]

Walter Bright wrote:

On 2/18/2017 1:37 PM, ketmar wrote:
i think that we should have an article on wiki for client writers. 
no, really,
some knowledge is here but never written, so people like me have to 
figure it
out each time. not that there are so many client writers, of course, 
but... oh,

ok, i guess that i'll write a short summary on this later. ;-)

I'm curious about your client project. Can you post a link?


sure:

http://repo.or.cz/knntp.git
https://files.catbox.moe/wxga1k.png

it is really titled "dingo", not "knntp", but it is not possible to 
rename repos on repo.or.cz. ;-)


but please note that it is not "pure D", i'm using my slightly modified 
dmd/druntime/phobos fork. it is completely compatible with "vanilla", 
but i am usually never "vanilizing" code that i'm not intending to 
announce/present to other people. so you won't be able to build it out 
of the box (yet required changes to "vanilize" it are minimal).


i added a screenshot, so you can make your eyes bleed without building 
my code. ;-)


and i am now writing an email client, with the slightly modified dingo 
engine as backend (and the same eye-bleeding frontend ;-).


it is also using Adam D. Ruppe's simpledisplay.d module to do all the 
low-level gfx, and his email.d module to decode mime messages. and alot 
of my own "iv" modules, of course.

Re: Hello, folks! Newbie to D, have some questions!

[Moritz Maxeiner via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
My rudimentary knowledge of the D ecosystem tells me that there 
is a GC in D, but that can be turned off. Is this correct?


Technically yes; you will lose core functionality, though, if you 
do.
I don't have the complete list at hand, but e.g. dynamic and 
associative arrays are one of the things you won't be able to use 
without the GC IIRC. If you use the reference compiler (dmd), you 
can use the flag `-vgc` to be shown all the GC allocations in a D 
program.


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
Also, some threads online mention that if we do turn off GC, 
some of the core std libraries may not fully work. Is this 
presumption also correct?


Yes. Everything in Phobos that uses features depending on the GC 
won't work anymore.


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine?


If you don't turn the GC off you should be fine. The GC will - 
AFAIK - only perform a collection cycle as a result of an 
allocation call to it, so you can avoid slow collection cycles 
without turning it off.


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
If you could share your experiences and domains of use, that 
would also be very helpful for me.


I mostly use D for writing tools for my own use that have to 
interact with C APIs.


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
Secondly, how stable is the language and how fast is the pace 
of development on D?


The parts of the language I need are pretty stable, but I don't 
think I use even half of what the language offers (D is very 
complex).
Regarding speed, you can see the numbers (git tags) for yourself 
here[0].


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
2. I am also curious as to what would be the best path for a 
complete beginner to D to learn it effectively?


That's usually not something someone can tell you, since every 
person learns differently.
Personally, when I started with D (back in D1 days) I read the 
articles about it and then just tried writing tools in it, so I 
suggest reading these[1]


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
I am a relatively fast learner (and I learn better by context, 
as in, some core unifying idea described and then elucidated 
through big examples instead of learning in bits and pieces).


I'd describe D's unifying idea as "allow people to write complex, 
native software without all the C/C++ insanity". Though D comes 
with it's own share of insanity, of course.


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
Are there any books/video tutorials that you would recommend 
(aside from this site itself).


I personally would not recommend books at the very start of 
learning a language (if one is already proficient with native 
programming in general), but only after one has already gotten 
comfortable with it and is looking for a comprehensive overview.

Regardless, I've heard good things about two books[2][3].
Since I loathe video tutorials I can't add anything on that point.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
3. Are there some small-scale Open Source projects that you 
would recommend to peruse to get a feel for and learn idiomatic 
D?


Technically there's no such thing as idiomatic D as D is 
multi-paradigm. You can see some sensible idioms here[4], but no, 
I would not recommend reading anyone's D code just to get a 
feeling for "idiomatic D".


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
4. I have heard good reports of D's metaprogramming 
capabilities (ironically enough, primarily from a thread on the 
Rust user group),


This doesn't surprise me, honestly, since Rust's (compile time) 
metaprogramming capabilities are below D's and from my experience 
people in both communities are well aware of that. There are 
threads on Reddit about this topic if you have the time to dig 
them up. D's advanced compile time features are one of the main 
reasons I'm unlikely to switch to anything else for my tools (in 
my experience there is no other native programming language that 
let's me get things done as fast - in terms of development time - 
as D).


On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
and coming from a Common Lisp (and some  Racket) background, I 
am deeply interested in this aspect. Are  D macros as powerful 
as Lisp macros? Are they semantically similar (for instance, I 
found Rust's macros are quite similar to Racket's)?


D does not have macros, it has compile time function 
execution[5], templates[6],

 mixins[7], and template mixins[8].

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
5. Supposing I devote the time and energy and get up to speed 
on D, would the core language team be welcoming if I feel 

Re: [OT] NNTP client and threading

[Walter Bright via Digitalmars-d]

On 2/18/2017 1:37 PM, ketmar wrote:

i think that we should have an article on wiki for client writers. no, really,
some knowledge is here but never written, so people like me have to figure it
out each time. not that there are so many client writers, of course, but... oh,
ok, i guess that i'll write a short summary on this later. ;-)


I'm curious about your client project. Can you post a link?

Re: Hello, folks! Newbie to D, have some questions!

[ketmar via Digitalmars-d-learn]

timmyjose wrote:
Thanks for the very comprehensive response! I think most of my doubts 
are cleared now. You're right though that I'm probably worrying too 
much about GC with my current use case.


i can tell you that i'm doing things like, for example, ZX Spectrum 
emulator and hobbyst videogames (everything in D, even low-level gfx), 
i never really cared about "avoiding GC", and i can maintain solid 
35/50/60 FPS (depending of my needs) with my code.


i.e. that "GC-phobia" (i'm not talking about you specifiallly, of 
course, sorry) is mostly based on nothing. as GC will never fire "on 
it's own", and you can control it, avoiding GC is not unnecessary 
(except some very special cases, of course ;-). the key tech here (as 
usual) is to not allocate in tight loops, plan your memory discipline 
and such. nothing new for people used to systems languages. ;-)


sure, you can stop worrying about that and use D as some kind of 
scripting language too, and still have all the features like type 
checking. for things like IRC or email client i absolutely don't care 
about allocations (i.e. doing it left and right) and just letting GC to 
do it's work. my usual IRC client uptime is several monthes (after that 
it runs out of memory, but this is 'cause it never does any cleanup on 
it's data, keeping all logs and db in memory. i am too lazy to finish 
it. note that is it not a GC fault, it is my code. ;-).

Re: Hello, folks! Newbie to D, have some questions!

[Daniel Kozak via Digitalmars-d-learn]

Dne 18.2.2017 v 21:15 timmyjose via Digitalmars-d-learn napsal(a):


Hello folks,

I am interested in learning D (just starting out, did a few of the 
exercises on the D tour), and had some questions before I decide to 
jump right in. My questions are genuinely motivated by my experiences 
and expectations, so please forgive me if some questions don't come 
across as well as my intentions!


1. I have some experience with both C and C++, and have been learning 
Rust for a while, but a few things put me off about the whole business -


a). The core language appears to be simple enough, but becomes 
increasingly complex as I begin writing larger programs.


b). The whole ownership system is easy to understand, but the APIs 
become very complicated and unwieldy, and more time appears to be 
spent on understanding and ensuring that memory is being used 
correctly than on the core program logic.


c). The whole community seems infused with both the Feminism/SJW (I 
don't care about those communities, but it feels weird having a 
programming community get sidetracked by all that bullshit), and too 
much of Ruby-on-Rails culture (probably started with Steve Klabnik) so 
that it doesn't feel like any real systems programmers are focusing on 
that language, and finally, d). The whole language feels like a bit of 
patchwork of random ideas, and also the whole "safety" and "no 
segfaults" guarantees seem to have lesser and lesser RoI as time goes by.


Sorry for the rant, I didn't realise I was quite that frustrated! 
That's just to give some background about me and my recent 
experiences! :D


In that regard, I suppose I'll get a better feel of the community here 
as I interact more, but I have high hopes that it'll be much more 
technical than purely social!

Hi, welcome in D community


2. I am more interested in learning D as a pure systems programming 
language so that I can develop my own tools (not looking to develop an 
OS, just some grep-scale tools to start off with). In that regard, I 
have a few concerns about the GC. My rudimentary knowledge of the D 
ecosystem tells me that there is a GC in D, but that can be turned 
off. Is this correct? Also, some threads online mention that if we do 
turn off GC, some of the core std libraries may not fully work. Is 
this presumption also correct? In this regard, I am curious to know if 
I would face any issues (with my intent in mind), or will I do just 
fine? If you could share your experiences and domains of use, that 
would also be very helpful for me




Yes, by default D use GC. And yes there is a some part of D standard 
library which uses GC. But it is something you can avoid if you want. I 
am using D for many years and for almost anything and never have issue 
with GC.


Secondly, how stable is the language and how fast is the pace of 
development on D?


Again, sorry for my ignorance if I have been wrong-footed on some (or 
all) points.


D stability is good, really good, for many of us too good :P. I have 
been using D for many years (five or six). And right now there is a big 
effort to never break anything until it makes really sense.


OTOH D development is quite fast. So there are many improvements with 
every release





2. I am also curious as to what would be the best path for a complete 
beginner to D to learn it effectively? I am a relatively fast learner 
(and I learn better by context, as in, some core unifying idea 
described and then elucidated through big examples instead of learning 
in bits and pieces). How did you folks learn D? I'm sure hearing your 
experiences would be helpful too. Are there any books/video tutorials 
that you would recommend (aside from this site itself).
I can't help here because I am using D for a long time, so I do not 
remember how I have learned it.


3. Are there some small-scale Open Source projects that you would 
recommend to peruse to get a feel for and learn idiomatic D?


It is maybe not small-scale but idiomatic D code is in phobos itself.



4. I have heard good reports of D's metaprogramming capabilities 
(ironically enough, primarily from a thread on the Rust user group), 
and coming from a Common Lisp (and some Racket) background, I am 
deeply interested in this aspect. Are D macros as powerful as Lisp 
macros? Are they semantically similar (for instance, I found Rust's 
macros are quite similar to Racket's)?
I do not know Lisp macros, but AFAIK there are not semantically similar. 
OTOH D metaprogramming is really powerful and there has been some 
proposals to improve that https://wiki.dlang.org/DIP50


5. Supposing I devote the time and energy and get up to speed on D, 
would the core language team be welcoming if I feel like I can 
contribute?


That's all off the top of my head at the moment. Perhaps I'll have 
more questions as I read the responses. Thanks in advance!


Cheers.

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 21:27:55 UTC, sarn wrote:

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

[...]


Hi :)


[...]


Okay, yes, it's easy to turn off or control the GC.  It's also 
easy to control memory allocation in general (unlike, say, 
Java, where it's practically impossible to do anything without 
writing "new").


Also, yes, a lot of the standard library doesn't work if you do 
that.  A lot does work, but a lot doesn't.  The biggest blocker 
is the use of exceptions, which currently rely on GC (though 
there's interest in changing that).


But I think the real answer to your question is in this thread:
https://forum.dlang.org/thread/o6c9tj$2bdp$1...@digitalmars.com
(Silicon Valley D Meetup - January 26, 2017 - "High Performance 
Tools in D" by Jon Degenhardt)



[...]


When I first started using D about four years ago, it was easy 
to hit compiler bugs and basic things that didn't work.  It 
don't find that happens much nowadays when I'm doing everyday 
programming.


There's plenty of new stuff happening, like escape analysis, 
but the foundation is getting pretty good.  I think the biggest 
gap is the number of libraries compared to, say, Python, but 
personally I'm happy binding to C libraries, and there are 
plenty of them.



[...]


Some people have written tutorials.  It sounds like you're 
already experienced with programming, so the fastest way is 
probably to just dive in.  Get the basics from a small 
tutorial, then pick a small project (or some practice 
programming problems) and start coding with the standard 
library docs on hand :)



[...]


Lisp macros let you rewrite features at the interpreter level.  
Walter Bright has explicitly said he doesn't like that kind of 
macro (I don't think he even likes the C preprocessor's macros).


D's metaprogramming is more constrained in that sense, but it's 
powerful at code generation (see templates and the "mixin" 
keyword), compile-time code execution, and compile-time 
introspection.  Compile-time introspection is one of my 
favourite features.  If, for example, you need an array of all 
the names of single argument methods (or whatever) from a 
class, you can get it.


Take a look at ctRegex in the standard library for a great 
example of what can be done.



[...]


I'm not the core team, but I'm confident the answer is yes :)


Wow! That was an excellent response. Thank you!

I'll be sure to check out the thread that you linked in detail (a 
lot of it went over my head, but I'm sure it'll all make more 
sense soon). I also managed to dig out the YouTube link from 
there. :-)


Also, thanks for sharing your experience. It really does help. I 
was a bit apprehensive because these days rather than the effort, 
I'm more concerned with the time invested (who isn't, right?), 
and reading that your experience with D helps put me at ease.


About metaprogramming, yes, that is one part that I'm really 
interested in, and I would love to explore that area 
thoroughly!The introspection example is pretty cool! I'm pretty 
sure I'll have tons of questions once I get going with D, and the 
community has been very welcoming so far! :-)

Re: The end of curl (in phobos)

[ketmar via Digitalmars-d]

Seb wrote:

So what's the consensus on this issue?


leave curl where it is now.

i am teh user. i have alot of code depending on std.net.curl. i hope 
that "we are not breaking user's code" motto is not just a PR slogan.

Re: [OT] NNTP client and threading

[ketmar via Digitalmars-d]

Vladimir Panteleev wrote:
Even in the presence of "In-Reply-To", "References" is still useful 
when different parties see different Message-IDs (e.g. due to 
mailing-list gateways). That way, replies (except top-level replies) 
will still at least be nested in the right thread instead of 
appearing as a new thread.


ah, really, i forgot that msgid can be changed by some intermediary. 
tnx.


i think that we should have an article on wiki for client writers. no, 
really, some knowledge is here but never written, so people like me 
have to figure it out each time. not that there are so many client 
writers, of course, but... oh, ok, i guess that i'll write a short 
summary on this later. ;-)

[Issue 17048] [REG 2.071] Synchronized class methods give warnings for RMW operations

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Hardware|x86_64  |All
Summary|Synchronized class methods  |[REG 2.071] Synchronized
   |give warnings for RMW   |class methods give warnings
   |operations  |for RMW operations
 OS|Linux   |All
   Severity|enhancement |regression

--

Re: Hello, folks! Newbie to D, have some questions!

[sarn via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:
Also, some threads online mention that if we do turn off GC, 
some of the core std libraries may not fully work. Is this 
presumption also correct?


Yes. Whenever a std function returns a new string or some such 
it's going to be GC-allocated.


This particular problem isn't so bad as it might sound because D 
string functions are based on ranges.

Re: Hello, folks! Newbie to D, have some questions!

[sarn via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

Hello folks,


Hi :)

2. I am more interested in learning D as a pure systems 
programming language so that I can develop my own tools (not 
looking to develop an OS, just some grep-scale tools to start 
off with). In that regard, I have a few concerns about the GC. 
My rudimentary knowledge of the D ecosystem tells me that there 
is a GC in D, but that can be turned off. Is this correct? 
Also, some threads online mention that if we do turn off GC, 
some of the core std libraries may not fully work. Is this 
presumption also correct?


Okay, yes, it's easy to turn off or control the GC.  It's also 
easy to control memory allocation in general (unlike, say, Java, 
where it's practically impossible to do anything without writing 
"new").


Also, yes, a lot of the standard library doesn't work if you do 
that.  A lot does work, but a lot doesn't.  The biggest blocker 
is the use of exceptions, which currently rely on GC (though 
there's interest in changing that).


But I think the real answer to your question is in this thread:
https://forum.dlang.org/thread/o6c9tj$2bdp$1...@digitalmars.com
(Silicon Valley D Meetup - January 26, 2017 - "High Performance 
Tools in D" by Jon Degenhardt)


In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine? If you could 
share your experiences and domains of use, that would also be 
very helpful for me. Secondly, how stable is the language and 
how fast is the pace of development on D?


When I first started using D about four years ago, it was easy to 
hit compiler bugs and basic things that didn't work.  It don't 
find that happens much nowadays when I'm doing everyday 
programming.


There's plenty of new stuff happening, like escape analysis, but 
the foundation is getting pretty good.  I think the biggest gap 
is the number of libraries compared to, say, Python, but 
personally I'm happy binding to C libraries, and there are plenty 
of them.


2. I am also curious as to what would be the best path for a 
complete beginner to D to learn it effectively? I am a 
relatively fast learner (and I learn better by context, as in, 
some core unifying idea described and then elucidated through 
big examples instead of learning in bits and pieces). How did 
you folks learn D? I'm sure hearing your experiences would be 
helpful too. Are there any books/video tutorials that you would 
recommend (aside from this site itself).


Some people have written tutorials.  It sounds like you're 
already experienced with programming, so the fastest way is 
probably to just dive in.  Get the basics from a small tutorial, 
then pick a small project (or some practice programming problems) 
and start coding with the standard library docs on hand :)


4. I have heard good reports of D's metaprogramming 
capabilities (ironically enough, primarily from a thread on the 
Rust user group), and coming from a Common Lisp (and some 
Racket) background, I am deeply interested in this aspect. Are 
D macros as powerful as Lisp macros? Are they semantically 
similar (for instance, I found Rust's macros are quite similar 
to Racket's)?


Lisp macros let you rewrite features at the interpreter level.  
Walter Bright has explicitly said he doesn't like that kind of 
macro (I don't think he even likes the C preprocessor's macros).


D's metaprogramming is more constrained in that sense, but it's 
powerful at code generation (see templates and the "mixin" 
keyword), compile-time code execution, and compile-time 
introspection.  Compile-time introspection is one of my favourite 
features.  If, for example, you need an array of all the names of 
single argument methods (or whatever) from a class, you can get 
it.


Take a look at ctRegex in the standard library for a great 
example of what can be done.


5. Supposing I devote the time and energy and get up to speed 
on D, would the core language team be welcoming if I feel like 
I can contribute?


I'm not the core team, but I'm confident the answer is yes :)

Re: Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools in D" by Jon Degenhardt

[Jon Degenhardt via Digitalmars-d-announce]

On Saturday, 18 February 2017 at 07:50:02 UTC, Joakim wrote:
On Friday, 27 January 2017 at 18:20:53 UTC, Jon Degenhardt 
wrote:
On Friday, 27 January 2017 at 16:21:51 UTC, Jack Stouffer 
wrote:

On Friday, 27 January 2017 at 03:58:26 UTC, Ali Çehreli wrote:

And this:

  http://youtu.be/-DK4r5xewTY


Hey Jon, if you're in this thread, are you able to post any 
of the code that you use for tsv parsing?


Code has been open-sourced: 
https://github.com/eBay/tsv-utils-dlang


The performance benchmarks showed in the talk are not in the 
repo, the benchmarks currently listed are from a year ago. I'm 
planning to update the repo in the next few weeks, probably 
after the next LDC release.


If there are questions about specific types of things perhaps 
a thread in General forum would work.


--Jon


Watched the video some time back, interesting results.  Any 
plans to blog about this?  It would be great if you could run 
them through a profiler too, see why D is so much faster.  
Would be really worth writing this up, maybe on the D blog.


Thanks for the feedback. I'm pretty close to publishing the 
benchmarks, they'll go in a doc file in the repository. They 
weren't quite complete when the meetup happened.


Regarding a blog post - I haven't talked to Mike Parker, if 
there's interest I'd be open to it.


As to why the tools compare so well - That's a really intriguing 
question, especially since the tools favor using high level 
constructs from D / Phobos rather than hand-built data structures 
or memory management. I have hypotheses, but no sure answers. 
Some of it likely involves design choices rather than language 
facilities per se, but even so, it's a good story for D.


--Jon

Re: CTFE Status 2

[Satoshi via Digitalmars-d]

Will be possible to make precompiled headers and distribute it 
with static library for example?

Re: The end of curl (in phobos)

[Seb via Digitalmars-d]

On Monday, 9 May 2016 at 10:44:13 UTC, ZombineDev wrote:

On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:

On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
But given that std.net.curl handles stuff like SSL/TLS, we 
_can't_ actually replace all of its functionality - at least 
not without adding a dependency on a different C library, 
since there's no way that it's sane to do the crypto stuff 
ourselves without a crypto expert, and even then, we should 
think twice about it. I could see implementing the SSL/TLS 
protocols themselves but not the crypto they use. If we 
replace std.net.curl, we likely should just provide the basic 
HTTP functionality, and leave the rest to a dub package that 
we move std.net.curl to.


Any chances that we can produce good crypto code over time? 
And verify it with experts, of course.


https://github.com/etcimon/botan AFAIK, it is already used in 
production by its author, in combination with libasync + vibe.d 
+ http2 for a full stack D solution.



So what's the consensus on this issue?
Can't we simply move std.net.curl and etc.c.curl to undead and 
just _not_ include it in Phobos?
Anyone reasonable will use requests [1], vibe.d's async 
requestHTTP [2] or their home-grown library anyways. As mentioned 
in another thread [3], Phobos is bloated with "old" modules that 
wouldn't have made it through today's review process.


With DUB's "new" single file feature and DUB being bundled in the 
DMD release process, any DUB library is just a header comment 
away.
Moreover we can configure the DUB package to automatically 
compile the curl sources, so that it won't create any troubles as 
e.g. the people on Windows or the gdc maintainers experience.


[1] https://github.com/ikod/dlang-requests
[2] vibed.org/api/vibe.http.client/requestHTTP
[3] 
http://forum.dlang.org/post/odbddahgxadkffbwc...@forum.dlang.org

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

Thanks for the very comprehensive response! I think most of my 
doubts are cleared now. You're right though that I'm probably 
worrying too much about GC with my current use case. Also thanks 
for the links - they should also come in very handy indeed.


I managed to find some book recommendations as well on the site. 
I've decided to start out with what appears to be the most 
approachable of them - Programming in D by Ceherli.


D doesn't have macros. D has templates like C++, string mixins 
(insert a statically >know/generated string as D code), and CTFE 
(Compile Time Function Evaluation, to >programmatically generate 
static stuff).


Ah, I see! Thanks for clarifying that although CTFE as you 
mentioned it seems to match my specific interest.


I look forward to learning D and being able to contribute some 
day! :-)


On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

[...]


There is a GC, but you can avoid the features that use it. 
There's a function attribute for that: @nogc [1]. It forbids 
GC-manages allocations. The GC is still there, but it won't do 
anything because you're not triggering it.


You can also turn automatic collections off (GC.disable [2]). 
There's no need for that when all your code is @nogc, though, 
because collections are triggered by allocations.


As for getting rid of the GC entirely (for saving space, I 
guess), I think that's more involved. May require changes to 
druntime. Shouldn't be necessary most of the time.



[...]


Yes. Whenever a std function returns a new string or some such 
it's going to be GC-allocated. There's an experimental module 
for custom allocators [3], but the rest of the library doesn't 
make use of it, yet. When a std function uses the GC, the 
compiler won't let you call it from @nogc code.



[...]


I don't think you're going to run into much trouble when making 
"grep-scale tools".


[...]

[...]


D doesn't have macros. D has templates like C++, string mixins 
(insert a statically know/generated string as D code), and CTFE 
(Compile Time Function Evaluation, to programmatically generate 
static stuff).



[...]


Can't answer this, because I'm not familiar enough with those 
languages.



[...]


Absolutely. Anyone is welcome to contribute. D is very much a 
volunteer effort. Also don't hesitate to point out (or even 
fix) any stumbling blocks you may encounter when starting out.


[1] https://dlang.org/spec/attribute.html#nogc
[2] https://dlang.org/phobos/core_memory.html#.GC.disable
[3] https://dlang.org/phobos/std_experimental_allocator.html
[4] http://ddili.org/ders/d.en/index.html
[5] https://tour.dlang.org/

Re: Hello, folks! Newbie to D, have some questions!

[ag0aep6g via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
2. I am more interested in learning D as a pure systems 
programming language so that I can develop my own tools (not 
looking to develop an OS, just some grep-scale tools to start 
off with). In that regard, I have a few concerns about the GC. 
My rudimentary knowledge of the D ecosystem tells me that there 
is a GC in D, but that can be turned off. Is this correct?


There is a GC, but you can avoid the features that use it. 
There's a function attribute for that: @nogc [1]. It forbids 
GC-manages allocations. The GC is still there, but it won't do 
anything because you're not triggering it.


You can also turn automatic collections off (GC.disable [2]). 
There's no need for that when all your code is @nogc, though, 
because collections are triggered by allocations.


As for getting rid of the GC entirely (for saving space, I 
guess), I think that's more involved. May require changes to 
druntime. Shouldn't be necessary most of the time.


Also, some threads online mention that if we do turn off GC, 
some of the core std libraries may not fully work. Is this 
presumption also correct?


Yes. Whenever a std function returns a new string or some such 
it's going to be GC-allocated. There's an experimental module for 
custom allocators [3], but the rest of the library doesn't make 
use of it, yet. When a std function uses the GC, the compiler 
won't let you call it from @nogc code.


In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine?


I don't think you're going to run into much trouble when making 
"grep-scale tools".


[...]
4. I have heard good reports of D's metaprogramming 
capabilities (ironically enough, primarily from a thread on the 
Rust user group), and coming from a Common Lisp (and some 
Racket) background, I am deeply interested in this aspect. Are 
D macros as powerful as Lisp macros?


D doesn't have macros. D has templates like C++, string mixins 
(insert a statically know/generated string as D code), and CTFE 
(Compile Time Function Evaluation, to programmatically generate 
static stuff).


Are they semantically similar (for instance, I found Rust's 
macros are quite similar to Racket's)?


Can't answer this, because I'm not familiar enough with those 
languages.


5. Supposing I devote the time and energy and get up to speed 
on D, would the core language team be welcoming if I feel like 
I can contribute?


Absolutely. Anyone is welcome to contribute. D is very much a 
volunteer effort. Also don't hesitate to point out (or even fix) 
any stumbling blocks you may encounter when starting out.


[1] https://dlang.org/spec/attribute.html#nogc
[2] https://dlang.org/phobos/core_memory.html#.GC.disable
[3] https://dlang.org/phobos/std_experimental_allocator.html
[4] http://ddili.org/ders/d.en/index.html
[5] https://tour.dlang.org/

Re: scope with if

[berni via Digitalmars-d-learn]

Just a note - I found something, that works:


import std.stdio;

void main(string[] args)
{
   immutable cond = args[1]=="a";
   if (cond) write("A");
   scope (exit) if (cond) write("B");

   write("C");
}


I'm using the immutable variable to avoid, that the condition 
changes later.

Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

Hello folks,

I am interested in learning D (just starting out, did a few of 
the exercises on the D tour), and had some questions before I 
decide to jump right in. My questions are genuinely motivated by 
my experiences and expectations, so please forgive me if some 
questions don't come across as well as my intentions!


1. I have some experience with both C and C++, and have been 
learning Rust for a while, but a few things put me off about the 
whole business -


a). The core language appears to be simple enough, but becomes 
increasingly complex as I begin writing larger programs.


b). The whole ownership system is easy to understand, but the 
APIs become very complicated and unwieldy, and more time appears 
to be spent on understanding and ensuring that memory is being 
used correctly than on the core program logic.


c). The whole community seems infused with both the Feminism/SJW 
(I don't care about those communities, but it feels weird having 
a programming community get sidetracked by all that bullshit), 
and too much of Ruby-on-Rails culture (probably started with 
Steve Klabnik) so that it doesn't feel like any real systems 
programmers are focusing on that language, and finally, d). The 
whole language feels like a bit of patchwork of random ideas, and 
also the whole "safety" and "no segfaults" guarantees seem to 
have lesser and lesser RoI as time goes by.


Sorry for the rant, I didn't realise I was quite that frustrated! 
That's just to give some background about me and my recent 
experiences! :D


In that regard, I suppose I'll get a better feel of the community 
here as I interact more, but I have high hopes that it'll be much 
more technical than purely social!


2. I am more interested in learning D as a pure systems 
programming language so that I can develop my own tools (not 
looking to develop an OS, just some grep-scale tools to start off 
with). In that regard, I have a few concerns about the GC. My 
rudimentary knowledge of the D ecosystem tells me that there is a 
GC in D, but that can be turned off. Is this correct? Also, some 
threads online mention that if we do turn off GC, some of the 
core std libraries may not fully work. Is this presumption also 
correct?


In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine? If you could 
share your experiences and domains of use, that would also be 
very helpful for me. Secondly, how stable is the language and how 
fast is the pace of development on D?


Again, sorry for my ignorance if I have been wrong-footed on some 
(or all) points.



2. I am also curious as to what would be the best path for a 
complete beginner to D to learn it effectively? I am a relatively 
fast learner (and I learn better by context, as in, some core 
unifying idea described and then elucidated through big examples 
instead of learning in bits and pieces). How did you folks learn 
D? I'm sure hearing your experiences would be helpful too. Are 
there any books/video tutorials that you would recommend (aside 
from this site itself).


3. Are there some small-scale Open Source projects that you would 
recommend to peruse to get a feel for and learn idiomatic D?


4. I have heard good reports of D's metaprogramming capabilities 
(ironically enough, primarily from a thread on the Rust user 
group), and coming from a Common Lisp (and some Racket) 
background, I am deeply interested in this aspect. Are D macros 
as powerful as Lisp macros? Are they semantically similar (for 
instance, I found Rust's macros are quite similar to Racket's)?


5. Supposing I devote the time and energy and get up to speed on 
D, would the core language team be welcoming if I feel like I can 
contribute?


That's all off the top of my head at the moment. Perhaps I'll 
have more questions as I read the responses. Thanks in advance!


Cheers.

Re: Converting multiple inheritance code into C ++ for D language

[biozic via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 19:05:14 UTC, Jean Cesar wrote:
This is exactly what I want this code I did to understand how 
would apply multiple inheritance in D, C # also process using 
interfaces but the difference from C # to D is that C # already 
in the base class you have to define it as interface. ..


OK, but I guess you are aware that in this code, using interfaces 
and the pseudo-multiple-inheritance is pointless! You could just 
ditch them and use regular methods :)

Re: Converting multiple inheritance code into C ++ for D language

[Jean Cesar via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 16:27:51 UTC, biozic wrote:

On Saturday, 18 February 2017 at 12:56:51 UTC, wiki wrote:

On Saturday, 18 February 2017 at 09:33:25 UTC, biozic wrote:
A mixin can be used to provide an base implementation for the 
methods of an interface, along with data members, so that you 
don't have to define it in every class that implements the 
interface.


An example : https://dpaste.dzfl.pl/b656851e5c51




I tried to use it in the same way but I did not understand 
correctly because to simulate, alias in this code I had 
already defined the classes as interfaces but I did not 
understand how these constructors should be declared for later 
use ..


There are multiple typos problems with your code. For me, the 
main problem would be that this code is using OOP the wrong 
way, but maybe this code doesn't represent what you actually 
want to do... Anyway, see a corrected version below.


import std.stdio;

class Test1
{
protected string _msg1;

this(string msg1)
{
_msg1 = msg1;
}
} // No semicolon

interface Test2
{
// Interfaces can't have data members

// This template could actually be out of the interface.
// I just put it here because it's more clear that it's 
related to Test2.

mixin template Impl()
{
protected string _msg2; // Data member is inside the 
template


// This function is not a constructor. Only the class 
implementing

// the interface will have one.
void thisTest2(string msg2)
{
_msg2 = msg2;
}
}
}

interface Test3
{
mixin template Impl()
{
protected string _msg3;
void thisTest3(string msg3)
{
_msg3 = msg3;
}
}
}

class Test4 : Test1, Test2, Test3
{
mixin Test2.Impl;
mixin Test3.Impl;

string _msg4;

this(string msg1, string msg2, string msg3, string msg4)
{
super(msg1);  // Calls the constructor of Test1
thisTest2(msg2); // Use interface Test2
thisTest3(msg3); // Use interface Test3
this._msg4 = msg4; // Test4 implementation
}

void show() // Don't use override here
{
writeln(_msg1, _msg2, _msg3, _msg4);
}
}

void main()
{
auto teste = new Test4("\n\tTeste1 ", "Teste2 ", "Teste3 ", 
"Teste4");

teste.show();
// No explicit return is required
}


This is exactly what I want this code I did to understand how 
would apply multiple inheritance in D, C # also process using 
interfaces but the difference from C # to D is that C # already 
in the base class you have to define it as interface. ..

[Issue 16673] improve cyclic module imports checker

[via Digitalmars-d-bugs]

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

--- Comment #6 from Martin Nowak  ---
Should be fairly easy with the new 2-step lookup process (SearchLocalsOnly,
SearchImportsOnly), just instrument all symbol searches in expression.d to tag
the current scope's func as usesImports, when only the SearchImportsOnly lookup
returns a symbol.
Furthermore CallExp's using such functions also need to tag their scope's
function to make it work transitively.

--

[Issue 16673] improve cyclic module imports checker

[via Digitalmars-d-bugs]

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

--- Comment #5 from Martin Nowak  ---
And obviously nested functions within the ctor.
This would turn all ctors in Higgs to standalone ctors. Data initialization is
the biggest use-case for ctors, so this would likely solve many cyclic module
issues.

--

Re: [OT] NNTP client and threading

[Vladimir Panteleev via Digitalmars-d]

On Friday, 17 February 2017 at 18:46:21 UTC, ketmar wrote:

Ali Çehreli wrote:

On 02/17/2017 09:52 AM, ketmar wrote:

that one didn't had "References:" set -- i forgot to append 
'em to

headers. this one should have 'em.

This one worked.
Ali


thank you. so mail readers aren't that smart after all. ;-)


Even in the presence of "In-Reply-To", "References" is still 
useful when different parties see different Message-IDs (e.g. due 
to mailing-list gateways). That way, replies (except top-level 
replies) will still at least be nested in the right thread 
instead of appearing as a new thread.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Seb via Digitalmars-d-announce]

On Friday, 17 February 2017 at 13:50:48 UTC, John Colvin wrote:
Might I suggest you change the output s to s 
with border: none; and max-height: 30em;
This would make them auto-grow to the right height to fit the 
content (with max-height for sanity). It does mean you lose 
manual resizability (unless you mess around in js to sort out 
the clash with max-height)), but that doesn't seem so important 
if it auto-resizes.


Excellent idea! As the same js is used for the runnable boxes on 
the dlang.org main page, I didn't want to touch the editor that 
much (initially). Anyway I submitted a PR that changes the output 
element to :


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

As imho the border doesn't look that bad and for the same reason 
as above I didn't remove the border. See a visual comparison here:


http://imgur.com/a/pElAu

Are you or others still in favor of removing the border?

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Seb via Digitalmars-d-announce]

On Friday, 17 February 2017 at 16:07:37 UTC, Nick Sabalausky 
(Abscissa) wrote:

1. This is pretty awesome.


Thanks a lot :)

2. Looks like someone forgot to set a foreground text color for 
the output even though the background is set to white. This 
makes the output text invisible for those using eye-friendly 
light-on-dark systems.


I am not sure I follow. Do you use a custom color scheme or 
plugin that sets the body background color to black?
What exactly would be the best way for you to resolve your 
problem?

Maybe you can even submit a PR yourself? - the CSS is here:

https://github.com/dlang/dlang.org/blob/master/css/style.css#L1611

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Seb via Digitalmars-d-announce]

On Friday, 17 February 2017 at 08:00:29 UTC, Jack Stouffer wrote:

On Friday, 17 February 2017 at 05:06:20 UTC, Seb wrote:
Short follow-up: this is now live for the released 
documentation pages. Enjoy!


Please make a post on Reddit!

I firmly believe that this puts D at the top of programming 
language docs. We should advertise!


Excellent idea!
AFAIK reddit doesn't like self posts that much.
Would someone be so kind to post this once the improvements are 
in?


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

(this PR disables the `assert` transformation for now and also 
changes the output to pre.

It will automatically be deployed once merged)

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Seb via Digitalmars-d-announce]

On Saturday, 18 February 2017 at 13:46:10 UTC, Sönke Ludwig wrote:

Am 18.02.2017 um 14:43 schrieb Sönke Ludwig:

Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky:

On 2/17/17 6:06 AM, Seb wrote:
On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei 
Alexandrescu wrote:
Following https://github.com/dlang/dlang.org/pull/1532, the 
new-style

docs now also allow editing and running examples. Start at
http://dlang.org/library-prerelease/ and go anywhere to 
check it out.




Broken on the first example I tried :(

http://dlang.org/library-prerelease/std/algorithm/searching/find.html

---
Dmitry Olshansky


The example got cut off two or three characters too early, 
compared with
the source unit test. I'll have to check if this is an issue 
with DDOX,

or with the JSON output.


Hm, okay, false alert. The characters are there in the page 
sources and get cut off by the JS that transforms the HTML.


Yeah the regex trick doesn't seem to work that well:

-> https://github.com/dlang/dlang.org/pull/1575 (disables the 
`assert` transformation for now and also changes the output to 
pre)

Re: Converting multiple inheritance code into C ++ for D language

[biozic via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 12:56:51 UTC, wiki wrote:

On Saturday, 18 February 2017 at 09:33:25 UTC, biozic wrote:
A mixin can be used to provide an base implementation for the 
methods of an interface, along with data members, so that you 
don't have to define it in every class that implements the 
interface.


An example : https://dpaste.dzfl.pl/b656851e5c51




I tried to use it in the same way but I did not understand 
correctly because to simulate, alias in this code I had already 
defined the classes as interfaces but I did not understand how 
these constructors should be declared for later use ..


There are multiple typos problems with your code. For me, the 
main problem would be that this code is using OOP the wrong way, 
but maybe this code doesn't represent what you actually want to 
do... Anyway, see a corrected version below.


import std.stdio;

class Test1
{
protected string _msg1;

this(string msg1)
{
_msg1 = msg1;
}
} // No semicolon

interface Test2
{
// Interfaces can't have data members

// This template could actually be out of the interface.
// I just put it here because it's more clear that it's 
related to Test2.

mixin template Impl()
{
protected string _msg2; // Data member is inside the 
template


// This function is not a constructor. Only the class 
implementing

// the interface will have one.
void thisTest2(string msg2)
{
_msg2 = msg2;
}
}
}

interface Test3
{
mixin template Impl()
{
protected string _msg3;
void thisTest3(string msg3)
{
_msg3 = msg3;
}
}
}

class Test4 : Test1, Test2, Test3
{
mixin Test2.Impl;
mixin Test3.Impl;

string _msg4;

this(string msg1, string msg2, string msg3, string msg4)
{
super(msg1);  // Calls the constructor of Test1
thisTest2(msg2); // Use interface Test2
thisTest3(msg3); // Use interface Test3
this._msg4 = msg4; // Test4 implementation
}

void show() // Don't use override here
{
writeln(_msg1, _msg2, _msg3, _msg4);
}
}

void main()
{
auto teste = new Test4("\n\tTeste1 ", "Teste2 ", "Teste3 ", 
"Teste4");

teste.show();
// No explicit return is required
}

tanya library 0.2.0

[Eugene Wissner via Digitalmars-d-announce]

It isn't really a release announce, maybe a pre-release.

tanya is a general purpose library, used mostly for networking by 
me. It is an attempt to develop an alternative memory model for 
D; 100% of the library are usable in @nogc code.


I previously announced that I want to merge my code with another 
project and that I would stop the development. But it didn't 
happen. I'm sorry that I wanted to abandon it. It won't happen 
anymore. I'll continue the development.


tanya contains an event loop, containers, an URL parsing routine 
and alternative TCP sockets implementation, multiple precision 
integer. The library is cross plattform, but not thread-safe yet.


The memory management is based on allocators. The allocators are 
one-way compatible with std.experimental.allocator, it means my 
allocators can be used with std.exeperimental.allocator but the 
std.experimental.allocator isn't usable with my lbirary (though 
it is pretty straightforward to write a wrapper for phobos 
allocators). tanya's allocators follow Bloomberg Allocator Model, 
see discussions on BDE Allocator Model for pro and contra.


And sorry once again for a long post...

What's new:
- Bug fixes and performance improvements in the main allocator: 
MmapPool.
- Container redesign: There is a new container, Vector (similar 
to std.container.array) with the support of ranges and all the 
cool stuff. I also started to experiment with the "move" 
semantics in D based on the D conf talk of Ali Çehreli. There are 
also a singly linked list, circular buffer and a queue. SList 
will get range support soon, and some time later the buffers.

- Bug fixes in the epoll event loop and a few new features.
- RefCounted: more similar to C++ shared_ptr than to phobos' 
RefCounted, but more primitive.


Future plans:
I still need a few more containers: UTF-8 string and a hash 
table. The string won't be the same as RCString. I'm thinking of 
a not templated string with UTF-8 support only (with a 
possibility to initialize it from a string, dstring and wstring).
Big integer bug fixing and optimization has a priority aswell for 
me.
I'm also planning to add streams but it won't happen very soon 
since it is a lot of work.


I plan to start a small blog in April based on the library 
(university project). It will be a SCGI-server, serving only 
static pages, behind Apache. It will be the first try-out :). 
From there I can move to a http-server.


The library is still under permanent development. I begin to care 
about the API stability and proper deprecations, but it isn't 
always possible.
I intend to make releases regularly, maybe all the 6 weeks and to 
prepare some new features for each of the releases.
The API docs for the latest version can be found on 
https://docs.caraus.io/tanya/
If you have questions, need some examples, let me know. I'll 
write something up and publish it somewhere.


https://github.com/caraus-ecms/tanya
http://code.dlang.org/packages/tanya
https://docs.caraus.io/tanya/

[Issue 17196] [Reg 2.074] isUnsigned!bool now true

[via Digitalmars-d-bugs]

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

--- Comment #1 from Martin Nowak  ---
I'd opt for a temporary phobos fix and a dmd deprecation/transition of
__traits(isUnsigned, bool).

--

Re: multi-dimensional arrays, not arrays of arrays

[XavierAP via Digitalmars-d-learn]

Nice, thanks! Will check it out

[Issue 17196] New: [Reg 2.074] isUnsigned!bool now true

[via Digitalmars-d-bugs]

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

  Issue ID: 17196
   Summary: [Reg 2.074] isUnsigned!bool now true
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import std.traits : isUnsigned;

void pack(T)(in T value) if (is(T == bool))
{
}

void pack(T)(in T value) if (isUnsigned!T)
{
}

void test()
{
pack(true);
}
CODE
dmd -c -o- bug.d

bug.d(13): Error: bug.pack called with argument types (bool) matches both:
bug.d(3): bug.pack!bool.pack(const(bool) value)
and:
bug.d(7): bug.pack!bool.pack(const(bool) value)


Caused by https://github.com/dlang/phobos/pull/5038, this breaks the
msgpack-d-0.9.6.

--

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Sönke Ludwig via Digitalmars-d-announce]

Am 18.02.2017 um 14:43 schrieb Sönke Ludwig:

Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky:

On 2/17/17 6:06 AM, Seb wrote:

On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote:

Following https://github.com/dlang/dlang.org/pull/1532, the new-style
docs now also allow editing and running examples. Start at
http://dlang.org/library-prerelease/ and go anywhere to check it out.



Broken on the first example I tried :(

http://dlang.org/library-prerelease/std/algorithm/searching/find.html

---
Dmitry Olshansky


The example got cut off two or three characters too early, compared with
the source unit test. I'll have to check if this is an issue with DDOX,
or with the JSON output.


Hm, okay, false alert. The characters are there in the page sources and 
get cut off by the JS that transforms the HTML.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky:

On 2/17/17 6:06 AM, Seb wrote:

On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote:

Following https://github.com/dlang/dlang.org/pull/1532, the new-style
docs now also allow editing and running examples. Start at
http://dlang.org/library-prerelease/ and go anywhere to check it out.



Broken on the first example I tried :(

http://dlang.org/library-prerelease/std/algorithm/searching/find.html

---
Dmitry Olshansky


The example got cut off two or three characters too early, compared with 
the source unit test. I'll have to check if this is an issue with DDOX, 
or with the JSON output.

Re: Converting multiple inheritance code into C ++ for D language

[wiki via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 09:33:25 UTC, biozic wrote:

On Friday, 17 February 2017 at 23:35:33 UTC, Jean Cesar wrote:
On Friday, 17 February 2017 at 23:31:41 UTC, Adam D. Ruppe 
wrote:

On Friday, 17 February 2017 at 23:11:25 UTC, Jean Cesar wrote:
so I changed the code to use interface but how would I do so 
I could use the constructor in the same way as such a C ++ 
code?


Interfaces + mixin templates give you something very similar 
to multiple inheritance. You can have named functions in the 
mixin templates that do the work of the constructor, then 
call them from the real constructor.



Yes I saw here that it uses interface to make multiple 
inheritance just like C#, but I did not understand what would 
this mixing?


A mixin can be used to provide an base implementation for the 
methods of an interface, along with data members, so that you 
don't have to define it in every class that implements the 
interface.


An example : https://dpaste.dzfl.pl/b656851e5c51




I tried to use it in the same way but I did not understand 
correctly because to simulate, alias in this code I had already 
defined the classes as interfaces but I did not understand how 
these constructors should be declared for later use ..


import std.stdio;
import std.string;

/**
* Source: Digital MArs D  
*
* Name: StringHerancaMulti.d  
*
* Concept Aplied: Herança Multipla usando Classe com 4 variáveis 
string   *
* Autor: Jean Zonta   
*

**/

class Test1
{
 protected string _msg1;

   this( string msg1 )
   {
 _msg1=msg1;
   }
};

interface Test2
{
   protected string _msg2;

 // Provide an overridable implementation
 mixin template Impl()
 {
   this( string msg2 )
   {
_msg2=msg2;
   }
 }
};

interface Test3
{
 protected string _msg3;

 // Provide an overridable implementation
 mixin template Impl()
 {
   this( string msg3 )
   {
_msg3=msg3;
   }
 }
};

class Test4: Test1, Test2, Test3
{
  mixin Test2.Impl;
  mixin Test3.Impl;

 string _msg4;

 this( string msg1, string msg2 , string msg3, string msg4 )
 {
  super(msg1,msg2,msg3);
  this._msg1 = msg1;
  this._msg2 = msg2;
  this._msg3 = msg3;
  this._msg4 = msg4;
 }

 override void show()
 {
  writeln(_msg1,_msg2,_msg3,_msg4);
 }
};

void main()
{
 Test4 teste = new Teste4("\n\tTeste1 ","Teste2 ","Teste3 
","Teste4");

 teste.show();
 return 0;
}

Re: multi-dimensional arrays, not arrays of arrays

[Ilya Yaroshenko via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 10:37:21 UTC, XavierAP wrote:
Does D provide anything like this? Otherwise, was this ever 
considered and were reasons found not to have it?


They are implemented as part of the Mir project. We call them 
ndslices.


https://github.com/libmir/mir-algorithm
Docs: http://docs.algorithm.dlang.io/

See also other Mir projects at https://github.com/libmir.

std.experimental.ndslice is a deprecated version of mir.ndslice. 
std.experimental.ndslice provides only numpy like tensors. 
mir.ndslice provides all kinds of tensors. Sparse tensors can be 
found at https://github.com/libmir/mir


Best,
Ilya

multi-dimensional arrays, not arrays of arrays

[XavierAP via Digitalmars-d-learn]

Does D provide anything like this? Otherwise, was this ever 
considered and were reasons found not to have it?


I mean at least in C# (not talking about C/C++ at all) you can 
declare two kind of multi-dimensional arrays: T[][][] or T[,,]. 
The first is the same as the D ones, array of arrays of... 
(except the order of the indices isn't inverted in C# type 
declarations IIRC); but the second provides contiguous, 
rectangular truly multi-dimensional arrays supposedly with one 
single level of indirection. (Of course static arrays don't exist 
in C# just dynamic but that's an apart issue.)


Is there a reason why this feature would not be really desirable 
or possible? Does it really exist and I missed it in Andrei's 
book? As a matter of fact he states in chapter 4.3:


«On the minus side, "tall and thin" arrays with many rows and few 
columns incur a large size overhead as there's one array to keep 
per column. [...] Jagged arrays may have problems with efciency 
of access and cache friendliness. Each element access requires 
two indirections [...] going column-wise through a jagged array 
is a cache miss bonanza.»


It would look that well implemented [,,] arrays would fill some 
application gaps, even though arrays of arrays (jagged in 
practice or not) are elsewhere useful as well of course. In the 
former cases I would think about defining my own struct wrapping 
a flat array with an n-dimensional api such as return _buff[i*m + 
j]... but generic in type and maybe also in dimension.


Again any special reason why this isn't already provided in the 
language? Either a generic struct/class like that, or something 
deeper in the language that allows using the [] operator as 
transparently as with any other arrays (as in C#).

Thanks for any input.

Re: Converting multiple inheritance code into C ++ for D language

[biozic via Digitalmars-d-learn]

On Friday, 17 February 2017 at 23:35:33 UTC, Jean Cesar wrote:
On Friday, 17 February 2017 at 23:31:41 UTC, Adam D. Ruppe 
wrote:

On Friday, 17 February 2017 at 23:11:25 UTC, Jean Cesar wrote:
so I changed the code to use interface but how would I do so 
I could use the constructor in the same way as such a C ++ 
code?


Interfaces + mixin templates give you something very similar 
to multiple inheritance. You can have named functions in the 
mixin templates that do the work of the constructor, then call 
them from the real constructor.



Yes I saw here that it uses interface to make multiple 
inheritance just like C#, but I did not understand what would 
this mixing?


A mixin can be used to provide an base implementation for the 
methods of an interface, along with data members, so that you 
don't have to define it in every class that implements the 
interface.


An example : https://dpaste.dzfl.pl/b656851e5c51

Re: Vibrant 2.0, major update

[Guillaume Piolat via Digitalmars-d-announce]

On Friday, 17 February 2017 at 20:45:53 UTC, Relja Ljubobratovic 
wrote:
On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat 
wrote:

It's the 10th update for this abstract shooter made in D.


This is the first time I've heard of this game. Downloaded the 
demo, and first impressions were mind blowing!


Gameplay seems very fluid and well calibrated. But, I've got to 
say - most awesome element of the gameplay is definitely the 
music! This might be the most impressive sound I've heard 
coming from my macbook since I've bought it! Truly drives the 
mood in the game. :)


I've gladly payed for the full version, and will spread the 
word of this game whenever I can.


Congrats, and thank you!


(On Friday, 17 February 2017 at 20:45:53 UTC, Relja Ljubobratovic 
wrote:
On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat 
wrote:

It's the 10th update for this abstract shooter made in D.


This is the first time I've heard of this game. Downloaded the 
demo, and first impressions were mind blowing!


Gameplay seems very fluid and well calibrated. But, I've got to 
say - most awesome element of the gameplay is definitely the 
music! This might be the most impressive sound I've heard 
coming from my macbook since I've bought it! Truly drives the 
mood in the game. :)


I've gladly payed for the full version, and will spread the 
word of this game whenever I can.


Congrats, and thank you!


It's a blessing to have some happy players :)

Music is obviously an integral part of the game, and apparently 
when Nelson did it (perhaps 10 years ago?) it was a live 
performance. I'll forward him your kind message.


(regular readers: sorry for the noise and promotion)