Re: DlangUI and android
On Monday, 10 September 2018 at 09:19:52 UTC, Josphe Brigmo wrote: Is there an emulator that can run the apks? Android emulator does not work, I suppose, because it isn't java. Complains about a missing classes.dex file. It isn't clear what you're trying to do: you're trying to run a D apk compiled for ARM in an Android/x86 emulator? That won't work. I'd rather have an emulator version if possible for quicker dev. I've just been trying out the Anbox container for linux, which allows you to run Android apps on the same CPU as your linux distro, so Android/x64 apps on my linux/x64 VPS: https://anbox.io However, 15 modules from Phobos have tests that are failing or segfaulting, as it's the first time I tried Android/x64. I hope to have it working better by the next ldc 1.12 beta, maybe you can try it then. I'll also note that you can get pretty quick turnaround for actual Android hardware by enabling USB debugging or WiFi adb access on your device. But if you need to do some touch or GUI testing with the screen and don't want to manually handle the hardware each time, you'll either have to use an ARM emulator or wait for the Android/x64 support to get better.
Re: GTKD for android?
On Saturday, 8 September 2018 at 02:59:48 UTC, Josphe Brigmo wrote: I have an app I'm writing using GtkD on windows. Eventually I'd like to port it to android. Since I have never been able to actually get anything to work on android I'm curious if there are any demos with gtkD for android? I'm wondering if I just scrap the idea of using it because it won't port without a ton of work. Ideally I'd like to just cross compile and it all work out except for a few bugs. The GtkD maintainer said a couple years ago he might try it when the Android support was better: https://forum.dlang.org/post/o4rq0i$dur$1...@digitalmars.com I don't think anyone's tested it yet, do you know if Gtk supports Android well? The DlangUI maintainer did get his GUI library working on Android, as James mentioned: https://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org
Re: Temporary file creation for unittests
On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote: Hi, What's the current official position on how to create temporary files for use during a unittest. I found https://github.com/dlang/phobos/pull/5788 but it seems to be languishing in the "we have discussed all the issues that no-one will ever have a problem with" phase. What to do between now and when there is an LDC release that has the result of the merge? You could use std.file.deleteme, which is what the Phobos unittests use: https://github.com/dlang/phobos/blob/master/std/file.d#L117
Re: there's no gdc for windows?
On Tuesday, 15 May 2018 at 14:25:31 UTC, Dr.No wrote: Has gdc been supported for Windows? if so, where can I find it? I've only find Linux versions so far... ldc has good Windows support: https://github.com/ldc-developers/ldc/releases
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: 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: D in SUSE Enterprise Linux
On Tuesday, 1 May 2018 at 16:02:03 UTC, rikki cattermole wrote: On 02/05/2018 3:51 AM, Vino wrote: On Tuesday, 1 May 2018 at 15:42:38 UTC, Jonathan M Davis wrote: On Tuesday, May 01, 2018 15:18:12 Vino via Digitalmars-d-learn wrote: [...] That sounds like your /tmp is mounted with noexec. which won't work with rdmd or any other program that expects to be able to create a file in /tmp and run it. Presumably, you'll need to change the settings in /etc/fstab so that /tmp is not mounted with noexec. - Jonathan M Davis Hi Jonathan, Yes the /tmp is mounted with noexec option , we should not change this option as it is a security violation so is there any other way we can make it work, it tried setting the tmp env variable to a local FS which is mounted with the noexec option but it did not work. From, Vino.B Modify rdmd to use another directory which is more acceptable for your setup. Or just set an environment variable like TMP, if you don't want to append the flag Jonathan gave each time, as rdmd simply calls std.file.tempDir: https://dlang.org/phobos/std_file.html#.tempDir
Re: private selective import + overload = breaks accessibility rules
On Wednesday, 17 January 2018 at 02:23:40 UTC, Seb wrote: On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote: On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote: Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. 2.078, but also 2.077. Deprecation is emitted only if there is no overload; Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed. Done: https://issues.dlang.org/show_bug.cgi?id=18243 1) Imports are by default private 2) This is a known bug. See: https://github.com/dlang/phobos/pull/5584 https://issues.dlang.org/show_bug.cgi?id=17630 On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668 Are you sure about this? I thought such module-scope selective imports were supposed to be private by default since Martin's fixes for bug 314, which is why you submitted pull 5584. Bug 17630 is about something different, that selective imports pull symbols out of the imported module's non-selective imports, but he's not using any selective imports in his module b. I ran this code example through my symbol-dumping dmd (http://forum.dlang.org/thread/pbpckzwmfglzgwqve...@forum.dlang.org) and module b from his first example is indeed getting isNaN from std.math, which implies the older bug that selective imports at module scope are still leaking out.
Re: Instructions to build DMD from source don't work (anymore) here
On Thursday, 30 November 2017 at 08:38:15 UTC, Basile B. wrote: Hi, I've recently switched from a linux distribution to another (F27). During the last 2 years i used a script to build DMD, unfortunately i forgot to include it in my backup. Initially i thought "No problem, there's the instructions in the wiki, it's more or less about calling make with a couple of option". In theory only... make -fposix.mak gives me [basile@pc1 dmd]$ make -f posix.mak make -C src -f posix.mak make[1] : on entre dans le répertoire « /home/basile/dev/repos/dlang/dmd/src » no cpu specified, assuming X86 (CC) ROOT_OBJS ddmd/root/newdelete.c c++ -c -o../generated/linux/release/64/newdelete.o -Wno-deprecated -Wstrict- aliasing -fno-exceptions -fno-rtti -D__pascal= -DMARS=1 -DTARGET_LINUX=1 - DDM_TARGET_CPU_X86=1 -m64 -fPIC -std=gnu++98 -Iddmd/root -MMD -MF ../generated/linux/release/64/newdelete.deps ddmd/root/newdelete.c cc1plus: désolé, pas implémenté: mode 64 bits pas compilé According to Google Translate, this means your C++ compiler doesn't support 64-bit mode. Not sure why, since the Makefile is only compiling in 64-bit after checking that's what your kernel is, with uname -m.
Re: betterC and noboundscheck
On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote:
Hello. I try compile simple example:
import core.stdc.stdio;
import std.algorithm : min;
extern (C) void main()
{
char[256] buf;
buf[] = '\0';
auto str = "hello world";
auto ln = min(buf.length, str.length);
buf[0..ln] = str[0..ln];
printf("%s\n", buf.ptr);
}
rdmd -betterC bettercarray2.d
and get error:
/tmp/.rdmd-1000/rdmd-bettercarray2.d-435C14EC3DAF09FFABF8ED6919B624C1/objs/bettercarray2.o:
In function `main':
bettercarray2.d:(.text.main[main]+0xbc): undefined reference to
`_d_arraycopy'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
If I understand correctly _d_arraycopy is part of druntime and
it check bounds of array access.
If I add -noboundscheck flag all works fine.
dmd version is 2.076.1
Why -betterC flag not 'include' -noboundscheck flag?
It's bug or in some cases it's useful?
betterC is a new feature that's still being worked on and still
has holes in it:
https://github.com/dlang/dmd/pull/7151
I suggest you open an issue for it on bugzilla, as this sounds
like either a hole or at least something that should be
documented better:
https://issues.dlang.org
Re: ESR on post-C landscape
On Tuesday, 14 November 2017 at 19:48:07 UTC, Joakim wrote: On Tuesday, 14 November 2017 at 04:31:43 UTC, Laeeth Isharc wrote: He mentions D, a bit dismissively. http://esr.ibiblio.org/?p=7724&cpage=1#comment-1912717 Eh, he parrots decade-old anti-D talking points about non-technical, organizational issues and doesn't say anything about the language itself, who knows if he's even tried it. As for the the rest, the usual bunk from him, a fair amount of random theorizing only to reach conclusions that many others reached years ago: C has serious problems and more memory-safe languages are aiming to replace it, while C++ doesn't have a chance for the same reason it took off, it bakes in all of C's problems and adds more on top. He's basically just jumping on the same bandwagon that a lot of people are already on, as it starts to pick up speed. Good for him that he sees it picking up momentum and has jumped in instead of being left behind clinging to the old tech, but no big deal if he didn't. I thought this was a much better post in that thread, especially the last two paragraphs: "Some may claim that the programming language isn’t the place to look for help, but I disagree. If it can prevent language errors in the first place (memory management, type systems) and help me use available resources (concurrency), and deal with expected failure (distribution) then I want it in the flow of the program (my description of what should happen), not in some box bolted onto the side. And it has to be efficient, because I’ve only a few cycles to waste and no IO or memory. So that’s where I’d look for action in the programming language field – not to improve C, an imperfect solution to yesterday’s problems; I want something that helps with apps that are big, distributed, concurrent, and efficient because those are the more important problems people are solving today and in the future." http://esr.ibiblio.org/?p=7724&cpage=1#comment-1913062 To the extent microservices push in exactly this direction, D needs to make an effort there.
Re: ESR on post-C landscape
On Tuesday, 14 November 2017 at 04:31:43 UTC, Laeeth Isharc wrote: He mentions D, a bit dismissively. http://esr.ibiblio.org/?p=7724&cpage=1#comment-1912717 Eh, he parrots decade-old anti-D talking points about non-technical, organizational issues and doesn't say anything about the language itself, who knows if he's even tried it. As for the the rest, the usual bunk from him, a fair amount of random theorizing only to reach conclusions that many others reached years ago: C has serious problems and more memory-safe languages are aiming to replace it, while C++ doesn't have a chance for the same reason it took off, it bakes in all of C's problems and adds more on top. He's basically just jumping on the same bandwagon that a lot of people are already on, as it starts to pick up speed. Good for him that he sees it picking up momentum and has jumped in instead of being left behind clinging to the old tech, but no big deal if he didn't.
Re: Debug info for druntime.
On Saturday, 4 November 2017 at 21:54:14 UTC, ciechowoj wrote: What is the fastest way to have the detailed debug info for druntime? I have a program that fails in Fiber constructor after I create and delete at least 68_209 Fibers one after another. For 68_208 works fine, one more and it aborts. I'm trying to use gdb to debug, but most likely don't have symbols for druntime. The symbols for function names are there, just not the DWARF debug info, if you want to step through the corresponding source line by line. I compiled the druntime from source, is there a way to make the dmd/dub use the source compiled version? Assuming you want to use the debug version, you may be better off using ldc, which comes with debug versions of druntime and phobos and the -link-debuglib option, which will use those instead. dmd and ldc also have the -defaultlib= and -debuglib= options, from which you can specify your own or a debug build of the standard library, with -debuglib= used if you compile with -g.
Re: Just starting with D (linking with C++)
On Friday, 27 October 2017 at 17:43:08 UTC, sivakon wrote: On Friday, 27 October 2017 at 17:21:39 UTC, Joakim wrote: This should work: dmd foo.d Sample.o Just like the C examples from the D blog: https://dlang.org/blog/2017/10/25/dmd-windows-and-c/ Just used this! Got this error! sample.o: In function `foo(int, int, int)': sample.cpp:(.text+0x17): undefined reference to `std::cout' Sorry, just responded quickly from my tablet, didn't try it out first. There's actually a variant of this sample that is run as a test from the dmd compiler testsuite, so it is checked hundreds of times a day for pending pull requests, on all officially supported platforms by the auto-tester: https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 https://github.com/dlang/dmd/blob/master/test/runnable/extra-files/cppb.cpp#L41 https://github.com/dlang/dmd/blob/master/test/runnable/cppa.d#L25 Looking at the D script that runs each compiler test, it adds the following flag for all C++ objects: https://github.com/dlang/dmd/blob/master/test/d_do_test.d#L499 So adding that flag got your example to work for me: dmd -L-lstdc++ foo.d Sample.o
Re: Just starting with D (linking with C++)
On Friday, 27 October 2017 at 17:14:20 UTC, sivakon wrote:
Hi,
Just started to work with D. Great language.
I want to use C++ libraries for machine learning and deep
learning. How do I add C++ libraries to my d code.
For example,
//sample.cpp
#include
using namespace std;
int foo(int i, int j, int k)
{
cout << "i = " << i << endl;
cout << "j = " << j << endl;
cout << "k = " << k << endl;
return 7;
}
//foo.d
extern (C++) int foo(int i, int j, int k);
void main()
{
foo(1,2,3);
}
How do I compile and link each of them to produce the result?
dmd -c foo.d
gcc -c Sample.cpp
Both of them get me .o files. Where do I go from there?
Thanks,
Siv
This should work:
dmd foo.d Sample.o
Just like the C examples from the D blog:
https://dlang.org/blog/2017/10/25/dmd-windows-and-c/
Re: Huge increase in UT compile time
On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote: On Wednesday, 11 October 2017 at 08:11:37 UTC, Jonathan M Davis wrote: On Wednesday, October 11, 2017 06:25:19 Dhananjay via Digitalmars-d-learn wrote: Hello, I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar results on 2.075.1), and seeing a huge increase in unittest compilation time when the -deps parameter is also passed to dmd. This is on both OSX and linux. What can be the cause of this? Well, that's a pretty big version jump. So, a lot could have changed. One thing that comes to mind would be that imports were overhauled pretty thoroughly to try and fix various import bugs. This blog article talks about some of that: http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Or the change could be the result of something else entirely. Figuring it out would likely require doing a fair bit of debugging to narrow down when the change happened (and that's assuming that it's caused by a single commit or small set of commits rather than simply getting worse over time due to a variety of factors). - Jonathan M Davis The following observations (for the above test program) were recorded on Mac OS X 10.11.6: DMD64 D Compiler v2.073.1 real0m0.091s user0m0.067s sys 0m0.020s DMD64 D Compiler v2.074.0 real0m0.105s user0m0.072s sys 0m0.022s DMD64 D Compiler v2.075.1 real0m44.932s user0m35.732s sys 0m7.098s DMD64 D Compiler v2.076.1 real0m46.833s user0m37.827s sys 0m7.254s Furthermore, 2.075.1 gave a bunch of deprecation warnings in std/string.d. The -de switch had to be removed before running. Hope this helps, Saurabh I can reproduce on linux/x64, looks like a memory leak, as dmd balloons out to eat up all available memory until it's killed. I see it with this minimal command passed to dmd 2.075.1, but not the 2.074.1 frontend, as reported: ./dmd2/linux/bin64/dmd -c -o- foo.d -unittest -deps=foo.deps The closest issue I was able to find in bugzilla is this one, but that says it goes away with -o-, not the case here: https://issues.dlang.org/show_bug.cgi?id=17601 I suggest one of you file a bug with the minimal command, noting that it goes away if -unittest or -deps is not passed. Make sure you mark it as a regression, just like the above bug, as Walter pays special attention to those.
Re: Having trouble porting basic GLFW C++ example to D
On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote: I've been trying to port a basic GLFW C++ example to D. The C++ version shows the textures correctly. But the D version shows nothing. The code is almost identical. Heh, that's the problem. Does anyone know why the D version does not work? https://github.com/workhorsy/d_glfw I ran into this myself, took me awhile to track it down. I too took the size of dynamic arrays this way: https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L158 https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L161 That will give you 2 words for a slice or dynamic array, the length and pointer. What you want is the length of the array https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L192 multiplied by the size of the element https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L195 Sizeof works for static arrays, but is different for slices: that's likely your problem.
Re: dub cross compilation binary extension
On Tuesday, 26 September 2017 at 17:48:06 UTC, Andre Pany wrote:
Hi,
I had set up a cross compilation from Windows to Raspberry Pi
using LDC and GCC toolchain. Almost everything is working fine.
Dub creates a binary which is runnable on the Raspberry Pi.
There is only 1 small issue. Dub creates the executable with
the windows file extension ".exe".
Is there anything I can do to force dub not to include the
windows file extension?
dub.json
{
"name": "test",
"dflags-ldc": ["-mtriple=arm-linux-gnueabihf",
"-gcc=arm-linux-gnueabihf-gcc"],
"lflags-ldc":
["-LC:\\D\\ldc2-1.4.0-beta1-win32-msvc\\bin\\ldc-build-runtime.tmp\\lib\\"]
}
dub build --compiler=ldc2 -v
My current workaround is to have a batch file which renames the
file automatically. But I want to write a blog post and this
workaround looks ugly.
Kind regards
André
Dub is not meant for cross-compilation yet, it will need patches.
I'm surprised just passing those flags worked.
I mean to look at it and submit a pull. Until then, renaming
will be needed, or you could submit a pull for that yourself.
Re: Is compiling for Android/iOS possible?
On Wednesday, 6 September 2017 at 18:34:28 UTC, Timothy Foster wrote: I'm just wondering if I made an application for Windows/Mac/Linux if I could get it to also work on mobile devices, or would I have to rewrite the application in another language to get it to work? If it's possible, what should I be looking at to get something like a "Hello World" example to show on my phone using D? Backend code that does most of the work, ie your business logic, should work fine in D on mobile devices. For the frontend, I don't know of a good touch-enabled GUI that you could use in D though. If you're okay with doing your GUI in the native language, ie Java on Android, then calling D for the backend, that will work. There has been some preliminary work on getting a D GUI library, DlangUI, working on Android, but my understanding is that it isn't touch-optimized: http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org Ali gave you some good links to check out for simple apps on Android. As for iOS, Dan was working on it, but he doesn't have time for it anymore, so it hasn't been kept up to date. The upcoming ldc 1.4 official release will have easy support for Android, you can try it out with the current beta (you will need to cross-compile the stdlib for Android/ARM by using ldc-build-runtime, with a small tweak to druntime): http://forum.dlang.org/thread/ojoyytdparflttnna...@forum.dlang.org We're refining the build process for Android in the ldc 1.4 betas, so chip in if you'd like to see that done well.
Re: Getting error in dmd testsuite
On Saturday, 26 August 2017 at 21:59:10 UTC, Thomas Mader wrote: Hello, I am building ldc on Nix (https://nixos.org/nix/) but keep getting an error while running the cppa.d test from the dmd testsuite (https://github.com/ldc-developers/dmd-testsuite). 1588: ... runnable/cppa.d -L-lstdc++ (-g) -O 1588: Test failed. The logged output: 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/bin/ldmd2 -conf= -m64 -Irunnable -L-lstdc++ -od/tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable -of/tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0 runnable/cppa.d /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o: In function `_Dmain': 1588: runnable/cppa.d:(.text._Dmain[_Dmain]+0x49f): undefined reference to `int foo15372(int)' 1588: runnable/cppa.d:(.text._Dmain[_Dmain]+0x4b2): undefined reference to `Foo15802::boo(int)' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa6C131616__vtblZ[_D4cppa6C131616__vtblZ]+0x0): undefined reference to `C13161::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa4Test6__vtblZ[_D4cppa4Test6__vtblZ]+0x0): undefined reference to `C13161::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa7C13161a6__vtblZ[_D4cppa7C13161a6__vtblZ]+0x0): undefined reference to `C13161a::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa5Testa6__vtblZ[_D4cppa5Testa6__vtblZ]+0x0): undefined reference to `C13161a::dummyfunc()' 1588: collect2: error: ld returned 1 exit status 1588: Error: /nix/store/df84hkmhrhx1c2zpvrhmk6aprhlzkasx-gcc-wrapper-6.4.0/bin/gcc failed with status: 1 1588: 1588: 1588: == 1588: Test failed: expected rc == 0, exited with rc == 1 1588: 1588: make[2]: *** [Makefile:335: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa.d.out] Error 1 Apart from that all other tests pass. Any ideas? It's running on Linux with gcc 6.4.0. That module tests linking with C++ files, looks like you have some symbols that don't match up. That's weird, because those normally work with gcc. For each of them, use the readelf command from binutils to compare the symbols generated and see how they differ. For example, readelf -sW /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o |grep foo15372 Then run the same command on the D side, ie for cppa_0.o, and compare the symbols. File a bug on the ldc github if you can't figure it out: https://github.com/ldc-developers/ldc/issues
Re: dmd (v2.075.0): fully static linking: undefined reference to `__tls_get_addr'
On Saturday, 19 August 2017 at 14:22:21 UTC, kdevel wrote: On Saturday, 19 August 2017 at 14:07:49 UTC, kdevel wrote: src/rt/sections_elf_shared.d:(.text._D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv[_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv]+0x38): undefined reference to `__tls_get_addr' https://issues.dlang.org/show_bug.cgi?id=12268 That function is supposed to be provided by the dynamic linker when running your program, but I'm guessing -static makes the linker check for all symbols at link-time, not allowing such deferred linking. It looks like dmd or druntime doesn't support such full static linking yet, as they assume that function will be there.
Re: Need help with units library
On Friday, 18 August 2017 at 13:21:06 UTC, alexander1974 wrote: I want to write a library for working with units (lengths, weights, ...). It should allow maths and converting with/between different units (cm to mm, angstrom to meter, ...). [...] I have no opinion on your layout, but have you seen these existing libraries on the D package repository? http://code.dlang.org/packages/units-d http://code.dlang.org/packages/quantities Perhaps you'd be better off contributing to one of them.
Re: Specify dmd or ldc compiler and version in a json dub file?
On Tuesday, 8 August 2017 at 10:07:54 UTC, data pulverizer wrote:
On Tuesday, 8 August 2017 at 09:51:40 UTC, Moritz Maxeiner
wrote:
If your code depends on capabilities of a specific D compiler,
I wouldn't depend on build tools for that, I'd make it clear
in the source code via conditional compilation [1]:
---
version (DigitalMars)
{
}
else version (LDC)
{
}
else
{
static assert (0, "Unsupported D compiler");
}
---
There's no equivalent for the frontend version, though AFAIK.
If it's not your code that needs something compiler specific,
but you just want to control which is used, don't use dub as a
build tool, use another (cmake, meson, write your own
compilation "script" in D), and set it's invocation as a
prebuildcommand in the dub package file (make sure dub's
source file list is empty).
[1] http://dlang.org/spec/version.html#predefined-versions
Many thanks!
I'll note that you can specify that dub use a particular D
compiler for building all your own D packages, by creating a file
called .dub/settings.json in your home directory, and putting the
full path to the compiler you want in there, like so:
{
"defaultCompiler": "/home/datapulverizer/ldc-1.3/bin/ldc2"
}
Ldc uses a file like that to make sure the dub binary it comes
with uses ldc, not dmd, so you can look at that file for an
example.
However, it sounds like you want to ensure that all users of a
package are forced to use a particular D compiler, while this
will just make sure that your dub binary will always use the D
compiler you want.
Re: D on AArch64 CPU
On Sunday, 6 August 2017 at 06:26:57 UTC, David J Kordsmeier wrote: Also, why I don't look at LDC further, I think RAM on the embedded devices is still pretty skimpy, Raspi3 only has 1GB ram. It's not great for compiling with the LLVM-based things and probably run OOM. Other devices I have only have 512MB ram. So gcc is usually fine in these circumstances. Don't know about gdc, but ldc is close (most of the listed upstream PRs are merged): https://github.com/ldc-developers/ldc/issues/2153 As for memory, ldc can be used to cross-compile from a more capable machine, the official builds all ship with the AArch64 backend enabled now: https://github.com/ldc-developers/ldc/releases/tag/v1.3.0 The next ldc beta will ship with a build tool that lets you easily compile or cross-compile the stdlib yourself, so you can generate the stdlib for AArch64 even if it isn't provided: https://github.com/ldc-developers/ldc/pull/2253
Re: Is std.xml seriously broken, or is it me?
On Sunday, 30 July 2017 at 03:16:35 UTC, Mike wrote:
On Sunday, 30 July 2017 at 02:58:09 UTC, Mike wrote:
[...]
It appears `onStartTag` does not handle the root element. For
example, this code seems to work:
import std.xml;
import std.stdio;
void main()
{
auto parser = new DocumentParser("encoding=\"utf-8\"?>");
parser.onStartTag["peripheral"] = (ElementParser parser)
{
writeln("peripheral");
};
parser.parse();
}
Mike
You may want to try the experimental candidate for Phobos
instead, which was developed as a GSoC project but never finished:
http://code.dlang.org/packages/std-experimental-xml
Re: It makes me sick!
On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote: On Saturday, 29 July 2017 at 19:17:08 UTC, Joakim wrote: On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote: [...] What you are suggesting is blatantly idiotic. No software ever made supports simply installing on top of an old installation from a compressed zip or tar file. If you need hand-holding, the installer will wipe the old install before unpacking the new install for you. The zip file is for people who know what they are doing, such as not unpacking on top of the old install. You should just use the installer from now on, not the zip file, if you can't be bothered to remove the old install first. bullshit. Are you a moron? You really think your absolute "No software ever" is logical? The only moron here is the one who simply uncompresses zip files on top of old software. That either shows blatant ignorance of what uncompressing does, or sheer stupidity that it would work well for a compiler install. Of course there is trivial software that consists of a single binary, for which you could do this. But there is nothing "logical" about that, just an exception for extremely simple software, which a compiler and its stdlib clearly isn't. I can name many off the top of my head. Have you ever heard the fucking word "portable"? I guess not, go look it up. You can name so many, yet you did not name a single one. I guess it's not so easy. Yes, that's hilarious, "portable" has essentially nothing to do with this. Please take your jack ass arrogant self somewhere else. The only jackass is the one constantly braying about doing stupid things and how we should account for every dumb thing you do. If you want to blame us for your not knowing how to deal with zip files, sounds like you're the one who should leave. Also, equating dmd to an audio program or a clip art program that is designed to load any and all files in it's install dir is moronic too. It is not moronic, it's a simple example that illustrates the larger principle, which is much more relevant for a compiler and its source. The fact that you rail on the example rather than understanding the principle shows how much of an idiot you are. I'm tired of your constant complaints in this forum, which reflect your own stupidity and ignorance more than anything else. I'm amazed people have treated you this nicely in this thread, and yet you keep ranting about how the D devs should account for the most idiotic things you do. GTFO, nobody wants you around.
Re: It makes me sick!
On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote: On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote: On Friday, 28 July 2017 at 21:23:22 UTC, FoxyBrown wrote: [...] I'm sorry if I'm not expressing it in a way that agrees with you but you're looking at the wrong side of the example. You're pasting one set of files onto another and expect the software to somehow know to ignore some of them. YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT THE HELL IT IS DOING! I'm sorry if that is too complex to understand. If the software has some build in design that makes it use arbitrary files in a specific way like it does with std.datetime, then it should have sanity checks. After all, who the hell knows more about dmd using std.datetime and how it uses it and such, the end user or the programmer of dmd? You are expecting the end user, who generally knows very little to do the dirty work instead of having the programmer who is suppose to know what the fuck is going on to add sanity checks, useful error messages, etc. Ali suggested a very reasonable solution that would have solved this problem and you guys are against it and offer no solution to the issue. It all boils down to laziness. Too lazy to spend the time to add code that makes dmd more robust. Simple as that. It's not that it can't be done, like you bone-heads are claiming, but that you simply don't want to do it. Another very simple solution: Before the zip file is generated, a listing of all the files in the dmd installation that are used(which should be all of them) is taken. This file then is parsed by dmd and only those files in the dmd dir that are in the list are used. This would also have avoided the issue and future issues. Any stale files in the dir would simply be ignored. But, again, too much work. Keep making the end users deal with these problems instead of doing your due diligence. That we, we have something to waste our time with in these forums instead of real problems. What you are suggesting is blatantly idiotic. No software ever made supports simply installing on top of an old installation from a compressed zip or tar file. If you need hand-holding, the installer will wipe the old install before unpacking the new install for you. The zip file is for people who know what they are doing, such as not unpacking on top of the old install. You should just use the installer from now on, not the zip file, if you can't be bothered to remove the old install first.
Re: GtkD on android?
On Saturday, 22 July 2017 at 18:59:44 UTC, FoxyBrown wrote: With LDC's new ability to do android/arm, we are missing the ability to do GUI's? Can any of the current D solutions work such as GtkD or QtD? I'm looking for something somewhat lightweight, easy to use(I find GtkD a bit funky but it does seem to work and is relatively easy once one gets through the basics). I think having a GUI builder is crucial though as it makes it so much easier in the long run. Glade is a bit funky but functional and works. Ideally I'd like to be able to make portable apps that just work across the board(mac, linux, windows, android) without much hassle. Mike said maybe later, when I asked him in January: http://forum.dlang.org/post/o4rq0i$dur$1...@digitalmars.com In the meantime, you can try DlangUI, as Seb pointed out, but I get the impression it's not touch-optimized, just like Gtk.
Re: Auto-decoding
On Saturday, 15 July 2017 at 18:14:48 UTC, aberba wrote: On Saturday, 15 July 2017 at 05:54:32 UTC, ag0aep6g wrote: On 07/15/2017 06:21 AM, bauss wrote: [...] 1) Drop two elements from "Bär". With auto-decoding you get "r", which is nice. Without auto-decoding you get [0xA4, 'r'] where 0xA4 is the second half of the encoding of 'ä'. You have to know your Unicode to understand what is going on there. [...] So what is the current plan? :) Andrei has talked about having a non-auto-decoding path for those who know what they're doing and actively choose that path, while keeping auto-decoding the default, so as not to break existing code. Jack has been submitting PRs for this, but it is probably tedious work, so progress is slow and I don't know how much more remains to be done: https://github.com/dlang/phobos/pulls?q=is%3Apr+auto-decoding+is%3Aclosed
Re: rdmd issues
On Thursday, 6 July 2017 at 00:31:04 UTC, FoxyBrown wrote: rdmd -m64 Build.d Error: can't run 'C:\Program Files\VS\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64', check PATH The path exists, but since it doesn't tell me what it is trying to run, I have no clue. The path contains link.exe. Add the --chatty command-line option, it will tell you everything rdmd is trying to do.
Re: stacktrace for InvalidMemoryOperationError
On Tuesday, 11 July 2017 at 01:34:08 UTC, crimaniak wrote: Hi! I have vibe.d application and long-standing error in it. For the current moment, I have logs for stdout, stderr, and additional log to write exceptions I catch. This error gives me only the short line in stderr log: core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid memory operation Also, I use registerMemoryErrorHandler(); (see http://vibed.org/docs#handling-segmentation-faults ) What else can I do to have the stack trace for this error? I can't debug it because I don't have it on my developer's machine. See the wiki page about this: https://wiki.dlang.org/InvalidMemoryOperationError If you can't do all that, look for places you might be allocating in a destructor. The recent GC allocation flag -vgc might help: https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
Re: iOS Apps in D
On Wednesday, 31 May 2017 at 12:49:38 UTC, Oleksii wrote: Hi everybody, Perhaps this topic has been raised many times before, but I'm going to go back to it anyways :-P Are there any good reference materials and/or tutorials on programming for iOS and Android in D? Other than this wiki page that shows you how to build a basic Android app and the README for the iOS port, no: https://wiki.dlang.org/Build_LDC_for_Android https://github.com/smolt/ldc-iphone-dev/blob/master/README.md I wonder if anybody could share their story of success with D on mobile? I don't think there has been one. The closest is this demo of porting some DlangUI apps to Android: http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org
Re: D scripting in D
On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote: On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote: So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers? it is... the link above is all there is to it, you simply compile it. The docs also call it a download: http://dlang.org/rdmd.html dmd just happens to bundle it. The others prolly should too. Ldc should have it in the next release, except on Windows: https://github.com/ldc-developers/ldc/issues/548#issuecomment-306073946
Re: Can i using D & LLVM & SDL2 for Android?
On Tuesday, 14 March 2017 at 01:57:56 UTC, rikki cattermole wrote: On 14/03/2017 6:08 AM, Joakim wrote: On Monday, 13 March 2017 at 09:33:39 UTC, rikki cattermole wrote: On 13/03/2017 7:48 PM, Joakim wrote: [...] Why exactly doesn't the Android port support dlopen, dlsym and dlclose? It is provided by the NDK libc. At least according to this[0]. [0] https://developer.android.com/ndk/guides/stable_apis.html I was more talking about D shared libraries, which I'm assuming DerelictSDL2 qualifies as and would require Phobos built as a shared library. That hasn't been tried yet on Android. DerelictSDL2 would be statically linked, it would dynamically bind via dlopen, dlsym and dlclose to SDL itself which would be compiled as a shared library. This is how Derelict based libraries work. Ah, I have either misunderstood or forgotten how Derelict works. If the D code is all statically linked and only non-D, C/C++ shared libraries are loaded in addition to the single D shared library, there should be no problem using all Derelict modules on Android.
Re: TLS
On Friday, 10 March 2017 at 06:41:46 UTC, M-exe wrote: I found that D is great language, but for my own reasons I'm trying to use it without TLS at all. Can the TLS directory be avoided? (compiling on windows) I don't know what you mean by the TLS directory, can you explain? I mean, can it avoided without losing GC and main language features? You could probably modify druntime so that it doesn't use any Thread-Local Storage, but Phobos uses it extensively, as global and static variables are put in TLS by default since D 2.030: https://dlang.org/migrate-to-shared.html Are you against emulated TLS also? If not, I have modified dmd, ldc, and druntime to use the same emulated TLS scheme Walter came up with for OS X, for my Android port: https://github.com/dlang/dmd/pull/3643 https://github.com/ldc-developers/ldc/pull/1447 https://github.com/dlang/druntime/pull/784 You may be able to use something similar on Windows, depending on how feasible such an emulated TLS scheme is there and if you want to dig into these details.
Re: Can i using D & LLVM & SDL2 for Android?
On Monday, 13 March 2017 at 09:33:39 UTC, rikki cattermole wrote: On 13/03/2017 7:48 PM, Joakim wrote: [...] Why exactly doesn't the Android port support dlopen, dlsym and dlclose? It is provided by the NDK libc. At least according to this[0]. [0] https://developer.android.com/ndk/guides/stable_apis.html I was more talking about D shared libraries, which I'm assuming DerelictSDL2 qualifies as and would require Phobos built as a shared library. That hasn't been tried yet on Android. On Monday, 13 March 2017 at 10:11:35 UTC, Mike Parker wrote: On Monday, 13 March 2017 at 06:48:01 UTC, Joakim wrote: [...] The alpha release of DerelictSDL2 3.0 supports static linking. When compiling manually, it requires -version=DerelictSDL_static on the command line and all files matching "derelict/sdl2/internal/*_dyn*.d" should be excluded from the build. When building DerelictSDL2 with DUB, specifying -cderelict-sdl2-static gets the job done, or the same can be added as a subConfiguration value in a project's dub.json/sdl file. Thanks for the update, didn't know that.
Re: Can i using D & LLVM & SDL2 for Android?
On Thursday, 9 March 2017 at 10:35:18 UTC, dummy wrote: On Wednesday, 8 March 2017 at 10:24:24 UTC, Joakim wrote: On Tuesday, 7 March 2017 at 12:06:48 UTC, dummy wrote: Just thought. I do want to know. :-) As far as I know is, * LDC2 woring on NDK(yah!) * Native OpenGLES: http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D * Dlangui working on Android that based on SDL2: https://github.com/buggins/dlangui / https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ regards, Yes, though I have not tried SDL2 myself. https://forum.dlang.org/post/hbumubsbrzffvgria...@forum.dlang.org Ah, you're right. I will trying DerelictSDL2. Thx :-) Regarding the link to that forum post, that bug has since been found and fixed. If you're planning on using Derelict, there is an issue where all Derelict libraries are loaded as shared libraries, whereas the Android port currently doesn't support loading shared libraries. If DLangUI is using SDL2, maybe he has a header file that allows him to statically link against SDL2, which you could reuse. Otherwise, you may need to generate one using DStep: https://github.com/jacob-carlborg/dstep or modify the DerelictSDL2 files to allow you to link statically.
Re: Can i using D & LLVM & SDL2 for Android?
On Tuesday, 7 March 2017 at 12:06:48 UTC, dummy wrote: Just thought. I do want to know. :-) As far as I know is, * LDC2 woring on NDK(yah!) * Native OpenGLES: http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D * Dlangui working on Android that based on SDL2: https://github.com/buggins/dlangui / https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ regards, Yes, though I have not tried SDL2 myself.
Re: Cross-compile with LDC
On Wednesday, 8 February 2017 at 17:57:49 UTC, kinke wrote: On Wednesday, 8 February 2017 at 17:21:03 UTC, Oleg B wrote: If I understand correctly with vanilla LDC I can't cross-compiling from host linux-x86_64, but with your patch I can. Right? Right. Joakim Noah has worked on LDC for Android and as far as I know provides some prebuilt compilers, a native one and a cross-compiler (Linux x86_64 host) including that patch. There's also a pre-built Windows -> ARM cross-compiler; see http://forum.dlang.org/thread/xzzzfvahuwvgsluli...@forum.dlang.org and more ARM-related threads in our subforum. That's not really a Windows build of ldc, he just used the new linux support in Windows 10. There is a build of ldc 1.1.0 for native linux/ARM, if you want to compile D code on the ARM device itself: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 If not, it's pretty straight forward to build a cross-compiler for ARM, take a look at my patches and instructions for Android: https://github.com/joakim-noah/android/releases If I use your patch must I use in my programs only double or I can stay real in existing code? Don't worry, the reals can stay. The patch will make reals the same as double, ie they're all 64-bit, so it is irrelevant which one you use. If you're writing cross-platform code and care about that difference on other platforms, you may need to check for it. Take a look at std.math for examples of this, where it checks the length of the mantissa sometimes for reals.
Re: Compile to C?
On Monday, 23 January 2017 at 02:20:02 UTC, Nestor wrote: On Monday, 23 January 2017 at 01:17:20 UTC, Adam D. Ruppe wrote: On Monday, 23 January 2017 at 01:12:21 UTC, Nestor wrote: You mean phobos, or system libraries? Phobos but mostly the druntime that interfaces with the system. I see, I was mostly thinking in Android and/or other platforms, but it does seem like heavy work, though curiously this approach seems to be working for Nim (at least so far), is it that the language is better suited for that, or simply that more work has been put into it? (not bashing D, honest curiosity) Btw, Ldc has good support for a lot of platforms already, including Android and iPhone: http://wiki.dlang.org/LDC Porting druntime to a new OS is not heavy work, mostly translating some C headers: https://github.com/dlang/druntime/pulls?utf8=✓&q=is%3Apr%20is%3Aopen%20netbsd
Re: Compile to C?
On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote: Hi friends, Is there a way to "compile" d code to C, similar to what nim does? That would be cool for greater portability. The wiki says there was a dmd fork that attempted this 5 years ago, don't know how far he got: https://wiki.dlang.org/Compilers https://github.com/yebblies/dmd/tree/microd
Re: Android Status
On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote: Well, I posed a reply but I guess it didn't get though ;/ I'm only suing android-x86 because I thought it would be easier to test/debug. My device is a cortex-arm7. It's probably not easier, and in any case, android-x86 won't be supported, largely because I don't have any working x86 devices. Two questions I have: 1. In the command lines present there is a lot of use of `x86`. There shouldn't be when compiling for ARM. The instructions for ARM only have it because of the path where the cross-compiler toolchain is stored, in a directory called toolchains/llvm/prebuilt/linux-x86_64/ because that's the OS and CPU architecture where you can run the cross-compiler. I used them to compile the hello world for my device and it worked so I'm a bit confused. I realize there is the x86 binaries for compiling and then the binaries that are compiled to but not sure what is what. You are cross-compiling from linux (even though it's really a linux shell running in Windows) with the x86 or x86_64 CPU architecture to Android with the ARM CPU architecture. As such the cross-compiler itself is an x86_64 binary, but produces an ARM object file and binary. You have to be careful to set up the toolchain right or you will produce files for the wrong architecture. 2. I downloaded the native_app_glue.d and tried to compile it. It imports jni.d which I found in hello-jni and I copied that to the android folder and was able to compile it using effectively the same command line I used to compile the working hello world code. I'm not sure why you are downloading and moving around these individual files. They should all be in my android repository, which both pages of instructions tell you to clone. but when I try to then use it to compile the hello-jni sample I get that it is an invalid format and many ELF relocation errors. Could you send me your working native_app_glue.o(if for the cortex-arm7 or try to compile it for both cortex-arm7 and x86/x64) or explain to me what is the issue with linking it in and how to fix it? No. I'm not going to support Android/x86 and all the instructions are there for Android/ARM. cmdline that compiles android_native_app_glue.d bin/ldc2 -m32 -shared -Iandroid -c android_native_app_glue.d (tried with -m64 and without either) This won't work because my latest build of the ldc cross-compiler will try to compile for ARM by default. cmdline trying to compile hello-jni. $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-soname,libhello-jni.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ../obj/local/x86/objs-debug/hello-jni/hello-jni.o ../android_native_app_glue.o -lgcc -gcc-toolchain $NDK/toolchains/x86-4.8/prebuilt/linux-x86 -target i686-none-linux-android -no-canonical-prefixes -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o ../libs/libhello-jni.so which gives the errors /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in generic ELF (EM: 40) /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in generic ELF (EM: 40) /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in generic ELF (EM: 40) ../android_native_app_glue.o: error adding symbols: File in wrong format clang: error: linker command failed with exit code 1 (use -v to see invocation) It's telling you that android_native_app_glue.o is the wrong format, likely ARM as I noted above. You can check the format with this command: file android_native_app_glue.o Since you're trying to create a binary for Android/x86, it cannot use the ARM object file to build it. It might be better to wait for you to finish your build setup which might resolve all these problems and be more robust(I'd like to be able to easily build for different platforms(for testing on VM and device). There is nothing to wait for, as I will not support Android/x86, certainly not anytime soon. But if all I need to do is get the android_native_app_glue to work to run full fledged apps, then It seems I'm close? (just need to compile it to the correct format?) It may not take much more to get it working, as I did first try ldc with Android/x86 and left that support in. However, it hasn't been tested in more than a year and so probably will require some fixing up. If you want to look into that, you're on your own.
Re: Android Status
On Monday, 9 January 2017 at 18:38:01 UTC, Ignacious wrote: On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote: I've tried to write up detailed instructions on the wiki. I'm still improving those and plan to spin off those two sections I linked you, on how to just build the samples, into their own page. You can contribute any steps you had to take with Bash/Ubuntu on Windows with the prebuilt linux/x64 cross-compiler there, once I put the page up. Yeah, I found it a bit confusing though. It seems like it is written up by someone that is working on the core rather than a newb! ;) Yep, that's what it is. That's one reason why I want to add another wiki page which will just focus on building the sample apps, as opposed to building the cross-compiler too. The main problem I have had seems to be that UoW uses ver 14. Somehow I was able to upgrade by following docs online(wasn't easy but eventually got there and everything seems to work... I should have documented ;) but I wasn't sure if the process would work. Supposedly ver 16 exists by one has to be part of the dev team or something. If you know all the steps to upgrade Ubuntu on Windows, you may want to document them on the wiki page I will put up or link to a good resource that shows how to do it. I don't because it was all new to me(I didn't know there was even such a thing as UoW. I simply searched for the errors I got and tried different solutions until it worked. Luckily the outcome worked... which is not always the case. Is it easy for you to nuke it and go back to the original 14.04 setup? I may be able to remove some of those ldc library dependencies, so that it works on the original setup too. I think that it would be a boon for D to have some type of well defined and well planned Android development suite rather than what seems to be hacked/cobbled together. This would bring not only more developers to D for android but also to D in general. Yes, definitely the plan. The big problem right now is that it requires a slightly modified llvm. If that weren't needed, we could just have the official release builders also build the standard library for Android/ARM on their OS. I'm gonna try the opengl examples and hopefully the work. The main problem I see is how to actually write "commercial" apps using D for android. Can it be done successfully? Nobody knows because there isn't a history. What are the exact steps, say, to add ads, or interface with the subsystem? I saw that there is some way to call some java stuff from D but seems like nothing is thoroughly tested(most of the work as been just trying to get things up and running). I got interfacing with Java working late last year, through JNI. Not "thoroughly tested" by any means, but seems to work. The only way to know whether commercial Android apps can be written in D is to actually do it. I plan on writing one this year. On Monday, 9 January 2017 at 23:24:08 UTC, Ignacious wrote: How difficult is it to build for x86/x64? Would be nice to be able to use something like http://www.android-x86.org/ as a test instead of an actual device. Does one simply have to use the proper ldc2/dmd and link in the correct libs? or is it more complex? Not too hard. I haven't bothered with it because Android/x86 had almost no market share, and Intel has essentially given up and pulled out of that market. I may someday update it again, but the problem right now is that I don't have an x86 machine on which to try it. I've gone all ARM and setting Android/x86 up on a VPS takes some work. Also, I'm a bit confused on how to compile the source examples(working it out and trying to explain the solutions as I type) https://wiki.dlang.org/Build_DMD_for_Android As noted there, those instructions haven't been updated in a year and a half and are out of date. I just updated the wiki page with a stronger warning. (set $NDK permanently) I have done(easy, find the file and modify) rt_init(); android_main(android_app); rt_term(); Clean up and compile as before: $NDK/ndk-build clean NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1 But no error. Object files for various architectures are created though, it seems. (rt_ errors do no exist contrary to what is said in the docs) I'm not sure why that wouldn't error anymore, it should be the same. Anyway, since I wrote those instructions a couple years ago, I translated the google-provided android_native_app_glue.c to android_native_app_glue.d and didn't bother updating the instructions for Android/x86. But the following seems need updating/explaining. I am using prebuilt ldc2 for android from some link you provided. -android doesn't seem to work and I can't find sensor.d (not sure if it is needed anymore)? ../../../dmd/src/dmd -android -I../.. -ofobj/local/x86/objs/native-activity main.o -c jni/main.d ../../android/sensor.d I had to change to use ldc2,
Re: Android Status
On Monday, 9 January 2017 at 00:40:35 UTC, Ignacious wrote:
On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:
On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:
Not sure what is going on, of course ;) So much BS just to do
something that is suppose to be simple ;)
test.d
void main()
{
}
here is test.o
http://pastebin.com/NRrKgKtb
Any ideas?
Oh, that's easy: install the NDK too, as shown on the wiki.
You need the linker that supports ARM from the NDK. Follow
the instructions from the wiki to compile and link the binary,
simply having ldc do everything won't work.
Ok, after executing
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm
-lgcc -gcc-toolchain
$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
-target armv7-none-linux-androideabi -no-canonical-prefixes
-fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb
-Wl,--export-dynamic -lc -lm test.o lib/libphobos2-ldc.a
lib/libdruntime-ldc.a -o test
I get a test elf file with no errors(although 2.5MB for a hello
world).
I had to do the chmod 755 test
then
./test
to get any output. Before that no output and no errors so
wasn't sure what as going on.
Looks like everything is working! ;)
Good to hear it finally works. :D
Seems like someone really needs to put some time in to getting
all this stuff organized and situated
Maybe the D language foundation can push some money towards it
to get it started off on the right foot?
I'll try to get some of the opengl examples on your repository
to see if they work soon.
I don't think money is the issue as much as people like you
trying it on your own platform and documenting any problems you
find.
Cross-compiler toolchains are never simple, consider yourself
lucky for having gotten off easy. :)
I realize things are difficult but it's people that make it
that way ;) Life would be so much simpler if people would just
properly document stuff exactly(or, rather, do what they are
suppose to do). (Even windows seems to love to forget to put in
descriptions of services, tasks, application descriptions, etc).
I've tried to write up detailed instructions on the wiki. I'm
still improving those and plan to spin off those two sections I
linked you, on how to just build the samples, into their own
page. You can contribute any steps you had to take with
Bash/Ubuntu on Windows with the prebuilt linux/x64 cross-compiler
there, once I put the page up.
The main problem I have had seems to be that UoW uses ver 14.
Somehow I was able to upgrade by following docs online(wasn't
easy but eventually got there and everything seems to work... I
should have documented ;) but I wasn't sure if the process
would work. Supposedly ver 16 exists by one has to be part of
the dev team or something.
If you know all the steps to upgrade Ubuntu on Windows, you may
want to document them on the wiki page I will put up or link to a
good resource that shows how to do it.
Re: Android Status
On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:
Not sure what is going on, of course ;) So much BS just to do
something that is suppose to be simple ;)
test.d
void main()
{
}
here is test.o
http://pastebin.com/NRrKgKtb
Any ideas?
Oh, that's easy: install the NDK too, as shown on the wiki. You
need the linker that supports ARM from the NDK. Follow the
instructions from the wiki to compile and link the binary, simply
having ldc do everything won't work.
Cross-compiler toolchains are never simple, consider yourself
lucky for having gotten off easy. :)
Re: Android Status
On Sunday, 8 January 2017 at 19:58:06 UTC, Ignacious wrote: I suppose it will be easier to install a real ubuntu distro rather than relying on windows? All these issues seem to be related to outdated versions? Distributor ID: Ubuntu Description:Ubuntu 14.04.5 LTS Release:14.04 Codename: trusty I doubt that'd work either as Debian just uses older packages. Your best bet may be to just compile ldc yourself, by following the instructions on the wiki.
Re: Conditional Compilation Multiple Versions
On Friday, 6 January 2017 at 13:44:37 UTC, Claude wrote:
Yes, it works quite well for most use cases and should
generally be preferred. I disagree that it scales, though. At
some point (a point that is highly project-dependent), it
breaks down, requiring either very large modules or duplicated
versions across multiple modules.
Yes, in that case, you would probably break it down into
several specialized config modules. I meant it forces you not
to put directly version(Windows) into your code, but rather
version(ThatFeatureSupportedByWindowsAmongstOtherOSs).
Yes, this is the idiom that version() encourages. You can put
all your configuration logic in one place in your build script
and then pass -version=hasFeature to your build. If you use
reggae, you can even write your configuration logic in D:
https://github.com/atilaneves/reggae/
My position is that I will always choose version blocks first,
but if I find myself in a situation where I have to choose
between duplicating version statements (e.g. version(A)
{version=AorB; version=AorC;}) across multiple modules and
restructuring my code to accommodate versioning, I much prefer
to use the enum alternative as an escape hatch.
Ok, that's interesting.
Do you have code samples where you do that? I'm just curious.
Druntime uses this for its translation of POSIX header files:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/config.d
An example:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/resource.d#L96
Re: Android Status
On Monday, 2 January 2017 at 11:47:52 UTC, Ignacious wrote: On Monday, 2 January 2017 at 03:08:10 UTC, Joakim wrote: On Sunday, 1 January 2017 at 09:34:24 UTC, Ignacious wrote: Can you try sudo apt-get install libconfig9 I don't know if that will install something different, but it's the command I see others using online. Otherwise, check if the libconfig++9 package you installed included libconfig.so.9, which is what ldc is linked against. If not, install the package that provides that library. The wiki mentions installing libconfig-dev, you could always just install that if nothing else works. That is what I used to get it on there in the first place... but the ldc compiler still could not find it. The problem seems to be where ldc2 is looking for libconfig.so.9 rather than it being installed or not. How do I either know where it is looking for where to put it? You said you installed libconfig++9, which an apt search shows me is a different package than libconfig9, that includes a library named differently. As I said, are you sure that particular libconfig.so.9 library is installed? If it is, manually adding its path to LD_LIBRARY_PATH is the way to make sure it's found. Ok, I didn't realize they were different packages. I now get the error ./bin/ldmd2: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory and trying to install libncursesw is missing. I tried installing libncurses5 and it worked, but, of course, not version 6 or whatever. tried various things... nothing works. ./bin/ldc2: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory I downloaded the sources. I had to install gcc, make, then I did ./configure --enable-widec (http://arstechnica.com/civis/viewtopic.php?f=20&t=1161942), then ran make.. I end up getting the errors make[1]: Leaving directory `/mnt/b/c/test' cd misc && make DESTDIR="" all make[1]: Entering directory `/mnt/b/c/misc' WHICH_XTERM=xterm-new \ ticdir=/usr/share/terminfo \ /bin/sh ./gen_edit.sh >run_tic.sed echo '** adjusting tabset paths' ** adjusting tabset paths sed -f run_tic.sed ../misc/terminfo.src >terminfo.tmp make[1]: Leaving directory `/mnt/b/c/misc' cd c++ && make DESTDIR="" all make[1]: Entering directory `/mnt/b/c/c++' cp ./etip.h.in etip.h sh ./edit_cfg.sh ../include/ncurses_cfg.h etip.h substituting autoconf'd values from ../include/ncurses_cfg.h into etip.h ... CPP_HAS_PARAM_INIT 0 ... CPP_HAS_STATIC_CAST 0 ... ETIP_NEEDS_MATH_EXCEPTION 0 ... ETIP_NEEDS_MATH_H 0 ... HAVE_BUILTIN_H 0 ... HAVE_GPP_BUILTIN_H 0 ... HAVE_GXX_BUILTIN_H 0 ... HAVE_IOSTREAM 0 ... HAVE_TYPEINFO 0 ... HAVE_VALUES_H 0 ... IOSTREAM_NAMESPACE 0 cd ../objects; -I../c++ -I../include -I. -DHAVE_CONFIG_H -D_GNU_SOURCE -DNDEBUG -I. -I../include -c ../c++/cursesf.cc /bin/sh: 1: -I../c++: not found make[1]: *** [../objects/cursesf.o] Error 127 make[1]: Leaving directory `/mnt/b/c/c++' make: *** [all] Error 2 So, now I do not know what to do next. Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libncurses6 (This is why I hate working linux, so much obfuscation... so many potential points of failure) Yeah, not a good idea to build from source yourself. Try the advice here, ie see if you can install a package with that library or just symlink to the older library if not: http://askubuntu.com/questions/771047/erlang-error-while-loading-shared-libraries-libncursesw-so-6 Every system has these problems, whether Windows, linux, or OS X. Linux makes it really easy to install packages and libraries, but then you can hit this issue where Debian/Ubuntu doesn't provide the latest versions of packages like Arch does, which is where I compiled the cross-compiler. Also, once I go through all this trouble, I have to do it again for the arm verson(using x86-64 ldc)? Can I install on the same system or will the libraries conflict and I'll have to go through all this mess again? I'm not sure what you mean, there is no other ARM version. All you have to do is download the cross-compiler and run it. The cross-compiler is a linux/x64 binary that comes with a pre-compiled standard library for ARM. Once you can run this cross-compiler build I provided, by setting up the needed libraries, you should be able to build Android binaries or apks just by using the cross-compiler, by following these instructions: http://wiki.dlang.org/Build_LDC_for_Android#Build_a_command-line_executable http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D However, you will also want to install the Android SDK for Windows, which requires Java, if you want to build an apk in the usual way, as mentioned in the wiki: http://developer.android.com/sdk/index.html Alternately, you could package an apk from sc
Re: Android Status
On Sunday, 1 January 2017 at 09:34:24 UTC, Ignacious wrote: Can you try sudo apt-get install libconfig9 I don't know if that will install something different, but it's the command I see others using online. Otherwise, check if the libconfig++9 package you installed included libconfig.so.9, which is what ldc is linked against. If not, install the package that provides that library. The wiki mentions installing libconfig-dev, you could always just install that if nothing else works. That is what I used to get it on there in the first place... but the ldc compiler still could not find it. The problem seems to be where ldc2 is looking for libconfig.so.9 rather than it being installed or not. How do I either know where it is looking for where to put it? You said you installed libconfig++9, which an apt search shows me is a different package than libconfig9, that includes a library named differently. As I said, are you sure that particular libconfig.so.9 library is installed? If it is, manually adding its path to LD_LIBRARY_PATH is the way to make sure it's found.
Re: Android Status
On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote: On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote: On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote: What is the current status for building android apps in D? I would like to create simple graphic based apps but don't wanna get bogged down in trying to get car moving without any wheels. Should all work, but nothing other than small apps have been tested. Try the latest beta, which I just put up: http://forum.dlang.org/post/xetfqojxijgobisfa...@forum.dlang.org If you want something more substantive than my ports of the NDK's sample apps, check out Vadim's Tetris app, which I spent half an hour playing on my phone, :) or his minecraft-like demo (click on the sourceforge link from his forum post to get the apps): http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org Let me know if you have any questions or problems. Is there any way to get a package that works for windows? While the steps don't seem too difficult to do, things never go well for me(something always breaks... always!) did install the linux subsystem but... seems like it would be easier for you to compile a binary and upload it... since you know what you are doing and have everything at hand already... At least that gives me(and others) the ability to try to build the examples and see how it works and all that... then I can go through all the trouble of building the compiler myself if it seems worth it rather than wasting time. Sorry, I haven't used Windows in more than a year, ever since my ultrabook died. I've gone full Android since then, which is why it is easier for me to provide a native Android compiler than a Windows cross-compiler. :) I'm currently typing this message out on an Android 5.1" smartphone, propped up on a cheap Chinese tablet stand in front of me and hooked up to a full USB keyboard. In any case, you should be able to use the linux build I provide, as you later found. On Saturday, 31 December 2016 at 06:48:12 UTC, Ignacious wrote: On Saturday, 31 December 2016 at 06:33:10 UTC, Ignacious wrote: On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote: On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote: [...] I see these: https://github.com/joakim-noah/android/releases Seems the two archives are identical though except the libs? Is this what I use to compile the examples? nvm mind, I guess I accidentally extracted the same archive thinking it was the other. so, essentially these are the two different compilers for the two different android architectures? As mentioned at the top of the release, the first is a native Android compiler, meaning you use it on an Android tablet or smartphone. The second is a linux cross-compiler, meaning you need a linux/x64 shell from which you cross-compile to Android/ARM. On Saturday, 31 December 2016 at 08:05:42 UTC, Ignacious wrote: Ok, so I installed ldc2-android-arm-1.1.0-beta4-linux-x86_64.tar.xz in to ldcandroid and tried running ./bin/ldc2 -c test.d I get the error. ./bin/ldc2: error while loading shared libraries: libconfig.so.9: cannot open shared object file: No such file or directory Searched the file system for libconfig and found nothing so I did sudo apt-get install libconfig++9 which installed it under lxss\rootfs\usr\lib\x86_64-linux-gnu It shows up when I do sudo ldconfig -v /usr/lib/x86_64-linux-gnu: libconfig++.so.9 -> libconfig++.so.9.1.3 I tried adding this: export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu But still same issue. Any ideas how to fix this? Can you try sudo apt-get install libconfig9 I don't know if that will install something different, but it's the command I see others using online. Otherwise, check if the libconfig++9 package you installed included libconfig.so.9, which is what ldc is linked against. If not, install the package that provides that library. The wiki mentions installing libconfig-dev, you could always just install that if nothing else works. Let me know if you run into any other problems. The Win10 support is brand new, just added this week, so we don't have much experience with it.
Re: Android Status
On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote: What is the current status for building android apps in D? I would like to create simple graphic based apps but don't wanna get bogged down in trying to get car moving without any wheels. Should all work, but nothing other than small apps have been tested. Try the latest beta, which I just put up: http://forum.dlang.org/post/xetfqojxijgobisfa...@forum.dlang.org If you want something more substantive than my ports of the NDK's sample apps, check out Vadim's Tetris app, which I spent half an hour playing on my phone, :) or his minecraft-like demo (click on the sourceforge link from his forum post to get the apps): http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org Let me know if you have any questions or problems.
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. Sorry, I didn't see this thread till now, or I could have saved you some time by telling you not to apply the llvm patch on non-Android linux. Note that you don't have to compile llvm yourself at all, as long as the system llvm has the ARM backend built in, as it often does.
Re: Autodecode in the wild and An Awful Hack to std.regex
On Thursday, 28 July 2016 at 21:02:59 UTC, John Carter wrote: On Thursday, 28 July 2016 at 15:48:58 UTC, Seb wrote: [...] Eh. I hoped that somewhere in that explosion of discussion on the topic the problem had been solved and I had just missed it and merely had to use that. Also this idea is a bit immature for a DIP... I haven't look at the regex code beyond the the stack trace it died on. ie. * Would this even be a Good Idea for a dip or is it better solve by another existing means? * I only inspected and changed one occurrence of decode (the one that broke) is there any other route in the regex engine that could throw a UTFException? * Would adding an additional template parameter with default break existing code? Or would I have to provide a shim? I suggest you talk to Dmitry, who wrote std.regex, as he will be motivated to look into this.
Re: Using D in Android App
On Saturday, 16 April 2016 at 04:04:24 UTC, Justice wrote: Is it difficult to create a D business like app and connect it to android through java for the interface? Not difficult, but it hasn't really been done yet. I don't anticipate JNI causing much of a problem, but I need to look into it more. I'd rather create all the complex stuff in D and either use it natively through java(I need a UI). If it is workable, can the same be said for IOS(just recompile the D source to the IOS architecture then use it in an IOS app for the ui)? Dan would have to answer the question of how well his iOS support integrates with Obj-C and the iOS GUI. Mobile support is in alpha, meaning it's mostly been used to run a bunch of unit tests in the background. I hope to release a beta for Android in the next couple weeks, along with JNI integration and sample apps. Once that's done, you may consider using D for such an app, if you don't mind using a beta.
Re: Multiple selective imports on one line
On Monday, 28 December 2015 at 14:16:36 UTC, Basile B. wrote: On Monday, 28 December 2015 at 14:09:30 UTC, Joakim wrote: I wish dfmt could do this for us, so that you develop with all the modules imported at the top, then run dfmt and it scopes all the imports and adds the selective import of symbols. I've been thinking about implementing a tool to do this myself, will get around to it someday. This is not formating (what DFMT is aimed to do) this is refactoring. You're right, I was thinking about patching Dscanner to do it, just mentioned dfmt here without thinking about that aspect.
Re: Must I compile on the target architecture?
On Friday, 25 December 2015 at 12:43:05 UTC, Jakob Jenkov wrote: Hi, just a quick question: If I write a program in D and I use Windows for development but want it to run on Linux, do I have to copy the source code to the target Linux machine and compile it there, to make an executable for that machine? What is the standard process for cross platform compilation? I'll also note that ldc supports cross-compilation out of the box. The only issue is that you'll need a linker to link the resulting objects, but you can usually install one in Cygwin. I believe gdc also supports some cross-compilation, though I've not tried it. Dmd isn't a cross-compiler, though it is capable of being turned into one: nobody has put in the remaining work yet.
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote:
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt,
and Dscanner.
Upon saving files, it produces suggestions, much like warnings
from the compiler.
One suggestion is to use selective imports in local scopes. OK,
I'll do that.
Now I'm left with a smattering of lines which are just
selective imports from a single module:
void foo()
{
import std.exception:enforce;
import std.algorithm:array;
import std.algorithm.iteration:filter;
import std.functional:memoize;
//..Work..
}
What is the proper way to combine these into one line?
You really shouldn't have to do this by hand. I wish dfmt could
do this for us, so that you develop with all the modules imported
at the top, then run dfmt and it scopes all the imports and adds
the selective import of symbols. I've been thinking about
implementing a tool to do this myself, will get around to it
someday.
Re: Download DDMD?
On Wednesday, 22 April 2015 at 07:57:40 UTC, Jeremiah DeHaan wrote: Just curious, but I was wondering if there was a 2.067 DDMD available for download somewhere for Windows. If not, then are there any special build instructions I need to build it? I kind of just want to try a couple of things, so I would rather I not have to build it if I can avoid it. No, just build dmd from source as you normally would, but add the target ddmd instead. They are supposedly going to try to get the next 2.068 release to use ddmd, and want to get the next release out sooner, so you may not have to wait long for an official ddmd release.
Re: OT; Donald Knuth on beauty, efficiency, and the programmer as artist
On Sunday, 29 March 2015 at 18:41:36 UTC, Laeeth Isharc wrote: The whole art/science vein of these Knuth quotes seems like a lot of BS, trying to situate computer programming in the long-standing and overblown science/humanities "divide." I should like to see an argument rather than mere assertion. There is no point in diving into that worthless debate. Whatever arguments I wanted to make are below. Steve Jobs is not an authority on this subject, but I found his conception of placing Apple at the juncture of science and the humanities rather intriguing. Perhaps Jobs early study of fonts and typefaces eventually helped with the development of the striking visual design of the iPhone, iPad, OS X, iOS, and the various Apple products that are lusted after by conspicuous consumers everywhere today, but other than that, I always found that conception similarly fanciful. Other than visual design, where is the great influence of the humanities on Apple? Do they build great authoring tools, that the majority of writers use to write their books and ebooks? No. They acquired some nice editing tools like Final Cut Pro that had some uptake, but that's about it. He characterizes the artistic approach as "aesthetic, creative, humanitarian, anxious, irrational." He was making a statement about how it was characterized in his time, in order to set the context for his further remarks. He didn't express a view one way or another about whether this was a good characterization. I pointed out that he was wading into an existing debate that was overly simplistic and that he shouldn't simply have accepted their terms. Of course art is "humanitarian," as it's subjective and aimed at a human audience. Hard to argue the science that brought us modern civilization isn't a hundred times more humanitarian, far beyond the superficial sheen of "humanitarian" art he's talking about. "Anxious" and "irrational" are human emotions often possessed by artists, not qualities applied to art, fitting given they cannot produce anything of the great value of science. Interesting perspective; I will leave it at that. Feel free to disagree. :) I find terms like "humanitarian" or "spiritual" to be so vague and loaded as to be meaningless. He should have stuck to calling for more aesthetically pleasing programming languages and tools- the best contribution he could have made is to more precisely define what he thinks that aesthetic should look like- instead of needlessly laying out worthless and overly simplistic platonic definitions like the mindsets of Art and Science. At least his piece gave us that "premature optimization" line, which is worth far more than everything around it. That's rather the point - one cannot 'precisely define' what aesthetic excellence looks like because it uses at a basic cognitive level a different kind of mental process to that deployed in Cartesian analysis. I didn't ask for him to define "aesthetic excellence" but "what he thinks that aesthetic should look like." It might be difficult to analyze or communicate, but if one cannot even describe what the output might look like, it is basically worthless to even talk about, as we can only happen upon it by chance. ;) Analysis meaning breaking things down into their constituent parts, and thinking in terms of gestalts being the antithesis. (That's one of the fascinating things about programming: non-programmers perceive it as mostly about analysis, but that is not the case). It _is_ mostly about analysis, but that doesn't mean it's all it's about. Specifically, programming languages are a user interface, and so must be designed differently than some math library. http://www.ttbook.org/book/transcript/transcript-iain-mcgilchrist-uncut https://www.youtube.com/watch?v=MDO0yXgpD2w I'll take a look at the transcript, the video seems too long. There is a great desire by programmers and many other professions to see themselves as "artists." Well, there is art in everything, but they're not, and they should be grateful they aren't, or they wouldn't be paid anywhere near so well. ;) There is more art in C and D than Java and C++. I don't think that Knuth was playing a relative status game, but trying to bring peoples' attention to a facet of reality that he believed to be neglected yet important. I believe it remains neglected and that the aesthetic element matters for good design, but we blind ourselves to this if we pretend the field is drier than its intrinsic nature truly is. I think he was rightly pointing out the aesthetic element, but was likely playing a "relative status game" when he unnecessarily expanded it out to digressions on how programming is an art, not just a science. Sure, all engineering is an "art" to some extent, but in a much more limited way than what artists deal with and most technical types honestly probably don't care much about the pu
Re: OT; Donald Knuth on beauty, efficiency, and the programmer as artist
On Sunday, 29 March 2015 at 18:05:28 UTC, Laeeth Isharc wrote: I appreciate that many of us have better things to do. But I had been thinking about why I find D appealing, and how I would get this across to future partners, and had also been thinking about various forum comments equating measurement with science, and so I found this Knuth piece highly thought-provoking. Because it goes against the grain of the prevailing tendency, I shouldn't expect many to agree. But there is nothing wrong with appealing to minority opinion, provided one does not become a crank. In a sense that is in any case part of how I make a living. I completely agree with you about the aesthetic appeal of writing and reading D, it is one of the major draws of the language to me. I've recently been dealing with some C code and it feels like going back to punch cards by comparison. It is not a minor issue and Walter has often talked about optimizing for it. The white-space formatting requirements of Python were one of the main reasons I rejected it early on. Call it a superficial, knee-jerk reaction if you like, but I can't be bothered with a language that won't even let me insert temporary debugging code without formatting it just right.
Re: OT; Donald Knuth on beauty, efficiency, and the programmer as artist
On Friday, 27 March 2015 at 06:31:40 UTC, Laeeth Isharc wrote: In this talk I shall try to explain why I think "Art" is the appropriate word. I will discuss what it means for something to be an art, in contrast to being a science; I will try to examine whether arts are good things or bad things; and I will try to show that a proper viewpoint of the subject will help us all to improve the quality of what we are now doing. ... As I was looking up these things about the meanings of "art," I found that authors have been calling for a transition from art to science for at least two centuries. For example, the preface to a textbook on mineralogy, written in 1784, said the following [17]: "Previous to the year 1780, mineralogy, though tolerably understood by many as an Art, could scarce be deemed a Science." According to most dictionaries "science" means knowledge that has been logically arranged and systematized in the form of general "laws." The advantage of science is that it saves us from the need to think things through in each individual case; we can turn our thoughts to higher-level concepts. As John Ruskin wrote in 1853 [32]: "The work of science is to substitute facts for appearances, and demonstrations for impressions." It seems to me that if the authors I studied were writing today, they would agree with the following characterization: Science is knowledge which we understand so well that we can teach it to a computer; and if we don't fully understand something, it is an art to deal with it. Since the notion of an algorithm or a computer program provides us with an extremely useful test for the depth of our knowledge about any given subject, the process of going from an art to a science means that we learn how to automate something. ... From this standpoint it is certainly desirable to make computer programming a science, and we have indeed come a long way in the 15 years since the publication ot the remarks I quoted at the beginning of this talk. Fifteen years ago computer programming was so badly understood that hardly anyone even thought about proving programs correct; we just fiddled with a program until we "knew" it worked. At that time we didn't even know how to express the concept that a program was correct, in any rigorous way. It is only in recent years that we have been learning about the processes of abstraction by which programs are written and understood; and this new knowledge about programming is currently producing great payoffs in practice, even though few programs are actually proved correct with complete rigor, since we are beginning to understand the principles of program structure. ... A scientific approach is generally characterized by the words logical, systematic, impersonal, calm, rational, while an artistic approach is characterized by the words aesthetic, creative, humanitarian, anxious, irrational. It seems to me that both of these apparently contradictory approaches have great value with respect to computer programming. ... When I speak about computer programming as an art, I am thinking primarily of it as an art form, in an aesthetic sense. The chief goal of my work as educator and author is to help people learn how to write beautiful programs. It is for this reason I was especially pleased to learn recently [32] that my books actually appear in the Fine Arts Library at Cornell University. (However, the three volumes apparently sit there neatly on the shelf, without being used, so I'm afraid the librarians may have made a mistake by interpreting my title literally.) My feeling is that when we prepare a program, it can be like composing poetry or music; as Andrei Ershov has said [9], programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules. Furthermore when we read other people's programs, we can recognize some of them as genuine works of art. I can still remember the great thrill it was for me to read the listing of Stan Poley's SOAP II assembly program in 1958; you probably think I'm crazy, and styles have certainly changed greatly since then, but at the time it meant a great deal to me to see how elegant a system program could be, especially by comparison with the heavy-handed coding found in other listings I had been studying at the same time. The possibility of writing beautiful programs, even in assembly language, is what got me hooked on programming in the first place. Some programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones! .. Another important aspect of program quality is the efficiency with which the computer's resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste. Th
Re: Undefined symbol?
On Wednesday, 18 February 2015 at 08:55:51 UTC, Tofu Ninja wrote: When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be? See if you can reproduce with the latest 2.067 beta (http://forum.dlang.org/thread/54e41ca2.4060...@dawg.eu), and report back on the bugzilla issue that Kagamin just posted. Brian said he couldn't reproduce with the latest beta and the example there.
Re: Why can't functions and struct types have the same name?
On Monday, 26 January 2015 at 11:30:00 UTC, Daniel Kozak wrote: On Monday, 26 January 2015 at 11:15:26 UTC, Joakim wrote: Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported. Seems like a pain that can be mitigated by a smarter compiler. You can use static import, or alias to solve this issue Yep, both seem to be an easier way to fix the compile error. With the static import, it seemed painful to add the fully scoped path to every symbol from the third-party C library, but I forgot that you can simply use the fully scoped path when invoking the struct type alone, when it's not a static import, so that works. As for an alias, I didn't think of that, but that also requires the fully scoped path that I had forgotten about.
Why can't functions and struct types have the same name?
Right now, any attempt to have symbols with the same name errors out, regardless of how they're used. This caused a problem for me because I'm trying to use a third-party C library that defines a struct type called "socket" and my code calls that library and some networking modules from druntime. Since core.sys.posix.sys.socket happens to contain a function called socket also, dmd gets confused when I try to create a socket* and use it in my code. I would think it'd know I can't do that with a function name. Is such symbol disambiguation a convenience that just isn't implemented yet or something that can't/won't be done? Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported. Seems like a pain that can be mitigated by a smarter compiler.
Re: What to do with InvalidMemoryOperationError
On Wednesday, 21 January 2015 at 12:00:47 UTC, Nordlöw wrote: My executable throws as core.exception.InvalidMemoryOperationError@(0) when compiled with DMD git master. I get no stack trace in GDB. What to do? InvalidMemoryOperationError generally means that you are performing certain disallowed memory operations during a full garbage collection, such as allocating while the gc is running. This usually happens when you call a function that allocates in a destructor, which will trigger this error as the destructor is run by the gc. It appears that the gc issues mentioned above can also trigger it. If you're running off git head, maybe you can apply that PR 2794 and see if it helps. Otherwise, maybe you've hit some other gc issue somewhere.
Re: Any chance of a linux dtoh?
On Tuesday, 6 January 2015 at 16:02:24 UTC, Laeeth Isharc wrote: I downgraded dmd and now have a different problem with tango at link stage, which is progress of a sort. (I updated the ticket). Do you have to compile it yourself? Arch comes with dstep in their package repository, put there by Dicebot, I just used that. I don't know if any other distros have it packaged though.
Re: Compile for other OS's on Windows?
On Monday, 5 January 2015 at 15:00:05 UTC, Bauss wrote: On Monday, 5 January 2015 at 12:54:00 UTC, Gary Willoughby wrote: On Monday, 5 January 2015 at 11:49:32 UTC, Bauss wrote: Is it possible to compile for other OS's on Windows using dmd? This is what's known as cross compiling and is not currently supported by DMD at this time. Any alternatives? You might be able to lightly tweak ldc to do it: I was able to cross-compile druntime/phobos, their unit tests, and some small sample apps on a linux/x86 host to run on a linux/ARM target. The problem isn't really the D compiler so much as the other needed tools and environment. Dmd and the other D compilers are automatically configured to use your system linker and link against the system's C standard library. Well, optlink or the Microsoft linker on Windows don't know how to link for linux or OS X! So you have to set up linkers and C libraries for every other OS you want to build for on Windows. It's possible: the Android NDK can be installed on Windows with Cygwin and compile C/C++ code for the various Android architectures. But none of the D compilers have gone to all the trouble to provide that cross-compiling support out of the box for all the various OSs they support. It's easier to just run each OS in a VM on top of Windows, as Colin said.
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby
wrote:
I was just taking a look at the following poll[1] about the
order of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
{
auto foo = [0, 0];
int i = 0;
foo[i++] = i++; // Woah!
writefln("%s", foo);
}
Apparently the C++ equivalent is undefined behaviour but when
run using D the following result is output:
[1, 0]
1. Can someone please explain this output?
2. Is there anywhere this order of evaluation is documented?
3. Do you agree this is right?
[1]:
http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation/
It has been pointed before that this behavior even varies by D
compiler:
http://forum.dlang.org/post/swczuwclttmoakpve...@forum.dlang.org
One of those many small details that will have to be tightened up
in the spec someday.
Re: Why the DMD Backend?
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? It seems to me that GCC and LLVM are far more developed and better supported by their respective communities. They have superior optimizers and are better equipped for migrating D to new platforms. On the other hand, from what I gather, there's lots of work to be done on DMD on improving support for x64 Windows and ARM. The backend comes from the dmc and dmc++ compilers which Walter wrote, so he's always going to build against that, both because he knows it well and because he refuses to look at source for other compilers, for legal reasons. I don't know that there's much work left for Win64, certainly not on the backend. The dmc backend is for Intel only, ie i386 and x64. No support for ARM or any other arch and no plans to add them. It's a genuine question, which is why I posted this to D.learn. I don't follow development on the backend and overall I'm unfamiliar with compilers, so I'm not sure what the benefits are of the D community continuing to maintain it's own backend. What are the drawbacks? ldc and gdc have their own maintainers. I don't think it takes much work to maintain the dmc backend. On Friday, 28 November 2014 at 20:10:03 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 28 Nov 2014 19:59:39 + Xinok via Digitalmars-d-learn wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? build time for the whole DMD compiler with standard library, using G++: 100 seconds. yea, no kidding. gdc: i don't even want to think about that, way t long. ldc: not that long as gcc, but still much longer than DMD. I haven't timed it, but compiling ldc feels about 50-100% longer to me, which isn't too bad. Unless you're including the time to compile llvm, which is a different story. On Friday, 28 November 2014 at 20:14:07 UTC, LeakingAntonovPlane wrote: DDMD, bootstraping. LDC and GDC are not written in D. That's not the reason, both those projects plan on moving to the new D frontend also. dmd isn't written in D either: they just plan on translating the common dmd frontend from C++ to D, then using it across all three compilers. There is a D frontend written from scratch in D, SDC, which also uses llvm as the backend: https://github.com/deadalnix/SDC
Re: windows linker error
On Wednesday, 26 November 2014 at 04:10:08 UTC, Vlad Levenfeld
wrote:
I'm compiling the latest build from github.
(I normally stay up to date with the current builds on 64bit
Debian and everything works more or less without a hitch there,
but now I need to get some of my tools working in a Windows
environment)
I'm not really sure what my options are regarding the COFF or
what they mean, 64-bit is really the only requirement (mostly
because I can't get the 32-bit stuff to compile).
I've got Visual Studio Premium, I tried to install from the exe
at one point and got Visual D in the process (and this did
work, except that the code I need is built against the latest
dmd/druntime/phobos builds).
I see, so the problem appears to be that you're trying to compile
D from git to produce Win64 builds. COFF is the binary format
used by Microsoft for their MSVC runtime, and dmd only supports
Win64 with COFF, the Microsoft linker, and MSVC. If you're okay
with 32-bit dmd from git, which by default uses the Digital Mars
C runtime, the Digital Mars linker called optlink, and the OMF
binary format, these instructions should work for you, as they
did for me:
http://wiki.dlang.org/Building_DMD#Windows_2
Installing it from the instructions, IIRC, also worked for me,
but again, the version.
So I used the dmd visual studio project to build dmd, then
built druntime and phobos with Digital Mars make;
I had previously tried to use dmc to build dmd but couldn't get
it to work.
Anyway, I manage to build successfully but then I get this
linker error when I try to run dmd on some test.d consisting of
void main (){}.
I've gone into sc.ini and pulled out the ;VC2012 comments to
expose the LIB instruction (to fix a different problem) and
this is the point that I've gotten stuck at.
If you still want to get Win64 from git working, I advise you to
use a release build of dmd from the zip and set it up to get code
compiling for Win64, ie make sure you understand what environment
variables need to be set to use the MSVC runtime and linker.
Then, compile dmd from git using dmc and the instructions linked
above, before using the same Win64 environment variables to
compile your code.
If you still have problems, you may want to look at the scripts
and Win64-specific patches that Brad uses on the auto-tester to
continuously build dmd for Win64:
https://github.com/braddr/d-tester/tree/master/client/src
Re: windows linker error
On Tuesday, 25 November 2014 at 23:08:07 UTC, Vlad Levenfeld wrote: On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld wrote: On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next? Solved it by pointing to the dmc linker instead. Now I have LNK1104: cannot open file 'shell32.lib' I'm compiling with -m64... couldn't compile 32-bit phobos because of missing zlib. Just so we're clear, you're trying to compile for Win64 COFF? It sounds like you don't have something about your environment set up right, as Win64 requires the MSVC toolchain and some configuration if you use the dmd zip. Did you install from the exe installer or are you using the zip? The dmc linker is not going to work, as it only does OMF. You may find this page helpful, though it may be a bit outdated: http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
Re: Experience report on installing dmd 2.066.1 on OSX
On Wednesday, 12 November 2014 at 22:38:56 UTC, Ali Çehreli wrote: A friend of mine installed dmd on OSX and recorded his experiences: http://cap-lore.com/Languages/D/Install.html I wonder why he had to do manual work like running xattr. Is that expected on OSX? Looks like they're now requiring that apps be signed with the developer's account, which I'm guessing the dmd dmg isn't: http://stackoverflow.com/questions/24176378/why-my-dmg-is-not-getting-opened-without-asking-security-popup
Re: D support on SPARC/Solaris
On Friday, 31 October 2014 at 16:10:01 UTC, Wyatt wrote: On Thursday, 30 October 2014 at 15:39:55 UTC, Joakim wrote: You could look at the linux/powerpc work Kai did with ldc for an idea of the changes necessary for a new arch. Sounds fairly reasonable to me. Happen to have a link to a commit or branch with that or do I need to go digging? None that I know of, look at the commit log and grep the source for powerpc.
Re: D support on SPARC/Solaris
On Thursday, 30 October 2014 at 14:03:23 UTC, Wyatt wrote: At work, I have to target SPARC/Solaris. I'm writing code to interface with an internal network protocol, so my current choices are C and (old) C++ (remember Sun Studio? I wish I didn't have to). Having looked, it seems like there's some manner of support for SPARC in the runtime, but restricted to Linux and FreeBSD? Is that correct? Someone may have been thorough when adding arches to certain files, but that in no way implies much actual support. The gdc section of the download page claims sparc support, so you could look at what they've done. In which case, what would an enterprising individual have to actually do (read: fix or implement) to use D in that environment? (If it comes down to it, it may be worth my while to add it myself.) You may be able to combine the existing Solaris support and the sparc backend of llvm or gcc and get pretty far. A lot of the work should just be translating headers needed for the solaris/sparc sections in druntime. You could look at the linux/powerpc work Kai did with ldc for an idea of the changes necessary for a new arch. This echoes a thread Nordlöw started about six months ago, but my constraints aren't as rigid: DMD would be fine for me. I just pine for non-crap language. As kagamin said, dmd's backend is i386/x86_64 only, so you have to use ldc or gdc.
Re: Is Apple LLVM 6 compatible with LDC
On Thursday, 30 October 2014 at 08:54:03 UTC, Joakim wrote: As far as I know, ldc's support for iOS is still in the early stages but they should be binary compatible, particularly if you compile ldc against the same llvm backend, and a C wrapper is likely still necessary, as I don't think Dan Olson got it working without one: http://forum.dlang.org/post/m2txc2kqxv@comcast.net Sorry, rereading his post now, he did get it working without a C wrapper, _I_ needed a C wrapper for Android.
Re: Is Apple LLVM 6 compatible with LDC
On Wednesday, 29 October 2014 at 04:45:00 UTC, JJDuck wrote: I'm trying to compile my D code using LDC and hopefully used by my iOS program in Xcode. So I did some research (correct me if I'm wrong) If I compile my D code using LDC into static file and used by my iOS app and since they have the same compiler backend, are they binary compatible? If it is binary compatible, should I still build some C header file so it can be called by iOS? XCode's compiler seems to keep evolving into their next stage, so I'm not sure if I'm conceptually correct. THanks You should ask in the ldc forum, as you're more likely to get an answer there. As far as I know, ldc's support for iOS is still in the early stages but they should be binary compatible, particularly if you compile ldc against the same llvm backend, and a C wrapper is likely still necessary, as I don't think Dan Olson got it working without one: http://forum.dlang.org/post/m2txc2kqxv@comcast.net
Re: Beginner ?. Why does D suggest to learn java
On Monday, 20 October 2014 at 13:52:10 UTC, Kagamin wrote: On Friday, 17 October 2014 at 23:31:46 UTC, Joakim wrote: Tablets are optimized for basic usage, not saving files and document editing and whatever else you might want to do on a PC. Most people just need a basic appliance that isn't going to catch viruses or require registry hacks. LOL http://wmpoweruser.com/infected-android-phones-now-outnumber-infected-pcs-on-mobile-networks/ Are you laughing because of this? :) "Android devices accounted for 60% of total mobile network infections, and 40% of mobile malware originated from Windows laptops connected to a phone or connected directly through a mobile USB stick or W-Fi hub. Infections on Windows Phone, iPhone and BlackBerry devices made up less than 1% 'Android smartphones are the easiest malware target,' said Kevin McNamee, security architect and director of Alcatel-Lucent’s Kindsight Security Labs, but noted 'but Windows laptops are still the favourite of hard core professional cybercriminals.'” Note my original reference to not being able to save files and the very low rate of infection on the iPhone. Android is a little different because it's so open, just like Windows, and I bet most of those infected Android devices were rooted or old. If you do the math, there are a lot more Android devices than Windows laptops, so the fact that there are almost as many infected Windows laptops means the infection rate of Windows is much higher.
Re: [OT] the uses of computing
On Sunday, 19 October 2014 at 04:55:55 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 18 Oct 2014 23:38:35 + Joakim via Digitalmars-d-learn wrote: don't you think that we are going in circles now? not that i'm tired of this conversation, but i see that we get each other's POVs, and have no more arguments to convince each other. ;-) I guess, when does anyone ever convince anyone else online? People usually just throw their arguments at each other and leave holding the same opinion. ;) >> I don't read books anymore > even technical ones? ;-) I think the only technical book I've read in the last decade is Andrei's TDPL, which I bought in print and got about halfway through. I've probably read bits and pieces of maybe five other non-technical books here and there in the same timespan, which were all given to me as gifts. I've never read an ebook, yet I read extensively online. Books are an outdated form, now that we have blogs. i believe that blog posts and textbooks compliments each other. i prefer textbook for learning new language, for example, and read blogs to learn some interesting/funny/hidden features. That may be true now, but soon it will be just blogs. I don't know much about Oberon, but that gadgets UI sounds like it's still a GUI. sure, it's GUI, but with some "consolish" pieces dropped in. you can connect components and you can write some textual commands/scripts to modify component behavior. best from both worlds! ;-) The desktop UI paradigm needs to be completely redone, from the ground up. Current desktop GUIs are too limiting and the terminal is powerful but antiquated. The problem is how best to combine the two, since one is focused on keyboard input whether the other mostly uses trackpad/mouse. I suspect voice will have to be the new input to this new desktop GUI. I actually agree with you that some sort of component system like that is likely the future, even if it's only ultimately used to make developers' lives easier and largely unconfigured by users themselves it's simple enough for users to modify. changing layouts by dragging components, embedding components into components and so on. this things are mostly "visual" and easy. people love to customize their working environment if it's easy enough. ;-) I agree that customization should be made really easy, but what percentage of users ever configure their settings themselves now? I bet it's a negligible percentage. What I think is more likely is that they will pay someone to configure the component desktop you envision to suit them, but that person won't necessarily be a developer, more likely a power user. though I haven't looked much into the complex historical reasons why it hasn't happened yet. 'cause so-called "software industry" is not ready to die yet. ;-) with proper component system there will be no much sense in selling "applications". and selling components is much harder: how many people will buy "e-mail data source component"? it's not even visual! and selling "e-mail reader" is worthless, 'cause people will deconstruct it to basic parts and build their own "application", and will not buy "shiny new version with improved interface". they will not even buy the "full package" if they only need one part of it, like "faster e-mail data source component". so the only way to keep "software bussines" (as we know it) running is turning component system back to non-component one. take, for example, COM technology (which is badly done, but still usable component system). how much software uses COM to decouple application in reusable parts? even microsoft realised that this will be disaster and turned COM to "advancing scripting interface" instead of truly component system. I agree that the software business likely just didn't do it right, but I doubt that's all of it. Any component system isn't going to be as fast and efficient as a bespoke system. Maybe the hardware just wasn't fast enough for that lack of efficiency, but with how powerful hardware has gotten these days, maybe we're finally ready for it. > have you ever seen BlackBox Component Builder? it's written > in > Component Pascal, but the basic principles are > language-independent. > i'm dreaming about BCB with D as base language... No, never heard of it, sounds interesting. try it, it's fun and free! ;-) you'll see "component programming system" in action. it's not "component OS", but it's great programming environment nevertheless. D is almost capable of powering such system. if only i had more free time and motivation... creating something BCB-like can be that "killer app" D needs. I've loaded up a chapter from this pdf book about it: http://www.cslab.pepperdine.edu/warford/ComputingFundamentals/ I'll take a look.
Re: "Error: Undefined identifier" when moving import to another module
On Sunday, 19 October 2014 at 09:39:05 UTC, nrgyzer wrote:
Hi guys,
when I do the following:
module myMain;
import example;
import std.traits;
import my.static.library.binding;
static this()
{
foreach ( m; __traits(allMembers, example) )
{
static if ( isCallable!(mixing(m) )
{
// ... do something here
}
}
}
void main() { /* do something here */ }
And my example-module looks like:
module example;
void exmapleFunction()
{
// do something here
}
I can compile my application without any error, BUT when I move
the import of "my.static.library.binding" to the example-module:
module example;
import my.static.library.binding;
void exmapleFunction()
{
// do something here
}
... I'm getting many error messages like these:
myMain.d-mixin-11(11): Error: undefined identifier
_D12TypeInfo_xAa6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D49TypeInfo_xAS3std8typecons16__T5TupleTkTkTkZ5Tuple6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D75TypeInfo_xAS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D55TypeInfo_xAE3std5regex15__T6ParserTAyaZ6Parser8Operator6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D31TypeInfo_xAS3std5regex8Bytecode6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D110TypeInfo_xAS3std3uni152__T4TrieTS3std3uni20__T9BitPackedTbVmi1Z9BitPackedTwVmi1114112TS3std3uni23__T9sliceBitsVmi8Vmi21Z9sliceBitsTS3std3uni22__T9sliceBitsVmi0Vmi8Z9sliceBitsZ4Trie6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D45TypeInfo_xS3std5regex14__T7ShiftOrTaZ7ShiftOr6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D11TypeInfo_xw6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D11TypeInfo_xb6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D13TypeInfo_xAya6__initZ
myMain.d-mixin-11(11): Error: undefined identifier
_D41TypeInfo_xS3std5regex12__T5StackTkZ5Stack6__initZ
I'm having no idea what's going wrong here. I'm simply moving
the import from the file where my main() is located in to the
example-module. When removing the import of
"my.static.library.binding" in the example-module allows me to
successfully compile everything. But I need the import in the
example-module. Any suggestions what's going wrong here/how I
can solve the error?
An import is private by default:
http://dlang.org/module.html
When you move the import of my.static.library.binding to the
"example" module, its declarations are no longer available in the
"myMain" module. You'd have to make it a "public import
my.static.library.binding" to make it available to other modules.
Re: D developing on ARM board
On Sunday, 19 October 2014 at 14:35:06 UTC, Suliman wrote: I am planing to buy ARM-Board. I would use it for internet browsing and whant to know would it's possible to develop D apps on it? Which ARM board do you plan on getting? I own a Pandaboard ES. I tried using it for browsing for some time, but the software was pretty buggy when I tried it more than two years back. Maybe the ARM situation has gotten better since then. I had read that LDC have limited support of ARM. wiki said that it can compile hello-world apps. But it it not enough. What about DMD. Is there any progress of ARM support? dmd is x86 only, ldc and gdc have ARM backends. The ldc devs say there's still some stuff to fix to get all the tests passing on ARM, while the gdc devs say they have gdc passing most tests on ARM. Also: 1. Would Vibed work on ARM? Some people have tried it, this guy ran into a problem last year: http://forum.dlang.org/post/kksozynoounkasddb...@forum.dlang.org Not sure if that's fixed yet or if vibe works, you'd have to look into it. 2. Would Sublime work on ARM? Sublime seems to be x86-only, maybe you can ask them for an ARM build.
Re: [OT] the uses of computing
On Saturday, 18 October 2014 at 20:50:42 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 18 Oct 2014 19:42:50 + Joakim via Digitalmars-d-learn wrote: > most people are stupid. No disagreement there, but even the smart ones can only learn so much. that's why we should teach kids alot of things while their minds are "clear" and ready to absorb alot of knowledge. and, of course, we must teach them how to *use* that knowledge. So much of what's taught today is so worthless that I'm skeptical of anyone claiming kids should be taught "a lot," as if you know what that is. And given our long history of barely being able to teach any knowledge, with almost no success in getting people to "use" it for something original, that seems like a dead end too. Better to just let people take their own path and find what works best for them. Many people do not learn simple physics in school, and even if they did, wouldn't necessarily be able to figure out how to fix a specific mechanical system like a washing machine from the general physical principles. yes, figuring this out without manuals will be hard. but learning physics (proper learning of *anything* for that matter) will give 'em understanding of base principles (mechanics, electricity, etc) and the ability to extract information from books. it's enough for simple fixes that doesn't require to produce hi-tech parts. I disagree, as there is a large gap of knowledge between the base principles and the complex systems we build on top. How many people would be able to diagnose and force reallocation of bad sectors in their hard disk if hit with that problem, given the basics of how hard disks work? I actually ran into this recently and found little info about it, meaning not many people do it. Yeah, we agree if you truly mean making most of what they learn optional, not just "fun" but still required. Most of the stuff we force on kids today, like multiplication tables, how to divide numbers by hand, or memorizing historical dates, is utterly useless. ah, i hated that so-called "history lessons" where i was forced to remebmer that in year i don't care about somebody who i don't care about did something i equally don't care about. ;-) yes, i'm sure that we should teach kids how to do things, not just making 'em remember that 4*8 is 32. tell 'em what multiplication is and then play games with them, games which involves using of multiplication. this way kids will learn how to use multiplication. no need to remember any tables. or let 'em build a simple robot and program it to do some funny things. it's exciting and they will learn many things about mechanics, electricity, programming... let 'em play a role of factory manager, for example, and they will develop a good understanding of how economics works. and so on. We agree that practical application is a better way to motivate learning than absorbing theory from a book first, at least for most students. But some kids are just not going to enjoy those multiplication games or robot building and I'd say it's better for them to choose something else to pursue, rather than forcing them to pick up multiplication when it's a completely useless skill, now that everybody carries around a calculator with them in their phone these days. >> Yet, civilization is made up of people like you, who would >> all miss those mechanical systems far more than computers. > it's a huge difference between "i miss my washing machine" > and "all our > communication and data processing systems are foobared". Yet, I bet you they'll want that washing machine working far more than the internet. most people can't see a whole picture. it's bad. we must teach kids to understand how different things are interconnected too. At this point, _I_ can't see your "whole picture." :) I made a simple point, that building and fixing washing machines or software is something most people don't want to do. Saying they should learn those things anyway doesn't make sense. Isn't that what people use Excel macros for? aren't writing excel macros a programming? My understanding is that you can write simple mathematical formulas, which is as far as most probably go, even though it may also allow iteration and other programming constructs. My point, that I made below, is that people who need some of the power of programming without the training can use cruder tools like these most of the time. There are specialized tools for the job, that are more limited than full programming languages but easier to use for the average person. i never meant that all people should learn "full programming languages". they have to know how
[OT] the uses of computing
On Saturday, 18 October 2014 at 00:06:10 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 23:31:45 + Joakim via Digitalmars-d-learn wrote: You do realize that most people are clueless about how to fix those also, right? most people are stupid. No disagreement there, but even the smart ones can only learn so much. Would you require that how to fix all that mechanical stuff be taught in schools too? but it is! or at least it was. it's all simple physics, you know. not a rocket science. Many people do not learn simple physics in school, and even if they did, wouldn't necessarily be able to figure out how to fix a specific mechanical system like a washing machine from the general physical principles. Kids would never leave school if they had to learn all the stuff everybody says they should be forced to learn. ;) nobody should be *forced* to learn: it's pointless. yet kids are very curious, and they can be taught *alot* of things if they think that they are "just playing". make it interesting, and you'll be amazed how much kids can learn almost without problems. Yeah, we agree if you truly mean making most of what they learn optional, not just "fun" but still required. Most of the stuff we force on kids today, like multiplication tables, how to divide numbers by hand, or memorizing historical dates, is utterly useless. Yet, civilization is made up of people like you, who would all miss those mechanical systems far more than computers. it's a huge difference between "i miss my washing machine" and "all our communication and data processing systems are foobared". Yet, I bet you they'll want that washing machine working far more than the internet. They should use tools like Automator instead, no programming needed: http://en.wikipedia.org/wiki/Automator_(software) i wasn't talking about sorting out file mess. i was talking about tabular data processing, for example, with some logics and calculations that can't be done automatically without programming. Isn't that what people use Excel macros for? There are specialized tools for the job, that are more limited than full programming languages but easier to use for the average person. Tablets are optimized for basic usage what is "basic usage"? i really don't know what tablets are for. what i can do with it? watching movie? listening music? reading book? yes, tablets can do this... badly. what else? All of the above, anything you'd use a portable computer for that doesn't require much typing and would benefit from a larger screen than your smartphone. I wouldn't say they do it all badly: it's the most portable "TV" you could ever have, if you use it to watch video. And you're not limited to the junk on the idiot box, you can download any video from the web and watch on the go. Most websites benefit from a larger screen also. i can listen music with my N900, and it fits in my pocket. movies? on tablet screen? no, thanks. books? "electronic books" are better. I've watched parts of movies on my 4.7" smartphone screen, which happens to have the best display I've ever used. Tablets are even better for video. I don't read books anymore, but with their high-res displays up to 200-300 ppi these days, reading text is very nice on tablets too. tablets are like XML: bad for everything. Now that's just low, you can't compare anything to the utter junk that is XML. :) Most people just need a basic appliance that isn't going to catch viruses or require registry hacks. give 'em wooden board with painting. it's great! It's a little better than that. ;) It is completely different, because there are tools like Automator to help you automate your workflow without needing to write anything. oh, please. i can do batch renaming with wildcards, and for any task that is more complex than that there *is* a need to write logic. scripts. "graphic programming" is a dead end. people drop icons in favor of alphabet 'cause alphabet is just better. Actually, the progression went the other way, people dropped text UIs for graphical UIs. :) I'm not saying _you_ need to leave the terminal, but for most people GUI tools like Automator are enough. If you need to communicate something on paper- well, nobody uses paper these days i wish that the goverment of my country knows about that. and banking. somehow they still insist to have everything written on paper. Well, the government is the most backwards part of any country. For most people, that is a better route, particularly if they don't need to modify the script as they go and just need it written once. so instead of spending ten minutes to write the script they'll spend a day searching for som
Re: Beginner ?. Why does D suggest to learn java
On Friday, 17 October 2014 at 21:20:29 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 20:40:37 + Joakim via Digitalmars-d-learn wrote: This is nonsense and I see it repeated all the time, with code.org and other efforts. Do you know how to fix your car, washing machine, or refrigerator? i have no car, i know how to fix my wahing machine, i know how to fix my refrigerator. You do realize that most people are clueless about how to fix those also, right? Would you require that how to fix all that mechanical stuff be taught in schools too? Kids would never leave school if they had to learn all the stuff everybody says they should be forced to learn. ;) No, yet your life would likely collapse far faster without those. my life is not the whole human civilization. Yet, civilization is made up of people like you, who would all miss those mechanical systems far more than computers. You hire somebody to do the job if any of those mechanical systems breaks. Similarly, most people hire programmers to do the software work they don't want to do. ...and pretty sure that computers are magical devices. oh, how many times i've seen people doing tedious repetetive work for hours, that kind of work that can be done in seconds by the simple script. They should use tools like Automator instead, no programming needed: http://en.wikipedia.org/wiki/Automator_(software) actually, that's why people so love their pads: "no-brain-required". not only that, but "no easy way to made it do what i want" too. i still can't understant that kind of attitude. Tablets are optimized for basic usage, not saving files and document editing and whatever else you might want to do on a PC. Most people just need a basic appliance that isn't going to catch viruses or require registry hacks. I will agree that basic computer literacy is important, ie people should know their way around a computer or tablet, how to open and turn off apps, mouse or touch your way around the UI, etc. But beyond that it's a matter of interest: some people like Walter want to work on their car or computer, but most people don't. inability to write a simple script to automate some task is not different from inability to write some words on a piece of paper. It is completely different, because there are tools like Automator to help you automate your workflow without needing to write anything. If you need to communicate something on paper- well, nobody uses paper these days so let's say in text ;) - that's more basic and fundamental. yet i see how the argument "oh, well, i hire someone to write that for me" fits here. For most people, that is a better route, particularly if they don't need to modify the script as they go and just need it written once.
Re: Beginner ?. Why does D suggest to learn java
On Friday, 17 October 2014 at 13:59:03 UTC, ketmar via Digitalmars-d-learn wrote: that's why i'm sure that basic programming must be teached in school. hey, the whole our civilization will collapse without computers! computer programming is the literacy of the new age. This is nonsense and I see it repeated all the time, with code.org and other efforts. Do you know how to fix your car, washing machine, or refrigerator? No, yet your life would likely collapse far faster without those. You hire somebody to do the job if any of those mechanical systems breaks. Similarly, most people hire programmers to do the software work they don't want to do. I will agree that basic computer literacy is important, ie people should know their way around a computer or tablet, how to open and turn off apps, mouse or touch your way around the UI, etc. But beyond that it's a matter of interest: some people like Walter want to work on their car or computer, but most people don't. On Friday, 17 October 2014 at 14:00:43 UTC, ketmar via Digitalmars-d-learn wrote: yet Scheme will teach how to write functional code. it's a valuable knowledge for D programmer. My first programming language was Scheme in my freshman year of college (I wasn't one of those kids programming since middle school). Scheme was fine for the time, though the scads of parentheses were annoying, but I think we can do better decades later. D would work fine if it's presented at a level appropriate to a beginner, ie not assuming they know anything about programming to begin with.
Re: Building a dmd that works on old systems: TLS problems with libc
On Friday, 3 October 2014 at 14:21:02 UTC, Atila Neves wrote: Then I tried only using dmd to compile and linking it myself. That worked, but the resulting binary crashed. After loading it up in gdb, it crashed in __tls_get_addr My guess would be that your system doesn't have __tls_get_addr, which is unique in that it is provided by the runtime linker from glibc. You may want to try out my Android patch for dmd, which doesn't use native TLS and doesn't rely on that function either: http://164.138.25.188/dmd/packed_tls_for_elf.patch You'll want to get rid of that last change to mars.c, substitute rt/sections_android.d for rt/sections_linux.d in druntime (don't forget to change the "version (Android):" inside that file to "version (linux):" also), and make sure you're using the default ld.bfd linker and not the gold linker. That might work for you. On Thursday, 9 October 2014 at 17:30:04 UTC, Kevin Lamonte wrote: I am experiencing a similar problem trying to build a static executable, exactly as described in https://issues.dlang.org/show_bug.cgi?id=12268 . I don't know if the root cause is a gcc issue or a phobos issue. Probably neither, probably a druntime issue, specifically the rt.sections_linux module's use of the __tls_get_addr function, which is called from the dynamic linker at runtime.
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 04:37:20 UTC, Puming wrote: On Saturday, 9 August 2014 at 21:46:45 UTC, Peter Alexander wrote: On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote: Yes, rust is a more infantile language compared to D, but people are already using them to create complicate applications like browser! Rust was designed to build Servo. The people building Servo are the people building Rust. With all due respect to Rust, I don't think that counts as endorsement of the language. I didn't know about that. I don't actually know much about Rust except the hype on hackernews :-) But nonetheless, this indicates that a serious application like a browser is a good driving force for a language to evolve. I'm planning on tinkering with D over the next couple months on an idea to replace the web browser, which I laid out on this forum last year: http://forum.dlang.org/thread/tlpikltmamsfmqunn...@forum.dlang.org?page=3#post-dqddjhccpmxhgcssqtol:40forum.dlang.org The browser has gotten way too complex, it's time to design away much of that complexity. On the one hand, this might show D is a good language to try new ideas, instead of simply implementing old, obsolete ones. On the other hand, since it's much simpler, it's not really going to push the language like an overly complex browser might. ;)
Re: Tracing down core.exception.InvalidMemoryOperationError
On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via Digitalmars-d-learn wrote: On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote: More broadly speaking, it is thrown whenever certain memory operations are attempted while the GC is running, 6 in all, as you can see here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 I believe I stuck in printfs till I found out which one was run before the error was thrown, and then traced that back with more printfs to where it was getting called. I didn't have a debugger available, you may be able to trace faster with one. Hi, thanks for the tip. I have a debugger at hand and I am would prefer to use it. However, I don't really know where and how to start. I would like to break at core/exception.d when onInvalidMemoryOperationError is called, but I am not sure how to build druntime with debug information. There does not seem to be some flag in the makefile like for dmd. Is there some document describing how to do this? It's not in the makefile; I simply added the -g or -gc flag where it compiled and then the debug symbols showed up in the debugger. You may also want to experiment with the -debug flag, which will turn on various kinds of log output depending on which module and flag you use it with.
Re: Tracing down core.exception.InvalidMemoryOperationError
On Monday, 28 July 2014 at 09:38:35 UTC, Martin Drasar via Digitalmars-d-learn wrote: Hi, at the end of my program it throws InvalidMemoryOperationError. Looking at the documentation and past forum questions I learned that it is probably because of allocations in destructors. However, I have no such thing in my code (at least not intentionally). I am suspecting the std.logger package, because it throwed on me a memory error on occasions. But regardless of the source, I would like to trace it and deal with it. But I do not have much of an idea where to start. Could you give me an advice? More broadly speaking, it is thrown whenever certain memory operations are attempted while the GC is running, 6 in all, as you can see here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 I believe I stuck in printfs till I found out which one was run before the error was thrown, and then traced that back with more printfs to where it was getting called. I didn't have a debugger available, you may be able to trace faster with one.
Re: Equivalent of DllMain on OSX?
On Friday, 25 July 2014 at 21:23:00 UTC, Mark Isaacson wrote: I am presently trying to port a driver I wrote for Windows to OSX. The one thing standing in my way is figuring out how to get the equivalent of DllMain on OSX. I need a place to call Runtime.initialize() and whatnot. Reading the wiki, it seemed like `shared static this()` was the appropriate construct to use, and indeed, when I run the test program from: http://dlang.org/dll-linux.html#dso9 I get the desired results: namely, I see that the `shared static this()` in that test program is called the desired point. When I try the same thing in my driver, it is never executed. Are dylibs on OSX not supported still (I saw some very old threads from 2012 stating as much)? Does it matter that I have multiple modules in the driver? Any help would be appreciated. I shall endeavor to get the modified driver code into a state where I can link it as well. Loading multiple D shared libraries isn't supported on OS X yet, see these warnings in druntime: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L198 If you only have a single D shared library, I think it's possible, you just may have to tweak dmd/druntime or your build process a bit. I think Martin Nowak or Jacob Carlborg can really answer your questions, as Martin wrote a lot of that code and Jacob seems to follow it closely, whereas I don't use OS X but looked at that code when porting to Android.
Re: core.exception.InvalidMemoryOperationError
On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio wrote: A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before? If you look at the source for the garbage collector, the only place that error is called is if the gc is trying to malloc or execute other memory operations while the collector is running. I ran across this myself because an assert was getting triggered in a destructor. Since an assert tries to malloc and the destructor is called by the GC, I got an InvalidMemoryOperationError which swallowed up the message from the original assert. By putting printfs in the code path in druntime, I was able to track it down to that destructor, otherwise I had no idea where the invalid memory error was getting triggered. You can probably do the same, but you can be sure it's a GC issue, and I would guess tied to allocating in a destructor (unless you happen to be calling InvalidMemoryOperationErrors somewhere in your own code or some library that you're using, which is unlikely).
Re: File needs to be closed on Windows but not on Posix, bug?
On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote: On Mon, 07 Jul 2014 12:17:34 +0100, Joakim wrote: On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote: See if stdio allows you to specify delete sharing when opening the file. I don't know what delete sharing is exactly, but the File constructor simply calls fopen and I don't see any option for the Windows fopen that seems to do it: http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx The fopen variant that allows you to specify sharing is: http://msdn.microsoft.com/en-us/library/8f30b0db.aspx But it does not mention delete sharing there. CreateFile allows sharing to be specified for delete however: http://msdn.microsoft.com/en-gb/library/windows/desktop/aa363858(v=vs.85).aspx So... you could: - Call CreateFile giving you a "handle" - Call _open_osfhandle to get a "file descriptor" - Call _fdopen on the file descriptor to get a FILE* for it But! I agree with Adam, leave it as a thin wrapper. Being a windows programmer by trade I would expect the remove to fail, I would not expect all my files to be opened with delete sharing enabled by default. Thanks for all the info. I'm looking at it from the point of view of a beginner or someone who just writes a quick D script that does something like this. They may find it confusing that it works on linux but doesn't work on Windows, especially given the confusing error message. But it is good practice to close a file before deleting and if D prefers to have thin wrappers around OS APIs, that implies less hand-holding like this, so maybe we just tell such people to close the file first.
Re: File needs to be closed on Windows but not on Posix, bug?
On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote: See if stdio allows you to specify delete sharing when opening the file. I don't know what delete sharing is exactly, but the File constructor simply calls fopen and I don't see any option for the Windows fopen that seems to do it: http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx
Re: implib and system dlls, oh my
On Tuesday, 24 June 2014 at 12:56:28 UTC, Jason King wrote: I don't know enough about implib to explain it. But another method that I believe should work is to use linker definition files. It'll allow optlink to work. Just add it to dmd, actually I believe it needs to be passed to Optlink (so -L it). Another fix, might be to use 64bit, but shouldn't be required. [0] http://www.dsource.org/projects/bindings/wiki/DefFiles/OleAut32 Rikki, Thank you for your kind attention. I spewed to the newsgroup and googled for an answer in the wrong order. It appears the solution to this problem is the combination of coffimplib + windows SDK. After using those on the SDK's oleaut32.lib I got a library with the properly decorated _VarCmp@16. Not your job, but this could probably be made simpler. You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 16:35:31 UTC, Andre Tampubolon wrote:
I've been reading the newsgroup for a while, and it seems that
one of the reason folks like D is because it supports module.
My question is: what does module mean?
A quick google pointed my this page:
http://dlang.org/module.html.
Still cannot understand it, though :)
How does it differ from the old C's #include?
For example, consider the hello world in C.
#include
int main(void){
printf("%s\n", "Hello world...");
return 0;
}
The C preprocessor while replace the line "#include "
with the content of stdio.h itself.
While in D:
import std.stdio;
void main(){
writeln("Hello world...");
}
Does that mean the compiler take the "definition" of writeln
itself from stdio.d and paste it into my program? Pardon my
ignorance, because I'm not versed in compiler theory.
You might find the clang docs on C++ modules worthwhile, though
they do it somewhat differently from D:
http://clang.llvm.org/docs/Modules.html
An #include simply copies and pastes the entire contents of the
C/C++ header into your source, which can happen over and over
again in a large project with no include guards, while modules
are a more sophisticated way of separating code.
File needs to be closed on Windows but not on Posix, bug?
I ran into this when trying to fix the Phobos unit tests and have
reduced it down to this test file:
import std.stdio, std.file;
void main() {
auto f = File("test.txt", "w");
//f.close();
std.file.remove("test.txt");
}
This compiles and runs fine on linux and the autotester shows
that it works on all the tested Posix platforms, but it fails on
Windows with
std.file.FileException@std\file.d(433): test.txt: The process
cannot access the file because it is being used by another
process.
Uncommenting the f.close() gets it to work fine on all supported
platforms, no doubt it has to do with the different OS APIs that
are being called.
This seems like inconsistent behavior: should I file a bug?
TKD set focus on window?
Hi, Quick question regarding TKD (tkinter): Is there a way to set focus on the application window automatically on run? I'm on Mac OS X if that's of any importance. I have tried to grep the documentation but I can't find anything relevant. Thanks!
Re: ncurses linking(?) problem on Mac OS X
It worked perfecly. I knew I had missed something stupid. :) What confused me was the homebrew warning. Thank you for helping a newbie out. :)
Re: ncurses linking(?) problem on Mac OS X
Have you actually installed ncurses on your system? https://gist.github.com/cnruby/960344 I will try this, but I did a search/info with homebrew and it said it was not recommended because OS X already has ncurses installed by default. Something about conflicts that could possibly occur. I found libncurses.dylib and such already installed in /usr/lib.
ncurses linking(?) problem on Mac OS X
Hi,
I am very new to D, I just started with it a week ago or so, and
I haven't really been using compiled languages before (except for
Java), so I'm pretty confused with the whole thing in general. ;)
I try to use the ncurses library in my project using:
"dependencies" : {
"ncurses" : "~master"
},
"lflags" : ["-v"]
But when I try to compile it, I get the following:
@(#)PROGRAM:ld PROJECT:ld64-236.4
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64
armv6m armv7m armv7em
Library search paths:
/usr/share/dmd/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: library not found for -lncursesw
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
--- errorlevel 1
FAIL
.dub/build/application-debug-posix.osx-x86_64-dmd-4349FBA7803F9504BC9BF29263B86A68
text edit executable
Error executing command build: Link command failed with exit code
1
Terminated, exit code: 2
I have no idea where to go from here to be honest. It's probably
something easily fixed for someone even a tiny bit more
experienced.
I would love some help if anyone feels up to it.
