Re: Coedit 2 alpha 4, split view and dfmt
On Monday, 21 December 2015 at 03:59:20 UTC, Rikki Cattermole wrote: On 21/12/15 4:21 PM, Basile B. wrote: Hello, A new alpha of CE is available: The two latest releases put the focus on the editor: - identifier markup improved. - split view. - macro recording state clearly indicated. - fix (highlighter, cache restoration when workspace is reloaded). - more shortcuts (prev/next location, ddoc, call tips, macro recording, synchro-edit) - more options. Also it's now possible to specify the favorite compiler in the applications options - for DUB: dmd, gdc and ldc are obviously supported. - for the CE projects (aka "native projects"): dmd and ldc are supported. A new widget, "Dfmt commander", has been added. It's a GUI for Dmft. It works automatically on the selected editor and it processes documents in memory only. Download links and detailed changelog: https://github.com/BBasile/Coedit/releases/tag/2_alpha_4 (see also previous release since I haven't announced it here). Thanks again for dfmt support. But ugh, I get access violation(message window) when it formats. Problem fixed now, I've moved two times the git tag and updated the binaries. To the newcomers, don't forget to read the wiki, coedit documentation is part of the software: https://github.com/BBasile/Coedit/wiki
Re: LDC 0.17.0-alpha1 has been released!
Kai Nackewrites: > Hi everyone, > > LDC 0.17.0-alpha1, the LLVM-based D compiler, is available for > download! > This release is based on the 2.068.2 frontend and standard library and > supports LLVM 3.5-3.7. > > Don't miss to check if your preferred system is supported by this > release. We also have a Win64 compiler available! > > As usual, you can find links to the changelog and the binary packages > over at digitalmars.D.ldc: > http://forum.dlang.org/thread/zwoixfjuagmwvlyat...@forum.dlang.org > > Regards, > Kai The ldc cross-compiler for iOS (iphoneos-ldc2) has been updated to match 0.17.0-alpha1. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.17.0-151221 Somebody have fun, -- Dan
Re: iz - it's so easy
On Monday, 21 December 2015 at 18:42:52 UTC, Basile B. wrote: iz is my user library. https://github.com/BBasile/iz http://code.dlang.org/packages/iz http://bbasile.github.io/iz/ Its particularities: - PropDescriptor: set, get something, runtime type. - PropertyPublisher: publish a collection of PropDescriptor - Serializer: read, write PropertyPublishers - Streams: Posix or win streams (file / memory) - memory: manual memory managment, via destruct & construct. And more. The name comes from this: https://www.youtube.com/watch?v=xdYaK3d-BNs
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 17:37:11 UTC, Andrei Alexandrescu wrote: On 12/21/2015 10:28 AM, Jacob Carlborg wrote: The original code is written in HTML, JavaScript and Less (CSS). See repository for build instructions [1]. If I move forward with this I would go with vibe.d. I would prefer Sass for the CSS and CoffeeScript for the JavaScript. That's a large leap. I suggest using Ddoc instead of Sass compact CSS files, see the existing instance at https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd. CoffeeScript sounds like a nice thing to add and is from what I've heard reasonably stable. IMO we should stay away from trans-plied languages like SCSS, Less, and CoffeeScript, for several reasons 1. Everyone who knows the superset already knows the subset 2. Because of 1, going with the superset unnecessarily limits your contributor base (I don't know and have no urge to learn CoffeeScript for example) for a very small amount of gain 3. The compilers out put ugly, hard to debug code, that also tends to be slower 4. We become dependent on their toolchain. What if CoffeeScript or SCSS ceases to exist, especially since Babel is now the fad that has replaced CoffeeScript? E.g. Does anyone remember Dart? How many Dart libraries are sitting unmaintained now? We have to think 10 years in the future so we don't end up rewriting a whole bunch of code and I am willing to bet that CoffeeScript will not be maintained in 2020. No. The top menu uses JavaScript and all the collapsible sections depends on JavaScript. I hope it's possible to change so the collapsible sections are expanded by default. My understanding is this is a sticky point with some, so probably needs fixing before the release. Yes, sites should degrade gracefully. Not everyone has JavaScript http://kryogenix.org/code/browser/everyonehasjs.html
Re: Redesign of dlang.org
On 12/21/2015 02:43 PM, Jack Stouffer wrote: IMO we should stay away from trans-plied languages like SCSS, Less, and CoffeeScript, for several reasons [snip] That sounds reasonable. -- Andrei
Re: Redesign of dlang.org
On 12/21/2015 01:04 PM, Adam D. Ruppe wrote: On Monday, 21 December 2015 at 17:37:11 UTC, Andrei Alexandrescu wrote: That's a large leap. I suggest using Ddoc instead of Sass compact CSS files, see the existing instance at https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd. Why is there a $(COLON) macro in there? Is it because of the silly section feature of ddoc? Why does it matter at the bottom of the file but not in the rest of it? Yeah, that was the reason. I don't remember the specifics. Using text macros in CSS is something I support. Indeed, my css expander does them too, but most of ddoc's other features I fear are wrong like the colon thing, and it lacks stuff that is specifically useful in css itself like nested selectors. Yah, there's always pressure on using the more specialized tool against the general one. I wouldn't sell ddoc for css as a product, but for what we need here is perfectly appropriate. The section-with-a-colon thing is something we should probably not do at all when compiling .dd files. Keep it for code documentation only. (BTW, your _=\n\n pattern is useless, it changes nothing and should be removed.) You must be right, either I was wrong all along or things have changed since. Please submit a tested PR? While I do like using css helper programs... here, I'd prefer to just keep the file simple. Let's just write standard CSS, understanding that it has a few warts, but then getting the benefit of a very easy to understand file for anyone to look at, no need to build it, and the possibility of using standard css tools on it. Sounds reasonable. CoffeeScript sounds like a nice thing to add and is from what I've heard reasonably stable. Please don't. Coffeescript has distinctly negative value to me, including complicating the build process even more, and just being a PITA to write. Again, I'd prefer to keep the javascript files simple too, no processors on them. It's not like we need that much of it on this site anyway. Nice, too. Andrei
[Issue 15465] New: Make the "Ddoc\
https://issues.dlang.org/show_bug.cgi?id=15465 Issue ID: 15465 Summary: Make the "Ddoc\ Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: and...@erdani.com --
Re: segfault in invariant { assert(super); }
On 12/19/15 11:01 PM, SimonN wrote: Hi, the following code compiles fine, then segfaults upon running. class Base { this(int) { } } class Derived : Base { this(int a) { super(a); } invariant() { assert (super); } } void main() { new Derived(5); } Tested both with dmd 2.069.2 on Linux 64-bit, and on dpaste's dmd 2.069.1: http://dpaste.dzfl.pl/4b9475c668f1 Backtrace on my home machine: Program received signal SIGSEGV, Segmentation fault. 0x004246a5 in _D9invariant12_d_invariantFC6ObjectZv () (gdb) bt #0 0x004246a5 in _D9invariant12_d_invariantFC6ObjectZv () #1 0x00647bf0 in _D3app7Derived6__initZ () #2 0x7f7ff030 in ?? () #3 0x0042301f in _D3app7Derived12__invariant1MxFZv (this=0x0) at source/app.d:7 Backtrace stopped: previous frame inner to this frame (corrupt stack?) So, looks like endless recursion inside the invairant. Questions: 1) Is this recursion expected? Yes. assert calls the virtual invariant function, which in the case of super is equivalent to this. So you are essentially calling assert(this). 2) The example is a dustmite'd version of this: I have a public final method Base.f(), and the compiler won't let me call f() in Derived's invariant. This is understandable, because f() is also a public method of Derived. However, I can call super.f() explicitly in Derived's invariant, with no compiler error. Is that expected to work, or should it lead to a similar segfault? (I get the segfault.) It seems like something you shouldn't do. AFAIK, invariant should not call any public functions on your existing class. It would make sense that super.f() should be disallowed if f() is disallowed (good idea to file an enhancement report). But the compiler can't prevent all issues here. All you need to do is obscure that the object you are asserting is 'this', and you can achieve the behavior. The runtime could potentially use a gate to prevent recursive calls, though I think the compiler would have to do this. -Steve
Re: What other than a pointer can be converted implicitly to const(char)*?
On 12/21/15 3:47 PM, anonymous wrote: On 21.12.2015 21:20, Steven Schveighoffer wrote: This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*" To my understanding, `alias this` means "is implicitly convertible to X", and not "is the same thing as X". That is, `is(S == const(char)*)` is false, but `is(S : const(char)*)` is true. It makes sense to me that isPointer behaves like the `==` variant. And for sure, the `alias this` doesn't make S interchangeable with a pointer. S may have a different size, the pointer may not be at a zero offset in S, etc. I'm not saying that isPointer should return true, I'm saying that it shouldn't be used here. For the phobos code in question it comes down to what's less surprising, I guess. Having such an `alias this` resolved before stringification, or not. I'm not sure. I think the issue here is the way the code determines it should use std.format. My preference is: 1. if the struct defines toString, then use std.format which will call that. 2. else if the struct aliases itself to some other type handled here, use that branch 3. else, use std.format anyway, and whatever happens happens. -Steve
[Issue 15464] Template parameter-dependent attributes
https://issues.dlang.org/show_bug.cgi?id=15464 --- Comment #2 from Daniel Kozak--- but s.ident https://github.com/D-Programming-Language/dmd/blob/master/src/parse.d#L4139 must be put to some temporaly variable before changunf s :) --
Socket - handling large numbers of incoming connections
What is the fastest / most scalable way to implement a server (using a Socket) which can handle large numbers of incoming connections? Like, at least 10K, but probably up to 1 million connections. More specifically: 1) How do I efficiently select the connections (client Socket instances) which have data which is ready to read? 2) How do I efficiently select the connection that are ready to accept data sent to them? (which are write ready - in other words) ? I read in the D Cookbook that using the SocketSet is not the fastest way to do this, as it has to iterate through all Socket instances in it, and check a flag on each Socket.
Is the Ddoc heading really necessary?
Destroy! https://issues.dlang.org/show_bug.cgi?id=15465 Andrei
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 19:54:45 UTC, Andrei Alexandrescu wrote: On 12/21/2015 02:43 PM, Jack Stouffer wrote: IMO we should stay away from trans-plied languages like SCSS, Less, and CoffeeScript, for several reasons [snip] That sounds reasonable. -- Andrei Meanwhile, we could also consider the [U.S. Government's standards] (https://playbook.cio.gov/designstandards/), which do explicitly suggest using SCSS. On the other hand, also explicitly state not to use Bootstrap. It also recommends a few different m**w js frameworks (like angular), but don't think it mentions coffeescript one way or another iirc. From what I've seen, these standards are actually exceptionally well written.
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 17:52:39 UTC, BLM768 wrote: We could use the :hover dropdowns as a fallback for the JS, though. It might not be ideal, but isn't that basically the definition of a fallback? Yeah, but :hover dropdowns really suck. I'd prefer a fallback link over them when given the choice. The language reference link list is kinda long and could use an introductory page anyway. (and I don't mean http://dlang.org/spec/intro.html that, I mean a meta-intro that describes what the spec is, how it is laid out, etc. so the reader knows what to expect from it.)
[Issue 15464] Template parameter-dependent attributes
https://issues.dlang.org/show_bug.cgi?id=15464 Daniel Kozakchanged: What|Removed |Added CC||kozz...@gmail.com --- Comment #1 from Daniel Kozak --- this block should be moved https://github.com/D-Programming-Language/dmd/blob/master/src/parse.d#L4134 after https://github.com/D-Programming-Language/dmd/blob/master/src/parse.d#L4161 this would probably fix it --
Re: Socket - handling large numbers of incoming connections
How about https://github.com/dcarp/asynchronous ? Asyncio Socket handling is sometimes quite nice. It's performance is okay for nearly no effort and the code looks clean. Details here: http://dcarp.github.io/asynchronous/asynchronous/streams/startServer.html vibe.d also offers a fiber based asyncio way of dealing with sockets. http://vibed.org/docs#tcp-server Maybe it fits your needs.
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Here's another thread about redesign of dlang.org. I'm creating I want say that there are also people who most like the current design.
Re: Socket - handling large numbers of incoming connections
On Monday, 21 December 2015 at 20:20:44 UTC, Stefan wrote: How about https://github.com/dcarp/asynchronous ? Asyncio Socket handling is sometimes quite nice. It's performance is okay for nearly no effort and the code looks clean. Details here: http://dcarp.github.io/asynchronous/asynchronous/streams/startServer.html vibe.d also offers a fiber based asyncio way of dealing with sockets. http://vibed.org/docs#tcp-server Maybe it fits your needs. Thanks - but I am primarily looking for a solution without external frameworks. Frameworks have a way of bloating over time.
Re: Socket - handling large numbers of incoming connections
My server uses "poll" for that. Okay, how does that work? How do I use "poll" in D? Link? Code example?
iz - it's so easy
iz is my user library. https://github.com/BBasile/iz http://code.dlang.org/packages/iz http://bbasile.github.io/iz/ Its particularities: - PropDescriptor: set, get something, runtime type. - PropertyPublisher: publish a collection of PropDescriptor - Serializer: read, write PropertyPublishers - Streams: Posix or win streams (file / memory) - memory: manual memory managment, via destruct & construct. And more.
Re: What other than a pointer can be converted implicitly to const(char)*?
On 21.12.2015 21:20, Steven Schveighoffer wrote: This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*" To my understanding, `alias this` means "is implicitly convertible to X", and not "is the same thing as X". That is, `is(S == const(char)*)` is false, but `is(S : const(char)*)` is true. It makes sense to me that isPointer behaves like the `==` variant. And for sure, the `alias this` doesn't make S interchangeable with a pointer. S may have a different size, the pointer may not be at a zero offset in S, etc. For the phobos code in question it comes down to what's less surprising, I guess. Having such an `alias this` resolved before stringification, or not. I'm not sure.
Re: What other than a pointer can be converted implicitly to const(char)*?
On 12/21/15 12:03 PM, anonymous wrote: On 21.12.2015 17:02, Shriramana Sharma wrote: https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L878 The `static if` condition here says if something is a pointer and if it is implicitly convertible to const(char)*. The isPointer! part seems superfluous. Is there something that is not a pointer yet implicitly convertible to const(char)*? A struct/class with an `alias this` to a `const(char)*`: import std.traits: isPointer; struct S { const(char)* ptr; alias ptr this; } static assert(!isPointer!S && is(S : const(char)*)); /* passes */ This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*" -Steve
[Issue 15465] Make the "Ddoc" header optional in .dd files
https://issues.dlang.org/show_bug.cgi?id=15465 Andrei Alexandrescuchanged: What|Removed |Added Summary|Make the "Ddoc\ |Make the "Ddoc" header ||optional in .dd files --- Comment #1 from Andrei Alexandrescu --- Files passed explicitly to dmd for doc processing and carrying the .dd extension don't need to present additional proof that they're ddoc files. The Ddoc header is a mere distraction. --
Re: Socket - handling large numbers of incoming connections
On Monday, 21 December 2015 at 20:53:14 UTC, Jakob Jenkov wrote: On Monday, 21 December 2015 at 20:20:44 UTC, Stefan wrote: How about https://github.com/dcarp/asynchronous ? Asyncio Socket handling is sometimes quite nice. It's performance is okay for nearly no effort and the code looks clean. Details here: http://dcarp.github.io/asynchronous/asynchronous/streams/startServer.html vibe.d also offers a fiber based asyncio way of dealing with sockets. http://vibed.org/docs#tcp-server Maybe it fits your needs. Thanks - but I am primarily looking for a solution without external frameworks. Frameworks have a way of bloating over time. My server uses "poll" for that.
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 20:44:06 UTC, Dmitry wrote: On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Here's another thread about redesign of dlang.org. I'm creating I want say that there are also people who most like the current design. Why? Reasons?
Re: DlangIDE - initial GDB debugger support
On Monday, 21 December 2015 at 18:03:32 UTC, Vadim Lopatin wrote: On Sunday, 20 December 2015 at 13:53:33 UTC, default0 wrote: This is quick progress! Awesome! I finally have some free time on my hands, so I deleted my workspace and tried to set things up following the How to hack on DlangIDE steps again. After doing that and trying to compile on Debug/Win32 I get output with a linker error: ... Any help in somehow getting this all to build would be much appreciated. Oh and of course "dub run" works just fine. For me, Visual Studio 2015 Community Edition + recent Visual D works ok. Try to create some helloworld project using VisualD and build it. Does it work? Clone dlangui and dlangide into the same directory (!!!) Inside dlangui directory create directory /deps and clone dependencies into it (as described in readme). Open dlangui/dlangui-msvc.sln In workspace, select dlangide as a startup project. Build dlangide. As well you can try to build other projects (e.g. dmledit, tetris, example1) - does it work? Simple Hello World project compiles and runs okay. I did do that. My directory structure is like this: DCode/dlangide DCode/dlangui DCode/dlangui/deps/ Which I assume is what you are describing. I just tried opening the setup I had from last time (ie dlangui-msvc.sln) and compile that (startup project set and all), now I get http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : OUT OPTLINK : Error 12: Number Overflow : Building Debug\dlangide.exe failed! I'm starting to think that either my VS or VD installation is cursed (I recently reinstalled VS though, so that shouldn't be it, maybe VD? But it generally works and I do have the latest stable version of it). I redid my setup again right now, though, but apparently the current master has some compiler errors: src\dlangui\core\files.d(264): Error: cannot implicitly convert expression (lastSlash + 1LU) of type ulong to uint src\dlangui\core\files.d(354): Error: cannot implicitly convert expression (start) of type ulong to uint. After crudely fixing these with cast(uint) I got it to build though. So, something about my computer is definitely cursed (I ran the EXACT same commands as always - basically straight copy-paste from the Readme in DlangIDE and I didn't notice any changes to this file since I first did the setup). Anyhow, it finally builds! \o/ Thanks a lot for the help and putting up with my incompetence at diagnosing issues through this, will probably start hacking away on things as time permits :-)
[Issue 15466] New: Incorrect result for 'real'
https://issues.dlang.org/show_bug.cgi?id=15466 Issue ID: 15466 Summary: Incorrect result for 'real' Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: acehr...@yahoo.com I was able to reduce the code to the following, which involves std.datetime.benchmark. However, I have not investigated whether this is a compiler or Phobos bug. Hence the vague subject. :( The bug manifests itself only if the four conditions are satisfied in the reduced code (-O, -inline, etc. do not make any difference): import std.stdio; import std.datetime; alias T = real; // Must be 'real' enum testCount = 7; // Must be > 6 T foo() { // Must return a value return 42; } void main() { // Must cast to void const m = benchmark!(() => cast(void)foo)(testCount); writeln(m[0].msecs); } The output of the program (test measurement) is not 0 (or a very small number of milliseconds) as one would expect: -9223372036854775808 Ali --
Re: Socket - handling large numbers of incoming connections
V Mon, 21 Dec 2015 20:53:14 + Jakob Jenkov via Digitalmars-d-learnnapsáno: > On Monday, 21 December 2015 at 20:20:44 UTC, Stefan wrote: > > How about https://github.com/dcarp/asynchronous ? Asyncio > > Socket handling is sometimes quite nice. It's performance is > > okay for nearly no effort and the code looks clean. > > Details here: > > http://dcarp.github.io/asynchronous/asynchronous/streams/startServer.html > > > > vibe.d also offers a fiber based asyncio way of dealing with > > sockets. > > http://vibed.org/docs#tcp-server > > > > Maybe it fits your needs. > > Thanks - but I am primarily looking for a solution without > external frameworks. Frameworks have a way of bloating over time. Use vibe.d or other library for async io (libasync). If you want to reinvent the wheel you can use kqueue(https://github.com/D-Programming-Language/druntime/blob/1f957372e5dadb92ab1d621d68232dbf8a2dbccf/src/core/sys/freebsd/sys/event.d) for bsd, epoll(https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/linux/epoll.d) for linux and "I do not use windows" for windows.
Re: Socket - handling large numbers of incoming connections
On Monday, 21 December 2015 at 23:17:45 UTC, Daniel Kozák wrote: If you want to reinvent the wheel you can use It isn't really reinventing the wheel to just use an alternate library... it isn't like the bundled functions with the OS are hard to use and you really should understand how they work anyway to write efficient programs.
ndslice of an array structure member?
I'm trying to learn ndslice. It puzzles me why t3 compiles ok, but t4 causes a compiler error in the example below. Should I be able to slice a struct member that is an array? import std.stdio; import std.experimental.ndslice; import std.experimental.ndslice.iteration: transposed; struct sample{ ulong [10] core_ctr; } struct block{ ulong[60] samples; } void main() { auto a1 = new sample[60]; auto t3 = a1.sliced!(ReplaceArrayWithPointer.no)(3,4,5); auto b1 = new block; auto t4 = b1.samples.sliced!(ReplaceArrayWithPointer.no)(3,4,5); } == results in error Building D project: nd4 Running: "C:\Program Files\dub\dub.exe" build Performing "debug" build using dmd for x86. dip80-ndslice 0.8.4: target for configuration "library" is up to date. nd4 ~master: building configuration "application"... src\app.d(16,58): Error: template std.experimental.ndslice.slice.sliced cannot deduce function from argument types !(cast(Flag)false)(ulong[60], int, int, int), candidates are: C:\Users\rlxv10\AppData\Roaming\dub\packages\dip80-ndslice-0.8.4\source\std\experimental\ndslice\slice.d(39,6): std.experimental.ndslice.slice.sliced(Flag mod = ReplaceArrayWithPointer.yes, Range, Lengths...)(Range range, Lengths lengths) if (!isStaticArray!Range && !isNarrowString!Range && allSatisfy!(isIndex, Lengths) && Lengths.length) C:\Users\rlxv10\AppData\Roaming\dub\packages\dip80-ndslice-0.8.4\source\std\experimental\ndslice\slice.d(47,6): std.experimental.ndslice.slice.sliced(Flag mod = ReplaceArrayWithPointer.yes, uint N, Range)(Range range, auto ref size_t[N] lengths, size_t shift = 0) if (!isStaticArray!Range && !isNarrowString!Range && N) C:\Users\rlxv10\AppData\Roaming\dub\packages\dip80-ndslice-0.8.4\source\std\experimental\ndslice\slice.d(116,1): std.experimental.ndslice.slice.sliced(Names...) if (Names.length && !anySatisfy!(isType, Names) && allSatisfy!(isStringValue, Names)) dmd failed with exit code 1. ^^^ Terminated, exit code: 2 ^^^
Re: ndslice and limits of debug info and autocompletion
On Tuesday, 22 December 2015 at 00:21:16 UTC, Jay Norwood wrote: import std.experimental.ndslice.iteration: transposed; I don't use visualD so I can't help you there, but I wanted to point out that this import is unnecessary.
Packt ebooks are currently $5.00
All Packt ebooks are currently only $5.00, including pre-order of D Web Development, Learning D, and D Cookbook. https://www.packtpub.com/web-development/d-web-development https://www.packtpub.com/application-development/learning-d https://www.packtpub.com/application-development/d-cookbook
Re: ndslice of an array structure member?
On Monday, 21 December 2015 at 23:59:07 UTC, Jay Norwood wrote: I'm trying to learn ndslice. It puzzles me why t3 compiles ok, but t4 causes a compiler error in the example below. Should I be able to slice a struct member that is an array? import std.stdio; import std.experimental.ndslice; import std.experimental.ndslice.iteration: transposed; struct sample{ ulong [10] core_ctr; } struct block{ ulong[60] samples; } void main() { auto a1 = new sample[60]; auto t3 = a1.sliced!(ReplaceArrayWithPointer.no)(3,4,5); auto b1 = new block; auto t4 = b1.samples.sliced!(ReplaceArrayWithPointer.no)(3,4,5); } The problem is that t3 is slicing a1 which is a dynamic array, which is a range, while t4 is trying to slice a static array, which is not a range. The ranges primitive popFront mutates the length of the range, so static arrays cannot be used as ranges. But, if you take a slice of b1.samples, you can use that as a range. auto t4 = b1.samples[].sliced!(ReplaceArrayWithPointer.no)(3,4,5); See the section on ranges on this page for more general info on ranges: http://dlang.org/overview.html
Re: Socket - handling large numbers of incoming connections
On Monday, 21 December 2015 at 21:32:55 UTC, Jakob Jenkov wrote: My server uses "poll" for that. Okay, how does that work? How do I use "poll" in D? Link? Code example? The same as in C [1]. Just change #include to import core.sys.posix.poll; [1] http://linux.die.net/man/2/poll
ndslice and limits of debug info and autocompletion
I'm trying to determine if the debugger autocompletion would be useful in combination with ndslice. I find that using visualD I get offered no completion to select core_ctr or epu_ctr where epu_ctr is used in the writeln below. I take it this either means that there is some basic limitation in the debug info, or else VisualD just punts after some number of array subscripts. The code builds and executes correctly ... but I was hoping the debugger completion would help out with an exploratory mode using compiled code. import std.stdio; import std.experimental.ndslice; import std.experimental.ndslice.iteration: transposed; struct sample{ ulong [10] core_ctr; ulong [32] epu_ctr; } void main() { auto a1 = new sample[60]; auto t3 = a1.sliced!(ReplaceArrayWithPointer.no)(3,4,5); writeln(t3[0][0][0].epu_ctr); }
Re: ndslice and limits of debug info and autocompletion
The autocompletion doesn't work here to offer epu_ctr in the writeln statement either, so it doesn't seem to be a problem with number of subscripts. writeln(a1[0]. does offer epu_ctr for completion at the same place. import std.stdio; import std.experimental.ndslice; import std.experimental.ndslice.iteration: transposed; struct sample{ ulong [10] core_ctr; ulong [32] epu_ctr; } void main() { auto a1 = new sample[60]; auto t3 = a1.sliced!(ReplaceArrayWithPointer.no)(60); writeln(t3[0].epu_ctr); }
Re: C string to D without memory allocation?
On Monday, December 21, 2015 05:43:59 Jakob Ovrum via Digitalmars-d-learn wrote: > On Monday, 21 December 2015 at 05:41:31 UTC, Shriramana Sharma > wrote: > > Rikki Cattermole wrote: > > > >> string myCString = cast(string)ptr[0 .. strLen]; > > > > Thanks but does this require that one doesn't attempt to append > > to the returned string using ~= or such? In which case it is > > not safe, right? > > Growing operations like ~= will copy the array to a GC-allocated, > druntime-managed array if it isn't one already. Exactly. As long as the GC has not been disabled, that there is sufficient memory to allocate, and that appending elements does not result in an exception being thrown (which it wouldn't with arrays of char) ~= should always work. When ~= is used, the runtime looks at the capacity of the dynamic array to see whether it has enough room to grow to fit the new elements. If it does, then the array is grown into that space. If it doesn't, then a block of GC memory is allocated, the elements are copied into that memory, and the dynamic array is set to point to that block of memory. Whether the array is pointing to a GC-allocated block of memory or not when ~= is called is irrelevant. If it isn't, all that means is that the array's capacity will be 0, so it's going to have to reallocate, whereas if it were GC-allocated, it might have enough capacity to not need to reallocate. In either case, the operation will work. - Jonathan M Davis
Re: Slicing AliasSeq-s
On Monday, 21 December 2015 at 09:06:08 UTC, Shriramana Sharma wrote: http://dlang.org/spec/template.html#TemplateTupleParameter Apart from the obvious need for changing the references to tuples to alias sequences (for which I'm working on a PR), my question: Both the above page and http://dlang.org/phobos/std_meta.html refer to "slicing" alias sequences. In D slicing means just creating another reference to the same memory as the sliced object. Given that AliasSeq-s cannot be written to[*], it's not possible for me to test whether it's actually sliced or a new AliasSeq with the same elements is created. Otherwise I could do something like this: alias A = [int, 2, symbol]; alias B = A[1 .. $]; alias C = A[0 .. $ - 1]; A[1] = 3; // not possible static assert(B[0] == 3 && C[1] == 3); So out of curiosity I'd like to know how this is implemented in the compiler: as really a slice or a copy? (Posting this to D and not learn since it relates to compiler internals.) I don't know the answer, but I suspect it's a (shallow) copy. Anyway, as you've noticed, there's no observable difference either way, so this is an implementation detail which the documentation shouldn't mention (if this was the intention behind your question).
Re: Redesign of dlang.org
On 2015-12-21 09:12, Sean Campbell wrote: It only removes the border, so that it better integrates with the top menu. The difference between the two seem trivial? Actually it has changed the red color and I think it removes the gloss effect. But the shape of the D and the two moons is the same, which I think is the important part. -- /Jacob Carlborg
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 15:09:06 UTC, Adam D. Ruppe wrote: Dedicated pages is a good idea and can be done trivially with ddoc macros to avoid repetition of the content in the source. It could also be a css :hover dropdown instead of JS, but I hate drop downs on hover so I'd prefer the dedicated pages. We could use the :hover dropdowns as a fallback for the JS, though. It might not be ideal, but isn't that basically the definition of a fallback?
[Issue 8166] retro() of splitter() too
https://issues.dlang.org/show_bug.cgi?id=8166 Jack Stoufferchanged: What|Removed |Added CC||j...@jackstouffer.com --- Comment #2 from Jack Stouffer --- Currently, this can be achieved via auto p = std.array.splitter("this is a message", " ").retro(); but it's deprecated and going to be removed at the end of the month. So I don't think adding this feature to the string specific overload of splitter is going to be welcome because it looks like doing it is buggy (I assume, why else would this be deprecated?). Therefore, I think that this should be marked as won't fix. --
Re: DlangIDE - initial GDB debugger support
On Sunday, 20 December 2015 at 13:53:33 UTC, default0 wrote: This is quick progress! Awesome! I finally have some free time on my hands, so I deleted my workspace and tried to set things up following the How to hack on DlangIDE steps again. After doing that and trying to compile on Debug/Win32 I get output with a linker error: ... Any help in somehow getting this all to build would be much appreciated. Oh and of course "dub run" works just fine. For me, Visual Studio 2015 Community Edition + recent Visual D works ok. Try to create some helloworld project using VisualD and build it. Does it work? Clone dlangui and dlangide into the same directory (!!!) Inside dlangui directory create directory /deps and clone dependencies into it (as described in readme). Open dlangui/dlangui-msvc.sln In workspace, select dlangide as a startup project. Build dlangide. As well you can try to build other projects (e.g. dmledit, tetris, example1) - does it work?
Re: Make Simple Things Hard to Figure out
On Monday, 21 December 2015 at 16:20:18 UTC, Adam D. Ruppe wrote: On Monday, 21 December 2015 at 13:51:57 UTC, default0 wrote: The thing I was trying to do was dead simple: Receive a base64 encoded text via a query parameter. So when I read this, I thought you might have missed another little fact... there's more than one base64. I am aware of this and I used Base64URL in my code, as does my frontend :-) Glad you pointed it out though, I really did write my post as if I missed that fact. Yup, normal Base64 encoding uses + and / as characters, which are special in URLs, so often (but not always!), base64 url encoding uses - and _ instead. This isn't D specific, it is just part of the confusing mess that is the real world of computer data. Normal base64 does work in urls, as long as it is properly url encoded. (Got enough encoding yet?!) Oh you can keep going, I'm not that easily scared :D My first instinct was to use google. Tip I tell people at work too: yes, look for it yourself, but if you don't see an answer with a few minutes, go ahead and ask us, drop a quick question in the chatroom. D has one on IRC freenode called #d. I don't have an IRC client set up since I rarely use that, plus an IRC is always kind of "out of the way". It's good to know, but if you're a beginner trying to learn about basics of a language, standalone tutorials and/or easy-to-understand documentation with examples are miles better :-) There is a decode function, but I couldn't quite figure out what it did or how I was supposed to use it, if it did what I wanted it to - no examples. std.utf.decode will take a few chars and decode them into a single wchar or dchar. Take the character “ for example, the double curly quote that Microsoft Word likes to put in when you type " on your keyboard. “ has several different encodings as bytes. http://www.fileformat.info/info/unicode/char/201c/index.htm UTF-8 (hex) 0xE2 0x80 0x9C (e2809c) UTF-16 (hex)0x201C (201c) UTF-32 (hex)0x201C (201c) UTF-8 is char in D. That curly quote takes up three chars: char[] curlyQuote = [0xE2, 0x80, 0x9C]; size_t idx = 0; dchar curlyQuoteAsDchar = decode(curlyQuote[], idx); assert(curlyQuoteAsDchar == '\u201c'); Nice explanation, thanks. I wish the documentation could have taught me that information as clearly as you did :-) There's one big exception though... the validate function. http://dlang.org/phobos/std_utf.html#validate That works on a whole string and validates the whole sequence of chars as being valid utf8, throwing an exception if it isn't. (Weird behavior btw, I think I would have preferred `isValid` returning bool, or `validate` taking bytes and returning chars - which would be exactly what you wanted - but it returns void and throws instead :( ) Well, a ubyte[] isn't exactly an array of code-points, so just calling validate and casting is confusing (even though logical if you think about it for a second). Having an API like bool tryDecode(ubyte[], char[] outBuf) except more rangified and an analogous char[] decode(ubyte[]) (also rangified) would be much easier to understand (and I would argue use, too). The task I'm trying to do is explicitly not "casting this byte array to code points" but "decode this byte array into code points". That an implementation of this functionality may simply cast the original array is an implementation detail, so going for cast(string)ubytes in the first place is kind of counter-intuitive (since I did have some D exposure for a while I managed to figure that one out without too much of a hassle though). This stuff btw is pretty confusing, there's an awful lot to know about text encoding, so don't feel bad if it makes very little sense to you. I spent like four pages in my book introducing unicode as part of the discussion on D strings... and still, that left out a lot of things too... Text encoding in general makes sense to me - I don't usually have trouble dealing with it. It was just hard to navigate the information available on how to write the code to do the necessary things in D :-) After that I moved on to std.string. It only had one function that seemed somewhat interesting - assumeUTF. After reading through the docs, it failed my criteria since it had no validation - as its name states, it simply assumes that whatever you give it is correctly encoded. I didn't expect much here anyways, it would have been an odd place to put this functionality. Ooooh you're close though. If you did --- import std.base64, std.string, std.utf; auto utf = assumeUTF(Base64.decode(it)); validate(utf); --- you'd probably get what you wanted... That plus some text explaining the details should be the answer to the SO question. http://stackoverflow.com/questions/34401744/convert-ubyte-to-string-in-d is where I asked. Would be awesome if you could respond there! Really inconvenient. It then goes on to state
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 17:37:11 UTC, Andrei Alexandrescu wrote: That's a large leap. I suggest using Ddoc instead of Sass compact CSS files, see the existing instance at https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd. Why is there a $(COLON) macro in there? Is it because of the silly section feature of ddoc? Why does it matter at the bottom of the file but not in the rest of it? Using text macros in CSS is something I support. Indeed, my css expander does them too, but most of ddoc's other features I fear are wrong like the colon thing, and it lacks stuff that is specifically useful in css itself like nested selectors. (BTW, your _=\n\n pattern is useless, it changes nothing and should be removed.) While I do like using css helper programs... here, I'd prefer to just keep the file simple. Let's just write standard CSS, understanding that it has a few warts, but then getting the benefit of a very easy to understand file for anyone to look at, no need to build it, and the possibility of using standard css tools on it. CoffeeScript sounds like a nice thing to add and is from what I've heard reasonably stable. Please don't. Coffeescript has distinctly negative value to me, including complicating the build process even more, and just being a PITA to write. Again, I'd prefer to keep the javascript files simple too, no processors on them. It's not like we need that much of it on this site anyway.
Re: Make Simple Things Hard to Figure out
On Monday, 21 December 2015 at 18:02:55 UTC, default0 wrote: I don't have an IRC client set up since I rarely use that, plus an IRC is always kind of "out of the way". Just click this link: http://webchat.freenode.net/?channels=d type in a random name, click the captcha checkbox and go! I'll come back to the rest later, just want to highlight the existence of that webchat link for everyone.
[Issue 8166] retro() of splitter() too
https://issues.dlang.org/show_bug.cgi?id=8166 --- Comment #3 from Jack Stouffer--- (In reply to Jack Stouffer from comment #2) > Currently, this can be achieved via > > auto p = std.array.splitter("this is a message", " ").retro(); > > but it's deprecated and going to be removed at the end of the month. So I > don't think adding this feature to the string specific overload of splitter > is going to be welcome because it looks like doing it is buggy (I assume, > why else would this be deprecated?). Therefore, I think that this should be > marked as won't fix. Wait, my mistake. Doing auto p = std.array.splitter("this is a message", ' ').retro(); instead is perfectly fine. The string specific overload can be changed to use the first overload of splitter internally. --
Re: Redesign of dlang.org
On 2015-12-21 00:20, Iain Buclaw via Digitalmars-d wrote: I'd like to see a more complete menu in the new layout to get a better feel for it. It certainly looks the part with the small set of key features of dlang on display. But how will it fair showing the entire language or library reference list items? There are currently links to the language reference and standard library in the menu (Documentation). But there won't be any submenus, as it is on the current version of dlang.org. Possibly a left menu would be a good fit for this. That is only present on the language reference and standard library pages. -- /Jacob Carlborg
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: The redesign is just a mock of the start page and a Phobos documentation page. No Ddoc, vibe.d or similar is used. Only HTML, JavaScript and Less (CSS). It's not a functioning site, it's only to show the design. Nice! A few suggestions: 1. Red is an attention-seeking colour, so it usually a good idea to use it more sparingly. But if you use it on links, make sure you only use it on "clickable" items. Right now some icons and text are red, but non-clickable. 2. Align the elements. Make the logo horizon unclipped in the horizontal direction (complete the sphere) and implement it as part of the background, then align the left edge of the D logo with the left edge of the content.
Re: C string to D without memory allocation?
On Monday, 21 December 2015 at 08:35:22 UTC, Jonathan M Davis wrote: There's also fromStringz that Jakob suggests using elsewhere in this thread, but that really just boils down to return cString ? cString[0 .. strlen(cString)] : null; So, using that over simply slicing is primarily for documentation purposes, though it does make it so that you don't have to call strlen directly or check for null before calling it. To add to this, the main motivation behind `fromStringz` is that `cString` is often a non-trivial expression, such as a function call. With `fromStringz`, this expression can always be put in the argument list and it will only be evaluated once. Otherwise a variable has to be added: auto cString = foo(); return cString[0 .. strlen(cString)];
Make Simple Things Hard to Figure out
Hi So today I tried setting up vibe.d and see how that all works out. Doing the initial setup was easy enough (dub is amazingly convenient!) and I had a "Hello World" server up and running in about 10 minutes. Sweet. After that, I started looking into vibes URLRouter - also easy enough, documented good enough to get the gist of it without having to spend a long time doing anything. After that, it all went downhill for me. First off, I'm very new to D, I'm also very new to lots of the concepts D implements/exposes (low-level stuff, most the paradigms, etc). This is mostly a description of what I did to attempt solving my problems and how that did or did not work out. Maybe this can help guide decisions on what things to clarify and where. The thing I was trying to do was dead simple: Receive a base64 encoded text via a query parameter. After digging around the HTTPRequest vibe exposes, I quickly found the query-dictionary, so to get my base64 encoded text, all I had to do was query["data"]. Easy, convenient. To decode the base64 there is something in the std-lib. Awesome. So all I need to do is Base64URL.decode(query["data"]) and I'm done. Or so I thought. Naturally, the decode function returns a ubyte[], so I need to somehow decode the ubyte[] to a char[] (since I'm using a frontend-library that encodes base64 text as utf8). My first instinct was to use google. The first thing that came up was unsurprisingly std.utf. After skimming through the functions I couldn't really make any function out that would accept a simple ubyte[] (or range of ubyte) and output a simple string or char[] (or range of chars). Disappointing. Maybe I missed something? There is a decode function, but I couldn't quite figure out what it did or how I was supposed to use it, if it did what I wanted it to - no examples. After that I moved on to std.string. It only had one function that seemed somewhat interesting - assumeUTF. After reading through the docs, it failed my criteria since it had no validation - as its name states, it simply assumes that whatever you give it is correctly encoded. I didn't expect much here anyways, it would have been an odd place to put this functionality. On to the third package that seemed related to my problem: std.encoding. The function that seemed most obvious to do what I wanted to do was called "decode". Well... it decodes a single code point. Really inconvenient. It then goes on to state that it supersedes std.utf.decode, but I don't remember reading any notice in std.utf.decode that it actually was superseded and I shouldn't even really bother trying to learn about it, weird but okay. It also helpfully notes that codePoints() is more convenient than it. So let's look at that. Alright, the example shows that codePoints() wants a string or a range of chars. I only have a range of bytes, and I would like to validate it, not type-system-breaking-cast it. Doesn't seem like this function is helpful, but maybe I'm missing something. Scrolling a bit further, there is an EncodingScheme class. It has a neat function, isValid. So after reading a bit on it, what I ended up with was: EncodingScheme.create("UTF-8").isValid(decodedBase64) followed by a type-system-ignoring cast from ubyte[] to char[] (since I now know it is valid so this cast is fine). All in all, including the explicit error handling required by isValid this has taken about an hour of research and 7 lines of code. In a language with far less abstraction capabilities (namely C#) the following would've done the trick, throwing an exception on failure: Encoding.UTF8.GetString(Convert.FromBase64String("base64")) Looking back the things that really slowed me down here were: -The lack of an answer on StackOverflow to this very specific problem (otherwise this would have been the job of 5 minutes, if even) -The lack of examples for specific functions in the documentation -The relative difficulty navigating the documentation (often times 10 or more functions on a single page) as well as very densely written documentation (I often find myself reading sentences twice or more just to extract all information from them, since single sentences often contain multiple important facts) As this isn't really a question for Learn I'm not sure if it fits here. This is more of a "This is how I went about trying to learn X. These are the problems I encountered. Ideas to improve?" but I guess I might as well post it here. So with that in mind, any ideas to improve the situation (that do not require 500 man-decades of work)?
Re: Template specialization using traits?
Thanks all for your replies. One question: Jonathan M Davis wrote: > Alternatively, you can use static if, though you're only dealing > with one template in that case. e.g. But if we wanted to deprecate one of the alternatives, then we necessary need to declare two templates with the same name and complementary constraints right? -- Shriramana Sharma, Penguin #395953
Re: C string to D without memory allocation?
Jonathan M Davis via Digitalmars-d-learn wrote: > If it isn't, all that means is that the > array's capacity will be 0, so it's going to have to reallocate So it's safe to return a string produced by fromStringz without having to worry that the user would append to it? Then why is it marked @system? Only because one cannot be sure that the input point refers to a valid null-terminated string? -- Shriramana Sharma, Penguin #395953
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 05:14:34 UTC, Vladimir Panteleev wrote: On Sunday, 20 December 2015 at 13:50:53 UTC, Jacob Carlborg wrote: On 2015-12-20 06:12, Charles wrote: kind of a neat project here... mind if I help out? Sure, that would be great. Although I don't really want to do anything until Walter and Andrei approve the design. Worth noting that this design modifies the logo, which Walter vetoed during the previous redesign. It only removes the border, so that it better integrates with the top menu. The difference between the two seem trivial? This new design for dlang.org is much easier to use. I hope it replaces the current one.
Deimos recommendation still official?
http://dlang.org/spec/interfaceToC.html refers one to Deimos (https://github.com/D-Programming-Deimos) to look for existing bindings to C libraries. Is this recommendation still valid? I ask because less than one fourth of the repos there seem to have been active in this year 2015. Or is it just because the other C libraries haven't changed (!)... -- Shriramana Sharma, Penguin #395953
Re: C string to D without memory allocation?
On Monday, December 21, 2015 18:39:32 Rikki Cattermole via Digitalmars-d-learn wrote: > size_t strLen = ...; > char* ptr = ...; > > string myCString = cast(string)ptr[0 .. strLen]; > > I can't remember if it will include the null terminator or not, but if > it does just decrease strLen by 1. Casting to string is almost always wrong. Casting anything to immutable is almost always wrong. If you want to use C strings in D without allocating, they're going to have to be const(char)[], not immutable(char)[], which is what string is. Otherwise, you risk violating the type system. Slicing explicitly like this can work just fine, and it will result in either char[] or const(char)[] depending on whether the pointer is char* or const char*, but the cast should _not_ be done. There's also fromStringz that Jakob suggests using elsewhere in this thread, but that really just boils down to return cString ? cString[0 .. strlen(cString)] : null; So, using that over simply slicing is primarily for documentation purposes, though it does make it so that you don't have to call strlen directly or check for null before calling it. Regardless, do _not_ cast something to immutable if it's not already immutable. It's just begging for trouble. - Jonathan M Davis
[Issue 5753] Disallow map() of void function
https://issues.dlang.org/show_bug.cgi?id=5753 Ryuichi OHORIchanged: What|Removed |Added Status|RESOLVED|REOPENED CC||r.97...@gmail.com Resolution|FIXED |--- --- Comment #7 from Ryuichi OHORI --- It seems that void lambda is not disallowed. DMD2.069 compiles the code below, which I think must not: void f(T)(T x){} unittest { import std.algorithm : map; static assert (!__traits(compiles, [1].map!f)); static assert ( __traits(compiles, [1].map!(e => f(e; } --
Re: Small minesweeper game in D
On Sunday, 20 December 2015 at 02:11:58 UTC, Adam D. Ruppe wrote: code here: http://arsdnet.net/dcode/minesweeper.d [...] On Ubuntu 64 bit: $ dmd minesweeper.d simpledisplay.d color.d simpledisplay.d(4477): Error: cannot implicitly convert expression (XCreatePixmapCursor(this.display, pm, pm, & blackcolor, & blackcolor, 0u, 0u)) of type ulong to int $ dmd --version DMD64 D Compiler v2.069.2 I casted the problem away with cast(int)XCreatePixmapCursor(...) to play a couple games. Not really solving the problem though... Nice work though! 'Tis very cool. The game code is very simple to follow too. I'll try making a simple game using simpledisplay over the christmas. It looks quite nifty!
[Issue 15464] New: Template parameter-dependent attributes
https://issues.dlang.org/show_bug.cgi?id=15464 Issue ID: 15464 Summary: Template parameter-dependent attributes Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: and...@erdani.com Related forum discussion: http://forum.dlang.org/post/n4s66a$i9u$1...@digitalmars.com Attributes should be allowed to depend on template parameters. Without this, their usefulness is seriously and artificially limited. Example in the post: void insertFrontMany(C, R)(C container, R range) @BigO(complexity!(C.insertFront) * linearTime) { ... } currently does not compile. Walter and I discussed this language change and we're preapproving it. Per Timon Gehr's reply, implementation could achieved the feature by means of a lowering. --
Re: Redesign of dlang.org
On Sunday, 20 December 2015 at 13:50:53 UTC, Jacob Carlborg wrote: On 2015-12-20 06:12, Charles wrote: kind of a neat project here... mind if I help out? Sure, that would be great. Although I don't really want to do anything until Walter and Andrei approve the design. On that - have you had any contact / discussion with Walter and/or Andrei about this? I recall there was a thread on this very subject close to a year ago but can't remember if there was any decisions made.
[Issue 15464] Template parameter-dependent attributes
https://issues.dlang.org/show_bug.cgi?id=15464 Andrei Alexandrescuchanged: What|Removed |Added Keywords||preapproved --
Re: Redesign of dlang.org
On 19.12.2015 15:33, Jacob Carlborg wrote: http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM I know you wait for Walter's and Andrei's approval on this before investing more work. That's very reasonable. Luckily, I'm not so reasonable ;) http://d-ag0aep6g.rhcloud.com/ On GitHub if people want to play around with it: https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign That's a full clone of dlang.org in the new style. I just pasted it over the old style, and hacked around on top of it until it worked, more or less. It's a quick and dirty showcase. I touched everything, but polished nothing. There are more rough edges than smooth ones. I changed various details from the mock-up (logo, icons, text, ...), so this is not a perfect port. In particular, I tried not to throw out content and features from the current dlang.org. For now, that is. The home page is pretty crowded, and the menu bar definitely needs to be streamlined. By the way, I'm not sold on that font. I think I'd prefer a sans-serif.
Re: Template parameter-dependent attributes
On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote: [snip] I submitted https://issues.dlang.org/show_bug.cgi?id=15464, which is preapproved. There is a bit of a sense of urgency to it - it blocks the bigo library proposal and an article. Takers? Andrei
Re: Redesign of dlang.org
On 12/21/2015 08:58 AM, anonymous wrote: On 19.12.2015 15:33, Jacob Carlborg wrote: http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM I know you wait for Walter's and Andrei's approval on this before investing more work. That's very reasonable. Luckily, I'm not so reasonable ;) http://d-ag0aep6g.rhcloud.com/ On GitHub if people want to play around with it: https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign That's a full clone of dlang.org in the new style. I just pasted it over the old style, and hacked around on top of it until it worked, more or less. It's a quick and dirty showcase. I touched everything, but polished nothing. There are more rough edges than smooth ones. I changed various details from the mock-up (logo, icons, text, ...), so this is not a perfect port. In particular, I tried not to throw out content and features from the current dlang.org. For now, that is. The home page is pretty crowded, and the menu bar definitely needs to be streamlined. By the way, I'm not sold on that font. I think I'd prefer a sans-serif. Nice! A few questions. What are the changes to the tooling used and the build process? Is there a reasonable decay if javascript is disabled? Can we defer any changes to the logo so we don't get sidetracked in this? Just scale the existing logo to fit and defer any changes to it to later. Thanks, Andrei
Re: D Structs(Enums) to Typescript Interfaces(Enums)
Update: It now also generates functions that call the vibe.d rest service in typestrict.
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 13:58:30 UTC, anonymous wrote: I know you wait for Walter's and Andrei's approval on this before investing more work. That's very reasonable. Luckily, I'm not so reasonable ;) http://d-ag0aep6g.rhcloud.com/ Huh, that's mildly buggy but I'm actually pretty impressed with it. If it was my decision, I think I'd greenlight this then do a few little tweaks myself on staging.
Re: D Consortium as Book / App Publisher... ?
On Sunday, 20 December 2015 at 21:09:31 UTC, Jakob Jenkov wrote: I was thinking that the D Consortium could function as publisher of D books too, for the following (obvious) reasons: [...] All decent ideas- I've been thinking recently about setting up a paid blog for articles by D devs- but without someone to explore and push them, they will go nowhere, ie somebody has to do the work of wrangling the writers and docs.
Re: How is D doing?
Thank you for your insights. I've decided to stick with D. A friend of mine told me that my post might have sounded a bit trollish i assure you that was not the case. Also i never used any mailing lists so wasn't sure who to reply to so i replied to myself.
Re: How is D doing?
On 22/12/15 4:43 PM, ShinraTensei wrote: Thank you for your insights. I've decided to stick with D. A friend of mine told me that my post might have sounded a bit trollish i assure you that was not the case. No no it is fine for D.learn. It shows that you are willing to learn actually try instead of trolling. Also i never used any mailing lists so wasn't sure who to reply to so i replied to myself. No worries. You're welcome to join us on Freenode #d.
Re: Set color to a single point in Cairo
On Sunday, 20 December 2015 at 11:16:06 UTC, TheDGuy wrote: On Sunday, 20 December 2015 at 01:17:50 UTC, Basile B. wrote: On Saturday, 19 December 2015 at 14:16:23 UTC, TheDGuy wrote: is it possible to set the color of a single pixel with Cairo? Not like you would do with a classic canvas (2d grid), because colors are applied with `cairo_fill()` and `cairo_stroke()` on a particular path. but you can define a path that represents a single pixel and fill it: ``` cairo_rectangle (cr, x, y, 1, 1); // 1 pix rectangle cairo_set_source_rgba (cr, 0, 0, 0, 1); // color cairo_fill (cr); // fill the rectangle with source rgba ``` However cairo is node made to be used like this. The workflow is usually more based on stacked layers (1 layer = 1 path) with different filling, different transparency. Thanks for your answer, but a bit disappointing that cairo doesn't offer a real "setPixel" function :( Vectorial graphics are like that, they are at a higher level than, for, example, open GL. My experience with such libraries is a bit dusty (for example I made this when I was younger: http://4.bp.blogspot.com/-cmzQAHlaE50/TxcG3vEAA9I/QS0/qFxVLeo1JGU/s1600/GrainPlot%2Bv.2.4.jpg, here it plots some variable shape segments defined by x³-ax²+ax) but I clearly remember that you **never** need to draw a single pixel. A point is either part of the fill or of the border, I mean **always**. However not that internaly cairo uses "pixman" but IDK if you can access it directly. (see http://www.pixman.org/)
Re: How is D doing?
On Tuesday, 22 December 2015 at 03:30:32 UTC, ShinraTensei wrote: my question is weather the D is actually used anywhere D rox and is used by a lot of people. are there chances of it dying anytime soon. It can never die as long as we remember it...
How is D doing?
I recently noticed massive increase in new languages for a person to jump into(Nim, Rust, Go...etc) but my question is weather the D is actually used anywhere or are there chances of it dying anytime soon. So far I've tried a while bunch of languages and i do like D the most, since i am used to C/C++ syntax also Java a bit, but i don't like Java. Now i'm trying to can C/C++ and get accustomed to something more modern so D is my choice unless its a dead language. I'm not looking into D for job opportunities. Just writing programs for my own amusement and maybe even profit some day.
Re: ndslice of an array structure member?
On Tuesday, 22 December 2015 at 01:13:54 UTC, Jack Stouffer wrote: The problem is that t3 is slicing a1 which is a dynamic array, which is a range, while t4 is trying to slice a static array, which is not a range. ok, thanks. I lost track of the double meaning of static ... I normally think of static as variables with static preceding the type, allocated at start-up, but in this case it refers to structure members that will have a fixed size after the allocation.
Re: How is D doing?
On 22/12/15 4:30 PM, ShinraTensei wrote: I recently noticed massive increase in new languages for a person to jump into(Nim, Rust, Go...etc) but my question is weather the D is actually used anywhere or are there chances of it dying anytime soon. So far I've tried a while bunch of languages and i do like D the most, since i am used to C/C++ syntax also Java a bit, but i don't like Java. Now i'm trying to can C/C++ and get accustomed to something more modern so D is my choice unless its a dead language. I'm not looking into D for job opportunities. Just writing programs for my own amusement and maybe even profit some day. D is most certainly not a dead language. We grow fairly slowly, but we are most certainly growing. We play the long game, slow but steady.
Re: Ddoc getting better: no more need for them pesky $(P ...)s
Just a note, in my docs I used DDOC_BLANKLINE= and it more-or-less works... but indeed, one of these ways would be nice to have.
Re: Voting For std.experimental.ndslice
Yes
Re: Redesign of dlang.org
On 2015-12-21 18:37, Andrei Alexandrescu wrote: That's a large leap. I suggest using Ddoc instead of Sass compact CSS files, see the existing instance at https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd. CoffeeScript sounds like a nice thing to add and is from what I've heard reasonably stable. We can't make the site depend on dub at this time. There have been situations in the past when dub wouldn't build and nobody was available to work on it. At that time only the alternate documentation got broken, but if the site depends on it we're looking at catastrophic failure. I have no interest in using Ddoc. If that's a requirement we can close down the redesign idea completely. Just defer it and we're good. I think it looks pretty bad and will ruin the design. -- /Jacob Carlborg
Re: How is D doing?
On 12/21/2015 07:30 PM, ShinraTensei wrote: > I'm not looking into D for job opportunities. Even so, we may start hearing more and more D job openings. I've heard about yet another San Francisco startup where individual teams pick their own language and one of their teams uses D. (I don't know which company yet.) Ali
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? [1] http://forum.dlang.org/thread/ejpuwwlutklvlozyf...@forum.dlang.org [2] http://forum.dlang.org/thread/fdbnecqbemseocwzg...@forum.dlang.org [3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM IMHO design is nice but on homepage there's too much to read. It is disorienting for a newcomer. I think you should reduce informations given on the main page. And there's nothing that catch the focus: I think you should highlight one part of that page using a bigger font size, for example. You need to drive a new user that comes there. Colors are good but on documentation they're too light. Andrea
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 08:47:48 UTC, Ola Fosheim Grøstad wrote: idea to use it more sparingly. But if you use it on links, make sure you only use it on "clickable" items. I personally prefer black text with coloured underline on links. Easier on the eyes: http://www.w3.org/
Slicing AliasSeq-s
http://dlang.org/spec/template.html#TemplateTupleParameter Apart from the obvious need for changing the references to tuples to alias sequences (for which I'm working on a PR), my question: Both the above page and http://dlang.org/phobos/std_meta.html refer to "slicing" alias sequences. In D slicing means just creating another reference to the same memory as the sliced object. Given that AliasSeq-s cannot be written to[*], it's not possible for me to test whether it's actually sliced or a new AliasSeq with the same elements is created. Otherwise I could do something like this: alias A = [int, 2, symbol]; alias B = A[1 .. $]; alias C = A[0 .. $ - 1]; A[1] = 3; // not possible static assert(B[0] == 3 && C[1] == 3); So out of curiosity I'd like to know how this is implemented in the compiler: as really a slice or a copy? (Posting this to D and not learn since it relates to compiler internals.) -- Shriramana Sharma, Penguin #395953
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? Wow. I really like it. Clearly better than the actual design +1 for me.
Template specialization using traits?
Hello. I want to define a template specialization using traits: import std.stdio, std.traits; void func(T)(T t) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } void main() { func(1); } But I'm getting an error saying that the called function matches both. If it were a single type, I know I have to put the specialization as in: void func(T: int)(T t) { writeln(2); } and that works, but how to make it more generic than that? -- Shriramana Sharma, Penguin #395953
Re: Template specialization using traits?
On Monday, 21 December 2015 at 11:12:10 UTC, Jonathan M Davis wrote: On Monday, 21 December 2015 at 11:07:16 UTC, Jonathan M Davis wrote: For your example to work with template constraints, the most straightforward solution would be void func(T)(T t) if(!isIntegral!T) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } Alternatively, you can use static if, though you're only dealing with one template in that case. e.g. void func(T)(T t) { static if(isIntegral!T) writeln(2); else writeln(1); } - Jonathan M Davis Another alternative is: template func(T){ static if( isIntegral!T ){ void func(T t){ writeln( 2 ); } } else{ void func(T t){ writeln( 1 ); } } }
Re: Some feedback on the website.
On 2015-12-21 04:44, Vladimir Panteleev wrote: There is no definitive answer for when something is "good enough" If nobody knows what it takes to make Ddox the default, how do we know that it's not already good enough? but to get you started: https://github.com/rejectedsoftware/ddox/issues Finally :) -- /Jacob Carlborg
Re: Redesign of dlang.org
On 2015-12-21 06:14, Vladimir Panteleev wrote: Worth noting that this design modifies the logo, which Walter vetoed during the previous redesign. Yeah... But as I have tried to explain, it's common for companies to have different version of the same logo for different use cases. I think this stays true to the original one. The key part of the logo is the D and the two moons (or whatever they are), which looks the same on both logos. The Apple's logo for example. It's basically different on each of their products. Different sizes, different colors and so on. What is the same is the shape and that is what people recognize. -- /Jacob Carlborg
Re: Template specialization using traits?
On Monday, December 21, 2015 15:14:20 Shriramana Sharma via Digitalmars-d-learn wrote: > Hello. I want to define a template specialization using traits: > > import std.stdio, std.traits; > void func(T)(T t) { writeln(1); } > void func(T)(T t) if(isIntegral!T) { writeln(2); } > void main() > { > func(1); > } > > But I'm getting an error saying that the called function matches both. If it > were a single type, I know I have to put the specialization as in: > > void func(T: int)(T t) { writeln(2); } > > and that works, but how to make it more generic than that? In D, each template constraint must match exactly once. A template with no template constraint is the same as having a template constraint that's always true. So, you need to alter your template constraints so that for a given template argument, exactly one template constraint is true. There really isn't such a thing as a specialization when dealing with template constraints. Using : like in your second example is the only kind of template specialization that we have. For your example to work with template constraints, the most straightforward solution would be void func(T)(T t) if(!isIntegral!T) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } - Jonathan M Davis
Re: Template specialization using traits?
On Monday, 21 December 2015 at 11:07:16 UTC, Jonathan M Davis wrote: For your example to work with template constraints, the most straightforward solution would be void func(T)(T t) if(!isIntegral!T) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } Alternatively, you can use static if, though you're only dealing with one template in that case. e.g. void func(T)(T t) { static if(isIntegral!T) writeln(2); else writeln(1); } - Jonathan M Davis
Re: Template specialization using traits?
On Monday, 21 December 2015 at 09:44:20 UTC, Shriramana Sharma wrote: Hello. I want to define a template specialization using traits: import std.stdio, std.traits; void func(T)(T t) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } void main() { func(1); } But I'm getting an error saying that the called function matches both. If it were a single type, I know I have to put the specialization as in: void func(T: int)(T t) { writeln(2); } and that works, but how to make it more generic than that? void func(T)(T t) if(!isIntegral!T) { writeln(1); } void func(T)(T t) if(isIntegral!T) { writeln(2); } :)
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? Fantastic. +1. The editable and runnable code on the existing homepage is a nice touch. That should find its way into the new homepage.
Re: Deimos recommendation still official?
On Monday, December 21, 2015 14:03:25 Shriramana Sharma via Digitalmars-d-learn wrote: > http://dlang.org/spec/interfaceToC.html refers one to Deimos > (https://github.com/D-Programming-Deimos) to look for existing bindings to C > libraries. Is this recommendation still valid? I ask because less than one > fourth of the repos there seem to have been active in this year 2015. Or is > it just because the other C libraries haven't changed (!)... A number of C bindings are in Deimos, so anyone looking for C bindings should look there. How much any of them need to be updated, I don't know, but it doesn't hurt to look there regardless, and many C libraries simply don't change much. Regardless, Deimos certainly isn't dead - but remember that what's there for any given project is there primarily because a single developer needed it for one of their own projects and took the time to put it in Deimos for others to use. So, if they don't need more work done on it to do what they're doing, and no one else adds to it, then what's there probably isn't going to change. That doesn't mean that it's not useful though, and if someone needs bindings to be added to it or updated, then they can always create pull requests to do that. - Jonathan M Davis
Re: IAP Tools for D
On Sunday, 20 December 2015 at 21:37:35 UTC, Jakob Jenkov wrote: The designers of HTTP would strongly argue that is a major thing HTTP got right, and is the feature primarily responsible for it huge success. Then why is HTTP 2 moving away from it? And Web Sockets? Clearly, having the choice between keeping state and not keeping state is preferable to HTTP taking that choice away from you. Lots of apps also spend quite an effort to mimic stateful communication on top of HTTP. Sessions? Authentication tokens? Cookies? Caching in the browser? HTML5 Local Storage? No, HTTP did not get "stateless" right. Yep, the whole stateless argument is a complete joke, it has not been true except maybe in the very beginning. HTTP 2 is a huge step forward for this, its binary encoding, and other reasons. Your "fix-the-network" problem is definitely valid. At this point we have mostly focused on ION - the binary object / message format for IAP. However, we have a pretty good idea about how IAP will work on a conceptual level. IAP will have a set of "semantic protocols". Each semantic protocol can address its own area of concern. File exchange, time, RPC, distributed transactions, P2P, streaming etc. You can also define your own semantic protocol to address exactly your specific situation (e.g. the Byzantine Generals Problem - distributed consensus). Everything is not yet in place - but we will get there step by step. Interesting effort, I'll check it out.
Re: ndslice and limits of debug info and autocompletion
On Tuesday, 22 December 2015 at 00:21:16 UTC, Jay Norwood wrote: I'm trying to determine if the debugger autocompletion would be useful in combination with ndslice. I find that using visualD I get offered no completion to select core_ctr or epu_ctr where epu_ctr is used in the writeln below. I take it this either means that there is some basic limitation in the debug info, or else VisualD just punts after some number of array subscripts. The code builds and executes correctly ... but I was hoping the debugger completion would help out with an exploratory mode using compiled code. import std.stdio; import std.experimental.ndslice; import std.experimental.ndslice.iteration: transposed; struct sample{ ulong [10] core_ctr; ulong [32] epu_ctr; } void main() { auto a1 = new sample[60]; auto t3 = a1.sliced!(ReplaceArrayWithPointer.no)(3,4,5); writeln(t3[0][0][0].epu_ctr); } I don't know how VisualD works, but to provide auto-completion it should be able to compile a source code for autocompletion information, because simple analyzer would not work with variadic templates like opIndex(Indexes...)(Indexes indexes). Nitpick: t3[0][0][0] is much slower than t3[0, 0, 0]. Best, Ilya
Re: Socket - handling large numbers of incoming connections
V Mon, 21 Dec 2015 23:29:14 + "Adam D. Ruppe via Digitalmars-d-learn"napsáno: > On Monday, 21 December 2015 at 23:17:45 UTC, Daniel Kozák wrote: > > If you want to reinvent the wheel you can use > > It isn't really reinventing the wheel to just use an alternate > library... I guess you are right > it isn't like the bundled functions with the OS are > hard to use and you really should understand how they work anyway I agree, if something go wrong it is a nice to know why > to write efficient programs. > I can write efficient programs with vibe.d(libevent,libuv,libasync...) too :).
Re: Redesign of dlang.org
On 2015-12-21 09:47, Ola Fosheim Grøstad wrote: Nice! A few suggestions: 1. Red is an attention-seeking colour, so it usually a good idea to use it more sparingly. But if you use it on links, make sure you only use it on "clickable" items. Right now some icons and text are red, but non-clickable. Most links are dummy links. 2. Align the elements. Make the logo horizon unclipped in the horizontal direction (complete the sphere) and implement it as part of the background, then align the left edge of the D logo with the left edge of the content. It's apparently very sensitive to modify the logo. -- /Jacob Carlborg
Re: We need a good code font for the function signatures on dlang.org
On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu wrote: I was looking at https://github.com/D-Programming-Language/dlang.org/pull/1169 and that bold sans serif proportional text for the code is just... well let's say it's time to replace it. What would be a good code font to use for those? My favourites would be: Menlo, DejaVu Sans Mono, Ubuntu Mono. But don't embed them, just provide a safe fallback, like monospace.
Re: Make Simple Things Hard to Figure out
On Monday, 21 December 2015 at 15:55:13 UTC, default0 wrote: Well if I post this as a question to SO and link it here, would you mind answering it? Maybe we should make this a general scheme: If someone has trouble learning something, just ask the question directly on SO and have someone answer it there. SO is way easier to google than this learn forum or the documentation on dlang. And every single question that gets answered may be helpful to others trying to do the same :) yeah I think that's a good idea to do, even if you already know the answer you can post it there and answer at the same time to provide an archive for future searching.
Re: Redesign of dlang.org
On 21.12.2015 16:45, Adam D. Ruppe wrote: Let's not underestimate, but let's not overestimate either, I'm pretty confident these bugs could all be fixed in a day of tweaking, probably less than that. It looks reasonable right now. Possibly, but the whole thing still needs to be implemented properly. I just added all the CSS from the mock-up on top of the existing stuff. We don't want to keep it that way. Finding all the little issues in the different sections of the site may take its time, too. And then there are forum.dlang.org and visuald.dlang.org. Also, things like the overcrowded menu bar, and overly long code snippets (on the home page) need decisions, which can take a while if people are not in immediate agreement. On doing it right, I'm not sure how to approach the Bootstrap grid thing. Use it with raw HTML/CSS? That may be more complicated than just doing things without a framework like that. And switching dlang.org over to some preprocessor is not trivial, and may be deemed "too disruptive for too little gain".
Re: Make Simple Things Hard to Figure out
On Monday, 21 December 2015 at 13:51:57 UTC, default0 wrote: The thing I was trying to do was dead simple: Receive a base64 encoded text via a query parameter. So when I read this, I thought you might have missed another little fact... there's more than one base64. Yup, normal Base64 encoding uses + and / as characters, which are special in URLs, so often (but not always!), base64 url encoding uses - and _ instead. This isn't D specific, it is just part of the confusing mess that is the real world of computer data. Normal base64 does work in urls, as long as it is properly url encoded. (Got enough encoding yet?!) Anywho if you are consuming this from some other source, make sure you are using the same kind as base64 as they are. import std.base64; // for normal base64 ubyte[] bytes = Base64.decode(your_string); // for the url-optimized variant of base64 ubyte[] bytes = Base64URL.decode(your_string); My first instinct was to use google. Tip I tell people at work too: yes, look for it yourself, but if you don't see an answer with a few minutes, go ahead and ask us, drop a quick question in the chatroom. D has one on IRC freenode called #d. We won't necessarily even see your question and might not know, so keep trying to figure it out yourself, but you might be able to save a lot of time by just picking our brains. There is a decode function, but I couldn't quite figure out what it did or how I was supposed to use it, if it did what I wanted it to - no examples. std.utf.decode will take a few chars and decode them into a single wchar or dchar. Take the character “ for example, the double curly quote that Microsoft Word likes to put in when you type " on your keyboard. “ has several different encodings as bytes. http://www.fileformat.info/info/unicode/char/201c/index.htm UTF-8 (hex) 0xE2 0x80 0x9C (e2809c) UTF-16 (hex)0x201C (201c) UTF-32 (hex)0x201C (201c) UTF-8 is char in D. That curly quote takes up three chars: char[] curlyQuote = [0xE2, 0x80, 0x9C]; size_t idx = 0; dchar curlyQuoteAsDchar = decode(curlyQuote[], idx); assert(curlyQuoteAsDchar == '\u201c'); The std.utf module mostly works on this level, chars to dchars and back. There's one big exception though... the validate function. http://dlang.org/phobos/std_utf.html#validate That works on a whole string and validates the whole sequence of chars as being valid utf8, throwing an exception if it isn't. (Weird behavior btw, I think I would have preferred `isValid` returning bool, or `validate` taking bytes and returning chars - which would be exactly what you wanted - but it returns void and throws instead :( ) This stuff btw is pretty confusing, there's an awful lot to know about text encoding, so don't feel bad if it makes very little sense to you. I spent like four pages in my book introducing unicode as part of the discussion on D strings... and still, that left out a lot of things too... After that I moved on to std.string. It only had one function that seemed somewhat interesting - assumeUTF. After reading through the docs, it failed my criteria since it had no validation - as its name states, it simply assumes that whatever you give it is correctly encoded. I didn't expect much here anyways, it would have been an odd place to put this functionality. Ooooh you're close though. If you did --- import std.base64, std.string, std.utf; auto utf = assumeUTF(Base64.decode(it)); validate(utf); --- you'd probably get what you wanted... Really inconvenient. It then goes on to state that it supersedes std.utf.decode, but I don't remember reading any notice in std.utf.decode that it actually was superseded and I shouldn't even really bother trying to learn about it, weird but okay. blargh I had to look at the source to understand what these actually did EncodingScheme.create("UTF-8").isValid(decodedBase64) followed by a type-system-ignoring cast from ubyte[] to char[] (since I now know it is valid so this cast is fine). All in all, including the explicit error handling required by isValid this has taken about an hour of research and 7 lines of code. yeah that works too So with that in mind, any ideas to improve the situation (that do not require 500 man-decades of work)? We need a lot more examples, and not just of individual functions. Examples on how to bring the functions together to do real world tasks.
Re: Small minesweeper game in D
On Monday, 21 December 2015 at 02:28:27 UTC, Adam D. Ruppe wrote: On Sunday, 20 December 2015 at 17:24:41 UTC, jmh530 wrote: The code looks easy to understand also. You might consider writing this up into a blog post. I might if I had a blog... which I need to set up at some point but haven't yet (well, I used to have one but not for years). You can write in "THIS WEEK IN D"... please do it! Bubba.
Re: Redesign of dlang.org
On Monday, 21 December 2015 at 16:50:31 UTC, anonymous wrote: On 21.12.2015 16:45, Adam D. Ruppe wrote: Let's not underestimate, but let's not overestimate either, I'm pretty confident these bugs could all be fixed in a day of tweaking, probably less than that. It looks reasonable right now. Possibly, but the whole thing still needs to be implemented properly. I just added all the CSS from the mock-up on top of the existing stuff. We don't want to keep it that way. Finding all the little issues in the different sections of the site may take its time, too. And then there are forum.dlang.org and visuald.dlang.org... Don't forget... less is good: http://motherfuckingwebsite.com/ Bubba.