Re: Intended behavior of std.range.cycle?
On Friday, 5 September 2014 at 10:41:22 UTC, Vlad Levenfeld wrote: On Thursday, 4 September 2014 at 11:43:28 UTC, monarch_dodra wrote: *Should* cycle be negatively index-able? Personally, I don't think so. And even if it could, it has been proven non-size_t indexing is not well supported at all. It was de-facto chosen after the iota-map fiasco that all ranges be indexed with size_t and nothing else... Can you elaborate on what the problem was? I'm curious as I've recently implemented a DSP module that uses ranges with floating-point slicing and, other than having to define a second kind of length (I call it measure so I can still have a discrete length when I need it), it seems to work well enough so far. It'd be bad if there were some unseen fiasco waiting for me... In itself, there is nothing wrong with having a shallow container that can be indexed from -inf to +inf. The issues might appear if you try to tag on the range interface on it. In particular, who is front? If I do a foreach over the sequence, then will it miss half the elements? What does it mean to slice from -5 to +5 ? Which element becomes the new 0? As for floating point indexing, it's the same thing. The indexing itself is fine, there's no problem there. But if you popFront, how many elements are you actually skipping over. What would it mean if I were to take(4.5) elements? *Overall*, it should be fine, but if you are creative, you could hurt yourself. I don't know your exact use case though. So my conclusion is mostly that as long as you only index, you should be fine. Mix in range adaptors, and things *could* become less stable. *could*. But you should still be mostly safe. Again, depends on use case.
Installing LDC on Windows
OK I installed LDC pre-built on MinGW for Windows on Windows and then Installed MinGW for Windows but when I run ldc2 it tells me libgcc_s_dw2-1.dll is missing. Is this problem soluble by any means other than destruction of Windows? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 11:13:20 UTC, Russel Winder via Digitalmars-d-learn wrote: OK I installed LDC pre-built on MinGW for Windows on Windows and then Installed MinGW for Windows but when I run ldc2 it tells me libgcc_s_dw2-1.dll is missing. Is this problem soluble by any means other than destruction of Windows? You need to set PATH in environment variables to the directory where shared libaries of MinGW are present...
Re: Installing LDC on Windows
On Sat, 2014-09-06 at 11:26 +, Danyal Zia via Digitalmars-d-learn wrote: On Saturday, 6 September 2014 at 11:13:20 UTC, Russel Winder via Digitalmars-d-learn wrote: OK I installed LDC pre-built on MinGW for Windows on Windows and then Installed MinGW for Windows but when I run ldc2 it tells me libgcc_s_dw2-1.dll is missing. Is this problem soluble by any means other than destruction of Windows? You need to set PATH in environment variables to the directory where shared libaries of MinGW are present... Hummm… I thought I had since all the DLLs are in the bin directory and you need that in your PATH. Ah, I installed MinGW that has libgcc_s_seh-1.dll not libgcc_s_dw2-1.dll. Of course having a gcc and g++ in my path ruins all my SCons experiments since the whole point was not to have them in the path, just ldc2. Ho hum. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Installing LDC on Windows
SEH was patented, so llvm doesn't support it.
Re: Installing LDC on Windows
On Sat, 2014-09-06 at 15:09 +, Kagamin via Digitalmars-d-learn wrote: SEH was patented, so llvm doesn't support it. I installed the other MinGW option and it provides libgcc_s_sjlj-1.dll which is not helping me actually run ldc2 on Windows :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Installing LDC on Windows
Looks like mingw supports 3 types of exception handling. LDC usually tightly coupled with mingw version, you shouldn't try it blindly, but follow installation instructions instead.
Re: Installing LDC on Windows
SEH was patented, so llvm doesn't support it. That has changed.
Re: Installing LDC on Windows
On 9/6/2014 11:09 AM, Kagamin wrote: SEH was patented, so llvm doesn't support it. Seriously, if they're worried about infringing a software patent, they have no business writing any code at all. Avoiding things covered by patents *and* writing code that actually does anything useful is NOT REALISTICALLY POSSIBLE. The SEH patent is just a red herring here.
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote: SEH was patented, so llvm doesn't support it. That has changed. Has it? SEH on Win64 is something entirely different from the original (x86) SEH design, and not covered by said patent. David
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 16:11:55 UTC, Russel Winder via Digitalmars-d-learn wrote: I installed the other MinGW option and it provides libgcc_s_sjlj-1.dll which is not helping me actually run ldc2 on Windows :-( It is mentioned both the in README coming with the Windows packages and the on wiki [1] that you need a Dwarf 2 EH package (-dw2) of MinGW-w64 for LDC to work. How can we make this more clear? Cheers, David [1] http://wiki.dlang.org/Building_LDC_on_MinGW_x86
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 16:36:38 UTC, Kagamin wrote: Looks like mingw supports 3 types of exception handling. LDC usually tightly coupled with mingw version, you shouldn't try it blindly, but follow installation instructions instead. It's not really tightly coupled to the MinGW version per se. What is required is Dwarf 2 EH and a working TLS implementation. The latter is the reason for the recent version of mingw-w64 requirement, because I fixed the implementation there a year ago or so. No idea if the mingw.org people have gotten their act together since. That being said, it still makes sense to try a known good version first, as LDC exercises quite a large part of the compiler/runtime features, some of which aren't needed in more wide-spread use cases (for example native TLS). David
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 21:54:00 UTC, David Nadlinger wrote: On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote: SEH was patented, so llvm doesn't support it. That has changed. Has it? SEH on Win64 is something entirely different from the original (x86) SEH design, and not covered by said patent. Ok 2in1. 1) As far as I know the x86 SEH patent expired in June. 2) For x64 the implementation is very close now: https://github.com/ldc-developers/ldc/issues/166#issuecomment-54522891
extern(C) function declaration inside a function without altering mangling
Is there way to declare a extern(C) function inside a function without
altering the mangled name?
Should I write a mixin for that based on pragma(mangleof) (used as
extern_C_global_scope in example below) ? Or did someone already implement
that?
extern(C) void foo1();
void fun(){
extern(C) void foo2();
mixin(extern_C_global_scope(void foo3()));
foo1(); //OK
foo2(); //will result in link error due to different mangling of foo2.
foo3(); //OK
}
Re: Automatic translation of opUnary!++ into opOpAssign!+
On 12/28/2013 11:00 AM, monarch_dodra wrote:
On Saturday, 28 December 2013 at 15:37:06 UTC, Francesco Cattoglio wrote:
So, while I was studying the apropriate template constraints for my
shiny new iota implementation, I found out this funny thing:
import std.stdio;
class Test{
int x = 41;
Test opOpAssign(string op)(int rhs) if (op == +) {
x += rhs;
return this;
}
}
void main() {
Test t1 = new Test;
//class Test has no opUnary defined, so the following
//gets automagically converted into (t1) += (1)
++t1;
writeln(t1.x); //prints 42, correct!
}
This actually comes really handy, but I couldn't find it into the
language documentation on dlang.org, so it surprised me.
Same here. I still can't find it in the documentation at least easily.
Did I miss it in the language specification? Should we add it
somewhere to the docs?
Anyone with some spare time care to explain briefly what was the
rationale behind this?
I seem to remember that this is mentioned in TDPL? That's not spec of
course, but I think it's mentioned here.
I just checked again. No, I can't find it in TDPL.
I'm a bit fuzy about the shortcuts, but I *think* there are a couple
other shortcuts like this, such as a += b = a = a + b?
No, that translation is not there.
In any case, http://dlang.org/operatoroverloading.html; needs to be
updated
Agreed.
Can someone who is familiar with the dmd source code enumerate such
translations?
Thank you,
Ali
