Re: code.dlang.org name collision

[Andre Pany via Digitalmars-d]

On Thursday, 21 December 2017 at 20:13:21 UTC, Steven 
Schveighoffer wrote:
I think currently on code.dlang.org, if you create a 
library/program for use, it uses the name you choose as a 
unique identifier for your project.


However, this seems rather open to abuse, or to unnecessary 
conflicts.


An example, I plan to have iopipe depend (eventually) on Martin 
Nowak's new io library listed here:


https://github.com/MartinNowak/io

But, there is already an "io" library in dub:

http://code.dlang.org/packages/io

This links to a stale project, 
https://github.com/jasonwhite/io, not updated since June 2016.


So what does this mean? Jason White's library gets to own the 
name "io" forever?


It's not fair to Jason, or anyone who links to his project to 
take it down or change it, but this also seems unfair to anyone 
who is willing to publish and maintain an io package of their 
own.


One of the most annoying things I found is that even if I 
add-local Martin's io repository to dub, it *still* wants to 
compile against the code.dlang.org library (this makes sense as 
we don't want hijacking, but the solution sucks, I have to use 
a modified version of Martin's dub.sdl file).


Regardless of this example, I'm sure you can see the dilemma 
here. Should we have an application/approval process for 
package names? Should we allow the same named packages on dub, 
but provide a way to disambiguate when specifying dependencies? 
Other ideas?


What do you all think?

-Steve

P.S. maybe there is already a solution in place for this, but 
I'm not seeing it.


Great you brought this to attention. During a technical code 
review for a XMake build plugin for D I was asked how a company 
can set the organization name in dub.json to avoid name clashes 
with Dub package names. Maybe we could also have a look how this 
is done in other languages npm/python,...


Kind regards
Andre

Re: dip1000 info web address

[crimaniak via Digitalmars-d]

On Friday, 22 December 2017 at 04:15:14 UTC, Mike Franklin wrote:

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

It was fast :)

Re: Proposal for a standard Decimal type in alpha

[Walter Bright via Digitalmars-d-announce]

On 12/21/2017 5:59 AM, Jack Stouffer wrote:
I just finished getting the type into an alpha version, and I wanted to solicit 
people's opinions on the API and if I'm heading in the right direction with this.


Thanks for doing this.

Your proposal would be enhanced a lot if it included a comparison with 
successful decimal packages in other languages, and why your solution is better!

Re: code.dlang.org name collision

[drug via Digitalmars-d]

22.12.2017 01:11, Steven Schveighoffer пишет:

On 12/21/17 4:55 PM, Walter Bright wrote:

I don't think existing names can be changed - too disruptive.

But moving forward, perhaps a reasonable solution is to require new 
packages added to dub to have at least a 6 character name, and it 
should not be something generic like "io", "file", "network", "time", 
etc.


Please bring this up with the dub maintainers.


https://github.com/dlang/dub/issues/1315

I had an idea based on WebFreak's suggestion:

If more than one person registers project "X", then you can depend on 
the earliest project via "X", but must use "username/X" to depend on 
other projects with the same name.


This would be backwards compatible. I'm assuming that you can't actually 
name a project "username/X" now, right?


-Steve
We should also consider provider's name - github, bitbucket, gitlab etc. 
Because there can be different (real) users with identical names.

Re: Don't expect class destructors to be called at all by the GC

[Neia Neutuladh via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
Even calling GC.collect directly did not guarantee the DB 
handle was closed at the right time.  This may have been a bug 
in my code that left dangling references to it, or perhaps the 
array of Database handles was still scanned through by the GC 
even though the only remaining array slice has a shorter 
length. Whatever the reason was, it left me with the very 
unpleasant prospect of silently accumulating file descriptor 
leaks.


Last I checked, the GC doesn't understand arrays. It only 
understands "segment of memory that might contain pointers" and 
"segment of memory that doesn't contain pointers". You might have 
gotten better results if you had nulled out the reference in the 
array.


Of course, that relies on not having any remaining references on 
the stack or in registers, neither of which is easy to guarantee.

Re: Answers needed from those using D for Web Development, Web APIs and Services

[bauss via Digitalmars-d]

On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:
I'm going to do a writeup on the state of D in Web Development, 
APIs and Services for 2017. I need the perspective of the 
community too along with my personal experience. Please help 
out. More details the better.


0. Since when did you or company start using D in this area?

1. Do you use a framework? Which one?

2. Why that approach and what would have done otherwise?

3. Which task exactly do you use D to accomplish?

4. Which (dub) packages do you use and for what purpose?

5. How do you host your software code (cloud platforms,  vps,  
PaaS, docker,  Openshift, kubernetes, etc)?


6. What are some constraints and problems in using D for such 
tasks?


7. What solutions do you recommend?


0. Since over a year ago, I mostly do freelancing with it, so 
just me really.


1. Diamond -- https://github.com/diamondmvc/diamond

2. Would have done nothing different.

3. Every project I do using D, I pretty much use D only, so all 
tasks necessary; big or small.


4. mysql-native, vibe.d and diamond.

5. I don't host any projects myself.

6. None so far, except for webservices like SOAP. (Although I'm 
planning on implementing that for Diamond -- Don't know when 
however.)


7. Depends on the task.

Re: Maybe D is right about GC after all !

[thedeemon via Digitalmars-d]

On Thursday, 21 December 2017 at 22:45:23 UTC, Neia Neutuladh 
wrote:
You can use mprotect(2) for write barriers, and that doesn't 
require compiler support. It's relatively inefficient, though.


As I understand it's prohibitively inefficient, that's why this 
approach is not used by any real world GC.


Without such help from the compiler you can't make anything 
decent, just a slow half-conservative GC that scans whole heap 
every time and leaks memory being unable to tell whether some 
stack value is a number or a pointer.


Numbers tend very much to be small, and pointer values tend not 
to be small, especially on 64-bit. So it shouldn't be that 
common to confuse the two. It should be more common to confuse 
floating point values for pointers, but the odds go down as 
address space increases.


Floating point values are also numbers, real numbers. ;)
Indeed in 64 bits our current GC is not too leaky. But still 
people encounter leaks occasionally, when trying to make long 
running services.


Actually, there's an idea. Instrument real-world code to 
determine what address ranges are least likely to be hit by a 
false pointer, then try to arrange the GC to concentrate 
allocations in those ranges.


I'm not sure all major OSs will let you choose freely address 
ranges when allocating memory.


D also offers better support for not allocating than Go. 
const/immutable to reduce defensive copies. 
std.experimental.allocator. GC.addRange for when you mix the GC 
with manually allocated memory.


Sure, carefully written D code has all the means to outperform Go.

Re: Don't expect class destructors to be called at all by the GC

[bauss via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 19:43:16 UTC, Steven 
Schveighoffer wrote:

On 12/20/17 9:57 PM, Mike Franklin wrote:

[...]


It's implementation defined :)

The gist is, you cannot expect that destructors will be run in 
a timely manner, or at all.


They may be called, and most of the time they are. But the 
language nor the current implementation makes a guarantee that 
they will be called.


For this reason, any classes that use non-memory resources 
should clean up those resources before becoming garbage. This 
is why most of the time, such items are managed by structs.


Note that the same non-guarantee exists in other GC'd 
languages, such as Java or C#.


-Steve


Except for that in C# you have the IDisposable interface, which 
can actually be used to prevent this kind of stuff and generally 
used to clean up non-GC memory.

Re: Maybe D is right about GC after all !

[thedeemon via Digitalmars-d]

On Thursday, 21 December 2017 at 22:11:26 UTC, Thomas Mader wrote:
D compiler also doesn't insert that bookkeeping code, so 
running code is fast as C but GC is slow and sloppy.


But for D it's planned to rewrite the GC to become something 
like the Go GC right?
The last attempt to do this was afaik a Google Summer of code 
project.


No, not like in Go. A few years ago there was a project 
implementing concurrent GC by forking the process and scanning 
the heap snapshot in parallel to the main process. It kinda 
worked but it's not portable, it won't work on Windows, so don't 
expect it to land into main D distribution and become an official 
GC.
There were other projects to improve current GC, make it more 
precise (but still not 100% precise) and optimize to some extent, 
but they don't bring substantial speed improvements, since the 
main scheme remains the same: no write barriers, scan whole heap 
every time and hope false pointers won't cause too much leaks.


Making the GC more like in Go and JVM means adding write 
barriers, it means making general code slower (we're not 
fast-as-C anymore), it means losing easy C compatibility (hello 
FFI!), it means forbidding many current language features like 
unions and casts, it means changing the language to something 
that's not D anymore.


So I think we can expect some minor improvements in GC, but 
nothing radical.

Re: can't run libuid examples

[bauss via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 18:41:28 UTC, greatsam4sure 
wrote:
I am having problem with running the examples of libuid on 
Windows and how to use libuid on a project without errors. I am 
using dmd version 2.076


Okay, but how are we supposed to help if you don't show us what 
errors you get?


Errors can depend on many things like your compiler-setup, paths, 
linker, your code, packages, compiler-flags and so on.

Re: dip1000 info web address

[Mike Franklin via Digitalmars-d]

On Friday, 22 December 2017 at 03:57:22 UTC, crimaniak wrote:

Hi all!

There is a string in DMD help message:

  -dip1000 implement http://wiki.dlang.org/DIP1000 
(experimental)


But in fact page http://wiki.dlang.org/DIP1000 is empty, and 
DIP100 information resides at the address 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Wrote it here because not sure if this is site problem (need to 
create DIP100 page in Wiki) or DMD problem (need to fix address)


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

Re: Answers needed from those using D for Web Development, Web APIs and Services

[Jonathan Marler via Digitalmars-d]

On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:
I'm going to do a writeup on the state of D in Web Development, 
APIs and Services for 2017. I need the perspective of the 
community too along with my personal experience. Please help 
out. More details the better.


0. Since when did you or company start using D in this area?


I converted 2 of my websites from PHP to D earlier this year.

http://clarityfitidaho.com
http://bobbiblu.net



1. Do you use a framework? Which one?


I use my own "cgi.d" framework to create cgi scripts in D that 
are served up by apache. 
(https://github.com/marler8997/mored/blob/master/more/cgi.d)  I 
started a project to replace apache for my applications, however, 
I have not finished or deployed it yet.




2. Why that approach and what would have done otherwise?


PHP is a nightmare.  I love the benefits of compiled languages, 
and D is both compiled and powerful enough to compete with 
dynamic languages like python/javascript/php.  Go would also be a 
good candidate, but without all the power of D that I've come to 
know and love, I feel like someone's cut off my legs when I 
program in it.




3. Which task exactly do you use D to accomplish?


In the web space, I use it to render web pages via cgi scripts, 
but I use D in many more areas outside of the web space.




4. Which (dub) packages do you use and for what purpose?


I don't use any dub packages.



5. How do you host your software code (cloud platforms,  vps,  
PaaS, docker,  Openshift, kubernetes, etc)?


I rent a debian server for $50 a month from serverpronto. I host 
a handful of websites on it and use it for other things as well.




6. What are some constraints and problems in using D for such 
tasks?


No complaints from me.  D works great especially on linux.



7. What solutions do you recommend?

Re: dip1000 info web address

[rikki cattermole via Digitalmars-d]

On 22/12/2017 3:57 AM, crimaniak wrote:

Hi all!

There is a string in DMD help message:

   -dip1000 implement http://wiki.dlang.org/DIP1000 (experimental)

But in fact page http://wiki.dlang.org/DIP1000 is empty, and DIP100 
information resides at the address 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Wrote it here because not sure if this is site problem (need to create 
DIP100 page in Wiki) or DMD problem (need to fix address)




DMD, a simple PR if you want to do it :)

Re: Answers needed from those using D for Web Development, Web APIs and Services

[Adam D. Ruppe via Digitalmars-d]

On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:

0. Since when did you or company start using D in this area?


I used D for web in 2009 until about 2013 for work, and then 
changed jobs and didn't get back into using D until this year.



1. Do you use a framework? Which one?


my own web.d


2. Why that approach and what would have done otherwise?


Libraries suck. I avoid them unless they are ubiquitous. Using 
traditional cgi meant it could go with a well-tested production 
server.



3. Which task exactly do you use D to accomplish?


everything server-side, json apis as well as html pages/form 
handling/websockets.



4. Which (dub) packages do you use and for what purpose?


none

5. How do you host your software code (cloud platforms,  vps,  
PaaS, docker,  Openshift, kubernetes, etc)?


on a linux server.

6. What are some constraints and problems in using D for such 
tasks?


Nothing serious. Compile time got a little slow (~14 seconds at 
one point) but some refactoring improved it.



7. What solutions do you recommend?


keep it simple to get work done.

dip1000 info web address

[crimaniak via Digitalmars-d]

Hi all!

There is a string in DMD help message:

  -dip1000 implement http://wiki.dlang.org/DIP1000 
(experimental)


But in fact page http://wiki.dlang.org/DIP1000 is empty, and 
DIP100 information resides at the address 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Wrote it here because not sure if this is site problem (need to 
create DIP100 page in Wiki) or DMD problem (need to fix address)

Re: Answers needed from those using D for Web Development, Web APIs and Services

[crimaniak via Digitalmars-d]

On Thursday, 21 December 2017 at 19:58:44 UTC, WebFreak001 wrote:

yes, I can see each response and export them to csv. I wanted
 I think if you can make csv with only answers related to WEB 
development it will be data relevant to what aberba wants.


to make a summary of the results but I don't really know where 
to start


  As for me, the main summary of results already is on the 
/viewanalytics page:


D User Survey
167 answers

D even much more marginal than I expected.

--
Узок их круг, страшно далеки они от народа

Re: Version Cygwin

[rikki cattermole via Digitalmars-d-learn]

On 21/12/2017 4:22 PM, Anonymouse wrote:
Cygwin is a reserved version[1], alongside Windows and linux and the 
like. However it doesn't seem to be automatically recognised.



import std.stdio;

void main()
{
    version(Cygwin) writeln("Cygwin");
}


Compiled from a Cygwin prompt this prints nothing. So I thought to add 
versions: [ "Cygwin" ] to dub.json, but dub refuses.



Error: version identifier `Cygwin` is reserved and cannot be set


Is there any way to force Cygwin or should I resign to creating an 
alternative lowercase "cygwin" version?


The use-case is to version stdout.flush() here and there to counter that 
the default Cygwin terminal (mintty) doesn't update when text is written 
to the terminal. I forget the reason why it doesn't.



[1]: https://dlang.org/spec/version.htm


You are not using a Cygwin build.
It doesn't matter who calls a process, it doesn't change the version's 
by itself.


As far as I know, nobody supports Cygwin like this.

[Issue 18113] New: E-mail attachments

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

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

  Issue ID: 18113
   Summary: E-mail attachments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: vino.bhee...@hotmail.com

Hi All,

 We are using D to to develop few system monitoring / alert tools, so request
you to add the feature of adding attachments to the e-mails to the library
std.net.curl SMTP, we know that there are other non Phobos repository which
contains this features but we intend to us only Phobos. 

From,
Vino.B

--

[Issue 18112] findSkip example in version 2.78 is not working are expected

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

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

Vino  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 18112] New: findSkip example in version 2.78 is not working are expected

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

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

  Issue ID: 18112
   Summary: findSkip example in version 2.78 is not working are
expected
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: vino.bhee...@hotmail.com

Hi,

 The example in the document for findSkip in version 2.078 is not working as
expected, throwing compliation error.

import std.ascii : isWhite;
string s = "abc";
assert(findSkip!isWhite(s) && s == "abc");
assert(!findSkip!isWhite(s) && s == "abc");

s = "  ";
writeln(findSkip!isWhite(s)); // 2
import std.stdio;
s = "  ";
findSkip!isWhite(s).writeln;

From,
VIno.B

--

Re: Fold in Parallelism

[Vino via Digitalmars-d-learn]

On Friday, 22 December 2017 at 00:18:40 UTC, Seb wrote:

On Friday, 22 December 2017 at 00:12:45 UTC, Vino wrote:
On Thursday, 21 December 2017 at 06:31:52 UTC, Ali Çehreli 
wrote:

[...]


Hi Ali,

Thank you very much, the pull request is in open state, so can 
you please let me know when can we can test the same.


From,
Vino.B


It will take a couple of days for this pull request to reach a 
ready form and to be approved. The best way to help it to move 
forward is to review it yourself or at least vote for it on 
GitHub ;-)
Once merged it will appear on dmd-nightly on the next day, but 
I'm not sure why you depend on his pull request?

Can't you just use the code directly?


Hi Seb,

  I am fine waiting for a couple of days for this pull request to 
reach to teh ready form and approved. Sure will vote on GItHub.


From,
Vino.B

[Issue 18111] New: unittests get different names depending on how the files are passed to dmd

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

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

  Issue ID: 18111
   Summary: unittests get different names depending on how the
files are passed to dmd
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

/tmp/foo.d:
void _() {
import dir1.dir2.bar;
pragma(msg, __traits(getUnitTests, dir1.dir2.bar));
}

/tmp/dir1/dir2/bar.d:
module dir1.dir2.bar;
unittest { }
void _() { pragma(msg, __traits(getUnitTests, dir1.dir2.bar)); }

When compiling foo.d:
/tmp % dmd -c -unittest foo.d   
tuple(__unittest_dir1_dir2_bar_d_2_0)

When compiling bar.d:
/tmp % dmd -c -unittest /tmp/dir1/dir2/bar.d
tuple(__unittest__tmp_dir1_dir2_bar_d_2_0)

The symbol names don't match and a linker error ensues. This prevents
__traits(getUnittests) from being used in certain separate compilation
scenarios.

--

Re: Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 23:08:22 UTC, Andre Pany wrote:

That are fantastic news. Thanks for working on this topic.
Is it possible to define a decimal type with a defined scale 
and precision?
From the examples and the documentation I am not sure whether 
it is possible.


Yes, the Hook template parameter currently controls how many 
significant digits your decimal can have and will eventually be 
able to control the min and max allowed exponents as well. By 
default, it's set at 9 digits, but you can have as many as 
int.max - 1 since it auto uses BigInt under the hood. Once your 
decimal has more than the allowed number of digits, it's rounded 
according to the Hook prescribed rounding method, which is half 
up by default.

unit-threaded v0.7.33

[Atila Neves via Digitalmars-d-announce]

http://code.dlang.org/packages/unit-threaded

Another release of unit-threaded, an advanced testing library for 
D. Changes since the last post to announce:


* Bug fixes.
* @Flaky UDA to rerun flaky tests. But really, fix the test 
instead!

* Property-based tests for user-defined types.
* Faster string property-based tests (ugh, auto-decoding).

Atila

Re: Don't expect class destructors to be called at all by the GC

[Mike Parker via Digitalmars-d-learn]

On Friday, 22 December 2017 at 00:09:31 UTC, Mike Franklin wrote:



What condition(s) would cause a destructor for an object that 
is managed by the GC to potentially not be called?




Here:

===
import std.stdio;

class Clazz {
~this() {
writeln("Class dest");
}
}

void makeClazz() {
auto clazz = new Clazz;
}

void main() {
makeClazz();
}

static ~this() {
writeln("Static dest");
}


This outputs:


Static dest
Class dest


The class destructor is not run during the lifetime of the 
program. The fact that it's run during runtime termination is an 
implementation detail. Another implementation might not run a 
finalization at termination.


So the destructors (finalizers) are only run when an object is 
collected. No collection, no destructor call.

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

"C, Python, Go, and the Generalized Greenspun Law"

http://esr.ibiblio.org/?p=7804


The question that remains, is how scalable and tunable is "D's GC 
implementation" to my programming needs (whatever they might 
happen to be).


It seems to me, that most GC implementations assume particular 
things about the environment in which they're operating, whereas 
I think that the programmer should be able to tell the GC about 
the environment in which it's operating, and the GC can adjust 
its parameter to that environment (e.g real time collection, 
generational collection, regional collection, etc...).


To the extent that a particular type of GC implementation forces 
its particular model onto the programmer, that I think, is a real 
limitation of GC.


That's why I believe manual memory management, much like the 
language C, will be around for a long time to come.

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Wednesday, 20 December 2017 at 18:28:20 UTC, Ali Çehreli wrote:
I think it's a psychological phenomenon worthy of scientific 
interest how a craft with so many guidelines can still be 
accepted.


Actually, the 'core guidelines' is itself a psychological 
phenomenon of interest, given that most people will mostly never 
read it.

excel-d v0.2.16 - now with more @Async

[Atila Neves via Digitalmars-d-announce]

excel-d lets you write plain D code that can be run from Excel 
unmodified via the magic of compile-time reflection.


Other than bug fixes, the main new feature since 0.2.15 is 
@Async. Slap it on a function like so:


@Async
double myfunc(double d) {
// ...
return ret;
}

And it will be executed in a separate thread. Useful for long 
running calculations / tasks so that they don't block the UI or 
other calculations in the worksheet.


Since the last time it was posted to announce, it also has these 
new features:


* `Any` variant type. When a D function needs to be passed more 
than one type of Excel value (e.g. string or double). This also 
works when a function takes arrays of `Any` such as `Any[]` or 
`Any[][]`.


* `std.datetime.DateTime` support. Declare one of the parameters 
as `DateTime`, type in a date in Excel and things just work.


* D functions/delegates can be registered to be run when the XLL 
is closed.


* D functions to be called from Excel no longer need to be 
`nothrow`.


Atila


Atila

Mir Random v0.3.0 release

[Nathan S. via Digitalmars-d-announce]

About package
--
Mir-Random [1] is a random number generator library that covers 
C++ STL [2]. It is compatible with mir.ndslice, std.algorithm, 
and std.range. In the same time mir.random has its own API, 
which is more secure and safe compared with std.random.


Release 0.3.0
--
You may find the release notes with hyperlinks more useful: 
https://github.com/libmir/mir-random/releases/tag/v0.3.0


Performance Increases
--
We now use Daniel Lemire's fast alternative to modulo reduction. 
Compiling with LDC 1.6.0 for x86-64, Mt19937_64 randIndex 
throughput increased 40% for uint and 136% for ulong. 
Xoroshiro128Plus randIndex throughput increased 73% for uint and 
325% for ulong.


The required mir-algorithm version has increased to v0.7.0 
because extMul is necessary for the ulong version.


New since v0.2.8
--
- New engine: SplitMix64 / Splittable64
- Convenience functions related to thread-local randoms: rne 
(like std.random rndGen); threadLocal!Engine for arbitrary 
engine; & ways of mucking about with the bookkeeping state that 
most people won't need but a few have requested in the past.
- Made some engines compatible with APIs that expect 
std.random-style UniformRNG. Compatible as-is: Xoroshiro128Plus; 
all predefined PCG engines; and the new SplitMix64/Splittable64 
engines. For any others there is an adaptor. Copy-constructors 
are disabled so they will only work with functions that "do the 
right thing" and take PRNGs by reference and don't make implicit 
copies of them.


Fixed since v0.2.8
--
- Changed many parts of the library to be @safe.
- Linux GETRANDOM in unpredictableSeed now works on 
non-x86/x86-64 architectures.
- Removed endian-dependency when producing 64-bit values from a 
native-32-bit PRNG.


Changed APIs
--
- The versions of genRandomBlocking/genRandomNonBlocking that 
take a pointer and a length are no longer @trusted. Instead there 
are trusted overloads for both that take a ubyte[].
- mir.random.algorithm has been changed in the interest of memory 
safety. You can still write unsafe code but now if you try to 
write @safe code the library will let you. Instead of taking 
engines by reference and storing their addresses (which could 
result in the stored address outliving the engine), now the 
various functions require arguments to be either objects or 
pointers to structs. For local-scoped engines there are templates 
with alias parameters. This is a major API change so 
feedback/criticism is welcome.


Links
--
[1] https://github.com/libmir/mir-random
[2] http://en.cppreference.com/w/cpp/numeric/random

[Issue 13255] static imports should be done lazily

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--

Re: Fold in Parallelism

[Seb via Digitalmars-d-learn]

On Friday, 22 December 2017 at 00:12:45 UTC, Vino wrote:
On Thursday, 21 December 2017 at 06:31:52 UTC, Ali Çehreli 
wrote:

On 12/19/2017 02:32 AM, Vino wrote:

> even though it is a simple code copy+paste

The change was a little more complicated than my naive 
adaptation from std.algorithm.fold. Here is the pull request:


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

Ali


Hi Ali,

Thank you very much, the pull request is in open state, so can 
you please let me know when can we can test the same.


From,
Vino.B


It will take a couple of days for this pull request to reach a 
ready form and to be approved. The best way to help it to move 
forward is to review it yourself or at least vote for it on 
GitHub ;-)
Once merged it will appear on dmd-nightly on the next day, but 
I'm not sure why you depend on his pull request?

Can't you just use the code directly?

Throwing away microseconds

[codephantom via Digitalmars-d]

Know what you're throwing away, when you throw away microseconds.

984 feet!

https://www.youtube.com/watch?v=9eyFDBPk4Yw=youtu.be

Re: Fold in Parallelism

[Vino via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 06:31:52 UTC, Ali Çehreli wrote:

On 12/19/2017 02:32 AM, Vino wrote:

> even though it is a simple code copy+paste

The change was a little more complicated than my naive 
adaptation from std.algorithm.fold. Here is the pull request:


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

Ali


Hi Ali,

Thank you very much, the pull request is in open state, so can 
you please let me know when can we can test the same.


From,
Vino.B

Re: Don't expect class destructors to be called at all by the GC

[Mike Franklin via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 19:43:16 UTC, Steven 
Schveighoffer wrote:


The gist is, you cannot expect that destructors will be run in 
a timely manner, or at all.


They may be called, and most of the time they are. But the 
language nor the current implementation makes a guarantee that 
they will be called.


I understand that we can't deterministically predict when a 
destructor will be called, but if we can't deterministically 
predict if a destructor will be called, that seems asinine.


What condition(s) would cause a destructor for an object that is 
managed by the GC to potentially not be called?


Thanks,
Mike

Re: No of threads

[Vino via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 00:32:50 UTC, codephantom wrote:

On Wednesday, 20 December 2017 at 13:41:06 UTC, Vino wrote:


Hi Ali,

 Thank you very much, below are the observations, our program 
is used to calculate the size of the folders, and we don't see 
any improvements in the execution speed from the below test, 
are we missing something. Basically we expected the total 
execution time for the test 2 , as the time taken to calculate 
the size of the biggest folder + few additional mins, the 
biggest folder size is of 604 GB.  Memory usage is just 12 MB, 
whereas the server has 65 GB and hardly 30% - 40% is used at 
any given point in time, so there is no memory constrain.




Are you running this over the network, or on (each) server that 
contains the actual folders?


Hi,

  Yes, the file system used is a NetApp file system mapped on 
Windows server.


From,
Vino.B

Re: No of threads

[Vino via Digitalmars-d-learn]

On Wednesday, 20 December 2017 at 17:31:20 UTC, Ali Çehreli wrote:

On 12/20/2017 05:41 AM, Vino wrote:

> auto TL = dFiles.length;
> auto TP = new TaskPool(TL);

I assume dFiles is large. So, that's a lot of threads there.

> foreach (d; TP.parallel(dFiles[],1))

You tried with larger work unit sizes, right? More importantly, 
I think all these threads are working on the same disk. If the 
access is serialized by the OS or a lower entity, then all 
threads necessarily wait for each other, making the whole 
exercise serial.


> auto SdFiles = Array!ulong(dirEntries(d,
SpanMode.depth).map!(a =>
> a.size).fold!((a,b) => a + b) (x))[].filter!(a => a  > Size);
> Thread.sleep(5.seconds);

You don't need that at all. I had left it in there just to give 
me a chance to examine the number of threads the program was 
using.


Ali


Hi Ali,

Below are the answers.

"I think all these threads are working on the same disk. If the 
access is serialized by the OS or a lower entity, then all 
threads necessarily wait for each other, making the whole  
exercise serial."


   The File system that is used here to scan and find the folder 
size is an NetApp File system mapped on Windows 2008. The file 
system is exported using NFS v3 so you are right that the disk 
access is serialized.


The no of folders are from 2 NetApp file system and no of folders 
in each file system is as below


File system 1 : 76 folders and File system 2: 77 folders.

You don't need that at all. I had left it in there just to give 
me a chance to examine the number of threads the program was 
using.


We have not update your main code yet, it was a test that we 
performed on test server.


From,
Vino.B

Re: Reorganization and list of D libraries (300+)

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 21:24:57 UTC, user1234 wrote:

"" to each url, e.g

click page 10: 
http://code.dlang.org/?sort=updated==180=20
then gotta to change it by hand to: 
http://code.dlang.org/?sort=updated==180=20


The query parameter is a hidden dev preview, meant to wait a 
little until we know that the ratings are adequate. It's actually 
about time to move forward with this feature.

https://github.com/dlang/dub-registry/pull/267

Re: Strange vibe.d build error

[H. S. Teoh via Digitalmars-d]

On Thu, Dec 21, 2017 at 10:04:29PM +, WebFreak001 via Digitalmars-d wrote:
> On Thursday, 21 December 2017 at 21:10:39 UTC, H. S. Teoh wrote:
> > After pulling from vibe.d git master today, my vibe.d project
> > doesn't compile anymore. `dub build` dies with:
> > 
> > /usr/src/d/vibe.d/stream/vibe/stream/memory.d(56,42): Error:
> > constructor vibe.utils.array.AllocAppender!(ubyte[],
> > ubyte).AllocAppender.this (IAllocator alloc, ubyte[] initial_buffer
> > = null) is not callable using argument types (IAllocator)
> > 
> > No idea where to even start looking, because the error message
> > doesn't make sense. The ctor is stated to take an IAllocator as
> > first parameter, and an optional second parameter defaulting to
> > null. So why does calling the ctor with an instance of IAllocator
> > fail?!
> > 
> > 
> > --T
> 
> have you tried `dub upgrade && dub build --force` yet and pulled potential
> submodules?

Hmm, that seemed to do the trick. Thanks!

But still, that error message is exceedingly unhelpful.  If possible I'd
love to track it down and file an enhancement to improve the error
message.


T

-- 
When solving a problem, take care that you do not become part of the problem.

Re: lld status

[Atila Neves via Digitalmars-d]

On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei 
Alexandrescu wrote:
I only became aware today about https://lld.llvm.org, llvm's 
own linker. I wonder how that changes distribution dynamics for 
us - I heard ldc already uses its embedded variant for linking 
programs (on Widows? Posix? 32bit? 64bit?). Can we distribute 
it as an alternative to optlink? Thanks! -- Andrei


I tried lld on Linux for D binaries and some of them crash. That 
might not mean anything on Windows, but given that I've run into 
2 dmd bugs so far in which picking one of ld.bfd or ld.gold 
produced crashing binaries, I'd be wary of using lld on Windows 
until it's thoroughly tested on dozens of executables.


Atila

Re: Don't expect class destructors to be called at all by the GC

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

On Thursday, 21 December 2017 at 18:48:38 UTC, H. S. Teoh wrote:

Alas, RefCounted doesn't work well with inheritance...


Oh?  What's the issue?


Implicit casts don't work so you can't pass a RefCounted!Class as 
RefCounted!Interface except in simple cases using alias this 
tricks.

Re: Proposal for a standard Decimal type in alpha

[Andre Pany via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
A couple of months ago, Andrei noted that a donor asked for a 
precise decimal type for D specifically: 
https://forum.dlang.org/post/osnema$d5s$1...@digitalmars.com. I've 
also heard this asked for many times, so I decided to start 
work on a library for eventual proposal to Phobos.


I just finished getting the type into an alpha version, and I 
wanted to solicit people's opinions on the API and if I'm 
heading in the right direction with this.


The dub page: https://code.dlang.org/packages/stdxdecimal

The docs: https://jackstouffer.github.io/stdxdecimal/

What you can do so far:

* Control behavior with a Hook type a-la 
std.experimental.checkedint

* Addition, subtraction, multiplication, division
* Construction from a strings and built-in number types

For the full list of planned features, see: 
https://github.com/JackStouffer/stdxdecimal


Please let me know what you think!


That are fantastic news. Thanks for working on this topic.
Is it possible to define a decimal type with a defined scale and 
precision?
From the examples and the documentation I am not sure whether it 
is possible.


Kind regards
Andre

Re: Maybe D is right about GC after all !

[Neia Neutuladh via Digitalmars-d]

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
A good GC requires the compiler to add special bookkeeping code 
to every pointer mutation in the heap, and to generate special 
data for each function to help GC find all the pointers in its 
stack and closures.


Precise stack scanning requires compiler support, yes.

You can use mprotect(2) for write barriers, and that doesn't 
require compiler support. It's relatively inefficient, though.


Without such help from the compiler you can't make anything 
decent, just a slow half-conservative GC that scans whole heap 
every time and leaks memory being unable to tell whether some 
stack value is a number or a pointer.


Numbers tend very much to be small, and pointer values tend not 
to be small, especially on 64-bit. So it shouldn't be that common 
to confuse the two. It should be more common to confuse floating 
point values for pointers, but the odds go down as address space 
increases.


Actually, there's an idea. Instrument real-world code to 
determine what address ranges are least likely to be hit by a 
false pointer, then try to arrange the GC to concentrate 
allocations in those ranges.


Go compiler includes that special bookkeeping, so the running 
code is a bit slower but GC can be fast, its GC can analyze 
heap concurrently, it can clean it by parts. With C you can't 
do that. D compiler also doesn't insert that bookkeeping code, 
so running code is fast as C but GC is slow and sloppy.


D also offers better support for not allocating than Go. 
const/immutable to reduce defensive copies. 
std.experimental.allocator. GC.addRange for when you mix the GC 
with manually allocated memory.


Go's only objective with its collector is to reduce the maximum 
pause time, and it's not bad at that. The JVM is going for low 
overhead with its default parameters, and you can muck about with 
it to prioritize low pause times; it's better than Go at both. D 
is currently going for predictability.

Re: Blog post: using dynamic libraries in dub

[Neia Neutuladh via Digitalmars-d-announce]

On Tuesday, 19 December 2017 at 21:38:40 UTC, Mike Wey wrote:
And for GtkD, that is why it would make sense to relay on the 
packages supplied by your distribution. And just list "gtkd-3" 
in the "libs" section. Avoiding the need for the workaround to 
build a shared version.


That would be awesome. I'm not able to access the d-apt 
repository at the moment and Ubuntu 16.04 doesn't seem to have 
gtkd in the repositories. So for the near future, at least, I'll 
continue using this cruddy workaround.

Re: Maybe D is right about GC after all !

[Thomas Mader via Digitalmars-d]

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
A good GC requires the compiler to add special bookkeeping code 
to every pointer mutation in the heap, and to generate special 
data for each function to help GC find all the pointers in its 
stack and closures. Without such help from the compiler you 
can't make anything decent, just a slow half-conservative GC 
that scans whole heap every time and leaks memory being unable 
to tell whether some stack value is a number or a pointer. Go 
compiler includes that special bookkeeping, so the running code 
is a bit slower but GC can be fast, its GC can analyze heap 
concurrently, it can clean it by parts. With C you can't do 
that. D compiler also doesn't insert that bookkeeping code, so 
running code is fast as C but GC is slow and sloppy.


But for D it's planned to rewrite the GC to become something like 
the Go GC right?
The last attempt to do this was afaik a Google Summer of code 
project.

Re: code.dlang.org name collision

[Steven Schveighoffer via Digitalmars-d]

On 12/21/17 4:55 PM, Walter Bright wrote:

I don't think existing names can be changed - too disruptive.

But moving forward, perhaps a reasonable solution is to require new 
packages added to dub to have at least a 6 character name, and it should 
not be something generic like "io", "file", "network", "time", etc.


Please bring this up with the dub maintainers.


https://github.com/dlang/dub/issues/1315

I had an idea based on WebFreak's suggestion:

If more than one person registers project "X", then you can depend on 
the earliest project via "X", but must use "username/X" to depend on 
other projects with the same name.


This would be backwards compatible. I'm assuming that you can't actually 
name a project "username/X" now, right?


-Steve

Re: run.dlang.io issues

[mermoldy via Digitalmars-d]

On Thursday, 21 December 2017 at 00:41:35 UTC, Seb wrote:

On Wednesday, 20 December 2017 at 23:03:48 UTC, mermoldy wrote:
The code execution on https://run.dlang.io/ fails with the 
following error:


docker: Error response from daemon: Failed to initialize 
logging driver: open 
/var/lib/docker/containers/76d5aa020af8591ec2bd72f3ef6aa329fca6c4669fa1c73e26dc1a76a07d760b/76d5aa020af8591ec2bd72f3ef6aa329fca6c4669fa1c73e26dc1a76a07d760b-json.log: no space left on device.


and after some time just:


Server error:


Please open issues at https://github.com/dlang-tour/core
Even though I'm not the maintainer of this server, I fixed the 
issue for now.

Thanks for the report!


ok. thanks

Re: Strange vibe.d build error

[WebFreak001 via Digitalmars-d]

On Thursday, 21 December 2017 at 21:10:39 UTC, H. S. Teoh wrote:
After pulling from vibe.d git master today, my vibe.d project 
doesn't compile anymore. `dub build` dies with:


	/usr/src/d/vibe.d/stream/vibe/stream/memory.d(56,42): Error: 
constructor vibe.utils.array.AllocAppender!(ubyte[], 
ubyte).AllocAppender.this (IAllocator alloc, ubyte[] 
initial_buffer = null) is not callable using argument types 
(IAllocator)


No idea where to even start looking, because the error message 
doesn't make sense. The ctor is stated to take an IAllocator as 
first parameter, and an optional second parameter defaulting to 
null. So why does calling the ctor with an instance of 
IAllocator fail?!



--T


have you tried `dub upgrade && dub build --force` yet and pulled 
potential submodules?

Re: code.dlang.org name collision

[Walter Bright via Digitalmars-d]

I don't think existing names can be changed - too disruptive.

But moving forward, perhaps a reasonable solution is to require new packages 
added to dub to have at least a 6 character name, and it should not be something 
generic like "io", "file", "network", "time", etc.


Please bring this up with the dub maintainers.

[Issue 5489] std.typecons tuples dynamically iterable

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

[Issue 5489] std.typecons tuples dynamically iterable

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

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

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

https://github.com/dlang/phobos/commit/059be4da3afe87bff6c8c37186c8fdef271f3388
Fix Issue 5489 - std.typecons tuples dynamically iterable

https://github.com/dlang/phobos/commit/0ba08bb6530ce84709f141645e2f6f28ab551813
Merge pull request #5953 from wilzbach/fix-5489

Fix Issue 5489 - std.typecons tuples dynamically iterable
merged-on-behalf-of: MetaLang 

--

Re: Reorganization and list of D libraries (300+)

[user1234 via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 20:22:05 UTC, Martin Nowak wrote:
On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:
Even being the wrong Martin :-) I think the DUB registry 
really needs more and better filters, so that the gems inside 
can be found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


That actually already landed in September.
https://github.com/dlang/dub-registry/pull/224
Try http://code.dlang.org/?showrating


The rating barely works; once i leave the front page from the 
link you give here i have to manually add


"" to each url, e.g

click page 10: 
http://code.dlang.org/?sort=updated==180=20
then gotta to change it by hand to: 
http://code.dlang.org/?sort=updated==180=20

Strange vibe.d build error

[H. S. Teoh via Digitalmars-d]

After pulling from vibe.d git master today, my vibe.d project doesn't
compile anymore. `dub build` dies with:

/usr/src/d/vibe.d/stream/vibe/stream/memory.d(56,42): Error: 
constructor vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender.this 
(IAllocator alloc, ubyte[] initial_buffer = null) is not callable using 
argument types (IAllocator)

No idea where to even start looking, because the error message doesn't
make sense. The ctor is stated to take an IAllocator as first parameter,
and an optional second parameter defaulting to null. So why does calling
the ctor with an instance of IAllocator fail?!


--T

Re: One liner for creating an array filled by a factory method

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/21/17 4:00 PM, kerdemdemir wrote:

I have a case like :

http://rextester.com/NFS28102

I have a factory method, I am creating some instances given some enums.
My question is about :


void PushIntoVector( BaseEnum[] baseEnumList )
{
     Base[] baseList;
     foreach ( tempEnum; baseEnumList )
     {
    baseList ~= Factory(tempEnum);
     }
}

I don't want to use "foreach" loop. Is there any cool std function that 
I can call ?


Something like baseEnumList.CoolStdFunc!( a=> Factory(a) )(baseList);



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

-Steve

Re: code.dlang.org name collision

[WebFreak001 via Digitalmars-d]

On Thursday, 21 December 2017 at 20:55:40 UTC, Steven 
Schveighoffer wrote:

On 12/21/17 3:42 PM, WebFreak001 wrote:

I don't think it should be removed, semver states versions 
must be immutable and never changed. Also there are guaranteed 
packages or programs depending on this which need it and 
future people wouldn't be able to build them if it was 
removed. Once registered they should stay registered forever 
imo, should just take a different name then


Obviously we can't remove or change the names of currently 
registered projects. That isn't an option.


But the result is that code.dlang.org will be full of projects 
like "betterxml" or "xml2" or "xml2018", because each developer 
abandons some work, and now it looks like a complete mess.


Imagine if github was this way, you couldn't name your project 
after any other persons project name! I don't see why we 
shouldn't be able to disambiguate between people's projects 
somehow, even specifying a dependency.


-Steve


well we have colons for subpackages, so we couldn't use those but 
maybe add / which adds an extra level of complexity and would 
require at least a dmd + ldc release including that dub version 
before pushing it to the website. Other than that I actually like 
that idea:


dependency "webfreak/fswatch" version="*"
dependency "webfreak/d2dgame" version="*"
dependency "webfreak/eventsystem" version="*"

One liner for creating an array filled by a factory method

[kerdemdemir via Digitalmars-d-learn]

I have a case like :

http://rextester.com/NFS28102

I have a factory method, I am creating some instances given some 
enums.

My question is about :


void PushIntoVector( BaseEnum[] baseEnumList )
{
Base[] baseList;
foreach ( tempEnum; baseEnumList )
{
   baseList ~= Factory(tempEnum);
}
}

I don't want to use "foreach" loop. Is there any cool std 
function that I can call ?


Something like baseEnumList.CoolStdFunc!( a=> Factory(a)  
)(baseList);


Erdem

Re: code.dlang.org name collision

[Steven Schveighoffer via Digitalmars-d]

On 12/21/17 3:42 PM, WebFreak001 wrote:

I don't think it should be removed, semver states versions must be 
immutable and never changed. Also there are guaranteed packages or 
programs depending on this which need it and future people wouldn't be 
able to build them if it was removed. Once registered they should stay 
registered forever imo, should just take a different name then


Obviously we can't remove or change the names of currently registered 
projects. That isn't an option.


But the result is that code.dlang.org will be full of projects like 
"betterxml" or "xml2" or "xml2018", because each developer abandons some 
work, and now it looks like a complete mess.


Imagine if github was this way, you couldn't name your project after any 
other persons project name! I don't see why we shouldn't be able to 
disambiguate between people's projects somehow, even specifying a 
dependency.


-Steve

Re: code.dlang.org name collision

[WebFreak001 via Digitalmars-d]

On Thursday, 21 December 2017 at 20:13:21 UTC, Steven 
Schveighoffer wrote:
I think currently on code.dlang.org, if you create a 
library/program for use, it uses the name you choose as a 
unique identifier for your project.


However, this seems rather open to abuse, or to unnecessary 
conflicts.


An example, I plan to have iopipe depend (eventually) on Martin 
Nowak's new io library listed here:


https://github.com/MartinNowak/io

But, there is already an "io" library in dub:

http://code.dlang.org/packages/io

This links to a stale project, 
https://github.com/jasonwhite/io, not updated since June 2016.


So what does this mean? Jason White's library gets to own the 
name "io" forever?


It's not fair to Jason, or anyone who links to his project to 
take it down or change it, but this also seems unfair to anyone 
who is willing to publish and maintain an io package of their 
own.


One of the most annoying things I found is that even if I 
add-local Martin's io repository to dub, it *still* wants to 
compile against the code.dlang.org library (this makes sense as 
we don't want hijacking, but the solution sucks, I have to use 
a modified version of Martin's dub.sdl file).


Regardless of this example, I'm sure you can see the dilemma 
here. Should we have an application/approval process for 
package names? Should we allow the same named packages on dub, 
but provide a way to disambiguate when specifying dependencies? 
Other ideas?


What do you all think?

-Steve

P.S. maybe there is already a solution in place for this, but 
I'm not seeing it.


I don't think it should be removed, semver states versions must 
be immutable and never changed. Also there are guaranteed 
packages or programs depending on this which need it and future 
people wouldn't be able to build them if it was removed. Once 
registered they should stay registered forever imo, should just 
take a different name then

Re: Reorganization and list of D libraries (300+)

[Martin Nowak via Digitalmars-d-announce]

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:
Even being the wrong Martin :-) I think the DUB registry really 
needs more and better filters, so that the gems inside can be 
found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


That actually already landed in September.
https://github.com/dlang/dub-registry/pull/224
Try http://code.dlang.org/?showrating

What's left now that search results are sorted by relevance, is 
more indexing so that we really find most packages for a search 
term.

https://github.com/dlang/dub-registry/pull/193

code.dlang.org name collision

[Steven Schveighoffer via Digitalmars-d]

I think currently on code.dlang.org, if you create a library/program for 
use, it uses the name you choose as a unique identifier for your project.


However, this seems rather open to abuse, or to unnecessary conflicts.

An example, I plan to have iopipe depend (eventually) on Martin Nowak's 
new io library listed here:


https://github.com/MartinNowak/io

But, there is already an "io" library in dub:

http://code.dlang.org/packages/io

This links to a stale project, https://github.com/jasonwhite/io, not 
updated since June 2016.


So what does this mean? Jason White's library gets to own the name "io" 
forever?


It's not fair to Jason, or anyone who links to his project to take it 
down or change it, but this also seems unfair to anyone who is willing 
to publish and maintain an io package of their own.


One of the most annoying things I found is that even if I add-local 
Martin's io repository to dub, it *still* wants to compile against the 
code.dlang.org library (this makes sense as we don't want hijacking, but 
the solution sucks, I have to use a modified version of Martin's dub.sdl 
file).


Regardless of this example, I'm sure you can see the dilemma here. 
Should we have an application/approval process for package names? Should 
we allow the same named packages on dub, but provide a way to 
disambiguate when specifying dependencies? Other ideas?


What do you all think?

-Steve

P.S. maybe there is already a solution in place for this, but I'm not 
seeing it.

Re: Answers needed from those using D for Web Development, Web APIs and Services

[WebFreak001 via Digitalmars-d]

On Tuesday, 19 December 2017 at 06:58:06 UTC, crimaniak wrote:

On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:
I'm going to do a writeup on the state of D in Web 
Development, APIs and Services for 2017. I need the 
perspective of the community too along with my personal 
experience. Please help out. More details the better.
I think some questions already answered in this survey 
https://forum.dlang.org/thread/hrtakvaqrhvayeidq...@forum.dlang.org


I wonder, it is possible to filter Google Forms result to see 
only results with relevant items in 'primary and secondary area 
of development' questions?


yes, I can see each response and export them to csv. I wanted to 
make a summary of the results but I don't really know where to 
start

Re: Don't expect class destructors to be called at all by the GC

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/20/17 9:57 PM, Mike Franklin wrote:

"Don't expect class destructors to be called at all by the GC"

I was a bit shocked to read that here: 
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors


The document tries to clarify with:
"The garbage collector is not guaranteed to run the destructors for all 
unreferenced objects."


Unfortunately, that doesn't really shed much light on this oddity.  So, 
specifically, under what circumstances are destructors not called?


It's implementation defined :)

The gist is, you cannot expect that destructors will be run in a timely 
manner, or at all.


They may be called, and most of the time they are. But the language nor 
the current implementation makes a guarantee that they will be called.


For this reason, any classes that use non-memory resources should clean 
up those resources before becoming garbage. This is why most of the 
time, such items are managed by structs.


Note that the same non-guarantee exists in other GC'd languages, such as 
Java or C#.


-Steve

Re: lld status

[kinke via Digitalmars-d]

On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei 
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking 
programs (on Widows? Posix? 32bit? 64bit?).


Currently only for Windows-MSVC targets (both 32 and 64 bits) and 
only when specifying the `-link-internally` switch. The host 
platform doesn't matter, i.e., it works for cross-linking from 
any Posix system too, even on ARM etc.
['Embedded variant' => we're linking in the static LLD libs and 
so share the common LLVM code in a single executable.]



Can we distribute it as an alternative to optlink?


Now that it's capable of outputting debuginfo .pdb's too (since 
v5.0, at least on Windows hosts), it should basically be fine.


There's one catch though, and that's the rather big size of the 
executable (26 MB for the v5.0.1 32-bit executable when linked 
against the static MS runtime with VS 2017, with enabled LLVM 
backends for x86[_64], ARM, AArch64 and Nvidia PTX).
That's due to LLD being a cross-linker by default, capable of 
outputting Windows, ELF and Mach-O binaries, and because of 
included codegen capabilities (for Link-Time Optimization), i.e., 
stuff that DMD doesn't need. Unfortunately, those features cannot 
be simply opted-out via CMake.

Re: lld status

[David Nadlinger via Digitalmars-d]

On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei 
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking 
programs (on Widows? Posix? 32bit? 64bit?)


Internal linking is currently enabled by a separate command-line 
flag; we still use the system linker by default (just as a 
precaution to avoid needless breakage because of a new feature).


lld works for COFF, ELF as well as Mach-O. For the latter, there 
is the problem of locating the appropriate C runtime libraries to 
consider, though (those that the `gcc` linker driver implicitly 
passes to the underlying `ld`).



Can we distribute it as an alternative to optlink?


Yes, that should work. As far as I know, it doesn't support OMF, 
though, so we would need to find COFF C/system libraries we can 
redistribute - it is unclear whether Microsoft's license allows 
redistribution of their static libraries.


 - David

Re: Don't expect class destructors to be called at all by the GC

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

On Thu, Dec 21, 2017 at 06:45:27PM +, Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
> > When the scoped destruction of structs isn't an option, RefCounted!T
> > seems to be a less evil alternative than an unreliable class dtor.
> > :-/
> 
> Alas, RefCounted doesn't work well with inheritance...

Oh?  What's the issue?


> Though, what you could do is make the refcounted owners and borrow the
> actual reference later.

Yeah, I figured that I pretty much have to use a proxy struct with
RefCounted, and have the struct dtor do the actual cleanup of the class
reference, something like:

class Resource {
void cleanup(); // inheritable
}
struct Proxy {
private Resource res;
this(Resource _res) { res = _res; }
~this() { res.cleanup(); }
}
...
auto obj = RefCounted!Proxy(allocateResource());


T

-- 
The problem with the world is that everybody else is stupid.

[Issue 17167] dmd fails to write to file or create directory with more than 248 characters in the path

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

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

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

https://github.com/dlang/dmd/commit/c22616ae6ea9c6832d4c261bc957149c2b265a98
Temporarily disable test for issue 17167 on CircleCi

https://github.com/dlang/dmd/commit/9b45aa736fd08eed3d20c41c5014f7ff68833bc0
Merge pull request #7486 from wilzbach/circleci-fix

Temporarily disable test for issue 17167 on CircleCi
merged-on-behalf-of: Petar Kirov 

--

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

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #2 from Andrei Alexandrescu  ---
I'd vote for this, but looks like voting has disappeared.

--

Re: Don't expect class destructors to be called at all by the GC

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

On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option, 
RefCounted!T seems to be a less evil alternative than an 
unreliable class dtor. :-/


Alas, RefCounted doesn't work well with inheritance...

Though, what you could do is make the refcounted owners and 
borrow the actual reference later.

can't run libuid examples

[greatsam4sure via Digitalmars-d-learn]

I am having problem with running the examples of libuid on 
Windows and how to use libuid on a project without errors. I am 
using dmd version 2.076

lld status

[Andrei Alexandrescu via Digitalmars-d]

I only became aware today about https://lld.llvm.org, llvm's own linker. 
I wonder how that changes distribution dynamics for us - I heard ldc 
already uses its embedded variant for linking programs (on Widows? 
Posix? 32bit? 64bit?). Can we distribute it as an alternative to 
optlink? Thanks! -- Andrei

Re: Don't expect class destructors to be called at all by the GC

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

On Thu, Dec 21, 2017 at 06:50:44AM +, Mike Parker via Digitalmars-d-learn 
wrote:
[...]
> I just don't even bother with class destructors. Without a guarantee
> that they can run and without any sort of deterministic behavior, it's
> really not appropriate to refer to them as destructors and they're
> about as useful as Java finalizers, which means not at all. In order
> to make them less error prone, we need to separate the concept of
> destruction from finalization and allow both destructors and
> finalizers. That's what I've taken to doing manually, by implementing
> a `terminate` function in my classes that I either call directly or
> via a ref-counted templated struct called Terminator.

I recently ran into this problem while using Adam Ruppe's lightweight
SQLite binding (arsd/sqlite.d). Originally, I kept an open database
handle (which is a class instance) throughout the lifetime of the
program; in this case, I could just use a scoped reference and it would
ensure the DB is closed when the handle went out of scope, just what I
want.  But as my code developed, I began to need to cache multiple DB
handles for performance, and scope no longer helps me there. At first I
thought, no problem, the GC would handle this for me. Right?

Wrong. Even calling GC.collect directly did not guarantee the DB handle
was closed at the right time.  This may have been a bug in my code that
left dangling references to it, or perhaps the array of Database handles
was still scanned through by the GC even though the only remaining array
slice has a shorter length. Whatever the reason was, it left me with the
very unpleasant prospect of silently accumulating file descriptor leaks.

I ended up calling .destroy on the class instance explicitly just so the
destructor would run at the right time, right before nulling the
reference so that the GC would collect the memory.

This makes using classes in D an even dimmer prospect than it already
generally is (nowadays, and I don't seem to be the only one, I prefer to
just use structs and templates instead of runtime polymorphism, where
possible).  When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an unreliable
class dtor. :-/


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

Re: Some thoughts about C and D, return data through parameters

[Nick Treleaven via Digitalmars-d]

On Tuesday, 19 December 2017 at 08:54:38 UTC, Petar Kirov 
[ZombineDev] wrote:
Reminds me of C#7's out variable declarations: 
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7#out-variables


However multiple return values are much better implemented 
through language-integrated tuples: 
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7#tuples


In D we don't have tuple unpacking syntax, but if we supported 
inline variable declarations for out arguments, we could do it 
with a library function:


void unpack(T, A...)(T tuple, out A args);
tuple(4, false).unpack(auto first, auto second);

Re: GUI program on Mac OS in D?

[mrphobby via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 15:45:32 UTC, Adam D. Ruppe 
wrote:

oh sorry i forgot to post this sooner here's my code so far.

when i'm reasonably happy with it, it will be part of my 
simpledisplay.d. I might leave it undocumented, but if you 
wanted to dive into my source the final version will be in 
there somewhere.


Thanks for sharing! Your solution is more complete for sure. I 
think I will borrow a few ideas here :)

Re: Maybe D is right about GC after all !

[Mark via Digitalmars-d]

On Thursday, 21 December 2017 at 13:27:55 UTC, Guillaume Piolat 
wrote:

[...]

There is also a downside to the C++ scoped owership wa: you 
have to find an owner for everything even if they are just 
memory. So small scripts in D will be written almost 2x faster 
because of that and rich stdlib.


Right. That's definitely a nuisance. It's probably also an issue 
in Rust with its "borrowing and ownership" apparatus.

Re: Maybe D is right about GC after all !

[Nick Treleaven via Digitalmars-d]

On Tuesday, 19 December 2017 at 11:30:14 UTC, ketmar wrote:
but Rikki, we have this! i'm using refcounted structs for 
years, and it works like a charm! ;-)


You can either have guaranteed memory-safe (due to DIP1000) but 
inefficient RC (due to extra runtime checks*), or efficient and 
not memory safe. That's why DIP74, DIP77 were created.


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

Re: It's possible to declare a variable inside a static foreach()?

[Seb via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 16:38:36 UTC, Anonymouse wrote:

On Thursday, 21 December 2017 at 16:25:00 UTC, Marc wrote:
For example, I'd like to declare a variable inside a static 
foreach like in below code, just for better organization, 
otherwise, I have to use the value directly instead of the 
variable. If the value is used more than once, it might be 
inviable.



enum allMembers = __traits(derivedMembers, C);
static foreach(enum string member; allMembers) {
		enum attributes = __traits(getAttributes, 
__traits(getMember, C, member));

static foreach(C c; attributes) {
writeln(c);
}
}


I got redefinition erros of "atributes" on this. Can I have 
this only at compile time?


I don't think you need static for foreach of __traits 
allMembers/derivedMembers and .tupleof. It unrolls at 
compile-time and builds fine for me if I just remove the 
statics. https://run.dlang.io/is/Ln3kVZ



/*static*/ foreach(C c; attributes)
Mind that c will not be of type C but of the type of the 
attribute.



The trick with static foreach is to create a new scope:

https://run.dlang.io/is/wODA0x

DIP1010 [1] suggested __local but while this is implemented, it 
it's not exposed yet.

There's also a bit of discussion about this at [2].

[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#local-declarations

[2] https://github.com/dlang/phobos/pull/5729

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

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

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

--- Comment #1 from Martin Nowak  ---
std.stdio.File.byLine:

Should be @safe as the internally used buffer is GC allocated, thus unexpected
mutation of an escaped line is possible, but cannot cause a memory corruption.

@safe function 'foo' cannot call @system function 'std.stdio.File.byLine!(char,
char).byLine'
@safe function 'foo' cannot call @system destructor
'std.stdio.File.ByLine!(char, char).ByLine.~this'

std.stdio.File.byLineCopy:

obviously

@safe function 'foo' cannot call @system function
'std.stdio.File.byLineCopy!(char, immutable(char)).byLineCopy'
@safe function 'foo' cannot call @system destructor
'std.stdio.File.ByLineCopy!(immutable(char), char).ByLineCopy.~this'

--

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

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

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

  Issue ID: 18110
   Summary: most of phobos should be @safe-ly useable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

Tracking issue for phobos entities that should be @safe, but currently aren't.

Let's reference per-module/package issues if someone goes on a fixing spree,
but first this issue is intended to collect such issues.

--

Re: It's possible to declare a variable inside a static foreach()?

[Anonymouse via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 16:25:00 UTC, Marc wrote:
For example, I'd like to declare a variable inside a static 
foreach like in below code, just for better organization, 
otherwise, I have to use the value directly instead of the 
variable. If the value is used more than once, it might be 
inviable.



enum allMembers = __traits(derivedMembers, C);
static foreach(enum string member; allMembers) {
		enum attributes = __traits(getAttributes, __traits(getMember, 
C, member));

static foreach(C c; attributes) {
writeln(c);
}
}


I got redefinition erros of "atributes" on this. Can I have 
this only at compile time?


I don't think you need static for foreach of __traits 
allMembers/derivedMembers and .tupleof. It unrolls at 
compile-time and builds fine for me if I just remove the statics. 
https://run.dlang.io/is/Ln3kVZ



/*static*/ foreach(C c; attributes)
Mind that c will not be of type C but of the type of the 
attribute.

It's possible to declare a variable inside a static foreach()?

[Marc via Digitalmars-d-learn]

For example, I'd like to declare a variable inside a static 
foreach like in below code, just for better organization, 
otherwise, I have to use the value directly instead of the 
variable. If the value is used more than once, it might be 
inviable.



enum allMembers = __traits(derivedMembers, C);
static foreach(enum string member; allMembers) {
		enum attributes = __traits(getAttributes, __traits(getMember, 
C, member));

static foreach(C c; attributes) {
writeln(c);
}
}


I got redefinition erros of "atributes" on this. Can I have this 
only at compile time?

Version Cygwin

[Anonymouse via Digitalmars-d-learn]

Cygwin is a reserved version[1], alongside Windows and linux and 
the like. However it doesn't seem to be automatically recognised.



import std.stdio;

void main()
{
version(Cygwin) writeln("Cygwin");
}


Compiled from a Cygwin prompt this prints nothing. So I thought 
to add versions: [ "Cygwin" ] to dub.json, but dub refuses.



Error: version identifier `Cygwin` is reserved and cannot be set


Is there any way to force Cygwin or should I resign to creating 
an alternative lowercase "cygwin" version?


The use-case is to version stdout.flush() here and there to 
counter that the default Cygwin terminal (mintty) doesn't update 
when text is written to the terminal. I forget the reason why it 
doesn't.



[1]: https://dlang.org/spec/version.htm

Re: Don't expect class destructors to be called at all by the GC

[12345swordy via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:

On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:

[...]



[...]



[...]


The root of the problem is that in D, class destruction and 
finalization are conflated. It would be much more accurate to 
refer to ~this in classes as a finalizer. Then this sort of 
confusion wouldn't be so widespread.


[...]


Have you considered writing a DIP on this?

Re: Who can make Phobos faster to import?

[Andrei Alexandrescu via Digitalmars-d]

On 12/20/2017 10:31 PM, Joakim wrote:

On Wednesday, 20 December 2017 at 18:21:33 UTC, Andrei Alexandrescu wrote:
A tool (call it depend - heh) to automate that would be awesome. For 
example, this run would make all imported names explicit:


depend --explicit *.d

This run would push all imports down to the innermost scope of usage:

depend --pushdown *.d


Andrei


I'm on it.  I tried using a version of Seb's frontend library yesterday 
but with the standard dmd main and tried running it on std.stdio, but it 
asserted in asmSemantic because of an asm block somewhere in druntime, 
so I'm back to using a tweaked full dmd with the backend simply disabled 
again:


https://github.com/dlang/dmd/pull/7425
https://github.com/dlang/dmd/blob/master/src/dmd/gluelayer.d#L47
https://gist.github.com/joakim-noah/09cf49bee3d82b03a54f

Once I have something basic working, I'll put it up on github, so others 
who are interested can play with it and pitch in to make it a real tool.


That's an awesome start, thanks! -- Andrei

Re: std way to remove multiple indices from an array at once

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/20/17 7:52 PM, Nicholas Wilson wrote:

On Thursday, 21 December 2017 at 00:23:08 UTC, Steven Schveighoffer wrote:

On 12/20/17 6:01 PM, aliak wrote:
Hi, is there a way to remove a number of elements from an array by a 
range of indices in the standard library somewhere?


I wrote one (code below), but I'm wondering if there's a better way?

Also, can the below be made more efficient?

auto without(T, R)(T[] array, R indices) if (isForwardRange!R && 
isIntegral!(ElementType!R) && !isInfinite!R) {

 T[] newArray;
 ElementType!R start = 0;
 foreach (i; indices) {
 newArray ~= array[start .. i];
 start = i + 1;
 }
 newArray ~= array[start .. $];
 return newArray;
}

// Usage
long[] aa = [1, 2, 3, 4]
aa = aa.without([1, 3])

Thanks!


I'm assuming here indices is sorted? Because it appears you expect 
that in your code. However, I'm going to assume it isn't sorted at first.


Now:

import std.range;
import std.algorithm;

auto indices = [1,2,3,4];
aa = aa.enumerate.filter!(a => !indicies.canFind(a[0])).map(a => 
a[1]).array;


Now, this is going to be O(n^2), but if indices is sorted, you could 
use binary search:


auto sortedIdxs = indices.assumeSorted; // also could be = indices.sort()

arr = arr.enumerate.filter!(a => !sortedIdxs.contains(a[0])).map(a => 
a[1]).array;


Complexity would be O(n lg(n))

It's not going to be as good as hand-written code, complexity wise, 
but it's definitely shorter to write :)




isn't that n log(m), where n is length of array and m is length of indices?


Strictly speaking, yes :) But lg(n) and lg(m) are going to be pretty 
insignificantly different.


If indices is sorted with no duplicates and random access then you can 
do it in linear time.


int i;
int ii;
int[] indicies = ...;
arr = arr.filter!((T t)
{
     scope(exit) i++;
     if (i == indicies[ii])
     {
     ii++;
     return false;
     }
     return true;
}).array;



Very nice! as aliak mentioned, however, you have a bug, as ii might 
extend beyond the size of indicies. So should be if(ii < indices.length 
&& indicies[ii] == i).


We are always focused on using a chained one-liner, but your lambda 
stretches that ;)


Here's a similar solution with an actual range:

https://run.dlang.io/is/gR3CjF

Note, all done lazily. However, the indices must be sorted/unique.

-Steve

Re: GUI program on Mac OS in D?

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

On Thursday, 14 December 2017 at 19:10:26 UTC, mrphobby wrote:
This looks pretty awesome and very much like something I was 
looking for. Would really appreciate if you could share your 
work. Otherwise I'll have to roll up my sleeves and try hacking 
it on my own :)


oh sorry i forgot to post this sooner here's my code so far.

when i'm reasonably happy with it, it will be part of my 
simpledisplay.d. I might leave it undocumented, but if you wanted 
to dive into my source the final version will be in there 
somewhere.



CODE MODULE

-
import helper_module;
import core.stdc.math;
import core.stdc.stdio;

void main() {
auto delegate_ = AppDelegate.alloc.init;
assert(delegate_, "AppDelegate null");

NSApp.delegate_ = delegate_;

NSApp.setActivationPolicy(NSApplicationActivationPolicy.regular);
NSApp.run();
}

@ObjCParentOverride("NSObject")
extern (Objective-C) interface AppDelegate : 
NSApplicationDelegate {


mixin IVar!(NSWindow, "window");
mixin IVar!(ViewController, "controller");

extern (C)
@ObjCMethodOverride("applicationShouldTerminateAfterLastWindowClosed:")
	static bool 
applicationShouldTerminateAfterLastWindowClosed(AppDelegate self, 
SEL sel, NSNotification notification) {

return true;
}

extern (C)
@ObjCMethodOverride("applicationDidFinishLaunching:")
	static void applicationDidFinishLaunching(AppDelegate self, SEL 
sel, NSNotification notification) {

NSApp.menu = mainMenu();

immutable style = NSWindowStyleMask.resizable |
NSWindowStyleMask.closable |
NSWindowStyleMask.miniaturizable |
NSWindowStyleMask.titled;

auto window = NSWindow.alloc.initWithContentRect(
NSMakeRect(10, 10, 300, 300),
style,
NSBackingStoreType.buffered,
false
);

window.title = "D Rox";

auto controller = ViewController.alloc.init;
window.contentView = controller.view;

window.center();

self.window = window;
self.controller = controller;

window.makeKeyAndOrderFront(null);
NSApp.activateIgnoringOtherApps(true);
}

// copy these two lines on any class
typeof(this) init() @selector("init");
mixin RegisterObjCClass;
}

extern (Objective-C) interface ViewController : NSViewController {
extern (C)
@ObjCMethodOverride("loadView")
static void loadView(ViewController self, SEL sel) {
printf("loadView\n");
}

extern (C)
@ObjCMethodOverride("viewDidLoad")
static void viewDidLoad(ViewController self, SEL sel) {
printf("viewDidLoad\n");
}

ViewController init() @selector("init");
mixin RegisterObjCClass;
}

NSMenu mainMenu() {
auto mainMenu = NSMenu.alloc.init("MainMenu".toNSString);

auto title = "Apple";
auto menu = NSMenu.alloc.init(title.toNSString);

	auto item = mainMenu.addItem(title.toNSString, null, 
"".toNSString);

mainMenu.setSubmenu(menu, item);

menu.addItem(NSMenuItem.alloc.init("Quit", "stop:", "q"));

return mainMenu;
}

-

HELPER MODULE:

-

version(OSX) {
/*  */
// Obj-C / Cocoa bindings and helpers
/*  */

// Special thanks to Jacob Carlborg
	// see: 
http://forum.dlang.org/thread/qzitebxwvavcfamsl...@forum.dlang.org


/// Add an instance var to an Obj-C subclass
mixin template IVar(T, string name) {
extern(D) final {
mixin("@IVarAttr T " ~ name ~ "() {
return this.ivar!(name, T);
}");

mixin("void " ~ name ~ "(T v) {
this.ivar!(name, T) = v;
}");
}
}

	/// Add to your extern(Objective-C) interfaces if you need the 
parent class to be different

/// from what in inherits from
struct ObjCParentOverride { string parentClassName; }

	/// Attach to a method like `extern(C) static R 
name(typeof(this) self, SEL sel, Args...)`

/// to give it a selector to override.
struct ObjCMethodOverride { string selector; }

	/// And mix this in to your subclasses of the 
extern(Objective-C) interfaces

mixin template RegisterObjCClass() {
mixin ClassTrait;

		private static objc_method method(alias imp, string selector, 
const char* type = null)() {
			return objc_method(sel_registerName(selector.ptr), type, 
cast(IMP) );

}

shared static this() {
  

Re: Write native GUI applications for Windows

[FrankLike via Digitalmars-d-learn]

On Monday, 18 December 2017 at 07:55:25 UTC, Andrey wrote:

Hello!
I have a question about creating native GUI applications for 
Windows 7 or/and Windows 10.


Hi,here is a very good native d gui lib,it's name is "dgui":   
https://github.com/FrankLIKE/DguiT/


I fork and modify ,let it work on DMD2.077 for win7 or win10.
It can make the x64 lib.

You can try it.

Injoy it.

Frank.

Re: GUI program on Mac OS in D?

[mrphobby via Digitalmars-d-learn]

On Thursday, 14 December 2017 at 19:10:26 UTC, mrphobby wrote:
On Thursday, 14 December 2017 at 14:07:25 UTC, Adam D. Ruppe 
wrote:
I was playing with this myself based on Jacob's code and made 
it look like this:


extern (Objective-C) interface ViewController : 
NSViewController {

extern (C)
@ObjCMethodOverride("loadView")
static void loadView(ViewController self, SEL sel) {
printf("loadView\n");
}

extern (C)
@ObjCMethodOverride("viewDidLoad")
static void viewDidLoad(ViewController self, SEL sel) {
printf("viewDidLoad\n");
}

ViewController init() @selector("init");
mixin RegisterObjCClass;
}

This looks pretty awesome and very much like something I was 
looking for. Would really appreciate if you could share your 
work. Otherwise I'll have to roll up my sleeves and try hacking 
it on my own :)


Ok, I finally had some time to work this out today. Thanks to the 
ideas posted here I was able to wrap something up despite my very 
limited knowledge of D and its compile time features :)


Basically this is what your classes will look like:

extern (Objective-C)
@ObjCSuperClass("NSObject")
interface AppDelegate : NSApplicationDelegate {
mixin ObjCClass;

AppDelegate init() @selector("init");

extern (C):

@ObjCMethod("applicationDidFinishLaunching:")
	static void applicationDidFinishLaunching(AppDelegate self, SEL 
sel, NSNotification notification) {

writefln("applicationDidFinishLaunching");
}
}

In this case I needed to add the explicit superclass attribute 
since NSApplicationDelegate is a protocol and not a class. If 
your object inherits from an interface representing a regular 
Objective-C class you don't need this.


The actual registration and setup principle is based on Jacobs 
code and I added stuff to handle the attributes. Obviously you 
need declarations for Objective-C runtime calls but you can find 
those in Jacobs example source as well.


Anyway, hope this helps. Feel free to fork and improve!
https://gist.github.com/mrphobby/a247deb15d38aea86b3346079f32ce58

Re: Don't expect class destructors to be called at all by the GC

[Mike Parker via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 14:26:55 UTC, Guillaume Piolat 
wrote:
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker 
wrote:
That's what I've taken to doing manually, by implementing a 
`terminate` function in my classes that I either call directly 
or via a ref-counted templated struct called Terminator.


I feel like I'm rambling but..
The problem with that approach is that you can't reuse Unique, 
RefCounted, scoped!T because they rely on .destroy


I'm not proposing it as a general solution. It's easy to 
implement and it works for my use case, so it's one possible 
solution.

[Issue 17680] Broken ddmd source links in documentation

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

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #8 from Seb  ---
Somehow the commits didn't close this issue :/
Anyhow it got broken during the ddmd -> dmd transition, but it's fixed on
master:

https://dlang.org/phobos-prerelease/dmd_access.html
https://dlang.org/phobos-prerelease/dmd_backend_cdef.html

And will be on stable soon.

--

Re: Blog post: using dynamic libraries in dub

[Guillaume Piolat via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 13:44:18 UTC, Benjamin Thaut 
wrote:
Ideally we should end up with visibility hidden being the 
default and only making symbols visible which use "export", 
because that is what it was designed for in the first place.


If this is an option, that would be really great.

[Issue 17789] Use a much more practical and beginner-friendly landing page on Dlang.org, integrating Dlang-Tour try-it-online examples

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 17777] broken link: Download D 2.076.0 => 403 Forbidden

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

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #3 from Seb  ---
Seems to be working fine for https://dlang.org/changelog/2.078.0.html

--

[Issue 18061] DDOC_MEMBER_ANCHOR is undocumented

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 18060] DDOC_MEMBER_HEADER is undocumented

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 18059] DDOC_MEMBER is undocumented

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 18104] Alias example compiles where it states that it should be illegal

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 18109] Spec should mention operator precedence

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp

--

Re: Don't expect class destructors to be called at all by the GC

[Guillaume Piolat via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
That's what I've taken to doing manually, by implementing a 
`terminate` function in my classes that I either call directly 
or via a ref-counted templated struct called Terminator.


I feel like I'm rambling but..
The problem with that approach is that you can't reuse Unique, 
RefCounted, scoped!T because they rely on .destroy

[Issue 5489] std.typecons tuples dynamically iterable

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

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com
   Assignee|nob...@puremagic.com|greensunn...@gmail.com

--- Comment #2 from Seb  ---
This already works if you combine .expand with std.range.only:

```
import std.algorithm, std.range, std.stdio, std.typecons;
auto t = tuple(1, 2);
t.expand.only.sum.writeln;
```

PR to add this as an example: https://github.com/dlang/phobos/pull/5953

--

Re: std way to remove multiple indices from an array at once

[aliak via Digitalmars-d-learn]

On Thursday, 21 December 2017 at 00:52:29 UTC, Nicholas Wilson 
wrote:
On Thursday, 21 December 2017 at 00:23:08 UTC, Steven 
Schveighoffer wrote:


I'm assuming here indices is sorted? Because it appears you 
expect that in your code. However, I'm going to assume it 
isn't sorted at first.


auto sortedIdxs = indices.assumeSorted; // also could be =

It's not going to be as good as hand-written code, complexity 
wise, but it's definitely shorter to write :)


-Steve
If indices is sorted with no duplicates and random access then 
you can do it in linear time.



Ah yes, I guess sorted and unique as well would be the expected 
input. But nice to see the handling of non-sorted indices.


I tried to search for an assumeUnique function as well (the 
assumeSorted one was nice to see) but it's not what I thought 
it'd be - seems to be more of an assumeUnaliased. And I guess 
there's no assumeUniqueElements.


And the filter approach is nice! :) (just need to account for the 
last ii++ (when filter comes back in I think one case would be ii 
== indices.length and you'd get a range error)


Thanks for the feedback!

Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

A couple of months ago, Andrei noted that a donor asked for a 
precise decimal type for D specifically: 
https://forum.dlang.org/post/osnema$d5s$1...@digitalmars.com. I've 
also heard this asked for many times, so I decided to start work 
on a library for eventual proposal to Phobos.


I just finished getting the type into an alpha version, and I 
wanted to solicit people's opinions on the API and if I'm heading 
in the right direction with this.


The dub page: https://code.dlang.org/packages/stdxdecimal

The docs: https://jackstouffer.github.io/stdxdecimal/

What you can do so far:

* Control behavior with a Hook type a-la 
std.experimental.checkedint

* Addition, subtraction, multiplication, division
* Construction from a strings and built-in number types

For the full list of planned features, see: 
https://github.com/JackStouffer/stdxdecimal


Please let me know what you think!