date:20130805


On 8/5/2013 6:21 AM, Richard Webb wrote:

Is that needed, or would changing them to

OutBuffer-writestring(name);

be more efficient?


Yes.

Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()


On 8/5/2013 4:01 AM, Richard Webb wrote:

Using the latest DMD and this snn.lib, i'm seeing it take about 11.5 seconds to
compile the algorithm unit tests (when i tried it last week, it was taking
closer to 17 seconds).

For comparison, the MSVC build takes about 10 seconds on the same machine
(Athlon 64X2 6000+).

Keep up the good work :-)



So I guess the DMC code generator isn't as awful as has been assumed! This is 
hardly the first time the culprit was a library routine, not the code generator.

Re: Article: Increasing the D Compiler Speed by Over 75%


--snip--

Leandro Lucarella wrote:

I know is technically right, I'm just saying it can be easily 
confused for something else that looks much better than the 
actual (very good) reality, and in this case is misleading.


If you say something that's technically correct but hard to 
understand, you are not communicating your message effectively.


Technically correct is the best kind of correct :D

Re: Article: Increasing the D Compiler Speed by Over 75%

2013-08-05 Thread Richard Webb


On Monday, 5 August 2013 at 17:53:48 UTC, Walter Bright wrote:

On 8/5/2013 6:21 AM, Richard Webb wrote:

Is that needed, or would changing them to

   OutBuffer-writestring(name);

be more efficient?


Yes.


https://github.com/D-Programming-Language/dmd/pull/2450

glad OpenGL loader generator

glad - is an OpenGL loader (with experimental gles support, --api=gles2)
which is generated 1:1 from the OpenGL official spec
(https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml).
It has at the moment a backend for three languages (frontend parses,
backend generates code, like constants and function pointers).

https://github.com/Dav1dde/glad

What are the advantages over e.g. Derelict?

* supports *every* opengl extension
* always up to date
* (basically) never incorrect bindings
* easy to maintain
* easy API, 3 functions
* allows you to use your own loader

And the more important:
* provides an easy way to check if extension X is loaded
`enforce(GL_EXT_Cg_shader)` (same works for OpenGL versions
`enforce(GL_VERSION_3_2)`)
* glad generates loaders exactly for your needs. If you only need a
OpenGL 3.2 core profile with two extensions, glad can generate exactly
this code. Making your binding small, without overhead.


What your code might look like with glad:

import glad.gl; // imports all constants and functions, including extensions
import glad.loader : gladInit, gladTerminate, gladLoadGL;
void main() {
gladInit();
scope(exit) gladTerminate();

/* setup OpenGL context with e.g. glfw */

auto glv = gladLoadGL();
enforce(glv.major == 3  glv.minor == 2);
// or: enforce(GL_VERSION_3_2);
enforce(GL_EXT_texture_filter_anisotropic);

/* done, use OpenGL here */
}

gladInit() and gladTerminate() are not needed if you provide your own
loader, e.g. you use SDL:

void main() {
/* setup OpenGL context with SDL */

auto glv = gladLoadGL(SDL_GL_GetProcAddress);
enforce(glv.major == 3  glv.minor == 2);

/* done, use OpenGL here */
}

A fully blown OpenGL 4.4 compatability, all extensions loader:
https://github.com/Dav1dde/glad/tree/d
But I really recommend generating your own loader/binding for your exact
needs!

python main.py --generator=d
--extensions=GL_EXT_texture_filter_anisotropic --out-path=build


A example in C:
https://github.com/Dav1dde/glad/blob/master/example/c/simple.c (to show
glad is not rocket science!)



--- Slightly Offtopic, why Derelict/Dynamic linking is bad  

glad was mainly written to have an easy backend to support multiple
languages at a time, but also to get rid of Derelict as a dependency.

(warn: dynamic/static linking rant)

OpenGL was the only reason I still used Derelict, now I could get rid of
another relativly big dependency. Don't get me wrong Derelict is great,
but dynamic loading isn't! Unfortunatly you have to dynamically load OpenGL.

Why is dynamic loading a problem?
Well static linking has several important advantages:
* slightly faster startup times
* easier to distribute
* no DLL hell like on windows! with all it's DLLs, it's a mess!
https://en.wikipedia.org/wiki/DLL_hell

If you depend on a system-wide installation of a library you get another
problem Windows might have a different DLL than Ubuntu a .so  or
Archlinux or Debian old stable, so you have to ship your DLLs with you
or depend on a specific version, which makes distribution a lot harder.

You might say, but on Windows, I can't statically link because dmc
doesn't really work (e.g. Makefiles not supporting DM Make), objconv
(another dependency next to the C compiler) etc... Well on Windows you
can still use an import library. Which brings us to the next advantage.
You don't need two separate librarys for one and the same binding (one
which works like a C-Header and one with a ton of function pointers and
loader code attached).

Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()

2013-08-05 Thread Kagamin

On Sunday, 4 August 2013 at 09:28:11 UTC, Denis Shelomovskij 
wrote:
So I suppose you use `HeapFree` too? Please, be sure you use 
this Windows API BOOL/BOOLEAN bug workaround:

https://github.com/denis-sh/phobos-additions/blob/e061d1ad282b4793d1c75dfcc20962b99ec842df/unstd/windows/heap.d#L178


BOOLEAN is either TRUE or FALSE, so it should be ok to check only 
the least significant byte.

Re: glad OpenGL loader generator

2013-08-05 Thread w0rp

I'm glad you invested time in glad. I'll probably try it out soon 
enough.

Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()

2013-08-05 Thread Mr. Anonymous


On Monday, 5 August 2013 at 21:42:11 UTC, Kagamin wrote:
On Sunday, 4 August 2013 at 09:28:11 UTC, Denis Shelomovskij 
wrote:
So I suppose you use `HeapFree` too? Please, be sure you use 
this Windows API BOOL/BOOLEAN bug workaround:

https://github.com/denis-sh/phobos-additions/blob/e061d1ad282b4793d1c75dfcc20962b99ec842df/unstd/windows/heap.d#L178


BOOLEAN is either TRUE or FALSE, so it should be ok to check 
only the least significant byte.


Not in Windows:
typedef BYTE BOOLEAN;
typedef int BOOL;

(c) 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx


While ideally it should be TRUE or FALSE, sometimes it isn't.
In fact, for functions that return BOOL, MSDN states the 
following:

If the function succeeds, the return value is nonzero.

Re: glad OpenGL loader generator

It looks like your D backend generates string literals with literal null 
bytes--this is unnecessary as string literals are already null 
terminated. (Documented here: http://dlang.org/interfaceToC.html (see 
final bullet under Calling C Functions)

Also, it looks like loading each extension requires scanning all 
available extension names, e.g. loading 25 extensions requires 25 linear 
scans of the extension list.  You might consider caching and sorting if 
the number of extensions requested is more than a handful.

Re: glad OpenGL loader generator

Am 06.08.2013 00:17, schrieb Justin Whear:
 It looks like your D backend generates string literals with literal null 
 bytes--this is unnecessary as string literals are already null 
 terminated. (Documented here: http://dlang.org/interfaceToC.html (see 
 final bullet under Calling C Functions)

This is (was) on purpose.
I should probably change that now, since it will confuse people. I had
for a short time a mess in the generators and tried to use the D
generator to build for another language too, which required the explicit
\0 and .ptr

 Also, it looks like loading each extension requires scanning all 
 available extension names, e.g. loading 25 extensions requires 25 linear 
 scans of the extension list.  You might consider caching and sorting if 
 the number of extensions requested is more than a handful.

I was thinking of that, too, but caching the OpenGL call to
glGetStringi, I don't think you can prevent the linear searches.

D reaches 1000 questions on stackoverflow

2013-08-05 Thread Andrei Alexandrescu


http://stackoverflow.com/questions/tagged/d

Andrei

Re: glad OpenGL loader generator

2013-08-05 Thread Land


I really like the sound of this. I'll try it out tomorrow.

Re: glad OpenGL loader generator

Am 06.08.2013 00:33, schrieb Justin Whear:
 On Tue, 06 Aug 2013 00:21:46 +0200, David wrote:
 I was thinking of that, too, but caching the OpenGL call to
 glGetStringi, I don't think you can prevent the linear searches.
 
 Why not something like this for the GL_VERSION = 3 codepath in has_ext?
 ---
 static auto availableExts;
 
 if (availableExts.empty)
 {
 int num;
 glGetIntegerv(GL_NUM_EXTENSIONS, num);
 availableExts = new string[](num);
 
 foreach (i, ref extName; availableExts)
   extName = (cast(const(char)*)glGetStringi(GL_EXTENSIONS, i)).idup;
 
 availableExts.sort();
 }
 
 // Use binary search
 return assumeSorted(availableExts).contains(ext);
 ---
 

Thanks, I will definitly look into improving it (when I wake up ;))

Re: glad OpenGL loader generator

Am 06.08.2013 01:11, schrieb Land:
 I really like the sound of this. I'll try it out tomorrow.

glad to hear that ;) (to join w0rp with glad jokes)

Re: glad OpenGL loader generator

2013-08-05 Thread Andrej Mitrovic

On 8/6/13, David d...@dav1d.de wrote:
 Thanks, I will definitly look into improving it (when I wake up ;))

You should know better than to code when you're sleepwalking!

glad works great for me, I've tested it on Win7 x64. Great project!

Re: D reaches 1000 questions on stackoverflow


Andrei Alexandrescu wrote:
http://stackoverflow.com/questions/tagged/d

Andrei


Perhaps we can get it to 1000 answers? I'm looking through it now 
to see if I can find something I can answer.

Re: request switch statement with common block

2013-08-05 Thread luminousone

perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
... before stuff ...
}
out {
 after stuff ...
}
body {
case 1:
in {
   ... etc 
}
out {
   ... more etc ...
}
body {
   ...
}
case 2:
  // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
assert( i == 0 );
}
out {
assert( i == 9 );
}
body {
   ... stuff ...
}

if it is desired for a particular contract block to be called in 
release builds perhaps a attribute label to mark it as a runtime 
block or something similar.


foreach( i, k ; somerange )
@runtime in {
 ...
}
body {
}

Re: Network server design question

2013-08-05 Thread Johannes Pfau

Am Sun, 04 Aug 2013 22:59:04 +0200
schrieb Marek Janukowicz ma...@janukowicz.net:

  - I already have problems with interrupted system call on
  Socket.select due to GC kicking in; I'm restarting the call
  manually, but TBH it sucks I have to do anything about that and
  would suck even more to do that with 50 or so threads
  
  I'm not sure if that problem will surface with blocking reads.
 
 Unfortunately it will (it precisely happens with blocking calls).
 
 Thanks for your input, which shed some more light for me and also
 allowed me to explain the whole thing a bit more.
 

This is a bug in std.socket BTW. Blocking calls will get interrupted by
the GC - there's no way to avoid that - but std.socket should handle
this internally and just retry the interrupted operation. Please file a
bug report about this.

(Partial writes is another issue that could/should be handled in
std.socket so the user doesn't have to care about it)

Re: request switch statement with common block


On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
... before stuff ...
}
out {
 after stuff ...
}
body {
case 1:
in {
   ... etc 
}
out {
   ... more etc ...
}
body {
   ...
}
case 2:
  // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
assert( i == 0 );
}
out {
assert( i == 9 );
}
body {
   ... stuff ...
}

if it is desired for a particular contract block to be called 
in release builds perhaps a attribute label to mark it as a 
runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
 ...
}
body {
}


Please do not take offense, but I do not see this as a good idea. 
Contracts have a very different function; not just in D, but 
every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs for 
the purposes proposed here would, in my opinion, cause confusion 
and/or weaken the proper use of contract programming.



The code in the contract conditions should never do anything more 
than what is necessary to specify the contract. It should not do 
explicit IO (other than implied by assert()), mutate state, or 
anything like that.


At the bottom of this page you can find a reading list for more 
info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do any 
static analysis on the contracts? Such as a void safety/null 
reference check?

Re: request switch statement with common block

2013-08-05 Thread dennis luehring


Am 05.08.2013 08:28, schrieb luminousone:

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
  assert( i == 0 );
}
out {
  assert( i == 9 );
}
body {
 ... stuff ...
}


that is just evil code

if you got something todo before or on the first item of the list do it 
before the loop - and for the last behind the for loop


if we talk about code-duplication then - use an inner function

this type of sub-branching de-looping is slow (if performance is 
relevant) and just not foreach-able, and so not functional-style 
programming - its called for loop index micro management for unknown 
reasons - but many programmers prefer it very much :)

Re: Network server design question

2013-08-05 Thread Robert M. Münch


On 2013-08-04 19:38:49 +, Marek Janukowicz said:


...
If anyone has any idea how to handle the problems I mentioned or has any
idea for more suitable design I would be happy to hear it. It's also
possible I'm approaching the issue from completely wrong direction, so you
can correct me on that as well.


Hi, I would take a look at the BEEP protocol idea and there at the 
Vortex library [1] it deals with everything you need. The idea of BEEP 
is, that you don't have to care about all the network pitfalls since 
these are always the same. Instead you can concentrate on your 
application level design. Where the time is spent much more valuable.


The lib is written in C and works very good. It's matured and 
multi-threaded to allow for maximum transfers.


[1] http://www.aspl.es/vortex/


--
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

Re: Network server design question

2013-08-05 Thread Regan Heath

On Sun, 04 Aug 2013 20:38:49 +0100, Marek Janukowicz  
ma...@janukowicz.net wrote:

I'm writing a network server with some specific requirements:
- 5-50 clients connected (almost) permanently (maybe a bit more, but
definitely not hundreds of them)
- possibly thousands of requests per seconds
- responses need to be returned within 5 seconds or the client will
disconnect and complain

Currently I have a Master thread (which is basically the main thread)  
which

is handling connections/disconnections, socket operations, sends parsed
requests for processing to single Worker thread, sends responses to  
clients.

Interaction with Worker is done via message passing.

The problem with my approach is that I read as much data as possible from
each ready client in order. As there are many requests this read phase  
might

take a few seconds making the clients disconnect. Now I see 2 possible
solutions:

1. Stay with the design I have, but change the workflow somewhat -  
instead
of reading all the data from clients just read some requests and then  
send

responses that are ready and repeat; the downside is that it's more
complicated than current design, might be slower (more loop iterations  
with
less work done in each iteration) and might require quite a lot of  
tweaking

when it comes to how many requests/responses handle each time etc.

2. Create separate thread per each client connection. I think this could
result in a nice, clean setup, but I see some problems:
- I'm not sure how ~50 threads will do resource-wise (although they will
probably be mostly waiting on Socket.select)
- I can't initialize threads created via std.concurrency.spawn with a  
Socket

object (Aliases to mutable thread-local data not allowed.)
- I already have problems with interrupted system call on Socket.select
due to GC kicking in; I'm restarting the call manually, but TBH it sucks  
I
have to do anything about that and would suck even more to do that with  
50

or so threads

If anyone has any idea how to handle the problems I mentioned or has any
idea for more suitable design I would be happy to hear it. It's also
possible I'm approaching the issue from completely wrong direction, so  
you

can correct me on that as well.


Option #2 should be fine, provided you don't intend to scale to a larger  
number of clients.  I have had loads of experience with server  
applications on Windows and a little less on the various flavours of  
UNIXen and 50 connected clients serviced by 50 threads should be perfectly  
manageable for the OS.


It sounds like only non-blocking sockets have the GC interrupt issue, if  
so use non-blocking sockets instead.  However, it occurs to me that the  
issue may rear it's head again on the call to select() on non-blocking  
sockets, so it is worth testing this first.


If there is no way around the GC interrupt issue then code up your own  
recv function and re-use it all your threads, not ideal but definitely  
workable.


In the case of non-blocking sockets your read operation needs to account  
for the /this would block/ error code, and should go something like this..  
(using low level socket function call names because I have not used the D  
socket library recently)

1. Attempt recv(), expect either DATA or ERROR.
1a. If DATA, process data and handle possible partial request(s) - by  
buffering and going back to #1 for example

1b. If ERROR, check for code [WSA]EWOULDBLOCK and if so go to step #2
1c. If ERROR and not would block, fail/exit/disconnect.
2. Perform select() (**this may be interruptable by GC**) for a finite  
shortish timeout - if you want your client handlers to react quickly to  
the signal to shutdown then you want a shorter time - for example.

2a. If select returns a read indicator, go to #1
2b. If select returns an error, fail/exit/disconnect.
2c. Otherwise, go to #2

Do you have control of the connecting client code as well?  If so, think  
about disabling the Nagle algorithm:

http://en.wikipedia.org/wiki/Nagle's_algorithm

You will want to ensure the client writes it's requests in a single send()  
call but in this way you reduce the delay in receiving requests at the  
server side.  If the client writes multiple requests rapidly then with  
Nagle enabled it may buffer them on the client end and will delay the  
server seeing the first, but with it disabled the server will see the  
first as soon as it is written and can start processing it while the  
client writes.  So depending on how your clients send requests, you may  
see a performance improvement here.


I don't know how best to solve the Aliases to mutable thread-local data  
not allowed..  You will need to ensure the socket is allocated globally  
(not thread local) and because you know it's unique and not shared you can  
cast it as such to get it into the thread, once there you can cast it back  
to unshared/local/mutable.  Not ideal, but not illegal or invalid AFAICS.


FYI.. For a better more scaleable solution

Re: request switch statement with common block

2013-08-05 Thread MattCodr


On Monday, 5 August 2013 at 04:07:55 UTC, Andre Artus wrote:



Andre Artus:
int number;
string message;
switch (number)
{
default: // valid: ends with 'throw'
throw new Exception(unknown number);
case 3:
message ~= three ; break;
case 4:
message ~= four ; continue;
case 5:
message ~= five ; goto case;
case 6:
message ~= six ; break;
case 1:
case 2:
message = one or two;
}

With the inclusion of 'default' the condition covers the 
whole range of 'int'. The programmer may only want the pre  
and post code to be executed for every other case (1..6).



MattCoder:
Like I said, it would be nice if we could extend some D 
features without change the compiler source, maybe like macros 
in LISP.


It may not always be the case, but in my experience this often 
leads to write-only code.
I'm pretty new to D, so I'm not quite up to speed with the 
metaprogramming abilities, but I'm under the impression that 
this is what mixin's are for.


Well I'm not experienced too, but mixin's for what I know just 
works in compiler time right?


But anyway it would be possible to write my own switch version 
with mixin? I really would like to see this.


Matheus.

Re: request switch statement with common block

2013-08-05 Thread QAston


On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:

this type of sub-branching de-looping is slow (if performance 
is relevant) and just not foreach-able, and so not 
functional-style programming - its called for loop index micro 
management for unknown reasons - but many programmers prefer 
it very much :)


It's caused by lack of inner functions in many languages - people 
use switch+flags or for loops to be more DRY.

Re: D component programming is a joke (Was: Re: Component programming)

2013-08-05 Thread Dejan Lekic


On Friday, 2 August 2013 at 05:26:05 UTC, H. S. Teoh wrote:

On Thu, Aug 01, 2013 at 10:34:24AM -0700, Walter Bright wrote:

On 8/1/2013 2:23 AM, John Colvin wrote:
On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
Add in some code examples and that could make a nice article.

Yes, please!


Alright, so I decided to prove my point about component 
programming by
actually writing a fully-functional version of the calendar 
layout

program, so that I have a solid piece of evidence that component
programming lives up to its promise. :) In addition, I decided 
that for
maximum reusability, I want the output lines available in an 
input
range, with absolutely no binding to writeln whatsoever (except 
in
main() where the range is handed to writeln for output). In 
retrospect,
that was perhaps a bit too ambitious... I ran into a few 
roadblocks to

actually get the code working, so it took me a lot longer than I
anticipated to finish the code.

However, I *will* say that I'm very proud of the code: already 
there are
a few pieces that, if properly cleaned up and refined, probably 
deserve
inclusion in Phobos. Reusability FTW!! Now, just tell me if 
you've ever
seen a calendar layout program made of straightforward, 
reusable pieces.
I for sure haven't. I tried looking at the C code for the Unix 
cal
program once... It looked frighteningly similar to an IOCCC 
entry. :-/


My D version, however, built using ranges through and through, 
has many
pieces that are easily reusable. For example, if you wanted to 
output
only a single month instead, you could just call join(\n) on 
the range
of formatted month lines that the full year layout algorithm 
uses to
splice lines from multiple months together -- it's *that* 
reusable.


Anyway. Enough hand-waving in the air. Let the actual code 
speak for

itself:

https://github.com/quickfur/dcal/blob/master/dcal.d

Now, w.r.t. the roadblocks I alluded to.

When I first started working on the code, my goal was to 
maximize usage
of existing Phobos facilities in order to show how many 
batteries D
already comes with. As it turned out, I could only use basic 
Phobos
components; some of the more complex pieces like 
frontTransversal, which
would've been perfect for the bit that splices formatted month 
lines
together, couldn't be used because it wasn't flexible enough to 
handle
the insertion of fillers when some subranges are empty. In the 
end, I
had to code that range by hand, and I can't say I'm that happy 
with it
yet. But at least, it's nothing compared to the hairy 
complexity of the

C version of cal.

Another place where I wanted to use existing Phobos components 
was
chunkBy. There's probably a way to do it if you think hard 
enough about
it, but in the end I felt it was simpler to just write the code 
myself.
Might be a failure on my part to recognize how to put existing 
Phobos
ranges in a clever enough way to achieve what I wanted. I did 
try to do
something similar to byWeek(), but somehow it didn't do what I 
wanted
and I decided to just code it by hand instead of investigating 
further.


By far the biggest roadblock I ran into was that after I wrote
everything up to (and including) pasteBlocks, my unittests 
refused to
work. Somehow, pasteBlocks kept repeating the first line of the 
output
(the month names, if you look at the unittest) and refused to 
advance
farther.  Eventually I traced the problem to Lines.popFront(), 
which
pops each subrange off the range of ranges. The problem is that 
this
only works on some ranges, but not others; if you pass the 
output of
formatMonths() straight to pasteBlocks(), it will NOT work. 
Why? Because
pasteBlocks return a std.algorithm.Map object, which recreates 
the
subrange each time, so Lines.popFront() is only popping a 
temporary copy
of the subrange, not the real thing. I was about to give up and 
try
another approach, when out of the blue I decided to try and see 
if I
could stuff the range returned by formatMonths() into an array, 
and then

pass *that* to pasteBlocks() -- and behold, it worked!!

This was a totally unexpected fix, that a newbie probably would 
never
have thought of, so this is a potential trap for newcomers to D 
who
expect components to just be pluggable. In retrospect, it makes 
sense --

you need to somehow buffer the ranges of formatted month lines
*somewhere* in order to be able to splice them together out of 
their
natural depth-first outer/inner range order. But this is not 
obvious at
all from first glance; perhaps it's a sign of a leaky 
abstraction
somewhere. We should probably look into why this is happening 
and how to
fix it. And there should be a way to test for this in 
pasteBlocks'
signature constraint so that future code won't fall into the 
same trap,

but I can't think of one right now.

Once this last bit worked, though, everything fell into place 
quickly.
After all unittests were passing, no more bugs were found!! The 
program
can print beautifully laid out

Static unittests?


Are compile-time unittests possible in D? Maybe something like:

static unittest {
assert(2 == 1 + 1);
}

So that every assert in the unittest is translated to static 
assert. And no normal asserts to be allowed in static unittest?
So the above code would be executed at compile time and 
translated to:


unittest {
static assert(2 == 1 + 1);
}

With statement become like C#'s using?


In C# there is this using construct:

using(Bitmap image = this.OpenImage(filename.bmp)) {
image.Name = foo;
//use image like image.sth
}

which is translated to:

{
Bitmap image = this.OpenImage(filename.bmp);
try {
image.Name = foo;
//use image like image.sth
}
finally {
IDisposable obj = image as IDisposable;
if(obj != null)
obj.Dispose();
}
}

I know that the with statement is different, but it can be 
improved so that you can declare things in it like an using 
statement:


with(Bitmap image = open(filename.bmp)) {
name = foo;
//no need to specify image.sth
}

or even a more implicit one:
with(open(filename.bmp)) {
//ditto
}

And both of the above to be translated to:

{
Bitmap temp = expression;
//use bitmap
delete temp; // Call destructor/finallizer of the object
//I'm not sure if delete was the proper way to call a 
destructor in D

}

And I hope you got the point. Tell me what you think.

Re: With statement become like C#'s using?

2013-08-05 Thread Michal Minich


On Monday, 5 August 2013 at 12:40:26 UTC, Bosak wrote:

In C# there is this using construct:


just declare variable as scope, and ti will be destructed as son 
as function exits.


void foo ()
{
   scope obj = new Object;
} // obj will be destructed here

you can also use it together with anonymous scope (same as c#)

more generally, there is a scope statement 
http://dlang.org/exception-safe.html that can be used where 
normally try/finally (without catch) would be used, to achieve 
cleaner code.

Re: With statement become like C#'s using?

2013-08-05 Thread bearophile


Michal Minich:


void foo ()
{
   scope obj = new Object;
} // obj will be destructed here


That usage of scope has being deprecated...

For Walter: I suggest dmd to give a deprecation message where you 
use one of the many deprecated D features, like scope classes, 
floating point comparison operators, and so on. Otherwise D 
programmers will use those featueres in their code today, and 
when those feature become deprecated, those people will become 
angry because of too much code to modify/fix.


Bye,
bearophile

Re: With statement become like C#'s using?

2013-08-05 Thread Michal Minich


On Monday, 5 August 2013 at 13:11:44 UTC, bearophile wrote:

Michal Minich:


void foo ()
{
  scope obj = new Object;
} // obj will be destructed here


That usage of scope has being deprecated...


Why it is deprecated? I follow newsgroups, but that I miss...

I like it use together with scope classes: scope class C {} - are 
they too deprecated?

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 12:49:11 UTC, Michal Minich wrote:

On Monday, 5 August 2013 at 12:40:26 UTC, Bosak wrote:

In C# there is this using construct:


just declare variable as scope, and ti will be destructed as 
son as function exits.


void foo ()
{
   scope obj = new Object;
} // obj will be destructed here

you can also use it together with anonymous scope (same as c#)

more generally, there is a scope statement 
http://dlang.org/exception-safe.html that can be used where 
normally try/finally (without catch) would be used, to achieve 
cleaner code.


Oh yes, I completely forgot about scope.

Re: With statement become like C#'s using?

2013-08-05 Thread John Colvin


On Monday, 5 August 2013 at 13:11:44 UTC, bearophile wrote:

Michal Minich:


void foo ()
{
  scope obj = new Object;
} // obj will be destructed here


That usage of scope has being deprecated...

For Walter: I suggest dmd to give a deprecation message where 
you use one of the many deprecated D features, like scope 
classes, floating point comparison operators, and so on. 
Otherwise D programmers will use those featueres in their code 
today, and when those feature become deprecated, those people 
will become angry because of too much code to modify/fix.


Bye,
bearophile


It's not a feature I've ever had the need for so far, but what is 
the replacement for scope?

Re: With statement become like C#'s using?

2013-08-05 Thread Adam D. Ruppe


On Monday, 5 August 2013 at 12:40:26 UTC, Bosak wrote:

with(Bitmap image = open(filename.bmp)) {


I think this shoudl be allowed simply for consistency with this:

if(auto a = getfoo()) { use a }

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 13:11:44 UTC, bearophile wrote:

Michal Minich:


void foo ()
{
  scope obj = new Object;
} // obj will be destructed here


That usage of scope has being deprecated...

For Walter: I suggest dmd to give a deprecation message where 
you use one of the many deprecated D features, like scope 
classes, floating point comparison operators, and so on. 
Otherwise D programmers will use those featueres in their code 
today, and when those feature become deprecated, those people 
will become angry because of too much code to modify/fix.


Bye,
bearophile


Interesting. I didn't knew that it is being deprecated. So my 
suggestion could actually be a good replacement of scope.?

Re: With statement become like C#'s using?

2013-08-05 Thread Michal Minich


On Monday, 5 August 2013 at 13:33:28 UTC, Adam D. Ruppe wrote:

On Monday, 5 August 2013 at 12:40:26 UTC, Bosak wrote:

with(Bitmap image = open(filename.bmp)) {


I think this shoudl be allowed simply for consistency with this:

if(auto a = getfoo()) { use a }


This is good. I think it should too.

But what Bosak proposes is that when with statements ends, the 
object should be destructed, which is large violation what with 
statements if for. Not mentioning breaking all the existing 
code...

Re: dsource.org down

2013-08-05 Thread David Nadlinger


On Sunday, 4 August 2013 at 22:06:58 UTC, Flamaros wrote:

For dsource.org it seems to be a server error.


Yes, it seems that the server disk is full.

David

Re: With statement become like C#'s using?

2013-08-05 Thread Adam D. Ruppe


On Monday, 5 August 2013 at 13:42:01 UTC, Michal Minich wrote:
But what Bosak proposes is that when with statements ends, 
the object should be destructed


That would happen if the object is a struct, or wrapped in a 
struct, since it would go out of scope at the end of the with and 
call its destructor then.


So then you could just go

import std.typecons;
with(auto a = Scoped!T()) { ... }

and the Scoped destructor does the deleting.

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 13:25:43 UTC, John Colvin wrote:
It's not a feature I've ever had the need for so far, but what 
is the replacement for scope?


http://dlang.org/phobos/std_typecons.html#.scoped

Re: Static unittests?


On Monday, 5 August 2013 at 12:25:36 UTC, Bosak wrote:

Are compile-time unittests possible in D? Maybe something like:

static unittest {
assert(2 == 1 + 1);
}

So that every assert in the unittest is translated to static 
assert. And no normal asserts to be allowed in static unittest?
So the above code would be executed at compile time and 
translated to:


unittest {
static assert(2 == 1 + 1);
}


Not right now at the very least. Use case?

Re: Network server design question

2013-08-05 Thread David Nadlinger


On Monday, 5 August 2013 at 06:36:15 UTC, Johannes Pfau wrote:
This is a bug in std.socket BTW. Blocking calls will get 
interrupted by
the GC - there's no way to avoid that - but std.socket should 
handle
this internally and just retry the interrupted operation. 
Please file a

bug report about this.


I'm not sure whether we can do anything about Socket.select 
itself at this point, as it would be a breaking API change – 
interrupted calls returning a negative value is even mentioned 
explicitly in the docs.


There should, however, be a way to implement this in a 
platform-independent manner in client code, or even a second 
version that handles signal interruptions internally.



(Partial writes is another issue that could/should be handled in
std.socket so the user doesn't have to care about it)


I don't think that would be possible – std.socket by design is a 
thin wrapper around BSD sockets (whether that's a good idea or 
not is another question), and how to handle partial writes 
depends entirely on the environment the socket is used in (think 
event-based architecture using fibers vs. other designs).


In general, I wonder what the best way for going forward with 
std.socket is. Sure, we could try to slowly morph it into a 
modern networking implementation, but the current state also 
has its merits, as it allows people to use the familiar BSD 
sockets API without having to worry about all the trivial 
differences between the platforms (e.g. in symbol names).


We should definitely add a note to std.socket though that it is a 
low-level API and that there might be a better choice for most 
applications (e.g. vibe.d, Thrift, …).


David

Re: Static unittests?

2013-08-05 Thread Andrej Mitrovic

On 8/5/13, Bosak bo...@gmail.com wrote:
 Are compile-time unittests possible in D? Maybe something like:

 static unittest {
  assert(2 == 1 + 1);
 }

Nope.

Interestingly, in git-head we now have the getUnitTests trait, however
this won't allow us to call the tests at compile time, I get back:

Error: __unittestL5_1 cannot be interpreted at compile time, because
it has no available source code

This trait is fairly new, so maybe we could expand on this to allow
invoking the tests at compile time.

Note of course that fundamentally not all tests can be executed at
compile-time (e.g. any kind of use of files makes them non-CTFE-able)

Re: Static unittests?

2013-08-05 Thread Jacob Carlborg


On Monday, 5 August 2013 at 12:25:36 UTC, Bosak wrote:

Are compile-time unittests possible in D? Maybe something like:

static unittest {
assert(2 == 1 + 1);
}

So that every assert in the unittest is translated to static 
assert. And no normal asserts to be allowed in static unittest?
So the above code would be executed at compile time and 
translated to:


unittest {
static assert(2 == 1 + 1);
}


Not exactly as you describe but you can do unit tests for CTFE 
functions. Have a look at this thread:


http://forum.dlang.org/thread/ks1brj$1l6c$1...@digitalmars.com

--
/Jacob Carlborg

Re: D component programming is a joke (Was: Re: Component programming)

2013-08-05 Thread H. S. Teoh

On Mon, Aug 05, 2013 at 02:11:32PM +0200, Dejan Lekic wrote:
[...]
 Good work! I've read the article yesterday. Very educational!

Thanks!

I did actually make a major revision to the article last night based on
some feedback I got; I rewrote much of the first part of it, so if
you're interested you might want to re-read it.


T

-- 
Caffeine underflow. Brain dumped.

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 13:54:38 UTC, Adam D. Ruppe wrote:

On Monday, 5 August 2013 at 13:42:01 UTC, Michal Minich wrote:
But what Bosak proposes is that when with statements ends, 
the object should be destructed


That would happen if the object is a struct, or wrapped in a 
struct, since it would go out of scope at the end of the with 
and call its destructor then.


So then you could just go

import std.typecons;
with(auto a = Scoped!T()) { ... }

and the Scoped destructor does the deleting.


Exactly. My idea is to add third use case of with. Not there are 
2 ways to use with(of witch I know):


1) Declare something and use with to not repeat yourself:
auto foo = new Foo;
with(foo) {
   name = bar; //foo.name = bar;
}
In this case it is only used for object construction and setup. 
And the with statement doesn't destruct the object or anything 
like that.

2) Used with types
struct Foo {
static int bar = 2;
}
with(Foo) {
bar++; //Foo.bar++;
}
Again with doesn't destruct or anything

All of the above are currently available, but I want a third case 
to be added:


3) Used when you declare something in the with statement with 
scope only in the with statement

with(Foo foo = new Foo) {
name = bar;
}
After that foo's destructor gets called and since foo was in the 
scope of with it goes out of scope and no references are made to 
foo. There should be a constraint that you cannot take the 
address of foo in the with statement(i.e assign a global to foo)

3.1) Or used with rvalues??
int[] values;
with(new Foo) {
name = bar;
values = getData(); //foo.getData()
}
//use values taken from foo

I think that in case 3.1 it is very intuitive for using resources 
like files. Instead of writing something like:

string text;
auto file = open(myfile.txt, r);
text = t.readlines();
file.close();
You can write this:
string text;
with(open(myfile.txt, r)) { //no need to declare variable
text = readlines(); //just use the file to get the data
}//with automaticaly calls close() on the file, even if exception 
got thrown
And if the exception got thrown in the declaration of the with 
block, then the with block doesn't execute. For example in the 
above code if the file didn't exist, an exception would be thrown 
from open and no variable would be created.


I hope that I have made my suggestion more clear.

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 15:30:45 UTC, Bosak wrote:

...


What you propose is rather unwelcome for classes (destruction of 
GC-managed objects is non-deterministic) and closest thing for 
IDisposable D has is destroy which is not something that is 
expected to be called silently.


However, I do like proposed extension of `with` syntax to allow 
declarations. It perfectly matches `if` and allows to emulate C# 
behavior via `scoped`. That will improve language consistency.

Re: With statement become like C#'s using?

2013-08-05 Thread John Colvin


On Monday, 5 August 2013 at 14:00:47 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 13:25:43 UTC, John Colvin wrote:
It's not a feature I've ever had the need for so far, but what 
is the replacement for scope?


http://dlang.org/phobos/std_typecons.html#.scoped


cool, thanks. Any particular catches a user should be aware of? 
Other than leaking a reference of course.

Re: Network server design question

On Sun, 04 Aug 2013 21:38:49 +0200, Marek Janukowicz wrote: 
 If anyone has any idea how to handle the problems I mentioned or has any
 idea for more suitable design I would be happy to hear it. It's also
 possible I'm approaching the issue from completely wrong direction, so
 you can correct me on that as well.

Are you familiar with ZeroMQ?  I write network infrastructure on a fairly 
regular basis and wouldn't dream of doing it without ZeroMQ: http://
zeromq.org/

There are D bindings in Deimos: https://github.com/D-Programming-Deimos/
ZeroMQ

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 15:55:00 UTC, John Colvin wrote:

On Monday, 5 August 2013 at 14:00:47 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 13:25:43 UTC, John Colvin wrote:
It's not a feature I've ever had the need for so far, but 
what is the replacement for scope?


http://dlang.org/phobos/std_typecons.html#.scoped


cool, thanks. Any particular catches a user should be aware of? 
Other than leaking a reference of course.


Quality of implementation of course :) I have not used it much 
personally and don't know how good it is, but it creates wrapper 
struct and there can be issues with forwarding methods/operators 
to wrapped class for some weird corner cases.

Re: request switch statement with common block


On Monday, 5 August 2013 at 11:32:14 UTC, QAston wrote:

On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:

this type of sub-branching de-looping is slow (if 
performance is relevant) and just not foreach-able, and so not 
functional-style programming - its called for loop index 
micro management for unknown reasons - but many programmers 
prefer it very much :)


It's caused by lack of inner functions in many languages - 
people use switch+flags or for loops to be more DRY.


I was under the impression that D has nested functions, unless by 
inner function you mean something else.

Re: Static unittests?


On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:

Use case?


The use case is simply checking that your functions can be 
CTFE'd, and that they produce the correct result.



Not right now at the very least.


std.exception defines the package assertCTFEable.

It allows code such as:
unittest
{
assertCTFEable!(
{
assert(to!string(1uL  62) == 4611686018427387904);
assert(to!string(0x1) == 4294967296);
assert(to!string(-138L) == -138);
});
}

If this code does not run at CTFE, then a static assert triggers.

This is currently package, but it proves that what you asked 
for is not only possible, it is implemented *and* used in phobos.


So either duplicate locally, or file an ER to make it public I 
guess.

Cryptography

2013-08-05 Thread Larry


Hello,

I would like to know how we can trust this source concerning 
scrypt :


http://code.dlang.org/packages/scrypt-d

And second : will there be any official package in D ?

The same goes for bcrypt and sha2 cryptographic algo.

Thanks,

Larry

Re: Cryptography


On Monday, 5 August 2013 at 16:52:39 UTC, Larry wrote:

Hello,

I would like to know how we can trust this source concerning 
scrypt :


http://code.dlang.org/packages/scrypt-d


By reading its source code if that is important.

Re: Static unittests?


On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:

On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:

Use case?


The use case is simply checking that your functions can be 
CTFE'd, and that they produce the correct result.


Considering your, example, you can always do `static 
assert(to!string(1uL  62) == 4611686018427387904);`


What is the crucial difference?

Re: Static unittests?


On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
This is currently package, but it proves that what you asked 
for is not only possible, it is implemented *and* used in 
phobos.


topic-starter has been asking about _language_ feature and my 
answer was related to this possible _language_ feature. Existence 
of some template in Phobos does not prove anything here.

Re: request switch statement with common block


Andre Artus:

It may not always be the case, but in my experience this often 
leads to write-only code.
I'm pretty new to D, so I'm not quite up to speed with the 
metaprogramming abilities, but I'm under the impression that 
this is what mixin's are for.



MattCoder:

Well I'm not experienced too, but mixin's for what I know just 
works in compiler time right?


But anyway it would be possible to write my own switch version 
with mixin? I really would like to see this.


Matheus.


Yes, it takes any string that's valid D. I see people using it to 
embed domain specific languages (e.g. PEG via PEGGED) so you 
should easily be able to write a translator/preprocessor that 
takes  your switch and converts it to D code.


mixin(
switch (number)
{
default: // valid: ends with 'throw'
throw new Exception(unknown number);
common_entry:
  // some common entry code
break;
common_exit:
  // some common exit code
break;
case 3:
message ~= three ;
break;
case 4:
message ~= four ;
continue;
case 6:
message ~= six ;
break;
}
);

The preprocessor could rewrite to this string:


switch (number)
{
case 3:
case 4:
case 6:
  // some common entry code
break;
}
switch (number)
{
default: // valid: ends with 'throw'
throw new Exception(unknown number);
case 3:
message ~= three ;
break;
case 4:
message ~= four ;
continue;
case 6:
message ~= six ;
break;
}
switch (number)
{
case 3:
case 4:
case 6:
  // some common exit code
break;
}



 I do not recommend anyone do  this 

The reason I would not recommend this is that it leads to brittle 
code that is hard to debug and reason about.



The reason I use `switch`, and not `if` for the entry and exit 
code is because these should only fire under the same conditions 
as the cases in the original switch, otherwise you introduce hard 
to find bugs in your code.


Once again, I do not recommend people doing this: my preference 
is for code that makes the programmers intent clear and explicit.

Re: Static unittests?


On Monday, 5 August 2013 at 17:13:52 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:

On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:

Use case?


The use case is simply checking that your functions can be 
CTFE'd, and that they produce the correct result.


Considering your, example, you can always do `static 
assert(to!string(1uL  62) == 4611686018427387904);`


What is the crucial difference?


Well, the crucial difference is that this tests a single 
expression, and not an entire block. For example, the simple test 
that int.init is 0:


static assert({int i; assert(i == 0;});

This doesn't work. You'd have to write:
static assert({int i; assert(i == 0; return 1;}());
or
static assert({int i; assert(i == 0);}(), 1);

Both of which are a bit combersome. assertCTFEable allows 
testing that the *block* will actually will compile and ctfe run 
conveniently.

Re: Static unittests?


On Monday, 5 August 2013 at 17:15:34 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
This is currently package, but it proves that what you asked 
for is not only possible, it is implemented *and* used in 
phobos.


topic-starter has been asking about _language_ feature and my 
answer was related to this possible _language_ feature. 
Existence of some template in Phobos does not prove anything 
here.


Well, it's not about *proving* anything :/

Technically, the question asked was: Are compile-time unittests 
possible in D?, so I'm not even sure the question *was* strictly 
about language.


But even if someone asks if a language can *do* something you 
*have* to take into account what the library can do. For example, 
D doesn't have native octals because they are library 
implemented. Does this mean that D doesn't have octals ?


So sure, I guess that strictly speaking, no, D language doesn't 
have static unittests. However, when someone asks the question, 
if you just answer No without pointing out that the language 
allows this semantic:


version(unittest) assertCTFEAble!({
//YOUR CODE HERE
});

Then I believe you are giving an incomplete answer.

Re: Cryptography


On 8/5/2013 9:52 AM, Larry wrote:

Hello,

I would like to know how we can trust this source concerning scrypt :

http://code.dlang.org/packages/scrypt-d

And second : will there be any official package in D ?

The same goes for bcrypt and sha2 cryptographic algo.



https://github.com/D-Programming-Deimos/openssl

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 15:38:12 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 15:30:45 UTC, Bosak wrote:

...


What you propose is rather unwelcome for classes (destruction 
of GC-managed objects is non-deterministic) and closest thing 
for IDisposable D has is destroy which is not something that 
is expected to be called silently.


However, I do like proposed extension of `with` syntax to allow 
declarations. It perfectly matches `if` and allows to emulate 
C# behavior via `scoped`. That will improve language 
consistency.


Oh yes using scoped to achieve that is a good solution. So if I 
write

with(File file = open(filename))
{
//setup file
type = Types.Text; //etc.
}
string text = file.read(); //file still usable after with, but 
explicitly

And if I write the scoped version:
with(scoped!File file = open(filename))
{
//retrieve data from file or whatever
}
//file is out of scope and is not usable after

You say that D's destroy is not like C#'s IDisposable. Then why 
doesn't D then declare that kind of interface:

interface Disposable {
void dispose();
}
And include it in the object module? That way some classes can 
implement this dispose method that will just dispose any used 
resources(and not to replace destructor's role). It is a very 
small(but core) change that is even not connected with the 
compiler, but only with phobos.
For example std file structs can just implement the interface 
like this:

//...in File class/struct that implements Disposable
void dispose() {
this.close();
}

And if you don't like the idea of adding an interface to the core 
module, then the same thing could be achieved if a special 
opDispose function is declared. This is a more D-way of doing it, 
since there exist opApply that is used only in the foreach 
construct and the opCall that is used to call classes like 
functions.


And then the with implementation is mostly straightforward. 
Depending on weather the declared variable is scoped or not, with 
behaves differently. If it is scoped it first checks if the 
object has dispose/opDispose method in it calls it and then 
destroys(or whatever the compiler does to scoped variables) it. 
And if it is not scoped then it doesn't dispose it and it acts 
just like with acts now(just the ability to declare the variable 
right in the with statement).


That way you explicitly specify that the variable is scoped and 
you know that it will be destroyed when it goes out of scope. In 
addition to that it dipposes savely.


Maybe opDispose shouldn't be only used in with statement, but 
EVERYWHERE a scoped variable is declared? Here is a more complete 
example:


class Resource { //can be any resource from files to streams to 
anything

Resource[] used;

void opDispose() {
writeln(Resource disposed!);
//in opDispose the resource should dispose all it's 
resources too

foreach(res; used)
res.opDispose();
}

static Resource open(string name){
return new Resource;
}
}

with(auto resource = Resource.open(res1)){
//set properties of resource and call setup/init functions
}
resource.doStuff(); //use resource later too
resource.opDispose(); //you can manually dispose it

//or a scoped variant:
string[] data;
with(scoped!Resource res = Resource.open(res2)){
data = res.getData();
}//res gets out of scope and opDispose is called

if(cond){
scoped!Resource res = Resource.open(res3);
//do sth with res
}//get out of scope opDispose gets called and res gets destroyed

I think this dispose thing should be added to D, because it is a 
very common practice in C#(and not only). In the book I used to 
learn C# long ago I remember how they sayed like 100 of times: 
If you use an object that implements IDisposable ALLWAYS use it 
in an using statement. It is not a strange or not-intuitive 
feature. In fact it can make the scoped variables idea more 
popular. And instead of explicitly adding an using statement you 
just declare your variable as scoped and the compiler takes care 
of calling it's dispose automatically when it gets out of scope.


I think that's everything for now.

Re: request switch statement with common block


On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:

Am 05.08.2013 08:28, schrieb luminousone:

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
 assert( i == 0 );
}
out {
 assert( i == 9 );
}
body {
... stuff ...
}


that is just evil code

if you got something todo before or on the first item of the 
list do it before the loop - and for the last behind the for 
loop


if we talk about code-duplication then - use an inner function

this type of sub-branching de-looping is slow (if performance 
is relevant) and just not foreach-able, and so not 
functional-style programming - its called for loop index micro 
management for unknown reasons - but many programmers prefer 
it very much :)


I have been programming since '92 and I must say that I have 
never seen this before. Maybe I've just been lucky, but this kind 
of thing would never pass a review anywhere I have worked before. 
Code is a user interface, if the user's model differs from the 
system model you will get errors. I.e. Junior von Newhire should 
be able to correctly reason about any piece of the code from day 
one. If they cannot do so they will introduce bugs.

Re: Network server design question

2013-08-05 Thread Dmitry Olshansky

05-Aug-2013 00:59, Marek Janukowicz пишет:

Dmitry Olshansky wrote:
There are more things specific to this particular application that would
play a role here. One is that such real workers would operate on a common
data structure and I would have to introduce some synchronization. Single
worker thread was not my first approach, but after some woes with other
solutions I decided to take it, because the problem is really not in
processing (where a single thread does just fine so far), but in socket
read/write operations.

Then what will make it simple is the following scenario
X Input threads feed 1 worker thread by putting requests into one shared
queue.

You would have to use lock around it or get some decent concurrent queue
code (but better start with simple lock + queue)...

Got carried away ... you can just easily use std.concurrency message
passing (as *it is* an implicit message queue).

Then just throw in another writer thread that recieves pairs of
responses + sockets (or shared void* e-hm) from real worker.

The pipeline is then roughly:
Acceptor
--CREATES-- InputWorkers (xN)
--SEND REQ-- Real Worker
--SOCK/RESP-- Writer

2. Create separate thread per each client connection. I think this could
result in a nice, clean setup, but I see some problems:
- I'm not sure how ~50 threads will do resource-wise (although they will
probably be mostly waiting on Socket.select)

50 threads is not that big a problem. Around 100+ could be, 1000+ is a
killer.

Thanks for those numbers, it's great to know at least the ranges here.

The benefit with thread per client is that you don't even need
Socket.select, just use blocking I/O and do the work per each parsed
request in the same thread.

Not really. This is something that Go (the language I also originally
considered for the project) has solved in much better way - you can select
on a number of channels and have both I/O and message passing covered by
those.

They multiplex stuff in their runtime. In fact AFAIK they don't even
have clean-cut native threads. It would be interesting to see how they
handle it but I guess either self-pipe or event-driven + async I/O to
begin with.

In D I must react both to network data or message from worker
incoming, which means either self-pipe trick (which leads to Socket.select
again) or some quirky stuff with timeouts on socket read and message receive
(but this is basically a busy loop).

Sadly like others said with std.socket you get to witness the gory glory
of BSD sockets API that shows its age. Regardless it's what all major OS
directly provide.

Btw.
would it work if I pass a socket to 2 threads - reader and writer (by
working I mean - not running into race conditions and other scary concurrent
stuff)?

Should be just fine.
See also
http://stackoverflow.com/questions/1981372/are-parallel-calls-to-send-recv-on-the-same-socket-valid

Also I'm really puzzled by the fact this common idiom doesn't work in some
elegant way in D. I tried to Google a solution, but only found some weird
tricks. Can anyone really experienced in D tell me why there is no nice
solution for this (or correct me if I'm mistaken)?

The trick is that Socket/std.socket was designed way back before
std.concurrency. It's a class as everything back then liked to be.
The catch is that classes by default are mutable and thread-local and
thus can't be automatically _safely_ transfered across threads.

There were/are talks about adding some kind of Unique helper to
facilitate such move in a clean way. So at the moment - nope.

--
Dmitry Olshansky

Re: With statement become like C#'s using?


--snip--


Bosak:

class Resource { //can be any resource from files to streams to 
anything

Resource[] used;

void opDispose() {
writeln(Resource disposed!);


You should avoid doing IO in a destructor/finaliser. Writing to 
STDOUT can fail which may  lead to resource leaks (if it throws).


//in opDispose the resource should dispose all it's 
resources too

foreach(res; used)
res.opDispose();
}

static Resource open(string name){
return new Resource;
}
}


--snip--

Re: Cryptography

2013-08-05 Thread Larry


Thanks,

But,

1) By trusted, I meant : that one with good background used and 
thinks is good (i am not skilled enough to tell) - no memory 
leaks, no big f*g breach.


Well if it is cryptographically strong or not. Again, I cannot 
judge of it. But thanks to remind people to read before asking.


2) I might have missed it but Openssl doesn't enable people to 
crypt passwords, it enables us to secure the communication layer, 
does it?


Thanks,

Larry

D game development: a call to action

2013-08-05 Thread Jonathan A Dunlap

I am one of the few who have taken a keen interest in D for game 
development. The concise language and modern conveniences may be 
able to reduce many hours worth of development time off a game 
project, while making the code more maintainable. Aside from the 
core language, Dlang graphics bindings have a way to go before 
even earning acceptance in the indie gaming scene, but it's 
making great strides to get there.


The main challenge I've hit is the lack of any sort of path for 
adopting a media engine. Bindings (like SFML 
https://github.com/krzat/SFML-D) all suffer from:


A) No information about its current status: this is scary if its 
repo hasn't been updated in months.
B) Usually are complex to get working in a new project (manually 
building or searching for undocumented dependency DLLs)

C) Lack practical references and tutorials for real would usage
e.g. how to create an OpenGL window or how to render a 
triangle
versus something like how to load from disk an image texture 
onto a quad and move it around using keyboard events


SFML bindings are also in https://github.com/aldacron/Derelict3 
but I couldn't find a scrap of information on how to use it, how 
to compile correctly, or example usage. It's unclear if the 
library is even usable in its current state.


Please don't take this as blind criticism, but rather a plea to 
action for the community to provide better library documentation 
support for: current lib status, getting started adding it, and a 
general use tutorial/example. If we start doing this, it'll make 
a big impact for other game developers who are new to Dlang to 
adopt the language. Thanks for listening!

Re: Static unittests?


On Monday, 5 August 2013 at 17:30:38 UTC, monarch_dodra wrote:

static assert({int i; assert(i == 0;});


enum i;
static assert(i == 0);

I am really struggling to understand the use case.
D has a tool to force CTFE execution - `enum`. It has a tool for 
compile-time checks - `static assert`. Any possible compile-time 
test can be expressed via those. All assertCTFEable or similar 
tool adds is ability to save on some `static` markers.

Re: Static unittests?


On Monday, 5 August 2013 at 17:38:22 UTC, monarch_dodra wrote:
So sure, I guess that strictly speaking, no, D language doesn't 
have static unittests. However, when someone asks the question, 
if you just answer No without pointing out that the language 
allows this semantic:


version(unittest) assertCTFEAble!({
//YOUR CODE HERE
});

Then I believe you are giving an incomplete answer.


Well, the problem is, D does have static unit-tests in a form of 
`static assert`. But topic starter has immediately provided an 
example that shows that his understanding of static unit-tests 
is different one, making it pretty hard to reason about proper 
alternative.


Even assertCTFEAble does not _exactly_ match what was asked here. 
Thus I feel the need to first ask about specific use case and 
only then propose any real solutions.


So, yes, of course, it is incomplete - because question is 
incomplete and requires further clarification. Which is the main 
point.

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 17:45:25 UTC, Bosak wrote:
You say that D's destroy is not like C#'s IDisposable.Then why 
doesn't D then declare that kind of interface:

interface Disposable {
void dispose();
}


It _is_ similar but not exact match. 2 key differences:
1) destroy works on variety of types, not only classes
2) it puts the object into some invalid state
But you can still use class destructor instead of `dispose()` 
method.


But destroy() is considered a power tool that should be used only 
when absolutely needed. The very necessity to deterministically 
call some method opposes the concept of garbage collection - it 
is a sign of bad design and clear indicator that one should do a 
proper RAII here. I really think D approach here is much cleaner 
than C# one.

Re: Static unittests?


On Monday, 5 August 2013 at 18:15:22 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 17:30:38 UTC, monarch_dodra wrote:

static assert({int i; assert(i == 0;});


enum i;
static assert(i == 0);

I am really struggling to understand the use case.
D has a tool to force CTFE execution - `enum`. It has a tool 
for compile-time checks - `static assert`. Any possible 
compile-time test can be expressed via those. All 
assertCTFEable or similar tool adds is ability to save on some 
`static` markers.


You are working around the argument. The point is that some calls 
simply can't be reduced to a single call. How would you deal with 
testing parse then?


assertCTFEable!({ string s =  1234abc; assert(parse! int(s) ==  
1234  s == abc); });


The point is that you can write native runtime code, and then 
only CTFE test it once. It brings more than just saving on 
markers.


What about, for example:

assertCTFEable!({
int i = 5;
string s;
while (i--)
s ~= 'a';
assert(s == a);
});

And still, all of these are just simple cases.

Re: Static unittests?


On Monday, 5 August 2013 at 18:21:37 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 17:38:22 UTC, monarch_dodra wrote:
So sure, I guess that strictly speaking, no, D language 
doesn't have static unittests. However, when someone asks the 
question, if you just answer No without pointing out that 
the language allows this semantic:


version(unittest) assertCTFEAble!({
   //YOUR CODE HERE
});

Then I believe you are giving an incomplete answer.


Well, the problem is, D does have static unit-tests in a form 
of `static assert`. But topic starter has immediately provided 
an example that shows that his understanding of static 
unit-tests is different one, making it pretty hard to reason 
about proper alternative.


Even assertCTFEAble does not _exactly_ match what was asked 
here. Thus I feel the need to first ask about specific use case 
and only then propose any real solutions.


So, yes, of course, it is incomplete - because question is 
incomplete and requires further clarification. Which is the 
main point.


Alright. I tend to try to give as much information as possible in 
answers, even when the question isn't completely clear, or it was 
not exactly what was asked. With some luck, I can provide enough 
information to get the question answered, or give enough 
background to provide better understanding. This may or may not 
be the best thing to do, and sometimes it may indeed be better to 
stop and ask for clarification.


I'll agree my answer is not 100% exact, but I feel it does bring 
something to the conversation. In any case, while it was a 
reply/quote to what you said, it was not meant as a rebutal to 
what you were saying.

Re: Static unittests?


On Monday, 5 August 2013 at 18:27:02 UTC, monarch_dodra wrote:

...


Saying test CTFE function that mutates its arguments would have 
been perfectly enough for me :) Okay, that makes sense, thanks 
for the explanation.

Re: D game development: a call to action

On Mon, 05 Aug 2013 20:18:29 +0200, Jonathan A Dunlap wrote::
 
 A) No information about its current status: this is scary if its repo
 hasn't been updated in months.
 B) Usually are complex to get working in a new project (manually
 building or searching for undocumented dependency DLLs)
 C) Lack practical references and tutorials for real would usage
 e.g. how to create an OpenGL window or how to render a triangle
 versus something like how to load from disk an image texture onto a
 quad and move it around using keyboard events
 
 SFML bindings are also in https://github.com/aldacron/Derelict3 but I
 couldn't find a scrap of information on how to use it, how to compile
 correctly, or example usage. It's unclear if the library is even usable
 in its current state.
 
 Please don't take this as blind criticism, but rather a plea to action
 for the community to provide better library documentation support for:
 current lib status, getting started adding it, and a general use
 tutorial/example. If we start doing this, it'll make a big impact for
 other game developers who are new to Dlang to adopt the language. Thanks
 for listening!

A) I recommend using Derelict3--it's kept up to date, looking at the 
commit log shows work in the last 24 hours to update the bindings. It's 
also well designed and works well.
B) If using Derelict3, you simply need to: build Derelict3 (it's as 
simple as running build/build.d) and have recent builds of whatever 
libraries you're using through it.  How difficult the shared libraries 
dependencies are is project by project and not really a D-specific issue.
C) Derelict3 is basically just bindings over the C functions--you should 
use any and all documentation, references, and tutorials against the C 
libraries.  E.g. any C language tutorials on SFML, OpenGL, etc. are 
trivially translatable once you understand how to load the Derelict 
modules (again, look at the Derelict README).

Re: Static unittests?

2013-08-05 Thread Artur Skawina

On 08/05/13 20:27, monarch_dodra wrote:
 On Monday, 5 August 2013 at 18:15:22 UTC, Dicebot wrote:
 On Monday, 5 August 2013 at 17:30:38 UTC, monarch_dodra wrote:
 static assert({int i; assert(i == 0;});

 enum i;
 static assert(i == 0);

 I am really struggling to understand the use case.
 D has a tool to force CTFE execution - `enum`. It has a tool for 
 compile-time checks - `static assert`. Any possible compile-time test can be 
 expressed via those. All assertCTFEable or similar tool adds is ability to 
 save on some `static` markers.
 
 You are working around the argument. The point is that some calls simply 
 can't be reduced to a single call. How would you deal with testing parse 
 then?
 
 assertCTFEable!({ string s =  1234abc; assert(parse! int(s) ==  1234  s 
 == abc); });
 
 The point is that you can write native runtime code, and then only CTFE 
 test it once. It brings more than just saving on markers.
 
 What about, for example:
 
 assertCTFEable!({
 int i = 5;
 string s;
 while (i--)
 s ~= 'a';
 assert(s == a);
 });
 
 And still, all of these are just simple cases.

   static assert({
   int i = 5;
   string s;
   while (i--)
   s ~= 'a';
   return s == a;
   }());

etc

artur

Re: With statement become like C#'s using?


On Monday, 5 August 2013 at 18:29:09 UTC, Dicebot wrote:

On Monday, 5 August 2013 at 17:45:25 UTC, Bosak wrote:
You say that D's destroy is not like C#'s IDisposable.Then why 
doesn't D then declare that kind of interface:

interface Disposable {
   void dispose();
}


It _is_ similar but not exact match. 2 key differences:
1) destroy works on variety of types, not only classes
2) it puts the object into some invalid state
But you can still use class destructor instead of `dispose()` 
method.


But destroy() is considered a power tool that should be used 
only when absolutely needed. The very necessity to 
deterministically call some method opposes the concept of 
garbage collection - it is a sign of bad design and clear 
indicator that one should do a proper RAII here. I really think 
D approach here is much cleaner than C# one.


Well I don't know much stuff about GC and internals and if you 
think it is not a good design concept, ok I'm fine with it. I 
don't miss C#'s using statement or IDisposable. I was just 
giving a suggestion that would be discussed and considered with 
the community.


At least this with(declaration) syntax might make it into the 
language. And probably use the more strange one, where you only 
give it an rvalue:

with(new Foo) {
name = Foo; //same as temp.name
calc(); //same as temp.calc()
writeln(); //and even maybe this to be translated to 
temp.writeln() and then to writeln(temp) ?

}

Well that was everything I had to say about with, using, and 
dispose. I'm glad that there was a discussion going.

Re: D game development: a call to action


On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote:
I am one of the few who have taken a keen interest in D for 
game development. The concise language and modern conveniences 
may be able to reduce many hours worth of development time off 
a game project, while making the code more maintainable. Aside 
from the core language, Dlang graphics bindings have a way to 
go before even earning acceptance in the indie gaming scene, 
but it's making great strides to get there.


The main challenge I've hit is the lack of any sort of path for 
adopting a media engine. Bindings (like SFML 
https://github.com/krzat/SFML-D) all suffer from:


A) No information about its current status: this is scary if 
its repo hasn't been updated in months.
B) Usually are complex to get working in a new project 
(manually building or searching for undocumented dependency 
DLLs)
C) Lack practical references and tutorials for real would 
usage
e.g. how to create an OpenGL window or how to render a 
triangle
versus something like how to load from disk an image texture 
onto a quad and move it around using keyboard events


SFML bindings are also in https://github.com/aldacron/Derelict3 
but I couldn't find a scrap of information on how to use it, 
how to compile correctly, or example usage. It's unclear if the 
library is even usable in its current state.


Please don't take this as blind criticism, but rather a plea to 
action for the community to provide better library 
documentation support for: current lib status, getting started 
adding it, and a general use tutorial/example. If we start 
doing this, it'll make a big impact for other game developers 
who are new to Dlang to adopt the language. Thanks for 
listening!


Take a look at https://github.com/Jebbs/DSFML
The autor, aubade, me and few other guys are trying to maintain 
the project. I wrote a small tutorial on the wiki. And we have 
plans on documenting it, adding unittests and much more. The 
autor announced today that he will soon update the C bindings to 
SFML 2.1


If you have any problems using it just open an issue on github.

Re: D game development: a call to action

2013-08-05 Thread Jonathan A Dunlap

C) Derelict3 is basically just bindings over the C 
functions--you should
use any and all documentation, references, and tutorials 
against the C

libraries.


Thanks Justin for the response. Derelict3 does seem to be the 
library with the most activity by far. However, it's simply not 
good enough to just say that since these are just bindings that 
the documentation/examples in the host language is adequate. This 
is true under the assumption that: the developer already is 
comfortable in the D language to know the usage difference, are 
familiar with the lib API to know when these differences apply, 
or even know to translate dependent idioms outside the actual 
library usage (like loading an image from disk, to apply to a 
texture, may be a separate but related learned task to the 
library). If we are looking for a broader adoption of D, we 
should be in the mindset of someone who may not even have a 
background in computer science here.

Re: D game development: a call to action

2013-08-05 Thread Jonathan A Dunlap


Take a look at https://github.com/Jebbs/DSFML
The autor, aubade, me and few other guys are trying to maintain 
the project. I wrote a small tutorial on the wiki. And we have 
plans on documenting it, adding unittests and much more.


Great stuff, Borislav. The basic tutorial 
https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot to 
grok how to get your feet wet. I'm looking forward to seeing more 
tutorials like this.

Re: D game development: a call to action


On Monday, 5 August 2013 at 19:03:29 UTC, Jonathan A Dunlap wrote:

Take a look at https://github.com/Jebbs/DSFML
The autor, aubade, me and few other guys are trying to 
maintain the project. I wrote a small tutorial on the wiki. 
And we have plans on documenting it, adding unittests and much 
more.


Great stuff, Borislav. The basic tutorial 
https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot 
to grok how to get your feet wet. I'm looking forward to seeing 
more tutorials like this.


Thanks! Bear in mind that the autor is working on splitting the 5 
modules into separate files for each class. That is because 
currently everything is too cluttered into one file for each sfml 
sub-module. See the Experimental branch, it is almost done. After 
the change you would be able to more easily browse code and the 
only change you would have to make is in the imports. So instead 
of:

import dsfml.system; - import dsfml.system.all;
or import specific classes:
import dsfml.system.vector; //or something like that

Also about building and assembling everything together, see 
https://github.com/Jebbs/DSFML/issues/34
A build.d script is being worked on and things like adding more 
documentation, unittests and examples are being worked on too. 
Also an suggestion has been made to add dsfml to the DUB package 
manager(that is used by vibe.d) and is something similar to 
ruby's gems manager.


And now that Direlict has been mentioned, I suggest you to not 
use it for sfml. It is just a collection of c-bindings of popular 
libraries.

Re: D game development: a call to action

2013-08-05 Thread Namespace


I'm working currently on Dgame: http://dgame-dev.de/
I'm almost finished, but the documentation, the tutorials and the 
download there is not up to date, but that will change in the 
next few days (now that I had my last exam today).
My fellow students and I also work with Dgame on a 2D 
sidescroller. The work on it was stopped because of exams, but it 
will continue in the coming weeks.

Re: D game development: a call to action


...


Oh and I completely forgot to mention that I am working on a D 
version of the spine runtime (http://esotericsoftware.com/). If 
you haven't heard of it it is a 2D skeletal animation tool that 
exports to bin or json(other formats too). And there are many 
runtime libraries for many languages(currently no D support) and 
popular game engines. Although the tool isn't free ($70), it 
helps development A LOT. However the 'format' is open, so one 
could write his own editor/exporter.
Runtimes are usually split up in two - engine and renderer. The 
engine part is language-specific (for example C#) and it only 
parses the data into appropriate structires that the renderer 
will use later. The renderer part is gameengine-specific (for 
example Unity, XNA, MonoGame for C#) and uses the engine part's 
source. Then the renderer part just implements one or two classes 
that do the actual rendering and logic updates that are 
engine-specific.


And yeah, I decided to make a D runtime for spine:

https://github.com/nikibobi/spine-d - engine part (pure D)
https://github.com/nikibobi/spine-dsfml - renderer part (D + 
DSFML)


Also I forgot to mention that aubade made an separate repository 
for SFML extensions ported to D like sfMod and sfMidi


https://github.com/aubade/dsfml-contrib

Also about your original post you mentioned SFML-D and if you 
have looked the original SFML site's bindings 
page(http://www.sfml-dev.org/download/bindings.php) it is 
indicated that SFML-D is inactive. And there is Jebbs DSFML 
marked as active along with Direlict 3

Evangelizing Your Cool Product


This is a bit of a generic reply to a constant theme I see here.

It pains me to see a lot of great D projects languish in obscurity, and often 
the author(s) eventually get frustrated with that and abandon them.


The problem is that Field of Dreams, i.e. build it and they will come is a 
Hollywood fantasy. The authors simply must promote it. That means, at the barest 
minimum, writing a nice article that answers the basic questions:


   who
   what
   where
   when
   why
   how

and then getting that article published  promoted in social media, online 
magazines, etc. Note that online magazines are BEGGING for content. Some will 
even PAY MONEY for decent content.


Throwing code up on github isn't good enough. Expecting people to read the 
source code to figure out who/what/where/etc is never going to work. A one line 
announcement Hi! I just released Dx! Enjoy! is going to fail. Hoping that 
others will pick up the flag and carry it for you is a pipe dream.


I know that people often are reluctant to promote their own stuff because they 
feel it's immodest. All I can say is get over it! Look at Donald Trump, Steve 
Jobs, Gene Simmons, Jeff Bezos, Elon Musk, etc. None of them are/were remotely 
shy about promotion.


Besides, it's fun when others read one's articles and comment on them, a lot 
more fun than waiting to be discovered.

Re: D game development: a call to action


On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote:

I'm working currently on Dgame: http://dgame-dev.de/
I'm almost finished, but the documentation, the tutorials and 
the download there is not up to date, but that will change in 
the next few days (now that I had my last exam today).
My fellow students and I also work with Dgame on a 2D 
sidescroller. The work on it was stopped because of exams, but 
it will continue in the coming weeks.


Wow that's great news! I will try it and maybe try to help you 
test it and improve it. I will look more into it tomorrow when I 
have more time. But from the first looks, I like the site design 
and the engine looks a lot like SFML(a good thing).

Re: D game development: a call to action

On Mon, 05 Aug 2013 20:59:32 +0200, Jonathan A Dunlap wrote:

 C) Derelict3 is basically just bindings over the C functions--you
 should use any and all documentation, references, and tutorials against
 the C libraries.
 
 Thanks Justin for the response. Derelict3 does seem to be the library
 with the most activity by far. However, it's simply not good enough to
 just say that since these are just bindings that the
 documentation/examples in the host language is adequate. This is true
 under the assumption that: the developer already is comfortable in the D
 language to know the usage difference, are familiar with the lib API to
 know when these differences apply, or even know to translate dependent
 idioms outside the actual library usage (like loading an image from
 disk, to apply to a texture, may be a separate but related learned task
 to the library). If we are looking for a broader adoption of D, we
 should be in the mindset of someone who may not even have a background
 in computer science here.

All Derelict3 usage differences are clearly documented in a wonderfully 
short section in the README.  I don't think it's a problem to assume that 
someone who wants to write a video game in the D programming language 
has a basic working knowledge of D and of the various aspects of language 
agnostic game programming; i.e. documentation on how to invent the 
universe should not be a prerequisite for baking an apple pie.

That said, I will seriously consider writing an article on getting 
started with modern OpenGL with Derelict3.

Re: request switch statement with common block

2013-08-05 Thread ron


On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
   ... before stuff ...
}
out {
    after stuff ...
}
body {
   case 1:
   in {
  ... etc 
   }
   out {
  ... more etc ...
   }
   body {
  ...
   }
   case 2:
 // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
   assert( i == 0 );
}
out {
   assert( i == 9 );
}
body {
  ... stuff ...
}

if it is desired for a particular contract block to be called 
in release builds perhaps a attribute label to mark it as a 
runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
...
}
body {
}


Please do not take offense, but I do not see this as a good 
idea. Contracts have a very different function; not just in D, 
but every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs for 
the purposes proposed here would, in my opinion, cause 
confusion and/or weaken the proper use of contract programming.



The code in the contract conditions should never do anything 
more than what is necessary to specify the contract. It should 
not do explicit IO (other than implied by assert()), mutate 
state, or anything like that.


At the bottom of this page you can find a reading list for more 
info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do 
any static analysis on the contracts? Such as a void 
safety/null reference check?


None taken, =-p.

I don't see how this is different from current contract usage, 
right now they apply to function scopes only. currently I believe 
you could get a similar effect via using an inner function.


void a() {
   int i = 0;
   void b()
   in {
  assert( i == 0 );
   }
   out {
  assert( i == 10 );
   }
   body {
  for( ; i  10 ; i ++ ) {
 ... do something ...
  }
   }
   b();
}

Re: Cryptography

2013-08-05 Thread Kapps


On Monday, 5 August 2013 at 16:52:39 UTC, Larry wrote:

Hello,

I would like to know how we can trust this source concerning 
scrypt :


http://code.dlang.org/packages/scrypt-d

And second : will there be any official package in D ?

The same goes for bcrypt and sha2 cryptographic algo.

Thanks,

Larry


Looks to me like it's just a wrapper around a C library, so it's 
not really whether you can trust that source as it is whether you 
can trust the C library.

Re: D game development: a call to action

2013-08-05 Thread Namespace


On Monday, 5 August 2013 at 19:47:40 UTC, Borislav Kosharov wrote:

On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote:

I'm working currently on Dgame: http://dgame-dev.de/
I'm almost finished, but the documentation, the tutorials and 
the download there is not up to date, but that will change in 
the next few days (now that I had my last exam today).
My fellow students and I also work with Dgame on a 2D 
sidescroller. The work on it was stopped because of exams, but 
it will continue in the coming weeks.


Wow that's great news! I will try it and maybe try to help you 
test it and improve it. I will look more into it tomorrow when 
I have more time. But from the first looks, I like the site 
design and the engine looks a lot like SFML(a good thing).


Yes SFML was one of my inspirations. I'll hurry to bring 
everything up to date. And of course I'd be happy about any help. 
;)

Another use-case for multiple alias this

2013-08-05 Thread Andrej Mitrovic

I've noticed something that's happening in many D libraries, some data
structures are constantly being reinvented. The classic example is the
Rectangle struct.

For example, CairoD defines a Rect struct, but so do other libraries
like DGui, Qtd, and practically any library which has to deal with
drawing something on the screen.

The problem when using multiple libraries, is that you end up having a
hard time interacting with these libraries when you have to take care
which exact Rect structure you can pass to some library function, for
example:

-
// library code
void fooLibDrawRect(Rect rect);  // actually takes foo.rect
void barLibDrawRect(Rect rect);  // actually takes bar.rect

// user code
import foo;
import bar;
void main()
{
fooLibDrawRect(Rect(...));  // usually a symbol error if there's 2
different Rect definitions
}
-

So the current fix for this is to use either explicit symbol lookup or
to introduce aliases:

-
import foo;
import bar;
alias FooRect = foo.Rect;
alias BarRect = foo.Rect;

void main() {
fooLibDrawRect(FooRect(...));
barLibDrawRect(BarRect(...));
}
-

If we had multiple alias this support, then the user could introduce
his own Rect struct that wraps all the other Rect structs to make
using the actual libraries much simpler:

-
struct Rect  //
{
int x, y, width, height;

/* These might do conversions if necessary,
or they could use a static cast of the this object */
@property auto getFooRect() { return foo.Rect(...); }
@property auto getBarRect() { return bar.Rect(...); }

alias getFooRect this;
alias getBarRect this;
}

void main() {
fooLibDrawRect(Rect(...));  // works
barLibDrawRect(Rect(...));  // also works
}
-

I think this would be a major selling point for D.

And in fact multiple alias this is a feature we've practically all
agreed on, but what's holding it from being finally implemented?

atomicLoad/Store

2013-08-05 Thread zyhong

From my understanding, any data type that is less than 32bit 
(bool, char, int, etc) is atomic and there is no need to use 
atomicLoad/Store and read/write the data to be thread safe. In 
std.parallelism, I saw it use atomicLoad/Store for any shared 
data. Could anyone clarify if it is really necessary to 
atomicLoad/Store to read/write data that datatype is bool, int, 
byte, etc?

Re: Ironclad C++

2013-08-05 Thread Kagamin


On Sunday, 4 August 2013 at 15:04:48 UTC, Timon Gehr wrote:


- No naming or scoping:


OK, but I'm not sure naming and scoping buys you anything except 
for being more explicit, but explicity vs implicity is a tradeoff.
I kinda understand the argument about dependent purity, but the 
problem with purity arises mostly in generic code consuming 
arbitrary ranges, the problem with delegate purity looks minor.
As to the crash, it looks like it tries to mess with the 
delegate's signature, which it souldn't do: delegate's signature 
doesn't participate in const transitivity rules. The cost is 
probably one if at the right place.



- Only works for parameters or stack based variables:


Not a failure to not do what is not proved to be possible and 
acceptable. Const system doesn't interoperate with templates 
well. You don't have a solution either, even with your universal 
notation, right?



- Plain unsoundness of current type checking approach:


Closures were not covered in DIP2 (I agree, that was a major 
overlook). Closured variables should be treated as external to 
the closure and either be seen as const or require cast to const. 
Fix may be non-trivial, but possible.


I was thinking to call for lore about issues with inout and solve 
them, also for other people, who want to work on the type system 
to have an estimate of the problem's scale. Am I late?

Re: bug reporting

2013-08-05 Thread captaindet


On 2013-08-03 18:29, captaindet wrote:

recently i inadvertently created some noise in the bug
reporting/tracking system. i had run into an ICE after using
'__MODULE__' in a certain way. before reporting the bug, i did enter
'__MODULE__' in the search mask of the tracking system but got no
hit. so i thought it was a new issue and reported it. turns out this
bug was reported before and the issue was resolved 2 weeks ago. what
i did not know then (but found out now) was that after the 0-hit
search i should have clicked the innocent looking 'edit search' link,
which is actually an 'advanced search' feature - then latest* i would
have realized that the default search excluded resolved issues,
activated them, and then found out about the issue being reported and
resolved already.

i think it is an easy pit to fall into, at least for first time
reporters. i'd like to suggest some improvements to the tracking
interface:

1 'edit search' should be 'advanced search' as it is the standard
name for this 2a make the default search to include resolved issues
or b even let the 'report new bug' link direct to the advanced search
already or c put up a brief explanation how ppl have to search the
database properly before reporting a bug

i felt sorry for having wasted my time with reporting a resolved
issue and even worse of course for having wasted some developer's
time for straightening the records.

/det


* yes, the default search results list which bug statuses were
included in the search and that 'resolved' or 'closed' was not among
them...but it is so easy to overlook something that is not there...


i just realized the the actual entry point for the issue tracking, i.e.
http://d.puremagic.com/issues
is much more helpful/useful than the bug reporting link put on the dlang 'bug 
tracker' webpage  ( http://dlang.org/bugstats.php ), i.e.
http://d.puremagic.com/issues/enter_bug.cgi?product=D
with the latter, as far as i can see, being the only link from dlang to the 
issue tracker. weird. i think dlang should link to the overview page of the 
issue tracker (first of the two links above).

/det

Re: request switch statement with common block


On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:

On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
  ... before stuff ...
}
out {
   after stuff ...
}
body {
  case 1:
  in {
 ... etc 
  }
  out {
 ... more etc ...
  }
  body {
 ...
  }
  case 2:
// and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
  assert( i == 0 );
}
out {
  assert( i == 9 );
}
body {
 ... stuff ...
}

if it is desired for a particular contract block to be called 
in release builds perhaps a attribute label to mark it as a 
runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
...
}
body {
}


Please do not take offense, but I do not see this as a good 
idea. Contracts have a very different function; not just in D, 
but every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs for 
the purposes proposed here would, in my opinion, cause 
confusion and/or weaken the proper use of contract programming.



The code in the contract conditions should never do anything 
more than what is necessary to specify the contract. It should 
not do explicit IO (other than implied by assert()), mutate 
state, or anything like that.


At the bottom of this page you can find a reading list for 
more info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do 
any static analysis on the contracts? Such as a void 
safety/null reference check?


None taken, =-p.

I don't see how this is different from current contract usage, 
right now they apply to function scopes only. currently I 
believe you could get a similar effect via using an inner 
function.


void a() {
   int i = 0;
   void b()
   in {
  assert( i == 0 );
   }
   out {
  assert( i == 10 );
   }
   body {
  for( ; i  10 ; i ++ ) {
 ... do something ...
  }
   }
   b();
}


Speaking of contracts, and reading the docs I see:
Pre and Post Contracts

The pre contracts specify the preconditions before a statement is 
executed. The most typical use of this would be in validating the 
parameters to a function. The post contracts validate the result 
of the statement. The most typical use of this would be in 
validating the return value of a function and of any side effects 
it has...


So are contracts possible outside function declarations? For 
example just scopes or random places in code.

Re: bug reporting

2013-08-05 Thread Jesse Phillips


On Monday, 5 August 2013 at 20:44:07 UTC, captaindet wrote:
i just realized the the actual entry point for the issue 
tracking, i.e.

http://d.puremagic.com/issues
is much more helpful/useful than the bug reporting link put on 
the dlang 'bug tracker' webpage  ( 
http://dlang.org/bugstats.php ), i.e.

http://d.puremagic.com/issues/enter_bug.cgi?product=D
with the latter, as far as i can see, being the only link from 
dlang to the issue tracker. weird. i think dlang should link to 
the overview page of the issue tracker (first of the two links 
above).


/det


Enter a bug report :)

Re: With statement become like C#'s using?

2013-08-05 Thread Gambler

On 8/5/2013 11:30 AM, Bosak wrote:
 On Monday, 5 August 2013 at 13:54:38 UTC, Adam D. Ruppe wrote:
 On Monday, 5 August 2013 at 13:42:01 UTC, Michal Minich wrote:
 But what Bosak proposes is that when with statements ends, the
 object should be destructed

 That would happen if the object is a struct, or wrapped in a struct,
 since it would go out of scope at the end of the with and call its
 destructor then.

 So then you could just go

 import std.typecons;
 with(auto a = Scoped!T()) { ... }

 and the Scoped destructor does the deleting.
 
 Exactly. My idea is to add third use case of with. Not there are 2 ways
 to use with(of witch I know):
 
 1) Declare something and use with to not repeat yourself:
 auto foo = new Foo;
 with(foo) {
name = bar; //foo.name = bar;
 }
 In this case it is only used for object construction and setup. And the
 with statement doesn't destruct the object or anything like that.
 2) Used with types
 struct Foo {
 static int bar = 2;
 }
 with(Foo) {
 bar++; //Foo.bar++;
 }
 Again with doesn't destruct or anything
 
 All of the above are currently available, but I want a third case to be
 added:
 
 3) Used when you declare something in the with statement with scope only
 in the with statement
 with(Foo foo = new Foo) {
 name = bar;
 }
 After that foo's destructor gets called and since foo was in the scope
 of with it goes out of scope and no references are made to foo. There
 should be a constraint that you cannot take the address of foo in the
 with statement(i.e assign a global to foo)
 3.1) Or used with rvalues??
 int[] values;
 with(new Foo) {
 name = bar;
 values = getData(); //foo.getData()
 }
 //use values taken from foo
 
 I think that in case 3.1 it is very intuitive for using resources like
 files. Instead of writing something like:
 string text;
 auto file = open(myfile.txt, r);
 text = t.readlines();
 file.close();
 You can write this:
 string text;
 with(open(myfile.txt, r)) { //no need to declare variable
 text = readlines(); //just use the file to get the data
 }//with automaticaly calls close() on the file, even if exception got
 thrown
 And if the exception got thrown in the declaration of the with block,
 then the with block doesn't execute. For example in the above code if
 the file didn't exist, an exception would be thrown from open and no
 variable would be created.
 
 I hope that I have made my suggestion more clear.

IMO, using statements in C# are annoying. They make otherwise linear
code much harder to read. The *idea* behind them makes total sense, but
I dislike the implementation. Instead of writing this:

public string[] GetLines(string name)
{
string result;
using (var file = new File(name))
{
result = file.ReadText();
}
return result.split('\n');
}

...I would very much like to write this:

public string[] GetLines(string name)
{
autodispose var file = new File(name1);
string result = file.ReadText(); //file disposed after this line,
since it's the last place it's used
return result.split('\n');
}

Another problem with C#'s using (){} is that it doesn't easily scale
from single-method use to object-wide use. For example, would you want
to add using statements to every single method in a controller just
because all of them use the same database object?

Re: Ironclad C++

2013-08-05 Thread Kagamin


On Sunday, 4 August 2013 at 16:18:48 UTC, bearophile wrote:
I am starting to think that to design type system features 
sometimes you need formal mathematics, otherwise you build a 
Swiss cheese.


How would you account for yet undefined features like ARC?

Re: Article on programming language adoption (x-post from /r/programming)

2013-08-05 Thread Gambler

On 8/1/2013 9:21 AM, Dicebot wrote:
 They see more value in unit
 tests than types, both overall and as a debugging aid. Fur-
 thermore, how features are presented strongly influences
 developer feelings about them, such as prioritizing class in-
 terfaces much higher than static types
 
 Stop the world, I want to get out!

This does not surprise me. TDD has been sold as One True Way of
programming for decades now. A lot of modern developers just throw the
code (and tests, which are also code) at the problem until it seems
solved. Using type system or declarative functional programming to
eliminate certain errors is often not considered during development.

Re: Evangelizing Your Cool Product


On Monday, 5 August 2013 at 19:44:12 UTC, Walter Bright wrote:

This is a bit of a generic reply to a constant theme I see here.

It pains me to see a lot of great D projects languish in 
obscurity, and often the author(s) eventually get frustrated 
with that and abandon them.


The problem is that Field of Dreams, i.e. build it and they 
will come is a Hollywood fantasy. The authors simply must 
promote it. That means, at the barest minimum, writing a nice 
article that answers the basic questions:


   who
   what
   where
   when
   why
   how

and then getting that article published  promoted in social 
media, online magazines, etc. Note that online magazines are 
BEGGING for content. Some will even PAY MONEY for decent 
content.


Throwing code up on github isn't good enough. Expecting people 
to read the source code to figure out who/what/where/etc is 
never going to work. A one line announcement Hi! I just 
released Dx! Enjoy! is going to fail. Hoping that others 
will pick up the flag and carry it for you is a pipe dream.


I know that people often are reluctant to promote their own 
stuff because they feel it's immodest. All I can say is get 
over it! Look at Donald Trump, Steve Jobs, Gene Simmons, Jeff 
Bezos, Elon Musk, etc. None of them are/were remotely shy about 
promotion.


Besides, it's fun when others read one's articles and comment 
on them, a lot more fun than waiting to be discovered.


Wow Walter, your post really motivated me right now. For a few 
days I have this idea about an next gen OS. I only told it to my 
friends and I haven't written it anywhere(but I was planing to). 
Now I will probably create a blog and start writing programming 
articles and explaining ideas I have and projects I work on. But 
the thing that you said about promoting counts for D too. The D 
community is rather small compared to other languages. But in 
recent days I see more and more people starting talking about it. 
From time to time I see a post about D in reddit and probably 
Dconf '13 boosted the growth. I really hope that D one day 
becomes a success and I will try to write and promote D too in my 
non-currently-existent blog :)

Re: request switch statement with common block

2013-08-05 Thread luminousone


On Monday, 5 August 2013 at 20:45:47 UTC, Borislav Kosharov wrote:

On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:

On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
 ... before stuff ...
}
out {
  after stuff ...
}
body {
 case 1:
 in {
... etc 
 }
 out {
... more etc ...
 }
 body {
...
 }
 case 2:
   // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
 assert( i == 0 );
}
out {
 assert( i == 9 );
}
body {
... stuff ...
}

if it is desired for a particular contract block to be 
called in release builds perhaps a attribute label to mark 
it as a runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
...
}
body {
}


Please do not take offense, but I do not see this as a good 
idea. Contracts have a very different function; not just in 
D, but every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs 
for the purposes proposed here would, in my opinion, cause 
confusion and/or weaken the proper use of contract 
programming.



The code in the contract conditions should never do anything 
more than what is necessary to specify the contract. It 
should not do explicit IO (other than implied by assert()), 
mutate state, or anything like that.


At the bottom of this page you can find a reading list for 
more info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do 
any static analysis on the contracts? Such as a void 
safety/null reference check?


None taken, =-p.

I don't see how this is different from current contract usage, 
right now they apply to function scopes only. currently I 
believe you could get a similar effect via using an inner 
function.


void a() {
  int i = 0;
  void b()
  in {
 assert( i == 0 );
  }
  out {
 assert( i == 10 );
  }
  body {
 for( ; i  10 ; i ++ ) {
... do something ...
 }
  }
  b();
}


Speaking of contracts, and reading the docs I see:
Pre and Post Contracts

The pre contracts specify the preconditions before a statement 
is executed. The most typical use of this would be in 
validating the parameters to a function. The post contracts 
validate the result of the statement. The most typical use of 
this would be in validating the return value of a function and 
of any side effects it has...


So are contracts possible outside function declarations? For 
example just scopes or random places in code.


I being zero is the precondition for that loop, and i being 10 is 
the post condition for that loop.


Pretty much I think that any scope can potentially fit the 
definition for contracts.


Really any block of code, can be considered to have pre and post 
conditions, functions just happen to be one way to organize code.

Re: request switch statement with common block