Re: unittests, dub and libraries
On Wednesday, 28 March 2018 at 03:07:23 UTC, Jonathan M Davis wrote: Run dub test The problem is that an executable needs a main, and a library doesn't have one, whereas when you're testing a library, you need an executable. So, a main must be inserted - e.g. with the -main flag to dmd. Just building the unittest build doesn't insert one. However, dub test _does_ deal with that for you. Thanks.
Re: unittests, dub and libraries
On Wednesday, March 28, 2018 02:16:59 Joe via Digitalmars-d-learn wrote: > I'm trying to build a very simple library. For now it just has a > single class, constructor, destructor and one method. I added a > unit test right after the method, declared the targetType to be > "library" and a buildType of "unittest" (with options > "unittests", "debugMode", "debugInfo"). When I run > >dub run -b unittest > > it builds the library, but then says: > >Target is a library. Skipping execution. > > If I compile with ldc2 -unittest the linker throws the error: > >(.text+0x20): undefined reference to `main' > > If I add an empty main function to the source file, ldc2/gcc > manage to create an executable that can be invoked manually and > it runs through the unit test. > > Is this the best that can be done? Run dub test The problem is that an executable needs a main, and a library doesn't have one, whereas when you're testing a library, you need an executable. So, a main must be inserted - e.g. with the -main flag to dmd. Just building the unittest build doesn't insert one. However, dub test _does_ deal with that for you. - Jonathan M Davis
unittests, dub and libraries
I'm trying to build a very simple library. For now it just has a single class, constructor, destructor and one method. I added a unit test right after the method, declared the targetType to be "library" and a buildType of "unittest" (with options "unittests", "debugMode", "debugInfo"). When I run dub run -b unittest it builds the library, but then says: Target is a library. Skipping execution. If I compile with ldc2 -unittest the linker throws the error: (.text+0x20): undefined reference to `main' If I add an empty main function to the source file, ldc2/gcc manage to create an executable that can be invoked manually and it runs through the unit test. Is this the best that can be done?
Re: Checking if a structs .init value is zero bits only
On Wednesday, 28 March 2018 at 00:15:34 UTC, Per Nordlöw wrote: Is there a way to check if a struct `S` can be initialized using zero bits only, so that we can allocate and initialize an array of `S` in one go using `calloc`? If not, what should such a trait look like? Have a look at: https://github.com/dlang/phobos/pull/6024 (review/feedbackon this PR is welcome!)
Re: Checking if a structs .init value is zero bits only
On 03/27/2018 05:15 PM, Per Nordlöw wrote:
Is there a way to check if a struct `S` can be initialized using zero
bits only, so that we can allocate and initialize an array of `S` in one
go using `calloc`? If not, what should such a trait look like?
The following idea should work. One question that I'm not certain about
is whether padding bytes inside .init can ever be non-zero in D. I
assumed they are always zero. If not, the same idea must be applied
recursively to individual members.
bool allZeros(T)() {
// Yes, this can be implemented as a range algorithm. :)
T t;
foreach (b; (cast(ubyte*))[0..T.sizeof]) {
if (b) {
return false;
}
}
return true;
}
unittest {
static struct A {
int i;
long l;
}
static struct B {
double d;
}
assert(allZeros!A);
assert(!allZeros!B);
}
void main() {
}
Ali
Checking if a structs .init value is zero bits only
Is there a way to check if a struct `S` can be initialized using zero bits only, so that we can allocate and initialize an array of `S` in one go using `calloc`? If not, what should such a trait look like?
Re: utf.d codeLength asserts false on certain input
On Tuesday, March 27, 2018 23:29:57 Anonymouse via Digitalmars-d-learn
wrote:
> My IRC bot is suddenly seeing crashes. It reads characters from a
> Socket into an ubyte[] array, then idups parts of that (full
> lines) into strings for parsing. Parsing involves slicing such
> strings into meaningful segments; sender, event type, target
> channel/user, message content, etc. I can assume all of them to
> be char[]-compliant except for the content field.
>
> Running it in a debugger I see I'm tripping an assert in utf.d[1]
> when calling stripRight on a content slice[2].
>
> > /++
> >
> > Returns the number of code units that are required to
> >
> > encode the code point
> >
> > $(D c) when $(D C) is the character type used to encode it.
> >
> > +/
> >
> > ubyte codeLength(C)(dchar c) @safe pure nothrow @nogc
> > if (isSomeChar!C)
> > {
> >
> > static if (C.sizeof == 1)
> > {
> >
> > if (c <= 0x7F) return 1;
> > if (c <= 0x7FF) return 2;
> > if (c <= 0x) return 3;
> > if (c <= 0x10) return 4;
> > assert(false); // <--
> >
> > }
> > // ...
>
> This trips it:
> > import std.string;
> >
> > void main()
> > {
> >
> > string s = "\355\342\256 \342\245\341⮢\256\245
> >
> > ᮮ\241饭\250\245".stripRight; // <-- asserts false
> > }
>
> The real backtrace:
> > #0 _D3std3utf__T10codeLengthTaZQpFNaNbNiNfwZh (c=26663461) at
> > /usr/include/dlang/dmd/std/utf.d:2530
> > #1 0x5578d7aa in
> > _D3std6string__T10stripRightTAyaZQrFQhZ14__foreachbody2MFNaNbNiNfKmKwZi
> > (this=0x7fff99c0, __applyArg1=@0x7fff9978: 26663461,
> > __applyArg0=@0x7fff9970: 17) at
> > /usr/include/dlang/dmd/std/string.d:2918 #2 0x77a47014 in
> > _aApplyRcd2 () from
> > /usr/lib/libphobos2.so.0.78
> > #3 0x5578d731 in
> > _D3std6string__T10stripRightTAyaZQrFNaNiNfQnZQq (str=...) at
> > /usr/include/dlang/dmd/std/string.d:2915
> > #4 0x558e0cc7 in
> > _D8kameloso3irc17parseSpecialcasesFNaNfKSQBnQBh9IRCParserKSQCf7ircdefs8I
> > RCEventKAyaZv (slice=..., event=...,parser=...) at
> > source/kameloso/irc.d:1184
> Should that not be an Exception, as it's based on input? I'm not
> sure where the character 26663461 came from. Even so, should it
> assert?
>
> I don't know what to do right now. I'd like to avoid sanitizing
> all lines. I could catch an Exception but not so much an
> AssertError.
>
>
> [1]: https://github.com/dlang/phobos/blob/master/std/utf.d#L2522
> [2]:
> https://github.com/zorael/kameloso/blob/master/source/kameloso/irc.d#L1184
It means that codeLength requires that dchar be a valid code point, though
the documentation doesn't say that. It probably should. It was probably
assumed that no one would try to pass it an invalid code point - especially
since it's usually called with well-known values rather than data from some
place like a socket. Regardless, the way to work around it would be to call
isValidDchar on the dchar before passing it to codeLength so that you can
handle the invalid code point rather than calling codeLength on it.
- Jonathan M Davis
utf.d codeLength asserts false on certain input
My IRC bot is suddenly seeing crashes. It reads characters from a
Socket into an ubyte[] array, then idups parts of that (full
lines) into strings for parsing. Parsing involves slicing such
strings into meaningful segments; sender, event type, target
channel/user, message content, etc. I can assume all of them to
be char[]-compliant except for the content field.
Running it in a debugger I see I'm tripping an assert in utf.d[1]
when calling stripRight on a content slice[2].
/++
Returns the number of code units that are required to
encode the code point
$(D c) when $(D C) is the character type used to encode it.
+/
ubyte codeLength(C)(dchar c) @safe pure nothrow @nogc
if (isSomeChar!C)
{
static if (C.sizeof == 1)
{
if (c <= 0x7F) return 1;
if (c <= 0x7FF) return 2;
if (c <= 0x) return 3;
if (c <= 0x10) return 4;
assert(false); // <--
}
// ...
This trips it:
import std.string;
void main()
{
string s = "\355\342\256 \342\245\341⮢\256\245
ᮮ\241饭\250\245".stripRight; // <-- asserts false
}
The real backtrace:
#0 _D3std3utf__T10codeLengthTaZQpFNaNbNiNfwZh (c=26663461) at
/usr/include/dlang/dmd/std/utf.d:2530
#1 0x5578d7aa in
_D3std6string__T10stripRightTAyaZQrFQhZ14__foreachbody2MFNaNbNiNfKmKwZi (this=0x7fff99c0, __applyArg1=@0x7fff9978: 26663461, __applyArg0=@0x7fff9970: 17) at /usr/include/dlang/dmd/std/string.d:2918
#2 0x77a47014 in _aApplyRcd2 () from
/usr/lib/libphobos2.so.0.78
#3 0x5578d731 in
_D3std6string__T10stripRightTAyaZQrFNaNiNfQnZQq (str=...) at
/usr/include/dlang/dmd/std/string.d:2915
#4 0x558e0cc7 in
_D8kameloso3irc17parseSpecialcasesFNaNfKSQBnQBh9IRCParserKSQCf7ircdefs8IRCEventKAyaZv (slice=..., event=...,parser=...) at source/kameloso/irc.d:1184
Should that not be an Exception, as it's based on input? I'm not
sure where the character 26663461 came from. Even so, should it
assert?
I don't know what to do right now. I'd like to avoid sanitizing
all lines. I could catch an Exception but not so much an
AssertError.
[1]: https://github.com/dlang/phobos/blob/master/std/utf.d#L2522
[2]:
https://github.com/zorael/kameloso/blob/master/source/kameloso/irc.d#L1184
Re: Building application with LDC and -flto=thin fails in link stage
On Tuesday, 27 March 2018 at 22:00:42 UTC, Johan Engelen wrote: Indeed. Please try to manually link first (without dub) by modifying the command on which dub errors: ``` ldmd2 -flto=thin -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-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2 ``` -Johan Yes, that works!
Re: Building application with LDC and -flto=thin fails in link stage
On Tuesday, 27 March 2018 at 13:28:08 UTC, kinke wrote: On Monday, 26 March 2018 at 23:32:59 UTC, Nordlöw wrote: forwarded as `-L-flto=thin` but still errors as Which is wrong, it's not a ld command-line option (i.e., the `-L` prefix is wrong). Indeed. Please try to manually link first (without dub) by modifying the command on which dub errors: ``` ldmd2 -flto=thin -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-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2 ``` -Johan
Re: Where is TypeInfo stored?
On Tuesday, 27 March 2018 at 19:06:38 UTC, Adam D. Ruppe wrote: On Tuesday, 27 March 2018 at 18:56:58 UTC, Jeremy DeHaan wrote: Are these put into the text or data segments? Yeah, they are in the data segment as static data (just like if you declared your own static array). Awesome, thanks. That is what I was hoping for.
Re: Where is TypeInfo stored?
On Tuesday, 27 March 2018 at 18:56:58 UTC, Jeremy DeHaan wrote: Are these put into the text or data segments? Yeah, they are in the data segment as static data (just like if you declared your own static array).
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, March 27, 2018 16:16:15 Adam D. Ruppe via Digitalmars-d-learn wrote: > On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: > > it was deemed too dangerous to have in suddenly really mean > > both scope and const, because it would potentially break a lot > > of code. > > To be frank, this pisses me off to a ridiculous extent because if > it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler > would now just be actually telling you the truth. > > And many of us have spent years describing what it is supposed to > do (it WAS documented in the spec the whole time!) and how to use > it properly, All it ever said about scope was that it prevented references from escaping. It did not explain what that meant for any particular type. Reasonable assumptions could be made about what it probably meant, but it was never actually explained. DIP 1000 explains the semantics, and it clearly goes beyond whatever might have been originally planned, because it applies scope to far more than just parameters in order to make it work. > so much code using it may actually be totally > correct, and keeping the original behavior would actually help > adoption of the new rules because more code would be compatible > with it! > > We need to stop being cowards about compile errors. The compiler > actually correctly flagging an error that it skipped before isn't > code breakage. That's FIXING broken code by actually drawing > attention to the ALREADY EXISTING bug. Well, if you want that, you'll have to talk Walter into it. In this case, I very much agree with him. Based on discussions on it in the past, and many of the questions that have popped up over the years, I think that it's quite clear that a lot of folks have been using in without really understanding it, meaning that I don't think that it's at all safe to say that the average programmer used in expecting anything like the semantics of DIP 1000, and the changes that -dip1000 requires means that scope needs to be used in a lot more places than just the function parameters, meaning that even if the programmer had meant in / const scope in the way that DIP 1000 means scope, their code is going to have quite a few compilation errors with the change. This wouldn't be a few compilation errors here and there that would catch bugs. This would be compilation errors all over the place because either in was misused and/or because scope is required in a bunch of extra places to make it work. Now, I there are enough issues with using -dip1000 that I don't know how Walter is ever going to make it the default behavior anyway. So, maybe there's room to argue that it causes enough breakage on its own that it doesn't matter if in breaks everything, but I think that it's very much a stretch to argue that most of the uses of in in the wild match what -dip1000 means. Personally, I think that it was mistake in the first place to have a keyword be an alias for another keyword - let alone two keywords - but the only way to fix that would be to deprecate in, and given that Walter's reaction was to make in const rather than deprecate it, I question that he could be talked into doing so. It _is_ used by a lot of code, whether the programmer meant anything like DIP 1000 means or not. - Jonathan M Davis
Where is TypeInfo stored?
I was doing some experiments with the runtime and I didn't notice the TypeInfo instances being allocated by the GC. Are these put into the text or data segments? Is there anyway to find out more about this process?
Re: "in" no longer "scope" since 2.079.0?
On Tue, Mar 27, 2018 at 03:27:07AM -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > > Because scope has mostly done nothing (it only affected delegates), in has > effectively been const without scope for its entire existence in D2 in spite > of the fact that it was supposed to be the same as const scope. Now that DIP > 1000 is being implemented, and scope is actually going to do something for > more than just delegates, it was deemed too dangerous to have in suddenly > really mean both scope and const, because it would potentially break a lot > of code. So, in order to prevent such breakage, in was changed to officially > only mean const instead of const scope. So, what it's meant in practice > hasn't really changed, but the spec has. > > https://issues.dlang.org/show_bug.cgi?id=17928 > > - Jonathan M Davis > FWIW, this is very much my opinion, but if I am understanding this correctly, the difference between the two prototypes below, that I just happened to be working on, (assuming they are equivalent with the old 'in' behavior) is the difference between D being really great and D being 'meh' and not much better than C++ syntax wise. void copyFrom( in size_t baseIndex, in WFFRecord from, in size_t[] args ) vs. void copyFrom( scope const size_t baseIndex, scope const WFFRecord from, scope const size_t[] args )* For me, I think the second is so much worse for two reasons: 1) The prototype is obfuscated in attribute puke and those extra few moments to separate the attributes from the parameters bring back memories of C++ and needing to put parameters on their own lines. 2) It's approaching the line length that just works all the time with whatever editor I'm in. I really hope that a better solution to 'in' is found. I'd greatly prefer breaking code (at compile time) and forcing it to be better code, but my programs are short and easy to update. Actually, if arguments to functions were default "logically input" meaning that they couldn't be changed, returned, and the compiler could make smart optimizations and pass by reference or value, etc that would be way better than needing any annotation at all. (Also @safe and maybe pure by default too, :) I'd rather opt-in to the 'this' context pointers) * I realize that scope is redundant but I'm not going to remember all the specific "rules" about it when I want to say that the argument is an INPUT and don't mutate or allow it to be be mutated it in ANY surprising way. Brian
Comparing In-Person Interpretation Vs Video Interpretation
In recent years, thanks to the rapid and continuous advancements in the field of technology, more companies are doing businesses across borders. Hence, language interpretation services have become extremely crucial in today's world. There are different types of interpretation services such as video interpretation, face-to-face interpretation, and telephone interpretation. The question is which one is the most superior. The answer to this question is that each type has its own share of pros and cons. The difference between in-person and video interpretation can be understood by trying to understand their features. In-Person Interpretation In a majority of scenarios, face-to-face interpretation is the best choice. Since an interpreter is physically present inside the room, he or she can easily read the facial expression and the body language of the speaker. Thus an in-person interpreter can easily pick up finer nuisances like when a topic requires further explanation, has a query or a speaker is confused. Video Interpretation Such an interpretation service can save your time or money. When you are unable to get a professional interpretation service nearby, the best option for you is to go for a video interpreting or telephone interpreting service. Video interpreting service is a remote one and is an excellent choice in emergency situations like at a hospital's Emergency Room. Cost is an important factor for choosing it since you need to spend more for ensuring the travel of a professional interpreter to your site. www.language-school.hk
Re: "in" no longer "scope" since 2.079.0?
On Tue, Mar 27, 2018 at 04:16:15PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: > > it was deemed too dangerous to have in suddenly really mean both > > scope and const, because it would potentially break a lot of code. > > To be frank, this pisses me off to a ridiculous extent because if it > "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler would > now just be actually telling you the truth. > > And many of us have spent years describing what it is supposed to do > (it WAS documented in the spec the whole time!) and how to use it > properly, so much code using it may actually be totally correct, and > keeping the original behavior would actually help adoption of the new > rules because more code would be compatible with it! > > We need to stop being cowards about compile errors. The compiler > actually correctly flagging an error that it skipped before isn't code > breakage. That's FIXING broken code by actually drawing attention to > the ALREADY EXISTING bug. +1. I think our current phobia of breaking existing code is getting a little too far on the side of paranoia. "Breaking" existing buggy code with a compiler error is a good thing. It's actually helping users find bugs in the code, and I'm sure any reasonable user would appreciate that! Certainly, I did when it happened to me in the past. T -- People say I'm arrogant, and I'm proud of it.
Re: How to use annotation get key name?
On Tuesday, 27 March 2018 at 15:38:48 UTC, Brian wrote:
but you don't understand my means, I want have keys with
multiple indeterminate names.
You can pass an associative array (or better yet, a struct
containing one) as a UDA and then use the regular loop over its
keys and values.
struct Table { string[string] keys_and_values; }
@Table(["name1": "users", "name2" : "users111"])
void foo() {}
D's UDAs are just a value attached to the name, so all normal
rules of types apply.
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code. To be frank, this pisses me off to a ridiculous extent because if it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler would now just be actually telling you the truth. And many of us have spent years describing what it is supposed to do (it WAS documented in the spec the whole time!) and how to use it properly, so much code using it may actually be totally correct, and keeping the original behavior would actually help adoption of the new rules because more code would be compatible with it! We need to stop being cowards about compile errors. The compiler actually correctly flagging an error that it skipped before isn't code breakage. That's FIXING broken code by actually drawing attention to the ALREADY EXISTING bug.
Re: Optional type - how to correctly reset a wrapped immutable T
On Tuesday, 27 March 2018 at 15:28:40 UTC, jmh530 wrote: static if (isMutable!T) bag[0] = rhs; else bag = [rhs]; I like this idea. I'd even take it a step futher: When T is a pointer or class reference, then we can put the reference on the stack (instead of into the array) and handle assignments like Rebindable handles assignments -- provided that Rebindable really is 100 % safe to the outside, see my concerns from 2 posts above. In this case (static if), we won't even declare the array T[] bag, and instead implement as T value, bool isPresent. When T is a mutable value type, it goes on the stack, too. Again no array. When T is a const/immutable/inout value type, we declare the array as before and rebind on assignment with bag = [rhs], as you proposed here. -- Simon
Re: How to use annotation get key name?
On Monday, 26 March 2018 at 08:50:31 UTC, Simen Kjærås wrote:
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
Thanks.
but you don't understand my means, I want have keys with multiple
indeterminate names.
Rust sample code:
#[cfg(name1 = "users", name2 = "users111")]
PHP sample code:
/*
@Table(name2 = "users", name2 = "users111")
*/
Java sample code:
@Table(name2 = "users111", name1 = "users")
How to use dlang get key name?
Don't have support get key function?
How to do?
Re: Optional type - how to correctly reset a wrapped immutable T
On Tuesday, 27 March 2018 at 13:51:20 UTC, jmh530 wrote:
How about:
[snip]
I can kind of like this more, but after re-reading your original
post I'm not sure it really resolves your issue:
struct Optional(T) {
import std.traits : isMutable;
T[] bag;
this(T t) inout {
bag = [t];
}
void opAssign(T rhs)
{
static if (isMutable!T)
bag[0] = rhs;
else
bag = [rhs];
}
}
Optional!T optional(T)(T x)
{
return Optional!T(x);
}
void main()
{
int x = 3;
const(int) xx = 3;
immutable(int) xxx = 3;
immutable(int) = 4;
auto y = optional(x);
auto yy = optional(xx);
auto yyy = optional(xxx);
yyy = ;
}
Re: Optional type - how to correctly reset a wrapped immutable T
On Monday, 26 March 2018 at 14:17:03 UTC, Jonathan M Davis wrote:
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.
Yeah, I've always assumed that Rebindable cannot be implemented
without internally breaking the type system, then exposing a safe
interface.
But this sparked my interest, I've dug out the Rebindable code:
private mixin template RebindableCommon(T, U, alias This)
if (is(T == class) || is(T == interface) ||
isAssociativeArray!T)
{
private union
{
T original; // e.g., immutable(A) for classs A
U stripped; // the unqualified type, e.g., A
}
// ...
}
Does Rebindable-using code, oblivious of the hacks inside
Rebindable, remain 100 % safe even with aggressive compiler
optimizations? For class A, inside Rebindable!(immutable A),
there is a union of (immutable A) and A. I suspect that the D
compiler is allowed to treat this reference to (immutable A) as
immutable itself. Have there never been bugs here when, later,
stripped = another.stripped;?
-- Simon
Re: Optional type - how to correctly reset a wrapped immutable T
On Tuesday, 27 March 2018 at 13:02:50 UTC, aliak wrote:
Hmm, now that I'm explicitly trying to produce it, I feel I
maybe using inout incorrectly?
struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}
struct S {
Optional!(inout(int)) f() inout
{
return Optional!(inout(int))(3);
}
}
void main()
{
auto a = S().f;
}
Above gives: Error: variable
`onlineapp.Optional!(inout(int)).Optional.bag` only parameters
or stack based variables can be inout
Change inout to const e.g. and it's all good.
You may refer to the section on struct constructors. inout on a
constructor serves as both a const and an immutable constructor.
This would allow you to create mutable/const/immutable objects of
whatever struct. The payload could have some different setting.
https://dlang.org/spec/struct.html#struct-constructor
How about:
struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}
Optional!T optional(T)(T x)
{
return Optional!T(x);
}
void main()
{
int x = 3;
const(int) xx = 3;
immutable(int) xxx = 3;
auto y = optional(x);
auto yy = optional(xx);
auto yyy = optional(xxx);
}
Re: Building application with LDC and -flto=thin fails in link stage
On Monday, 26 March 2018 at 23:32:59 UTC, Nordlöw wrote: forwarded as `-L-flto=thin` but still errors as Which is wrong, it's not a ld command-line option (i.e., the `-L` prefix is wrong). I don't use dub though, so I don't know how to fix it.
Re: Optional type - how to correctly reset a wrapped immutable T
On Tuesday, 27 March 2018 at 11:57:28 UTC, jmh530 wrote:
On Tuesday, 27 March 2018 at 06:26:57 UTC, aliak wrote:
[snip]
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?
Example?
Hmm, now that I'm explicitly trying to produce it, I feel I maybe
using inout incorrectly?
struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}
struct S {
Optional!(inout(int)) f() inout
{
return Optional!(inout(int))(3);
}
}
void main()
{
auto a = S().f;
}
Above gives: Error: variable
`onlineapp.Optional!(inout(int)).Optional.bag` only parameters or
stack based variables can be inout
Change inout to const e.g. and it's all good.
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, 27 March 2018 at 11:24:01 UTC, Jonathan M Davis wrote: On Tuesday, March 27, 2018 09:58:11 bauss via Digitalmars-d-learn wrote: On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: > [...] So now "in" is basically just an alias and serves no real purpose or is there a plan to eventually make "in" mean something other than just "const"? There are no plans at this point to change the meaning of in again. It has been suggested that maybe we could deprecate in and reintroduce it as meaning const scope later, but nothing has been decided beyond the fact that in now officially is just const, because too much code would break when -dip1000 became the normal behavior if in meant const scope. Well, that's not entirely true - there's a PR: https://github.com/dlang/dmd/pull/8021 and it's not too unlikely that it will be part of the DIP1000 change or maybe get its own transition period. Deprecation it and reintroducing doesn't seem to be super popular.
Re: Is there something special required to use Appender.clear
On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper wrote: Sorry if this is a stupid question, but is there something special required to call Appender.clear? When I attempt even just a simple use I am getting compile errors relating to `template object.clear`. From the documentation for Appender: Note clear is disabled for immutable or const element types, due to the possibility that Appender might overwrite immutable data. Since string is immutable(char)[], clear() is simply not available for appender!string. -- Simen
Re: Is there something special required to use Appender.clear
On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper wrote:
Sorry if this is a stupid question, but is there something
special required to call Appender.clear? When I attempt even
just a simple use I am getting compile errors relating to
`template object.clear`.
When I try:
import std.array;
void main(string[] args){
auto foo = appender!string;
foo.clear;
}
I receive the following output:
$ ldc2 source/tmp.d
source/tmp.d(5): Error: template object.clear cannot deduce
function from argument types !()(Appender!string), candidates
are:
/usr/local/include/d/ldc/object.d(2041):
object.clear(T : Value[Key], Value, Key)(T aa)
/usr/local/include/d/ldc/object.d(2046):
object.clear(T : Value[Key], Value, Key)(T* aa)
$ dmd source/tmp.d
source/tmp.d(5): Error: template object.clear cannot deduce
function from argument types !()(Appender!string), candidates
are:
/usr/include/dmd/druntime/import/object.d(1983):
object.clear(T : Value[Key], Value, Key)(T aa)
/usr/include/dmd/druntime/import/object.d(1988):
object.clear(T : Value[Key], Value, Key)(T* aa)
versions:
$ dmd --version
DMD64 D Compiler v2.078.0
Copyright (c) 1999-2017 by The D Language Foundation
written by Walter Bright
$ ldc2 --version
LDC - the LLVM D compiler (1.8.0git-921bb7f):
based on DMD v2.078.3 and LLVM 4.0.1
built with DMD64 D Compiler v2.078.0
Is there something I am missing here?
Thanks
I would say that's a bug, because it seems like it's trying to
get the clear() function used for associative arrays.
Re: Is there something special required to use Appender.clear
On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper wrote:
Sorry if this is a stupid question, but is there something
special required to call Appender.clear? When I attempt even
just a simple use I am getting compile errors relating to
`template object.clear`.
When I try:
import std.array;
void main(string[] args){
auto foo = appender!string;
foo.clear;
}
Appender only implements clear for mutable types, and string is
an array of immutables. I'm not sure but it looks like you're
hitting the associative array clear by UFCS instead?
Make it Appender!(char[]) and it will work.
// only allow overwriting data on non-immutable and non-const
data
static if (isMutable!T)
{
/**
* Clears the managed array. This allows the elements of
the array to be reused
* for appending.
*
* Note: clear is disabled for immutable or const element
types, due to the
* possibility that $(D Appender) might overwrite
immutable data.
*/
void clear() @trusted pure nothrow
{
if (_data)
{
_data.arr = _data.arr.ptr[0 .. 0];
}
}
[...]
https://github.com/dlang/phobos/blob/master/std/array.d#L3140
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, 27 March 2018 at 11:24:01 UTC, Jonathan M Davis wrote: On Tuesday, March 27, 2018 09:58:11 bauss via Digitalmars-d-learn wrote: On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: > On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via > > Digitalmars-d-learn wrote: >> Hello! Can someone point me to the changelong entry or >> maybe a pull request, wich changed the "in" from "scope >> const" to "const"? I thought the previous matter of things >> was pretty natural, and current "in" is now redundant. >> Would be glad to read up on this design decision. >> >> https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters> > Because scope has mostly done nothing (it only affected > delegates), in has effectively been const without scope for > its entire existence in D2 in spite of the fact that it was > supposed to be the same as const scope. Now that DIP 1000 is > being implemented, and scope is actually going to do > something for more than just delegates, it was deemed too > dangerous to have in suddenly really mean both scope and > const, because it would potentially break a lot of code. So, > in order to prevent such breakage, in was changed to > officially only mean const instead of const scope. So, what > it's meant in practice hasn't really changed, but the spec > has. > > https://issues.dlang.org/show_bug.cgi?id=17928 > > - Jonathan M Davis So now "in" is basically just an alias and serves no real purpose or is there a plan to eventually make "in" mean something other than just "const"? There are no plans at this point to change the meaning of in again. It has been suggested that maybe we could deprecate in and reintroduce it as meaning const scope later, but nothing has been decided beyond the fact that in now officially is just const, because too much code would break when -dip1000 became the normal behavior if in meant const scope. But the reality of the matter is that in has never served any real purpose. In theory, it was supposed to mean const scope, but scope has never meant anything for parameters that weren't delegates, and it was never really defined as to what scope would mean for anything other than delegates. There were plenty of assumptions about it made by folks, but the reality is that scope has never been well-defined. Lots of folks have used in either because they thought that it would benefit their code once some sort of enforcement was added to scope for types other than delegates, and plenty of folks have used in simply because they thought that it went well with out. But it has always been the case that they would have gotten the same effect by using const rather than in. Plenty of folks have never understood that, since the spec was never clear on the matter, but that's how it's always been. So, really, all that's changed is that the spec now reflects reality. The only hope of in ever serving any real purpose was if scope were finally implemented to mean something for non-delegates. That's happening with DIP 1000, but it's happening in 2018, and while Walter might have been willing to break code that used in or scope incorrectly in 2010, he's a lot less willing to break code now. So, the fact that it took so long for anything to happen with scope pretty much guaranteed that in would never really mean const scope. The only hope of that changing would involve some sort of deprecation of in, but there are not currently any plans for such. - Jonathan M Davis Thanks, that explains a lot and makes sense.
Is there something special required to use Appender.clear
Sorry if this is a stupid question, but is there something
special required to call Appender.clear? When I attempt even
just a simple use I am getting compile errors relating to
`template object.clear`.
When I try:
import std.array;
void main(string[] args){
auto foo = appender!string;
foo.clear;
}
I receive the following output:
$ ldc2 source/tmp.d
source/tmp.d(5): Error: template object.clear cannot deduce
function from argument types !()(Appender!string), candidates are:
/usr/local/include/d/ldc/object.d(2041):
object.clear(T : Value[Key], Value, Key)(T aa)
/usr/local/include/d/ldc/object.d(2046):
object.clear(T : Value[Key], Value, Key)(T* aa)
$ dmd source/tmp.d
source/tmp.d(5): Error: template object.clear cannot deduce
function from argument types !()(Appender!string), candidates are:
/usr/include/dmd/druntime/import/object.d(1983):
object.clear(T : Value[Key], Value, Key)(T aa)
/usr/include/dmd/druntime/import/object.d(1988):
object.clear(T : Value[Key], Value, Key)(T* aa)
versions:
$ dmd --version
DMD64 D Compiler v2.078.0
Copyright (c) 1999-2017 by The D Language Foundation written
by Walter Bright
$ ldc2 --version
LDC - the LLVM D compiler (1.8.0git-921bb7f):
based on DMD v2.078.3 and LLVM 4.0.1
built with DMD64 D Compiler v2.078.0
Is there something I am missing here?
Thanks
Re: Optional type - how to correctly reset a wrapped immutable T
On Tuesday, 27 March 2018 at 06:26:57 UTC, aliak wrote: [snip] 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? Example?
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, March 27, 2018 09:58:11 bauss via Digitalmars-d-learn wrote: > On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: > > On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via > > > > Digitalmars-d-learn wrote: > >> Hello! Can someone point me to the changelong entry or maybe a > >> pull request, wich changed the "in" from "scope const" to > >> "const"? I thought the previous matter of things was pretty > >> natural, and current "in" is now redundant. Would be glad to > >> read up on this design decision. > >> > >> https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters > >> https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters> > > Because scope has mostly done nothing (it only affected > > delegates), in has effectively been const without scope for its > > entire existence in D2 in spite of the fact that it was > > supposed to be the same as const scope. Now that DIP 1000 is > > being implemented, and scope is actually going to do something > > for more than just delegates, it was deemed too dangerous to > > have in suddenly really mean both scope and const, because it > > would potentially break a lot of code. So, in order to prevent > > such breakage, in was changed to officially only mean const > > instead of const scope. So, what it's meant in practice hasn't > > really changed, but the spec has. > > > > https://issues.dlang.org/show_bug.cgi?id=17928 > > > > - Jonathan M Davis > > So now "in" is basically just an alias and serves no real purpose > or is there a plan to eventually make "in" mean something other > than just "const"? There are no plans at this point to change the meaning of in again. It has been suggested that maybe we could deprecate in and reintroduce it as meaning const scope later, but nothing has been decided beyond the fact that in now officially is just const, because too much code would break when -dip1000 became the normal behavior if in meant const scope. But the reality of the matter is that in has never served any real purpose. In theory, it was supposed to mean const scope, but scope has never meant anything for parameters that weren't delegates, and it was never really defined as to what scope would mean for anything other than delegates. There were plenty of assumptions about it made by folks, but the reality is that scope has never been well-defined. Lots of folks have used in either because they thought that it would benefit their code once some sort of enforcement was added to scope for types other than delegates, and plenty of folks have used in simply because they thought that it went well with out. But it has always been the case that they would have gotten the same effect by using const rather than in. Plenty of folks have never understood that, since the spec was never clear on the matter, but that's how it's always been. So, really, all that's changed is that the spec now reflects reality. The only hope of in ever serving any real purpose was if scope were finally implemented to mean something for non-delegates. That's happening with DIP 1000, but it's happening in 2018, and while Walter might have been willing to break code that used in or scope incorrectly in 2010, he's a lot less willing to break code now. So, the fact that it took so long for anything to happen with scope pretty much guaranteed that in would never really mean const scope. The only hope of that changing would involve some sort of deprecation of in, but there are not currently any plans for such. - Jonathan M Davis
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 as According to LDC's Release info: Known issues: ThinLTO may not work well with the ld.bfd linker, use ld.gold instead (-linker=gold). Maybe this is the problem. Arek
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via Digitalmars-d-learn wrote: Hello! Can someone point me to the changelong entry or maybe a pull request, wich changed the "in" from "scope const" to "const"? I thought the previous matter of things was pretty natural, and current "in" is now redundant. Would be glad to read up on this design decision. https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters Because scope has mostly done nothing (it only affected delegates), in has effectively been const without scope for its entire existence in D2 in spite of the fact that it was supposed to be the same as const scope. Now that DIP 1000 is being implemented, and scope is actually going to do something for more than just delegates, it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code. So, in order to prevent such breakage, in was changed to officially only mean const instead of const scope. So, what it's meant in practice hasn't really changed, but the spec has. https://issues.dlang.org/show_bug.cgi?id=17928 - Jonathan M Davis So now "in" is basically just an alias and serves no real purpose or is there a plan to eventually make "in" mean something other than just "const"?
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote: On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via Now that DIP 1000 is being implemented, and scope is actually going to do something for more than just delegates, it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code. So, in order to prevent such breakage, in was changed to officially only mean const instead of const scope. https://issues.dlang.org/show_bug.cgi?id=17928 - Jonathan M Davis Well, here I am, writing "in" everywhere in anticipation of DIP1k ) But I guess "do not break" at this point is indeed more important. Thanks.
Re: "in" no longer "scope" since 2.079.0?
On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via Digitalmars-d-learn wrote: > Hello! Can someone point me to the changelong entry or maybe a > pull request, wich changed the "in" from "scope const" to > "const"? I thought the previous matter of things was pretty > natural, and current "in" is now redundant. Would be glad to read > up on this design decision. > > https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters > https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters Because scope has mostly done nothing (it only affected delegates), in has effectively been const without scope for its entire existence in D2 in spite of the fact that it was supposed to be the same as const scope. Now that DIP 1000 is being implemented, and scope is actually going to do something for more than just delegates, it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code. So, in order to prevent such breakage, in was changed to officially only mean const instead of const scope. So, what it's meant in practice hasn't really changed, but the spec has. https://issues.dlang.org/show_bug.cgi?id=17928 - Jonathan M Davis
"in" no longer "scope" since 2.079.0?
Hello! Can someone point me to the changelong entry or maybe a pull request, wich changed the "in" from "scope const" to "const"? I thought the previous matter of things was pretty natural, and current "in" is now redundant. Would be glad to read up on this design decision. https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters
Re: Truly automatic benchmarking
On Tuesday, 27 March 2018 at 08:41:41 UTC, bauss wrote: Perhaps https://dlang.org/phobos/std_datetime_stopwatch.html#benchmark ? That fulfils neither of my two requirements mentioned in above; it requires explicit iteration count given by the caller and no automatic printing of results.
Re: Truly automatic benchmarking
On Tuesday, 27 March 2018 at 08:18:43 UTC, Nordlöw wrote: Have anybody implemented anything near the expressiveness and ease of use of Rust's builtin benchmarking features https://doc.rust-lang.org/1.16.0/book/benchmark-tests.html I'm mostly interested in completely automatic printing of results such as test tests::bench_add_two ... bench: 1 ns/iter (+/- 0) and letting the benchmarking library (like in Rust) itself figure out the suitable number of iterations a function should be tested based on some heuristics on how long one iteration takes and some default upper wall clock time limit. Perhaps https://dlang.org/phobos/std_datetime_stopwatch.html#benchmark ?
Truly automatic benchmarking
Have anybody implemented anything near the expressiveness and ease of use of Rust's builtin benchmarking features https://doc.rust-lang.org/1.16.0/book/benchmark-tests.html I'm mostly interested in completely automatic printing of results such as test tests::bench_add_two ... bench: 1 ns/iter (+/- 0) and letting the benchmarking library (like in Rust) itself figure out the suitable number of iterations a function should be tested based on some heuristics on how long one iteration takes and some default upper wall clock time limit.
Re: importPaths option in dub
On Tuesday, 27 March 2018 at 06:34:29 UTC, ANtlord wrote: 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! I don't think so, but someone could correct me. I just remember having tried with something similar in the past, but it was sourcePath I think?
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!
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 !
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: 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 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 = 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
