Re: Separate IP parts
On Saturday, 10 December 2016 at 03:51:34 UTC, brocolis wrote:
How do I separate IP parts with dlang?
I found this very cool trick, with C++:
http://stackoverflow.com/a/5328190
std::string ip ="192.168.1.54";
std::stringstream s(ip);
int a,b,c,d; //to store the 4 ints
char ch; //to temporarily store the '.'
s >> a >> ch >> b >> ch >> c >> ch >> d;
std::cout << a << " " << b << " " << c << " "<< d;
I wonder what's the equivalent D code.
Not much of a trick, but:
import std.algorithm : splitter, map;
import std.range : take;
import std.conv : to;
import std.array : array;
string ip = "192.168.1.54";
auto parts = ip
.splitter('.')
.take(4)
.map!((a) => a.to!int)
.array;
assert(parts[0] == 192);
assert(parts[1] == 168);
assert(parts[2] == 1);
assert(parts[3] == 54);
Remove the .array to keep it lazy, but then you can't index it
for the values, only walk through them in a foreach.
Separate IP parts
How do I separate IP parts with dlang? I found this very cool trick, with C++: http://stackoverflow.com/a/5328190 std::string ip ="192.168.1.54"; std::stringstream s(ip); int a,b,c,d; //to store the 4 ints char ch; //to temporarily store the '.' s >> a >> ch >> b >> ch >> c >> ch >> d; std::cout << a << " " << b << " " << c << " "<< d; I wonder what's the equivalent D code.
Re: mkdir; remove; under Windows throw Exception
On Saturday, 10 December 2016 at 03:36:11 UTC, Adam D. Ruppe wrote: On Saturday, 10 December 2016 at 03:29:18 UTC, unDEFER wrote: But it works under Linux That's just because the underlying C function handles the case. But the D function makes no promises about that: std.file.remove's documentation says "removes the file", leaving what it does to directories undefined. Interestingly, the Linux kernel *does* make the distinction: the C remove function on Linux does a test then calls unlink or rmdir based on if it is a directory or not. But it didn't always do that. But what you have is undefined behavior - the function is only guaranteed to work on files, and does not specify if it will work or be an error on directories. Thank you, but I think in this case D must use unlink for implementation remove.
Re: mkdir; remove; under Windows throw Exception
On Saturday, 10 December 2016 at 01:30:52 UTC, Jonathan M Davis wrote: On Saturday, December 10, 2016 01:19:45 unDEFER via Digitalmars-d-learn wrote: Well, much as I'd love to rag on Windows for doing dumb and annoying stuff with file locks (which they do do), in this case, your code wouldn't have worked an other OSes either. The problem is that you created a directory and then used a function which removes files. If you want to remove a directory, then use rmdir (or rmdirRecurse if you want to blow away a non-empty directory). - Jonathan M Davis man remove: remove - remove a file or directory The function which removes only files named unlink. The D must guarantee the same behaviour of remove on all OSes.
Re: mkdir; remove; under Windows throw Exception
On Saturday, 10 December 2016 at 03:29:18 UTC, unDEFER wrote: But it works under Linux That's just because the underlying C function handles the case. But the D function makes no promises about that: std.file.remove's documentation says "removes the file", leaving what it does to directories undefined. Interestingly, the Linux kernel *does* make the distinction: the C remove function on Linux does a test then calls unlink or rmdir based on if it is a directory or not. But it didn't always do that. But what you have is undefined behavior - the function is only guaranteed to work on files, and does not specify if it will work or be an error on directories.
Re: mkdir; remove; under Windows throw Exception
On Saturday, 10 December 2016 at 01:28:13 UTC, SonicFreak94 wrote:
On Saturday, 10 December 2016 at 01:19:45 UTC, unDEFER wrote:
remove("D:\\TEST");
Try rmdir instead.
But it works under Linux
Re: The module 'foo' is already defined in 'libmylib.so'
On Saturday, 10 December 2016 at 02:39:33 UTC, timotheecour wrote:
Have a look at what `trace -E d_executable args` and `trace -E
c++_executable args`
print on startup and grep for dlopen calls and the like.
do you mean strace?
I have trace on OSX but I'm asking for linux.
Looking at the code for $checkModuleCollisions in druntime
[src/rt/sections_elf_shared.d:859]:
```
* Check for module collisions. A module in a shared library
collides
* with an existing module if it's ModuleInfo is interposed
(search
* symbol interposition) by another DSO. Therefor two modules
with the
* same name do not collide if their DSOs are in separate symbol
resolution
* chains.
```
Not exactly sure what that means nor how to fix my issue:
```
void some_fun(){
handle=dlopen2("path/liblib.so", RTLD_LAZY | RTLD_LOCAL);
// error: The module 'foo' is already defined in 'libmylib.so'
}
```
How would I modify the code to avoid this?
Re: The module 'foo' is already defined in 'libmylib.so'
Have a look at what `trace -E d_executable args` and `trace -E c++_executable args` print on startup and grep for dlopen calls and the like. do you mean strace? I have trace on OSX but I'm asking for linux.
Re: staticIota is easy
On 12/09/2016 05:34 PM, Stefan Koch wrote: On Friday, 9 December 2016 at 18:52:59 UTC, Ali Çehreli wrote: I thought I needed something like staticIota in a unittest to effect static foreach over a number range and I found one in druntime's implementation: https://github.com/dlang/druntime/blob/master/src/core/internal/traits.d#L106 (I wonder why that one is implemented in divide-and-conquer fashion. Perhaps due to faster compilation that way?) Yes it is. n log n instead of n^2 Makes sense. I was stopping my counting at n: both looked O(n) to me. :) How about my staticIota()? Is it n^2 inside the compiler? Ali
Re: staticIota is easy
On Friday, 9 December 2016 at 18:52:59 UTC, Ali Çehreli wrote: I thought I needed something like staticIota in a unittest to effect static foreach over a number range and I found one in druntime's implementation: https://github.com/dlang/druntime/blob/master/src/core/internal/traits.d#L106 (I wonder why that one is implemented in divide-and-conquer fashion. Perhaps due to faster compilation that way?) Yes it is. n log n instead of n^2
Re: mkdir; remove; under Windows throw Exception
On Saturday, 10 December 2016 at 01:19:45 UTC, unDEFER wrote:
remove("D:\\TEST");
Try rmdir instead.
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 21:20:12 UTC, Martin Krejcirik wrote: On Friday, 9 December 2016 at 16:50:05 UTC, unDEFER wrote: And in mini program it works and shows diagnostic message. Where my diagnostic message in more complicate program??? Try redirecting stdout and stderr to a file(s). There are cases when the console itself can crash. OK, thank you. Next time with other crashes I will try.
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 20:35:07 UTC, Ali Çehreli wrote: Assuming boundschecking is turned off, I think you get unlucky in the mini program and happen to hit a '\0' byte. No, no.. the program built in debug mode with dub.
mkdir; remove; under Windows throw Exception
Hello!
$ cat try.d
import std.file;
void main ()
{
mkdir("D:\\TEST");
remove("D:\\TEST");
}
$ ./try.exe
std.file.FileException@std\file.d(731): D:\TEST: Access Denied.
What I don't know about removing directories in Windows?
Why I can't remove directory which just time created?
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 16:50:05 UTC, unDEFER wrote: And in mini program it works and shows diagnostic message. Where my diagnostic message in more complicate program??? Try redirecting stdout and stderr to a file(s). There are cases when the console itself can crash.
Re: The program exits unexpectedly
On 12/09/2016 08:50 AM, unDEFER wrote:
> On Friday, 9 December 2016 at 14:29:38 UTC, unDEFER wrote:
>> I'm afraid that the problem that my program wants to say something,
>> but there is no "flush" so message leaves in the buffer.
>
> I have found, it was code like:
>
> string path = "C:";
> string parent = path[0..path.lastIndexOf("\\")];
That's a bug because you're not checking the return value of
lastIndexOf. According to its documentation, lastIndexOf returns -1 if
it fails to find the needle:
http://dlang.org/phobos/std_string.html#.lastIndexOf
ptrdiff_t found = path.lastIndexOf("\\");
if (found == -1) {
// Not found
}
else {
// Now we can use it:
string parent = path[0..path.lastIndexOf("\\")];
// ...
}
The added complication is the fact that ptrdiff_t can be converted to
size_t and you get a huge string when doing path[0..path.lastIndexOf("\\")]
Do you have boundschecking turned off? It should catch such an error.
> And in mini program it works and shows diagnostic message.
> Where my diagnostic message in more complicate program???
Assuming boundschecking is turned off, I think you get unlucky in the
mini program and happen to hit a '\0' byte.
Ali
staticIota is easy
I thought I needed something like staticIota in a unittest to effect
static foreach over a number range and I found one in druntime's
implementation:
https://github.com/dlang/druntime/blob/master/src/core/internal/traits.d#L106
(I wonder why that one is implemented in divide-and-conquer fashion.
Perhaps due to faster compilation that way?)
Then I realized that this is actually pretty easy with D:
template staticIota(size_t N) {
import std.range: iota;
import std.meta: aliasSeqOf;
alias staticIota = aliasSeqOf!(N.iota);
}
unittest {
size_t count = 0;
foreach (i; staticIota!10) {
mixin("++count;");
}
assert(count == 10);
}
void main() {
}
I realized that I don't actually need it but I wanted to share. :)
Ali
P.S. Related, I've been using D for a living since I started working for
Weka.IO in June. (I think the only mention of that was in this blog
post: https://dlang.org/blog/2016/06/). The more I use D, the more I
like it but you already know it. ;)
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 14:29:38 UTC, unDEFER wrote:
I'm afraid that the problem that my program wants to say
something, but there is no "flush" so message leaves in the
buffer.
I have found, it was code like:
string path = "C:";
string parent = path[0..path.lastIndexOf("\\")];
And in mini program it works and shows diagnostic message.
Where my diagnostic message in more complicate program???
Re: Range of uncopyable elements
On Thursday, 8 December 2016 at 23:08:35 UTC, Jonathan M Davis wrote: I've seen that in C++ code all the time, especially if you're dealing with smart pointers, because otherwise you have to do stuff like (*iter)->foo() instead of just var->foo(). Smart pointers weren't introduced until C++11. I'm talking about std library code that would have to be generic. Not user code where the type in the iterator is known. Except that C++ _does_ have special iterators. They're just not as common. Still not as common and C++ has a way to With the upcoming improvements to @safe and return ref, it _might_ happen that there will be a way for a function to accept rvalues by ref. Andrei has indicated that a really good proposal might be accepted. But that's a separate issue from having ref on local variables, which is what would be required for what you're suggesting, and both Walter and Andrei have been adamant that that is not worth it - even without getting rvalue references into the mix. I don't know that it would be impossible to convince them otherwise, but I would be _very_ surprised if anyone managed to talk them into it. Exactly, the problem will continue to persist even if rvalue references are included into D. It's not well thought out, isInputRange reflects that. And for the most part, with ranges, this is pretty much a non-issue. It does become an issue when you start worrying about ranges with a non-copyable front, but this is literally only the second or third thread that I have ever seen where anyone complained about it. Much as it is annoying when someone runs int ito, it's not a big complaint that folks have. And given how much of a pain it would be to deal with in general, I seriously question that it's worth it - especially when simply using pointers fixes the problem. That's not an acceptable workaround. It complicates code for no reason. If that's the decision that is going to be accepted. Then there should be helper functions included in the standard to reflect that.
Re: The program exits unexpectedly
I'm afraid that the problem that my program wants to say something, but there is no "flush" so message leaves in the buffer.
Re: @property
My issue isn't about @property, it just shows 3 cases where i think that dmd is missing a check for alias this. Even if D didnt had @property or parentesis less function call, due to alias opCall this it should be possible to call opCall without parentesis.
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 10:08:24 UTC, unDEFER wrote: On Friday, 9 December 2016 at 09:42:52 UTC, unDEFER wrote: Exceptions works good, and prints debug message always. It is not exception.. I have tried to add try/catch around full loop of the program. It doesn't work. And program has infinite loop. But maybe it is unhandled signal? I have found. It exits on "stdout.flush()" Without flush falls in different places.. And in the console leaves not fully printed lines.
Re: @property
On Thursday, 8 December 2016 at 22:09:14 UTC, Jonathan M Davis wrote: On Thursday, December 08, 2016 16:54:57 Adam D. Ruppe via Digitalmars-d- learn wrote: [...] Yeah, it's pretty common for folks to slap @property on functions to make it clear that it's intended to be used as a property and thus is a getter or setter. So, it serves a purpose from the standpoint of documentation. But at this point, it doesn't make much differently on the technical level. The differences with typeof and stuff like std.traits.FunctionAttributes are what would be different. You can use the property syntax whether @property was used or not. [...] Thank you very much for your detailed explanation.
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 09:42:52 UTC, unDEFER wrote: Exceptions works good, and prints debug message always. It is not exception.. I have tried to add try/catch around full loop of the program. It doesn't work. And program has infinite loop. But maybe it is unhandled signal? I have found. It exits on "stdout.flush()"
Re: The program exits unexpectedly
On Friday, 9 December 2016 at 09:29:36 UTC, rikki cattermole wrote: On 09/12/2016 10:26 PM, unDEFER wrote: An exception/error might be thrown, try catching Error's in the threads function. Also try adding an infinite loop to it. Exceptions works good, and prints debug message always. It is not exception.. I have tried to add try/catch around full loop of the program. It doesn't work. And program has infinite loop. But maybe it is unhandled signal?
Re: The program exits unexpectedly
On 09/12/2016 10:26 PM, unDEFER wrote: Hello! I'm starting port my program to Windows _without_ Cygwin and found big trouble. My main thread exits unexpectedly without any diagnostic messages. The second thread still lives when it happens. The visual studio debugger say that thread exits with code 2. What it maybe? An exception/error might be thrown, try catching Error's in the threads function. Also try adding an infinite loop to it.
The program exits unexpectedly
Hello! I'm starting port my program to Windows _without_ Cygwin and found big trouble. My main thread exits unexpectedly without any diagnostic messages. The second thread still lives when it happens. The visual studio debugger say that thread exits with code 2. What it maybe?
