Re: Why is 64-bit dmd not built as part of the Windows release?
On 5/23/2018 3:20 PM, Vladimir Panteleev wrote: On Wednesday, 23 May 2018 at 20:17:04 UTC, Dlang User wrote: I tried adding bootstrap option for 64 bit: digger -c build.components.dmd.dmdModel=64 -c build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0 Which didn't work (totally different error): Looks like more DMD bugs. Try more host versions, e.g. v2.079.0 or v2.080.0. Thank you. I had success with using v2.080.0 as the bootstrap: digger -c build.components.dmd.dmdModel=64 -c build.components.dmd.bootstrap.ver=v2.080.0 build --model=64 v2.080.0
Re: Why is 64-bit dmd not built as part of the Windows release?
On 5/23/2018 12:42 PM, Vladimir Panteleev wrote: On Wednesday, 23 May 2018 at 17:35:28 UTC, Dlang User wrote: I too am looking for 64-bit on Windows 10. Not just DMD but ideally everything. When I try the command exactly as above, or a slightly modified version (on a second run show after this run), I hit an error on my machine: Internal error: dmd\backend\cod3.c 6830 Hmm, that looks like a DMD bug/regression. I think that should have been caught by the auto-tester. In any case, try adding --model=64 to your command to also build a 64-bit Phobos, as that seems to be what you're after anyway. You could also try specifying a different (newer?) host DMD version with e.g. `-c build.components.dmd.bootstrap.ver=v2.075.0`. Thanks for looking at this, I actually did try adding --model=64, in the second run that I was referring to in my original post, but that resulted in the same error. Some additional things I realized when trying to use digger on my machine: Digger is only failing when trying to use the build.components.dmd.dmdModel=64 switch, so when trying to build 64 bit DMD. digger -c build.components.dmd.dmdModel=64 build --model=64 v2.080.0 The first time the error is this (so this is probably the real error): FLunde Internal error: dmd\backend\cod3.c 5488 The second time, the error is (this is probably due to the previous failed run): Internal error: dmd\backend\cod3.c 6830 I tried adding bootstrap option for 32 bit, and that worked fine: digger -c build.components.dmd.dmdModel=32 -c build.components.dmd.bootstrap.ver=v2.075.0 build --model=32 v2.080.0 I tried adding bootstrap option for 64 bit: digger -c build.components.dmd.dmdModel=64 -c build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0 Which didn't work (totally different error): C:\DProj\digger\work\dl\dmd-2.075.0\dmd2/windows/bin\dmd.exe -of..\generated\windows\release\64\dmd.exe -vtls -J..\generated\windows\release\64 -J../res -L/STACK:8388608 -O -release -inline -m64 -wi -version=MARS -L/delexe/la dmd/access.d dmd/aggregate.d dmd/aliasthis.d dmd/apply.d dmd/argtypes.d dmd/arrayop.d dmd/arraytypes.d dmd/astcodegen.d dmd/attrib.d dmd/builtin.d dmd/canthrow.d dmd/cli.d dmd/clone.d dmd/compiler.d dmd/complex.d dmd/cond.d dmd/constfold.d dmd/cppmangle.d dmd/cppmanglewin.d dmd/ctfeexpr.d dmd/ctorflow.d dmd/dcast.d dmd/dclass.d dmd/declaration.d dmd/delegatize.d dmd/denum.d dmd/dimport.d dmd/dinifile.d dmd/dinterpret.ddmd/dmacro.d dmd/dmangle.d dmd/dmodule.d dmd/doc.d dmd/dscope.d dmd/dstruct.d dmd/dsymbol.d dmd/dsymbolsem.d dmd/lambdacomp.d dmd/dtemplate.d dmd/dversion.d dmd/escape.ddmd/expression.d dmd/expressionsem.d dmd/func.d dmd/hdrgen.d dmd/id.d dmd/imphint.d dmd/impcnvtab.d dmd/init.d dmd/initsem.d dmd/inline.d dmd/inlinecost.d dmd/intrange.d dmd/json.d dmd/lib.d dmd/link.d dmd/mars.d dmd/mtype.d dmd/nogc.d dmd/nspace.d dmd/objc.d dmd/opover.d dmd/optimize.d dmd/parse.ddmd/sapply.d dmd/sideeffect.d dmd/statement.d dmd/staticassert.d dmd/target.d dmd/safe.d dmd/blockexit.d dmd/permissivevisitor.d dmd/transitivevisitor.d dmd/parsetimevisitor.d dmd/printast.d dmd/typesem.d dmd/traits.d dmd/utils.d dmd/visitor.d dmd/libomf.d dmd/scanomf.d dmd/templateparamsem.d dmd/typinf.d dmd/libmscoff.d dmd/scanmscoff.d dmd/statement_rewrite_walker.d dmd/statementsem.d dmd/staticcond.d dmd/semantic2.d dmd/semantic3.d dmd/irstate.d dmd/toctype.d dmd/glue.d dmd/gluelayer.d dmd/todt.d dmd/tocsym.d dmd/toir.d dmd/dmsc.d dmd/tocvdebug.d dmd/s2ir.d dmd/toobj.d dmd/e2ir.d dmd/objc_glue.d dmd/eh.d dmd/iasm.d dmd\backend/bcomplex.d dmd\backend/cc.d dmd\backend/cdef.d dmd\backend/cgcv.d dmd\backend/code.d dmd\backend/cv4.d dmd\backend/dt.d dmd\backend/el.d dmd\backend/global.d dmd\backend/obj.d dmd\backend/oper.d dmd\backend/outbuf.d dmd\backend/rtlsym.d dmd\backend/code_x86.d dmd\backend/iasm.d dmd\backend/ty.d dmd\backend/type.d dmd\backend/exh.d dmd\backend/mach.d dmd\backend/md5.d dmd\backend/mscoff.d dmd\backend/dwarf.d dmd\backend/dwarf2.d dmd\backend/xmm.d dmd\tk/dlist.d dmd\root/aav.d dmd\root/array.d dmd\root/ctfloat.d dmd\root/file.d dmd\root/filename.d dmd\root/man.d dmd\root/outbuffer.d dmd\root/port.d dmd\root/response.d dmd\root/rmem.d dmd\root/rootobject.d dmd\root/speller.d dmd\root/stringtable.d dmd\root/hash.d ..\generated\windows\release\64\newdelete.obj ..\generated\windows\release\64\backend.lib ..\generated\windows\release\64\lexer.lib object.Error@(0): Access Violation 0x004CF5B7 0x004987C7 0x77B716B7 in RtlAllocateHeap 0x00441CCD 0x0064DE30 0x0044E40A 0x00405B42 --- errorlevel 1 --- errorlevel 1 --- errorlevel 1 digger: Saving to cache. digger: Clearing temporary cache object.Exception@C:\Users\dlang.user\AppData\Local\dub\packages\ae-0.0.2177\ae\sys\d\manager.d(850): Command ["make", "-f", "win64.mak", "MODEL=64", "HOST_DC=C:\\DProj\\digger\\work\\dl\\dmd-2
Re: Why is 64-bit dmd not built as part of the Windows release?
On 5/22/2018 10:03 AM, Atila Neves wrote: On Tuesday, 22 May 2018 at 13:30:02 UTC, Vladimir Panteleev wrote: On Tuesday, 22 May 2018 at 13:11:00 UTC, Atila Neves wrote: On Thursday, 17 May 2018 at 03:28:33 UTC, Vladimir Panteleev wrote: digger build --model=64 If you don't have Digger yet, you can run it straight from Dub: dub fetch digger dub run digger -- build --model=64 I keep forgetting about digger for some reason. Unfortunately the command above produced a 32-bit dmd. 64-bit druntime and phobos, but 32-bit dmd. Atila Apologies, that indeed is the wrong command. This should work: dub run digger -- -c build.components.dmd.dmdModel=64 build Thanks! That was pretty confusing though - and I consulted the documentation before trying --model=64 myself. In any case, I seem to have gotten a working 64-bit version of dmd. I too am looking for 64-bit on Windows 10. Not just DMD but ideally everything. When I try the command exactly as above, or a slightly modified version (on a second run show after this run), I hit an error on my machine: Internal error: dmd\backend\cod3.c 6830 Does anyone have any suggestions? It could be something simple, as I am relitivly new to D. I have windows 10 64 bit and I have v2.080.0 of D installed and I have VS2017 installed and I am able to complile D code to create a 64bit apps. I have tried compiling digger as both 32bit and 64bit, and that made no difference. If I run digger to build 32 bit DMD, then it succeeds with or without the --model=64 switch: digger build v2.080.0 digger build v2.080.0 --model=64 In the case of the original command I see this: digger -c build.components.dmd.dmdModel=64 build C:\DProj\digger\work\build\bin\dmd.exe -lib -oflib\druntime.lib -Xfdruntime.json -m32 -conf= -O -release -dip1000 -inline -w -Isrc -Iimport src\object.d src\core\atomic.d src\core\attribute.d src\core\bitop.d src\core\checkedint.d src\core\cpuid.d src\core\demangle.d src\core\exception.d src\core\math.d src\core\memory.d src\core\runtime.d src\core\simd.d src\core\thread.d src\core\time.d src\core\vararg.d src\core\internal\abort.d src\core\internal\arrayop.d src\core\internal\convert.d src\core\internal\hash.d src\core\internal\parseoptions.d src\core\internal\spinlock.d src\core\internal\string.d src\core\internal\traits.d src\core\stdc\assert_.d src\core\stdc\complex.d src\core\stdc\config.d src\core\stdc\ctype.d src\core\stdc\errno.d src\core\stdc\fenv.d src\core\stdc\float_.d src\core\stdc\inttypes.d src\core\stdc\limits.d src\core\stdc\locale.d src\core\stdc\math.d src\core\stdc\signal.d src\core\stdc\stdarg.d src\core\stdc\stddef.d src\core\stdc\stdint.d src\core\stdc\stdio.d src\core\stdc\stdlib.d src\core\stdc\string.d src\core\stdc\time.d src\core\stdc\wchar_.d src\core\sync\barrier.d src\core\sync\condition.d src\core\sync\config.d src\core\sync\exception.d src\core\sync\mutex.d src\core\sync\rwmutex.d src\core\sync\semaphore.d src\core\sys\darwin\netinet\in_.d src\core\sys\freebsd\dlfcn.d src\core\sys\freebsd\execinfo.d src\core\sys\freebsd\netinet\in_.d src\core\sys\freebsd\sys\_bitset.d src\core\sys\freebsd\sys\_cpuset.d src\core\sys\freebsd\sys\cdefs.d src\core\sys\freebsd\sys\elf_common.d src\core\sys\freebsd\sys\elf.d src\core\sys\freebsd\sys\elf32.d src\core\sys\freebsd\sys\elf64.d src\core\sys\freebsd\sys\event.d src\core\sys\freebsd\sys\link_elf.d src\core\sys\freebsd\sys\mman.d src\core\sys\freebsd\time.d src\core\sys\dragonflybsd\dlfcn.d src\core\sys\dragonflybsd\execinfo.d src\core\sys\dragonflybsd\netinet\in_.d src\core\sys\dragonflybsd\sys\_bitset.d src\core\sys\dragonflybsd\sys\_cpuset.d src\core\sys\dragonflybsd\sys\cdefs.d src\core\sys\dragonflybsd\sys\elf_common.d src\core\sys\dragonflybsd\sys\elf.d src\core\sys\dragonflybsd\sys\elf32.d src\core\sys\dragonflybsd\sys\elf64.d src\core\sys\dragonflybsd\sys\event.d src\core\sys\dragonflybsd\sys\link_elf.d src\core\sys\dragonflybsd\sys\mman.d src\core\sys\dragonflybsd\time.d src\core\sys\linux\netinet\in_.d src\core\sys\linux\netinet\tcp.d src\core\sys\linux\stdio.d src\core\sys\linux\tipc.d src\core\sys\linux\sys\inotify.d src\core\sys\linux\sys\mman.d src\core\sys\linux\sys\signalfd.d src\core\sys\linux\sys\socket.d src\core\sys\linux\sys\sysinfo.d src\core\sys\linux\sys\time.d src\core\sys\linux\sys\xattr.d src\core\sys\posix\dirent.d src\core\sys\posix\signal.d src\core\sys\posix\netdb.d src\core\sys\posix\netinet\in_.d src\core\sys\posix\arpa\inet.d src\core\sys\posix\sys\ioctl.d src\core\sys\posix\sys\ipc.d src\core\sys\posix\sys\mman.d src\core\sys\posix\sys\resource.d src\core\sys\posix\sys\select.d src\core\sys\posix\sys\shm.d src\core\sys\posix\sys\socket.d src\core\sys\posix\sys\stat.d src\core\sys\posix\sys\statvfs.d src\core\sys\posix\sys\time.d src\core\sys\posix\sys\types.d src\core\sys\posix\sys\uio.d src\core\sys\posix\sys\un
Re: Sealed classes - would you want them in D?
On 05/15/2018 04:05 PM, Jonathan M Davis wrote: On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote: On 5/15/2018 10:17 AM, aliak wrote: On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote: The way you use the word "leak" make is sounds that this is unintentional, while in reality it is intentional by design. That why reading the specification is important! Alexander Ya I guess you be right - but a leak is what it is to people who expect private to mean private. Which is not a small number of people ;) And while I agree reading a spec is important. Language specs are not known for being trivial to go through and it's not really something you read but more of something you refer to, and that also probably for more advanced developers. This is not something you can expect newcomers or even intermediate level devs to go through. And the less you need to refer to a spec the better (i.e. more intuitive) a language is. I concur with that. When I first started learning D (coming from a C# background), I figured that I already knew all of the OOP stuff and didn't dig too deeply into it, figuring that it worked pretty close to the same as C#. It did catch me off guard when I first realized how it really worked in D. But the work around (putting it in its own module), seemed pretty trivial and is what I typically do in C# anyways, so it didn't bother me too much. I think that if there's an actual problem here, it's the fact that how private works in D is surprising to folks coming from languages like C++, C#, or Java. IMHO, D's approach works extremely well, but if you don't understand what it is, you risk problems, just like with any other feature that you don't understand properly. And to better deal with that, we probably need more in the way of documentation geared towards teaching newbies. The "spec" is pretty poor in that it's not precise enough to be a spec, meaning that it doesn't really do its job in that respect, but it's also not really written with the idea that it's teaching someone, so it doesn't do a great job teaching the language either. There's a lot of great information there, but it's ultimately not all that accessible for many folks. Though if someone expects to be able to just jump into any language and use it without reading up on how it works, they're just shooting themselves in the foot. And surprisingly often, that seems to be how many folks operate. Ultimately, if newcomers don't want to be tripped up on stuff like this, their best bet is probably to read books like Andrei's "The D Programming Language" and Ali's "Programming in D." https://wiki.dlang.org/Books - Jonathan M Davis To clarify myself a little bit, the main points that I was agreeing with were: 1. I think there are significant number of people coming from other languages that are going to get tripped up by D's module level encapsulation, mainly because it happened to me. 2. The spec is hard to use as a training resource, because I tried to use it and didn't have a good experience with it. I ended up reading all of the free material that I could find (including the Programming in D book). I also wasn't trying say anything about D's encapsulation being right or wrong, just that it tripped me up initially, and that now that I know how it works, it isn't a big deal for me.
Re: Sealed classes - would you want them in D?
On 5/15/2018 10:17 AM, aliak wrote: On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote: The way you use the word "leak" make is sounds that this is unintentional, while in reality it is intentional by design. That why reading the specification is important! Alexander Ya I guess you be right - but a leak is what it is to people who expect private to mean private. Which is not a small number of people ;) And while I agree reading a spec is important. Language specs are not known for being trivial to go through and it's not really something you read but more of something you refer to, and that also probably for more advanced developers. This is not something you can expect newcomers or even intermediate level devs to go through. And the less you need to refer to a spec the better (i.e. more intuitive) a language is. I concur with that. When I first started learning D (coming from a C# background), I figured that I already knew all of the OOP stuff and didn't dig too deeply into it, figuring that it worked pretty close to the same as C#. It did catch me off guard when I first realized how it really worked in D. But the work around (putting it in its own module), seemed pretty trivial and is what I typically do in C# anyways, so it didn't bother me too much.
Re: dub search
On 5/8/2018 10:50 AM, Nicholas Wilson wrote: I was searching for zmq-d on code.dlang.org to find the git page for it ( to differentiate it from the other ama wrappers) and was greeted with 500 - Internal Server Error Internal Server Error Internal error information: vibe.db.mongo.connection.MongoDriverException@../vibe.d/mongodb/vibe/db/mongo/cursor.d(304): Query failed. Does the database exist? ??:? [0xa7bbee] ??:? [0xa825de] exception.d:421 [0x50aa93] exception.d:388 [0x50116d] cursor.d:304 [0x517adc] dbcontroller.d:393 [0x518643] ... OK, i thought, I'll try searching for "z" Found 30 packages. ^f z one match: Search results for: z That does not bode well for people searching for code on dub. Nic I am seeing the same thing, apparently it crashes for anything that contains a "-d" in the search. "-dd" doesn't crash.
Re: Building is slow!
On 4/16/2018 3:27 PM, Ivan Trombley wrote: I want to revisit this issue. Building 64 bit on Linux, release or debug, is fast. However, building 64 bit release on Windows 10 is super slow. I have a cross platform app that uses gtk-d. Today, I updated DMD to 2.079.1 and the gtk-d lib to 3.8.0. When I performed a debug build on Windows 10, it only took a few seconds to build gtk-d. I attempted to build release but canceled the build after a couple of hours. I tried building 32 bit release on Windows and while it took a lot longer than debug, it still completed in a reasonable amount of time (it wouldn't link, though, probably because I'm missing some 32 libraries). Does anyone have any idea why 64 bit release builds on Windows would take so long? I have no idea why, but I can confirm that I am seeing something similar on Windows 10. I have tried it both with anti-virus enabled and disabled, with the same results. Compiler Version: 2.079.1 (-m64 switch set in the sc.ini file) Using a gtkd project (tried two versions 3.8.0 and 3.8.1) Attempts: 1. plain build It succeeds with this output (build time is 21 seconds, including fetching): C:\DProj\gtktest>dub build -b plain --force Fetching gtk-d 3.8.1 (getting selected version)... Performing "plain" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64. gtk-d:gtkd 3.8.1: building configuration "library"... gtk-d:gstreamer 3.8.1: building configuration "library"... gtk-d:peas 3.8.1: building configuration "library"... gtk-d:sv 3.8.1: building configuration "library"... gtk-d:vte 3.8.1: building configuration "library"... gtktest ~master: building configuration "application"... Linking... 2. debug build It succeeds with a linker warning (build time is 23 seconds, already fetched): C:\DProj\gtktest>dub build -b debug --force Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64. gtk-d:gtkd 3.8.1: building configuration "library"... gtk-d:gstreamer 3.8.1: building configuration "library"... gtk-d:peas 3.8.1: building configuration "library"... gtk-d:sv 3.8.1: building configuration "library"... gtk-d:vte 3.8.1: building configuration "library"... gtktest ~master: building configuration "application"... Linking... gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info gtkd-3.lib(ActionIF.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info 3. release build This hangs (I killed it after 10 minutes): C:\DProj\gtktest>dub build -b release --force Performing "release" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64. gtk-d:gtkd 3.8.1: building configuration "library"...
