Re: Self-modifying code! The real kind!

[Swoorup Joshi via Digitalmars-d]

Self-modifying might be the answer to all sorts of performance 
problems due to branching. Only problem is security I guess. 
Don't they disable writes to code segment anyway?


On Wednesday, 5 April 2017 at 22:21:23 UTC, Jethro wrote:
I think it would be pretty novel to have the concept of self 
modifying code.


[...]

Re: What are we going to do about mobile?

[rikki cattermole via Digitalmars-d]

IMO there is two things that need to be done to get D for mobile:

1: ldc needs to natively target and distribute binaries for Android 
(MIPS, ARM, at least).
2: extern(JNI) seriously, its a pain to work with Java over JNI 
otherwise. It would be worse then not having extern(Obj-C).

What are we going to do about mobile?

[Joakim via Digitalmars-d]

I have been saying for some time now that mobile is going to go 
after the desktop next 
(http://forum.dlang.org/thread/rionbqmtrwyenmhmm...@forum.dlang.org), Samsung just announced it, for a flagship device that will ship tens of millions:


http://www.theverge.com/2017/3/29/15104600/samsung-dex-galaxy-s8-dock-announced-price-release-date
https://www.youtube.com/watch?v=QA31CaL_42A

That means this tidal wave of mobile swamping PCs is only going 
to get worse:


https://twitter.com/lukew/status/842397687420923904

D is currently built and optimized for that dying PC platform.  
There are only two devs working on mobile, Dan and me, I don't 
think anybody on the core team has even tried our work.


Even Microsoft has announced that they're taking another shot at 
ARM, ie Windows is coming to ARM again, this time with x86 
emulation for old Win32 apps:


http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm

I would even go so far as to say it may be worthwhile to develop 
an ARM backend for dmd.


What needs to be done?  Same as anything else, we need people to 
try it out and pitch in, like this guy who's now trying ldc out 
on an embedded device with an old ARMv5 core:


https://github.com/ldc-developers/ldc/issues/2058

I provide Android releases of ldc here:

https://github.com/joakim-noah/android/releases

We've been fixing Android/ARM regressions in the latest D 
releases here:


https://github.com/ldc-developers/ldc/issues/2024

More than anything else, we need the community to try building 
mobile libraries and apps, because compiler support is largely 
done.  We need to integrate mobile into our plans, rather than it 
just being a sideline.


There are two main possibilities for D usage on mobile right now:

- D libraries for faster code than the native languages
- full GUI apps written in D, likely cross-platform

The latter may seem far-fetched given D has not done that well in 
desktop GUI apps, but mobile is still a new market and D could do 
well.  D is uniquely well-suited to mobile, because it's nicer 
than Java or Obj-C while more efficient than the former, and it 
could make it easier to go cross-platform.


Vadim has done some nice work building DLangUI on Android, 
including a Tetris app that I spent half an hour playing on my 
phone:


http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org

I realize D is never going to have a polished devkit for mobile 
unless a company steps up and charges for that work.  But we can 
do a lot better than the complacency from the community we have 
now.

Re: Using the C preprocessor with D code

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 05, 2017 at 06:21:48PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/5/2017 1:50 PM, H. S. Teoh via Digitalmars-d wrote:
> > Who says you can't use a preprocessor with D code? ;-)
> 
> There are some issues with it. The C preprocessor is defined to work
> on "preprocessor tokens", which are not quite the same thing as text.

Well, yes, but since D syntax is sufficiently close to C, the difference
is immaterial. :-)

Mostly, anyway.  I can see the preprocessor getting confused by
D-specific syntax like token strings or `` literals, but for the most
part if the purpose is to expand C macros into D code snippets, this
mostly shouldn't matter.


T

-- 
Не дорог подарок, дорога любовь.

Re: Exceptions in @nogc code

[Andrei Alexandrescu via Digitalmars-d]

On 4/5/17 4:44 PM, deadalnix wrote:

On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu wrote:
As a matter of procedure no, a forum post will not be followed by a 
formal response. The DIP process ensures a formal response.


[...]
I encourage anyone interested in pursuing this idea to work on a DIP.


Thanks,

Andrei


To be blunt I played the DIP game in the past, never again.


Could you please point to the DIPs you have submitted? The only I know 
about is https://wiki.dlang.org/DIP27, which is of poor quality. You 
subsequently claimed you've invested significant work in it 
(https://forum.dlang.org/thread/hlckdmbpdlbjldcfw...@forum.dlang.org) 
although the history of the DIP 
(https://wiki.dlang.org/?title=DIP27=history) reveals only a few 
small edits.



This is very time consuming and nobody gives a shit.


Could you please watch the language. Thanks.

You two just do 
whatever the heck you want at the end of the day. I'm just pointing I 
predicted the problem you are running into with your brilliant approach 
years before you realized it is a problem. You can decide to not listen, 
not really my problem.


It is easy to frame any issue at hand as a manifestation of a larger 
problem.


I wrote fairly comprehensive specs of the idea in various places, 
including in the ML you created for this very topic. I just can't be 
writing specs again and again for them to be ignored, that's just not a 
productive use of my time, and at this point I'd even say it's not very 
respectful to ask people to waste more time.


I'm happy to work with you guy to come up with something, but I surely 
won't spend several days working a spec for nothing.


Thank you. If history is any indication, there is little to show after 
years of being around the community. The pattern seems to be a 
frustration that other people don't work on your ideas, which you can't 
convince yourself to spend time on. People tend to work on their own 
ideas, not others'. We don't have enough information to work on your 
vision, so absent that we work on our own.


To avoid being in a continuous state of frustration, you may want to 
take a risk and invest for real in your own ideas. They will have real 
impact if they are good.



Thanks,

Andrei

Re: Using the C preprocessor with D code

[Walter Bright via Digitalmars-d]

On 4/5/2017 1:50 PM, H. S. Teoh via Digitalmars-d wrote:

Who says you can't use a preprocessor with D code? ;-)


There are some issues with it. The C preprocessor is defined to work on 
"preprocessor tokens", which are not quite the same thing as text.

Re: Exceptions in @nogc code

[Walter Bright via Digitalmars-d]

On 4/5/2017 5:07 AM, deadalnix wrote:

You can do that, but that's 100% equivalent to:


   try { ... }
   catch (scope Exception e) { ... }


Unless you want to do something specific with the owned case ? You seems to be
under the impression that this does anything specific for catch/throw when it
doesn't.


Your original proposal listed 3 different kinds of catch, now it seems 
different. It's clear to me that this is more of an idea than a proposal - a lot 
more work needs to go into it.


For example, adding an `owned` type constructor is a major, major language 
change. Issues of implicit conversion, overloading, covariance, partial 
ordering, type deduction, mangling, construction, postblit, TypeInfo, inout, 
etc., all have to be addressed and worked out. Then there's legacy 
compatibility, deprecation issues, interaction with other languages, interaction 
with multiple storage allocators, etc.


The C# paper is 5 years old, and it has not been adopted by C# for unknown 
reasons. C# is a much more constrained language than D is, making it more 
practical for C#. It not being adopted by C# suggests problems with it - perhaps 
it doesn't deliver the promised results enough to justify its cost?


Making this work for D involves a great deal of careful design work, and even 
more implementation work. It also includes some significant risk that it will 
prove unworkable.


I don't believe that a back-and-forth disjointed email chain here is going to 
resolve the major issues with it. Until a far more thorough design proposal is 
made, I'm going to bow out.

Re: Updates to LDC snap package

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 5 April 2017 at 20:27:02 UTC, Joseph Rushton 
Wakeling wrote:
The package provides LDC 1.1.1 (based on the DMD 2.071.2 
frontend) and uses LLVM 3.9.1 as the backend.  It is expected 
to work on any distribution with a sufficiently up-to-date 
snapd package.  In practice this means at least:


  * Ubuntu 14.04, 16.04, 16.10 and 17.04

  * Debian Testing and Unstable

  * OpenSUSE Leap 42.2


More detailed installation instructions for different distros are 
available here:

https://snapcraft.io/docs/core/install

Self-modifying code! The real kind!

[Jethro via Digitalmars-d]

I think it would be pretty novel to have the concept of self 
modifying code.


I have several use cases in D where I have to repeat a process 
over and over such as compile, change some line, then recompile 
to get the effect.


The main one has to do with mixins.

//version = compiledMixins;

version(compiledMixins)
{
import fooMixedInFile;
} else
{
WriteFile(foo, fooMixedInFile);
ModFile(this, "//version = compiledMixins" => "version = 
compiledMixins");

}

This hypothetical code, when compiled behaves like this:


1. evaluates the code string represented by foo and writes it to 
the file fooMixinInFile(.d).


2. Modifies the current file and uncomments the version = 
compiled Mixins.


3. (hit compile again, or automate somehow)

4. imports fooMixedInFile instead.


What this does, instead of exposing the mixin(foo), is instead 
write the mixin to a file and imports that on next build so D can 
parse it and return errors properly.


This works well in practice except that WriteFile and ModFile 
actually have to be ran at runtime requiring step 3 to also 
include a "dummy" run, e.g.,


version(compiledMixins)
{
void main()
{
WriteFile(foo, fooMixedInFile);
ModFile(this, "//version = compiledMixins" => "version = 
compiledMixins");

}

} else {

}

Essentially this method allows debugging mixins as code with the 
only requirement that one build/dummy run.


The main problem is I create hacks to do it. It would be nice for 
a general purpose solution in a nice package. Many would benefit 
from being able to debug mixins as if they were code, which the 
process above allows. Not only that, which a little big of work, 
one could match the output of a mixin to the line of code that 
generated it to get an accurate way to find bugs in the mixin 
code vs it's output.


I am only talking about string mixins here, of course, and the 
import would have to be a valid way to run them(which possibly 
may not work for certain types of string mixins... but works in 
the majority of cases).


The self modifying code(The ModFile line) is interesting but 
probably requires a good D parser to be robust.


I have a feeling that the compiler could do the job internally 
much better and completely encapsulate all the work.


Essentially,

1. Evaluate the string mixin(doesn't actually insert it yet).
2. compute hash
3. match hash to mixin's file backing. If not matched or doesn't 
exist, write string to file.
4. import the file instead of the mixin code. (or, if you want, 
mixin(import(file) but one would need to fixup the the debugging 
a little)


This has 3 advantages: 1. Can be done completely by the compiler 
when it encounters a mixin statement and doesn't change anything 
for the user. 2. Allows both the string generating code to be 
debugged(compiler will catch those errors first) and the output 
of the mixin(caught on the second compile). 3. No recompilation 
required.


Thoughts?

Re: is char[] faster than string?

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

On Wed, Apr 05, 2017 at 09:58:16PM +, Inquie via Digitalmars-d-learn wrote:
> I have a lot of string concatenation to do and I'm wondering if char[]
> is faster? Does it simply extend the buffer or are new buffers created
> every time?
> 
> What I am looking for is something like StringBuilder in C#.

If you are doing lots of concatenation and produce a single big string
at the end, take a look at std.array.appender.

Though if you're concerned about performance, you really should run a
profiler. Last I heard, appender may not be that much faster than using
~=, but I could be wrong.  But when it comes to optimization, my advice
is, profile, profile, profile.  I came from a C/C++ background and used
to have all sorts of zany ideas about optimization, but eventually I
learned that 95% of the time my efforts were wasted because the real
bottleneck was somewhere else, usually in an unexpected place (that only
made sense in retrospect).  Always use a profiler before making
decisions on optimizations.  It will save you from a lot of headaches
and unwarranted optimizations that tend to make your code needlessly
convoluted.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and 
now it's killing me! -- Schoolboy

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #8 from Matthias Klumpp  ---
(In reply to greenify from comment #7)
> [...]
> You package `rdmd` as well, right?

No, there is nothing using it in Debian (and we already lack manpower for the
existing packages).

> Or is there a problem with using `rdmd`?

Yes, it doesn't support all command-line flags one would use with ldc, gdc or
dmd. Any wrapper is not an option.

--

Re: is char[] faster than string?

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

On Wednesday, 5 April 2017 at 21:58:16 UTC, Inquie wrote:
I have a lot of string concatenation to do and I'm wondering if 
char[] is faster?


No, they are the same.

Does it simply extend the buffer or are new buffers created 
every time?


Both will extend the buffer when the runtime can guarantee it is 
allowed to, which it quite often can. Details here: 
http://dlang.org/d-array-article.html



I recommend just trying it with ~= (avoid a ~ b though, a ~= b is 
better when possible) and see how it performs before getting too 
worried about it, the built in really isn't bad.

is char[] faster than string?

[Inquie via Digitalmars-d-learn]

I have a lot of string concatenation to do and I'm wondering if 
char[] is faster? Does it simply extend the buffer or are new 
buffers created every time?


What I am looking for is something like StringBuilder in C#.

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 05, 2017 at 08:08:32PM +, Yuxuan Shui via Digitalmars-d wrote:
> On Wednesday, 5 April 2017 at 16:06:39 UTC, H. S. Teoh wrote:
> > On Wed, Apr 05, 2017 at 11:20:28AM +, Yuxuan Shui via Digitalmars-d
> > wrote:
> > > [...]
> > 
> > Did you read the entire article?
> > 
> > There is an entire section dedicated to interleaving of CTFE and
> > templates.  And no, you still cannot run CTFE on the same part of
> > the AST that is being template-expanded. But you *can* run CTFE on a
> > subtree that has already been fully expanded.
> > 
> > And no, the forum post you linked to has nothing to do with CTFE.
> > The so-called "static foreach" is unrolled at AST expansion time,
> > and is not run through CTFE at all (unless later on you call the
> > expanded function at "compile-time"). And is() expressions are also
> > not CTFE, they are also evaluated at AST expansion time.
> > 
> > Read the entire article first. ;-)
> > 
> > 
> > T
> 
> I was talking about the use of R.front, R.drop in the template.

Yes, that's the interleaving I was talking about. In your code example,
R is an alias to something outside the template itself, so as long as
whatever it aliases can be "finalized" in its AST, it can be handed to
the CTFE engine for evaluation.  This is really just a more fancy
instance of the more common `enum X = f(Y);` idiom, but it's really the
same thing.  The compiler tries to use CTFE every time it sees a value
that's needed at "compile-time"; `enum` is the usual way to trigger
this, but a template expansion that depends on the value, as you have
here, is also where the same thing happens.

What you *cannot* have, though, is if R is in the process of being
AST-expanded.  E.g., if .front itself requires expandRange() in its
definition, then it won't work, because then the compiler can't finalize
the AST of .front and CTFE won't be able to run it.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum

Re: dlang.org SSL certs

[Ali Çehreli via Digitalmars-d]

Ping.

Ali

On 03/31/2017 11:33 AM, Ianis G. Vasilev wrote:

It's nice to see that all of the website's subdomains have SSL
certificates. However, I noticed an inconsistency:

dlang.org, forum.dlang.org, code.dlang.org, tour.dlang.org,
wiki.dlang.org all serve the same content over both http and https.

http://blog.dlang.org and https://blog.dlang.org, however, serve
completely different content. The https version seems to serve the same
page as https://digitalmars.com and, because the certificate is issued
for digitalmars.com, browsers complain about it being invalid. If this
is not intended behavior - maybe the same content should be served on
both ports? Or maybe the subdomain should be removed in favor of
https://dlang.org/blog?

Also, I don't want to start a flame war, but I think all the http
traffic need to be redirected to https. At least for the subdomains that
require user login.

Using the C preprocessor with D code

[H. S. Teoh via Digitalmars-d]

D doesn't have a preprocessor, and for good reason, as it can allow all
sorts of hard-to-find bugs and other issues that make code hard to
maintain / understand.

However, some time ago I found an occasion where it was useful to run D
code through a C preprocessor before handing it to the D compiler.  This
is in the context of a wrapper I wrote around libfreetype for one of my
projects.  It was easy enough to write declarations for Freetype
functions that I needed (I didn't intend for the wrapper to be
*complete*; just good enough for what I need), but when it came to
handling Freetype errors, I didn't want to manually type in error
definitions (which may change upon upgrading libfreetype).

Fortunately, Freetype itself comes with a flexible error-handling module
in the form of the header file fterrdef.h, in which errors are defined
as macros of the form FT_ERRORDEF_(name,code,msg) and
FT_NOERRORDEC_(name,code,msg). By suitably defining these two macros and
#include'ing the file, the user can generate useful things like tables
of error messages, switch statement blocks for handling translating
error codes, etc..

Of course, that's in the realm of C code, but since the C preprocessor
actually doesn't care what language it's processing (all it really cares
about is the #-directives, and on the side stripping C-style comments),
it's actually possible to do this *directly from D code*. So here's what
I did:

snip---
module font.freetype_errors;

alias FT_Error = int;

/* This sets up the macros for extracting the error definitions */
#define FT_ERRORDEF_(name,code,msg) \
enum FT_Err_ ## name = code;

#define FT_NOERRORDEF_(name,code,msg) \
enum FT_Err_ ## name = code;

/* This (evil!) magic does the actual emitting of the enum declaration 
*/
#include "freetype2/freetype/fterrdef.h"
#undef FT_ERRORDEF_
#undef FT_NOERRORDEF_

string toString(FT_Error err)
{
switch (err)
{
/* This sets up the macros for extracting the error messages */
#define FT_ERRORDEF_(name,code,msg) \
case FT_Err_ ## name:   \
return msg;

#define FT_NOERRORDEF_(name,code,msg) \
case FT_Err_ ## name:   \
return msg;
#include "freetype2/freetype/fterrdef.h"

default:
import std.conv : to;
return "Freetype error " ~ to!string(cast(int)err);
}
}
snip---

The D compiler, of course, can't compile this code, because it doesn't
understand the #-directives. But I *can* preprocess it explicitly by
running it through cpp and piping the output to an actual .d file that
will be imported by the rest of my code.  The preprocessor does the work
of actually expanding those error definitions into a D-style enum, as
well as generate the body of a nice function for converting FT_Error
into an error message defined by the libfreeetype sources.  Since this
is automatically done, I don't even have to change the code when
upgrading to a new version of libfreetype; any new error definitions
will automatically be created for me. :-)

Who says you can't use a preprocessor with D code? ;-)


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

Re: Proposal: Exceptions and @nogc

[deadalnix via Digitalmars-d]

On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
Much of Phobos has been redone to not assume/require the GC. A 
glaring exception (!) is when Exceptions are thrown, which is 
why we're looking for a solution.


Make the exception owned, and let the caller decide.

Re: Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu 
wrote:
As a matter of procedure no, a forum post will not be followed 
by a formal response. The DIP process ensures a formal response.


[...]
I encourage anyone interested in pursuing this idea to work on 
a DIP.



Thanks,

Andrei


To be blunt I played the DIP game in the past, never again.

This is very time consuming and nobody gives a shit. You two just 
do whatever the heck you want at the end of the day. I'm just 
pointing I predicted the problem you are running into with your 
brilliant approach years before you realized it is a problem. You 
can decide to not listen, not really my problem.


I wrote fairly comprehensive specs of the idea in various places, 
including in the ML you created for this very topic. I just can't 
be writing specs again and again for them to be ignored, that's 
just not a productive use of my time, and at this point I'd even 
say it's not very respectful to ask people to waste more time.


I'm happy to work with you guy to come up with something, but I 
surely won't spend several days working a spec for nothing.

Updates to LDC snap package

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all,

In the absence of any reports of problems with the current LDC 
snap package, I've released it to the stable release channel.  
This means that it should now be possible to install it with the 
command:


sudo snap install --classic ldc2

where the --classic flag is necessary in order to grant the 
access permissions the snap package needs to do its work.


Existing users wishing to ensure they will use this stable 
package release should refresh their installation:


sudo snap refresh --classic --stable ldc2

The package provides LDC 1.1.1 (based on the DMD 2.071.2 
frontend) and uses LLVM 3.9.1 as the backend.  It is expected to 
work on any distribution with a sufficiently up-to-date snapd 
package.  In practice this means at least:


  * Ubuntu 14.04, 16.04, 16.10 and 17.04

  * Debian Testing and Unstable

  * OpenSUSE Leap 42.2


-- Known issues ---

The package is not expected to work on Arch Linux for the time 
being due to some issues with the snapd package currently 
available.


Link-time optimization (i.e. the -flto flag) is expected to work 
only on Ubuntu 16.04, 16.10 and 17.04.  Since this is in any case 
an experimental feature, this partial support has been tolerated 
for the current release.



-- Upcoming development releases ---

With a stable package now available, the `edge` and `beta` 
release channels will soon be used to make releases related to 
the upcoming 1.2.0 release.  Some planned updates include:


  * supporting architectures other than amd64

  * upgrading LLVM to 4.0

The `edge` channel will publish every individual update to the 
development branch of the package.  Development packages will be 
upgraded to the `beta` channel once they have been shown to work 
on multiple distributions.  Once LDC 1.2.0 is officially 
released, the package will move towards the `candidate` and 
`stable` channels once more.


You can check which release channel your current install is 
tracking using the command


snap info ldc2

... and looking at the `tracking:` field.  You can switch which 
channel you are tracking by using the `snap refresh` command (see 
the beginning of this post) and choosing the channel using the 
corresponding flag: --stable, --candidate, --beta or --edge (in 
increasing order of instability:-)


For more information on snap package release channels, see: 
https://snapcraft.io/docs/reference/channels


Hope this package proves useful to people!

Best wishes,

-- Joe

Re: CTFE Status 2

[Yuxuan Shui via Digitalmars-d]

On Wednesday, 5 April 2017 at 16:06:39 UTC, H. S. Teoh wrote:
On Wed, Apr 05, 2017 at 11:20:28AM +, Yuxuan Shui via 
Digitalmars-d wrote:

[...]


Did you read the entire article?

There is an entire section dedicated to interleaving of CTFE 
and templates.  And no, you still cannot run CTFE on the same 
part of the AST that is being template-expanded. But you *can* 
run CTFE on a subtree that has already been fully expanded.


And no, the forum post you linked to has nothing to do with 
CTFE. The
so-called "static foreach" is unrolled at AST expansion time, 
and is not

run through CTFE at all (unless later on you call the expanded
function at "compile-time"). And is() expressions are also not 
CTFE,

they are also evaluated at AST expansion time.

Read the entire article first. ;-)


T


I was talking about the use of R.front, R.drop in the template.

Re: CTFE Status 2

[Dragos Carp via Digitalmars-d]

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
On Sat, Apr 01, 2017 at 05:06:14PM +, Inquie via 
Digitalmars-d wrote: [...]
How far off until newCTFE is usable to compile the majority of 
templates out there?


CTFE and templates are two separate things. You may want to 
read this (draft) article to get a better understanding of how 
they fit together:


https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T


Very nice and informative article! Thanks!

Still I miss some comments about mixins and template mixins.

[Issue 17296] EINTR awareness - posix system calls can be interrupted by posix signal

[via Digitalmars-d-bugs]

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

--- Comment #1 from Roman  ---
It turned out that the problem can appear even if user does not do signal
handling himself. It's enough to just do multithreading, so signals used by GC
can interrupt syscall in other thread.

Whether the hack is applied or not, the behavior of functions will need to be
documented. If hack is applied, it should say about possible looping, if it's
not applied it should say that interruption is considered error for these
functions.

There's also updated version of the hack:

template deintr(alias func) 
if (isFunction!func && isIntegral!(ReturnType!func) && 
isSigned!(ReturnType!func) && functionLinkage!func == "C")
{
ReturnType!func deintr(Args...)(Parameters!func args, Args varArgs)
{
ReturnType!func result;
do 
{
result = func(args, varArgs);
}
while(result == -1 && .errno == EINTR);
return result;
}
}

--

Re: cmake-d and gdc/gdmd compiler

[timvol via Digitalmars-d-learn]

On Tuesday, 4 April 2017 at 19:59:19 UTC, Dragos Carp wrote:

On Tuesday, 4 April 2017 at 18:42:45 UTC, timvol wrote:

Hi guys,

I'm trying to cross-compile a project using CMake and gdc (or 
better: the gdmd port). My CMakeLists-file is the following:




For cross-compiling, CMake uses a so called "toolchain" file 
[1] where you define the system paths similar to the target 
system.


I confess that never cross-compiled any code with cmake-d, but 
in principle it should work.


Dragos

[1] 
https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-linux


Alright. Thank you Dragos. I thought it's possible without using 
a toolchain file but I'll give it a try :)

Re: Exceptions in @nogc code

[Mike Parker via Digitalmars-d]

On Wednesday, 5 April 2017 at 17:08:55 UTC, Meta wrote:

My point is that I completely understand why someone would not 
want to bother going through the DIP process.


1. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


FYI, Dicebot has been helping me get acquainted with the process 
and pointed out that 1003 is ready for a formal review. I'll be 
moving on it soon.

Re: Proposal: Exceptions and @nogc

[Jack Stouffer via Digitalmars-d]

On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat 
wrote:

But those of us with the runtime disabled don't have TLS.
throwing, .destroy, TLS (and static this) are the fragmenting 
factors between runtime-free and D normal D.


I'm going to be harsh here and say that the D team members should 
focus on it's users who are using druntime + Phobos and allow 
people to use their own runtime if they wish. Then for the most 
part, ignore everyone else. We cannot afford to make concessions 
to a small handful of our userbase with our limited dev time.


Suggested party line: if you don't want to use druntime, best of 
luck, you're on your own. We're not going to gimp Phobos for you.

Re: Exceptions in @nogc code

[Meta via Digitalmars-d]

On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu 
wrote:

On 4/4/17 12:26 AM, Nick B wrote:
Can one assume that Walter is thinking about deadalnix's 
detailed proposal above, and that he will give a formal 
response, once he has given it serious thought, and discussed 
it with Andrei ?


As a matter of procedure no, a forum post will not be followed 
by a formal response. The DIP process ensures a formal response.


The post is far from what one would call a proposal, let alone 
a detailed one. It is a sketch of an idea that addresses a 
complex matter without minding a large number of details. 
That's totally fine; the whole discussion opener was also 
informal and lacking details. It's just that we can't work on 
someone else's vague idea.


I encourage anyone interested in pursuing this idea to work on 
a DIP.



Thanks,

Andrei


In fairness, the DIP process is painfully slow (which I can 
suppose can be seen as either a good thing or a bad thing). 
DIP1003[0] has yet to be commented on, despite it being a simple 
and easily understandable change. Yes, during that time Dicebot 
quit as DIP manager, but when he quit this DIP was already over 
the deadline for comment by a couple weeks.


I went in not expecting a lot in terms of promptness and with the 
understanding that it was such a trivial and low-priority change 
that a prompt result was not really necessary (and thus I was 
willing to wait patiently), and yet I admit that in spite of all 
my goodwill I was frustrated by the lack of response after over 2 
months.


My point is that I completely understand why someone would not 
want to bother going through the DIP process.


1. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

Re: Proposal: Exceptions and @nogc

[David Nadlinger via Digitalmars-d]

On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat 
wrote:
This means TLS is here but uninitialized and eg. core.cpuid has 
to be duplicated.

Fragmentation ensues.


You can still lazily initialise TLS data, though. — David

Re: shared: Has anyone used it without a lot of pain?

[via Digitalmars-d]

On Tuesday, 4 April 2017 at 21:56:37 UTC, Atila Neves wrote:
I feel dirty if I write `__gshared`. I sneeze when I read it. 
But everytime I try and use `shared` I get trouble for it.


TIL that if I want a struct to be both `shared` and not, 
destructors are out of the way. Because while constructors are 
easy because we can have more than one:


struct Foo {
this(this T)() { }
}

auto f1 = const Foo();
auto f2 = shared Foo();

There can be only one destructor:


struct Bar {
this(this T)() { }
~this() {} // no shared, if there was the problem would 
reverse

// ~this(this T)() {} isn't a thing
}

auto b1 = const Bar();
// Error: non-shared method foo.Bar.~this is not callable using 
a shared object

// auto b2 = shared Bar(); //oops

The reason why what I was trying to do isn't possible is 
obvious in hindsight, but it's still annoying. So either code 
duplication or mixins, huh?


Atila


The error message pretty much tells you that multiple threads 
should not be allowed to call the destructor concurrently, i.e. 
you should somehow guarantee that by the end of the scope only 
one thread has access to the object, which is what should happen 
in most multi-threaded programs.


A workable, but non the less dirty way of sharing RAII objects 
would be something along the lines:


struct Widget
{
this()  { /* ... */ }

void doWork() scope shared { /* ... */ }

~this() { /* ... */ }
}

Owner thread A
{
  /* 0) Make a new widget w/ automatic
 storage (RAII). Note: calling
 non-shared constructor since
 construction is a one thread endeavor
 anyway and we need non-shared `this`
 to call the destructor. */
  auto w = Widget();

  /* 1) share `w` with other threads
 and perform some useful work... */

  // Other thread B
  (ref scope shared(Widget) w) @safe
  {
ssw.doWork();
  }

  /* 2) Ensure that A is now the only
 thread with reference to `w`.   */

  /* 3) w.~this() called automatically.
 Safe, since thread A is only
 one with reference to w.*/
}

2) can be achieved only if you pass `scope` references to `w` in 
1), so that non of the other threads would be able to store a 
pointer to `w` in a variable with longer lifetime.
You also need to have a way of ensuring that the other threads 
have shorter lifetime than `w` (i.e. simple fork-join 
parallelism), or you need some sort of task infrastructure that 
allows you to block thread A until thread B finishes working on 
the task created in 1) and ensuring no references have escaped in 
thread B.


The other approach is to not use RAII at all, but instead to use 
an Arc (atomic reference counting) wrapper that @trusted-ly knows 
to cast the 'shared' qualifier off Widget when the ref count 
drops to zero in order to call the destructor.


// create a non-shared Widget and transfer
// the ownership to the Arc wrapper which
// makes the object `shared` with the world.
auto arcW = Arc!(shared W)(new W());

// auto w = new W();
// auto arcFromNonUniqueW = Arc!(shared W)(w); <- doesn't compile

void use1(ref shared(W) w) @safe;
// arcW.get().use1(); // Doesn't compile:
// Error: reference to local variable arcW assigned to non-scope 
parameter w calling arc_test.use1


void use2(ref scope shared(W) w) @safe;
arcW.get().use2(); // OK

Re: Proposal: Exceptions and @nogc

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 5 April 2017 at 16:08:33 UTC, David Nadlinger wrote:
On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat 
wrote:

But those of us with the runtime disabled don't have TLS.


This is only true on DMD/OS X x86, where TLS is emulated in 
druntime. On other platforms, TLS is implemented by the linker 
and/or C runtime, so it works without druntime just fine.




TIL, thanks.

Regular thread-local module constructors (static this) of 
course won't work without druntime support, as they are 
mediated through ModuleInfo.


 — David


Sure.
This means TLS is here but uninitialized and eg. core.cpuid has 
to be duplicated.

Fragmentation ensues.

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 05, 2017 at 11:20:28AM +, Yuxuan Shui via Digitalmars-d wrote:
> On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> > On Sat, Apr 01, 2017 at 05:06:14PM +, Inquie via Digitalmars-d
> > wrote: [...]
> > > How far off until newCTFE is usable to compile the majority of
> > > templates out there?
> > 
> > CTFE and templates are two separate things. You may want to read
> > this (draft) article to get a better understanding of how they fit
> > together:
> > 
> > https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
> > 
> > 
> > T
> 
> CTFE and template expansion might be more tangled than you thought.
> 
> For example, you do have access to CTFE during template expansion:
> http://forum.dlang.org/thread/yaekhryalyxyooaiu...@forum.dlang.org

Did you read the entire article?

There is an entire section dedicated to interleaving of CTFE and
templates.  And no, you still cannot run CTFE on the same part of the
AST that is being template-expanded. But you *can* run CTFE on a subtree
that has already been fully expanded.

And no, the forum post you linked to has nothing to do with CTFE. The
so-called "static foreach" is unrolled at AST expansion time, and is not
run through CTFE at all (unless later on you call the expanded
function at "compile-time"). And is() expressions are also not CTFE,
they are also evaluated at AST expansion time.

Read the entire article first. ;-)


T

-- 
Guns don't kill people. Bullets do.

Re: Proposal: Exceptions and @nogc

[David Nadlinger via Digitalmars-d]

On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat 
wrote:

But those of us with the runtime disabled don't have TLS.


This is only true on DMD/OS X x86, where TLS is emulated in 
druntime. On other platforms, TLS is implemented by the linker 
and/or C runtime, so it works without druntime just fine.


Regular thread-local module constructors (static this) of course 
won't work without druntime support, as they are mediated through 
ModuleInfo.


 — David

Re: Proposal: Exceptions and @nogc

[Guillaume Piolat via Digitalmars-d]

On Monday, 3 April 2017 at 22:30:46 UTC, Walter Bright wrote:


Using a singleton in TLS is indeed memory safe, as long as you 
don't do things like keep a reference to it around and expect 
it not to change.


But those of us with the runtime disabled don't have TLS.
throwing, .destroy, TLS (and static this) are the fragmenting 
factors between runtime-free and D normal D.

Re: Proposal: Exceptions and @nogc

[Jack Stouffer via Digitalmars-d]

On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
Much of Phobos has been redone to not assume/require the GC. A 
glaring exception (!) is when Exceptions are thrown, which is 
why we're looking for a solution.


Much, but not most. Dynamic arrays, AAs, closures, and all 
classes are still heavily used in Phobos. More than half of all 
the modules in Phobos rely on GC.


Again: making throwing exceptions @nogc WILL make a small number 
of the overall currently allocating functions @nogc. It will NOT 
make the majority of Phobos @nogc and it doesn't come close to 
the main problem already stated in my other comments.


You're adding in a confusing special case for a small piece of 
the overall whole and missing the forrest for the trees.

Re: shared: Has anyone used it without a lot of pain?

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 5 April 2017 at 13:18:26 UTC, Andrea Fontana wrote:

On Tuesday, 4 April 2017 at 21:56:37 UTC, Atila Neves wrote:
I feel dirty if I write `__gshared`. I sneeze when I read it. 
But everytime I try and use `shared` I get trouble for it.

[...]
Atila


https://p0nce.github.io/d-idioms/#The-truth-about-shared


Do we have a missed opportunity with shared?

My pet peeve with shared is the RoI.
You were supposed to use it whenever something is "shared across 
threads". My problem with it is with the RoI of putting entire 
object graphs under that type constructor.


For now it seems shared!T is about being a monadic hatch for the 
adventurous, one you can bring your own meaning for.

Re: Single exe vibe.d app

[Inquie via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 12:42:23 UTC, evilrat wrote:

On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote:

Hi,
How can I build single exe application with vibe.d (windows)?
now it require zlib.dll, libeay32.dll and ssleay32.dll

But I need it as single app.


btw, if all you need is to ship it as a single file and don't 
care if it writes anything, you can probably compile-in those 
.dll's to your .exe as string with D import statement and write 
them on disk from static module ctor (static shared this{} at 
module scope) when it launched.


Why is the writing to disk necessary? Seems like a costly step 
for no real benefit. The dll gets read in to memory anyways.


https://github.com/fancycode/MemoryModule

Re: shared: Has anyone used it without a lot of pain?

[Andrea Fontana via Digitalmars-d]

On Tuesday, 4 April 2017 at 21:56:37 UTC, Atila Neves wrote:
I feel dirty if I write `__gshared`. I sneeze when I read it. 
But everytime I try and use `shared` I get trouble for it.

[...]
Atila


https://p0nce.github.io/d-idioms/#The-truth-about-shared

Re: Single exe vibe.d app

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote:

Hi,
How can I build single exe application with vibe.d (windows)?
now it require zlib.dll, libeay32.dll and ssleay32.dll

But I need it as single app.


As Evilrat notes static libraries are one solution, the catch 
being you need to get them as static libraries. zlib you should 
easily be able to get as a static lib (making sure you use a 
compatible linker/ linker format.


If for the other libraries that is not possible one approach is 
described on the d idioms list: 
http://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable


The static library solution is probably the superior choice if 
available.

Re: Single exe vibe.d app

[evilrat via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote:

Hi,
How can I build single exe application with vibe.d (windows)?
now it require zlib.dll, libeay32.dll and ssleay32.dll

But I need it as single app.


btw, if all you need is to ship it as a single file and don't 
care if it writes anything, you can probably compile-in those 
.dll's to your .exe as string with D import statement and write 
them on disk from static module ctor (static shared this{} at 
module scope) when it launched.

Re: Covert a complex C header to D

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 12:27:23 UTC, biocyberman wrote:

On Monday, 3 April 2017 at 23:10:49 UTC, Stefan Koch wrote:

On Monday, 3 April 2017 at 11:18:21 UTC, Nicholas Wilson wrote:
   prefer template over string mixins where possible. This 
will make the code much more readable.


My advise would be the opposite.
templates put much more pressure on the compiler then 
string-mixins do.

Also the code that templates expand to is hard to get.
Whereas the code that string mixins expand to can always be 
printed one way or another.


Could you elaborate more about this (i.e. show where mixins is 
more readable, debugable and less stressful to the compiler)  ? 
This kind of information is good for tuning stage later. My 
goal now is to finish the conversion and running of the header 
and the test code 
(https://github.com/attractivechaos/klib/blob/master/test/khash_test.c).


@Ali:
I noticed the -E option recently but haven't really used it. I 
now generated the pre-processed source and try to make use of 
it.


While Stefan correctly notes that templates are slower than 
string mixins I generally find templates easier to read.

In terms of debugability:
you can pragma(msg, myGeneratedString) to see the generated code;
the error messages you get from templates are slightly more 
difficult to read than normal error messages in that you have to 
figure out what the significance of a particular parameter is (is 
it missing a method or operator? is it a struct instead of a 
class?), properly constraining the templates helps with this 
although the compiler is usually pretty good.

Re: pyd: implementing __hash__ and __str__ for PyD wrapped classes

[harfel via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 11:39:47 UTC, Nicholas Wilson wrote:

On Wednesday, 5 April 2017 at 09:31:09 UTC, harfel wrote:

Dear all,

[...]

Following the documentation and code examples, I got the basic 
functionality working. However, I am struggling with 
implementing the magic functions __str__ and __hash__ of the 
extension class. >> Is there a way to declare these slots in 
PyD? I noticed that Repr does this for __repr__ and the 
operator overloads do this of course for their respective 
slots, but I could not find anything for __hash__ and __str__.


[...]


I haven't chased the source but most likely __hash__ and 
__str__ will be "magically" generated from toHash() and 
toString() respectively (both methods of Object, 
see:https://dlang.org/phobos/object.html#.Object).


Unfortunately, this does not seem to be the case, as my D classes 
do override
toHash and toString, but they are not called by the corresponding 
python classes.

Re: shared: Has anyone used it without a lot of pain?

[Dukc via Digitalmars-d]

On Tuesday, 4 April 2017 at 21:56:37 UTC, Atila Neves wrote:
The reason why what I was trying to do isn't possible is 
obvious in hindsight, but it's still annoying. So either code 
duplication or mixins, huh?


template flag parameter for the struct for being shared or not? I 
may well be missing something. But in hindsight it could work.


Of course, you would still have to type the shared flag 
explicitly when instantiating which is less than desirable.

Re: Covert a complex C header to D

[biocyberman via Digitalmars-d-learn]

On Monday, 3 April 2017 at 23:10:49 UTC, Stefan Koch wrote:

On Monday, 3 April 2017 at 11:18:21 UTC, Nicholas Wilson wrote:
   prefer template over string mixins where possible. This 
will make the code much more readable.


My advise would be the opposite.
templates put much more pressure on the compiler then 
string-mixins do.

Also the code that templates expand to is hard to get.
Whereas the code that string mixins expand to can always be 
printed one way or another.


Could you elaborate more about this (i.e. show where mixins is 
more readable, debugable and less stressful to the compiler)  ? 
This kind of information is good for tuning stage later. My goal 
now is to finish the conversion and running of the header and the 
test code 
(https://github.com/attractivechaos/klib/blob/master/test/khash_test.c).


@Ali:
I noticed the -E option recently but haven't really used it. I 
now generated the pre-processed source and try to make use of it.

Re: Single exe vibe.d app

[evilrat via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote:

Hi,
How can I build single exe application with vibe.d (windows)?
now it require zlib.dll, libeay32.dll and ssleay32.dll

But I need it as single app.


you have to build those as static libraries first, compile vibe.d 
with that static libs provided to linker(you are most likely will 
be forced to x64 or m32mscoff depending on compilers used) and 
that *should* be enough.


but there may arise some non obviuos issues such as 
licensing(some licenses prohibits even linking with some other 
licenced code) or linking issues, or full disability to do so if 
dynamic loading is used, or whatever i forgot to remember.


sorry if it lacks details. thats just whole process in common.

Re: Exceptions in @nogc code

[Andrei Alexandrescu via Digitalmars-d]

On 4/4/17 12:26 AM, Nick B wrote:
Can one assume that Walter is thinking about deadalnix's detailed 
proposal above, and that he will give a formal response, once he has 
given it serious thought, and discussed it with Andrei ?


As a matter of procedure no, a forum post will not be followed by a 
formal response. The DIP process ensures a formal response.


The post is far from what one would call a proposal, let alone a 
detailed one. It is a sketch of an idea that addresses a complex matter 
without minding a large number of details. That's totally fine; the 
whole discussion opener was also informal and lacking details. It's just 
that we can't work on someone else's vague idea.


I encourage anyone interested in pursuing this idea to work on a DIP.


Thanks,

Andrei

Single exe vibe.d app

[Satoshi via Digitalmars-d-learn]

Hi,
How can I build single exe application with vibe.d (windows)?
now it require zlib.dll, libeay32.dll and ssleay32.dll

But I need it as single app.

Re: Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Wednesday, 5 April 2017 at 09:48:47 UTC, Walter Bright wrote:

   try { ... }
   catch (owned Exception e) { ... }
   catch (scope Exception e) { ... }
   catch (Exception e) { ... }

It not look enticing.


You can do that, but that's 100% equivalent to:


   try { ... }
   catch (scope Exception e) { ... }


Unless you want to do something specific with the owned case ? 
You seems to be under the impression that this does anything 
specific for catch/throw when it doesn't.


Today, you can do

try { ... }
catch(immutable(Exception) e) { ... }

There is nothing different here.

Re: DConf 2017 lightning talks - how to apply?

[Andrei Alexandrescu via Digitalmars-d]

On 4/4/17 3:48 AM, Atila Neves wrote:
Last year I missed the boat and ended up writing mine an hour before 
presenting it!


Atila


Please email to foundat...@dlang.org. Thanks! -- Andrei

[Issue 17298] Wrong deprecation warnings about derived class accessing private method

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

Summary|Templates cause wrong   |Wrong deprecation warnings
   |deprecation warnings about  |about derived class
   |derived class accessing |accessing private method
   |private method  |

--

Re: pyd: implementing __hash__ and __str__ for PyD wrapped classes

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 09:31:09 UTC, harfel wrote:

Dear all,

Relatively new to D in general and PyD in particular, I am 
trying to wrap some D classes I wrote for use in Python.


Following the documentation and code examples, I got the basic 
functionality working. However, I am struggling with 
implementing the magic functions __str__ and __hash__ of the 
extension class. My current approach was to implement them as 
ordinary member functions:



extern(C) void PydMain() {
module_init();

// Reaction
wrap_class!(PyReaction,
PyName!"Reaction",
Init!(MultiSet, MultiSet),
Property!(PyReaction.reactants),
Property!(PyReaction.products),
Repr!(PyReaction.repr),
Def!(PyReaction.py_str, PyName!"__str__"),   // XXX needs slot
Def!(PyReaction.py_hash, PyName!"__hash__"), // XXX needs slot
)();
}

but this does not work. In Python:

Python 2.7.12+ (default, Sep 17 2016, 12:08:02)
[GCC 6.2.0 20160914] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.

from teest_module import *
r=Reaction({'a':1, 'b':1}, {'ab':1})
r.__hash__
0x7fc1c7f4a080>

r.__hash__()

1430289695L

hash(r)

8779391257096

According to related post for C++/SWIG 
(http://stackoverflow.com/questions/25199233/str-not-called-when-printing-c-class-wrapped-for-python-with-swig), the reason is that these magic methods need to be implemented as slots, rather than ordinary member functions.


Is there a way to declare these slots in PyD? I noticed that 
Repr does this for __repr__ and the operator overloads do this 
of course for their respective slots, but I could not find 
anything for __hash__ and __str__.


Any ideas?

Thanks!


I haven't chased the source but most likely __hash__ and __str__ 
will be "magically" generated from toHash() and toString() 
respectively (both methods of Object, 
see:https://dlang.org/phobos/object.html#.Object).

[Issue 17298] Templates cause wrong deprecation warnings about derived class accessing private method

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
The test case doesn't need templates.

a.d:

import b: Derived;

class Base
{
private void func() {}
}

void foo() { new Derived().func(); }


b.d:

import a: Base;
class Derived : Base {}


`dmd -c a b`:

a.d(8): Deprecation: a.Base.func is not visible from class Derived


--

Re: CTFE Status 2

[Yuxuan Shui via Digitalmars-d]

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
On Sat, Apr 01, 2017 at 05:06:14PM +, Inquie via 
Digitalmars-d wrote: [...]
How far off until newCTFE is usable to compile the majority of 
templates out there?


CTFE and templates are two separate things. You may want to 
read this (draft) article to get a better understanding of how 
they fit together:


https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T


CTFE and template expansion might be more tangled than you 
thought.


For example, you do have access to CTFE during template 
expansion: 
http://forum.dlang.org/thread/yaekhryalyxyooaiu...@forum.dlang.org

[Issue 17298] New: Templates cause wrong deprecation warnings about derived class accessing private method

[via Digitalmars-d-bugs]

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

  Issue ID: 17298
   Summary: Templates cause wrong deprecation warnings about
derived class accessing private method
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: maxim...@gmail.com

Test code:

a.d:
--
module a;

class Base
{
private void func() {}
}

void foo(T)() { new T().func(); }  // line 8

struct Wrap(T)
{
void boo() { new T().func(); }  // line 12
}

class Cover(T)
{
void boo() { new T().func(); }  // line 17
}
--

b.d:
--
import a;

class Derived : Base {}

void main()
{
foo!Base();// OK
foo!Derived(); // Deprecation warning

alias A = Wrap!Base;// OK
alias B = Wrap!Derived; // Deprecation warning

alias C = Cover!Base;// OK
alias D = Cover!Derived; // Deprecation warning
}
--

dmd a b
--
a.d(8): Deprecation: a.Base.func is not visible from class Derived
a.d(12): Deprecation: a.Base.func is not visible from class Derived
a.d(17): Deprecation: a.Base.func is not visible from class Derived
--

--

Re: CTFE Status 2

[data pulverizer via Digitalmars-d]

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
On Sat, Apr 01, 2017 at 05:06:14PM +, Inquie via 
Digitalmars-d wrote: [...]
How far off until newCTFE is usable to compile the majority of 
templates out there?


CTFE and templates are two separate things. You may want to 
read this (draft) article to get a better understanding of how 
they fit together:


https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T


Just read your draft article, very illuminating. Thank you. There 
was a section "Interleaved AST manipulation and CTFE" which you 
mention is "one of the keystones of meta-programming in D". I 
think there should be a separate article on this topic as a way 
of popularising D's idioms. When can we expect this? :-)

Re: Proposal: Exceptions and @nogc

[Walter Bright via Digitalmars-d]

Much of Phobos has been redone to not assume/require the GC. A glaring exception 
(!) is when Exceptions are thrown, which is why we're looking for a solution.

Re: Exceptions in @nogc code

[Walter Bright via Digitalmars-d]

On 4/4/2017 8:13 AM, deadalnix wrote:

Then just do:
auto ePtr = malloc(...);
auto e = *(cast(Exception*) );
throw e;

Problem solved, you did not used the GC.


Your proposal also seems to require that all allocations are done with the GC 
(otherwise, how can things be "transferred" to the GC?). How can various 
destroyers know which allocator was used with each object? (One could add a 
pointer to the allocator to all class objects.)


Does this preclude allocating on the stack, using malloc, using custom 
allocators, etc.?


> If the catch is owned, then the ownership of the Exception is transferred to 
the catch block. It is then either transferred back to the runtime in case of 
rethrow, or consumed/destroyed depending on what the catch block is doing with it.


What happens if the:

   catch (owned Exception e)

is faced with an Exception that is not owned? Does it not catch it at all? If 
so, doesn't that imply that for practical purposes all thrown Exceptions need to 
be owned? Or should there be overloading of catch blocks:


   try { ... }
   catch (owned Exception e) { ... }
   catch (scope Exception e) { ... }
   catch (Exception e) { ... }

It not look enticing.

pyd: implementing __hash__ and __str__ for PyD wrapped classes

[harfel via Digitalmars-d-learn]

Dear all,

Relatively new to D in general and PyD in particular, I am trying 
to wrap some D classes I wrote for use in Python.


Following the documentation and code examples, I got the basic 
functionality working. However, I am struggling with implementing 
the magic functions __str__ and __hash__ of the extension class. 
My current approach was to implement them as ordinary member 
functions:



extern(C) void PydMain() {
module_init();

// Reaction
wrap_class!(PyReaction,
PyName!"Reaction",
Init!(MultiSet, MultiSet),
Property!(PyReaction.reactants),
Property!(PyReaction.products),
Repr!(PyReaction.repr),
Def!(PyReaction.py_str, PyName!"__str__"),   // XXX needs slot
Def!(PyReaction.py_hash, PyName!"__hash__"), // XXX needs slot
)();
}

but this does not work. In Python:

Python 2.7.12+ (default, Sep 17 2016, 12:08:02)
[GCC 6.2.0 20160914] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.

from teest_module import *
r=Reaction({'a':1, 'b':1}, {'ab':1})
r.__hash__
0x7fc1c7f4a080>

r.__hash__()

1430289695L

hash(r)

8779391257096

According to related post for C++/SWIG 
(http://stackoverflow.com/questions/25199233/str-not-called-when-printing-c-class-wrapped-for-python-with-swig), the reason is that these magic methods need to be implemented as slots, rather than ordinary member functions.


Is there a way to declare these slots in PyD? I noticed that Repr 
does this for __repr__ and the operator overloads do this of 
course for their respective slots, but I could not find anything 
for __hash__ and __str__.


Any ideas?

Thanks!

Re: Terminix renamed to Tilix

[Minas Mina via Digitalmars-d-announce]

On Monday, 20 March 2017 at 16:56:02 UTC, Gerald wrote:
Terminix, a Linux GTK3 tiling terminal emulator written in D, 
has been renamed to Tilix due to trademark infringement issues 
with the Terminix International corporation. The new URLs for 
Tilix are as follows:


Website: https://gnunn1.github.io/tilix-web
Github Repo: https://github.com/gnunn1/tilix

As always, anyone is interested in participating in the 
development of Tilix feel free to drop me a line.


I have tried it on Ubuntu.
Works like a charm, thanks for the good work!
(I have set it as my default terminal :))

Re: [OT] ISO C++ 17 changes

[Nick Treleaven via Digitalmars-d]

On Tuesday, 4 April 2017 at 13:30:47 UTC, Meta wrote:

On Tuesday, 4 April 2017 at 08:38:32 UTC, Walter Bright wrote:

http://dlang.org/phobos/std_algorithm_iteration.html#.fold


Not quite the same as this is a fold over a TypeTuple/AliasSeq. 
You could of course do:


only(args).fold!"a + b"()

But the semantics are different.


To avoid the runtime loop above, we could add an overload 
fold(alias fun, A...)(A args). (There are already min, max that 
take variadic arguments in std.algorithm). I think this would be 
more powerful than the C++ feature as it would support any 
function.


To make it a little nicer, we could have binaryFun accept 
operators as strings, e.g. fold!"+"(args). Doing that would allow 
e.g. sort!">"(r).