Re: Narrow string is not a random access range
On 2012-41-24 01:10, Adam D. Ruppe wrote: 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) As long as typeof("") != String, this is not going t work: auto s = ""; -- Simen
Re: More automated interfacing of D with C codebases
On 2012-10-23 21:43, Brad Lanam wrote: 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. I thought I said bash somewhere, but perhaps you didn't. 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. I see. 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. Ok, I see. -- /Jacob Carlborg
Re: long compile time question
On Tue, 23 Oct 2012 22:50:46 -0500, Dan 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/
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: exception messages
On Wed, Oct 24, 2012 at 03:03:02AM +0200, Andrej Mitrovic wrote: > On 10/24/12, Greg 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.
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 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 10/24/12, Greg 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;
exception messages
I'm attempting to learn D through a personal project, and can't figure out how to get the message from an exception. I've basically defined a custom subclass of Exception to represent when invalid inputs are provided, and would like to have a master catch block that handles them, but I can't find API docs for Throwable or Exception within the Phobos Library Reference. In particular, I can't find API definitions for those classes in either std.exception or core.exception. Where else should I be looking?
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: 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 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 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/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: 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: 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: 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: 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
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)
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
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.
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: 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 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
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 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
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?
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; } -
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/
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 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 11:34:35 UTC, denizzzka wrote: Something like execv() but with stdin/stdout? Something like popen(), not execv().
How to start new command with arguments, pass data to its stdin read its output?
Something like execv() but with stdin/stdout?