Re: getters and setters not an lvalue
On 2012-10-31 23:48, Adam D. Ruppe wrote: I tried it and found getting almost there is easy... but getting it to work in a bunch of edge cases is incredibly difficult. I can imagine operator overloading, opDispatch and similar features making it a lot harder. -- /Jacob Carlborg
Re: About demangling
On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: On Oct 11, 2012, at 6:17 AM, Lubos Pintes lubos.pin...@gmail.com wrote: Hi, Can someone point me to some source with information about name demangling when compiling some D program and the famous linker error 42 appears? Filter the symbol names through core.demangle. We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d Does this work and if so how? I've seen a thread about the demangling tool not working on types, just functions. The comment at top of this file says Replaces *all* occurrences of mangled D symbols in the input... so I assume it deals with types? The help says: 'If inputfile is a single dash '-', standard input is read.' I've tried: $ echo this _D56TypeInfo_xS8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ unq _D55TypeInfo_S8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ ./goo.txt $ ./ddmangle ./goo.txt which just hangs, and this - which does not demangle: $ echo this _D56TypeInfo_xS8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ unq _D55TypeInfo_S8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ | ./ddmangle this _D56TypeInfo_xS8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ unq _D55TypeInfo_S8plusauri6bsheet13balance_sheet12BalanceSheet6__initZ What is the correct way to do this? Thanks Dan
Re: About demangling
On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: On Oct 11, 2012, at 6:17 AM, Lubos Pintes lubos.pin...@gmail.com wrote: Hi, Can someone point me to some source with information about name demangling when compiling some D program and the famous linker error 42 appears? Filter the symbol names through core.demangle. We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d Does this work and if so how? I've seen a thread about the demangling tool not working on types, just functions. The comment at top of this file says Replaces *all* occurrences of mangled D symbols in the input... so I assume it deals with types? The help says: 'If inputfile is a single dash '-', standard input is read.' [...] This program only calls the library core.demangle. So if core.demangle doesn't demangle something, then it won't get demangled. The problem is, there's a comment in core.demangle that seems to say that some mangled symbols are skipped because they are not pertinent to the ABI, or something to that effect. Meaning that *not* all symbols are getting demangled. I think this should be an enhancement request in the bugtracker. T -- Let's call it an accidental feature. -- Larry Wall
Re: About demangling
On Thu, 01 Nov 2012 15:40:23 -, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: On Oct 11, 2012, at 6:17 AM, Lubos Pintes lubos.pin...@gmail.com wrote: Hi, Can someone point me to some source with information about name demangling when compiling some D program and the famous linker error 42 appears? Filter the symbol names through core.demangle. We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d Does this work and if so how? I've seen a thread about the demangling tool not working on types, just functions. The comment at top of this file says Replaces *all* occurrences of mangled D symbols in the input... so I assume it deals with types? The help says: 'If inputfile is a single dash '-', standard input is read.' [...] This program only calls the library core.demangle. So if core.demangle doesn't demangle something, then it won't get demangled. The problem is, there's a comment in core.demangle that seems to say that some mangled symbols are skipped because they are not pertinent to the ABI, or something to that effect. Meaning that *not* all symbols are getting demangled. I think this should be an enhancement request in the bugtracker. There is also a bug in demangle.d, line 55: foreach (line; stdin.byLine()) should read: foreach (line; f.byLine()) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: About demangling
On Thu, 01 Nov 2012 15:40:23 -, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: On Oct 11, 2012, at 6:17 AM, Lubos Pintes lubos.pin...@gmail.com wrote: Hi, Can someone point me to some source with information about name demangling when compiling some D program and the famous linker error 42 appears? Filter the symbol names through core.demangle. We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d Does this work and if so how? I've seen a thread about the demangling tool not working on types, just functions. The comment at top of this file says Replaces *all* occurrences of mangled D symbols in the input... so I assume it deals with types? The help says: 'If inputfile is a single dash '-', standard input is read.' [...] This program only calls the library core.demangle. So if core.demangle doesn't demangle something, then it won't get demangled. The problem is, there's a comment in core.demangle that seems to say that some mangled symbols are skipped because they are not pertinent to the ABI, or something to that effect. Meaning that *not* all symbols are getting demangled. I think this should be an enhancement request in the bugtracker. Also, running this: dmd test.d | demangle.exe - on windows, results in this: invalid UTF-8 sequence Usage: demangle.exe [options] inputfile Demangles all occurrences of mangled D symbols in the input and writes to standard output. If inputfile is a single dash '-', standard input is read. Options: --help, -hShow this help Adding writefln to demangle.d to debug the issue shows that args[1] is - and that getopt is throwing the exception invalid UTF-8 sequence. Omitting the - works, and demangle reads stdin. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: About demangling
On Thu, Nov 01, 2012 at 04:25:56PM -, Regan Heath wrote: On Thu, 01 Nov 2012 15:40:23 -, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: [...] We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d [...] Also, running this: dmd test.d | demangle.exe - on windows, results in this: invalid UTF-8 sequence [...] Omitting the - works, and demangle reads stdin. [...] https://github.com/D-Programming-Language/tools/pull/35 T -- English has the lovely word defenestrate, meaning to execute by throwing someone out a window, or more recently to remove Windows from a computer and replace it with something useful. :-) -- John Cowan
Re: About demangling
On Thu, 01 Nov 2012 16:25:56 -, Regan Heath re...@netmail.co.nz wrote: Adding writefln to demangle.d to debug the issue shows that args[1] is - and that getopt is throwing the exception invalid UTF-8 sequence. I was wrong here, this line is the issue: stderr.writeln(e.msg); For some reason, when run from command prompt and passed - as an arg it errors. If I run it in debug mode in VisualD it works and outputs: Unrecognized option - R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: About demangling
On Thu, 01 Nov 2012 17:21:29 -, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Nov 01, 2012 at 04:25:56PM -, Regan Heath wrote: On Thu, 01 Nov 2012 15:40:23 -, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: On 11-10-2012 22:56, Sean Kelly wrote: [...] We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d [...] Also, running this: dmd test.d | demangle.exe - on windows, results in this: invalid UTF-8 sequence [...] Omitting the - works, and demangle reads stdin. [...] https://github.com/D-Programming-Language/tools/pull/35 Perfect, thanks. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: About demangling
On Thu, Nov 01, 2012 at 08:40:23AM -0700, H. S. Teoh wrote: On Thu, Nov 01, 2012 at 03:16:25PM +0100, Dan wrote: On Thursday, 11 October 2012 at 21:04:28 UTC, Alex Rønne Petersen wrote: [...] We even have a tool for that: https://github.com/D-Programming-Language/tools/blob/master/ddemangle.d Does this work and if so how? I've seen a thread about the demangling tool not working on types, just functions. The comment at top of this file says Replaces *all* occurrences of mangled D symbols in the input... so I assume it deals with types? The help says: 'If inputfile is a single dash '-', standard input is read.' [...] This program only calls the library core.demangle. So if core.demangle doesn't demangle something, then it won't get demangled. The problem is, there's a comment in core.demangle that seems to say that some mangled symbols are skipped because they are not pertinent to the ABI, or something to that effect. Meaning that *not* all symbols are getting demangled. I think this should be an enhancement request in the bugtracker. [...] I just looked over core.demangle. Apparently only function names are demangled, everything else is currently not implemented. :-( I say, definitely file an enhancement request in the bugtracker. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
struct Yes in std.typecons
The docs say:
Convenience names that allow using e.g. yes!encryption instead
of Flag!encryption.yes and no!encryption instead of
Flag!encryption.no.
I could not get yes!encription to work. But Yes.encription
does. Are the docs out of date? Am I missing something? E.g.,
module yes_no_flag;
import std.stdio, std.typecons;
void retval(Flag!encryption v)
{
if (v)
writeln(Encryption);
else
writeln(Open);
}
void main()
{
retval(Flag!encryption.yes);
retval(Flag!encryption.no);
retval(Yes.encryption);
// retval(yes!encryption);
// Error: template instance yes!(encryption) template 'yes'
is not
// defined, did you mean Yes?
}
$ rdmd yes_no_flag.d
Encryption
Open
Encryption
Vibe: I found the problem, but don't know how to fix it
Hi, Some time ago I reported on D.Anounce, that Vibe apps are not working on my system, they failed with an exception. So I diagnosed a bit and found the following: There is a folder on my system C:\Users\pintes\AppData\Local\Temp\.rdmd\source which contains some DLLs needed for successful run. But the app.exe generated by rdmd is, in one concrete case in the folder C:\Users\pintes\AppData\Local\Temp\.rdmd\rdmd-app.d-7203ADE98B25A99E6D0DEF46E9812990 After I manually moved the app.exe from the previous folder with crazy name to the source folder, everything worked.
Re: struct Yes in std.typecons
On 11/01/2012 10:41 AM, Peter Summerland wrote: The docs say: Convenience names that allow using e.g. yes!encryption instead of Flag!encryption.yes and no!encryption instead of Flag!encryption.no. The documentation is wrong. Please either file a bug report or click the Improve this page button on that page to submit a pull request automatically. :) (I have never tried it myself though.) Ali
Re: Vibe: I found the problem, but don't know how to fix it
On Thursday, 1 November 2012 at 18:25:22 UTC, Lubos Pintes wrote: Hi, Some time ago I reported on D.Anounce, that Vibe apps are not working on my system, they failed with an exception. So I diagnosed a bit and found the following: There is a folder on my system C:\Users\pintes\AppData\Local\Temp\.rdmd\source which contains some DLLs needed for successful run. But the app.exe generated by rdmd is, in one concrete case in the folder C:\Users\pintes\AppData\Local\Temp\.rdmd\rdmd-app.d-7203ADE98B25A99E6D0DEF46E9812990 After I manually moved the app.exe from the previous folder with crazy name to the source folder, everything worked. Hi! You can report this problem to Vibe community forum (without signup): http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/
How to add n items to TypeTuple?
For example, adding 3 strings to type tuple t: foreach( i; 0..2 ) alias TypeTuple!( t, string ) t; // this is wrong code and result should be: TypeTuple!( string, string, string );
Re: How to add n items to TypeTuple?
On Thu, 01 Nov 2012 19:42:07 +0100, denizzzka wrote:
For example, adding 3 strings to type tuple t:
foreach( i; 0..2 )
alias TypeTuple!( t, string ) t; // this is wrong code
and result should be:
TypeTuple!( string, string, string );
Use a recursive template. Here's one that repeats a given type N times:
template Repeat(Type, size_t Times)
{
static if (Times == 0)
alias TypeTuple!() Repeat;
else
alias TypeTuple!(Type, Repeat!(Type, Times - 1)) Repeat;
}
Invoke like so:
Repeat!(string, 3) threeStrings;
Re: How to add n items to TypeTuple?
On 2012-11-01, 19:52, Justin Whear wrote:
On Thu, 01 Nov 2012 19:42:07 +0100, denizzzka wrote:
For example, adding 3 strings to type tuple t:
foreach( i; 0..2 )
alias TypeTuple!( t, string ) t; // this is wrong code
and result should be:
TypeTuple!( string, string, string );
Use a recursive template. Here's one that repeats a given type N times:
template Repeat(Type, size_t Times)
{
static if (Times == 0)
alias TypeTuple!() Repeat;
else
alias TypeTuple!(Type, Repeat!(Type, Times - 1)) Repeat;
}
Invoke like so:
Repeat!(string, 3) threeStrings;
I've always preferred the opposite order of arguments, as that
allows repetition of more complex things:
template Repeat(size_t times, T...) {
static if ( times == 0 ) {
alias TypeTuple!() Repeat;
} else {
alias TypeTuple!( T, Repeat!( times - 1, T ) ) Repeat;
}
}
Invoke like so:
alias Repeat!(4, string, int, Hello, template world!)
YeahThisIsGonnaBeUseful;
Or:
alias Repeat!(3, string) ThreeStrings;
--
Simen
Re: How to add n items to TypeTuple?
Great! Thanks!
vestigial delete in language spec
TDPL states
--
However, unlike in C++, clear does not dispose of the object’s
own memory and there is no delete operator. (D used to have a
delete operator, but it was deprecated.) You still can free
memory manually if you really, really know what you’re doing by
calling the function GC.free() found in the module core.memory.
--
The language spec has this example from the section on Struct
Postblits:
--
struct S {
int[] a;// array is privately owned by this instance
this(this) {
a = a.dup;
}
~this() {
delete a;
}
}
--
Is the delete call, then per TDPL not necessary? Is it harmful or
harmless?
Also, are there any guidelines for using and interpreting the
output of
valgrind on a D executable?
Thanks
Dan
Re: vestigial delete in language spec
On 01-11-2012 22:21, Dan wrote:
TDPL states
--
However, unlike in C++, clear does not dispose of the object’s
own memory and there is no delete operator. (D used to have a
delete operator, but it was deprecated.) You still can free
memory manually if you really, really know what you’re doing by
calling the function GC.free() found in the module core.memory.
--
The language spec has this example from the section on Struct
Postblits:
--
struct S {
int[] a;// array is privately owned by this instance
this(this) {
a = a.dup;
}
~this() {
delete a;
}
}
--
Is the delete call, then per TDPL not necessary? Is it harmful or
harmless?
Also, are there any guidelines for using and interpreting the output of
valgrind on a D executable?
Thanks
Dan
The docs are supposed to not use delete. In this particular case, you'd
use core.memory.GC.free(a.ptr); instead.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
SList of chars not possible?
auto i = SList!int(1, 2, 3, 4, 5, 6, 7);
auto f = SList!float(1.1, 2.234, 3.21, 4.3, 5.001, 6.2, 7.0);
auto s = SList!string([I, Hello, World]);
auto c = SList!char('a', 'b' ,'c'); // doesn't compile, get the
following
C:\D\dmd2\windows\bin\..\..\src\phobos\std\container.d(905):
Error: template std.container.SList!(char).SList.insertFront does
not match any function template
eclaration
C:\D\dmd2\windows\bin\..\..\src\phobos\std\container.d(1096):
Error: template std.container.SList!(char).SList.insertFront
cannot deduce template function from
argument types !()(char[])
Container.d(19): Error: template instance
std.container.SList!(char).SList.__ctor!(char) error instantiating
auto c = SList!char(['a', 'b' ,'c']); // doesn't compile either.
Seems to me a Slist of char nodes should be pretty innocuous.
Re: vestigial delete in language spec
On 11/01/2012 02:21 PM, Dan wrote: TDPL states -- However, unlike in C++, clear does not dispose of the object’s own memory and there is no delete operator. Additionally, TDPL predates 'clear's deprecation in December 2012. It is called 'destroy' now. Ali
Re: SList of chars not possible?
On 11/01/2012 03:18 PM, They call me Mr. D wrote:
auto i = SList!int(1, 2, 3, 4, 5, 6, 7);
auto f = SList!float(1.1, 2.234, 3.21, 4.3, 5.001, 6.2, 7.0);
auto s = SList!string([I, Hello, World]);
auto c = SList!char('a', 'b' ,'c'); // doesn't compile, get the following
C:\D\dmd2\windows\bin\..\..\src\phobos\std\container.d(905): Error:
template std.container.SList!(char).SList.insertFront does not match any
function template
eclaration
C:\D\dmd2\windows\bin\..\..\src\phobos\std\container.d(1096): Error:
template std.container.SList!(char).SList.insertFront cannot deduce
template function from
argument types !()(char[])
Container.d(19): Error: template instance
std.container.SList!(char).SList.__ctor!(char) error instantiating
auto c = SList!char(['a', 'b' ,'c']); // doesn't compile either.
Seems to me a Slist of char nodes should be pretty innocuous.
Looks related to the fact that the element type of a char[] range is
dchar, not char. So, SList!dchar works:
auto c = SList!dchar('a', 'b' ,'c');
SList!ubyte may make sense too but it requires a cast:
auto u = SList!ubyte(cast(ubyte[])[ 'a', 'b' ,'c' ]);
Ali
Re: vestigial delete in language spec
On Thursday, November 01, 2012 22:21:11 Dan wrote:
struct S {
int[] a; // array is privately owned by this instance
this(this) {
a = a.dup;
}
~this() {
delete a;
}
}
Is the delete call, then per TDPL not necessary? Is it harmful or
harmless?
It's not necessary at all. delete is _never_ necessary, and it's not safe.
delete frees GC-allocated memory. If you just leave it alone, and there are
really no other references to it, then the GC will eventually free it if it
needs more memory. Deleting it makes it so that it's freed now rather than
freed who-knows-when later, but if any other references to that data still
exist when it's deleted, then they'll end up pointing to garbage behavior,
giving you nasty bugs.
Because of all of this, delete is going to be deprecated if it hasn't been
already. core.memory will still provide functions for freeing GC memory if you
really want to and are willing to go the extra mile to make sure that your
code is safe, but there will no longer be a language primitive for doing so.
clear (which was recently renamed to destroy) specifically destroys an object
but does _not_ free its memory. So, you won't end up with bugs due to other
references to that data operating on garbage. In the case of classes, because
destroy zeroes out the vtbl, calling virtual functions on the destroyed object
will cause a segfault. In the case of primitives such as int, I believe that
they're set to their init property. And in the case of arrays, I believe that
it's no different from setting them to null, so nothing else is actually
affected by calling destroy on them. Regardless, with destroy, you're not going
to run into nasty memory issues due to memory being freed when other
references to it still existed, because it doesn't actually free any memory.
It just destroys what's there so that fewer references to it exist and so that
any non-GC-allocated resources which the destroyed object had get released.
- Jonathan M Davis
