Re: Coedit 2 alpha 4, split view and dfmt

2015-12-21 Thread Basile B. via Digitalmars-d-announce
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!

2015-12-21 Thread Dan Olson via Digitalmars-d-announce
Kai Nacke  writes:

> 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

2015-12-21 Thread Basile B. via Digitalmars-d-announce

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

2015-12-21 Thread Jack Stouffer via Digitalmars-d
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

2015-12-21 Thread Andrei Alexandrescu via Digitalmars-d

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

2015-12-21 Thread Andrei Alexandrescu via Digitalmars-d

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\

2015-12-21 Thread via Digitalmars-d-bugs
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); }

2015-12-21 Thread Steven Schveighoffer via Digitalmars-d-learn

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)*?

2015-12-21 Thread Steven Schveighoffer via Digitalmars-d-learn

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

2015-12-21 Thread via Digitalmars-d-bugs
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

2015-12-21 Thread Jakob Jenkov via Digitalmars-d-learn
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?

2015-12-21 Thread Andrei Alexandrescu via Digitalmars-d

Destroy! https://issues.dlang.org/show_bug.cgi?id=15465

Andrei


Re: Redesign of dlang.org

2015-12-21 Thread Charles via Digitalmars-d
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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d

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

2015-12-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15464

Daniel Kozak  changed:

   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

2015-12-21 Thread Stefan via Digitalmars-d-learn
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

2015-12-21 Thread Dmitry via Digitalmars-d
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

2015-12-21 Thread Jakob Jenkov via Digitalmars-d-learn

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

2015-12-21 Thread Jakob Jenkov via Digitalmars-d-learn

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

2015-12-21 Thread Basile B. via Digitalmars-d-announce

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)*?

2015-12-21 Thread anonymous via Digitalmars-d-learn

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)*?

2015-12-21 Thread Steven Schveighoffer via Digitalmars-d-learn

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

2015-12-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15465

Andrei Alexandrescu  changed:

   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

2015-12-21 Thread tcak via Digitalmars-d-learn

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

2015-12-21 Thread Bubbasaur via Digitalmars-d

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

2015-12-21 Thread default0 via Digitalmars-d-announce

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'

2015-12-21 Thread via Digitalmars-d-bugs
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

2015-12-21 Thread Daniel Kozák via Digitalmars-d-learn
V Mon, 21 Dec 2015 20:53:14 +
Jakob Jenkov via Digitalmars-d-learn
 napsá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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d-learn

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?

2015-12-21 Thread Jay Norwood via Digitalmars-d-learn
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

2015-12-21 Thread Jack Stouffer via Digitalmars-d-learn

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

2015-12-21 Thread bachmeier via Digitalmars-d-announce
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?

2015-12-21 Thread Jack Stouffer via Digitalmars-d-learn

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

2015-12-21 Thread Adrian Matoga via Digitalmars-d-learn

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

2015-12-21 Thread Jay Norwood via Digitalmars-d-learn
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

2015-12-21 Thread Jay Norwood via Digitalmars-d-learn
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?

2015-12-21 Thread Jonathan M Davis via Digitalmars-d-learn
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

2015-12-21 Thread Marc Schütz via Digitalmars-d
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

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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

2015-12-21 Thread BLM768 via Digitalmars-d

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

2015-12-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8166

Jack Stouffer  changed:

   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

2015-12-21 Thread Vadim Lopatin via Digitalmars-d-announce

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

2015-12-21 Thread default0 via Digitalmars-d-learn

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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d
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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d-learn

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

2015-12-21 Thread via Digitalmars-d-bugs
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

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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

2015-12-21 Thread Ola Fosheim Grøstad via Digitalmars-d
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?

2015-12-21 Thread Jakob Ovrum via Digitalmars-d-learn
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

2015-12-21 Thread default0 via Digitalmars-d-learn

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?

2015-12-21 Thread Shriramana Sharma via Digitalmars-d-learn
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?

2015-12-21 Thread Shriramana Sharma via Digitalmars-d-learn
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

2015-12-21 Thread Sean Campbell via Digitalmars-d
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?

2015-12-21 Thread Shriramana Sharma via Digitalmars-d-learn
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?

2015-12-21 Thread Jonathan M Davis via Digitalmars-d-learn
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

2015-12-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5753

Ryuichi OHORI  changed:

   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

2015-12-21 Thread wobbles via Digitalmars-d-announce

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

2015-12-21 Thread via Digitalmars-d-bugs
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

2015-12-21 Thread wobbles via Digitalmars-d

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

2015-12-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15464

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||preapproved

--


Re: Redesign of dlang.org

2015-12-21 Thread anonymous via Digitalmars-d

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

2015-12-21 Thread Andrei Alexandrescu via Digitalmars-d

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

2015-12-21 Thread Andrei Alexandrescu via Digitalmars-d

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)

2015-12-21 Thread Robert burner Schadek via Digitalmars-d-announce

Update:

It now also generates functions that call the vibe.d rest service 
in typestrict.




Re: Redesign of dlang.org

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d

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... ?

2015-12-21 Thread Joakim via Digitalmars-d

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?

2015-12-21 Thread ShinraTensei via Digitalmars-d-learn

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?

2015-12-21 Thread Rikki Cattermole via Digitalmars-d-learn

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

2015-12-21 Thread Basile B. via Digitalmars-d-learn

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?

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d-learn

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?

2015-12-21 Thread ShinraTensei via Digitalmars-d-learn
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?

2015-12-21 Thread Jay Norwood via Digitalmars-d-learn

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?

2015-12-21 Thread Rikki Cattermole via Digitalmars-d-learn

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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d
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

2015-12-21 Thread Yazan D via Digitalmars-d
Yes


Re: Redesign of dlang.org

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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?

2015-12-21 Thread Ali Çehreli via Digitalmars-d-learn

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

2015-12-21 Thread Andrea Fontana via Digitalmars-d
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

2015-12-21 Thread Ola Fosheim Grøstad via Digitalmars-d
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

2015-12-21 Thread Shriramana Sharma via Digitalmars-d
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

2015-12-21 Thread Misu via Digitalmars-d
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?

2015-12-21 Thread Shriramana Sharma via Digitalmars-d-learn
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?

2015-12-21 Thread tcak via Digitalmars-d-learn
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.

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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?

2015-12-21 Thread Jonathan M Davis via Digitalmars-d-learn
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?

2015-12-21 Thread Jonathan M Davis via Digitalmars-d-learn
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?

2015-12-21 Thread rumbu via Digitalmars-d-learn
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

2015-12-21 Thread earthfront via Digitalmars-d
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?

2015-12-21 Thread Jonathan M Davis via Digitalmars-d-learn
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

2015-12-21 Thread Joakim via Digitalmars-d-announce

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

2015-12-21 Thread Ilya via Digitalmars-d-learn

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

2015-12-21 Thread Daniel Kozak via Digitalmars-d-learn
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

2015-12-21 Thread Jacob Carlborg via Digitalmars-d

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

2015-12-21 Thread Adrian Matoga via Digitalmars-d
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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d-learn

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

2015-12-21 Thread anonymous via Digitalmars-d

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

2015-12-21 Thread Adam D. Ruppe via Digitalmars-d-learn

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

2015-12-21 Thread bubbasaur via Digitalmars-d-announce

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

2015-12-21 Thread Bubbasaur via Digitalmars-d

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.


  1   2   >