Vibe.d diet template reuse

[Jot via Digitalmars-d-learn]

I would like to create some generic diet templates for different 
html functionality.


Some code in the template will need to be setup/changed for it to 
function properly.


How can I write code that allows for one to express generic 
statements in the template but access/modify them in another 
template?


Is there a way to pass around a context, including functional 
code between templates?


e.g., I might want to create a d function in a diet template that 
will be used in generating another template.


e.g. (pseudo),

block
   -auto MyFunc(int x) { return 3*x; }
   include test



test.dt:

block
   -for(i; 1..MyFunc(3))
  ...


having such a feature allows me to generalize my templates quite 
a bit and reuse them for various html features rather than 
duplicating the majority of the code but I need a way to pass 
some unspecified functionality to a template before instantiation.

[Issue 14613] DMD: Internal error: backend/cod1.c 1567 on '-O' switch

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/a4f584ffdc195cc99a738ba495c8261284813d2a
fix Issue 14613 - DMD: Internal error: backend/cod1.c 1567 on '-O' switch

https://github.com/dlang/dmd/commit/5f803b0d75a722937a13b6590176984c3d436403
Merge pull request #6218 from WalterBright/fix14613

fix Issue 14613 - DMD: Internal error: backend/cod1.c 1567 on '-O' sw…

--

Re: Ever want to compile D on your Android phone? Well, now you can!

[Joakim via Digitalmars-d-announce]

On Saturday, 29 October 2016 at 21:47:35 UTC, Mergul wrote:

On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote:
An alpha release of ldc, the llvm-based D compiler, for 
Android devices is now available.  It is best used with the 
excellent Termux app 
(https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch):


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

You can install a test runner app or run a command-line binary.
 Please report your results in this thread in the ldc forum, 
which requires no registration, with the info and format 
requested there, particularly for Android 4.1 or earlier:


https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org

If you try out the native compiler, take a look at the README 
that comes with it for instructions.


If you have a D/OpenGL app you'd like to port to Android and 
submit to the Play Store, let me know if I can help with that 
process.


I'm trying to build native-activity sample in .d.
I have build cross ldc compiler using your instructions. When I 
have build native activity its work properly on BlueStack, but 
on my phone (android 4.2.1) this always crash and run again. 
Your app test runner work perfect and every test passed.

Application always crash when I'm using android_app.savedState.

if (state.savedState != null) {
// We are starting with a previous saved state; restore 
from it.

engine.state = *cast(saved_state*)state.savedState; //crash!
}

Sorry for bad english.


Hmm, I am unable to reproduce the crash with that sample app on 
my tablet running Marshmallow.  Can you try the prebuilt 
cross-compilers at 
https://github.com/joakim-noah/android/releases and see if the 
problem crops up with those too?


If you are able to reproduce consistently with some compiler, 
please file an issue with more info, such as which ldc version 
you built and what commands you used to build the app, either at 
the github repo for the sample app, 
https://github.com/joakim-noah/android/, or if you can reproduce 
with the pre-built ldc compilers, at the ldc github, 
https://github.com/ldc-developers/ldc/.

fPIC Error

[Dlang User via Digitalmars-d-learn]

I am running Debian Testing and I think I have run into the 
recent fPIC issue.  This is the source code for the test project 
I am using:


import std.stdio;

void main()
{
writeln("Edit source/app.d to start your project.");
readln();
}


When I try to compile a project, I get the following errors 
(truncated for brevity):



/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
dmd failed with exit code 1.
Exit code 2
Build complete -- 1 error, 0 warnings

I followed the advice to add "-defaultlib=libphobos2.so -fPIC" to 
my dmd.conf file as a workaround.


This causes it to build without errors, but now the resulting 
executable is marked as a shared library:


Output of the file command:

fpictest: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, 
BuildID[sha1]=e83ac1d5dea9e78912a6175d3c1c54b50b4e29cd, not 
stripped


Is this a known issue with this workaround or is there some other 
setting that I need to change?

mangle!(void function())("foo").demangle = "void function()* foo"

[Timothee Cour via Digitalmars-d-learn]

mangle!(void function())("foo").demangle returns "void function()* foo"

how would i get instead: `void foo ()` ?

my current workaround:

alias FunctionTypeOf(Fun)=typeof(*Fun.init);
mangle!(FunctionTypeOf!(void function()))("foo")

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 11:43 PM, Vladimir Panteleev wrote:

For each function that is only called during compilation (e.g. for code
generation), at the top add:

if (!__ctfe)
return;

That's it. For one project, this brought compilation time (with
optimizations) from over an hour down to seconds!

As it turns out, DMD will codegen all functions, even templated ones
when they're instantiated, whether they're called by something or not.
With metaprogramming-heavy code, it's easy to run into some optimizer
performance corner cases, however this may make an impact regardless.



That's interesting. cc Dmitry, perhaps adding that to ctRegex would be 
helpful. -- Andrei

Re: Error: function std.stdio.setmode is not accessible from module a

[Kirill Kryukov via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 11:17:49 UTC, Jonathan M Davis 
wrote:
setmode was never publicly documented, and technically, you 
weren't supposed to be using it from there (since it wasn't 
documented). It was fixed in 2.072.0 so that all of the 
undocumented stuff in std.stdio was made private. It was never 
intended that setmode be part of the public API in std.stdio. 
But of course, since you were using it in spite of it being 
undocumented, your code broke.


Now, setmode is a C function from Windows, so it should be in 
druntime where you could easily import it, but unfortunately, 
it looks like it's currently missing from there. Rather, the 
bindings for it were just put directly in std.stdio instead of 
in druntime where they belongs. So, if anything, the bug is 
that druntime doesn't have it. So, it would make sense to open 
a bug for that. But if you want to still use it without it 
being in druntime, you can just declare the bindings yourself, 
as annoying as that may be. e.g. this is essentially what's in 
std.stdio:


version(DIGITAL_MARS_STDIO)
extern(C) int setmode(int, int) nothrow @nogc;
else version(MICROSOFT_STDIO)
{
extern(C) int _setmode(int, int) nothrow @nogc;
alias setmode = _setmode;
}

It really should be put in druntime though.

- Jonathan M Davis


Thanks for the explanation, Jonathan! OK, I'll try adding my own 
binding for the time being, and submit a feature request.


I guess this does not count as regression since it was 
undocumented, as you say. Although I would have thought it was a 
documentation deficiency instead. Working, not obviously wrong 
code stopped working without an alternative method available. 
Perhaps it's OK if it can be added to druntime the future.


Also I am confused by it being both deprecation and error. I 
thought that deprecation message was just a warning about 
something that will stop working in the future, and the code 
should still compile. However in this case dmd first informs me 
that something is deprecated (it's not clear what exactly is 
deprecated). And then immediately fails with an error, on the 
same function call. Is it another separate diagnostic issue, or 
is it working as intended?


Thanks,
Kirill

[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6232

--

[Issue 16658] Win32API: default IE ver. set to 4.0 is too old

[via Digitalmars-d-bugs]

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

--- Comment #1 from j...@red.email.ne.jp ---
Forgot to mention:

The value cooperating with this is defined that
_WIN32_WINNT = 0x501 ( means WinXP )



So I suppose that _WIN32_IE should be changed as follows.

version (IE10) {
} else version (IE9) {
} else version (IE8) {
   ... snipped ...
} else static if (_WIN32_WINNT >= 0x501) { // ADD
enum uint _WIN32_IE = 0x600;   // ADD
} else static if (_WIN32_WINNT >= 0x410) {
enum uint _WIN32_IE = 0x400;   // this is used now
} else {

--

[Issue 16658] New: Win32API: default IE ver. set to 4.0 is too old

[via Digitalmars-d-bugs]

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

  Issue ID: 16658
   Summary: Win32API: default IE ver. set to 4.0 is too old
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

About Win32 API shipped with 2.070 druntime,
the condition for IE 'version _WIN32_IE = 0x400' ( by default ) is too old.
# See druntime/src/core/sys/windows/w32api.d.

At least, the value should be 0x600(the version bundled with WinXP),
otherwise some GUI enhansements (switch by that) are ignored because they are
shared with the OS.


Note:
If someone made an old app for Win98 or 2000 with the Win32 Bindings
_AND_ he has fixed it for the current druntime,
it may be subject to change.

--

Re: State of issues.dlang.org

[ketmar via Digitalmars-d]

On Wednesday, 2 November 2016 at 23:01:42 UTC, Brad Roberts wrote:

Upgrading is on my todo list.  I'll try to get to it soon.


thank you for investigating the possibility. post preview is a 
great feature! ;-)

Re: State of issues.dlang.org

[Walter Bright via Digitalmars-d]

On 11/2/2016 4:01 PM, Brad Roberts via Digitalmars-d wrote:

Upgrading is on my todo list.  I'll try to get to it soon.


Thank you, Brad. Your support of Bugzilla is critically important.

Re: Should I prefer immutable or const?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 02, 2016 23:23:22 Nordlöw via Digitalmars-d-learn 
wrote:
> On Tuesday, 1 November 2016 at 18:55:26 UTC, Jonathan M Davis
>
> wrote:
> > - Jonathan M Davis
>
> Thanks. I'll go for immutable, when possible, then.
>
> I wish I had a shorter way to write immutable, though :)
>
> Do you think it would be possible to adopt Rust's syntax `let`?

I'm not very familiar with rust, so I don't know, but in general, at this
point, you'd need a pretty solid argument why a syntactic change to the
language was a big improvement, or it wouldn't happen. It also would likely
require that someone put in the time and effort to produce a solid DIP in
favor of it, and from how Andrei has been responding to DIP-related stuff of
late, it sounds like he and Walter are setting the bar very high right now.
And I'd guess that simply not liking how many characters it takes to type
immutable is nowhere near a sufficient reason to get anything changed. But
maybe a solid DIP would stand a chance. I don't know.

- Jonathan M Davis

Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Jon Degenhardt via Digitalmars-d]

On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei 
Alexandrescu wrote:


Last time I looked our associative arrays were arrays of 
singly-linked lists. It follows that in order to implement 
reserve() we'd need a freelist allocator approach, which 
preallocates a bunch of nodes in a single contiguous block of 
memory.


Aren't associative arrays using open addressing for collision 
resolution? I'm looking at routines findSlotInsert() and 
findSlotLookup() here: 
https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L102


There is already a resize() routine: 
https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L141


The resize() routine takes the new size of the bucket array as an 
argument. Could a 'reserve' routine call this? Scanning through 
the code, it appears policy on size of the bucket array is 
established by callers to resize(), e.g. see the _aaRehash() 
function, which calls resize().

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Wednesday, 2 November 2016 at 23:48:46 UTC, Nordlöw wrote:
On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch 
wrote:

I am now passing phobos unittests!


I can't wait to see this in action!

Keep on going and I'll keep praying... 


No need for prayer.

I am trying my best to be doing solid engineering work.

Neither god nor the devil will paly any role.

I am currently working on making the DMD-AST-facing side of the 
code more solid.


With a bit of luck I can role out a preview release soon.

But I will only do so when there are no known bugs left.

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch wrote:

I am now passing phobos unittests!


I can't wait to see this in action!

Keep on going and I'll keep praying... 

Re: Should I prefer immutable or const?

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 18:55:26 UTC, Jonathan M Davis 
wrote:

- Jonathan M Davis


Thanks. I'll go for immutable, when possible, then.

I wish I had a shorter way to write immutable, though :)

Do you think it would be possible to adopt Rust's syntax `let`?

Re: State of issues.dlang.org

[Brad Roberts via Digitalmars-d]

On 11/2/16 2:44 PM, Vladimir Panteleev via Digitalmars-d wrote:

On Wednesday, 2 November 2016 at 12:34:04 UTC, Wyatt wrote:

This was added in Bugzilla 5.0.  We're just running 4.4.2 on issues.d.o.

Unfortunately, I'm not sure how easy it is to upgrade...


I believe Brad is using the Debian packaged version, so we'll get it whenever 
it reaches whatever
Debian flavor Brad is running.


Actually, bugzilla is one of the few things that's not from pre-packaged 
installers. :)

I do have some minor modifications that have to be ported over, primarily related to interacting 
with the newsgroups.  I haven't looked at the 4 -> 5 update to see how easily they changes will 
translate.  The 3 -> 4 transition took some re-working due to internal changes in bugzilla.


Upgrading is on my todo list.  I'll try to get to it soon.

Later,
Brad

Re: RC buffer

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 01:00 AM, Andrei Alexandrescu wrote:

In order to make opAssign safe, a language change will be necessary.


Take that back, no need for a language change as long as nobody returns 
references to refcounted memory.


Just pushed a commit to add @safe-ty annotations everywhere. Works as 
advertised! So now we have a buffer of ubyte that is reference counted, 
safe, and supports qualifiers properly (no shared yet).


https://github.com/dlang/phobos/pull/4878


Andrei

Re: State of issues.dlang.org

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 2 November 2016 at 12:34:04 UTC, Wyatt wrote:
This was added in Bugzilla 5.0.  We're just running 4.4.2 on 
issues.d.o.


Unfortunately, I'm not sure how easy it is to upgrade...


I believe Brad is using the Debian packaged version, so we'll get 
it whenever it reaches whatever Debian flavor Brad is running.

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[jmh530 via Digitalmars-d]

On Wednesday, 2 November 2016 at 20:03:59 UTC, Meta wrote:


I think there's an obvious reason as to why they're not called 
that.


I almost always see languages call it cumsum rather than 
cumulativeSum.


R - 
https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html

Matlab - https://www.mathworks.com/help/matlab/ref/cumsum.html
Python - 
https://docs.scipy.org/doc/numpy/reference/generated/numpy.cumsum.html


The only exceptions I could find were languages that called it 
something else, like Accumulate in Mathematica or the scan 
functions noted in the cumulativeFold function doc.


In practice, I would probably just create an alias.

Re: Ever want to compile D on your Android phone? Well, now you can!

[Dawid Masiukiewicz via Digitalmars-d-announce]

On Tuesday, 1 November 2016 at 13:33:02 UTC, Steven Schveighoffer 
wrote:

android_app.savedState appears to be defined here:

https://github.com/joakim-noah/android/blob/polish/android_native_app_glue.d#L56

It's a void *. So comparing against null with != is identical 
to !is.


There are actually cases where comparing against null with != 
is valid, and what you want exactly (e.g. comparing a string to 
null to check for empty string).


In this case, fixing the comparison is not the answer. What is 
happening is one of several things:


1. I don't know what type `engine` is, so if it's a pointer, 
then dereferencing the state member may be the culprit if 
engine is invalid.
2. If state is a pointer, then you could be crashing at the if 
statement (unlikely).

3. state or state.savedState isn't being properly initialized.
4. Something else (e.g. code generation error). Hope it's not 
this one.


-Steve


I don't know what was bad but I start working on something 
different.
I managed to compile project with SDL. Using SDL c++ code which 
call my D code. It's work.

Used libraries: SDL, Assimp, FreeImage.
http://imgur.com/a/aMs15

Re: SoundTab Theremin software synthesizer

[Karabuta via Digitalmars-d-announce]

On Wednesday, 2 November 2016 at 09:35:20 UTC, Vadim Lopatin 
wrote:

On Monday, 31 October 2016 at 22:33:38 UTC, Karabuta wrote:
On Friday, 28 October 2016 at 08:28:41 UTC, Vadim Lopatin 
wrote:

Hello,

I've open sourced my project SoundTab: 
https://github.com/buggins/soundtab/




I've published derelict-wintab (Wacom tablet API) and wasapi 
(windows audio API) libraries used for this project.


+1

Re: Linux Kernel in D?

[Karabuta via Digitalmars-d]

On Wednesday, 2 November 2016 at 13:56:22 UTC, qznc wrote:
On Tuesday, 1 November 2016 at 16:22:58 UTC, Andrei 
Alexandrescu wrote:

[...]


Nevertheless, I don't see a successful D kernel in the 
foreseeable future. Building a kernel for IoT devices is 
trendy, but you want a lot more portability for that and C 
compilers are everywhere. On the server, you could build a 
hypervisor OS with D, but currently containers are hyped so 
much more. You'd only have a chance, if you also port the JVM 
onto your D-OS. Still, where is the advantage to Linux?


Who knew containers will suddenly become a thing? You never know 
what might happen, a D kernel might as well be the game changer.

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[Meta via Digitalmars-d]

On Wednesday, 2 November 2016 at 00:41:38 UTC, jmh530 wrote:
On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko 
wrote:


DMD 2.072 just got cumulativeFold:

https://dlang.org/changelog/2.072.0.html#std-algorithm-iteration-cumulativeFold

https://dlang.org/phobos/std_algorithm_iteration.html#cumulativeFold


I was happy to see that.

I'm surprised there wasn't more angst about the name. 
cumulativeSum should be cumsum, which implies that 
cumulativeFold should be cumfold, IMO.


I think there's an obvious reason as to why they're not called 
that.

Re: __traits(getMember)

[Jacob Carlborg via Digitalmars-d]

On 2016-11-02 17:30, Márcio Martins wrote:

Can we get a getMember and a getOverloads that won't check for
visibility or anything else?

__traits appears really powerful, but every-time I try to use it for
anything other than a toy example or very simple serialization, it seems
like everything falls apart due to some detail... and I end up having to
hack it up with string mixins and static if(is(typeof(() { some_code; }))).


For serialization, where you most likely only need to access the fields, 
you can use .tupleof which will bypass the protection.


--
/Jacob Carlborg

Re: Release D 2.072.0

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

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

-Martin


https://www.reddit.com/r/programming/comments/5aru4f/d_version_2072_released_over_200_bugs_fixed/

Re: __traits(getMember)

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 02, 2016 16:30:04 Márcio Martins via Digitalmars-d 
wrote:
> Can we get a getMember and a getOverloads that won't check for
> visibility or anything else?

That's coming. There was a big discussion on it after the import rules were
changed. But IIRC, it was decided that we wouldn't just switch to that
immediately (maybe because it was a point release?). I don't remember the
details now, so I guess that I'm not very helpful. I'd suggest trying
2.072.0, now that it's out, and seeing if that fixes your problem. If not,
2.073.0 probably will when we get it - which wouldn't be very helpful now,
but at least you'd know that the change was coming.

- Jonathan M Davis

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

On Tuesday, 1 November 2016 at 21:52:40 UTC, e-y-e wrote:

...


bump : any more opinions?

Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)

[deXtoRious via Digitalmars-d]

On Saturday, 29 October 2016 at 11:25:17 UTC, Nicholas Wilson 
wrote:
On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat 
wrote:
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson 
wrote:


If you have any experience with either OpenCL or CUDA we'd 
love to have your input.


Have experience with both, more CUDA than OpenCL though. Feel 
free to contact me.


Great! I'll let you know when the compiler stuff is merged, 
probably in mir's public gitter.


I have experience with both CUDA and OpenCL. As soon as the 
compiler stuff is in, I'd be happy to port some of my standard 
microbenchmarks (mostly computational fluid dynamics stuff) and 
see how it stacks up in both performance/ease of use and get you 
some feedback.


I'm following the git repo and occasionally checking these 
forums, but feel free to contact me via e-mail or any other 
medium.

Re: hashOf()

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 2 November 2016 at 16:14:23 UTC, Márcio Martins 
wrote:
If you include core.internal.hash, you cannot call hashOf() 
anymore, because it conflicts with the implicit import in 
object.d, this is annoying in itself...


You should still be able to call it with the full name, 
`object.hashOf(...)` vs `core.internal.hash.hashOf(...)`

__traits(getMember)

[Márcio Martins via Digitalmars-d]

Can we get a getMember and a getOverloads that won't check for 
visibility or anything else?


__traits appears really powerful, but every-time I try to use it 
for anything other than a toy example or very simple 
serialization, it seems like everything falls apart due to some 
detail... and I end up having to hack it up with string mixins 
and static if(is(typeof(() { some_code; }))).



Also, I found this bug:

import std.datetime;
import std.stdio;
import std.traits;
import std.meta;

template staticIota(int start, int stop, int step = 1) {
  static if(start < stop) {
alias staticIota = AliasSeq!(start, staticIota!(start + step, 
stop, step));

  } else {
alias staticIota = AliasSeq!();
  }
}

struct M {
  void test(T)(T x) {
enum MemberName = "day";
foreach (i; staticIota!(0, __traits(getOverloads, x, 
MemberName).length)) {
  alias Member = Alias!(__traits(getOverloads, x, 
MemberName)[i]);
  alias MemberType = typeof(&__traits(getOverloads, x, 
MemberName)[i]);


  static if (is(FunctionTypeOf!(Member)) && 
(__traits(getProtection, Member) == "public")) {
auto addr =  //Error: this for day needs to be 
type Date not type M

pragma(msg, MemberName, MemberType);
writeln("addr: ", addr);
  }
}
  }
}

void main() {
  Date x;
  M m;
  m.test(x);
}

// output:
errocase.d(23): Error: this for day needs to be type Date not 
type M

dayubyte delegate() const pure nothrow @property @safe
errocase.d(23): Error: this for day needs to be type Date not 
type M

dayvoid delegate(int day) pure @property @safe
errocase.d(34): Error: template instance errocase.M.test!(Date) 
error instantiating



It works fine if test(T)() is not a member function...

Re: hashOf()

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 02, 2016 16:19:44 John Colvin via Digitalmars-d 
wrote:
> I think that "internal" means "for internal use", I.e. don't
> import and use it outside.
>
> You could argue that object.hashOf should hash the contents of
> slices, not just the meta-data (i.e. length / ptr), but that's a
> separate matter.

Yeah. Don't use anything in an internal package in either druntime or
Phobos. And now that we can do stuff like package(std), it should be
possible to fix it so that those symbols _can't_ be imported while still
being usable by other code inside the higher level package. Previously, the
only way to have core.internal accessible by the rest of core was to have it
be public, which then didn't actually prevent you form doing stuff like
importing it in your own code even though you shouldn't. So, core.internal
should be fixed to use package(core).

- Jonathan M Davis

Re: hashOf()

[John Colvin via Digitalmars-d]

On Wednesday, 2 November 2016 at 16:14:23 UTC, Márcio Martins 
wrote:
There are 2 hashOf() definitions, one in object.d and one in 
core.internal.hash.d


If you include core.internal.hash, you cannot call hashOf() 
anymore, because it conflicts with the implicit import in 
object.d, this is annoying in itself...

The bigger issue though, is that they have different semantics:

import core.internal.hash : hashOfInt = hashOf;

void main() {
string moo = "moo";
assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes 
moo.ptr[0..moo.length]
assert(moo.hashOf == moo.idup.hashOf); // fail - hashes 
[0..moo.sizeof]

}

Did anyone else fall into this trap?


I think that "internal" means "for internal use", I.e. don't 
import and use it outside.


You could argue that object.hashOf should hash the contents of 
slices, not just the meta-data (i.e. length / ptr), but that's a 
separate matter.

hashOf()

[Márcio Martins via Digitalmars-d]

There are 2 hashOf() definitions, one in object.d and one in 
core.internal.hash.d


If you include core.internal.hash, you cannot call hashOf() 
anymore, because it conflicts with the implicit import in 
object.d, this is annoying in itself...

The bigger issue though, is that they have different semantics:

import core.internal.hash : hashOfInt = hashOf;

void main() {
string moo = "moo";
assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes 
moo.ptr[0..moo.length]
assert(moo.hashOf == moo.idup.hashOf); // fail - hashes 
[0..moo.sizeof]

}

Did anyone else fall into this trap?

Re: RC buffer

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 11:32 AM, Andrei Alexandrescu wrote:

On 11/02/2016 07:29 AM, Nick Treleaven wrote:

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote:

In order to make opAssign safe, a language change will be necessary.


Technically, it should be possible with runtime checks:

https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org

The checking overheads disappear when -noboundschecks is passed. The
user has to manually copy the RCSlice when necessary for correct code.


It seems opAssign for RCSlice is unsafe, is that right? Consider (with
your codebase):

@safe void fun(ref RCSlice!int a, ref RCSlice!int b)
{
a = RCSlice!int();
... use b ...
}

@safe void gun(ref RCSlice!int s)
{
fun(s, s);
}

Assume the reference count of s is 1 upon entering gun. Then the first
thing opAssign does is to call the destructor of the slice, which
deallocates memory. Subsequently the other reference (b) is dangling.


Ah, never mind, the two names refer to the same object. -- Andrei

[Issue 16657] [The D Bug Tracker]

[via Digitalmars-d-bugs]

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

--- Comment #1 from Eyal  ---
Minor correction: opCmp is not auto-generated anyway and opEquals should just
be exhaustive and not lexicographic.

--

Re: Best way to get ceil(log2(x)) of a BigInt?

[Andrea Fontana via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 15:15:18 UTC, Andrea Fontana 
wrote:

Why don't you perform a binary search over 200 power of 2?


Something like: http://paste.ofcode.org/scMD5JbmLMZkrv3bWRmPPT

I wonder if a simple binary search on whole array is faster than 
search for limits as in this example


PS: If you need ceil, just use the else branch with <= instead of 
<.


Andrea

Re: RC buffer

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 07:29 AM, Nick Treleaven wrote:

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote:

In order to make opAssign safe, a language change will be necessary.


Technically, it should be possible with runtime checks:

https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org

The checking overheads disappear when -noboundschecks is passed. The
user has to manually copy the RCSlice when necessary for correct code.


It seems opAssign for RCSlice is unsafe, is that right? Consider (with 
your codebase):


@safe void fun(ref RCSlice!int a, ref RCSlice!int b)
{
a = RCSlice!int();
... use b ...
}

@safe void gun(ref RCSlice!int s)
{
fun(s, s);
}

Assume the reference count of s is 1 upon entering gun. Then the first 
thing opAssign does is to call the destructor of the slice, which 
deallocates memory. Subsequently the other reference (b) is dangling.



Andrei

Re: Best way to get ceil(log2(x)) of a BigInt?

[Andrea Fontana via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 14:49:08 UTC, pineapple wrote:
On Wednesday, 2 November 2016 at 14:24:42 UTC, Andrea Fontana 
wrote:

On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote:
I'm trying to do some math stuff with std.bigint and realized 
there's no obvious way to calculate the ceil of log2 of a 
bigint. Help?


How big are your bigints?


I think they'll generally stay between 0 and 2^200

I came up with this, I guess it'll work?

   auto clog2(BigInt number) in{
assert(number > 0);
}body{
uint log;
auto n = number - 1;
while(n > 0){
log++; n >>= 1;
}
return log;
}


Why don't you perform a binary search over 200 power of 2?
Something like:

BigInt powers[] = [BigInt(2), BigInt(4), BigInt(8), ...];

And I think you can reduce your search in a smaller interval. 
Something like:


   string number = "71459266416693160362545788781600";
   BigInt i = number;
   ulong l = number.length;

   ulong approxMin = cast(ulong)((l-1)/0.30103);
   ulong approxMax = cast(ulong)((l)/0.301029);

So you can search on powers[approxMin .. approxMax], if i'm right.

Re: Set Operations on Set-like Containers

[Andrei Alexandrescu via Digitalmars-d-learn]

On 11/02/2016 11:07 AM, Nordlöw wrote:

On Wednesday, 2 November 2016 at 13:45:41 UTC, Nordlöw wrote:

Typically set- and map-like containers with O(1) key membership checking.


A typical use case is intersection of the two sets `x` and `y`.

When `x` and `y` both support O(1)-`contains(e)` the preferred algorithm
is to interate over all elements in the shorter (smallest .length) of
`x` and `y` (called `s`), and return only those elements of type E in
`s` than can be looked up in `l` via `l.contains(E)`.


Currently we don't have a good framework for associative ranges yet. We 
should define what the associative operations are, and then we can 
proceed to see where they'd make sense. -- Andrei

[Issue 16657] New: [The D Bug Tracker]

[via Digitalmars-d-bugs]

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

  Issue ID: 16657
   Summary: [The D Bug Tracker]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

When adding an "alias this" to a type, the automatic opEquals and opCmp that
compare the object lexicographically are removed and instead only the alias
this portion of the type is compared via its opEquals/opCmp.

struct A {
int x;
}

struct B {
A a, b;
}
static assert(B(A(1), A(1)) != B(A(1), A(2))); // Works

struct C {
A a, b;
alias a this;
}
static assert(C(A(1), A(1)) != C(A(1), A(2))); // Fails!

Adding alias this should NOT cause a preference for the base type's
comparators.

--

Re: Is the following code legal?

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh 
wrote:
The D documentation (https://dlang.org/spec/hash-map.html) 
leaves this not defined.


The foreach statement is defined to not allow it:

http://dlang.org/spec/statement.html#ForeachStatement

"The aggregate must be loop invariant, meaning that elements to 
the aggregate cannot be added or removed from it in the 
NoScopeNonEmptyStatement."

Re: Is the following code legal?

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 11:17 AM, Adam D. Ruppe wrote:

On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh wrote:

The D documentation (https://dlang.org/spec/hash-map.html) leaves this
not defined.


The foreach statement is defined to not allow it:

http://dlang.org/spec/statement.html#ForeachStatement

"The aggregate must be loop invariant, meaning that elements to the
aggregate cannot be added or removed from it in the
NoScopeNonEmptyStatement."


Yah, we'd do good to relax that to allow removal of the currently 
iterated element. -- Andrei

Re: Release D 2.072.0

[anonymous via Digitalmars-d-announce]

On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:
On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen 
wrote:

LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between 
module ddmd.traits and ddmd.cond

ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*

Pretty much all of LDC's D code is DDMD front-end code, master 
is at front-end version 2.071.2. I hope someone can try to 
build DMD 2.071.2 using 2.072.0 and see if a similar issue is 
found.


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but 
boot since master straping works there's probably something 
that's been fixed in one or two of these ddmd modules, likely a 
static ctor...


Maybe after this:

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368

ddmd.attribs was removed

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15

and it was also part of the cycle.

Re: Set Operations on Set-like Containers

[Nordlöw via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 13:45:41 UTC, Nordlöw wrote:
Typically set- and map-like containers with O(1) key membership 
checking.


A typical use case is intersection of the two sets `x` and `y`.

When `x` and `y` both support O(1)-`contains(e)` the preferred 
algorithm is to interate over all elements in the shorter 
(smallest .length) of `x` and `y` (called `s`), and return only 
those elements of type E in `s` than can be looked up in `l` via 
`l.contains(E)`.

Re: Release D 2.072.0

[anonymous via Digitalmars-d-announce]

On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen 
wrote:

LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between 
module ddmd.traits and ddmd.cond

ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*

Pretty much all of LDC's D code is DDMD front-end code, master 
is at front-end version 2.071.2. I hope someone can try to 
build DMD 2.071.2 using 2.072.0 and see if a similar issue is 
found.


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but 
boot since master straping works there's probably something 
that's been fixed in one or two of these ddmd modules, likely a 
static ctor...

Re: Is the following code legal?

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2016 10:21 AM, Shachar Shemesh wrote:

int[int] hash;

..

foreach( key, ref value; hash ) {
if( value>12 )
hash.remove(key);
}

Some hash implementations support this, some don't. The D documentation
(https://dlang.org/spec/hash-map.html) leaves this not defined.

As reference, C++ does define this (in C++ it is allowed, at least since
C++14: http://en.cppreference.com/w/cpp/container/unordered_map/erase)

Shachar


We should render it defined, and document it as such. Could you please 
create an issue and I'll have someone look at it. Thanks! -- Andrei

Re: Best way to get ceil(log2(x)) of a BigInt?

[pineapple via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 14:24:42 UTC, Andrea Fontana 
wrote:

On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote:
I'm trying to do some math stuff with std.bigint and realized 
there's no obvious way to calculate the ceil of log2 of a 
bigint. Help?


How big are your bigints?


I think they'll generally stay between 0 and 2^200

I came up with this, I guess it'll work?

   auto clog2(BigInt number) in{
assert(number > 0);
}body{
uint log;
auto n = number - 1;
while(n > 0){
log++; n >>= 1;
}
return log;
}

[Issue 2742] std.stdio assumes console works in utf-8

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

 CC||m...@krej.cz
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15761

--

[Issue 15761] Windows wide character console output broken with MS runtime

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=2742

--

Is the following code legal?

[Shachar Shemesh via Digitalmars-d]

int[int] hash;

..

foreach( key, ref value; hash ) {
if( value>12 )
hash.remove(key);
}

Some hash implementations support this, some don't. The D documentation 
(https://dlang.org/spec/hash-map.html) leaves this not defined.


As reference, C++ does define this (in C++ it is allowed, at least since 
C++14: http://en.cppreference.com/w/cpp/container/unordered_map/erase)


Shachar

Re: Best way to get ceil(log2(x)) of a BigInt?

[Andrea Fontana via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote:
I'm trying to do some math stuff with std.bigint and realized 
there's no obvious way to calculate the ceil of log2 of a 
bigint. Help?


How big are your bigints?

[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Nick Treleaven from comment #0)
> The static asserts below fail:
> 
> struct Color {struct Red {}}
> 
> unittest {
>   import std.traits;
> 
>   alias ls = (string) => "string";
>   static assert(isSomeFunction!ls);
> 
>   with (Color) {
>   alias lc = (Red) => "red";
>   static assert(isSomeFunction!lc);
>   }
> }

This is a gotcha, but it's not a bug. In a function literal, a single
identifier is interpreted as the name of the parameter, not the type. So
`string` and `Red` do not refer to the types of the same names, but they're
parameter names. Consequently, ls and lc are not functions, but templates,
because the parameters are not typed yet.

Closing as invalid. Please reopen if I'm missing something.

--

Best way to get ceil(log2(x)) of a BigInt?

[pineapple via Digitalmars-d-learn]

I'm trying to do some math stuff with std.bigint and realized 
there's no obvious way to calculate the ceil of log2 of a bigint. 
Help?

[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)

[via Digitalmars-d-bugs]

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

--- Comment #2 from Johan Engelen  ---
Bootcamp hint: start looking at `mangleVariable` in `VisualCPPMangler` in
cppmangle.d.

--

Re: Linux Kernel in D?

[qznc via Digitalmars-d]

On Tuesday, 1 November 2016 at 16:22:58 UTC, Andrei Alexandrescu 
wrote:

On 11/01/2016 09:41 AM, Wild wrote:

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage 
compared to the

one that is written in C?


I think it wouldn't really be worth it.


I tend to think the same but for different reasons. Currently 
the Linux kernel is a large mature product that has its own 
evolution. It would be very difficult to reimplement it from 
first principles in any other language and get a competitive, 
timely product.


As an intellectual exercise, D's safety would help but at this 
point impart little advantage; the kernel has reached good 
stability and safety bugs are few and far across. This trend is 
likely for the foreseeable future.


Security is a big topic for Linux: 
https://lwn.net/Articles/662219/


Mostly the problem are drivers. They are produced hastily by 
careless companies without the scrutiny of the core kernel parts 
(like scheduler, file system, etc). I think D might help there, 
because it could enforce @safe or other properties onto the 
drivers.


Nevertheless, I don't see a successful D kernel in the 
foreseeable future. Building a kernel for IoT devices is trendy, 
but you want a lot more portability for that and C compilers are 
everywhere. On the server, you could build a hypervisor OS with 
D, but currently containers are hyped so much more. You'd only 
have a chance, if you also port the JVM onto your D-OS. Still, 
where is the advantage to Linux?

[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)

[via Digitalmars-d-bugs]

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

Johan Engelen  changed:

   What|Removed |Added

   Keywords||bootcamp

--

Set Operations on Set-like Containers

[Nordlöw via Digitalmars-d-learn]

Does

https://dlang.org/phobos/std_algorithm_setops.html

support specializations when (some) arguments are 
containers/ranges that provide the `in` operator?


Typically set- and map-like containers with O(1) key membership 
checking.


If not, should they?

And what about operator overloading for union (|), intersection 
(&) and difference (-)?

[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)

[via Digitalmars-d-bugs]

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

Johan Engelen  changed:

   What|Removed |Added

Summary|extern(C++) wrong mangling  |extern(C++, namespace)
   ||wrong mangling of variables
   ||(Windows)

--

[Issue 15576] extern(C++) wrong mangling

[via Digitalmars-d-bugs]

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

Johan Engelen  changed:

   What|Removed |Added

 CC||jbc.enge...@gmail.com

--- Comment #1 from Johan Engelen  ---
I ran into the same problem.

Simpler reproducer:

D:
extern (C++, ep) extern __gshared int variable;

C++:
namespace ep {
  int variable;
}

--

[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

--- Comment #9 from MichaelZ  ---
If this can't be readily fixed, then what exactly must we do (or rather, not
do) in our code to avoid triggering the issue?

Must we avoid using pre- (and post?) conditions in an interface at all?
Or must we avoid using pre- (and post?) conditions on 'override' functions?
Or something else entirely?

So far we've had the issue pop up roughly 4 times, some of those after making
apparently unrelated changes; cleaning up the problematic places once and for
all now that we have the issue in mind, will avoid frustrating bug hunting in
the future...

--

Re: RC buffer

[Andrei Alexandrescu via Digitalmars-d]

On 11/2/16 7:42 AM, anonymous wrote:

BTW about this PR: why RCString an not more generally RCArray ?


RCArray comes on top of RCBuffer. That way we isolate the matter of 
reference counting the buffer itself from the matter of managing the 
objects stored in the buffer. It's a simple matter of modularity. 
(Matters of alignment make this a bit more involved than it might seem, 
but nothing crazy.)


What is important (and probably unprecedented) about this PR is that 
it's the first reference counted artifact that works with qualifiers 
without resorting to undefined casts. That's the Big Thing about it. It 
harkens back to Dicebot idea to stash the reference counter in the 
allocator.



Andrei

[Issue 16656] move embedded zlib to a separate library

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com
   Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com

--

[Issue 16656] New: move embedded zlib to a separate library

[via Digitalmars-d-bugs]

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

  Issue ID: 16656
   Summary: move embedded zlib to a separate library
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

We'd like to get rid of the embedded zlib in phobos.
https://github.com/dlang/phobos/tree/fd518eb310a9494cccf28c54892542b052c49669/etc/c/zlib

As a shared zlib is available on literally any non-Windows OS, we should prefer
using that over statically linking.

For Windows we can integrate a DLL and import library with out binary releases,
similarly to how we handle libcurl. That means someone documents and builds
zlib [¹], we upload the results to downloads.dlang.org/other, and integrate it
with the build script [²][³].

[¹]: https://wiki.dlang.org/Curl_on_Windows
[²]:
https://github.com/dlang/installer/blob/8b3c7efe1e049f73ec5fc526a849904bf80b434d/create_dmd_release/build_all.d#L451
[³]:
https://github.com/dlang/installer/blob/8b3c7efe1e049f73ec5fc526a849904bf80b434d/create_dmd_release/build_all.d#L232

--

Re: Release D 2.072.0

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu 
wrote:

On 11/01/2016 11:41 AM, Johan Engelen wrote:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.


DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched 
back to DMD

2.071.2 for CI testing. :(


Is there somebody working on that bug? Thanks. -- Andrei


LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between 
module ddmd.traits and ddmd.cond

ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*

Pretty much all of LDC's D code is DDMD front-end code, master is 
at front-end version 2.071.2. I hope someone can try to build DMD 
2.071.2 using 2.072.0 and see if a similar issue is found.

Re: State of issues.dlang.org

[Wyatt via Digitalmars-d]

On Wednesday, 2 November 2016 at 11:00:58 UTC, Nick Treleaven 
wrote:


One thing I miss is the ability to preview posts on Bugzilla,


This was added in Bugzilla 5.0.  We're just running 4.4.2 on 
issues.d.o.


Unfortunately, I'm not sure how easy it is to upgrade...

-Wyatt

Re: RC buffer

[anonymous via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.



Andrei


BTW about this PR: why RCString an not more generally RCArray ?

Re: RC buffer

[Nick Treleaven via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
In order to make opAssign safe, a language change will be 
necessary.


Technically, it should be possible with runtime checks:

https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org

The checking overheads disappear when -noboundschecks is passed. 
The user has to manually copy the RCSlice when necessary for 
correct code.


The RCSlice in the link is just a basic proof of concept, using 
RCRef for temporary references. It doesn't handle reallocations - 
I think to have early diagnostics of potential errors it would 
need to have a separate RCRef reference count from the main 
count. That would be used to check there are no RCRef references 
alive when the main count is one and a reallocation could 
potentially occur - e.g. when appending. I think with this 
(hypothetical) RCSlice it's bug-prone to allow the user *not* to 
make a temporary copy of the RCSlice in this scenario because 
errors could depend on unknown runtime behaviour, not showing up 
in testing.


I mention this partly because I think this scenario has an impact 
on the design of a DIP to address when to automatically add 
reference counting bumps - perhaps a @rcbump attribute is 
necessary. Otherwise the compiler can't know if an external 
function taking an RCString performs an append or not.

[Issue 4542] [tdpl] TDPL NVI example results in linker error

[via Digitalmars-d-bugs]

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

Simon Na.  changed:

   What|Removed |Added

   Keywords||link-failure
 CC||eiderd...@gmail.com

--- Comment #16 from Simon Na.  ---
This bug is still in dmd 2.071.2 and 2.072.

I ran into this today, here's my reduced case:

interface IA {
package void f();
}
void main() {
IA a;
a.f();
}

Nothing new, but I'd like to nudge for resolution. :-) I dustmited my project
due to this bug. The linker error didn't help me.

If this is hard to fix, then maybe error out at compile-time as a hack?

-- Simon

--

Re: Error: function std.stdio.setmode is not accessible from module a

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 02, 2016 08:58:04 Kirill Kryukov via Digitalmars-d-
learn wrote:
> Hello,
>
> dmd 2.072.0 broke my project. I reduced it to following:
>
> = a.d start =
> import std.stdio;
>
> void main()
> {
>  setmode(stdin.fileno, 0x8000);
> }
> = a.d end =
>
> Compiling on Windows 7 64-bit with the following commands:
>
> C:\utl\dev\D\dmd-2.071.2\windows\bin\dmd.exe a.d -ofa1.exe
> C:\utl\dev\D\dmd-2.072.0\windows\bin\dmd.exe a.d -ofa2.exe
>
> The first one succeeds (producing a working executable), the
> second one fails with these messages:
>
> a.d(6): Deprecation: std.stdio.setmode is not visible from module
> a
> a.d(6): Error: function std.stdio.setmode is not accessible from
> module a
>
> 2.072.0 changelog does not seem to mention anything relevant. Is
> there something obvious I'm missing, or should I file a bug
> report?

setmode was never publicly documented, and technically, you weren't supposed
to be using it from there (since it wasn't documented). It was fixed in
2.072.0 so that all of the undocumented stuff in std.stdio was made private.
It was never intended that setmode be part of the public API in std.stdio.
But of course, since you were using it in spite of it being undocumented,
your code broke.

Now, setmode is a C function from Windows, so it should be in druntime where
you could easily import it, but unfortunately, it looks like it's currently
missing from there. Rather, the bindings for it were just put directly in
std.stdio instead of in druntime where they belongs. So, if anything, the
bug is that druntime doesn't have it. So, it would make sense to open a bug
for that. But if you want to still use it without it being in druntime, you
can just declare the bindings yourself, as annoying as that may be. e.g.
this is essentially what's in std.stdio:

version(DIGITAL_MARS_STDIO)
extern(C) int setmode(int, int) nothrow @nogc;
else version(MICROSOFT_STDIO)
{
extern(C) int _setmode(int, int) nothrow @nogc;
alias setmode = _setmode;
}

It really should be put in druntime though.

- Jonathan M Davis

Re: Pattern matching in D?

[Nick Treleaven via Digitalmars-d]

On Friday, 28 October 2016 at 11:53:16 UTC, Nick Treleaven wrote:
In the unittest, using with(Color) should help, but I couldn't 
get that to compile (visit thinks invalid lambdas are being 
passed).


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

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 November 2016 at 21:12:06 UTC, Nordlöw wrote:

On Tuesday, 1 November 2016 at 19:28:03 UTC, Stefan Koch wrote:

Now a phobos unittest miscompiles :(

Again passing the unittests does not mean too much.
I just means I bail out before I generate invalid code :)


Keep up!


I am now passing phobos unittests!
However please take it with a grain of salt ;)
The following line resbonsible for baling out of functions I know 
are failing.


	if (fd.ident == Identifier.idPool("isRooted") || fd.ident == 
Identifier.idPool("__lambda2") || fd.ident == 
Identifier.idPool("divideRoundUp") || fd.ident == 
Identifier.idPool("isSameLength") || fd.ident == 
Identifier.idPool("wrapperParameters") || fd.ident == 
Identifier.idPool("wrap") || fd.ident == 
Identifier.idPool("args"))

{
IGaveUp = true;
return ;
}

I am working on reducing test-cases to figure out why this is 
failing.
The code is burried in templates makeing it hard to see what is 
going on.


Still passing the tests is passing the tests :)

Re: State of issues.dlang.org

[Nick Treleaven via Digitalmars-d]

On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:

On 10/25/2016 05:17 AM, Jacob wrote:

There's no editing one's
comments so I often see people making multiple posts to 
themselves to
add more information or to correct themselves. That's just a 
minor

issue.


I don't think that's really an issue. Bugzilla sends out 
notification emails. An edit feature would complicate that. 
You'd have to read diffs instead of a human-written correction. 
I think that might be more annoying than having multiple 
comments. If any kind of discussion happens you're going to 
have many comments anyway.


One thing I miss is the ability to preview posts on Bugzilla, 
like our forum software. I know there's not much markup that 
happens for bugzilla posts, but somehow seeing the post rendered 
helps me to think whether I've forgotten anything or need to make 
some edits. Not huge but would be nice.

[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction

[via Digitalmars-d-bugs]

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

--- Comment #2 from Nick Treleaven  ---
BTW parameter names aren't needed because the lambdas are used for
Algebraic().visit!Lambdas:
http://forum.dlang.org/post/pggfdcttxdpernjbx...@forum.dlang.org

--

[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction

[via Digitalmars-d-bugs]

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

--- Comment #1 from Nick Treleaven  ---
Workaround is to add parameter names:

alias ls = (string s) => "string";
alias lc = (Red r) => "red";

--

[Issue 16655] New: lambda with type alias parameter fails std.traits.isSomeFunction

[via Digitalmars-d-bugs]

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

  Issue ID: 16655
   Summary: lambda with type alias parameter fails
std.traits.isSomeFunction
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

The static asserts below fail:

struct Color {struct Red {}}

unittest {
import std.traits;

alias ls = (string) => "string";
static assert(isSomeFunction!ls);

with (Color) {
alias lc = (Red) => "red";
static assert(isSomeFunction!lc);
}
}

If you define ls, lc like this it works:

alias ls = (immutable(char)[]) => "string";
alias lc = (Color.Red) => "red";

--

Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[safety0ff via Digitalmars-d]

On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei 
Alexandrescu wrote:


Last time I looked our associative arrays were arrays of 
singly-linked lists.


F.Y.I. It now appears to use quadratic probing since druntime PR 
#1229.




Each hashtable would have its own freelist, or alternatively 
all hashtables of the same types share the same freelist.


How do you return memory to the freelist when GC is expected to 
managed memory of the entries?


We no longer GC.free since your PR (#1143.)


Without belaboring the point, I think we'd better off with good 
library AA offerings as well.

Error: function std.stdio.setmode is not accessible from module a

[Kirill Kryukov via Digitalmars-d-learn]

Hello,

dmd 2.072.0 broke my project. I reduced it to following:

= a.d start =
import std.stdio;

void main()
{
setmode(stdin.fileno, 0x8000);
}
= a.d end =

Compiling on Windows 7 64-bit with the following commands:

C:\utl\dev\D\dmd-2.071.2\windows\bin\dmd.exe a.d -ofa1.exe
C:\utl\dev\D\dmd-2.072.0\windows\bin\dmd.exe a.d -ofa2.exe

The first one succeeds (producing a working executable), the 
second one fails with these messages:


a.d(6): Deprecation: std.stdio.setmode is not visible from module 
a
a.d(6): Error: function std.stdio.setmode is not accessible from 
module a


2.072.0 changelog does not seem to mention anything relevant. Is 
there something obvious I'm missing, or should I file a bug 
report?


Thanks,
Kirill

Re: is there "this"?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via 
Digitalmars-d-learn wrote:
> I tested already and it really works, thank you.
> I asked that because I tried once to use "this" in past but I got
> error. So I asked on some forum "how to get property of class?"
> and peoples said that I may use just a name of property. So I
> thought that there isn't "this" word.

I don't know why you were having trouble before, but I think that most
people never use an explicit this unless they need to, so plenty of folks
would have just told you to remove the this from you code, especially if it
worked without.

- Jonathan M Davis

Re: is there "this"?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 02, 2016 07:26:57 Bauss via Digitalmars-d-learn 
wrote:
> Well "this" in D has different meanings as it depends on its
> context sometimes.

Yes, but it's almost always the same thing that you'd expect from a language
like C++ or Java.

- Jonathan M Davis

Re: RC buffer

[Daniel9 via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.


The goal is to get the buffer @safe and be able to have a 
reasonable explanation for each and every cast. (There are no 
safety annotations currently, but the code passes unittests and 
supports qualifiers.) No undefined behavior casts should be 
used (e.g. that cast away immutability), only simple 
adjustments for realities that the type system is unable to 
cover.


In order to make opAssign safe, a language change will be 
necessary.



Andrei


Great goal, I wish you to do it!

Re: Got a post for the D Blog?

[Daniel9 via Digitalmars-d-announce]

On Monday, 31 October 2016 at 03:51:16 UTC, Mike Parker wrote:
So far, getting content for the blog has, with a few 
exceptions, been a process of sending out emails prompted by 
activity on my radar. This is no problem when it comes to 
project highlights or other fairly broad topics, but it's 
highly inefficient for ginning up technical posts on the 
implementation of specific algorithms, or optimization details, 
or how a D feature prevented a nuclear meltdown.


I want to publish more posts like Andreas's 'Find Was Too Damn 
Slow, So We Fixed It` [1] (which, by the way, is the 
most-viewed post so far, just ahead of Joakim's interview with 
Walter [2]), or Steven's 'How to Write @trusted Code in D' [3], 
but I need help.


If you, or someone you know, have done something interesting 
with an algorithm or optimization in D, or have used a D idiom 
to do things in a way that pleasantly surprised you, please let 
me know. If I think it's something we can work with, I'll help 
you in putting together a guest post, or something like I do 
with the project highlights (where I build a post around 
whatever info you give me).


Also, I need news. If you see or hear any D news anywhere 
outside of the forums -- new projects, research papers, usage 
at a company, a game using D -- please drop me a line. I'll 
either get a post together for it or make sure Adam knows about 
it for 'This Week in D'.


I'm also open to ideas for other types of posts, like project 
highlights, but I'd really like more of the technical stuff. 
Please send any suggestions to aldac...@gmail.com.


Thanks!

[1] 
http://dlang.org/blog/2016/06/16/find-was-too-damn-slow-so-we-fixed-it/
[2] 
http://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[3] 
http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/


It's excellent, thanks)

Re: is there "this"?

[Bauss via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 02:42:01 UTC, Konstantin 
Kutsevalov wrote:
On Wednesday, 2 November 2016 at 02:33:10 UTC, Konstantin 
Kutsevalov wrote:
On Wednesday, 2 November 2016 at 02:20:43 UTC, rikki 
cattermole wrote:

On 02/11/2016 3:17 PM, Konstantin Kutsevalov wrote:

[...]


You forgot an int in the arguments but otherwise that would 
work fine with your line uncommented.


yes I missed "int", but it's just an example.
so if I'll write "this.property = value" it will work?


I tested already and it really works, thank you.
I asked that because I tried once to use "this" in past but I 
got error. So I asked on some forum "how to get property of 
class?" and peoples said that I may use just a name of 
property. So I thought that there isn't "this" word.


Well "this" in D has different meanings as it depends on its 
context sometimes.

Re: Assistance with DUB

[Basile B. via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 22:01:23 UTC, Alfred Newman wrote:

Greetings,

I need some help with dub libraries.

Executing "dub list" in my machine, I got the following:

Packages present in the system and known to dub:
colorize ~master: 
C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\

...
sqlite-d ~master: 
C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d\
x11 1.0.15: 
C:\Users\Alfred\AppData\Roaming\dub\packages\x11-1.0.15\x11\


*** Note that sqlite-d is listed there.

When I try to run the code in the end of this thread, I got the 
following error:


compiling C:...\Projects\temp2.d
C:\Users\Alfred\Dropbox\Dlang\Projects\temp2.d(8,8): Error: 
module sqlited is in file 'sqlited.d' which cannot be read (***)

import path[0] = C:\D\dmd2\src\phobos
import path[1] = C:\D\dmd2\src\druntime\import
import path[2] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\source
import path[3] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d
import path[4] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\d2sqlite3-master\d2sqlite3\source

import path[5] = C:\D\dmd2\windows\bin\src\phobos
import path[6] = C:\D\dmd2\windows\bin\src\druntime\import
error: the process (dmd) has returned the signal 1
C:...\Projects\temp2.d has not been compiled

I'm stucked. Please, can you help me out ?


To compile a DUB script (It looks like you tried to do that) add 
this:


/+ dub.sdl:
   name "dub_script"
   dependency "sqlite-d" version="~>0.1.0"
+/

before the module declaration. It acts as a description.