Re: Derelict on Ubuntu with CODE::BLOCKS
On Thursday, 3 May 2018 at 03:18:02 UTC, RegeleIONESCU wrote: The only problem I have with DUB is that all added dependencies are "old". For example added dependency "derelict-sdl2" is version="~>2.1.4" while on DUB site the last version is 3.1.0-alpha.3. I tried the --upgrade plus --prerelease option but the dependencies remain the same. I tried to write myself the version in the dub.sdl but I get errors related to other packages. Is there anyway to make DUB automatically use the latest version of a dependency? You an control that with precision, specifying specific versions if you want. But with Derelict, if you're using mulitple Derelict package you have to make sure that all of them depend on the same major version of DerelictUtil. If you paste your full dependency list here, exactly as it's written in your package configuration, I might be able to help you.
Re: C++ / Wrong function signature generated for reference parameter
On 2018-05-03 02:23:27 +, Rubn said: If "Image" is a class then all classes are based as pointers to their respective object. Hi, ok. Didn't remember that this is always the case. So passing a ref to a class is kind of redundant. Yes, that's why I was confused. You want to use a struct which isn't passed by pointer, but by value. Which will then give you the signature you want. On the C++ side, Image is a class. Sometimes I need to use a pointer to it and sometimes a reference when using C++ side functions. So, how do I make it possible to have both variants available in D? If I use class I always get a pointer, if I use strucut I always get a reference. Do I define two interfaces in D one as class and one as struct with different names and than cast things on the D side? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Why does enumerate over range return dchar, when ranging without returns char?
On 03/05/2018 5:44 PM, James Blachly wrote:
I am puzzled why enumerating in a foreach returns a dchar (which forces
me to cast), whereas without the enumerate the range returns a char as
expected.
Example:
```
import std.stdio;
import std.range : enumerate;
void main()
{
char[] s = ['a','b','c'];
char[3] x;
auto i = 0;
foreach(c; s) {
x[i] = c;
i++;
}
writeln(x);
}
```
Above works without cast.
'''
import std.stdio;
import std.range : enumerate;
void main()
{
char[] s = ['a','b','c'];
char[3] x;
foreach(i, c; enumerate(s)) {
x[i] = c;
i++;
}
writeln(x);
}
```
Above fails without casting c to type char.
The function signature for enumerate shows "auto" return type, so that
does not help me understand.
Kind regards
The first example uses auto-decoding (UTF-8 codepoints into a single
UTF-32 one). This is considered a bad thing. But the compiler can
disable it and leave it as UTF-8 code point upon request.
The second example returns a Voldemort type (means no-name) which
happens to be an input range. Where it can't disable anything and has
been told that it is returning a dchar. See[0] as to where this gets
decoded. Writing two small functions to replace it (and popFront), will
override this behavior.
[0] https://dlang.org/phobos/std_range_primitives.html#.front
Why does enumerate over range return dchar, when ranging without returns char?
I am puzzled why enumerating in a foreach returns a dchar (which
forces me to cast), whereas without the enumerate the range
returns a char as expected.
Example:
```
import std.stdio;
import std.range : enumerate;
void main()
{
char[] s = ['a','b','c'];
char[3] x;
auto i = 0;
foreach(c; s) {
x[i] = c;
i++;
}
writeln(x);
}
```
Above works without cast.
'''
import std.stdio;
import std.range : enumerate;
void main()
{
char[] s = ['a','b','c'];
char[3] x;
foreach(i, c; enumerate(s)) {
x[i] = c;
i++;
}
writeln(x);
}
```
Above fails without casting c to type char.
The function signature for enumerate shows "auto" return type, so
that does not help me understand.
Kind regards
Re: Derelict on Ubuntu with CODE::BLOCKS
On Monday, 11 December 2017 at 07:34:47 UTC, Mike Parker wrote: On Sunday, 10 December 2017 at 16:50:10 UTC, RegeleIONESCU wrote: [...] My advice is to ditch Code::Blocks and use something like VS Code or Sublime Text in conjunction with DUB. It's by far the easiest way to get started with D, particularly for someone who as little practical experience with compilers and linkers. Then you don't have to worry about "installing" Derelict. You can get the Ubuntu packages for the C libraries you need via apt-get on Ubuntu, then use DUB to manage and build your project. Piece of cake compared to doing it all by hand. [...] Hello every body! I know it is four months old thread. But now I found the solution! :) As Mike Parker suggested, DUB + Sublime is the solution. DUB works so simple, so nice! DUB works like a charm it imports by itself all the needed libraries and does lots of other stuff. The only problem I have with DUB is that all added dependencies are "old". For example added dependency "derelict-sdl2" is version="~>2.1.4" while on DUB site the last version is 3.1.0-alpha.3. I tried the --upgrade plus --prerelease option but the dependencies remain the same. I tried to write myself the version in the dub.sdl but I get errors related to other packages. Is there anyway to make DUB automatically use the latest version of a dependency? Thank you all for your kind support!
Re: Ambiguous template parameter names
On Thursday, 3 May 2018 at 02:48:10 UTC, jmh530 wrote:
On Thursday, 3 May 2018 at 00:52:58 UTC, Meta wrote:
[snip]
It's not a big per se. It's a consequence of the declaration
expanding to the real template function form (I can't type it
all out as I'm on my phone), thus the inner `val` from the
function shadows the one from the template.
That makes sense. Before creating the example, I would have
assumed that when you instantiate it as foo!1, then the `val=1`
would flow through to the inner foo function.
template foo(int val)
{
int foo(int val)
{
return val;
}
}
If you want that, you might be able to do `int val = val` on the
inner function, though I'm not sure that'll work.
Re: Ambiguous template parameter names
On Thursday, 3 May 2018 at 00:52:58 UTC, Meta wrote:
[snip]
It's not a big per se. It's a consequence of the declaration
expanding to the real template function form (I can't type it
all out as I'm on my phone), thus the inner `val` from the
function shadows the one from the template.
That makes sense. Before creating the example, I would have
assumed that when you instantiate it as foo!1, then the `val=1`
would flow through to the inner foo function.
template foo(int val)
{
int foo(int val)
{
return val;
}
}
Re: C++ / Wrong function signature generated for reference parameter
On Wednesday, 2 May 2018 at 21:55:31 UTC, Robert M. Münch wrote:
I have the following C++ function signature:
uint _begin(Image& image, const InitParams* initParams)
and the following D code:
class InitParams {
}
class B2D {
uint _begin(ref Image image, InitParams initParams);
}
But this compiles to the following signature which is not found
by the linker:
public: virtual unsigned int __cdecl
b2d::Context2D::_begin(class b2d::Image * &,class
b2d::InitParams *)
I don't understand why "ref Image" translates to "Image * &"
and not "Image &". How can I get the C++ reference function
signature written down in D?
If "Image" is a class then all classes are based as pointers to
their respective object. So passing a ref to a class is kind of
redundant. You want to use a struct which isn't passed by
pointer, but by value. Which will then give you the signature you
want.
Re: Ambiguous template parameter names
On Wednesday, 2 May 2018 at 20:32:43 UTC, jmh530 wrote:
In the function below, there is a template parameter and a
normal parameter both with the same name. However, the function
returns the normal parameter. The template parameter is
effectively ignored. I was surprised by this behavior.
Is this a bug or intentional? I did not see it documented
anywhere.
```
int foo(int val)(int val)
{
return val;
}
void main()
{
assert(foo!1(2) == 2);
}
```
It's not a big per se. It's a consequence of the declaration
expanding to the real template function form (I can't type it all
out as I'm on my phone), thus the inner `val` from the function
shadows the one from the template.
Re: Out of memory during compilation
On Wednesday, 2 May 2018 at 15:13:58 UTC, Matt Gamble wrote: On Wednesday, 2 May 2018 at 14:30:19 UTC, Joakim wrote: On Wednesday, 2 May 2018 at 14:25:35 UTC, Matt Gamble wrote: I have a large program (for me) with several thousand lines of code. Recently when I've tried to compile under debug (-g -unittest) with VS2017, dmd2.076.1, windows 10, 8Gb ram), I've had the following output: Compiling SKaTERoptimizerD.d... Fatal Error: Out of memory Building x64\Debug\SKaTERoptimizerD.exe failed! When compiled under release (-O -release -inline -boundscheck=off) mode it works fine. Any advice on how to combat this? Do I need to start compiling DLLs? Does that change how the linking would be done? Would that affect the debugger? Any help is appreciated, Matt My guess would be Optlink, the old OMF linker. Are you using that or the VS linker? Try adding the -v flag to check log output for where it fails. I believe I'm using the vs linker (link.exe). This is what is automatically set for VisualD under x64 mode. I tried the -v flag and got compiler output messages that are 13,758 lines long. The "Fatal Error: Out of memory" happens at line 13,639. How do I use this information? The idea was to check the log output and see where it's failing, while compiling or linking. It sounds like you're saying while compiling? If so, are you compiling all your D files at once? You can either try separate compilation or a 64-bit compiler, as Rikki suggests.
Re: Digger v3.0 alpha 5 / DMD 2.080.0 / Can't build...
On Wednesday, 2 May 2018 at 21:13:03 UTC, Robert M. Münch wrote: On 2018-05-02 09:39:41 +, Seb said: [...] Hi, not that I know about... [...] Looks like it's an issue with the windows bootstrapping. I would recommend to report a bug to Vladimir's issue tracker: https://github.com/CyberShadow/Digger
Re: Ambiguous template parameter names
On Wednesday, 2 May 2018 at 20:32:43 UTC, jmh530 wrote:
In the function below, there is a template parameter and a
normal parameter both with the same name. However, the function
returns the normal parameter. The template parameter is
effectively ignored. I was surprised by this behavior.
Is this a bug or intentional? I did not see it documented
anywhere.
```
int foo(int val)(int val)
{
return val;
}
void main()
{
assert(foo!1(2) == 2);
}
```
i think this is a bug and that it should be reported. The main
problem is that you cant even use the val (the template parameter
one) in a static if.
C++ / Wrong function signature generated for reference parameter
I have the following C++ function signature:
uint _begin(Image& image, const InitParams* initParams)
and the following D code:
class InitParams {
}
class B2D {
uint _begin(ref Image image, InitParams initParams);
}
But this compiles to the following signature which is not found by the linker:
public: virtual unsigned int __cdecl b2d::Context2D::_begin(class
b2d::Image * &,class b2d::InitParams *)
I don't understand why "ref Image" translates to "Image * &" and not
"Image &". How can I get the C++ reference function signature written
down in D?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Digger v3.0 alpha 5 / DMD 2.080.0 / Can't build...
On 2018-05-02 09:39:41 +, Seb said: Works fine for me with 2.080.0. Did you maybe modify your working directory locally? Hi, not that I know about... If so, try nuking `work` away. I did and digger downloaded a bunch of things and failed wiht this: D:\develop\d-language\Digger> .\digger.exe build digger: Building spec: master digger: Adding D:\develop\d-language\Digger\work\dl\git\cmd to PATH. digger: Updating repo... Fetching origin digger: Starting at meta repository commit 8f79556c48f5161b5702589d47745fc9fb620eeb digger: Building components dmd, druntime, phobos-includes, phobos, rdmd digger: needInstalled: dmd-c86d97955d5bc565441e1aa3ee7664ae3f748683-3f836c943d2670833cf056224634bb96 digger: Clearing temporary cache digger: Cache miss. digger: needBuild: dmd-c86d97955d5bc565441e1aa3ee7664ae3f748683-3f836c943d2670833cf056224634bb96 digger: Cleaning repository dmd... HEAD is now at c86d979 Merge pull request #8212 from MartinNowak/merge_stable digger: Building dmd-c86d97955d5bc565441e1aa3ee7664ae3f748683-3f836c943d2670833cf056224634bb96 digger: Preparing DigitalMars C++ digger: Installing DigitalMars C++ v8.57 to D:\develop\d-language\Digger\work\dl\dm857-snn2074-optlink80017... digger: Unpacking D:\develop\d-language\Digger\work\dl\dm857c.zip to D:\develop\d-language\Digger\work\dl\dm857c... digger: Not caching dmd build failure due to temporary/environment error. std.file.FileException@std\file.d(945): Attempting to rename file D:\develop\d-language\Digger\work\dl\dmd.2.074.0.windows\dmd2\windows\lib\snn.lib to D:\develop\d-language\Digger\work\dl\dm857-snn2074-optlink80017.7712.9984.temp\lib\snn.lib: Das System kann die angegebene Datei nicht finden. The last line states that the file can't be found. (btw digger is used for DAutoTest so it's constantly tested by our CIs) I trust you and I really like the tool but I have some pretty hard times to get it up & running and then keep it running... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Ambiguous template parameter names
In the function below, there is a template parameter and a normal
parameter both with the same name. However, the function returns
the normal parameter. The template parameter is effectively
ignored. I was surprised by this behavior.
Is this a bug or intentional? I did not see it documented
anywhere.
```
int foo(int val)(int val)
{
return val;
}
void main()
{
assert(foo!1(2) == 2);
}
```
Re: How to curl!
On Wednesday, 2 May 2018 at 16:58:35 UTC, IntegratedDimensions wrote: On Wednesday, 2 May 2018 at 03:03:19 UTC, ikod wrote: On Wednesday, 2 May 2018 at 00:04:49 UTC, IntegratedDimensions wrote: On Tuesday, 1 May 2018 at 23:35:42 UTC, Arun Chandrasekaran wrote: [...] Ok, first try: Unhandled exception: object.Exception can't complete call to TLS_method at requests\ssl_adapter.d(248) which says it can't find the lib. I renamed ssleay32.dll to libssl32.dll and it then passed. I am getting http 404 error though ;/ I turned off cert though, which may be the reason, I have no idea. Seems to be working through. Did you try to use full path to cacert.pem? That seemed to work. Why would it not look in the current directory by default? Maybe something to add? Not sure about curl, but dlang-requests just pass filename as-is to libssl. I think that if you have cert file in current directiry, and use no path in call to sslSetCertFile it should work. If not - please post bugreport to github.com/ikod/dlang-requests PS. I'll check and add ssleay32 to search names for dynamic ssl library load.
Thread-safe cache
What would the most performent way to create a thread-safe cache that can be used across threads/fibers in D? Lock-free as much as possible. What I ultimately want to do is to cache some data I pull from a database (Or elsewhere for that matter) and then cache it somewhere, so I can avoid having multiple calls to eg. the database. Of course I can use an associative array and then put a synchronize statement around it, but it's not performant and it can have a huge performance impact when using fibers ex. with vibe.d since a single connection can end up blocking multiple connections, just by the fact that single connection is attempting to access that piece of data.
Re: Create variable for RedBlackTree range
On Wednesday, 2 May 2018 at 10:39:29 UTC, ag0aep6g wrote: On 04/28/2018 06:36 PM, Gerald wrote: What is the appropriate way to create a variable for the range returned by RedBlackTree lowerBound and upperBound. For example, given this code: ``` RedBlackTree!long promptPosition = redBlackTree!long(); long row = to!long(vte.getVadjustment().getValue()); RBRange!(RBNode!long*) range; [...] } ``` The second line where I declare the range variable as RBRange!(RBNode!long*) the compiler complains with the following warning: Deprecation: std.container.rbtree.RBRange(N) is not visible from module terminal Which makes sense since RBRange is a private struct. RedBlackTree also has public range types: Range, ConstRange, ImmutableRange. And `RedBlackTree!long.Range` is an alias for `RBRange!(RBNode!long*)`. So: RedBlackTree!long promptPosition = redBlackTree!long(); RedBlackTree!long.Range range; For completeness' sake, and if you don't want to re-specify the template parameters you passed to RedBlackTree, you can write: promptPosition.Range range;
Re: How to curl!
On Wednesday, 2 May 2018 at 03:03:19 UTC, ikod wrote: On Wednesday, 2 May 2018 at 00:04:49 UTC, IntegratedDimensions wrote: On Tuesday, 1 May 2018 at 23:35:42 UTC, Arun Chandrasekaran wrote: [...] Ok, first try: Unhandled exception: object.Exception can't complete call to TLS_method at requests\ssl_adapter.d(248) which says it can't find the lib. I renamed ssleay32.dll to libssl32.dll and it then passed. I am getting http 404 error though ;/ I turned off cert though, which may be the reason, I have no idea. Seems to be working through. Did you try to use full path to cacert.pem? That seemed to work. Why would it not look in the current directory by default? Maybe something to add?
Re: Out of memory during compilation
On 03/05/2018 3:21 AM, Matt Gamble wrote: On Wednesday, 2 May 2018 at 14:31:16 UTC, rikki cattermole wrote: On 03/05/2018 2:25 AM, Matt Gamble wrote: [...] Let me start by saying shared library support doesn't work (some people will say it does work partially, but it doesn't). The problem for you (I think) is that dmd is compiled as a 32bit executable. Either compile dmd as 64bit, or grab ldc (64bit) which will raise the limit from 2gb of ram :) Thanks, I'll check out Ldc and see if that helps. Will I still be able to use the VS debugger functionality? Of course.
Re: Out of memory during compilation
On Wednesday, 2 May 2018 at 14:31:16 UTC, rikki cattermole wrote: On 03/05/2018 2:25 AM, Matt Gamble wrote: [...] Let me start by saying shared library support doesn't work (some people will say it does work partially, but it doesn't). The problem for you (I think) is that dmd is compiled as a 32bit executable. Either compile dmd as 64bit, or grab ldc (64bit) which will raise the limit from 2gb of ram :) Thanks, I'll check out Ldc and see if that helps. Will I still be able to use the VS debugger functionality?
Re: Out of memory during compilation
On Wednesday, 2 May 2018 at 14:30:19 UTC, Joakim wrote: On Wednesday, 2 May 2018 at 14:25:35 UTC, Matt Gamble wrote: I have a large program (for me) with several thousand lines of code. Recently when I've tried to compile under debug (-g -unittest) with VS2017, dmd2.076.1, windows 10, 8Gb ram), I've had the following output: Compiling SKaTERoptimizerD.d... Fatal Error: Out of memory Building x64\Debug\SKaTERoptimizerD.exe failed! When compiled under release (-O -release -inline -boundscheck=off) mode it works fine. Any advice on how to combat this? Do I need to start compiling DLLs? Does that change how the linking would be done? Would that affect the debugger? Any help is appreciated, Matt My guess would be Optlink, the old OMF linker. Are you using that or the VS linker? Try adding the -v flag to check log output for where it fails. I believe I'm using the vs linker (link.exe). This is what is automatically set for VisualD under x64 mode. I tried the -v flag and got compiler output messages that are 13,758 lines long. The "Fatal Error: Out of memory" happens at line 13,639. How do I use this information?
Re: Out of memory during compilation
On Wednesday, 2 May 2018 at 14:25:35 UTC, Matt Gamble wrote: I have a large program (for me) with several thousand lines of code. Recently when I've tried to compile under debug (-g -unittest) with VS2017, dmd2.076.1, windows 10, 8Gb ram), I've had the following output: Compiling SKaTERoptimizerD.d... Fatal Error: Out of memory Building x64\Debug\SKaTERoptimizerD.exe failed! When compiled under release (-O -release -inline -boundscheck=off) mode it works fine. Any advice on how to combat this? Do I need to start compiling DLLs? Does that change how the linking would be done? Would that affect the debugger? Any help is appreciated, Matt My guess would be Optlink, the old OMF linker. Are you using that or the VS linker? Try adding the -v flag to check log output for where it fails.
Re: Out of memory during compilation
On 03/05/2018 2:25 AM, Matt Gamble wrote: I have a large program (for me) with several thousand lines of code. Recently when I've tried to compile under debug (-g -unittest) with VS2017, dmd2.076.1, windows 10, 8Gb ram), I've had the following output: Compiling SKaTERoptimizerD.d... Fatal Error: Out of memory Building x64\Debug\SKaTERoptimizerD.exe failed! When compiled under release (-O -release -inline -boundscheck=off) mode it works fine. Any advice on how to combat this? Do I need to start compiling DLLs? Does that change how the linking would be done? Would that affect the debugger? Any help is appreciated, Matt Let me start by saying shared library support doesn't work (some people will say it does work partially, but it doesn't). The problem for you (I think) is that dmd is compiled as a 32bit executable. Either compile dmd as 64bit, or grab ldc (64bit) which will raise the limit from 2gb of ram :)
Out of memory during compilation
I have a large program (for me) with several thousand lines of code. Recently when I've tried to compile under debug (-g -unittest) with VS2017, dmd2.076.1, windows 10, 8Gb ram), I've had the following output: Compiling SKaTERoptimizerD.d... Fatal Error: Out of memory Building x64\Debug\SKaTERoptimizerD.exe failed! When compiled under release (-O -release -inline -boundscheck=off) mode it works fine. Any advice on how to combat this? Do I need to start compiling DLLs? Does that change how the linking would be done? Would that affect the debugger? Any help is appreciated, Matt
Re: Concatenate strings at compile-time
On Wednesday, 2 May 2018 at 12:38:25 UTC, Jonathan M. Wilbur wrote: I have a method that cannot be @nogc only because it concatenates strings for a long exception message, as seen below. throw new ASN1ValuePaddingException ( "This exception was thrown because you attempted to decode " ~ "an INTEGER that was encoded on more than the minimum " ~ "necessary bytes. " ~ notWhatYouMeantText ~ forMoreInformationText ~ debugInformationText ~ reportBugsText ); Those variables you see are immutable. Is there a way that I can combine these strings together at compile time, rather than having a really long string that exceeds the 120 hard line-length limit? This will be concatenated at compiletime and there will be no runtime overhead iff those are static immutable or enum.
Re: Concatenate strings at compile-time
On 03/05/2018 12:38 AM, Jonathan M. Wilbur wrote: I have a method that cannot be @nogc only because it concatenates strings for a long exception message, as seen below. throw new ASN1ValuePaddingException ( "This exception was thrown because you attempted to decode " ~ "an INTEGER that was encoded on more than the minimum " ~ "necessary bytes. " ~ notWhatYouMeantText ~ forMoreInformationText ~ debugInformationText ~ reportBugsText ); Those variables you see are immutable. Is there a way that I can combine these strings together at compile time, rather than having a really long string that exceeds the 120 hard line-length limit? All strings are immutable. But can they be enum?
Concatenate strings at compile-time
I have a method that cannot be @nogc only because it concatenates strings for a long exception message, as seen below. throw new ASN1ValuePaddingException ( "This exception was thrown because you attempted to decode " ~ "an INTEGER that was encoded on more than the minimum " ~ "necessary bytes. " ~ notWhatYouMeantText ~ forMoreInformationText ~ debugInformationText ~ reportBugsText ); Those variables you see are immutable. Is there a way that I can combine these strings together at compile time, rather than having a really long string that exceeds the 120 hard line-length limit?
Re: Create variable for RedBlackTree range
On 04/28/2018 06:36 PM, Gerald wrote: What is the appropriate way to create a variable for the range returned by RedBlackTree lowerBound and upperBound. For example, given this code: ``` RedBlackTree!long promptPosition = redBlackTree!long(); long row = to!long(vte.getVadjustment().getValue()); RBRange!(RBNode!long*) range; [...] } ``` The second line where I declare the range variable as RBRange!(RBNode!long*) the compiler complains with the following warning: Deprecation: std.container.rbtree.RBRange(N) is not visible from module terminal Which makes sense since RBRange is a private struct. RedBlackTree also has public range types: Range, ConstRange, ImmutableRange. And `RedBlackTree!long.Range` is an alias for `RBRange!(RBNode!long*)`. So: RedBlackTree!long promptPosition = redBlackTree!long(); RedBlackTree!long.Range range;
Re: Digger v3.0 alpha 5 / DMD 2.080.0 / Can't build...
On Wednesday, 2 May 2018 at 09:36:23 UTC, Robert M. Münch wrote: Hi, digger won't build because it sees some local changes to file, which I didn't do: [...] Works fine for me with 2.080.0. Did you maybe modify your working directory locally? If so, try nuking `work` away. (btw digger is used for DAutoTest so it's constantly tested by our CIs)
Digger v3.0 alpha 5 / DMD 2.080.0 / Can't build...
Hi, digger won't build because it sees some local changes to file, which I didn't do: D:\develop\d-language\Digger> ./digger build --model=64 digger: Building spec: master digger: Adding D:\develop\d-language\Digger\work\dl\git\cmd to PATH. digger: Updating repo... Fetching origin digger: Starting at meta repository commit 15642ba3f6e9413eab584261d341a6f9cbf7b2ee digger: Building components dmd, druntime, phobos-includes, phobos, rdmd digger: needInstalled: dmd-c86d97955d5bc565441e1aa3ee7664ae3f748683-952245c3cf66d02b166197a829acd0c4 digger: Clearing temporary cache digger: Cache miss. digger: needBuild: dmd-c86d97955d5bc565441e1aa3ee7664ae3f748683-952245c3cf66d02b166197a829acd0c4 digger: Cleaning repository dmd... HEAD is now at acacaad Merge pull request #7762 from jacob-carlborg/objc_class_methods digger: Checking out dmd commit c86d97955d5bc565441e1aa3ee7664ae3f748683... error: Your local changes to the following files would be overwritten by checkout: .circleci/run.sh semaphoreci.sh test/compilable/crlf.sh test/compilable/ddoc9764.sh test/compilable/extra-files/ddocAny-postscript.sh test/compilable/extra-files/ddocYear-postscript.sh test/compilable/extra-files/depsOutput.sh test/compilable/extra-files/header-postscript.sh test/compilable/extra-files/json-postscript.sh test/compilable/extra-files/rdepsOutput.sh test/compilable/extra-files/test11237.sh test/compilable/extra-files/test7754-postscript.sh test/compilable/extra-files/vcg-ast-postscript.sh test/compilable/issue17167.sh test/compilable/jsonNoOutFile.sh test/compilable/json_nosource.sh test/compilable/test14894.sh test/compilable/test18367.sh test/compilable/test6461.sh test/compilable/test9680.sh test/compilable/testclidflags.sh test/d_do_test.d test/runnable/depsprot.sh test/runnable/extra-files/a20-postscript.sh test/runnable/extra-files/bug9010-postscript.sh test/runnable/extra-files/cov2-postscript.sh test/runnable/extra-files/hello-profile-postscript.sh test/runnable/extra-files/sieve-postscript.sh test/runnable/extra-files/statictor-postscript.sh test/runnable/extra-files/test17868-postscript.sh test/runnable/gdb15729.sh test/runnable/link14198a.sh test/runnable/link14198b.sh test/runnable/link14834.sh test/runnable/link846.sh test/runnable/linkdebug.sh test/runnable/test10386.sh test/runnable/test10567.sh test/runnable/test13666.sh test/runnable/test13742.sh test/runnable/test13774.sh test/runnable/test16096.sh test/runnable/test17619.sh test/runnable/test18076.sh test/runnable/test18141.sh test/runnable/test18335.sh test/runnable/test2.sh test/runnable/test35.sh test/runnable/test39.sh test/runnable/test44.sh test/runnable/test9287.sh test/runnable/test9377.sh test/runnable/test_shared.sh test/runnable/test_switches.sh test/sh_do_test.sh Please, commit your changes or stash them before you can switch branches. Aborting digger: Error checking out c86d97955d5bc565441e1aa3ee7664ae3f748683: object.Exception@C:\Users\robby\AppData\Local\dub\packages\ae-0.0.2155\ae\sys\cmd.d(92): Command `"git" -c core.autocrlf=false checkout ^"c86d97955d5bc565441e1aa3ee7664ae3f748683^"` failed with status 1 I tried to stash etc. but no success... any idea? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
