Re: LDC with ARM backend
On Thursday, 21 July 2016 at 13:13:39 UTC, Claude wrote: On Thursday, 21 July 2016 at 10:30:55 UTC, Andrea Fontana wrote: On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote: I can build a "Hello world" program on ARM GNU/Linux, with druntime and phobos. I'll write a doc page about that. It's a good idea :) Done: https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux I based it totally on Kai's previous page for LDC on Android. It lacks the build for druntime/phobos unit-tests. Thanks! That's really awesome! Did you manage to build more complex applications? EABI is a bit different from the hardfloat ABI and there may be still bugs lurking in LDC... Regards, Kai
Re: winsamp.d dont compiler.
On Monday, 1 August 2016 at 00:27:27 UTC, Sean Campbell wrote: On Sunday, 31 July 2016 at 23:36:54 UTC, Cassio Butrico wrote: [...] There was changes made to core.sys.windows so it defaults to unicode. Try dmd winsamp gdi32.lib winsamp.def -version=ANSI or change all of the xxxA functions to xxxW and use toUTF16z (in stf.utf) instead of toStringz. thanks for listening I will try
Re: winsamp.d dont compiler.
On Sunday, 31 July 2016 at 23:36:54 UTC, Cassio Butrico wrote: in C:\d\dmd2\samples\d winsamp.d dont compiler. dmd winsamp gdi32.lib winsamp.def winsamp.d(53): Error: function core.sys.windows.winuser.LoadIconA (void*, const(char)*) is not callable using argument types (typeof(null), wchar*) winsamp.d(54): Error: function core.sys.windows.winuser.LoadCursorA (void*, const(char)*) is not callable using argument types (typeof(null), wchar*) winsamp.d(57): Error: cannot implicitly convert expression (toStringz(className)) of type immutable(char)* to const(wchar)* winsamp.d(59): Error: function core.sys.windows.winuser.RegisterClassA (const(WNDCLASSA)*) is not callable using argument types (WNDCLASSW*) --- errorlevel 1 There was changes made to core.sys.windows so it defaults to unicode. Try dmd winsamp gdi32.lib winsamp.def -version=ANSI or change all of the xxxA functions to xxxW and use toUTF16z (in stf.utf) instead of toStringz.
winsamp.d dont compiler.
in C:\d\dmd2\samples\d winsamp.d dont compiler. dmd winsamp gdi32.lib winsamp.def winsamp.d(53): Error: function core.sys.windows.winuser.LoadIconA (void*, const(char)*) is not callable using argument types (typeof(null), wchar*) winsamp.d(54): Error: function core.sys.windows.winuser.LoadCursorA (void*, const(char)*) is not callable using argument types (typeof(null), wchar*) winsamp.d(57): Error: cannot implicitly convert expression (toStringz(className)) of type immutable(char)* to const(wchar)* winsamp.d(59): Error: function core.sys.windows.winuser.RegisterClassA (const(WNDCLASSA)*) is not callable using argument types (WNDCLASSW*) --- errorlevel 1
Re: FP magic in std.math.pow
On Sunday, 31 July 2016 at 22:38:59 UTC, Seb wrote:
Consider this short program:
void main()
{
alias S = float;
S s1 = 0x1.24c92ep+5;
S s2 = -0x1.1c71c8p+0;
[...]
It's an anoying feature.
The reason this is not implemented in dmd is that pow does not
map to a simple cpu instruction on x86.
I will have another shot at fixing this once the CTFE stuff is in.
FP magic in std.math.pow
Consider this short program:
void main()
{
alias S = float;
S s1 = 0x1.24c92ep+5;
S s2 = -0x1.1c71c8p+0;
import std.math : std_pow = pow;
import core.stdc.stdio : printf;
import core.stdc.math: powf;
printf("std: %a\n", std_pow(s1, s2));
printf("pow: %a\n", s1 ^^ s2);
printf("pow: %a\n", powf(s1, s2));
version(LDC)
{
import ldc.intrinsics : llvm_pow;
printf("ldc: %a\n", llvm_pow(s1, s2));
}
}
std: 0x1.2c155ap-6
pow: 0x1.2c155ap-6
powf: 0x1.2c1558p-6
As you can see below the C powf compiles to the assembly powf and
LDC compiles to powf too. The output of std.math.pow is rather
large, hence not listed.
1) Is this a bug in Phobos or just a very annoying "feature"?
2) I thought that DMD was decoupled from Phobos? So I was very
astonished to see that it's not (see [1])
[1]
https://github.com/dlang/dmd/blob/master/src/expression.d#L14781
```
.text._Dmainsegment
assume CS:.text._Dmain
_Dmain:
pushRBP
mov RBP,RSP
sub RSP,010h
movss XMM0,FLAT:.rodata[00h][RIP]
movss -8[RBP],XMM0
movss XMM1,FLAT:.rodata[00h][RIP]
movss -4[RBP],XMM1
movss XMM1,-4[RBP]
movss XMM0,-8[RBP]
call powf@PC32
cvtss2sdXMM0,XMM0
mov EDI,offset FLAT:.rodata@32
mov AL,1
call printf@PC32
xor EAX,EAX
leave
ret
0f1f
add 0[RCX],AL
.text._Dmainends
```
Re: Converting int to dchar?
That's a really informative response. Thank you!
Re: Converting int to dchar?
Am 31.07.2016 um 23:46 schrieb Seb:
> On Sunday, 31 July 2016 at 21:31:52 UTC, Darren wrote:
>> Hey, all.
>>
>> I'm pretty much a programming novice, so I hope you can bear with me.
>> Does anyone know how I can change an int into a char equivalent?
>>
>> e.g.
>> int i = 5;
>> dchar value;
>> ?
>> assert(value == '5');
>>
>> If I try and cast it to dchar, I get messed up output, and I'm not
>> sure how to use toChars (if that can accomplish this).
>>
>> I can copy+paste the little exercise I'm working on if that helps?
>>
>> Thanks in advance!
>
> Ehm how do you you want to represent 1_000 in one dchar?
> You need to format it, like here.
>
> import std.format : format;
> assert("%d".format(1_000) == "1000");
>
> Note that you get an array of dchars (=string), not a single one.
An immutable array of dchars is a dstring, not a string (which is an
immutable array of chars). It is true however, that you should not
convert to dchar, but to string (or dstring, if you want utf32, but i
see no real reason for this, if you are only dealing with numbers),
because of the reason mentioned above. Another solution for this would
be using "to":
import std.conv : to;
void main()
{
int i = 5;
string value = i.to!string;
assert(value == "5");
}
If you know that your int only has one digit, and you really want to get
it as char, you can always use value[0].
Re: Converting int to dchar?
On 07/31/2016 11:31 PM, Darren wrote: If I try and cast it to dchar, I get messed up output, Because it gives you a dchar with the numeric value 5 which is some control character. and I'm not sure how to use toChars (if that can accomplish this). value = i.toChars.front; toChars converts the number to a range of chars. front takes the first of them. Similarly, you could also convert to a (d)string and take the first character: value = i.to!dstring[0]; Or if you want to appear clever, add i to '0': value = '0' + i; I'd generally prefer toChars.front here. to!dstring[0] makes an allocation you don't need, and '0' + i is more obscure and bug-prone.
Re: Converting int to dchar?
On Sunday, 31 July 2016 at 21:31:52 UTC, Darren wrote:
Hey, all.
I'm pretty much a programming novice, so I hope you can bear
with me. Does anyone know how I can change an int into a char
equivalent?
e.g.
int i = 5;
dchar value;
?
assert(value == '5');
If I try and cast it to dchar, I get messed up output, and I'm
not sure how to use toChars (if that can accomplish this).
I can copy+paste the little exercise I'm working on if that
helps?
Thanks in advance!
Ehm how do you you want to represent 1_000 in one dchar?
You need to format it, like here.
import std.format : format;
assert("%d".format(1_000) == "1000");
Note that you get an array of dchars (=string), not a single one.
Converting int to dchar?
Hey, all. I'm pretty much a programming novice, so I hope you can bear with me. Does anyone know how I can change an int into a char equivalent? e.g. int i = 5; dchar value; ? assert(value == '5'); If I try and cast it to dchar, I get messed up output, and I'm not sure how to use toChars (if that can accomplish this). I can copy+paste the little exercise I'm working on if that helps? Thanks in advance!
Re: Cannot compare object.opEquals is not nogc
On 07/31/2016 08:43 PM, Rufus Smith wrote:
e.g., I have a nogc container and a remove(T obj). I can't search for
obj and remove it because opEquals is not marked nogc. So I need an
alternative that is somewhat robust.
Jonathan M Davis has already mentioned his plans to templatize
object.opEquals, which would help here. In the meantime, you can make
your own comparison function and use that instead of the == operator.
Note that you can add @nogc when overriding Object.opEquals, and you can
call such a @nogc opEquals directly from @nogc code. You just can't use
the == operator which is implemented in object.opEquals.
In code:
class C
{
override bool opEquals(Object other) const @nogc { return false; }
}
void f(C a, C b) @nogc
{
bool x = a == b; /* doesn't compile */
bool y = a.opEquals(b); /* compiles just fine */
}
object.opEquals (i.e. the == operator) does a little more than just
calling a.opEquals(b). You can check the source to see what it does exactly:
https://github.com/dlang/druntime/blob/master/src/object.d#L136-L156
You'd probably want to mirror that as closely as possible in a custom
comparison function, so that the results are consistent with the ==
operator.
As far as I see, you can't do the typeid thing, though, because
TypeInfo.opEquals is not @nogc. Ugh.
Re: Empty LST files?
On Sunday, 31 July 2016 at 17:01:32 UTC, Seb wrote: On Sunday, 31 July 2016 at 16:55:52 UTC, Seb wrote: On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote: On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote: [...] How about setting the source path directly? With a recent enough dmd version this can be done automatically like here: https://github.com/dlang/dmd/pull/5990/files Thanks Seb. Has this been included in an official version release yet? (I'm not sure how to tell. I've only used Git a small amount.) thanks! Nope it has been added five days ago. You might grab a dmd-nightly build from here https://dlang.org/download.html To clarify I am talking about ___FILE_FULL_PATH__, maybe hard-coding the source directory could also work for you? In the end, I elected to go with a separate solution for test EXEs with the project hierarchy echoed as solution folders. Although this adds some extra overhead to maintain this echo, that can be automated as part of the main solution's build. And it seems to me that there are inherent advantages to going this route. For instance, were this all still in one solution, I'd either have to add additional configurations (32-bit w/ -cov, and 64-bit w/ -cov), or I'd have to manually add -cov to each project whenever I wanted coverage info and later remove it, or I'd have to wait for the code coverage files to be created after every run. A separate solution allows me to maintain -cov for all configurations isolated from my main development mode. So it's there when I want it and gone when I don't, seamlessly. Thanks to everyone for their input!
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Sunday, 31 July 2016 at 17:48:48 UTC, BLM768 wrote: writeln(n1.hashOf == n2.hashOf); // false = BAD! Ok, yeah that is bad. Next question: what's the fastest hashing implementation that will provide the least collisions? Is there a hash implementation that's perfered for AAs?
Re: Cannot compare object.opEquals is not nogc
On Monday, 25 July 2016 at 12:24:53 UTC, Steven Schveighoffer wrote: On 7/23/16 5:44 PM, Rufus Smith wrote: [...] Again, I want to stress that Object.opEquals has been around since early D1 days, @nogc is only a few years old, it was not a wrong decision. @nogc cannot be added without breaking code, and even if you could, it's not correct for opEquals. The issue is one of design, Object should not define which attributes are acceptable on all objects, that should be up to the class designer. The solution is to deprecate and remove all convenience functions from Object. [...] This is an extreme solution for a minor problem. Minor for you... not for everyone. Some people despise the GC and try to write nogc code. For them it is not extreme. It is extreme for you because you are on the other side. Please don't treat your side as the only side.
Re: Cannot compare object.opEquals is not nogc
On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote: Trying to compare a *ptr value with a value in nogc code results in the error: Error: @nogc function '...' cannot call non-@nogc function 'object.opEquals' Shouldn't object opEquals be marked? So, I need to compare two objects in a no-gc context? How to do this? There are several checks to be done? Memory compare good enough? (not if opEquals is defined for structs, etc...) Unfortunately, regardless of what some people say, There is a need to compare objects in a nogc context... I have the case for one. e.g., I have a nogc container and a remove(T obj). I can't search for obj and remove it because opEquals is not marked nogc. So I need an alternative that is somewhat robust.
Re: Why D isn't the next "big thing" already
On Sunday, 31 July 2016 at 10:11:46 UTC, LaTeigne wrote: On Saturday, 30 July 2016 at 12:24:55 UTC, ketmar wrote: On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote: it you think that you know the things better than somebody who actually *lived* there in those times... well, keep thinking that. also, don't forget to teach physics to physicians, medicine to medics, and so on. i'm pretty sure that you will have a great success as a stupidiest comic they ever seen in their life. also, don't bother answering me, i won't see it anyway. https://forums.embarcadero.com/thread.jspa?messageID=831486 Again an evidence of your super ego. You think that your own experiences stand for everybody while it's actually representing anything byt you, which is quite near from the nil. He clearly suffers from NPD. I believe this is due to ignorance of experience. With such little real world experience one conjures up their own fabricated sense of reality that revolves around themselves. Such people lack the ability to understand others experiences and write them off because they do not coincide with their own. It's a form of the god complex, yet clearly these people are not god and generally not even that intelligent, experienced in life , etc, or happen just to be good at one thing which they treat as the only thing that matters; which is illogical and insane but very convenient for them.
Re: Why D isn't the next "big thing" already
On Saturday, 30 July 2016 at 22:52:23 UTC, bachmeier wrote: On Saturday, 30 July 2016 at 12:30:55 UTC, LaTeigne wrote: On Saturday, 30 July 2016 at 12:24:55 UTC, ketmar wrote: On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote: it you think that you know the things better than somebody who actually *lived* there in those times... well, keep thinking that. also, don't forget to teach physics to physicians, medicine to medics, and so on. i'm pretty sure that you will have a great success as a stupidiest comic they ever seen in their life. also, don't bother answering me, i won't see it anyway. Fucking schyzo ;) Have you took your little pills today ? Well this is beautiful marketing for the language. At some point, the leadership will need to put away ideology and get realistic about what belongs on this site. I agree with this sentiment. One of D's strengths is the helpful responses on the Learn forum. It is something the D community can be proud of. Participants in such personal attacks may view it as primarily as a 1-1 interchange, but they do take away from this strength. Better would be to move personal conflicts to some other venue.
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Sunday, 31 July 2016 at 16:39:59 UTC, Jack Stouffer wrote:
But D provides a default toHash for every type if it's not
defined. I was wondering why not just rely on that version.
If two objects are equal, their hashes must also be equal.
Consider this example:
struct Nullable(T) {
bool isNull;
T value;
bool opEquals(Nullable!T other) {
if(this.isNull != other.isNull) return false;
// Any two nulls are equal.
if(isNull) return true;
return this.value == other.value;
}
}
auto n1 = Nullable!int(true, 3);
auto n2 = Nullable!int(true, 4);
writeln(n1 == n2); // true
writeln(n1.hashOf == n2.hashOf); // false = BAD!
Now that I think about it, maybe this should be in the language
docs; I don't think they mention it.
(https://dlang.org/spec/operatoroverloading.html#equals)
Re: Empty LST files?
On Sunday, 31 July 2016 at 16:55:52 UTC, Seb wrote: On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote: On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote: [...] How about setting the source path directly? With a recent enough dmd version this can be done automatically like here: https://github.com/dlang/dmd/pull/5990/files Thanks Seb. Has this been included in an official version release yet? (I'm not sure how to tell. I've only used Git a small amount.) thanks! Nope it has been added five days ago. You might grab a dmd-nightly build from here https://dlang.org/download.html To clarify I am talking about ___FILE_FULL_PATH__, maybe hard-coding the source directory could also work for you?
Re: Empty LST files?
On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote: On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote: [...] After a couple more hours today, I found a couple of solutions. Neither is satisfactory. [...] How about setting the source path directly? With a recent enough dmd version this can be done automatically like here: https://github.com/dlang/dmd/pull/5990/files Thanks Seb. Has this been included in an official version release yet? (I'm not sure how to tell. I've only used Git a small amount.) thanks! Nope it has been added five days ago. You might grab a dmd-nightly build from here https://dlang.org/download.html
Re: Empty LST files?
On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote: On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote: [...] After a couple more hours today, I found a couple of solutions. Neither is satisfactory. [...] How about setting the source path directly? With a recent enough dmd version this can be done automatically like here: https://github.com/dlang/dmd/pull/5990/files Thanks Seb. Has this been included in an official version release yet? (I'm not sure how to tell. I've only used Git a small amount.) thanks!
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Sunday, 31 July 2016 at 15:30:15 UTC, LaTeigne wrote: On Sunday, 31 July 2016 at 15:21:01 UTC, Jack Stouffer wrote: Is it really a problem? What are the pitfalls of defining one but not the other? iirc usage in an AA requires both. But D provides a default toHash for every type if it's not defined. I was wondering why not just rely on that version.
Re: Empty LST files?
On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote: [...] After a couple more hours today, I found a couple of solutions. Neither is satisfactory. [...] How about setting the source path directly? With a recent enough dmd version this can be done automatically like here: https://github.com/dlang/dmd/pull/5990/files
Re: Empty LST files?
On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote: On Sunday, 31 July 2016 at 10:05:04 UTC, Basile B. wrote: On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote: On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote: Any idea what I'm doing wrong? Yes, what's going wrong is quite actually you said that the LST is well generated but empty so my previous answer is wrong, also i was focused on unittest coverage which doesn't seem to be what you want to verify. Thank Basile. Yes, these aren't unit tests, but rather integration tests, end-to-end tests, etc., all of which are driven from external EXEs. This is a complex application consisting (thus far) of 17 D and C# projects. Within a single project, D (and Visual D) work very well, but across projects I've run into a lot of challenges. Not being able to build these projects into DLLs without resorting to C-linkage for D-to-D interop (which Benjamin Thaut is working on fixing) was tough to swallow, and I can't used LIBs because in some cases I have projects that are not referenced at build time but whose classes are instead discovered at run time, so I'm forced to resort to OBJs for now. Code coverage is a must, though, so I'm really digging in here. I found part of the problem: Hitting F5 in Visual Studio after a fresh rebuild was giving me an error "cannot launch debugger... hr = 89710016" which looks to be related to Visual D. Subsequent runs work fine, but it was annoying me so I added the EXE itself as the startup project. This ran properly every time, but it resulted the LST files ending up in the build folder, and they were all empty. So I switched back to the test project as the startup project and, after the errant run, it generated LSTs in the EXE project root folder as expected. In this case, all the test EXE LST files were populated as expected, but all of the LSTs for the code being tested were still empty. I really don't need code coverage numbers for the test code, and currently I still get none for the code I do need to measure. But it's still progress. If anyone else has ideas I'd love to hear them. Otherwise, if I figure it out, I will add a quick explanation to this thread. thanks! After a couple more hours today, I found a couple of solutions. Neither is satisfactory. The first is to include the project that builds the EXE in the same folder as the project that builds the OBJ. The problem with this is that each OBJ will also have to have its own EXE, and aggregating information from each of these EXEs becomes a real chore. The second is to include all the source files directly in the test EXE project, AND to move the test EXE into its own solution. Having to maintain the same module hierarchy in two projects is obviously error prone. Having to maintain the separate solution is not a problem, really, but the reason it's necessary is a bit annoying: it seems that Visual D automatically includes the OBJ for any project previously built in the build process of subsequent projects, so whether you build the test EXE first or last, you end up with multiple definition problems, once in the EXE and once in the project OBJ, or once in the project and once in the EXE's OBJ. Either way the build breaks. If anyone has a third alternative, please let me know! Otherwise, I'll have to select the lesser of these two evils. thanks!
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Sunday, 31 July 2016 at 15:21:01 UTC, Jack Stouffer wrote: Is it really a problem? What are the pitfalls of defining one but not the other? iirc usage in an AA requires both.
Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
Is it really a problem? What are the pitfalls of defining one but not the other?
Re: null as parametr
On Sunday, 31 July 2016 at 05:41:55 UTC, AntonSotov wrote: 2 Seb Thank you! is (T: typeof (null)) - very comfortable An example of Seb's warning: What happens if you have: string s = null; MyFunc(s); I'm guessing it doesn't do what you want. But it isn't clear what you want - null is a value, not a type. It's just as if you were saying: is (T: typeof (-3))
Re: Empty LST files?
On Sunday, 31 July 2016 at 10:05:04 UTC, Basile B. wrote: On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote: On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote: Any idea what I'm doing wrong? Yes, what's going wrong is quite actually you said that the LST is well generated but empty so my previous answer is wrong, also i was focused on unittest coverage which doesn't seem to be what you want to verify. Thank Basile. Yes, these aren't unit tests, but rather integration tests, end-to-end tests, etc., all of which are driven from external EXEs. This is a complex application consisting (thus far) of 17 D and C# projects. Within a single project, D (and Visual D) work very well, but across projects I've run into a lot of challenges. Not being able to build these projects into DLLs without resorting to C-linkage for D-to-D interop (which Benjamin Thaut is working on fixing) was tough to swallow, and I can't used LIBs because in some cases I have projects that are not referenced at build time but whose classes are instead discovered at run time, so I'm forced to resort to OBJs for now. Code coverage is a must, though, so I'm really digging in here. I found part of the problem: Hitting F5 in Visual Studio after a fresh rebuild was giving me an error "cannot launch debugger... hr = 89710016" which looks to be related to Visual D. Subsequent runs work fine, but it was annoying me so I added the EXE itself as the startup project. This ran properly every time, but it resulted the LST files ending up in the build folder, and they were all empty. So I switched back to the test project as the startup project and, after the errant run, it generated LSTs in the EXE project root folder as expected. In this case, all the test EXE LST files were populated as expected, but all of the LSTs for the code being tested were still empty. I really don't need code coverage numbers for the test code, and currently I still get none for the code I do need to measure. But it's still progress. If anyone else has ideas I'd love to hear them. Otherwise, if I figure it out, I will add a quick explanation to this thread. thanks!
Re: [OT] Re: Why D isn't the next "big thing" already
On Sunday, 31 July 2016 at 04:51:13 UTC, bachmeier wrote: But this would be our own subreddit. I don't disagree if you're talking about r/programming. Oh, the people are terrible, but the platform is worse - I don't like the tree view nor the voting system. It makes it really hard to follow developing discussions and judge the content for yourself. I'm someone who either reads the whole thread and tries to respond holistically or just doesn't post at all (usually), so segmenting the thread into subthreads with new stuff popping up in the middle at random where it is really hard to actually find it (sometimes I search a reddit page for "minutes ago"...) just kills it. Reddit encourages hyper fragmentation and repeating the same opinions over and over again.
Re: Use dup on Containers with const Elements
On 7/30/16 5:21 PM, Q. Schroll wrote: On Friday, 29 July 2016 at 19:24:59 UTC, Steven Schveighoffer wrote: On 7/29/16 3:00 PM, Q. Schroll wrote: Cases to consider: Arrays and AAs with const(T) Elements, where T is a value or a reference type respectively. [snip] Questions: (1) Why do I have to specify the type here? Why does inference fail? (2) Why not just S[S]? The copy of a const S is a S so why is the copy of a (const S, const S)-pair not just (S, S)? array.dup has the meaning to copy the original but make the elements mutable. At least, that's what it was when it was handled by the compiler/runtime. I do understand the reasons why I can't simply copy const reference type objects to mutable. It just makes sense as the referred object is still const. I thought of dup being there for convenience and performance reasons. The spec says about dup: "Create a dynamic array of the same size and copy the contents of the array into it." It has not been clear to me it intends to make the elements mutable. For my intention, I thought of dup making a shallow copy--which is a deep copy on value types so it can drop the const then. If that intention is not in the docs, then that is an omission. It definitely always intends to make the result mutable, and should be an error if you can't do that. Much code out there expects it to be this way, and would break if it simply copied the const tag. I went ahead and submitted a PR: https://github.com/dlang/dlang.org/pull/1435 -Steve
Re: Why D isn't the next "big thing" already
On Saturday, 30 July 2016 at 12:24:55 UTC, ketmar wrote: On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote: it you think that you know the things better than somebody who actually *lived* there in those times... well, keep thinking that. also, don't forget to teach physics to physicians, medicine to medics, and so on. i'm pretty sure that you will have a great success as a stupidiest comic they ever seen in their life. also, don't bother answering me, i won't see it anyway. https://forums.embarcadero.com/thread.jspa?messageID=831486 Again an evidence of your super ego. You think that your own experiences stand for everybody while it's actually representing anything byt you, which is quite near from the nil.
Question regarding Base64 decoding
Currently, the function Base64.decode for decoding char[] to ubyte[] has an in contract, that should ensure that the supplied buffer is large enough. However, it uses the function decodeLength, which does not give the accurate decodeLength, but instead an upper bound (decodeLength can be up to 2 bigger than realDecodeLength). I understand, that this is useful for the cases when one wants to decode an imputRange, becuase the it is (in general) not possible to use realDecodeLength, because it needs random access and opDollar. But it would be possible to use realDecodeLength when decoding an array (in fact it is used in the out contract in this case). My problem with this is, that I read base64 encoded data from a file, and I know, that the data needs to be exactly 32 byte when decoded, otherwise the data is faulty and an exception should be raised. So naively, I would just supply a 32 byte buffer to the decode function. But the decodeLength function returns 33 for the encoded data, so when calling decode with a 32 byte buffer, the in contract fails. The funny thing is, when using a release build (and thus removing all contracts) everything works as expected. So my question is the following: Is there any specific reason for this behaviour (which I can't see), or is this simply a "bug" and realDecodeLength should be used in the in contract?
Re: Empty LST files?
On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote: On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote: Any idea what I'm doing wrong? Yes, what's going wrong is quite actually you said that the LST is well generated but empty so my previous answer is wrong, also i was focused on unittest coverage which doesn't seem to be what you want to verify.
Re: std.socket Socket.select failing on consecutive calls with listening socket
On Sunday, 31 July 2016 at 08:29:10 UTC, ketmar wrote: On Sunday, 31 July 2016 at 08:00:02 UTC, cc wrote: socket sets usually updated after call to `select()`. you have to recreate the sets before each call. Ah that works, thanks.
Re: Empty LST files?
On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote: I'm running into a problem where when I specify -cov in the DMD compiler command, the coverage LST files are generated, but they're all empty. Has anyone else run into this before? My command line is: dmd -m64 -gc -debug -w -wi -cov -X -Xf"obj\Unit.json" -I\ -deps="obj\Unit.dep" -c -odobj\Unit.build.rsp Interfaces.obj Invokers.obj (plus a whole lot of other .objs) This is for a test EXE. I thought there may be some trouble when generating files for the .d from the .obj files, but even the .d files local to the test EXE end up with empty LST files. Any idea what I'm doing wrong? Yes, what's going wrong is quite obvious. Coverage files are generated at run-time by the target application and not by the compiler at compile-time. In your options I can see that you generate an object file. You should rather compile for running the unittests: e.g: -main -unittest -cov and then execute the target application to generate the LST.
Re: std.socket Socket.select failing on consecutive calls with listening socket
On Sunday, 31 July 2016 at 08:00:02 UTC, cc wrote: socket sets usually updated after call to `select()`. you have to recreate the sets before each call.
Re: Template Inheritance
On Sunday, 31 July 2016 at 03:04:27 UTC, Gorge Jingale wrote: I like to build structures using template mixins because one can pick and choose functionality at compile time, but still have a relationship between different types. It would be really nice if one could sort of test if a template mixin was "mixed" in(or ideally, struct S : SomeTemplate (template inheritance)). While one can overcome a lot of the issues by doing static checking(e.g., does IsSomeTemplate compile or other introspective like checks), it is a bit messy and clutters up the code. Does anyone do stuff like this and have a nice elegant way? I suppose you could have the template mixin define a unique key ( kinda like the current(?) std.random's isUniformRandom trick) for that mixin and then do is(hasMember!(S,someUniqueTemplateMixinName))
std.socket Socket.select failing on consecutive calls with listening socket
Socket server = new TcpSocket(); server.setOption(SocketOptionLevel.SOCKET, SocketOption.REUSEADDR, true); server.bind(new InternetAddress(8000)); server.listen(8); auto set = new SocketSet(); set.add(server); auto sel = Socket.select(set, null, null, msecs(0)); Socket.select(set, null, null, msecs(0)); (Simplified from loop) On the second select call, fails with: std.socket.SocketOSException@std\socket.d(3439): Socket select error: An invalid argument was supplied. The ultimate goal is non-blocking accept calls. I tried skipping the select() calls entirely and just setting server.blocking = false; and auto client = server.accept(); every loop, but this resulted in accept() returning a non-null Socket object even when no client was connecting, and did not throw an exception to check for wouldHaveBlocked. When I added the select statement to check for pending connections, the first iteration returns 0 successfully, but the second iteration of the loop failed with the above message. (DMD32 D Compiler v2.071.1 running on Windows 7 x64)
