Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"
On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
I don't agree with the current solution:
Well let's come up with a better solution then.
Let's start by finding some proper use-cases that require
introspection on private members w/o having access to them.
Use case that I think is pretty durn important: using
Allocator.make and forwarding a call to the private constructor
on a class.
This does not work now:
---
class A
{ int b; private this(int a){b=a;} }
auto ptr = make!A(Mallocator.instance, 42); // Compile Error!
---
Allocators are second class in this respect compared to GC.
Mixins aren't a good solution to this.
Re: DConf Videos
On Monday, 6 June 2016 at 16:22:18 UTC, Gary Willoughby wrote: Also, where are the DConf 2016 videos? I was under the impression that they would be released on YouTube? Unedited videos: http://www.ustream.tv/search?q=dconf+2016=all=all=anywhere
Re: Beta release DUB 1.0.0-beta.1
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote: DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for single-file packages So nice. Thanks so much! This is great for solutions to project euler problems!
Re: Using private constructor with std.experimental.allocater:make
On Sunday, 1 May 2016 at 19:18:38 UTC, Basile B wrote: CT make(CT, Alloc, A...)(auto ref Alloc al, A a) This works. Thank you. Good point about __ctor alone not being sufficient. auto memory = al.allocate(size); ... GC.addRange(memory.ptr, size, typeid(CT)); Nit: "GC.addRange..." -- this attempts to clean memory allocated manually. The problem is that the template make and emplace() are **elsewhere** so they cannot see A.this() (== A.__ctor). A common way to fix this kind of problem is to make a template mixin with the template that has the visibility and to mix it in the current scope I guess this is the best workaround at the moment. There's a discontinuity between the GC and std.allocators. "new A(1)" works, because the GC has implicit private access to classes. I would love to see allocators in wider use. Workarounds are an obstacle to this. Possible solutions: * Emulate c++'s "friend" keyword somehow. D's rationale eschew's this. * Somehow designate friendship via [selective] module import? * Secret upcoming solution from Walter/Andrei. Weren't they discussing some sort of built in ref counting system?
Using private constructor with std.experimental.allocater:make
Hello!
This code fails:
-
void main(){
class A
{ int b; private this(int a){b=a;} }
//{ int b; this(int a){b=a;} }
import std.conv:emplace;
import std.experimental.allocator.mallocator:Mallocator;
import std.experimental.allocator:make;
{
auto ptr = make!A(Mallocator.instance, 42);
assert (ptr.b == 42);
}
}
---
with error message:
"/usr/include/dmd/phobos/std/conv.d(4115): Error: static assert
"Don't know how to initialize an object of type A with arguments
(int)"
/usr/include/dmd/phobos/std/experimental/allocator/package.d(456):
instantiated from here: emplace!(A, int)
./helloworld.d(25):instantiated from here: make!(A,
shared(Mallocator), int)"
If I make the constructor public, no problem.
It seems that emplace (specialized for classes) doesn't work if
the class has a private constructor.
I added the following snippet to confirm:
--
{
auto ptr =
Mallocator.instance.allocate(__traits(classInstanceSize, A));
auto aPtr = emplace(ptr,34);
assert( aPtr.b == 34 );
}
--
And I get the same error message.
Google gave me:
http://forum.dlang.org/post/kot0t1$uls$1...@digitalmars.com
That guy's ultimate fix was explicitly calling the class's __ctor
method, instead of emplace. The __ctor method is undocumented, as
far as I can tell.
Is there a better solution now? More widespread use of allocators
will likely result in more of this problem.
Re: Some feedback on the website.
On Thursday, 17 December 2015 at 13:44:31 UTC, John Colvin wrote: On Thursday, 17 December 2015 at 11:47:23 UTC, Walter Bright wrote: On 12/16/2015 11:12 AM, H. S. Teoh via Digitalmars-d wrote: Having said that, though, using ddoc for the website leads to other problems (e.g., the ongoing fiasco with XREF, LREF, whatever-REF and the associated relative/absolute URL nightmare that a proper web authoring system would have taken care of by default). Annoying, and maybe you have to spend a couple minutes picking the right one if you've forgotten for the moment => absolute nightmare? Come on. How does a user who happens to spot a mistake in the docs and wants to help work this out? This is happening to me right now. I have a live editor open in github to edit the template doc page. I'm trying to link to std.traits and cannot find how. FULL_XREF is used on the same page, but I don't know what arguments it can accept.
Re: running D on AWS lambda
On Sunday, 13 March 2016 at 21:22:11 UTC, Laeeth Isharc wrote: http://awslambda-d.readthedocs.org/ http://code.dlang.org/packages/awslambda_d https://github.com/kaleidicpublic/awslambda_d This is great! Thanks so much.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote: What's new: Enjoy! Atila Thanks! What is the relevant link?
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Tuesday, 9 February 2016 at 17:07:15 UTC, earthfront wrote: On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote: What's new: Enjoy! Atila Thanks! What is the relevant link? First link on DuckGo: https://github.com/atilaneves/unit-threaded
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote: When you do `import std.string;` you expect it to just work, and you find std.string's docs easily from dmd. I'd love it if you could do `import thirdparty.independent;` and it magically works too - without even need for a configuration file or an install command. And the docs are right there and tutorials are written however the author feels like writing them. OMG I would love this. Often I write short scripts and use rdmd for rapid prototyping. Having to dub initialize and pull in libraries is a pain for this. Python got it right with their package manager(s)
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 20:56:39 UTC, Basile B. wrote:
This is not available in the grammar. You can still open a
duplicate enhancement request.
https://issues.dlang.org/show_bug.cgi?id=14704
see also:
http://forum.dlang.org/post/trrxoacvpyyqrdfqx...@forum.dlang.org
OK. I'm putting in my vote for this, and maybe even write up a
pull request.
The value from this comes when using "component-oriented"
programming, as touted by AA and WB:
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
The combination of the good practice of local selective imports,
and the use of various library functions to perform component
oriented programming, results in verbose local "import"
statements.
View the example below. The import section is nearly as dense as
the component oriented block doing the actual work. This is
smelly.
void main( string args[] )
{
import std.exception: enforce;
import std.array: array;
import std.algorithm.iteration: map,filter;
import std.string: removechars;
//..snip ..//
auto file = File( args[1] );
auto result =
file.byLineCopy( KeepTerminator.no, ',')
.array
.map!(a => removechars!string( a, "\"" ) )
.filter!isTriangleWord
.array
.length;
writeln("Number of triangle words: ", result);
}
Understandably, this isn't a huge priority, but a spot for
improvement none-the-less.
Dennis M. Ritchie's design in his comment seems to be the most
concise:
import {std.array:array; std.algorithm.iteration:map,filter};
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 11:12:22 UTC, ZombineDev wrote: Actually array() is from sts.array and correct way to use selective imports is: import std.exception : enforce; import std.array : array; import std.algorithm.iteration : filter; import std.functional : memoize; If you want to import several symbols from one module, you can list them after the column like so: import std.algorithm : any, find, sort /*, etc... */; I hadn't compiled yet, so the array thing is indeed an error. So there's no way to combine these _selective_ imports on a single line, like I can with regular _module_ imports: import std.exception, std.array, std.functional; Correct?
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 11:00:19 UTC, Jakob Ovrum wrote: On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote: Now I'm left with a smattering of lines which are just selective imports from a single module: import std.exception:enforce; import std.algorithm:array; import std.algorithm.iteration:filter; import std.functional:memoize; What is the proper way to combine these into one line? There's no `array` in std.algorithm, and I don't see more than one import per module in your example, but I'm guessing what you want is: import mod : a, b, c; // import a, b and c from mod Sorry, no, I didn't want that. I should have typed above: "I'm left with lines which are selective imports from various modules." My goal is to import several symbols from different modules on one line. I'm trying to figure out if it's possible or not. It makes the code more concise in some cases.
Multiple selective imports on one line
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt,
and Dscanner.
Upon saving files, it produces suggestions, much like warnings
from the compiler.
One suggestion is to use selective imports in local scopes. OK,
I'll do that.
Now I'm left with a smattering of lines which are just selective
imports from a single module:
void foo()
{
import std.exception:enforce;
import std.algorithm:array;
import std.algorithm.iteration:filter;
import std.functional:memoize;
//..Work..
}
What is the proper way to combine these into one line?
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? Fantastic. +1. The editable and runnable code on the existing homepage is a nice touch. That should find its way into the new homepage.
Re: std.array oddness
On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via Digitalmars-d-learn wrote: auto names = File(names.txt) .byLine!(char,char)(KeepTerminator.no, ',') .map!a.idup .array; Awesome. map!idup does the trick. I had looked at the byLine doc before posting, in particular, this line: Note: Each front will not persist after popFront is called, so the caller must copy its contents (e.g. by calling to!string) if retention is needed. This explains the behavior though I didn't get it then. It's talking about the range methods. Following the component based stuff from Walter's article can be brain-bendy. And in this case, requires careful reading of the docs. But I like it. Thanks!
std.array oddness
Hello!
I was attempting project euler problem 22 and seeing something
weird going on with the array function in std.array.
I made the following code to demonstrate.
Given names.txt:
--
MARY,PATRICIA,LINDA,BARBARA,ELIZABETH
--
and code:
--
import std.array,std.stdio;
void main()
{
{ // Correct
auto names = File(names.txt,r)
.byLine!(char,char)(KeepTerminator.no,',');
foreach(char[] name; names ){ writeln( name ); }
}
{ // Converting to array borks the thing
auto names = File(names.txt,r)
.byLine!(char,char)(KeepTerminator.no,',')
.array;
foreach( char[] name; names){ writeln( name ); }
}
}
--
I get the following output:
--
➜ euler rdmd ./stdArrayBug.d
MARY
PATRICIA
LINDA
BARBARA
ELIZABETH
ELIZA
ELIZABETH
ELIZAB
ELIZABET
ELIZABETH
--
Am I using array incorrectly?
I searched bugzilla and didn't see anything pertaining to this
issue.
Should I file a bug?
DMD64 D Compiler v2.066.1
Ubuntu Linux
Thanks!
