Re: Connecting python to D on socket of localhost : target machine actively refuses connection
On Saturday, 23 September 2017 at 02:50:25 UTC, rikki cattermole
wrote:
On 23/09/2017 3:26 AM, Sergei Degtiarev wrote:
On Friday, 22 September 2017 at 04:06:08 UTC, Enjoys Math
wrote:
Here's my minimal D code (server.d):
public:
this(ushort port, string address="") {
super(& run);
if (address == "")
address = "DESKTOP-T49RGUJ";
this.port = port;
this.address = address;
.
listener.bind(new InternetAddress(address, port));
It seems to me, you pass invalid address to bind().
InternetAddress takes ipv4 dot notation string x.x.x.x, and
for bind you are to supply INADDR_ANY
For DNS resolution:
https://dlang.org/phobos/std_socket.html#.getAddress
Right, but in this case, it would be sufficient to bind socket to
INADDR_ANY.
Re: Connecting python to D on socket of localhost : target machine actively refuses connection
On Friday, 22 September 2017 at 04:06:08 UTC, Enjoys Math wrote:
Here's my minimal D code (server.d):
public:
this(ushort port, string address="") {
super(& run);
if (address == "")
address = "DESKTOP-T49RGUJ";
this.port = port;
this.address = address;
.
listener.bind(new InternetAddress(address, port));
It seems to me, you pass invalid address to bind().
InternetAddress takes ipv4 dot notation string x.x.x.x, and for
bind you are to supply INADDR_ANY
Re: Binary serialization of a struct
On Saturday, 16 September 2017 at 03:30:51 UTC, Joseph wrote: Are there any simple direct serialization libraries... I want something straight forward without allot of plumbing on my end. You may also take a look at https://github.com/sdegtiarev/persistentObject This is small module for binary serialization.
Re: std.algorithm.joiner unexpected behavior
On Friday, 1 September 2017 at 00:09:16 UTC, H. S. Teoh wrote: Consider the case where .front returns a subrange. As you state above, copying this subrange does not have defined behaviour. One reason is the difference in semantics between reference types and value types: the assignment operator `=` means different things for each kind of type. `x=y;` for a value type makes a new copy of the value in x, but `x=y;` for a reference type only copies the reference, not the value. Absolutely, in particular, InputRange shouldn't be assumed copyable. joiner saves whatever was passed to it, in this particular case, result of files.map!(a => a.byLine) which is range itself and is evaluated lazily. This makes every call of .front() to re-evaluate (a => a.byLine) and to call the constructor again, skipping first line every time. The partial solution is simple, force joiner to make immediate evaluation instead of lazy one: return joiner(array(files.map!(a => a.byLine))); here, the array is saved in joiner and no lazy constructor call is performed. However, in general I have a feeling that something is wrong here with design. Copying of InputRanges should be disabled possibly, or lazy range evaluation should be under control. Can't say what is wrong exactly, but something definitely is.
Re: std.algorithm.joiner unexpected behavior
Let me clarify, what I was going to create was a small utility,
analogous to Perl <> operator, taking a list of file names and
allowing forward iteration as it would be single stream of text
lines. It would take no time to write the range from scratch, but
what are all the phobos primitives for then? So it looks like
this:
auto catFiles(string[] args)
{
File[] files=args.map!(a => File(a)).array;
if(files.empty)
files~=stdin;
return joiner(files.map!(a => a.byLine));
}
but unfortunately it does not work.
It seems, everybody agreed the problem is likely in the line
buffer reused, however, replacing .byLine() with .byLineCopy()
yields same result. Also, neither .byLine() nor .byLineCopy()
return ForwardRange, just InputRange, so no .save() is probably
called on them. And last, the utility is supposed to be fast, so
using .byLineCopy() is very undesirable. Transient ranges may be
uneasy to handle, but they allow to retain status of D as "better
C" suitable for system programming. Using unsolicited internal
copies is more typical for high-level scripting languages, and is
one of the reasons of slower execution and high memory
consumption.
In short, I agree with your arguments, but still believe this is
a bug, probably in joiner rather than in .byLine(). I'm going to
take look at the code and will tell if find anything.
Thank you for the discussion.
std.algorithm.joiner unexpected behavior
Hi, I tried to create a simple range concatenating several files, something like this: File[] files; foreach(ln; joiner(files.map!(a => a.byLine))) writeln(ln); and I see every first line of each file is missing. However, when I do same thing with separator: char[][] separator=[" new file ".dup]; foreach(ln; joiner(files.map!(a => a.byLine), separator)) writeln(ln); everything works fine, both separator and first lines are printed. It looks pretty much as a bug for me, but I'm not sure I use it correctly.
Re: Casting away immutability
On Thursday, 3 September 2015 at 14:36:12 UTC, Mike Parker wrote:
immutable(T)[] getGetData(T)() {
return cast(immutable(T)[])data;
}
Absolutely, instead of returning raw void[] and allow user to
cast it, std.mmfile should implement template function to return
desired type.
This would allow all necessary checks inside the module,
returning pure result.
Re: Casting away immutability
On Thursday, 3 September 2015 at 05:15:35 UTC, Jonathan M Davis wrote: On Wednesday, September 02, 2015 14:00:07 Sergei Degtiarev via Digitalmars-d-learn wrote: Well, that's how mmap works. You're just getting raw bytes as void*, and the D code converts that to void[], which is slightly safer. It doesn't inherently have a type, and often, the data referred to by mmap never did have a type. It's just bytes in a file. So, if you want to use it as a type, you have to tell the compiler what it's type is - and get it right - via a cast. And yes, you can cast to immutable as part of that, because casts let you shoot yourself in the foot, because you're telling the compiler that you know better than it does, but you shouldn't be casting anything you get from C to immutable, because it's not going to be immutable. Most code shouldn't be casting to immutable any more than it should be casting away immutable. immutable data is treated by the compiler as immutable - it will _never_ change over the course of the program - so if it does change, you're going to have fun bugs, and if it really refers to mutable data (as would be the case with an mmapped file), then it could change. Additionally, immutable is treated as implicitly shared, so the compiler could do different optimizations based on that (though that probably won't affect anything if you only ever have it one a single thread), and if it's not really immutable, you could have fun bugs caused by that. Don't cast to or from immutable unless you know what you're doing, and in most of those cases, there's a decent chance that that's not the best way to do what you're trying to do anyway. Agree, however, memory obtained with mmap(..., PROT_READ, ..); is essentially read-only and any attempt to write to it will cause immediate crash with segmentation violation. It would be very desirable in this case to return something that could be cast to immutable(type)[] but not type[]. This is what I tried to find out. Thank you for the help.
Re: Casting away immutability
On Wednesday, 2 September 2015 at 04:19:24 UTC, lobo wrote: No, I think your design is unsafe because you're throwing away type information and returning void[], then telling the compiler not to worry about it. It is unsafe, but this not my design but std.mmfile module in phobos. This is what I'm trying to improve. And there was no type information initially, this is raw allocated memory returned to user.
Casting away immutability
I can't understand how cast coexist with immutability. Consider the code: immutable immutable(int)[4] buf; auto x=buf[0]; auto p=buf.ptr; auto i=cast(int[]) buf; i[]=1; assert(buf.ptr == p); assert(buf[0] != x); I've just modified immutable data, is it normal? Another, ever simpler, code: immutable a=0; auto b=cast(int*) *b=1; assert( == b); assert(a != *b); Last two assertions both succeed and really puzzle me. What is pointer in D at all?
Re: Casting away immutability
On Wednesday, 2 September 2015 at 02:50:30 UTC, Jonathan M Davis wrote: is undefined behavior. So, don't do it. I don't. Actually, I'm looking for opposite - to protect data, like it is a class with two methods, returning void[] and immutable(void)[] as memory buffer, which user of the class supposed to cast to desired type. I naively assumed that void[] to be cast to, say, int[]; and immutable(void)[] to immutable(int)[] respectively. Unfortunately, D cast notices no difference between these two types. I seems a little bit too easy to to shoot yourself in the foot. And still, assert( == b); assert(a != *b); How these two lines would look in assembler? Defined behavior or undefined behavior, I can't imagine that.
