Re: Optional type - how to correctly reset a wrapped immutable T
On Sunday, 25 March 2018 at 23:00:11 UTC, Simen Kjærås wrote: On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote: struct Optional(T) { Unqual!T value; opAssign(T t) { value = cast(Unqual!T)(t); } } Consider this case: Optional!(immutable int) a = some(3); immutable int* p = &a.value; a = some(5); Of course, if Optional offers no way to get a reference to the wrapped value (say, if a.value is an @property function that doesn't return ref T), then using Unqual internally is safe*. Someone with knowledge of the internal layout of Optional might use tricks like *cast(immutable(int)*)&a, but in that case they're breaking the type system anyway, and one simply cannot negotiate with terrorists. *actually, this may not be 100% true, in cases where T.opAssign does weird things. Consider: struct Foo { int* p; void opAssign(Foo rhs) { p = rhs.p; (*p)++; } } unittest { immutable a = Foo(new int(3)); assert(*a.p == 3); // Passes Optional!(immutable(Foo)) b; b = a; assert(*a.p == 3); // Fails } There actually is a workaround for this, using destroy() and move() instead of assignment. I'm unsure if there are other corner cases to consider. -- Simen
Re: Help with specific template function
On Monday, 26 March 2018 at 06:48:45 UTC, rumbu wrote: isNumeric applies to a type, not to a variable => IsNumeric!X On Monday, 26 March 2018 at 06:51:48 UTC, arturg wrote: use the type not the variables: isNumeric!X && isNumeric!Y Ah, missed that. Thanks a bunch!
How to use annotation get key name?
Rust sample code: #[cfg(name = "users")] PHP sample code: /* @Table(name = "users") */ Java sample code: @Table(name = "users") How to use dlang get key name?
Re: How to use annotation get key name?
On Monday, 26 March 2018 at 08:29:31 UTC, Brian wrote: Rust sample code: #[cfg(name = "users")] PHP sample code: /* @Table(name = "users") */ Java sample code: @Table(name = "users") How to use dlang get key name? If I understand your question correctly: struct Table { string name; } struct Foo { @Table("foo") int n; } unittest { import std.traits; string name = getUDAs!(Foo.n, Table)[0].name; } -- Simen
Re: Optional type - how to correctly reset a wrapped immutable T
On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote: Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable. Optional!(immutable int) a = some(3); a = none; I used to do this via a dynamic array and opAssign would recreate the array struct Optional(T) { T[] bag; opAssign(T t) { bag = [t] } } But then there were problems with inout, namely: Error: variable `Optional!(inout(A)).Optional.bag` only parameters or stack based variables can be inout So I changed it to a stack variable (prefer this anyway, it's not only because of the inout error) but now I'm unsure if I'm violating the type system. Basically I'm now storing T as Unqual!T, but what I'm looking for is a Rebindable implementation that's for value types as well. Is this possible? Now I do this: struct Optional(T) { Unqual!T value; opAssign(T t) { value = cast(Unqual!T)(t); } } I put up a PR if anyone wants to see the code. Any pointers, tips would be highly appreciated: https://github.com/aliak00/optional/pull/13/files#diff-cb543fea6a0b5eeb07b6aac9f068e262 Cheers - Ali Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable
Re: Homebuilt dmd fails to link my dub application
On Sunday, 25 March 2018 at 20:35:01 UTC, Seb wrote: For building everything locally, it should be as easy as: --- git clone https://github.com/dlang/dmd git clone https://github.com/dlang/druntime git clone https://github.com/dlang/phobos cd phobos && make -f posix.mak -j10 How do I build a release-inline-nobounds build with ldc? I want to set - DC=ldmd2, - ENABLE_RELEASE=1 when building dmd. BTW there's also this setup script: https://github.com/dlang/tools/blob/master/setup.sh Thanks.
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote: Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable Allow me to quote from aliak's post: what I'm looking for is a Rebindable implementation that's for value types As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types. -- Simen
C style array declaration.
I'm a big fan of betterC. In C, you can initialize an array without specifying the length like this int ia[ ] = {0, 2, 1}; What is the translation of this? Note that int[] is a different type than C's arrays. https://dlang.org/spec/interfaceToC.html#data_type_compat says there are no equivalent to this. What's the workaround? Also, is it possible to retrieve the pointer of the sequence of actual data from std.container.array? If all fails I'd like to use this container.
Re: C style array declaration.
On 26/03/2018 11:16 PM, Aedt wrote: I'm a big fan of betterC. In C, you can initialize an array without specifying the length like this int ia[ ] = {0, 2, 1}; What is the translation of this? Note that int[] is a different type than C's arrays. https://dlang.org/spec/interfaceToC.html#data_type_compat says there are no equivalent to this. What's the workaround? Also, is it possible to retrieve the pointer of the sequence of actual data from std.container.array? If all fails I'd like to use this container. Scroll further down. C: T[] -> D: T* https://dlang.org/spec/interfaceToC.html#passing_d_array
Re: C style array declaration.
On 03/26/2018 12:16 PM, Aedt wrote: I'm a big fan of betterC. In C, you can initialize an array without specifying the length like this int ia[ ] = {0, 2, 1}; What is the translation of this? The language doesn't have that feature. But there's a PR to add `staticArray` to the standard library [1]. When that gets in, you can write: import std.array; auto ia = [0, 2, 1].staticArray; /* ia is an int[3] */ [...] Also, is it possible to retrieve the pointer of the sequence of actual data from std.container.array? If all fails I'd like to use this container. Take the address of the first element: import std.container.array: Array; Array!int a = [1, 2, 3]; int* p = &a[0]; assert(*p == 1); assert(*++p == 2); assert(*++p == 3); Be aware that the pointer potentially becomes invalid when you append to the array. [1] https://github.com/dlang/phobos/pull/6178
Re: Homebuilt dmd fails to link my dub application
On Monday, 26 March 2018 at 10:01:38 UTC, Nordlöw wrote: On Sunday, 25 March 2018 at 20:35:01 UTC, Seb wrote: For building everything locally, it should be as easy as: --- git clone https://github.com/dlang/dmd git clone https://github.com/dlang/druntime git clone https://github.com/dlang/phobos cd phobos && make -f posix.mak -j10 How do I build a release-inline-nobounds build with ldc? I want to set - DC=ldmd2, - ENABLE_RELEASE=1 when building dmd. BTW there's also this setup script: https://github.com/dlang/tools/blob/master/setup.sh Thanks. 1) With LDC make -f posix.mak HOST_DMD=ldmd (or ldmd2 - depending on your distro) 2) Release mode params --- It's defined here: https://github.com/dlang/dmd/blob/master/src/posix.mak#L242 It doesn't add -noboundscheck by default. Typically the Makefiles allow passing an initial DFLAG variable, but that one doesn't seem to allow it, so I just submitted a PR to do so (https://github.com/dlang/dmd/pull/8089). With this PR you can do: make -f posix.mak HOST_DMD=ldmd ENABLE_RELEASE=1 DFLAGS="-noboundscheck" You might want to give ENABLE_LTO a try too.
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, 26 March 2018 at 10:13:08 UTC, Simen Kjærås wrote: On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote: Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable Allow me to quote from aliak's post: what I'm looking for is a Rebindable implementation that's for value types As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types. -- Simen Though Rebindable could be improved to work with value types: https://github.com/dlang/phobos/pull/6136
Re: Homebuilt dmd fails to link my dub application
On Monday, 26 March 2018 at 10:57:28 UTC, Seb wrote: It doesn't add -noboundscheck by default. Typically the Makefiles allow passing an initial DFLAG variable, but that one doesn't seem to allow it, so I just submitted a PR to do so (https://github.com/dlang/dmd/pull/8089). With this PR you can do: make -f posix.mak HOST_DMD=ldmd ENABLE_RELEASE=1 DFLAGS="-noboundscheck" You might want to give ENABLE_LTO a try too. Thanks!
Re: C style array declaration.
On Monday, 26 March 2018 at 10:16:55 UTC, Aedt wrote: I'm a big fan of betterC. In C, you can initialize an array without specifying the length like this int ia[ ] = {0, 2, 1}; That's the equivalent of D's static arrays if a variable, and is passed to C functions as a pointer. So important to note it is two different beasts in different contexts. I recently wrote about this here: https://forum.dlang.org/thread/uhibzcfwzqzqqfbrc...@forum.dlang.org so read that post for some more detail, especially with relation to `extern` variables. Also, is it possible to retrieve the pointer of the sequence of actual data from std.container.array? If all fails I'd like to use this container. address of first element for that, but if you are using a built-in D array, you can also just `arr.ptr`.
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, March 26, 2018 10:13:08 Simen Kjærås via Digitalmars-d-learn wrote: > On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote: > > Have a look at Rebindable: > > https://dlang.org/phobos/std_typecons.html#rebindable > > Allow me to quote from aliak's post: > > what I'm looking for is a Rebindable implementation that's for > > value types > > As can be surmised from the above line, aliak has looked at > Rebindable, and it doesn't work with value types. It doesn't make sense for it to work with value types. Its entire purpose is to be able to do the equivalent of const(T)* and immutable(T)* with classes. If I correctly follow what the OP is trying to do, it's in violation of the type system. You can't cast away const or immutable like that and mutate the object. Honestly, what Rebindable does is pretty questionable as far as the type system goes, but it does what it does by forcing pointer semantics on a class reference, so the point is arguable. However, I think that the reality of the matter is that Rebindable technically breaks the type system. It just happens to do so in a way that always works, and there is no other way to do what it does. But trying to do something like struct Foo(T) { const T _member; } where you cast away const and mutate the member is definitely in violation of the type system and risks serious bugs depending on the optimizations that the compiler chooses to employ - even more so if immutable is used. - Jonathan M Davis
Re: Aggressive conditional inlining with ldc only, not dmd
On Sunday, 25 March 2018 at 22:09:43 UTC, Nordlöw wrote: eventhough I compile with -release -inline -nobounds flags. Just to make sure: are you passing -O as well?
Is socket.send thread safe?
Can I send data over an std.socket on multiple threads without manual mutexing? If not, can I send data on a separate thread than receive? The docs for std.socket say nothing of it (which I guess means I should assume it is not thread safe but...). Thanks!
Re: Is socket.send thread safe?
On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote: Can I send data over an std.socket on multiple threads without manual mutexing? If not, can I send data on a separate thread than receive? The docs for std.socket say nothing of it (which I guess means I should assume it is not thread safe but...). Thanks! Define thread safe. It's safe in the way that the buffers each call to send will have will be what you expect. Ex. thread1 sends [1,2,3] and thread2 sends [4,5,6] then you're guaranteed that what you receive would be [1,2,3] and [4,5,6]. What it isn't safe from would be race conditions. So you don't know if you get it like [1,2,3,4,5,6] or [4,5,6,1,2,3]. So if the order of the buffer matters then you should use a mutex, but if the order doesn't matter then you don't need to.
Re: Aggressive conditional inlining with ldc only, not dmd
On Monday, 26 March 2018 at 16:02:30 UTC, Rene Zwanenburg wrote: On Sunday, 25 March 2018 at 22:09:43 UTC, Nordlöw wrote: eventhough I compile with -release -inline -nobounds flags. Just to make sure: are you passing -O as well? Yes I am, thanks, via the dub spec buildType "release-nobounds" { dflags "-mcpu=native" "-O3" buildOptions "releaseMode" "optimize" "noBoundsCheck" "inline" } I didn't measure any significant difference between -O and -O3. Is each optimization level `x` in `-Ox` defined in the same way for clang and ldc? If so, where's the best documentation for it?
Re: Aggressive conditional inlining with ldc only, not dmd
On Monday, 26 March 2018 at 18:47:17 UTC, Nordlöw wrote: Yes I am, thanks, via the dub spec buildType "release-nobounds" { dflags "-mcpu=native" "-O3" buildOptions "releaseMode" "optimize" "noBoundsCheck" "inline" } I didn't measure any significant difference between -O and -O3. Is each optimization level `x` in `-Ox` defined in the same way for clang and ldc? If so, where's the best documentation for it? https://wiki.dlang.org/Using_LDC -O is equivalent to -O3
Re: Optional type - how to correctly reset a wrapped immutable T
On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote: Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable. [snip] You might look at the source for std.typecons.Nullable. They use an inout constructor.
Re: Is socket.send thread safe?
On Monday, 26 March 2018 at 17:55:10 UTC, bauss wrote: On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote: Can I send data over an std.socket on multiple threads without manual mutexing? If not, can I send data on a separate thread than receive? The docs for std.socket say nothing of it (which I guess means I should assume it is not thread safe but...). Thanks! Define thread safe. It's safe in the way that the buffers each call to send will have will be what you expect. Ex. thread1 sends [1,2,3] and thread2 sends [4,5,6] then you're guaranteed that what you receive would be [1,2,3] and [4,5,6]. What it isn't safe from would be race conditions. So you don't know if you get it like [1,2,3,4,5,6] or [4,5,6,1,2,3]. So if the order of the buffer matters then you should use a mutex, but if the order doesn't matter then you don't need to. You answered what I needed. The order of receiving the messages is not a problem, merely that a message its self is not broken, ie: [4,1,2,5,3,6](This would not work!) Thanks!
Re: Aggressive conditional inlining with ldc only, not dmd
On Monday, 26 March 2018 at 21:11:12 UTC, jmh530 wrote: Is each optimization level `x` in `-Ox` defined in the same way for clang and ldc? If so, where's the best documentation for it? https://wiki.dlang.org/Using_LDC Thx!
Building application with LDC and -flto=thin fails in link stage
When I try build my application using LDC and -flto=thin it fails in the final linking as ldmd2 -of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-0CE08DAF93E48445402E07C3537FA4E6/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-933571CC843E8D13926CEC14051E7195/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2 /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/knetquery.o:1:3: invalid character /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/knetquery.o:1:3: syntax error, unexpected $end /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/knetquery.o: not an object or archive /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o:function _start: error: undefined reference to 'main' collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 FAIL .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-9FDE475789CA2E324E9DAE6A959C2B7F/ knetquery executable ldmd2 failed with exit code 1. What could be wrong?
Re: Building application with LDC and -flto=thin fails in link stage
On Monday, 26 March 2018 at 22:07:49 UTC, Nordlöw wrote: When I try build my application using LDC and -flto=thin it fails in the final linking You must also pass `-flto=thin` during linking (a special plugin is needed for LTO, and LDC will only pass the plugin to the linker when `-flto=` is specified). I couldn't see `-flto=thin` in your link command, so I suspect that will fix it. - Johan
Re: The first example in the Learning D book, wont compile
On Sunday, 25 March 2018 at 21:02:26 UTC, Ali wrote: On Sunday, 25 March 2018 at 20:52:29 UTC, Ali wrote: On Sunday, 25 March 2018 at 20:45:58 UTC, Ali wrote: I now see my typo, should be retro, not range We need better IDEs, this would have been easily highlighted by a good ide I pasted your code into Spacemacs, and it highlighted the error immediately. What editor are you using? Graham
Atomic vs Mutex
Everywhere I look the advice is to avoid atomic and just mutex things. Why is this `a.atomicStore(b)`(memory order is seq) less safe than `synchronized{a=b}`? I get that when more operations or shared values are used it is appropriate to mutex the entire set of operations but why would I for a single set? If the first is in fact less safe that the second then I am eager to learn more, could you recommend a book or paper on the subject? Thanks!
Re: Building application with LDC and -flto=thin fails in link stage
On Monday, 26 March 2018 at 22:13:02 UTC, Johan Engelen wrote: On Monday, 26 March 2018 at 22:07:49 UTC, Nordlöw wrote: When I try build my application using LDC and -flto=thin it fails in the final linking You must also pass `-flto=thin` during linking (a special plugin is needed for LTO, and LDC will only pass the plugin to the linker when `-flto=` is specified). I couldn't see `-flto=thin` in your link command, so I suspect that will fix it. - Johan I added `lflags` to my dub configuration as buildType "release-nobounds-lto" { buildOptions "releaseMode" "optimize" "inline" "noBoundsCheck" # TODO -march=native -ffast-math dflags "-mcpu=native" "-O3" "-flto=thin" platform="posix-ldc" lflags "-flto=thin" platform="posix-ldc" } forwarded as `-L-flto=thin` but still errors as Linking... ldmd2 -of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-flto=thin -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2 /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o:1:3: invalid character /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o:1:3: syntax error, unexpected $end /usr/bin/ld: error: .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o: not an object or archive /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o:function _start: error: undefined reference to 'main' collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 FAIL .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/ knetquery executable ldmd2 failed with exit code 1.
Re: Atomic vs Mutex
On Monday, March 26, 2018 23:15:42 Jonathan via Digitalmars-d-learn wrote: > Everywhere I look the advice is to avoid atomic and just mutex > things. > > Why is this `a.atomicStore(b)`(memory order is seq) less safe > than `synchronized{a=b}`? I get that when more operations or > shared values are used it is appropriate to mutex the entire set > of operations but why would I for a single set? > > If the first is in fact less safe that the second then I am eager > to learn more, could you recommend a book or paper on the subject? I think that what it mostly comes down to is that it's harder to get atomics right than it is to get mutexes right. It can be very difficult to write lock-free code - especially when you're dealing with more complicated objects like containers. It can already be surprisingly difficult to get mutexs right. People screw up thread-safety stuff all the time. The fact that D uses thread-local by default reduces the problem, but then folks frequently get annoyed with the restrictions that shared has and end up using __gshared, throwing away all of the protections and risking bugs due to the fact that the compiler assumes that the objects are thread-local. The biggest thing that you can do in a program to make it thread-safe is to make as much as possible thread-local and have as little as possible shared between threads. Also, it's frequently considered better practice to use message passing such as you get with std.concurrency than directly sharing data. Unfortunately, I don't really have any reading that I could recommend on the subject. There's always the section on concurrency in TDPL (which IIRC is a chapter which is actually available for free), but it's mostly talking about the D-specific issues and doesn't say anything about atomics (IIRC, core.atomic didn't even exist when TDPL was written). I expect that there are quite a few resources online talking about C++ atomics though. IIRC, their API goes about things in a different way, but the basic concepts are the same. All of the basic concepts are the same in C++ as they are in D. It's just that D objects are thread-local by default, which means that the type system helps you keep things thread-safe in a way that C++ doesn't. With shared, you're generally forced to cast it away while the mutex is locked, whereas in C++, since there is no shared, it just lets you muck with shared objects as if they were thread-local without any casting. In D, atomics are pretty much the only way to do much with shared without casting it away in protected sections of code. - Jonathan M Davis
D RAII with postblit disabled
Hi All, What's the best way to do this in D? E.g. --- struct O { int* value; @disable this(this); /+ this() { this.value = theAllocator.make!int(99); } +/ ~this() { theAllocator.dispose(this.value); } } O obj = O(); // Ideally this would be allocated but it simply run O.init --- Thanks Norm
Re: D RAII with postblit disabled
On Tuesday, 27 March 2018 at 02:35:23 UTC, Norm wrote: What's the best way to do this in D? I'd also add `@disable this();` and then a `static O make() { return O(theAllocator.make!int(99)); }` than you construct it with that static make function.
Re: D RAII with postblit disabled
On Tuesday, 27 March 2018 at 02:43:15 UTC, Adam D. Ruppe wrote: On Tuesday, 27 March 2018 at 02:35:23 UTC, Norm wrote: What's the best way to do this in D? I'd also add `@disable this();` and then a `static O make() { return O(theAllocator.make!int(99)); }` than you construct it with that static make function. Perfect, thanks.
Re: Optional type - how to correctly reset a wrapped immutable T
On Sunday, 25 March 2018 at 23:00:11 UTC, Simen Kjærås wrote: On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote: struct Optional(T) { Unqual!T value; opAssign(T t) { value = cast(Unqual!T)(t); } } Consider this case: Optional!(immutable int) a = some(3); immutable int* p = &a.value; a = some(5); Ahh, bugger. As for the problems you've had with inout, I wrote this template a few years back: This template seems to substitute type qualifiers from the FromType to any inout qualifiers in the ToType yes? I'm not sure how I'd use this actually. I would like to support the inout usecase when a user does Optional!(inout int) a = 3; // for e.g. I guess for that template I'd need to have some extra information that tells me what to substitute inout with yeah? Of course, if Optional offers no way to get a reference to the wrapped value (say, if a.value is an @property function that doesn't return ref T), then using Unqual internally is safe*. This thought crossed my mind as well, value should be private anyway, and there's an unwrap function that provides a pointer to the value if it exists, so I wouldn't know how to get around that (return a dynamic array with one or no element that contains a copy and only if it's immutable, else return a pointer? erm ... O_o ) and then I was thinking compiler optimizations may throw in wrench in that if I did find a way around. unittest { immutable a = Foo(new int(3)); assert(*a.p == 3); // Passes Optional!(immutable(Foo)) b; b = a; assert(*a.p == 3); // Fails } There actually is a workaround for this, using destroy() and move() instead of assignment. I'm unsure if there are other corner cases to consider. I'm curious what the move/destroy workaround would be? Cheers, - Ali
Re: Is socket.send thread safe?
On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote: Can I send data over an std.socket on multiple threads without manual mutexing? If not, can I send data on a separate thread than receive? The docs for std.socket say nothing of it (which I guess means I should assume it is not thread safe but...). It’s thin-wrapper over system interface. It’s thread-safe in that system will not topple over, you will likely get some interleaving of data. HOWEVER: there is such a thing as short-writes, which means that since OS buffer may fill up it could write less then you intended to and return that amount. It certainly happens with O_NONBLOCK. In normal blocking mode it might work, but in general it’s a bad idea to do writes to a single socket from multiple threads w/o some coordination s.t. only can do it at any given time. Lastly as far as guarantees go, POSIX doesn’t state that 2 writes will be interleaved “exactly”, it may for instance splice them zebra-style by some chunk size and I could imagine why (on long buffers). My suggestion is to have a queue of messages and a thread to send them. You might also want to check and see if there is a better protocol then TCP to take advantage of unordered messages. I think there is at least RDP (reliable datagram protocol) on Linux that might fit the bill. Thanks!
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, 26 March 2018 at 21:17:10 UTC, jmh530 wrote: On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote: Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable. [snip] You might look at the source for std.typecons.Nullable. They use an inout constructor. Unfortunately Nullable!(inout int) b = 3; produces that compiler error. This seems more a case on how T is stored than about construction in particular. Was interesting to see a use case for hasElaborateAssign though! By the by, how come inout has to be stack based and const/immutable/mutable doesn't? Isn't inout just one of those depending on context? Cheers, - Ali
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, 26 March 2018 at 11:19:31 UTC, Seb wrote: On Monday, 26 March 2018 at 10:13:08 UTC, Simen Kjærås wrote: On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote: Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable Allow me to quote from aliak's post: what I'm looking for is a Rebindable implementation that's for value types As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types. -- Simen Though Rebindable could be improved to work with value types: https://github.com/dlang/phobos/pull/6136 And of course Seb knows about a related PR :p Will take a look to see what kind of magic is in there. Thanks !
importPaths option in dub
Hello! I work using Linux. Is it possible to use environment variables like $HOME in option importPaths of Dub project file? I tried it but dub concatenates the path and current path so I get something like this /develop/project/$HOME/.dub/packages/gtk-d/generated/gtkd or /develop/project/~/.dub/packages/gtk-d/generated/gtkd. I can use $HOME in lflags-posix so it work perfectly. Dub 1.8.0 DMD 2.079 Thanks in advance!