Class info on interfaces
I noticed the calling classinfo on an interface returns the class info
of the static type and not the dynamic type. Is that intentional?
Perhaps because of COM and C++ interfaces?
module main;
import std.stdio;
interface Foo {}
class Bar : Foo {}
void main()
{
Foo f = new Bar;
writeln(f.classinfo);
}
The above program will print the static type main.Foo instead of the
dynamic type main.Bar.
--
/Jacob Carlborg
multiline string literal with CRLF
Is there any way to input such a literal? Both `...` and qEOS...EOS do not allow escape sequences. I'm on Linux, but I need precisely CRLF, not just \n. -- Marek Janukowicz
Re: Should this compile?
On Tuesday, 25 August 2015 at 18:29:08 UTC, Vladimir Panteleev
wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
Thanks, this worked.
Filled it: https://issues.dlang.org/show_bug.cgi?id=14965
[Issue 14965] Forward reference to inferred return type of function call when using auto return type
https://issues.dlang.org/show_bug.cgi?id=14965
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #1 from timon.g...@gmx.ch ---
Minimal example:
auto foo(){ return foo(0); }
int foo(int x){ return x; }
(Also, the original post has a typo, I suspect main should do
writeln(test(a)).)
--
[Issue 14966] New: Comparing two std.xml.Document result in infinite recursion
https://issues.dlang.org/show_bug.cgi?id=14966 Issue ID: 14966 Summary: Comparing two std.xml.Document result in infinite recursion Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: d...@me.com --
Re: Should this compile?
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically rewrites the function declaration into an eponymous
template declaration. ...
No true. In fact, doing so manually works around the problem. :o)
This compiles and runs:
import std.stdio;
import std.range : chain;
auto test()(string a) {
return test(a,b);
}
auto test(string a,string b) {
return chain(a,b);
}
void main() {
writeln(test(a));
}
Re: Class info on interfaces
On 08/26/2015 11:59 AM, Adam D. Ruppe wrote: On Wednesday, 26 August 2015 at 18:53:19 UTC, Jacob Carlborg wrote: Is that intentional? Perhaps because of COM and C++ interfaces? Yes, exactly. COM and C++ things won't necessarily have a D TypeInfo available and since interfaces can be them, it can't be sure. What I do there is to just cast the interface to Object. Then you should check for null to cover those cases, then you can typeid or classinfo it. To complete, the documentation says .classinfo applied to an interface gives the information for the interface, not the class it might be an instance of. http://dlang.org/property.html#classinfo Ali
Re: Should this compile?
On 08/26/2015 09:55 PM, Timon Gehr wrote:
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically rewrites the function declaration into an eponymous
template declaration. ...
No true. In fact, doing so manually works around the problem. :o)
This compiles and runs:
import std.stdio;
import std.range : chain;
auto test()(string a) {
return test(a,b);
}
auto test(string a,string b) {
return chain(a,b);
}
void main() {
writeln(test(a));
}
Another workaround is to order the declarations in the opposite way:
import std.stdio;
import std.range : chain;
auto test(string a,string b) {
return chain(a,b);
}
auto test(string a) {
return test(a,b);
}
void main() {
writeln(test(a));
}
Re: multiline string literal with CRLF
anonymous wrote: Is there any way to input such a literal? Both `...` and qEOS...EOS do not allow escape sequences. I'm on Linux, but I need precisely CRLF, not just \n. I'm probably missing the point, but: Hello\r\nworld Or if you want to include the \n verbatim: Hello\r world Thanks, this works - I don't know how I did it the first time, because I definitely tried that and failed. The other solution by Adam also works - thanks. -- Marek Janukowicz
Re: Class info on interfaces
On Wednesday, 26 August 2015 at 18:53:19 UTC, Jacob Carlborg wrote: Is that intentional? Perhaps because of COM and C++ interfaces? Yes, exactly. COM and C++ things won't necessarily have a D TypeInfo available and since interfaces can be them, it can't be sure. What I do there is to just cast the interface to Object. Then you should check for null to cover those cases, then you can typeid or classinfo it.
Re: multiline string literal with CRLF
On Wednesday, 26 August 2015 at 18:28:02 UTC, Marek Janukowicz wrote: Is there any way to input such a literal? Both `...` and qEOS...EOS do not allow escape sequences. I'm on Linux, but I need precisely CRLF, not just \n. One way you could do it is to stick a .replace(\n, \r\n) to the end of the literal. If it is in a compile time context, it will CTFE its way to a new literal for you.
Re: multiline string literal with CRLF
On Wednesday 26 August 2015 20:28, Marek Janukowicz wrote: Is there any way to input such a literal? Both `...` and qEOS...EOS do not allow escape sequences. I'm on Linux, but I need precisely CRLF, not just \n. I'm probably missing the point, but: Hello\r\nworld Or if you want to include the \n verbatim: Hello\r world
[Issue 14965] New: Forward reference to inferred return type of function call when using auto return type
https://issues.dlang.org/show_bug.cgi?id=14965
Issue ID: 14965
Summary: Forward reference to inferred return type of function
call when using auto return type
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
import std.stdio;
import std.range : chain;
auto test(string a) {
return test(a, b);
}
auto test(string a, string b) {
return chain(a, b);
}
void main() {
writeln(test(a));
}
Ends with: Error: forward reference to inferred return type of function call
'test'
I know this exact sample is solvable by default parameter but there are cases
where it is not possible.
Workaround is discussed here:
http://forum.dlang.org/post/cyvekwuwskhexribc...@forum.dlang.org
--
[Issue 14967] New: std.xml.Tag doesn't include attributes in comparison
https://issues.dlang.org/show_bug.cgi?id=14967 Issue ID: 14967 Summary: std.xml.Tag doesn't include attributes in comparison Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: d...@me.com --
Re: associative arrays with manual memory management
On 24-Aug-2015 15:01, Ilya Yaroshenko wrote: http://code.dlang.org/packages/aammm/~master # aammm Associative arrays with manual memory management All enries and buckets would be dealocated and disposed by internal implementation's destructor. The destructor is called by garbage collector (by default). Rox! Example ```D //std.experimental.allocator is included into `aammm` import std.experimental.allocator.mallocator; import aammm; auto a = AA!(string, int, shared Mallocator)(Mallocator.instance); Sure hope a factory to do IFTI is available? So that the following works: auto a = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced a[foo] = 0; a.remove(foo); //dealocates and disposes the entry assert(a == null); // should not crash ``` -- Dmitry Olshansky
Re: associative arrays with manual memory management
On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: http://code.dlang.org/packages/aammm/~master It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA. Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)? I'm especially interested in using this for keys and values only with no indirections.
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. [...] Great news for D, this is a brave decision. I hope it'll push the language ahead. Congratulations
Re: associative arrays with manual memory management
On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: Nice! I'll try this! auto a = AA!(string, int, shared Mallocator) When does the third parameter need to be qualified as `shared`?
Re: Moving forward with work on the D language and foundation
On Wed, 2015-08-26 at 09:20 +, John Colvin via Digitalmars-d -announce wrote: […] Not a one man shop. Ilya Yaroshenko is helping a lot, Lars T Kyllingstad is on board (along with SciD) and there are many others who are getting involved in some way. Anyone else who's interested should come to https://gitter.im/DlangScience/public and get involved in the conversation there. Even just for marketing reasons, it would be better if the DlangScience team on GitHub was more than one person. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
MmFile : Is this std.mmFile BUG?
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Re: __traits(allMembers) and aliases
On 08/26/15 14:42, Mike Parker via Digitalmars-d-learn wrote: This doesn't help me distinguish aliased function names. [...] I don't want to put any restrictions on what the user can have in the module/class/struct that contains the function pointer. It's just that aliased function names pass both tests as they are synonyms for the functions they alias. If it's just about functions then you can check identity (the address obtained via the alias will be the same). That will also work for other non-tls objects. It won't work for tls objects because the compiler will (incorrectly) reject the equality check at CT. Because of D's implicit TLS in module and static scopes, a lot of objects will unintentionally be made thread local, so this solution won't be practical until the compiler limitation goes away, yes. artur
Re: MmFile : Is this std.mmFile BUG?
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Note that mmap-ing a zero-length range is invalid on Linux. Dunno
about OSX; it shouldn't segfault though.
Re: RAII and Deterministic Destruction
Thanks for the thorough response. I'm aware of some of what you explained. Maybe I should have asked differently. Rather than asking what RAII facilities do exist, I guess I was looking for the answer, Here's what you typically do in C++ RAII that you can't do in D. I could probably find out things by experimenting too (and not be too lazy). I just didn't want to rely on my assumptions only. For example, say object A is a member of object B which is in turn a member of object C. If C is deleted or goes out of scope, does the destructor of A get called? If all three are classes, obviously not. But if all three are structs? What if they are classes but are all managed by Unique? If I use Unique for all of my heap-allocated classes (as I would with std::unique_ptr in C++) am I assured of destructors being called when the owning classes get destructed? I'm wondering about these various nesting/owning combinations. Jim
Re: RAII and Deterministic Destruction
Thanks. I had not looked at some of those yet. Jim
Re: This Week in D summarizes those long threads for you!
On 26 August 2015 at 00:55, Laeeth Isharc via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Tuesday, 25 August 2015 at 21:43:11 UTC, Iain Buclaw wrote: The work done on GDC is well appreciated, GDC's codebase is much cleaner now than it was before the refactoring. True, and it will only get more cleaner as each section is rewritten. But no one personally congratulates you on refactoring code (I have been spearheading a push to remove all dmd-backend-isms from gdc. It took about 3 months work to make expression (toElem) codegen to be stateless, and remove the dmd-specific 'backend IR state' (IRState) struct from the codebase. And that is barely 1/8 of what needs to be done to prepare the move to 2.067) http://wiki.dlang.org/GDC/CurrentReleaseTasks How can we make it easier for people to show their appreciation? I appreciate very much your work on GDC, and I know that there is a general problem that people tend to focus on what's visible and not necessarily what's hidden but important. Maybe by coming to Berlin next year? :-) Actually, perhaps this might be something worth discussing in the D foundation thread? Iain
Re: RAII and Deterministic Destruction
Thanks for all the info. It's a good comparison of structs and classes to keep handy. Actually, I'm fine with the GC. I don't mean to avoid it. I just would like some way to also have non-memory resources automatically released in a timely, predictable way. One common thing to do in C++ is to manage the lifetime of an object with std::unique_ptr but then use its .get() function to get a native pointer to use temporarily. You just have to ensure that the native pointer doesn't outlive the unique_ptr, which isn't that difficult. True, if the unique_ptr gets destructed the native pointer is invalid and that could be risky, but you limit its use. Unique in D doesn't seem to have anything like a get() function but I wonder if it could. That is, it would get another native reference to the Unique resource that is managed by the garbage collector. So if the Unique went out of scope and got destructed, the reference would at least refer to valid memory although not a valid object because its destructor had already been called. Not perfectly safe, but no worse than the C++ case. Just a thought. Jim
Re: Adding UDA at compile time
On Wednesday, 26 August 2015 at 14:29:30 UTC, Andrea Fontana
wrote:
__traits(setAttributes, ...)
It would be useful, for example, if I have a list of functions
to mark. Let's say
enum toExport = [oldFunction, thisToo];
foreach(d; toExport) __traits(setAttributes, ...);
Lots of compile-time information is fixed after the symbol is
defined, making it effectively immutable. There's not, for
example, a `__traits(setType, var)`.
If you want to apply a UDA to many functions at once, you can use
the block syntax:
@(hello) {
void foo1() {}
void foo2() {}
}
// or alternatively
@(hello):
void foo3() {}
void foo4() {}
Also if you're talking about the `export` keyword, then that's
not a UDA.
[Issue 14968] New: Invalid mmfile length allowed on Linux
https://issues.dlang.org/show_bug.cgi?id=14968 Issue ID: 14968 Summary: Invalid mmfile length allowed on Linux Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: rs...@rsw0x.me From the linux manpage on mmap: ERRORS ... EINVAL (since Linux 2.6.12) length was 0. Default length is 0 for mmfile, and 0 is an accepted number. This should probably throw an exception. See: http://forum.dlang.org/post/ngampbtrlokkajksr...@forum.dlang.org --
Re: MmFile : Is this std.mmFile BUG?
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill wrote:
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Note that mmap-ing a zero-length range is invalid on Linux.
Dunno about OSX; it shouldn't segfault though.
https://issues.dlang.org/show_bug.cgi?id=14968
Re: Decrease number of front evaluations
On Wed, 26 Aug 2015 08:27:05 +, FreeSlave wrote: Are there ways to fix this? Should I consider writing my own range type probably? Check http://dlang.org/phobos/std_algorithm_iteration.html#.cache
Re: dpaste web site
On Wednesday, 26 August 2015 at 05:54:44 UTC, nazriel wrote: On Thursday, 20 August 2015 at 20:28:48 UTC, Steven Schveighoffer wrote: dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at version 2.065. -Steve I will work on it. Should be fixed before weekend. I will also open source dpaste frontend and backend so such problems can be avoided in the future. Got a little bit behind with D related stuff and auto-updates of DMD stopped working for some reason. That's why we are on 2.065. Regards, Damian Ziemba Probably stopped working because the downloads section of the website changed around that time iirc. Thanks for working on it!
Re: Decrease number of front evaluations
On Wednesday, 26 August 2015 at 08:30:04 UTC, Yazan D wrote: On Wed, 26 Aug 2015 08:27:05 +, FreeSlave wrote: Are there ways to fix this? Should I consider writing my own range type probably? Check http://dlang.org/phobos/std_algorithm_iteration.html#.cache I tried it. It can help with map (still calls 2 times though) but the number of filter's predicate calls stay the same.
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 06:50:26 UTC, Per Nordlöw wrote: On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: http://code.dlang.org/packages/aammm/~master It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA. Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)? EDIT: Plus I think to RefCountingAA. I'm especially interested in using this for keys and values only with no indirections.
Adding UDA at compile time
I wonder if there's a way to add UDA to functions at compile-time (so I can read later from other parts of application). Andrea
Re: Decrease number of front evaluations
On 08/26/2015 01:27 AM, FreeSlave wrote:
I would want to avoid redundant front evaluations.
Another option is std.functional.memoize:
import std.stdio;
import std.functional;
import std.algorithm;
import std.array;
void main()
{
auto r = [ 1, 2, 1 ]
.map!(memoize!(delegate(int a) {
writefln(map for %s, a);
return a;
}))
.filter!(memoize!(delegate(int a) {
writefln(filter for %s, a);
return a;
}));
r.each;
}
Although there are two 1s, the second one is not evaluated because the
result of the first one is used:
map for 1
filter for 1
map for 2
filter for 2
Ali
Decrease number of front evaluations
Example:
import std.stdio;
import std.algorithm;
import std.path;
import std.file;
import std.exception;
import std.getopt;
import std.array;
import std.range;
auto algo(string fileName, string[] dirs, string[] extensions)
{
return dirs.filter!(delegate(dir) {
bool ok;
collectException(dir.isDir, ok);
return ok;
}).map!(dir = extensions
.map!(delegate(ext) {
string path = buildPath(dir, fileName ~ ext);
writefln(Map: %s, path);
return path;
}).filter!(delegate(filePath) {
bool ok;
writefln(Check: %s, filePath);
collectException(filePath.isFile, ok);
return ok;
})
).joiner;
}
void main(string[] args)
{
string fileName;
string extensionsStr;
getopt(args,
fileName, file name to search without extension,
fileName,
extensions, list of extensions separated by ':',
extensionsStr
);
string[] dirs = args[1..$];
if (fileName.empty) {
stderr.writeln(File name not given);
return;
}
if (dirs.empty) {
dirs = [.];
}
string[] extensions = extensionsStr.splitter(':').array;
if (extensions.empty) {
extensions = [.d];
}
foreach(item; algo(fileName, dirs, extensions)) {
writefln(Found: %s, item);
}
}
When I run this it like this (assuming main.d exists):
main --fileName=main
It gives me:
Map: .\main.d
Check: .\main.d
Map: .\main.d
Check: .\main.d
Map: .\main.d
Check: .\main.d
Map: .\main.d
Found: .\main.d
In this simple example it calls map 4 times and filter 3 times.
The map transformer and filter predicate can be expensive, so I
would want to avoid redundant front evaluations.
The real code is more complicated and can be found here
https://github.com/MyLittleRobo/icontheme/blob/master/source/icontheme.d#L427
It can call filter's predicate with the same argument up to 8
times, which is not nice.
Are there ways to fix this? Should I consider writing my own
range type probably?
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 06:50:26 UTC, Per Nordlöw wrote: On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: http://code.dlang.org/packages/aammm/~master It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA. Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)? Yes, except constructor. To do not use constructor you can use `makeAA` and `disposeAA`. I'm especially interested in using this for keys and values only with no indirections.
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 06:41:41 UTC, Per Nordlöw wrote: On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: Nice! I'll try this! auto a = AA!(string, int, shared Mallocator) When does the third parameter need to be qualified as `shared`? Only if you would use a shared allocator like Mallocator or GCAllocator. I will add factory template like Dmitry suggested. auto a = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced Ilya
Re: Moving forward with work on the D language and foundation
On Wednesday, 26 August 2015 at 05:51:06 UTC, Dmitry Olshansky wrote: On 25-Aug-2015 23:04, bachmeier wrote: On Tuesday, 25 August 2015 at 19:29:06 UTC, Daniel Kozák wrote: I can't agree more. OK maybe I would add this https://twitter.com/kozzi11/status/636190895856091136 ;-) This is a big recent development for many: https://github.com/DlangScience I just hope our math experts will join this organization even if only to bump the numbers. Seeing a one-man shop for D science is kinda disappointing. Not a one man shop. Ilya Yaroshenko is helping a lot, Lars T Kyllingstad is on board (along with SciD) and there are many others who are getting involved in some way. Anyone else who's interested should come to https://gitter.im/DlangScience/public and get involved in the conversation there.
[Issue 14962] [REG2.068] compiler inference of attributes for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14962 Jack Applegame jappleg...@gmail.com changed: What|Removed |Added CC||jappleg...@gmail.com --
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 06:52:01 UTC, Dmitry Olshansky wrote: auto a = AA!(string, int, shared Mallocator)(Mallocator.instance); Sure hope a factory to do IFTI is available? So that the following works: auto a = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced Just added to master branch) Thanks!
[Issue 13889] mscoff32 libs not available
https://issues.dlang.org/show_bug.cgi?id=13889 --- Comment #5 from Martin Nowak c...@dawg.eu --- Can you please try this preview. https://dlang.dawg.eu/downloads/dmd.stable~fix13889/ --
Re: DWT fails to build with DMD 2.068.0
On 2015-08-26 10:59, Mike James wrote: Thanks Jacob, I can confirm the libraries and snippets build no problem. Awesome :) -- /Jacob Carlborg
[Issue 13889] mscoff32 libs not available
https://issues.dlang.org/show_bug.cgi?id=13889 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #6 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/installer/pull/142 --
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 10:48:11 UTC, Ilya Yaroshenko auto a = aa!(string, int)(Mallocator.instance); // 3rd CT highlights It would be nice to also see an example at https://github.com/arexeu/aammm that shows AA-usage in conjunction with some other allocator such as FreeList and add a note about the performance improvement this gives. In that case, would it be possible to have factory functions for AA that automatically derives allocator parameters from key and value type for specific allocators? What do you say?
Casting pointers
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but
that's obviously no guarantee that it's correct or will continue
to do so.
Is this correct code in D? And if not, what should I do instead
to cleanly and efficiently extract structured data from a
sequence of bytes?
import std.stdio;
struct data
{
int a;
int b;
}
void main()
{
byte[] x = [1, 2, 3, 4, 5, 6, 7, 8];
data* ptr = cast(data*)(x);
printf(%x %x\n, ptr.a, ptr.b);
}
Re: __traits(allMembers) and aliases
On Tuesday, 25 August 2015 at 12:06:08 UTC, Mike Parker wrote: Is there a way to determine whether a given symbol is an alias? Consider this: ``` module funcs; alias FuncPtr = void function(); @ChooseMe FuncPtr funcPtr; alias anotherName = funcPtr; ``` Handing this module off to __traits(allMembers), then checking for the UDA on each member, I can filter out FuncPtr just fine. Unfortunately, anotherName passes the test, but I don't want it to. Is there anyway I can distinguish the anotherName alias from funcPtr without tagging it with a UDA? I can't find any sort of isAlias trait anywhere. I've been doing work on this recently. As far as I can tell, there is no way to do this. The problem is that an alias behaves exactly like the thing being aliased since it's just a name replacement, so there are no giveaways like being unable to take its address like enums. Aliases are more or less invisible. Hence, having an isAlias trait would be a really good idea.
Re: __traits(allMembers) and aliases
On Tuesday, 25 August 2015 at 16:08:48 UTC, Rikki Cattermole
wrote:
\ While my memory especially at 4am is rusty here:
enum isVarDecl = __traits(compiles, {mixin(GOT ~ got;);});
Where GOT is assumed to be the string that you got from
__traits(allMembers.
It'll be true that it is a variable declaration. False for
anything else e.g. a type.
This doesn't help me distinguish aliased function names. The
ideal thing to do is simply to check isFunctionPtr and hasUDA. I
don't want to put any restrictions on what the user can have in
the module/class/struct that contains the function pointer. It's
just that aliased function names pass both tests as they are
synonyms for the functions they alias.
[Issue 14964] New: __traits(isAlias, foo)
https://issues.dlang.org/show_bug.cgi?id=14964 Issue ID: 14964 Summary: __traits(isAlias, foo) Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: aldac...@gmail.com Currently, there doesn't appear any way to distinguish traits tested on an alias and the symbol it aliases. ``` module funcs; alias FuncPtr = void function(); @ChooseMe FuncPtr funcPtr; alias anotherName = funcPtr; module foo; foreach(sym; __traits(getAllMembers, funcs)) // Call hasUDA, isFunctionPtr, etc... ``` Here, I want to single out funcPtr, but it's impossible as any test that is true for funcPtr is also true for anotherName. An isAlias trait would be quite helpful for this situation. --
Re: __traits(allMembers) and aliases
On Wednesday, 26 August 2015 at 11:20:40 UTC, Meta wrote: I've been doing work on this recently. As far as I can tell, there is no way to do this. The problem is that an alias behaves exactly like the thing being aliased since it's just a name replacement, so there are no giveaways like being unable to take its address like enums. Aliases are more or less invisible. Hence, having an isAlias trait would be a really good idea. +1 That's the first thing I was looking for. https://issues.dlang.org/show_bug.cgi?id=14964
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 14:21:41 UTC, Ilya Yaroshenko wrote: It is possible but not so useful, thought. Why is it not so useful? `AA!(...).Entry.sizeof` and `AA!(...).Entry.alignof` should be accessible from user code since v0.0.3 . They can be used to construct allocators. I will add example with FreeList. Great! Thanks!
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 12:10:17 UTC, Per Nordlöw wrote: highlights It would be nice to also see an example at https://github.com/arexeu/aammm that shows AA-usage in conjunction with some other allocator such as FreeList and add a note about the performance improvement this gives. In that case, would it be possible to have factory functions for AA that automatically derives allocator parameters from key and value type for specific allocators? What do you say? It is possible but not so useful, thought. `AA!(...).Entry.sizeof` and `AA!(...).Entry.alignof` should be accessible from user code since v0.0.3 . They can be used to construct allocators. I will add example with FreeList.
Re: Adding UDA at compile time
On Wednesday, 26 August 2015 at 14:01:00 UTC, Alex Parrill wrote:
On Wednesday, 26 August 2015 at 08:19:04 UTC, Andrea Fontana
wrote:
I wonder if there's a way to add UDA to functions at
compile-time (so I can read later from other parts of
application).
Andrea
What do you mean? UDAs are already specified at compile time.
@(hello)
void foo() {
}
static assert(__traits(getAttributes, foo)[0] == hello);
__traits(setAttributes, ...)
It would be useful, for example, if I have a list of functions to
mark. Let's say
enum toExport = [oldFunction, thisToo];
foreach(d; toExport) __traits(setAttributes, ...);
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 14:24:54 UTC, Per Nordlöw wrote: On Wednesday, 26 August 2015 at 14:21:41 UTC, Ilya Yaroshenko wrote: It is possible but not so useful, thought. Why is it not so useful? Because looks like allocators have different additional params, that dose not related to AA.
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 13:12:38 UTC, Per Nordlöw wrote: On Wednesday, 26 August 2015 at 09:20:33 UTC, Ilya Yaroshenko wrote: Only if you would use a shared allocator like Mallocator or GCAllocator. Are there cases where a non-shared version of Mallocator or GCAllocator is motivated? Mallocator and GCAllocator are always shared. Possibly D will have ThreadLocalGCAllocator in the future. If not could, maybe the shared-ness could be inferred? `aa` function just uses shared type for shared argument and vise versa. GCAllocator.instance and Mallocator.instance. are always shared.
Re: Adding UDA at compile time
On Wednesday, 26 August 2015 at 08:19:04 UTC, Andrea Fontana
wrote:
I wonder if there's a way to add UDA to functions at
compile-time (so I can read later from other parts of
application).
Andrea
What do you mean? UDAs are already specified at compile time.
@(hello)
void foo() {
}
static assert(__traits(getAttributes, foo)[0] == hello);
Re: Object.factory() and exe file size bloat
On 26 August 2015 at 15:14, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote: A MUCH better solution: T[] _d_arrayliteral(T)(size_t length) Also, isn't the typeinfo now stored by the GC so it can call the dtor? Perhaps that is done in the filling of the array literal, but I would be surprised as this is a GC feature. I only looked at 2.066.1, the runtime implementation did not pass the typeinfo to the GC. _d_arrayliteralTX eventually calls structTypeInfoSize() which, according to https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214, is used to determine the size of TypeInfo so it can be stored by the GC, as Steven said. Mike Well, I have no control over what the library maintainers in DMD want to do in their runtime, but all is working fine without doing that in my camp.
[Issue 14953] std.concurrency: Add function to flush message box
https://issues.dlang.org/show_bug.cgi?id=14953 --- Comment #3 from Chris wend...@tcd.ie --- I understand your concerns regarding data flow. However, it's up to the user (programmer) to determine whether or not the pending messages are relevant. A use case: a text-to-speech synthesizer that has several sentences in the queue (e.g. reading out a document's content sentence by sentence or spelling out a word letter by letter). When the user presses a button to cancel the speech, the remaining items in the queue that haven't been spoken yet should be flushed immediately, which is the desired behavior, else the user would have pressed pause. I'm sure there are other use cases. If the API is flexible enough to offer a mechanism for both an immediate and a selective (filtered) flush, as you suggested, I think we're on the safe side. We should definitely have a method with a filter too. --
Re: RAII and Deterministic Destruction
A serious bug affecting RAII is https://issues.dlang.org/show_bug.cgi?id=14903, but apparently its importance hasn't been properly acknowledged yet. Improving the performance of binaries produced by dmd's backend is obviously way more important than fixing serious bugs or commenting on related PRs.
Re: dpaste web site
On Wednesday, 26 August 2015 at 05:54:44 UTC, nazriel wrote: On Thursday, 20 August 2015 at 20:28:48 UTC, Steven Schveighoffer wrote: dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at version 2.065. -Steve I will work on it. Should be fixed before weekend. I will also open source dpaste frontend and backend so such problems can be avoided in the future. Nice Got a little bit behind with D related stuff and auto-updates of DMD stopped working for some reason. There is an API now to get the latest version. http://ftp.digitalmars.com/LATEST And you can get the necessary package generically via http://downloads.dlang.org/releases/2.x/$LATEST/dmd.$LATEST.linux.zip.
Re: associative arrays with manual memory management
On Wednesday, 26 August 2015 at 09:20:33 UTC, Ilya Yaroshenko wrote: Only if you would use a shared allocator like Mallocator or GCAllocator. Are there cases where a non-shared version of Mallocator or GCAllocator is motivated? If not could, maybe the shared-ness could be inferred?
Re: Object.factory() and exe file size bloat
On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote: A MUCH better solution: T[] _d_arrayliteral(T)(size_t length) Also, isn't the typeinfo now stored by the GC so it can call the dtor? Perhaps that is done in the filling of the array literal, but I would be surprised as this is a GC feature. I only looked at 2.066.1, the runtime implementation did not pass the typeinfo to the GC. _d_arrayliteralTX eventually calls structTypeInfoSize() which, according to https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214, is used to determine the size of TypeInfo so it can be stored by the GC, as Steven said. Mike
Re: Casting pointers
On Wednesday 26 August 2015 14:14, John Burton wrote:
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but
that's obviously no guarantee that it's correct or will continue
to do so.
Is this correct code in D? And if not, what should I do instead
to cleanly and efficiently extract structured data from a
sequence of bytes?
import std.stdio;
struct data
{
int a;
int b;
}
void main()
{
byte[] x = [1, 2, 3, 4, 5, 6, 7, 8];
data* ptr = cast(data*)(x);
printf(%x %x\n, ptr.a, ptr.b);
}
There's an open issue about it:
https://issues.dlang.org/show_bug.cgi?id=10750
I don't know where we stand exactly, but by the looks of it, strict aliasing
has never been added to the spec. So compilers should not assume it.
As David Nadlinger points out: There is already quite a lot of D code out
there that violates the C-style strict aliasing rules.
I think that code should be fine for now. If it isn't, we have a problem,
because with a silent spec we have no way of knowing what alternatives
should work.
Re: Should this compile?
On Wednesday, 26 August 2015 at 20:02:35 UTC, Timon Gehr wrote:
Another workaround is to order the declarations in the opposite
way:
import std.stdio;
import std.range : chain;
auto test(string a,string b) {
return chain(a,b);
}
auto test(string a) {
return test(a,b);
}
void main() {
writeln(test(a));
}
It's definitely a bug if the code is dependent on order of
declaration.
Re: Russian-speaking community
On Friday, 21 August 2015 at 20:06:46 UTC, Andre Polykanine wrote: Cool, but could you please make your captcha accessible without Andre, I do not understand what is wrong with captcha? Write a Russian, it will be better :)
[Issue 14969] New: cannot evaluate atan at compile time
https://issues.dlang.org/show_bug.cgi?id=14969 Issue ID: 14969 Summary: cannot evaluate atan at compile time Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: yosik...@altalk.com import std.math; enum foo = atan(1.0); above code failed to compile using DMD32 D Compiler v2.068.0 Building Debug\T38DTest.exe... C:\APP\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(1135): Error: asm statements cannot be interpreted at compile time C:\APP\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(1023):called from here: atan2(x, 1.0L) C:\APP\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(1087):called from here: atan(cast(real)x) main.d(2):called from here: atan(1.0) --
[Issue 14969] cannot evaluate atan at compile time
https://issues.dlang.org/show_bug.cgi?id=14969 yosik...@altalk.com changed: What|Removed |Added CC||yosik...@altalk.com --
Re: linking-in libs under linux needed and not under windows
On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote: So the Q: Is this difference normal ? Yes, it is a feature the Windows format supports but the Linux one doesn't. On Linux, you need to list the libraries on the command line again.
Re: linking-in libs under linux needed and not under windows
On Thursday, 27 August 2015 at 03:17:57 UTC, BBasile wrote: On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote: So the Q: Is this difference normal ? the win OMF linux COFF thing maybe ? If I understand your problem description correctly, the culprit is likely the order in which the libraries are passed to the linker. The way the GNU linker works requires any library X that depends on any library Y to be placed before library Y on the command line. So, given your example, if libB uses symbols from libA, then it needs to come before libA on the command line. dmd sourceProject.d -L-lB -L-lA -IpathToSourceA -IpathToSourceB You can also see this when you use the pragma(lib) feature, as dmd passes the libraries to the linker in the order in which it found the pragmas.
Re: linking-in libs under linux needed and not under windows
On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote: So the Q: Is this difference normal ? the win OMF linux COFF thing maybe ?
Re: Moving forward with work on the D language and foundation
On 26-Aug-2015 12:20, John Colvin wrote: On Wednesday, 26 August 2015 at 05:51:06 UTC, Dmitry Olshansky wrote: On 25-Aug-2015 23:04, bachmeier wrote: On Tuesday, 25 August 2015 at 19:29:06 UTC, Daniel Kozák wrote: I can't agree more. OK maybe I would add this https://twitter.com/kozzi11/status/636190895856091136 ;-) This is a big recent development for many: https://github.com/DlangScience I just hope our math experts will join this organization even if only to bump the numbers. Seeing a one-man shop for D science is kinda disappointing. Not a one man shop. Ilya Yaroshenko is helping a lot, Lars T Kyllingstad is on board (along with SciD) and there are many others who are getting involved in some way. Anyone else who's interested should come to https://gitter.im/DlangScience/public and get involved in the conversation there. All of you guys should be displayed here on the right: https://github.com/DlangScience Else it's a very bad marketing. -- Dmitry Olshansky
Re: MmFile : Is this std.mmFile BUG?
On Wednesday, 26 August 2015 at 22:07:01 UTC, rsw0x wrote:
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill
wrote:
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Note that mmap-ing a zero-length range is invalid on Linux.
Dunno about OSX; it shouldn't segfault though.
From OS X 10.10.3 manage on mmap:
ERRORS
...
[EINVAL] The len argument was negative.
append to https://issues.dlang.org/show_bug.cgi?id=14968
thanks.
linking-in libs under linux needed and not under windows
let's say i have 'libA', 'libB' and 'Project' - libB uses libA - Project uses libB under Windows (32 bit, OMF objects, Digital Mars linker, so the standard setup): - * libA is compiled with: dmd sourceA.d -lib * libB is compiled with: dmd sourceB.d -lib -IpathToSourceA * Project is compiled with: dmd sourceProject.d libA.lib libB.lib -IpathToSourceA -IpathToSourceB and it just works fine under Linux (64 bit, also the standard setup): --- The same procedure fails with some messages (undefined this and that...) but if i link incrementaly (so i link libA in libB) it works: * libA is compiled with: dmd sourceA.d -lib * libB is compiled with: dmd sourceB.d libA.a -lib -IpathToSourceA * Project is compiled with: dmd sourceProject.d libA.a libB.a -IpathToSourceA -IpathToSourceB So the Q: Is this difference normal ? Why I ask this ? The problem is that I've made a change to Coedit recently that is based on the way it works on Windows: https://github.com/BBasile/Coedit/blob/master/src/ce_nativeproject.pas#L373 That does that: libraries files are only passed when the output binary must contain everything (so an executable). The problem is verified with a lib which uses two Derelict libs that use themselves DerelictUtil...I could just put a compiler switch in the .pas source to have the right behaviour according to the platform but i'd like an explanation...this difference looks weird.
[Issue 14968] Invalid mmfile length allowed on Linux
https://issues.dlang.org/show_bug.cgi?id=14968 Junichi Nakata nak...@sb.ecei.tohoku.ac.jp changed: What|Removed |Added CC||nak...@sb.ecei.tohoku.ac.jp --- Comment #1 from Junichi Nakata nak...@sb.ecei.tohoku.ac.jp --- From OS X 10.10.3 manage on mmap: ERRORS ... [EINVAL] The len argument was negative. --
