Re: More automated interfacing of D with C codebases
On 2012-10-22 21:48, Brad Lanam wrote: Nothing wrong with that. I had different goals -- portability and legacy systems. My tool is all bourne shell and awk. There aren't many systems it does not work on (e.g. ULTRIX shell runs out of memory). How can you mention bourne shell and portability in the same sentence? I doesn't work on Windows (yes I know about cygwin and mingw). Clang does work on Windows, I just haven't been able to compile DStep for Windows yet due to optlink not cooperating. Sure, if you're satisfied with Posix then I guess that's fine. But it's not really easy to build cross-platform code with shell script. I should also state my tool was written as a build configuration tool (like autoconf/iffe/dist), not a conversion tool. SWIG is better supported, faster and supports more languages. If you need to write code that runs on multiple systems and works with low level system calls (rpc, et.al.), my tool might be a better choice. Why would that make a difference. This sort of thing (from the D compiler): #if __sun #includealloca.h #endif Is nuts. I thought everyone had gotten away from that sort of thing (it died out in the mid-eighties!), but I still see it in code everywhere. The system should be tested for its capabilities and what it has available, not whether it is a sun machine. DMD (DMC) is from the eighties. It sill uses the .c for its C++ files. -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On 2012-10-23 07:09, timotheecour wrote:
If you try to automate processing of the pre-processed headers,
all of the included system headers will be processed and too much that
isn't needed will be output.
Swig has lots of customization to control what gets translated. For
example, we recursively translate the contents of header files or just
the contents minus without looking into the include statements (the
default):
b.h:
void funb();
a.h:
#include b.h
void funa();
%{
%include a.h
%}
%include a.h
= the default is NOT to inlude funb(), which is inside an include
statement.
I'm only translating what's in the main header file, i.e. the one you
gave on the command line. I have access to source information of where a
given symbol is declared, if it doesn't match the main header file it's
not translated.
If SWIG has a full blown C++ parser, then why is it choking on some
code?
One example is when there's no D equivalent, eg multiple inheritance.
But there are more:
actually in the example above, if I understand correctly, the stuff
inside the %{ %} uses the full blown C++ parser, whereas the stuff after
has some swig specificities and sometimes can't handle certain rare
constructs if one uses the lazy approach that I've taken of translating
the whole header file (%include a.h):
some stuff it choked on:
A) typedef Matx_Tp, MIN(m, n), 1 diag_type;
B) void addParam( int (Algorithm::*getter)()=0)
If there's something I can't translate to D I just skip it. I could
output a warning, some kind of static assert in the code or whatever.
The tool can still handle the file.
--
/Jacob Carlborg
How to start new command with arguments, pass data to its stdin read its output?
Something like execv() but with stdin/stdout?
Re: How to start new command with arguments, pass data to its stdin read its output?
On Tuesday, 23 October 2012 at 11:34:35 UTC, denizzzka wrote: Something like execv() but with stdin/stdout? Something like popen(), not execv().
Re: How to start new command with arguments, pass data to its stdin read its output?
On Tuesday, 23 October 2012 at 11:34:35 UTC, denizzzka wrote: Something like execv() but with stdin/stdout? If you're on linux i have a little file that might help: http://arsdnet.net/dcode/exec.d int exec( string program, string[] args = null, string input = null, string* output = null, string* error = null, string[] environment = null);
Re: How to start new command with arguments, pass data to its stdin read its output?
On Tuesday, 23 October 2012 at 12:19:08 UTC, Adam D. Ruppe wrote: On Tuesday, 23 October 2012 at 11:34:35 UTC, denizzzka wrote: Something like execv() but with stdin/stdout? If you're on linux i have a little file that might help: http://arsdnet.net/dcode/exec.d int exec( string program, string[] args = null, string input = null, string* output = null, string* error = null, string[] environment = null); Thanks! It is suitable for my case. I think something like this should be in the standard library.
Re: How to start new command with arguments, pass data to its stdin read its output?
On Tue, 23 Oct 2012 13:29:59 +0100, denizzzka 4deni...@gmail.com wrote: On Tuesday, 23 October 2012 at 12:19:08 UTC, Adam D. Ruppe wrote: On Tuesday, 23 October 2012 at 11:34:35 UTC, denizzzka wrote: Something like execv() but with stdin/stdout? If you're on linux i have a little file that might help: http://arsdnet.net/dcode/exec.d int exec( string program, string[] args = null, string input = null, string* output = null, string* error = null, string[] environment = null); Thanks! It is suitable for my case. I think something like this should be in the standard library. Coming soon I believe. The new std.process should support it. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
msgpack unresolved question
I got msgpack and was trying out an example (compare_json.d) and
I get an unresolved error.
Not sure what I'm doing wrong...
https://github.com/msgpack/msgpack-d/blob/master/src/msgpack.d
I think length is built in for associative arrays?
Thanks
Dan
The error and lines of code is:
-
/tmp/.rd.../objs/compare_json.o: In function `const(@trusted void
function(ref
msgpack.Packer!(std.array.Appender!(ubyte[]).Appender).Packer))
msgpack.Value.toMsgpack!(msgpack.Packer!(std.array.Appender!(ubyte[]).Appender).Packer).toMsgpack':
/home/dbdavidson/stage/msgpack-d/src/msgpack.d:2967: undefined
reference to `@property ulong
object.AssociativeArray!(msgpack.Value,
const(msgpack.Value)).AssociativeArray.length()'
case Type.array:
packer.beginArray(via.array.length);
foreach (elem; via.array)
elem.toMsgpack(packer);
break;
case Type.map:
packer.beginMap(via.map.length);
foreach (key, value; via.map) {
key.toMsgpack(packer);
value.toMsgpack(packer);
}
break;
}
-
Narrow string is not a random access range
Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this?
Re: Narrow string is not a random access range
On 10/23/12 11:36 AM, mist wrote: Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this? Historical mistake. Andrei
Re: Narrow string is not a random access range
On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote: On 10/23/12 11:36 AM, mist wrote: Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this? Historical mistake. Andrei Is string random access gonna be deprecated some day then or this is considered a mistake we need to get used to? :)
Re: Narrow string is not a random access range
On 10/23/12 12:35 PM, Andrei Alexandrescu wrote: On 10/23/12 11:58 AM, mist wrote: On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote: On 10/23/12 11:36 AM, mist wrote: Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this? Historical mistake. Andrei Is string random access gonna be deprecated some day then or this is considered a mistake we need to get used to? :) Walter is unconvinced it's a mistake, which doesn't make it any easier. If I had my way, I'd require people to write str.rep[6] to access the sixth byte in the representation of a UTF-8 or UTF-16 string. It would make D's strings from great to indistinguishable from perfect. Andrei s/byte/code unit/
Re: Narrow string is not a random access range
On 10/23/12 11:58 AM, mist wrote: On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote: On 10/23/12 11:36 AM, mist wrote: Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this? Historical mistake. Andrei Is string random access gonna be deprecated some day then or this is considered a mistake we need to get used to? :) Walter is unconvinced it's a mistake, which doesn't make it any easier. If I had my way, I'd require people to write str.rep[6] to access the sixth byte in the representation of a UTF-8 or UTF-16 string. It would make D's strings from great to indistinguishable from perfect. Andrei
Re: Narrow string is not a random access range
Hm, and all phobos functions should operate on narrow strings as if they where not random-acessible? I am thinking about something like commonPrefix from std.algorithm, which operates on code points for strings.
Re: Narrow string is not a random access range
On 2012-10-23, 19:21, mist wrote: Hm, and all phobos functions should operate on narrow strings as if they where not random-acessible? I am thinking about something like commonPrefix from std.algorithm, which operates on code points for strings. Preferably, yes. If there are performance (or other) benefits from operating on code units, and it's just as safe, then operating on code units is ok. -- Simen
Re: More automated interfacing of D with C codebases
On Tuesday, 23 October 2012 at 06:35:06 UTC, Jacob Carlborg wrote:
On 2012-10-22 21:48, Brad Lanam wrote:
How can you mention bourne shell and portability in the same
sentence? I doesn't work on Windows (yes I know about cygwin
and mingw). Clang does work on Windows, I just haven't been
able to compile DStep for Windows yet due to optlink not
cooperating.
Sure, if you're satisfied with Posix then I guess that's fine.
But it's not really easy to build cross-platform code with
shell script.
I'm sorry, I don't see how that follows. My scripts work on All
variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64,
HP-UX, All *BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare,
Windows Cygwin. My 'di' program builds on all of the above with
a simple 'make' as it uses my build tool. And I don't need to
install any special tools. These are just the systems I have
access to.
How is that not cross-platform? How is that not portable? How
is that not easy?
If I had a D compiler on all those platforms, the D version of
the 'di' program would build everywhere with just a 'make'.
If you need to write code that runs on multiple systems and
works with
low level system calls (rpc, et.al.), my tool might be a
better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE), toStringz(r));
}
If I understand your tool correctly, you might convert the
mount.h or mntent.h file [but how does your program decide which
one and even if they exist?]. But then how are you going to
change your code to handle the above? You've got a *lot* of work
to do if you want a cross platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Threading Question
Hi! I'm new to D an not a native speaker so I may misunderstand the following sentence of the thread documentation. final @property void isDaemon(bool val); Sets the daemon status for this thread. While the runtime will wait for all normal threads to complete before tearing down the process, daemon threads are effectively ignored and thus will not prevent the process from terminating. In effect, daemon threads will be terminated automatically by the OS when the process exits. That sounds to me as if the daemon will be finished when the main-thread has finished. But in my understanding daemons will survive the termination of the main-thread and be killed by a signal (KILL, SIGTERM etc) or finish itself. I think that is the case here too. Is that true ? Another question: I cannot find a reference how D deals with OS SIGNALS, especially about differences between the platform (*nix; Windows, Mac). Can you explain or point me to the documentation? Peter
overriding private interface methods
Hello. How to override private methods?
import std.stdio, std.conv;
interface abcInterface
{
private double private_func();
public final double func() { return private_func(); }
}
class abcImpl: abcInterface
{
override private double private_func() { return 3.14; } //#1
}
void main()
{
auto abc = new abcImpl;
writeln( abc.func() );
}
This code generate error
#1 Error: function inter.abcImpl.private_func cannot override a
non-virtual function
This private method (private_func) is 'private' because it must
call only in final interface methods (func)
Re: overriding private interface methods
On 10/23/2012 11:37 AM, Oleg wrote:
Hello. How to override private methods?
import std.stdio, std.conv;
interface abcInterface
{
private double private_func();
public final double func() { return private_func(); }
}
class abcImpl: abcInterface
{
override private double private_func() { return 3.14; } //#1
}
void main()
{
auto abc = new abcImpl;
writeln( abc.func() );
}
This code generate error
#1 Error: function inter.abcImpl.private_func cannot override a
non-virtual function
This private method (private_func) is 'private' because it must call
only in final interface methods (func)
private member functions are not virtual by the design of the language.
You have to make them 'protected', not private.
Ali
Re: More automated interfacing of D with C codebases
On 2012-10-23 19:42, Brad Lanam wrote:
I'm sorry, I don't see how that follows. My scripts work on All
variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64, HP-UX, All
*BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare, Windows Cygwin. My
'di' program builds on all of the above with a simple 'make' as it uses
my build tool. And I don't need to install any special tools. These
are just the systems I have access to.
All of these don't use the same shell. Requiring to install bash would
mean you do need to install special tools. Not really special but
additional tools. But I would count Cygwin as a special tool for Windows.
How is that not cross-platform? How is that not portable? How is that
not easy?
If I had a D compiler on all those platforms, the D version of the 'di'
program would build everywhere with just a 'make'.
If you need to write code that runs on multiple systems and works with
low level system calls (rpc, et.al.), my tool might be a better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE), toStringz(r));
}
If I understand your tool correctly, you might convert the mount.h or
mntent.h file [but how does your program decide which one and even if
they exist?]. But then how are you going to change your code to handle
the above? You've got a *lot* of work to do if you want a cross
platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Well then, how does your tool work?
--
/Jacob Carlborg
Re: More automated interfacing of D with C codebases
On Tuesday, 23 October 2012 at 19:10:29 UTC, Jacob Carlborg wrote:
On 2012-10-23 19:42, Brad Lanam wrote:
All of these don't use the same shell. Requiring to install
bash would mean you do need to install special tools. Not
really special but additional tools. But I would count Cygwin
as a special tool for Windows.
Oh, maybe were you thinking that bash is the bourne shell? It's
the
bourne-again shell, a rewrite of the bourne shell. Solaris sh is
probably the closest to the original bourne shell.
My tool runs with any bourne shell compatible shell. It works
with bash2, bash3, bash4, ksh, ksh88, ksh93, Solaris sh, Tru64 sh,
ash, dash, mksh, pdksh. HP-UX sh.
If you need to write code that runs on multiple systems and
works with
low level system calls (rpc, et.al.), my tool might be a
better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE),
toStringz(r));
}
If I understand your tool correctly, you might convert the
mount.h or
mntent.h file [but how does your program decide which one and
even if
they exist?]. But then how are you going to change your code
to handle
the above? You've got a *lot* of work to do if you want a
cross
platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Well then, how does your tool work?
You put directives in the interface file (to use the SWIG term)
to test which capabilities the system has. It creates an output
file (.sh, .c, .d). Depending on those capabilities, the code can
use #if or static if statements to provide code that works for
the system you are building on.
In the case of the C/D language interface, the directives will
extract typedefs, structures, C function declarations, macros,
#defines.
Re: overriding private interface methods
On Tuesday, October 23, 2012 11:47:09 Ali Çehreli wrote: private member functions are not virtual by the design of the language. You have to make them 'protected', not private. Yes, but according to TDPL, it's different for interfaces. It specifically talks about using private with interfaces for NVI. And I don't believe that you can just swap it with protected in the case of interfaces (though I could be wrong - I don't remember for sure). Regardless, it doesn't currently work to use private like this for interfaces in spite of the fact that TDPL says that you can, and I'm not quite sure what's going to happen with that in the future. It's clear that private functions in classes will never be virtual, but I'm not sure that the situation is as clear with interfaces. The relevant bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4542 - Jonathan M Davis
Re: Narrow string is not a random access range
On 10/23/2012 05:58 PM, mist wrote: On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote: On 10/23/12 11:36 AM, mist wrote: Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this? Historical mistake. Andrei Is string random access gonna be deprecated some day then or this is considered a mistake we need to get used to? :) The other valid opinion is that the 'mistake' is in Phobos because it treats narrow character arrays specially. Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated.
Re: Narrow string is not a random access range
On Wednesday, October 24, 2012 00:28:28 Timon Gehr wrote: The other valid opinion is that the 'mistake' is in Phobos because it treats narrow character arrays specially. If it didn't, then range-based functions would be useless for strings in most cases, because it rarely makes sense to operate on code units. Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated. I think that Andrei was arguing for changing how the compiler itself handles arrays of char and wchar so that they wouldn't have direct random access or length anymore, forcing you to do something like str.rep[6] for random access regardless of what happens with range-based functions. - Jonathan M Davis
Re: Narrow string is not a random access range
On 10/24/2012 01:07 AM, Jonathan M Davis wrote: On Wednesday, October 24, 2012 00:28:28 Timon Gehr wrote: The other valid opinion is that the 'mistake' is in Phobos because it treats narrow character arrays specially. If it didn't, then range-based functions would be useless for strings in most cases, because it rarely makes sense to operate on code units. Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated. I think that Andrei was arguing for changing how the compiler itself handles arrays of char and wchar so that they wouldn't have direct random access or length anymore, forcing you to do something like str.rep[6] for random access regardless of what happens with range-based functions. - Jonathan M Davis That idea does not even deserve discussion.
Re: Narrow string is not a random access range
On Tuesday, 23 October 2012 at 23:07:28 UTC, Jonathan M Davis wrote: I think that Andrei was arguing for changing how the compiler itself handles arrays of char and wchar so that they wouldn't As I said last time this came up, we could actually do this today without changing the compiler. Since string is a user defined type anyway, we could just define it differently. http://arsdnet.net/dcode/test99.d I'm pretty sure that changes to Phobos are even required. (The reason I called it String there instead of string is simply so it doesn't conflict with the string in object.d)
Re: Narrow string is not a random access range
On Wednesday, October 24, 2012 01:33:28 Timon Gehr wrote: On 10/24/2012 01:07 AM, Jonathan M Davis wrote: On Wednesday, October 24, 2012 00:28:28 Timon Gehr wrote: The other valid opinion is that the 'mistake' is in Phobos because it treats narrow character arrays specially. If it didn't, then range-based functions would be useless for strings in most cases, because it rarely makes sense to operate on code units. Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated. I think that Andrei was arguing for changing how the compiler itself handles arrays of char and wchar so that they wouldn't have direct random access or length anymore, forcing you to do something like str.rep[6] for random access regardless of what happens with range-based functions. - Jonathan M Davis That idea does not even deserve discussion. Actually, it solves the problem quite well, because you then have to work at misusing strings (of any constness or char type), but it's still extremely easy to operate on code units if you want to. However, Walter seems to think that everyone should understand unicode and code for it, in which case it would be normal for the programmer to understand all of the quirks of code units vs code points and code accordingly, but I think that it's pretty clear that that the average programmer doesn't have a clue about unicode, so if the normal string operations do anything which isn't unicode aware (e.g. length), then lots of programmers are going to screw it up. But since such a change would break tons of code, I think that there's pretty much no way that it's going to happen at this point even if it were generally agreed that it was the way to go. The alternative, of course, is to create a string type which wraps arrays of the various character types, but no one has been able to come up with a design for it which was generally accepted. It also risks not working very well with string literals and the like, since a string literal would no longer be a string (similar to the nonsense that you have to put up with in C++ with regards to std::string vs string literals). But even if someone can come up with a solid solution, the amount of code which it would break could easiily disqualify it anyway. - Jonathan M Davis
Re: exception messages
On 10/24/12, Greg greg.steffen...@gmail.com wrote:
I'm attempting to learn D through a personal project, and can't
figure out how to get the message from an exception.
I don't know why Throwable is not documented
(http://dlang.org/phobos/object.html#Throwable), but you can use the
.msg field:
import std.exception;
import std.stdio;
void main()
{
try {
enforce(0, message);
}
catch (Exception ex)
{
writeln(ex.msg);
}
}
See the DMD2/src/druntime/src/object_.d file for the class definition
of Throwable and Exception, Throwable has these fields:
string msg;
string file;
size_t line;
TraceInfo info;
Throwable next;
Re: exception messages
Awesome, that's more informative than the API docs would have
been anyway.
BTW, another API docs problem I noticed is that on the main page,
the module list in the sidebar doesn't match the module list in
the page content (the sidebar has more modules, including
std.exception).
Thanks!
On Wednesday, 24 October 2012 at 01:03:12 UTC, Andrej Mitrovic
wrote:
On 10/24/12, Greg greg.steffen...@gmail.com wrote:
I'm attempting to learn D through a personal project, and can't
figure out how to get the message from an exception.
I don't know why Throwable is not documented
(http://dlang.org/phobos/object.html#Throwable), but you can
use the
.msg field:
import std.exception;
import std.stdio;
void main()
{
try {
enforce(0, message);
}
catch (Exception ex)
{
writeln(ex.msg);
}
}
See the DMD2/src/druntime/src/object_.d file for the class
definition
of Throwable and Exception, Throwable has these fields:
string msg;
string file;
size_t line;
TraceInfo info;
Throwable next;
Re: exception messages
On Wed, Oct 24, 2012 at 03:03:02AM +0200, Andrej Mitrovic wrote: On 10/24/12, Greg greg.steffen...@gmail.com wrote: I'm attempting to learn D through a personal project, and can't figure out how to get the message from an exception. I don't know why Throwable is not documented (http://dlang.org/phobos/object.html#Throwable), but you can use the .msg field: [...] Neither Throwable nor Exception are adequately documented. I decided to remedy that: https://github.com/D-Programming-Language/druntime/pull/337 :) T -- Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.
long compile time question
The following takes nearly three minutes to compile.
The culprit is the line bar ~= B();
What is wrong with this?
Thanks,
Dan
struct B {
const size_t SIZE = 1024*64;
int[SIZE] x;
}
void main() {
B[] barr;
barr ~= B();
}
-
Re: long compile time question
On Tue, 23 Oct 2012 22:50:46 -0500, Dan dbdavid...@yahoo.com wrote:
The following takes nearly three minutes to compile.
The culprit is the line bar ~= B();
What is wrong with this?
Thanks,
Dan
struct B {
const size_t SIZE = 1024*64;
int[SIZE] x;
}
void main() {
B[] barr;
barr ~= B();
}
-
I have the same issue on linux x64 2.060
So appending to a dynamic array isn't really that efficient.
But this goes WAY over that line. I'm timing your test now.
It's still going...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
