Re: dub: Use Alternate Dependency
21.11.2017 07:42, bauss пишет: On Tuesday, 21 November 2017 at 02:51:13 UTC, jmh530 wrote: I'm working on two related dub projects on code.dlang.org. One has a dependency on the other. However, I've made changes to both and to run the tests properly requires me to use both versions in my working directory, rather than the versions (specifically for the dependency) that is registered on dub. How do I ensure that dub picks up the right version? Well dub will always use the versions you have specified in your dub.json/dub.sdl file, so if you have a specific version in you dub.json/dub.sdl then dub will use that version only and won't fetch a new version, so don't use something like "~>version", but just "version". Example --- Instead of (something like this.): dependency "package" version="~>1.2.3" Do: dependency "package" version="1.2.3" Probably author needs the following: dependency "package" version="*" path="../relative/path/to/other/custom/package" instead of dependency "package" version="~>1.2.3" this allows using custom package not registered on dub and after debugging register them and use them as usual.
DMD test suite assertion failure in test_cdvecfill.d
I'm getting this error when I try to run the DMD test suite. cd dmd make -C test -f Makefile ... runnable/test_cdvecfill.d -O (-mcpu=avx -mcpu=avx2) Test failed. The logged output: ../src/dmd -conf= -m64 -Irunnable -O -odtest_results/runnable -oftest_results/runnable/test_cdvecfill_0 runnable/test_cdvecfill.d test_results/runnable/test_cdvecfill_0 Expected code sequence for load!(ubyte, 16) not found. Expected: 0x50 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x59 0xc3 Actual: 0x55 0x48 0x8b 0xec 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x5d 0xc3 0x00 0x55 0x48 0x8b 0xec 0x0f 0xb6 0x07 0x66 0x0f 0x6e 0xc0 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x5d 0xc3 0x00 0x00 0x55 0x48 0x8b 0xec 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 core.exception.AssertError@runnable/test_cdvecfill.d(895): Assertion failure ??:? _d_assertp [0xd9faa4f1] ??:? [0x84bcd81c] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().__lambda1() [0xd9fc7d5f] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0xd9fc7c8f] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0xd9fc7d08] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0xd9fc7c8f] ??:? _d_run_main [0xd9fc7bfa] ??:? [0x84bd1057] ??:? __libc_start_main [0xd8eaaf69] Any idea what I'm doing wrong? I'm running 64-bit Arch Linux. Thanks, Mike
Re: dub: Use Alternate Dependency
On Tuesday, 21 November 2017 at 02:51:13 UTC, jmh530 wrote: I'm working on two related dub projects on code.dlang.org. One has a dependency on the other. However, I've made changes to both and to run the tests properly requires me to use both versions in my working directory, rather than the versions (specifically for the dependency) that is registered on dub. How do I ensure that dub picks up the right version? Well dub will always use the versions you have specified in your dub.json/dub.sdl file, so if you have a specific version in you dub.json/dub.sdl then dub will use that version only and won't fetch a new version, so don't use something like "~>version", but just "version". Example --- Instead of (something like this.): dependency "package" version="~>1.2.3" Do: dependency "package" version="1.2.3"
Visual D >> TRACKER : error TRK0004: Failed to locate: "FileTracker32.dll". The system cannot find the file specified.
I'm trying to learn D using Visual D in Visual Studio Community 2015. Both dmd and ldc give me this error when building from Visual Studio. Any ideas? I'm able to build C++ projects...
dub: Use Alternate Dependency
I'm working on two related dub projects on code.dlang.org. One has a dependency on the other. However, I've made changes to both and to run the tests properly requires me to use both versions in my working directory, rather than the versions (specifically for the dependency) that is registered on dub. How do I ensure that dub picks up the right version?
Re: dmd/ldc failed with exit code -11
On 21/11/2017 12:15 AM, Anonymouse wrote: I have a large named enum (currently 645 members) of IRC event types. It's big by neccessity[1]. I'm using dub, and both dmd and ldc successfully build it in test and debug modes, but choke and die on plain and release. I bisected it down to when I did a big addition to the enum to encompass virtually all event types there are. dmd -v: [...] code common function kameloso.common.Separator.__xopEquals function kameloso.common.Separator.__xtoHash function kameloso.common.Settings.__xopEquals function kameloso.common.Settings.__xtoHash function kameloso.common.scopeguard function kameloso.common.scopeguard.scopeString function kameloso.common.scopeguard.entryString function kameloso.common.KamelosoLogger.this function kameloso.common.KamelosoLogger.writeLogMsg function kameloso.common.KamelosoLogger.beginLogMsg function kameloso.common.KamelosoLogger.logMsgPart function kameloso.common.KamelosoLogger.finishLogMsg zsh: segmentation fault (core dumped) dmd -c -v -w -d -version=Have_kameloso -Isource/ source/arsd/dom.d Where it stops here varies if I comment stuff out, so I don't think the Logger is at fault. ldc -v: [...] code irc code constants code connection code config code common /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2b)[0x7f09953839bb] /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys17RunSignalHandlersEv+0x56)[0x7f0995381806] /usr/lib/libLLVM-5.0.so(+0x808953)[0x7f0995381953] /usr/lib/libpthread.so.0(+0x11da0)[0x7f099496cda0] ldc(_ZN16TemplateInstance12needsCodegenEv+0x8)[0x561fe42fc128] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] [...] zsh: segmentation fault (core dumped) ldc -v -w -d -oq -od=.dub/obj -d-version=Have_kameloso -Isource/ What can I do? Merely copying the enum into a test file and compiling with an empty main does nothing, it doesn't seem to be enough to replicate the bug. (Arch/Manjaro 64-bit, dmd 2.077.0, ldc 1.5.0 based on 2.075.1) [1] http://defs.ircdocs.horse/defs/numerics.html Source code please.
dmd/ldc failed with exit code -11
I have a large named enum (currently 645 members) of IRC event types. It's big by neccessity[1]. I'm using dub, and both dmd and ldc successfully build it in test and debug modes, but choke and die on plain and release. I bisected it down to when I did a big addition to the enum to encompass virtually all event types there are. dmd -v: [...] code common function kameloso.common.Separator.__xopEquals function kameloso.common.Separator.__xtoHash function kameloso.common.Settings.__xopEquals function kameloso.common.Settings.__xtoHash function kameloso.common.scopeguard function kameloso.common.scopeguard.scopeString function kameloso.common.scopeguard.entryString function kameloso.common.KamelosoLogger.this function kameloso.common.KamelosoLogger.writeLogMsg function kameloso.common.KamelosoLogger.beginLogMsg function kameloso.common.KamelosoLogger.logMsgPart function kameloso.common.KamelosoLogger.finishLogMsg zsh: segmentation fault (core dumped) dmd -c -v -w -d -version=Have_kameloso -Isource/ source/arsd/dom.d Where it stops here varies if I comment stuff out, so I don't think the Logger is at fault. ldc -v: [...] code irc code constants code connection code config code common /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2b)[0x7f09953839bb] /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys17RunSignalHandlersEv+0x56)[0x7f0995381806] /usr/lib/libLLVM-5.0.so(+0x808953)[0x7f0995381953] /usr/lib/libpthread.so.0(+0x11da0)[0x7f099496cda0] ldc(_ZN16TemplateInstance12needsCodegenEv+0x8)[0x561fe42fc128] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x561fe42fc223] [...] zsh: segmentation fault (core dumped) ldc -v -w -d -oq -od=.dub/obj -d-version=Have_kameloso -Isource/ What can I do? Merely copying the enum into a test file and compiling with an empty main does nothing, it doesn't seem to be enough to replicate the bug. (Arch/Manjaro 64-bit, dmd 2.077.0, ldc 1.5.0 based on 2.075.1) [1] http://defs.ircdocs.horse/defs/numerics.html
Re: GtkD help
On Monday, 20 November 2017 at 08:01:28 UTC, Ivan Trombley wrote: I solved the TreeView text cooler l color issue by using markup. Phoned.
Re: Template Question
On 11/19/17 2:41 PM, Adam D. Ruppe wrote: On Sunday, 19 November 2017 at 19:31:53 UTC, Jiyan wrote: Text X; You still need to instantiate it, even with default args. Text!() X; will work If that's the case, then he needs to use Text(T = char) (default type) vs. Text(T : char) (specialization) -Steve
Re: One liner alternatives for initing and pushing some values into array
On Monday, 20 November 2017 at 08:37:32 UTC, kerdemdemir wrote:
bool boolList[] = { a, b, c };
D alternative(at least my D alternative) seem long. Is there
any better way for
initialing and pushing values at the same time.
Erdem
Your use of the appender method suggest to me you want to be able
to append, as opposed to just initialise.
module test;
import std.stdio;
import std.array;
void main()
{
bool[] boolList;
bool a = true;
bool b = false;
bool c = false;
boolList ~= [ a, b, c ];
bool d = true;
bool e = false;
bool f = false;
boolList ~= [ d, e, f ];
// ...
}
Re: One liner alternatives for initing and pushing some values into array
On Monday, 20 November 2017 at 08:37:32 UTC, kerdemdemir wrote:
I need to init and push some values into a array something like:
//DMD64 D Compiler 2.072.2
import std.stdio;
import std.array;
void main()
{
bool a = true;
bool b = false;
bool c = false;
bool[] boolList;
auto boolListAppender = boolList.appender();
boolListAppender ~= [ a, b, c];
}
Live example : http://rextester.com/TJLIXU71426
My question is about
bool[] boolList;
auto boolListAppender = boolList.appender();
boolListAppender ~= [ a, b, c];
I could do the same in one line with C++:
bool boolList[] = { a, b, c };
Change the braces to brackets.
D alternative(at least my D alternative) seem long. Is there
any better way for
initialing and pushing values at the same time.
Erdem
One liner alternatives for initing and pushing some values into array
I need to init and push some values into a array something like:
//DMD64 D Compiler 2.072.2
import std.stdio;
import std.array;
void main()
{
bool a = true;
bool b = false;
bool c = false;
bool[] boolList;
auto boolListAppender = boolList.appender();
boolListAppender ~= [ a, b, c];
}
Live example : http://rextester.com/TJLIXU71426
My question is about
bool[] boolList;
auto boolListAppender = boolList.appender();
boolListAppender ~= [ a, b, c];
I could do the same in one line with C++:
bool boolList[] = { a, b, c };
D alternative(at least my D alternative) seem long. Is there any
better way for
initialing and pushing values at the same time.
Erdem
Re: GtkD help
Since I wanted people to just be able to run the executable and not have to go through some install process, glib.Settings turned out to be a no-go since it requires a schema file to be installed in a specific place. Instead, I just create a json sidecar file next to the app in order to store settings. I solved the TreeView text cooler l color issue by using markup. The application code is in this repository of anyone is interested: https://github.com/Barugon/CotA
