Re: D IDE
On Monday, 3 September 2018 at 19:31:58 UTC, Jonathan M Davis wrote: Because they can't hold a candle to vim. As far as text editing goes, there simply is no comparison. All these arguments, especially the above, makes me sad. May be this is the nature of open source that volunteers will work only on things that they like and may not always be aligned with all the users needs. D was born almost two decades ago when IDEs and tools that make user experience smooth as defined by current standards didn't exist that freely. Major competition then was c++ and Java. D was a breath of fresh air. It was as fast as c++ and as clean as Java. No wonder many people loved D. Nowadays the programming language landscape is much different. With Go, Rust, etc the competition is not only catching up but even surpassing D in popularity. I wonder why. I sometimes feel D is still stuck in the previous era. At least in my experience this smoothness factor has a heavy weight. I abandoned Java wonderful ecosystem for D's native and fast compilation and fast startup. I wrote D programs in notepad++ etc. I endured lack of so many wonderful features of a mature IDE like eclipse or netbeans. Now after 20ish years still a mature and smooth ecosystem is no where in sight. D did find some success with expert programs, good for them, but I couldnt take it any more. Funnily, I went back to Java. The improvements in java language, JVM and hardware in general lessened the pain of java very much. It was amazing how much easy and smooth experience matters to increase the productivity. I still keep an eye on D, the ecosystem seems to be getting better although at glacial pace. Everytime I read a comment like above, this comes to my mind https://imgs.xkcd.com/comics/supported_features.png
Re: How about implementing SPMD on SIMD for D?
On Saturday, 7 July 2018 at 13:26:10 UTC, Guillaume Piolat wrote: On Friday, 6 July 2018 at 23:08:27 UTC, Random D user wrote: Especially, since D doesn't even attempt any auto-vectorization (poor results and difficult to implement) and manual loops are quite tedious to write (even std.simd failed to materialize), so SPMD would be nice alternative. I think you are mistaken, D code is autovectorized often when using LDC. That is good to know. I haven't looked that much into LDC (or clang). I mostly use dmd for fast edit-compile cycle. Although, plan is to use LDC for "release"/optimized build eventually. Anyway, I would just want to code some non-trivial loops in SIMD, but I wouldn't want to fiddle with intrinsics. Or write a higher level wrapper for them. In my experience, you can only get the real benefits out of SIMD if you carefully handcraft your hot loops to fully use it. Sprinkling some SIMD here and there with a SIMD vector type, doesn't really seem to yield big benefits. Sometimes it's not and it's hard to know why. Exactly. In my experience compilers (msvc) often don't. A pragma we could have is the one in the Intel C++ Compiler that says "hey this loop is safe to autovectorize". What do you think? I think that ispc is like OpenCL on the CPU, but can't work on the GPU, FPGA or other OpenCL implementation. OpenCL is so fast because caching is explicit (several levels of memory are exposed). Yeah, it should be similar. The point is not run it on GPU, you can do CUDA, OpenCL, compute shader etc. for that. CPU code is much easier to debug, and sometimes you're already doing things on the GPU, but your CPU side has more room for computation. And you don't have to copy your data between the GPU and CPU or deal with latency. Of course, OpenCL runs on CPU too, but I think there's quite a bit of code required to set it up and to use it. I guess my point was that I would like to do CPU SIMD code easily without intrinsics (or manually trying to trick the compiler to vectorize the code). SPMD stuff seems to solve these issues. It would also be a forward looking step for D. Ideally, just write your loop normally, debug it and add an annotation to get it to run fast on SIMD. Done.
How about implementing SPMD on SIMD for D?
TL;DR
Would want to run your code 8x - 32x faster? SPMD (Single Program
Multiple Data) on SIMD (Single Instruction Multiple Data) might
be the answer you're looking for.
It works by running multiple iterations/instances of your loop at
once on SIMD and the compiler could do that automatically for you
and your normal loop & array code.
---
I'm a bit late to the party, but I recently was reading this (
http://pharr.org/matt/blog/2018/04/30/ispc-all.html ), a highly
interesting blog post series about how one guy did what the Intel
compiler team wouldn't or couldn't do.
He wrote a C like language and compiler on top of LLVM which
transforms normal scalar code into "parallel" SIMD code.
That compiler is called the ISPC (
https://ispc.github.io/perf.html ).
It basically works the similarly as GPU shaders, but the code
runs on the CPU SIMD.
You write your code for one thread/lane and the compiler then
runs N instances of that code simultaneously in lockstep.
For example, loop 8x (c.xyzw = a.xyzw + b.xyzw) would become 2x
(x. = x. + x.; y. = y. + y.; z. =
z. + z.; w. = w. + w.) (the notation here is
a bit weird, but I was trying to keep it short).
Branches are done using masking, so the code runs both sides of
the branch, but masks away the wrong results.
All of this is way better described in the paper they wrote about
it ( http://pharr.org/matt/papers/ispc_inpar_2012.pdf ). I
recommend reading it.
I was also looking at some videos from Unity (game
engine/framework) about their new "Performance by default"
initiative.
They are building a custom subset of C# with their own compiler
to native code. It looks like the subset is just C# with structs,
functions, slices and annotations (no classes).
That reminded me of D :).
One thing they touched was pointer aliasing and how slices and
custom compiler tech (that knows about the other engine systems)
allows them to avoid aliasing and produce more optimal code.
However the interesting part was that the compiler does similar
things as the ISPC when specific annotations are given by the
programmer.
Video about the tech/compiler is here (
https://www.youtube.com/watch?v=NF6kcNS6U80&feature=youtu.be?list=PLX2vGYjWbI0S8ujCJKYT-mIZf7YCuF-Ka ).
It occurred to me that SPMD on SIMD would be really nice addition
to D's arsenal.
Especially, since D doesn't even attempt any auto-vectorization
(poor results and difficult to implement) and manual loops are
quite tedious to write (even std.simd failed to materialize), so
SPMD would be nice alternative.
D also has some existing vector syntax and specialization, so
there's a precedent for vector programing. This could be
considered as an extension to that.
The SPMD should be easy to implement (I'm not a compiler expert)
since it's only a code transformation and not an optimization.
Finally, I don't think any serious systems/performance oriented
language can ignore that kind of performance-increase figures for
too long.
I had something like this in mind:
@spmd //or @simd // NOTE: just removing @spmd would mean it's a
normal loop, great for debugging
foreach( int i; 0 .. 100 )
{
c[i] = a[i] + b[i];
}
or
void doSum( float4[] a, float4[] b, float4[] c ) @spmd //or @simd
{
c = a + b; // NOTE: c[i] = a[i] + b[i], array index is
implicit because of @spmd, it's just some index of 0 .. a.length
}
What do you think?
Re: Sign the installers
It's all about removing resistance and raising the level of professionalism. D isn't a hobby project and shouldn't act like one. This is an obvious barrier that's worth removing. In this day and age of rampant actively dangerous software, it's an obvious improvement to sign it and make the strong claim that this is produced and vended by the d foundation and we vouch for it's contents. We already do for some (all?) of the posix distribution bundles. Well said, thanks.
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: Favorite GUI library?
I write lot of small utilities on Windows and prefer to have a gui. Gtkd is nice. Glade is awsome. but the runtime dlls are about 20mb, too much for a 1mb tool. For some reason the theming on Windows didnt work well for me. Dwt is nice, but no glade like gui editor. when using dwt, I build gui manually. Html css looks too different from native app. Opening and saving files is painful, nok. Most of the time java, swing, netbeans works very well. Startup time sucks, so i just added an intrresting splash screen and people seemed to like it. I have high hopes for dlangui, but it's still beta and has some bugs that's blocking me. In conclusion, if startup time is important i use dwt. Otherwise java with netbeans.
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"...
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
When i hear Go, you hear uniformal, fast, simple syntax language. When i hear Rust, you hear safe, manual memory management. When i hear D, you hear ... ... ... ... I usually hear awesome meta-programming and ranges. I think D community had put lot of effort in making these things work because (1) these are cool (2) increases expressive power. Unfortunately at the detriment of tooling and libraries. I think we should put a stop to adding new features in D2 at some point and focus on stability, libraries and tools. Can't wait to see how the road map looks like for 18H1.
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: On 1/4/2018 2:34 AM, Mike Franklin wrote: Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of late are mostly just refactorings rather than fixing difficult bugs. There's a lot of technical debt I've been trying to fix While not directly applicable to 'technical debt', has anyone ever written a fuzzer for dmd? Basically a testing software that generates valid or almost valid (negative case) input (code using grammar rules) and tries to run it through the application (compiler) to see what happens. These things usually reveal tons of easy to fix bugs at the application interface level and some hard to fix corner cases that no one thought. Best of all, you will get easy to use test cases that some else can try to fix. Unfortunately fuzzers often get stuck in local maximums, so you need to spend some time with app coverage using the generated data and modify the fuzzer accordingly. But once it has been built and it tests large code coverage, it's an awesome tool to reveal bugs and test changes. Just make a change, run tests, run fuzzer for 5-15 mins, 1h or days if you want extra coverage. I think there's also a variant of this that takes valid code and replace existing code constructs with equivalent but unusual constructs.
Re: So why double to float conversion is implicit ?
Is there a list of such quirks or gotchas in dlang? The ones I know of are 1. Implicit conversion from double to float 2. Integer division results in integer result truncation the fractional part. 3. ??
Re: My two cents
On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote: On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote: return foo ?? null; would be so much easier. return getOr(foo, null); I guess with UFCS you could get: return foo.PP(null); // vs. return foo ?? null; :D
Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 13:14:39 UTC, Steven Schveighoffer wrote: I don't know what the expectations of a Windows user are. In my exprience 80% of mainly Windows devs (in professional environment) use Visual Studio + plugins (e.g. Visual Assist/Dpack etc.). Most of the remaining 20% use Visual Studio with vim keybindings/emulation or they code with vim/emacs, but use Visual Studio for debugging. And the last 2% use something completely different. I think Visual Studio is the professional standard for C/C++/C# on Windows (as in Windows is the main platform and not some bad port hacked on top of cygwin). Basically what Xcode is for Mac.
Re: D on quora ...
On Friday, 6 October 2017 at 18:09:58 UTC, Ali wrote: On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote: On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via Digitalmars-d wrote: https://www.quora.com/What-is-your-review-of-D-programming-language It seems that D still has the GC being mentioned up to today. Maybe its better to move the standard library slower to a non gc version in the future... Why is GC a problem? T The reputation is D's GC is slow, and Manual Memory Management is fast Actually, Manual Memory Management is slow and D's GC is slower. But IMO that kind of means GC isn't that big of a problem in D. Because, if malloc/free is slow (free is often slower), you want to avoid them as much as possible. You do this by reusing your memory/buffers. Which means that even if they are GC allocated buffers, they aren't collected and you are not allocating new buffers (often) after initial allocs, so the GC doesn't even run. There was a good talk in cppcon2016 that gives you an example what high perf AAA games do for memory allocation. The presenter explains how they reduced memory allocations from 300 000 to 3000 (https://youtu.be/tD4xRNB0M_Q?t=1200).
Re: Problem with integral promotions
On Saturday, 22 July 2017 at 10:44:04 UTC, Walter Bright wrote: 1. Fix it so it matches C, as has been generally promised. Fixing it will break existing code such as: If D was my language I'd fix it, since it's a bug. D's fluidity and effortlessness comes from a lot of small compounding convenience features. The converse is true as well. A lot of small annoyances accumulate into frustration.
Re: proposed @noreturn attribute
On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu
wrote:
On 7/8/17 7:07 AM, bachmeier wrote:
On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
Having an @noreturn attribute will take care of that:
@noreturn void ThisFunctionExits();
Why should this be an attribute rather than a pragma?
So it's part of the summary of the function. -- Andrei
If it feels like a pragma, should be part of the function and
reflectable, then how about:
void assertFalse(bool cond) @pragma(noreturn)
or
void assertFalse(bool cond) @pragma("noreturn")
The compiler could probably give an error if the "" (inside
@pragma) wasn't a known string.
Also @pragma would be useful as standard way of saying "special
compiler attribute". No need to consume global attribute
namespace.
I'm expecting to see @myproject_safe and @myproject_noreturn type
of attributes someday in some project :|
Re: What are your hopes for the future D GC
On Friday, 30 June 2017 at 06:14:41 UTC, Dmitry Olshansky wrote: On 6/29/2017 10:19 PM, Random D user wrote: 2. Composable custom memory block GC. The ability to mallocate 128MB memory block and create a new GC instance to manage that block. It would only need to scan that 128MB block and not worry about rest of memory and resources (with complex destruction orders) in 16GB heap. This way you probably could guarantee good collection times for some subsystems in your program and use your favorite allocator for others. Not sure what benefit this has compared to just limiting GC heap to 128Mb. More flexibility, control and tools for doing mixed memory management. I was thinking that you could have multiple of these (thread local or single threaded, edge cases/safety would be user responsibility). Basically turning gc into similar custom allocator as "bump the pointer" allocators or object pools. This way few of these GCs could be used as poor man's incremental GC. I think it could be useful for applications that have tight memory and timing budgets. For example, in games, you typically have couple bigger subsytems. Some game architectures preallocate all the memory they need and distribute it to each subsystem using custom allocators. Maybe some systems with lot of small allocations could use "memory block local GC" and be fast enough. For example, some sort of a scripting or debug console subsytem could be fine with 32MB, but you wouldn't need care about releasing your temp objects. Small heap size would guarantee fast collections. And for some sort of incremental emulation you could manually trigger the collections and cycle between different local GC per frame or timestep. Also if any of the would pause for too long, you could easily just see which one and fix it.
What are your hopes for the future D GC
I just got curious, after reading the GC analysis blog post. What kind of features people generally would want for the GC (in the distant murky future of 1999)? Here's some of my nice to haves: 1. Thread local GCs. D is by default thread local, so it kind of would make sense and goodbye stop everything GC. 2. Composable custom memory block GC. The ability to mallocate 128MB memory block and create a new GC instance to manage that block. It would only need to scan that 128MB block and not worry about rest of memory and resources (with complex destruction orders) in 16GB heap. This way you probably could guarantee good collection times for some subsystems in your program and use your favorite allocator for others. 3. Callbacks to GC operations. I have timeline profiler implemented for my project. It would be quite cool to have GC collection starts and stops record a timestamp for the timeline. (Can this be done already? Hopefully without recompiling the GC. I tried to look but I couldn't find any hooks in the docs.) 4. Incremental GC with collection time limit. Is this even viable for D?
Re: Let's paint those bikesheds^Werror messages!
On Tuesday, 27 June 2017 at 18:42:45 UTC, Vladimir Panteleev wrote: On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote: What ever you do, please don't use extreme high intensity colors like red(255,0,0), green (0,255,0) or blue (0,0,255). That's up to the terminal (or your configuration of it). Without making many assumptions, console applications are limited to 16 symbolic colors, with their exact values depending on the OS/terminal/configuration. Right. I should've known that. I guess I don't really use cmd prompt or bash much these days. I'm pretty much always on windows and using Visual Studio for D, C/C++ and others with custom color plugin for errors. And GUI everywhere :).
Re: What are the unused but useful feature you know in D?
On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:
On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
Anyway, I think we could just have a compile time switch for
defaults.
Imagine having n libraries with pairwise different required
defaults used in your application. Say goodbye to combined
compilation, hello n separate required compiler invocations.
Yeah, that's true. I didn't really think of full source
compilation of libs in your project. I though .lib would've been
compiled with some settings and you'd just link with that and
work with its api.
Also in reality I wouldn't want to be able to cancel @nogc in a
function, because then the attribute would just lose power and
you couldn't trust it. I just used it as a simple example for the
@ and @! syntax that I'd like to have in general. Which would
allow a nice way of working with sections of code like this:
class
{
@nogc:or @!gc:
... some code ..
@gc:or @gc:
... more code ..
@nogc:or @!gc:
... even more code ..
}
Also I think @safe is a little bit broken (because of @trusted
and even the very pros (d-devs) seem to get @trusted wrong on
a regular basis (at least that's my perception)). Just bite
the bullet and use Rust if you want to be actually safe.
Except Rust is in exactly the same boat as D, because the same
issues that apply to `@trusted` apply to `unsafe`, as well.
Hmmm, I guess that's true. I don't really know a lot about Rust.
Their safety story just sounds way more convincing and believable
than D's. It would probably be the first language I'd look into
if I was interested in low level safety critical code.
Re: Let's paint those bikesheds^Werror messages!
On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev wrote: With 2.075's release near, now would be a good time to decide on a nice color palette that looks fine on most terminals. So, please vote: What ever you do, please don't use extreme high intensity colors like red(255,0,0), green (0,255,0) or blue (0,0,255). They'll burn through your eyes and look bad on either white or black. If you replace 0s with 32 and 255s with 192 you'll get colors that are more easy on the eyes and will work better on both black and white backgrounds. Another strategy is to use HSV. Set saturation and value something decent like 80 and 75. Then loop through hue with 360 / num_colors step + good offset. Now you should get enough colors that are as far from each other as they can be and give good contrast. You can quickly preview this in some photo editor, or maybe even faster by writing some d code :) I guess the next level would be actual color design instead of nerdy math.
Re: What are the unused but useful feature you know in D?
On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on request
3) imagine more potential going forward
I dislike doubling the keywords by having a 'not' case for each.
I'd rather have a systematic way of adding/removing attributes
and udas.
Something like:
@gc
@!gc (previously @nogc, compiler could even rewrite @nogc into
@!gc for transition)
---
Anyway, I think we could just have a compile time switch for
defaults.
Since some projects want to have pure, @safe, immutable by
default, but others want to have @system @nogc. And no one wants
write attributes more than they have to.
For example, I kind of like the current defaults since I like
flexibility/changeability/editability of code. Because that makes
coding fun which in turn usually means better code, features and
productivity. Strictness is just a kind of salt that can be
sprinkled on code in few difficult or dangerous cases.
Also I think @safe is a little bit broken (because of @trusted
and even the very pros (d-devs) seem to get @trusted wrong on a
regular basis (at least that's my perception)). Just bite the
bullet and use Rust if you want to be actually safe.
I'm not a huge fan of immutable/const system either as it's kind
of difficult to use and low benefits. It often leads into
backtracking and changing your code all over the place (small
change becomes an avalanche), because you found out in the last
leaf function of your subsystem, that your design can't actually
be immutable (basically, you forgot or couldn't imagine that
elusive corner case no. 99).
The good thing is that immutable/const is actually strict and
checkable. No holes like in @safe.
So if this change would happen, I would probably start all of my
d files with
impure:
@system:
(@nogc:) // depending on my needs, I actually haven't had big
issues with the gc
(nothrow:)
...
Which reminds me that it would be nice to group attributes as
well.
Something like this:
alias @apiStrict = @safe immutable pure
int foo() @apiStrict
{
return 1;
}
Re: DIP 1003 Formal Review
On Sunday, 14 May 2017 at 15:39:12 UTC, Walter Bright wrote:
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway.
A combination of Options 1 and 2:
1. Introduce 'function' as an alternative to 'body'.
How about using some other keyword like, with, else, scope or do,
for example.
Would they read better than 'function' (i.e. function with vs.
function function vs. function body)? Let's experiment a bit.
int foo()
in
{
}
out
{
}
with
{
bar();
}
-- or
int foo()
in
{
}
out
{
}
else // I guess this could be too confusing with template
constraint? See below.
{
bar();
}
int foo(T)() if(cond)
in
{
}
out
{
}
else
{
}
-- or
int foo()
in
{
}
out
{
}
scope
{
bar();
}
-- or
int foo()
in
{
}
out
{
}
do
{
bar();
}
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 22:11:19 UTC, Namespace wrote:
nuDist - in D you can program as free as you want. ;)
void main()
body
{
asm
{
naked;
}
}
Re: memcpy() comparison: C, Rust, and D
On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote: We would love to change the defaults, but unfortunately that boat has already sailed a long time ago. What if d had a -safe-defaults switch? It should be ok, since safe is stricter than unsafe right? This way old/existing code would compile fine by default, but if you want to use that code/lib with safe-defaults you either have to do trusted wrappers or modify it to be safe. All new code with safe-defaults would compile fine in safe mode and unsafe mode. To me it's similar approach to 'warnings-all' and 'warnings-as-errors'. --- I myself don't really care for @safe, it's complex and seems to have big practical hole with @trusted. Kind of like 'refs can't be null in c++' (as some people claim/argue) and then someone passes nullptr into function ref arg. Completely unreliable, even though refs usually work ok 99% of the time (by conventions and effort). I've already thrown const, immutable, inout mostly in to trash (string literals etc. are exception) after few tries. They make the code more complex and harder to modify especially when you have bigger system. Often you realize that your system/module isn't truly 100% const in the last insignificant leaf function, and that triggers large cascading modifications and rewrites, just to get the code work. Also I can't really remember when I accidentally modified data that I shouldn't have (i.e. violate const protection). But I often modify correct data incorrectly. I believe most programmers first figure out what they need to do before doing it instead of just writing randomly into some array/pointer that looked handy :) I prefer flexible (fun), fast and debuggable (debugger/printing friendly) code. It seems that neither @safe or const are part of it. (I'm not writing life and death safety critical code anyway).
Re: color lib
On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
I've done another pass incorporating prior feedback, mostly
focusing on documentation.
Just a quick minor comment on:
A8 RGB!("a",ubyte,false,0) 8 bit alpha-only color type.
-->
Reads like, "False what ???". Also "What is 0 ???".
-->
How about RGB!("a", ubyte, Linear.No, Colorspace.sRGB) or
something like that,
since there's going to be a list of these in the docs.
What does colorspace 0 mean actually? (AdobeRGB??? i.e. first
from colorspace enum according the docs).
Re: colour lib needs reviewers
On Tuesday, 13 September 2016 at 02:00:44 UTC, Manu wrote: On 13 September 2016 at 07:00, Marco Leise via Digitalmars-d wrote: Am Tue, 13 Sep 2016 00:37:22 +1000 schrieb Manu via Digitalmars-d : Alright, but hybrid gamma is really not something that can be googled. Or rather I end up at Toyota's Gamma Hybrid product page. :D True. I'm not even sure what the technical term for this sort of gamma function is... I just made that up! :/ As Walter and others have asked, I'll have to start adding links to reference material I guess, although that still feels really weird to me for some reason. FWIW I stumbled into this while double-checking HDR standards for my previous post. (I'm not a HDR expert, only somewhat interested because it's the future of displays/graphics) https://en.wikipedia.org/wiki/Hybrid_Log-Gamma
Re: colour lib needs reviewers
On Tuesday, 13 September 2016 at 01:05:56 UTC, Manu wrote:
Can you describe what you perceive to be hard?
Well, I just skimmed through the docs and I didn't look at the
code, so that sense it was an "honest" view for phobos proposal.
Also I was trying to convey that based on the docs it "looks
hard", although I was suspecting that it isn't really.
So the list of things was a list of examples that I would've
wanted to see in the docs. Maybe in an overview or "here's how
you use it" page. I can read the details if I really need them,
but I think it's important to have a cook book examples for quick
start.
In general, I think basics should be dead simple (even over
simplified for the very basic case), but the API and the docs
should provide me layers of increasing detail and sophistication,
which I can study if (or when) I really need control and care
about the details.
Few basic things I'd be interested in (examples):
1. How to pack/unpack color into uint/rgba channels.
auto c = RGBA8(r, g, b, a);
uint r = c.r.value; // 'r' is a 'NormalizedInt", so you need
'.value'
to get the raw integer value
float g = cast(float)c.g; // cast to float knows about the
normalized 0-1 range
Let's put these in the docs.
Also can I swizzle channels directly?
I could add something like:
auto brg = c.swizzle!"brg";
It's just a nicety. I guess I could just define exact color
formats and convert (let the lib do the rest), or just unpack and
repack.
Also the docs might want to mention which way is the
preferred/designed way.
2. Can I just cast an array of bytes into a RGBA array and
operate on that?
Yes. Of course, if the image library returned an array of
colors, you wouldn't have an array of raw bytes in the first
place.
Cool. I just wanted to make sure something like this possible.
Also should be in the docs as an example, so that people don't
have to try this out themselves.
Or search through github for details.
3. How to scale color channels e.g. 5 bits to 8 bits and vice
versa. How to convert color formats? Can I combine
scale/conversion with single channel or channel swizzling?
alias CustomPackedColor = PackedRGB!("BGR_5_6_5", ubyte); // <-
ordered bgr
CustomPackedColor[] image = loadPackedImage();
auto unpacked = cast(RGB8)image[0]; // unpack and swizzle
I'm not sure what you mean by "with single channel"?
For example if you first unpack RGBA_uint32 into R,G,B,A then you
want to take G (or just swizzle color.g) and scale that to 5 bits
or 16 bits for what ever use case you might have.
Looks to me like this can be handled with something like
PackedRGB!("G_5") and then do color conversion into that.
4. Which way are RGBA format names defined ("byte array order"
r is first byte or "uint order" r is in high bits)?
I describe formats in byte (bit) order. It's the only
reasonable way
that works outside of a uint.
Agreed. This should be in the docs, so that it's clear to users.
(especially, since RGBA is the common case and it does fit
into uint)
I'm showing that parsing colors from string's follow the web
convention. I can't redefine how colours are expressed on the
web for
decades.
I think you've just highlighted that I need to remove the '0x'
notation though, that is definitely misleading! Use '#', that
should
be clear.
Right. I was interpreting 0x as c hex literal. You should
document that it's following the web convention.
6. Perhaps you should define all the usual color formats,
since everybody
and their cat has their own preference for rgba channel orders.
In my experience all these 4 variants for RGBA are pretty
common:
RGBA
BGRA
ARGB
ABGR
and their X and 24bit variants.
I don't think they're common at all. Only 2 are common (one of
which
is deprecated), the other 2 are very niche.
Deprecated by who? Shouldn't phobos grade lib include all
reasonable platforms?
I agree that you probably don't see too much variation within
windows APIs, images (BMP etc.) or with D3D GPU textures (they're
compressed anyway and asset pipelines to do the conversions
beforehand), but I was more of thinking image libraries and the
numerous, sometimes old and quirky, image formats. Or perhaps
someone wants to implement a software blitter for their favorite
toy device/embedded project.
I was trying to balance a tasteful amount of instantiations. I
don't
really want to provide an instantiation of every single realtime
format I've ever encountered out of the box.
Seems reasonable.
For 16 bits fairly common are:
RGB565 and RGBA5551, also sometimes you see one of RGBA
permutations
(like RGBA8 above).
Nobody uses 16bit textures anymore. Compressed textures are
both MUCH smaller, and generally higher quality.
Sure, agreed. These are not too useful as GPU textures these days
(even on mobile), but if you do software 2d, load older image
formats (image viewer etc.) or something even
Re: colour lib needs reviewers
On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
I think I'm about as happy with my colour lib as I'm going to
be. It really needs reviews.
- Manu
Hi. I'm just a random forum lurker, but here's my feedback.
It needs more docs/examples for the basic usage cases (i.e. how
to skip docs and start working).
Now at first glance it looks like working with RGBA (most common
case (with srgb)) is complicated and while reading the docs I
kind of felt like I'd just write my own.
Few basic things I'd be interested in (examples):
1. How to pack/unpack color into uint/rgba channels. Also can I
swizzle channels directly? How would I extract a single channel
from color?
2. Can I just cast an array of bytes into a RGBA array and
operate on that?
3. How to scale color channels e.g. 5 bits to 8 bits and vice
versa. How to convert color formats? Can I combine
scale/conversion with single channel or channel swizzling?
4. Which way are RGBA format names defined ("byte array order" r
is first byte or "uint order" r is in high bits)?
5. Is it the same for packed rgba formats?
I'm not sure if packedrgb is a necessary distinction. Aren't they
all kind of packed (small structs)? There's no guarantee that 1
byte is not just a part of a bigger field.
Btw. Your RGBA8 example is a bit weird:
static assert(RGBA8("0x908000FF") == RGBA8(0x80,0x00,0xFF,0x90));
I'd assume RGBA8(r,g,b,a) would be either "uint order" r(0x90),
g(0x80), b(0x00), a(0xFF) or "byte array order" (le) r(0xFF),
g(0x00), b(0x80), a(0x90)
6. Perhaps you should define all the usual color formats, since
everybody and their cat has their own preference for rgba channel
orders.
In my experience all these 4 variants for RGBA are pretty
common:
RGBA
BGRA
ARGB
ABGR
and their X and 24bit variants.
For 16 bits fairly common are:
RGB565 and RGBA5551, also sometimes you see one of RGBA
permutations (like RGBA8 above).
Also L16 is pretty common for heightfields or other data
images/textures.
I guess there are also planar formats, but I think those are more
of a Image problem space.
Just as a completely random idea - How about aliases for HDR
formats like HDR10 and Dolby Vision? Kind of looks like they're
just combinations what you already have.
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 05:56:37 UTC, Vladimir Panteleev wrote: - A specific list of things that can be improved I too like the current soft dark theme of the forum (and website). Would it be possible to have optional dark theme in the forum settings? I wish the main website would have a dark alternative too, because I might have language/phobos docs open all day on my second monitor. The forum theme also has grey text on grey background (almost the same gray) in few places which makes it hard to read. While neutral gray is fine as background for black text in a darker theme, I don't really like its usage as part of visual elements in the current light theme. IMO big neutral gray boxes make the site look really boring (like a rainy day). And even the red seems a bit like sun burnt and used.
Re: Three people out of four dislike SDL
It all started here http://forum.dlang.org/post/evxhpxfkeorrrkhqz...@forum.dlang.org :-) ... or one of the posts in that thread, I mean.
Re: dmd codegen improvements
On Friday, 28 August 2015 at 21:59:57 UTC, Walter Bright wrote: On 8/28/2015 4:18 AM, Temtaime wrote: Are you sure that ONE Walter can achieve what they done ? People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. LLVM is a fine compiler, but there's nothing magical about it. Besides, we have a secret productivity enhancing weapon that LLVM doesn't have - D! Now, if I can only tear myself away from the internet for a while... The problem is that you're pretty much the face of D along with Andrei. Andrei announcing he was quitting Facebook to work on D fulltime was one of the most popular articles on Reddit's programming subreddit in the past month. Someone picks up D, and realizes that out of the box it has a full stop the world 1960s-style garbage collector completely wrapped in a mutex, can't inline constructors/destructors, basically non-functioning RTTI, no safe way to manage resources, a type system with massive holes in it, type qualifiers being suggestions, the non-proprietary compilers that generate faster code lag a year+ behind. Even more than this, D has no real IDE integration like C++ or Java, and none is even being worked on as far as I'm aware. D is advertised as a system's language, but most of the built-in language features require the GC so you might as well just use C if you can't use the GC. There's other things I can't remember right now. Then they come to the forums and see the head people of D working on ... DMD codegen improvements. That inspires a lot of confidence that these issues will get fixed beyond fixing them yourself - because that's what everyone adopting a new language wants to do. Do you know what the most complaints about D in the reddit thread were? D's incredibly old garbage collector, a complete lack of a good IDE, and a lack of good manual memory management utilities. I'm not blaming you, I'm just not sure if you're aware of what this looks like. If you intend for D to be a hobby project, then continue on.
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? What a cool thread. This is very valuable info for new(ish) d users. It's often the case for language features that they are just branded cool. But that's just a statement (and you go 'uhm, ok.'). What people usually need is some kind of proof or demonstration why they are useful and how to solve problems with them (which you can usually only get through experience). Wouldn't it be great if there was a wiki page of cool d-features where each feature would have a list like this showcasing what people have done with it? You could then just point people to this wiki page to get a practical view of why d is great.
Re: Breaking changes in Visual C++ 2015
On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote: https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx I'm sharing this specifically so we can have an unproductive flamewar about whether breaking changes in D are sometimes worth it or if they are holding D back from mass adoption :). the truth is, one of the biggest things holding D back from mass adoption is the complete lack of tooling compared to basically every other mainstream language. Compare D to Go, https://golang.org/cmd/go/ Go comes with a package manager, a linter, a static analysis tool, a formatter. Does D have these in some form? Sure. But you have to go hunting for them, and they're OK at best. And really, the only thing to blame for this is dmd. Go provides a Go parser and tokenizer right in their standard library - just one of the benefits of their compiler being written in Go. A lot of D's issues come back to: dmd is long in the tooth. Things D used to tout(faster compiler times) aren't really there anymore. My _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling. Due to how modules are compiled, it's _slower_ to do separate object compilation like in C++, so it's impossible to even get a gain from parallel compilation. Then you have LDC and GDC which generally lag behind dmd by a version or two(usually moreso for GDC,) fragmenting the libraries heavily because many new D versions fix tons of bugs. Due to dmd's license, it can't even be redistributed on Linux, BSD, etc. So now you have compilers for major Linux distros that are lagging versions behind. And really, the packages aren't well maintained anyways - LDC got blacklisted from Ubuntu for being unmaintained. If there's anything to learn from Go's success, it's that you don't need a good language design to be successful. If you want D to be successful, submit some PRs to SDC. If you want D to stay unpopular, keep moving towards Haskell with braces.
Re: DMD compilation speed
I've used D's GC with DDMD. It works*, but you're trading better memory usage for worse allocation speed. It's quite possible we could add a switch to ddmd to enable the GC. As a random d-user (who cares about perf/speed and just happened to read this) a switch sounds VERY good to me. I don't want to pay the price of GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits). Also, I wanted to add that freeing (at least to the OS (does this apply to GC?)) isn't exactly free either. Infact it can be more costly than mallocing. Here's enlightening article: https://randomascii.wordpress.com/2014/12/10/hidden-costs-of-memory-allocation/
Re: Window creation, for phobos?
I don't know, you sound like a perfectionist to me, like most of other community members. I can only give examples from my experience. I am a controls engineer in my current day job, and I do SW coding in my free time (like couple of hours per week). In the past, I changed my D GUI libs from old-DWT --> DFL --> GTKD --> new DWT for obvious reasons. I cannot afford to keep doing that. Finally I gave up and picked python-TKinter and Java-swing. I know they will always work and they still keep working without any changes even after several update cycles. My tools were such a hit that half the company (~ 0.5 * 2000 people) is using them now, which is nice. Had I written them in D, that would have been a nice advertisement for D. Note that I don't care that the GUI lib has to be awesome or perfect. It just have to work, even if it is ugly like tkinter. I think I understand the reasons for this philosophy of lean, mean and efficient std libs, they will help D compete with other heavily financially backed languages, but I guess the same philosophy is also hurting people like me. Maybe in another 10 years we will get a super efficient gui-lib in phobos, if at all, most likely we wont. May be next time I will try to experiment once again with the gui-libs in dub. - D user
Re: Window creation, for phobos?
On Wednesday, 28 January 2015 at 12:02:25 UTC, Dicebot wrote: GUI does not belong to Phobos. That's the only reason I use Java instead of D. If GUI is not in phobos, it has no guaranteed support. Of course this is because I only create GUI desktop application. Apparently this is only my issue, all others seems to be ok with no GUI in phobos.
Re: Dgui Will be continue?
don't use crap - use http://forum.dlang.org/thread/ovgoajvboltrtciqf...@forum.dlang.org it is great. works for 64bit!! On Wednesday, 17 December 2014 at 12:26:48 UTC, Gary Willoughby wrote: On Wednesday, 17 December 2014 at 10:35:25 UTC, FrankLike wrote: Dgui is very good,but what status is about now? FrankLike please stop asking about DGui's status here, it's very annoying. http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-fizbqpdqhcpdrzftubsg:40forum.dlang.org http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-pterdvszyjumzkkdells:40forum.dlang.org http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-ijokafwolgjuriglosya:40forum.dlang.org http://forum.dlang.org/thread/mhwrwanwhdzpkxllr...@forum.dlang.org?page=2#post-wnarnobzcmyqldzqfmqh:40forum.dlang.org You can see for yourself the status *at any time* by visiting this URL: https://bitbucket.org/dgui/dgui/ There you can speak to the developer as much as you wish.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via Digitalmars-d wrote: On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d wrote: There was a recent video[1] by Jonathan Blow about what he would want in a programming language designed specifically for game development. Go, Rust, and D were mentioned and his reason for not wanting to use D is is that it is "too much like C++" although he does not really go into it much and it was a very small part of the video it still brings up some questions. What I am curious is what are the worst parts of D? What sort of things would be done differently if we could start over or if we were designing a D3? I am not asking to try and bash D but because it is helpful to know what's bad as well as good. I will start off... GC by default is a big sore point that everyone brings up "is" expressions are pretty wonky Libraries could definitely be split up better What do you think are the worst parts of D? [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ Personally, after years of use, my focus on things that really annoy me has shifted away from problems with the language, and firmly towards basic practicality and productivity concerns. I'm for addressing things that bother the hell out of me every single day. I should by all reason be more productive in D, but after 6 years of experience, I find I definitely remain less productive, thanks mostly to tooling and infrastructure. 1. Constant rejection of improvements because "OMG breaking change!". Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes. 2. Tooling is still insufficient. I use Visual Studio, and while VisualD is good, it's not great. Like almost all tooling projects, there is only one contributor, and I think this trend presents huge friction to adoption. Tooling is always factored outside of the D community and their perceived realm of responsibility. I'd like to see tooling taken into the core community and issues/bugs treated just as seriously as issues in the compiler/language itself. 3. Debugging is barely ever considered important. I'd love to see a concerted focus on making the debug experience excellent. Iain had a go at GDB, I understand there is great improvement there. Sadly, we recently lost the developer of Mago (a Windows debugger). There's lots of work we could do here, and I think it's of gigantic impact. 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years later, I still can't pass an rvalue->ref (been discussed endlessly), create a ref local, and the separation from the type system makes it a nightmare in generic code. This was a nuisance for me on day-1, and has been grinding me down endlessly for years. It has now far eclipsed my grudges with the GC/RC, or literally anything else about the language on account of frequency of occurrence; almost daily. i couldn't agree more. i would like to add, that coming from D1's clean and nice syntax - D2 becomes a syntactic monster, that is highly irritating and hard to get used to. its littered with @ like a scripting language. that really sucks!
Re: RFC: std.json sucessor
I tried using "-disable-linker-strip-dead", but it had no effect. From the error messages it seems the problem is compile-time and not link-time... On Tuesday, 26 August 2014 at 07:01:09 UTC, Jacob Carlborg wrote: On 25/08/14 21:49, simendsjo wrote: So ldc can remove quite a substantial amount of code in some cases. It's because the latest release of LDC has the --gc-sections falg enabled by default.
Re: RFC: std.json sucessor
... I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64). ... I meant Ubuntu 13.10 :D
Re: RFC: std.json sucessor
Hi! Thanks for the effort you've put in this. I am having problems with building with LDC 0.14.0. DMD 2.066.0 seems to work fine (all unit tests pass). Do you have any ideas why? I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64). Master was at 6a9f8e62e456c3601fe8ff2e1fbb640f38793d08. $ dub fetch std_data_json --version=~master $ cd std_data_json-master/ $ dub test --compiler=ldc2 Generating test runner configuration '__test__library__' for 'library' (library). Building std_data_json ~master configuration "__test__library__", build type unittest. Running ldc2... source/stdx/data/json/parser.d(77): Error: safe function 'stdx.data.json.parser.__unittestL68_22' cannot call system function 'object.AssociativeArray!(string, JSONValue).AssociativeArray.length' source/stdx/data/json/parser.d(124): Error: safe function 'stdx.data.json.parser.__unittestL116_24' cannot call system function 'object.AssociativeArray!(string, JSONValue).AssociativeArray.length' source/stdx/data/json/parser.d(341): Error: function stdx.data.json.parser.JSONParserRange!(JSONLexerRange!string).JSONParserRange.opAssign is not callable because it is annotated with @disable source/stdx/data/json/parser.d(341): Error: safe function 'stdx.data.json.parser.__unittestL318_32' cannot call system function 'stdx.data.json.parser.JSONParserRange!(JSONLexerRange!string).JSONParserRange.opAssign' source/stdx/data/json/parser.d(633): Error: function stdx.data.json.lexer.JSONToken.opAssign is not callable because it is annotated with @disable source/stdx/data/json/parser.d(633): Error: 'stdx.data.json.lexer.JSONToken.opAssign' is not nothrow source/stdx/data/json/parser.d(630): Error: function 'stdx.data.json.parser.JSONParserNode.literal' is nothrow yet may throw FAIL .dub/build/__test__library__-unittest-linux.posix-x86_64-ldc2-0F620B217010475A5A4E545A57CDD09A/ __test__library__ executable Error executing command test: ldc2 failed with exit code 1. Thanks
