date:20130814


On Wednesday, 14 August 2013 at 12:09:27 UTC, Dejan Lekic wrote:
Speaking about PHP... I believe we all read that article. I 
could say worse about ASP than what that article says about PHP.


That doesn't mean that ASP is worse than PHP though. PHP is so 
bad that I've actually considered offering up my time pro-bono to 
rewrite sites written in PHP to pretty much anything else.


The only thing that excites me more than seeing PHP die is seeing 
IE6/7/8 die, and that's already happening. =D

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 19:55:52 UTC, ilya-stromberg 
wrote:
On Wednesday, 14 August 2013 at 19:23:51 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 21:11, Andrei Alexandrescu wrote:

I'm thinking some people may need to stream to/from large 
files and

would find the requirement of in-core representation limiting.


Yes, I understand that. But currently I'm limited by std.xml.


Can you use another serialization format and supports file 
output for it? For example, can you use JSON, BSON or binary 
format?


That's often not possible, especially when working with an 
external API.


When working with large files, it's much better to read the file 
in chunks so you can be processing the data while the platters 
are seeking. This isn't as big of a problem with SSDs, but you 
still have to wait for the OS. RAM usage is also an issue, but 
for me it's less of an issue than waiting for I/O.


Even if rotating media were to be phased out, there's still the 
problem of streaming data over a network.


std.xml will be replaced, but it shouldn't require breaking code 
to fix std.serialize.

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread Adam D. Ruppe

On Thursday, 15 August 2013 at 01:03:24 UTC, Tyler Jameson Little 
wrote:
However, Windows doesn't have this workflow, so mirroring the 
entire desktop became necessary.


It does now, Server 2008 I think was the first one, or maybe 
Windows 7, they call it Seamless RDP.


In a widget toolkit, I think the same applies: make just enough 
controls that most people are satisfied, then make the toolkit 
easy to extend with custom controls.


Yeah, and that's a much more modest goal too.

BTW I spent a couple more hours on my crappygui.d today. No 
network transparency here, just drawing non-native widgets. So 
yeah it sucks, but it is small, simple, and standalone. Take a 
look at this screenie!


http://arsdnet.net/gui2.png

My keyboard is literally falling apart and backspace doesn't work 
in the text edit yet (big downside of non-native widgets, the 
behavior is hard to get right)... so not much of an edit lol... 
but yeah it is moving along. I think by the end of this weekend, 
it will be good enough for me and I'll put the code on my misc 
github.


The event model is lifted from javascript:

 button.addEventListener("click", { window.close(); });

and mouseenter, keydown, etc. are implemented too. It does the 
capture, bubble, preventDefault, stopPropagation, just like the 
w3c dom. I kinda like that model.

Re: Request: a more logical static array behavior


On Thursday, 15 August 2013 at 01:05:54 UTC, Tommi wrote:

On Thursday, 15 August 2013 at 00:57:26 UTC, Tommi wrote:

...


And half the time I say "converted to int[]" I mean "converted 
to uint[]" and the other half of the time I mean "converted to 
char[]". Sorry about that.


Actually that's not true either. Whenever I say 'int' after the 
examples start, just think 'char'.

Re: Request: a more logical static array behavior


On Thursday, 15 August 2013 at 00:57:26 UTC, Tommi wrote:

...


And half the time I say "converted to int[]" I mean "converted to 
uint[]" and the other half of the time I mean "converted to 
char[]". Sorry about that.

Re: Ideas for a brand new widget toolkit


On Wednesday, 14 August 2013 at 17:35:24 UTC, Joakim wrote:
While remote desktop is decent, it's trying to do too much: 
mirroring an entire desktop is overkill.  Better to use a lean 
client that handles most situations.


Maybe this is because I'm used to Linux, but I generally just 
want to forward an application, not the entire desktop. On Linux, 
this is trivial:


$ ssh -X user@host
$ gui-program 

However, Windows doesn't have this workflow, so mirroring the 
entire desktop became necessary.


Simpler is usually better, as long as simpler doesn't prevent you 
from creating something robust on top.


In a widget toolkit, I think the same applies: make just enough 
controls that most people are satisfied, then make the toolkit 
easy to extend with custom controls.

Request: a more logical static array behavior

Disclaimer: I'm going to be excruciatingly explicit here just so 
that everybody can follow my train of thought.


References:
1) Subtype/Supertype: http://en.wikipedia.org/wiki/Subtyping

2) Type deduction: 
http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-/Stephan-T-Lavavej-Core-C-2-of-n


3) Range: http://dlang.org/phobos/std_range.html#isInputRange

---
e.g. = "for example"

Static array, e.g. int[3], is not a range.
Dynamic array, e.g. int[], is a range.

int[] is not a supertype of int[3].

Non-subtype type: "type that is not a subtype of any other type"

Static array types are somewhat magical in D; they can do 
something that no other non-subtype type can do: static arrays 
can implicitly convert to another type during type deduction. 
More specifically, e.g. int[3] can implicitly convert to int[] 
during type deduction.


Here's an example of this:

module test;

enum Ret { static_array, dynamic_array, input_range }

Ret foo(T)(T[3] sa) // [1]
if (is(T == uint))
{
return Ret.static_array;
}

Ret foo(T)(T[] da) // [2]
{
return Ret.dynamic_array;
}

enum uint[3] saUints = [0, 0, 0];
enum char[3] saChars = [0, 0, 0];
static assert(foo(saUints) == Ret.static_array);  // [3]
static assert(foo(saChars) == Ret.dynamic_array); // [4]

---
[3]: A perfect match is found in the first overload of 'foo' [1] 
when its template type parameter 'T' is deduced to be an int. 
Then, the type of the function parameter 'sa' is exactly the same 
as the type of the argument 'saUints'.


[4]: No perfect match is found. But, because 'saChars' is a 
static array, the compiler gives all 'foo' overloads the benefit 
of the doubt, and also checks if a perfect match could be found 
if 'saChars' were first converted to a dynamic array, int[] that 
is. Then, a perfect match is found for int[] in the second 
overload of 'foo' [2] when 'T' is deduced to be an int.


Now, let's add to the previous example:

import std.range;

Ret bar(T)(T[3] sa) // [5]
if (is(T == uint))
{
return Ret.static_array;
}

Ret bar(R)(R r) // [6]
if (std.range.isInputRange!R)
{
return Ret.input_range;
}

static assert(bar(saUints) == Ret.static_array); // [7]
static assert(bar(saChars) == Ret.input_range);  // [8]

---
[7]: This is effectively the same as [3]
[8]: This line throws a compile-time error: "template test.bar 
does not match any function template declaration". Compare this 
to [4]: for some reason, the compiler doesn't give the second 
overload of 'bar' [6] the benefit of the doubt and check to see 
if the call to 'bar' could be made if 'saChars' were first 
converted to int[]. Were the compiler to consider this implicit 
conversion as it does in [4], then it would see that the second 
overload of 'bar' [6] could in fact be called, and the code would 
compile.


Thus, my point is this:
Shouldn't this magical property of static arrays (implicitly 
converting to dynamic array during type deduction) extend to all 
type deduction situations?


I think this would be a breaking change.


NOTE:
Subtypes can implicitly convert to their supertype during type 
deduction, there's nothing magical about that.

Re: qtD

2013-08-14 Thread michaelc37

On Wednesday, 14 August 2013 at 07:20:14 UTC, Benjamin Thaut 
wrote:

Am 01.08.2013 16:36, schrieb michaelc37:


I compiled against Qt4, I want to try it on Qt5 soon but there 
is
another annoying issue I discovered when trying to update and 
compile
all of the qtd exmples: All slot functions must now be 
declared public..

I'm guessing something changed in traits recently.



Yes since dmd 2.061 typeof no longer works on members you don't 
have access to. But it is possible to bypass this using the 
tupleof property. See typeOfFieldImpl in


https://github.com/Ingrater/druntime/blob/master/src/core/traits.d

Kind Regards
Benjamin Thaut


Thanks, i just tried this but it didnt work as i expected or 
maybe i misunderstood.



e.g.

class Test
{
private void aa(){};
private int bb;
public void cc(){};
}

writeln(Test.tupleof.length);  //prints 1
writeln(Test.tupleof[0].stringof);  //prints (Test).bb

it didnt see aa(), or cc()

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread Rikki Cattermole


On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:

Hello everyone,

These days I've been searching for a cross-platform IDE for D 
and I found out that there aren't any viable standalone 
options. After a few clicks, I've ran over this topic: 
http://forum.dlang.org/thread/astrlgbptrlvcdicq...@forum.dlang.org 
and it wasn't a surprise to see there are other people 
searching for the very same thing.One of the reasons for the 
absence of such IDEs is that there are no widget toolkits 
written in D except DWT, but some people are complaining about 
DWT for being a clone of SWT and that clients will want DWT to 
be in sync with SWT since SWT is a "marketing paradigm". As 
such, I want to embark on a long journey of writing a new 
widget toolkit from scratch.


Here are the ideas that people came up with so far(sorry if I 
omitted something):


evilrat:
* we need a truly D UI(not wrapper) first
* there are almost no declarative cross platform(i mean major 
OS) toolkit for writing simple yet highly customizable UI's, 
with HTML markup-like,
customizable UI's without messing with 
imperative(C/C++/D/whatever) code


eles:
* a D-ported version of a rather anonymous toolkit won't be 
shaded by the original

* evolution is slower, so not a fast-moving target
* the team behind that toolkit will be more than glad to help, 
as their toolkit will gain in popularity, and could even be 
converted to D-development (instead of C or C++ or whatever)

* re-write FOX tk in D, not to bind to it
* drivers as the lower bound in my original post. The rest 
should be drawn...


Trvhgoy:
* define the layout with a markup language like XAML or XUL for 
example and the styling with a CSS-like definition.


Mike Parker:
* Harmonia might be a good place to start: 
http://harmonia.terrainformatica.com/doku.php


Chris:
* a UI tool like Glade or Interface Builder is indispensible

Jacob Carlborg:
* You would still need to some graphics primitives. Do you want 
to implement them yourself as well? I mean, you have to draw 
the line somewhere. There's always a layer beneath you that you 
rely on, if you're not doing embedded or similar.

* you want a non-native toolkit.
* primitives would be implemented on top of OpenGL or DirectX. 
OpenGL is implemented in the graphics drivers, don't know how 
it works with DirectX.


Now let me complete these notes:

* I think that porting an anonymous toolkit to D will do more 
harm than good because if the original project was lacking some 
features then clients will think that the ported version lacks 
them as well. If we want to take this route then, besides 
Harmonia and FOX tk, we might borrow things from FLTK(Fast 
Light Toolkit)
* If the projects starts from zero, with its own design and is 
"shiny new" then people will be more attracted.
* Even if we don't port a toolkit we can still get inspired to 
see how they interact with the underlying system. For example, 
we can take a look over the SDL way of handling input.
* for drawing primitives we can use Cairo(curently used by GTK) 
or libX11 on linux and Directx on windows.Bindings for cairo 
and libX11 are provided by Deimos. I'm not sure if we can use 
OpenGL because it requires a rendering window or it renders in 
fullscreen mode.That rendering window can be provided by other 
toolkits but I don't think we want to depend on them. The OS 
window manager(xorg on linux) needs to keep track of the things 
it draws on its root window or surface and must be aware what 
to clean-up after you close your program. So the layer beneath 
this widget toolkit on Linux would be X(libX11).
* XAML is being developed by Microsoft and XUL by Mozzilla. I 
think XUL is a better choice for a markup language and more 
friendlier with an open source toolkit. It would be pretty nice 
if we can make the GuiParser and abstract class and provide an 
implementation for XUL because that will allow us to write an 
implementation for the QML(Qt) aswell or other flavors of 
layout and style files.
* If we want the project to scale up nicely then we should do 
things by the book. That is doing some research to see what 
technologies are involved, what the client programmers 
want(this thread) and then write some specs.
* After we have the specs then we can start designing the 
toolkit using UML diagrams such that we will end up with a 
clean API and avoid future re-factoring. For UML designs, I 
recommend this web app https://www.draw.io/ which saves its 
files in XML format and we can store them in the git repository.
* Only after we have a good design we will begin the actual 
coding.
* there is this 3D modelling tool called Blender which has a 
modern-looking UI. People have been wondering if that GUI can 
be used as a library and the answer is no because the gui is 
harcoded into Blender. If our default ui look resembles that 
one(not necessarily identical) then we will gain more 
clients.Maybe we can even get support from its huge community 
of artists. Ta

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Brian Rogoff


On Wednesday, 14 August 2013 at 19:24:43 UTC, w0rp wrote:
As mentioned before, for very common lambdas that you don't 
want to type yourself, you could define those functions as 
generic functions with a given name, like a 'less' function.


Also as mentioned before, the issue is that (anonymous) lambda 
functions have some subtle issues in regards to templates, 
because lambda functions cannot be compared for equality (the 
problem in general is undecidable) while string lambdas can, even 
though they have the same problem as with some of the unwieldy 
attempts at comparison (AST comparison after normalization and 
renaming with De Bruijn indices, or whatever), namely that things 
that are obviously equal aren't seen as such. That's why you want 
to name functions, so that templates instantiated with the same 
function are interoperable.


It seems to me that the easiest solution for D would be to 
deprecate string lambdas, and declare that anonymous lambdas 
always compare to false. Is the workaround of naming lambdas 
being used in in separate template instantiations that need to 
work together so bad?

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 21:40, H. S. Teoh wrote:


Would it be possible to present a range *interface*, that currently just
converts to array (or aliases to array if it's already an array), so
that in the future, when std.xml is revamped to use ranges, existing
code will automatically reap the benefits?


Since std.xml returns the data as a string, you mean I just forward the 
range interface to this string?


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread ilya-stromberg

On Wednesday, 14 August 2013 at 19:23:51 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 21:11, Andrei Alexandrescu wrote:

I'm thinking some people may need to stream to/from large 
files and

would find the requirement of in-core representation limiting.


Yes, I understand that. But currently I'm limited by std.xml.


Can you use another serialization format and supports file output 
for it? For example, can you use JSON, BSON or binary format?

Re: std.serialization: pre-voting review / discussion

On Wed, Aug 14, 2013 at 09:23:50PM +0200, Jacob Carlborg wrote:
> On 2013-08-14 21:11, Andrei Alexandrescu wrote:
> 
> >I'm thinking some people may need to stream to/from large files and
> >would find the requirement of in-core representation limiting.
> 
> Yes, I understand that. But currently I'm limited by std.xml.
[...]

Would it be possible to present a range *interface*, that currently just
converts to array (or aliases to array if it's already an array), so
that in the future, when std.xml is revamped to use ranges, existing
code will automatically reap the benefits?

T

-- 
Today's society is one of specialization: as you grow, you learn more and more 
about less and less. Eventually, you know everything about nothing.

Re: qtD

2013-08-14 Thread w0rp

I'd love to see good working Qt bindings in D. I have considered 
resurrecting the QtD project before, but I've been far too busy 
and/or lazy to really do anything.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread w0rp

On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky 
wrote:

In D:
alias f = _ + _;


In addition to being a D fan, I am also a Scala fan, and I use 
the magic underscore syntax in Scala now and again. While it can 
sometimes be useful, I don't feel like it absolutely needs to 
exist in the language.


I would like to argue in favour of gradually replacing the string 
lambdas which just lambdas. I don't personally see a huge problem 
in typing (x, y) => x < y. It very clearly expresses your intent, 
and this is very brief syntax. The underscore syntax only takes 
away from the expressiveness to reduce line length.


As mentioned before, for very common lambdas that you don't want 
to type yourself, you could define those functions as generic 
functions with a given name, like a 'less' function.

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 21:11, Andrei Alexandrescu wrote:


I'm thinking some people may need to stream to/from large files and
would find the requirement of in-core representation limiting.


Yes, I understand that. But currently I'm limited by std.xml.

--
/Jacob Carlborg

Re: Future of string lambda functions/string predicate functions


On 2013-08-14 19:17, Andrei Alexandrescu wrote:


Really? How does Scala figure that _ < _ refers to two arguments and not
one?


In Scala _ is something like a wildcard.

* It can be used in imports: "import foo.bar._". Means import everything 
in foo.bar


* It can be use as a fallback in pattern matching, like the default in a 
switch


* It can be used in lambdas, as described above

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 18:25, Andrei Alexandrescu wrote:


This seems like a major limitation. (Disclaimer: I haven't read the
documentation yet.)


The data is built up as a DOM (with the XmlArchive) using std.xml. I 
should I get a range out of that?


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 8/14/13 12:10 PM, Jacob Carlborg wrote:

On 2013-08-14 18:25, Andrei Alexandrescu wrote:


This seems like a major limitation. (Disclaimer: I haven't read the
documentation yet.)


The data is built up as a DOM (with the XmlArchive) using std.xml. I
should I get a range out of that?


I'm thinking some people may need to stream to/from large files and 
would find the requirement of in-core representation limiting.


Andrei

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Walter Bright


On 8/14/2013 11:21 AM, Dicebot wrote:

On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:

Could work since with a bit of compiler magic (expression alias).
Or even
alias f = typeof(_ + _);
with expression templates. Sounds like a solution but that would destroy the
easy ordering of arguments...


And here one should probably stop for a while and ask: "is it worth it?"


+1 for common sense.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Dmitry Olshansky


14-Aug-2013 22:21, Dicebot пишет:

On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:

Could work since with a bit of compiler magic (expression alias).
Or even
alias f = typeof(_ + _);
with expression templates. Sounds like a solution but that would
destroy the easy ordering of arguments...


And here one should probably stop for a while and ask: "is it worth it?"


As a library - of course, it's a great exercise at futility. C++ Boost 
lambda was full of it as they had less powerful language.


--
Dmitry Olshansky

Re: Future of string lambda functions/string predicate functions

On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky 
wrote:
Could work since with a bit of compiler magic (expression 
alias).

Or even
alias f = typeof(_ + _);
with expression templates. Sounds like a solution but that 
would destroy the easy ordering of arguments...


And here one should probably stop for a while and ask: "is it 
worth it?"

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Dmitry Olshansky


14-Aug-2013 21:17, Andrei Alexandrescu пишет:

On 8/14/13 10:15 AM, Dmitry Olshansky wrote:

14-Aug-2013 20:37, H. S. Teoh пишет:

On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

[snip]

It just occurred to me, that perhaps what we really need here is an
even more abbreviated form of lambda literals, like this:

sort!(a < b)(range);

where 'a' and 'b' are undefined identifiers in the current scope, and
the compiler would know to bind them to lambda parameters. Defined
identifiers would, naturally, bind to whatever they refer to:



Make that
sort!( _ < _ )(range)

and you have some Scala :)


Really? How does Scala figure that _ < _ refers to two arguments and not
one?


Looking into "Programming in Scala, 2nd edition" again...

Left to right, each underscore is a new parameter.
Once you need the argument 2 times you are screwed and go back to the 
same syntax we have.


Even more funny is that Scala can't bind templated parameters...
val f = _ + _

Not going to fly since there is no context to infer argument types!
Hence the crufty:
val f = ( _ : Int) + ( _ : Int)

In D:
alias f = _ + _;

Could work since with a bit of compiler magic (expression alias).
Or even
alias f = typeof(_ + _);
with expression templates. Sounds like a solution but that would destroy 
the easy ordering of arguments...




Andrei




--
Dmitry Olshansky

Different types

2013-08-14 Thread bearophile


In my code I sometimes use the pattern:

!is(T1 == T2)

I have counted more than 200 usages of such pattern in 
dmd/Phobos, see the attach here:

http://d.puremagic.com/issues/attachment.cgi?id=1242

So I suggest to allow the handy syntax (similar to the "!is" and 
"!in" syntax):


is(T1 != T2)


The enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=10816

- - - - - - - - - - - - - - - - - - -

But Timon has reminded us of a complexity I didn't think/know 
about, look at the last assert:



void main() {
alias T1 = int;
alias T2 = int;
alias T3 = double;
static assert(is(T1 == T2));
static assert(!is(T1 == T3));
//static assert(!is(T1 == T4)); // Error: undefined 
identifier T4

static assert(!is(T4 == T1));   // OK?
}


Is that behavour by design? If it's unwanted then I'll open a bug 
report and I suggest to fix it, to generate errors in both the 
last two asserts.


If that behavour is desired or it can't be fixed, then an 
alternative solution is to support equality and disequality 
syntax of naked types:


bool b1 = T1 == T2;
bool b2 = T1 != T3;

With this syntax all the T1, T2 and T3 types must exist. Once 
this syntax is present the older is(T1==T2) should be deprecated.


- - - - - - - - - - - - - - - - - - -

Note: perhaps it's also meaningful to support comparisons < >:


class Klass1 {}
class Klass2 : Klass1 {}
enum bool b1 = is(Klass1 < Klass2);

alias T1 = Tuple!(int, "x");
alias T2 = Tuple!(int);
enum bool b2 = is(T1 < T2);


But this introduces complexities that I think are better left to 
a separate discussion and enhancement request.


Bye,
bearophile

Mixin overload sets

2013-08-14 Thread BLM768

The current behavior of placing identically-named functions from 
separate mixins into separate overload sets works well most of 
the time, but there are cases when the functions should be in the 
same overload set, and the aliasing required to allow overloading 
can quickly get tedious and clutter the namespace where the 
mixins are used, especially if the mixins define multiple 
functions.


mixin template someMixin(Args ...) {
  void abc(Args) {};
  void def(int, Args);
}

struct HasMixins {
  mixin someMixin!int mixinInt;
  alias mixinInt.abc abc;
  alias mixinInt.def def;
  mixin someMixin!float mixinFloat;
  alias mixinFloat.abc abc;
  alias mixinFloat.def def;
  //and so on...
}

It would be nice if we had a more concise way to pull all of the 
duplicate functions into a single overload set. I can think of 
two ways to handle this:


1. Introduce a new syntax.

struct HasMixins {
  //One possible syntax:
  alias mixin someMixin!int this;
  alias mixin someMixin!float this;
  //etc.
}

HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)

2. Automatically place functions that come from different 
instances of the same mixin template into the same namespace.


struct HasMixins {
  mixin someMixin!int;
  mixin someMixin!float;
}

HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)

mixin template someOtherMixin {
  void abc() {};
}

struct HasOtherMixins {
  mixin someMixin!int;
  mixin someMixin!float;
  mixin someOtherMixin;
}

HasOtherMixins hm2;
hm2.abc(3f); //error

Thoughts?

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread Joakim


On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:

On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
You mentioned X11 to me before, when we talked about this idea 
over email.


Ah yes. I think X's biggest problem though is that it doesn't 
do *enough*. The protocol is fairly efficient for what it does, 
but it just doesn't do enough so the commands aren't 
particularly compact when you start to get fancier.
As you point out later, I don't think it's the compactness of the 
commands that is the problem as much as that X11 bites off too 
much.  If you're going to be both efficient and allow remote GUI 
forwarding, that's an incredibly difficult and orthogonal set of 
features to deliver on, which is why Wayland only focuses on 
efficiency.  I'd punt on much of the stuff X11 tries to do with 
my lean GUI runtime, which I'll call Crack from here on out.


For instance, in my crappygui.d, I used XDrawString to draw 
text. This was the result: http://arsdnet.net/gui.png

--snip--
Note btw though, you *can* save the image on the display server 
to reuse it later, so every time you print a string it doesn't 
necessarily send that data across, but I'm not sure if the 
higher level libraries actually do this... the downsides of 
abstractions is you can miss important details like this.
Interesting, it does highlight what a mess X11 is.  I see no 
reason to build on such an old protocol.


This is why my simpledisplay.d now has a class Sprite in 
addition to class Image, and why Qt has QImages and QPixmaps, 
but how often do you think of drawing text as being something 
that needs a Pixmap to be efficient? Again the library might 
handle it, I'm not sure, but the relatively pathetic 
performance of a lot of apps on a remote X connection makes me 
think they probably don't.
This is why I'd implement text layout and rendering in the Crack 
client, with the server simply passing along strings for the 
client to render, breaking the simple OpenGL wrapper promised 
before. ;) Here's some other exceptions I'd put in, which I 
mentioned to you before:


Text input - As you say below, you wouldn't want to hit the 
server for every keypress, so text input boxes would be handled 
by the client.  It would be easy to implement since you're 
already doing text layout and rendering in the client.


Scrolling - Just as with text input, if you're using one 
rectangle onscreen as a scrollbar, you usually wouldn't want to 
hit the server just to get the new scroll position of the other 
rectangle it controls.  There would be some scrolling-related 
event-handling in the Crack client, so that you could designate 
one rectangle as the scrollbar control for another rectangle and 
the client would handle scrolling, simply notifying the server of 
the new scroll position after the user is done scrolling.


Upload/Download progress -  Another ability you'll need is to 
update a rectangle based on the progress of files being 
downloaded or uploaded, so you can create a progress bar without 
having to constantly hit the server to get the status of file 
transfers.


File chooser - And of course, access to the native file chooser 
widget.


Caching - Finally, you'll want some resource and event-handling 
caching so that you can load updates quicker, just like AJAX once 
hacked into the web stack.  Say you're implementing a photo 
gallery, you'll have the Crack client download the next photo in 
the gallery and be able to tell the client that if a certain 
rectangle is clicked, it should swap in the next photo without 
checking with the server first.  This is similar to your 
"predictive paths" idea from DWS and would greatly decrease 
network traffic and GUI lag.


The caching of event handling would be narrowly circumscribed, 
boolean logic with mouse/keyboard events as input and GUI updates 
as output, so that it's simpler and much more secure than a full 
language interpreter like javascript.


Obviously, all these exceptions break the simple OpenGL wrapper 
that I'd wanted Crack to be, but the goal is to minimize such 
exceptions, so that you don't become the bloated beast that the 
web client has become today. :)


Anyway, the other thing too is all events go to the client 
application from the display server, and then the application's 
changes go back to the display server. Since X itself doesn't 
offer any kind of widgets, a text control for instance would 
work like this:

--snip--
So I'd want to do higher level events too, and the application 
can request them. For instance, if all you want is a basic text 
input, output something like  and let the 
display do the details.

I agree, text input boxes should be handled by the Crack client.

(Another really nice benefit here, if we do it right, is it 
could use native controls on systems like Windows, or even pipe 
it to an external app on unix, and get a nice customized, 
adaptable system. Though while it sounds simpler in ways, this 
is easier said than don

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Dmitry Olshansky


14-Aug-2013 20:37, H. S. Teoh пишет:

On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

[snip]

It just occurred to me, that perhaps what we really need here is an
even more abbreviated form of lambda literals, like this:

sort!(a < b)(range);

where 'a' and 'b' are undefined identifiers in the current scope, and
the compiler would know to bind them to lambda parameters. Defined
identifiers would, naturally, bind to whatever they refer to:



Make that
sort!( _ < _)(range)

and you have some Scala :)


int x = 5;
find!(a == x)(range);

This would be equivalent to:

int x = 5;
find!((a) => a==x)(range);

IOW, an expression that references undefined identifiers in a template
parameter would be turned into a lambda that parametrize said
identifiers.


T




--
Dmitry Olshansky

Re: Future of string lambda functions/string predicate functions


On 8/14/13 10:15 AM, Dmitry Olshansky wrote:

14-Aug-2013 20:37, H. S. Teoh пишет:

On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

[snip]

It just occurred to me, that perhaps what we really need here is an
even more abbreviated form of lambda literals, like this:

sort!(a < b)(range);

where 'a' and 'b' are undefined identifiers in the current scope, and
the compiler would know to bind them to lambda parameters. Defined
identifiers would, naturally, bind to whatever they refer to:



Make that
sort!( _ < _)(range)

and you have some Scala :)


Really? How does Scala figure that _ < _ refers to two arguments and not 
one?


Andrei

Re: Future of string lambda functions/string predicate functions

On Wed, Aug 14, 2013 at 07:03:32PM +0200, John Colvin wrote:
> On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
> >On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu
> >wrote:
> >>On 8/14/13 7:34 AM, H. S. Teoh wrote:
> >[...]
> >>>That's a bit too terse. What about this:
> >>>
> >>>   less// a < b
> >>>   less!(5)// a < 5
> >>>   lessEq  // a <= b
> >>>   lessEq!(5)  // a <= 5
> >>>   more// a > b
> >>>   more!(5)// a > 5
> >>>   moreEq  // a >= b
> >>>   moreEq!(5)  // a >= 5
> >>>   equal   // a == b
> >>>   equal!(5)   // a == 5
> >>>   notEqual// a != b
> >>>   notEqual!(5)// a != 5
> >>
> >>At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
> >>becomes awfully attractive.
> >[...]
> >
> >It just occurred to me, that perhaps what we really need here is an
> >even more abbreviated form of lambda literals, like this:
> >
> > sort!(a < b)(range);
> >
> >where 'a' and 'b' are undefined identifiers in the current scope, and
> >the compiler would know to bind them to lambda parameters. Defined
> >identifiers would, naturally, bind to whatever they refer to:
> >
> > int x = 5;
> > find!(a == x)(range);
> >
> >This would be equivalent to:
> >
> > int x = 5;
> > find!((a) => a==x)(range);
> >
> >IOW, an expression that references undefined identifiers in a
> >template parameter would be turned into a lambda that parametrize
> >said identifiers.
> >
> >
> >T
> 
> That's a bit too fragile IMO.
> 
> int b; //rename to 'a'
> // lots of intermediate code...
> int x = 5;
> r.blah!(a == x);
> 
> Renaming of a seemingly unrelated variable would result in spooky
> action-at-a-distance behaviour.

Arguably, naming a variable as 'b' or 'a' is a bad idea, but, point
taken.

I guess we still have to fall back to full-fledged lambda literals,
then. I'm still in favor of deprecating string lambdas, but as Andrei
said, we need to address the problem of how to compare lambdas
meaningfully.

The question then becomes, what do we do *now*, for new additions to
Phobos? Should new code still support string lambdas or not?


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've 
forgotten this before.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread John Colvin


On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu 
wrote:

On 8/14/13 7:34 AM, H. S. Teoh wrote:

[...]

>That's a bit too terse. What about this:
>
>less// a < b
>less!(5)// a < 5
>lessEq  // a <= b
>lessEq!(5)  // a <= 5
>more// a > b
>more!(5)// a > 5
>moreEq  // a >= b
>moreEq!(5)  // a >= 5
>equal   // a == b
>equal!(5)   // a == 5
>notEqual// a != b
>notEqual!(5)// a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
becomes awfully attractive.

[...]

It just occurred to me, that perhaps what we really need here 
is an

even more abbreviated form of lambda literals, like this:

sort!(a < b)(range);

where 'a' and 'b' are undefined identifiers in the current 
scope, and
the compiler would know to bind them to lambda parameters. 
Defined

identifiers would, naturally, bind to whatever they refer to:

int x = 5;
find!(a == x)(range);

This would be equivalent to:

int x = 5;
find!((a) => a==x)(range);

IOW, an expression that references undefined identifiers in a 
template

parameter would be turned into a lambda that parametrize said
identifiers.


T


That's a bit too fragile IMO.

int b; //rename to 'a'
// lots of intermediate code...
int x = 5;
r.blah!(a == x);

Renaming of a seemingly unrelated variable would result in spooky 
action-at-a-distance behaviour.

Re: qtD

2013-08-14 Thread michaelc37

On Wednesday, 14 August 2013 at 15:16:27 UTC, David Nadlinger 
wrote:

On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote:
I don't think I got that far as I got a "Can't find the D 
compiler

problem. It seems the build rebuilds the build in some way but
fails. :-((


The cmake/FindD.cmake script searched for 'ldc' only, not 
'ldc2'.


Am on the way home right now, but I just pushed a commit (yay 
for git-hg) that should fix that issue (but only that issue).


David


I'm not sure that enough, the output of the "ldc2 --version" 
compiler seems to have changed. Also i found that in 
CMakeLists.txt ldc2 needs "D_FLAGS -d-version=QtdCppShared" for 
the D_IS_LLVM condition.


Here is what i did.
https://bitbucket.org/michaelc37/qtd-experimental/commits/bfd137549ab266cc0c2131be18d8ad955e78a501

I managed to get it to compile with ldc2, after hacking up a fix 
for Atomic.d , i did commit that change as i am not familiar with 
llvm at all..  But if anyone wants to try it, it is attached to 
https://bitbucket.org/michaelc37/qtd-experimental/issue/1/cannot-compile-with-ldc2

Re: working on the dlang.org website

2013-08-14 Thread Craig Dillabaugh


On Saturday, 10 August 2013 at 17:29:40 UTC, Ruslan Mullakhmetov
wrote:

clip

Let me put my two cents at this thread, hope it would be useful.

(1) The thread went (from the start) to discussion of technical 
details, not content discussion, and users are interested in 
content itself, which, IMHO is not optimally organized.


clip


Motiviated by Ruslan's comments I thought I would make a
suggestion I had been thinking of with regards to the Forums. The
Forums organization seems a bit out of date. For example there
are a number of topics that are rarely ever receive posts, but
they appear before busy forums, such as D.learn. I wonder if this
might be one of the reasons why obvious learner questions get
posted to digitialmars.D on occassion. Any easy way to deal with
this would be to sort forums by post count rather than
alphabetically, but that has its own issues.


Perhaps the D forums could be split into two separate headings:

1. D Programming - general D related programming questions could
go here. It could include:
-  D.learn (More focused for newer D users)
-  D.phobos (questions about use of standard library)
-  D.programming (more advanced questions)
-  Debugging/Profiling (was digitalmars.D.debugger - on first
reading sounds like the forum is

2. D Development (this isn't a great name - but it would include
forums
more focused on the Development of the D language). Some topics
might
include:
- current digitalmars.D forum
- announce
- digitalmars.D.bugs
- digitalmars.D.ldc
- D.gnu
- dmd-beta
- dmd-concurrency
- dmd-internals
- phobos
- D-runtime

I exclusively use the Forum's and perhaps such a reorganization
would be too much trouble for folks who uses newreaders/email,
but I thought I would but the suggestion out there.

Re: Future of string lambda functions/string predicate functions

On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:
> On 8/14/13 7:34 AM, H. S. Teoh wrote:
[...]
> >That's a bit too terse. What about this:
> >
> > less// a < b
> > less!(5)// a < 5
> > lessEq  // a <= b
> > lessEq!(5)  // a <= 5
> > more// a > b
> > more!(5)// a > 5
> > moreEq  // a >= b
> > moreEq!(5)  // a >= 5
> > equal   // a == b
> > equal!(5)   // a == 5
> > notEqual// a != b
> > notEqual!(5)// a != 5
> 
> At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
> becomes awfully attractive.
[...]

It just occurred to me, that perhaps what we really need here is an
even more abbreviated form of lambda literals, like this:

sort!(a < b)(range);

where 'a' and 'b' are undefined identifiers in the current scope, and
the compiler would know to bind them to lambda parameters. Defined
identifiers would, naturally, bind to whatever they refer to:

int x = 5;
find!(a == x)(range);

This would be equivalent to:

int x = 5;
find!((a) => a==x)(range);

IOW, an expression that references undefined identifiers in a template
parameter would be turned into a lambda that parametrize said
identifiers.

T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald Knuth

Re: std.serialization: pre-voting review / discussion


On 8/14/13 1:48 AM, Jacob Carlborg wrote:

On 2013-08-14 10:19, Tyler Jameson Little wrote:

   - I would to serialize to a range (file?) and deserialize from a
range (file?)


The serialized data is returned as an array, so that is compatible with
the range interface, it just won't be lazy.


This seems like a major limitation. (Disclaimer: I haven't read the 
documentation yet.)


Andrei

Re: Future of string lambda functions/string predicate functions


On 8/14/13 7:34 AM, H. S. Teoh wrote:

On Wed, Aug 14, 2013 at 09:10:37AM +0200, Tyler Jameson Little wrote:

On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:

On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:

Can you give an example where you've actually used a string lambda
before where the predicate is more complex than a basic comparison?
Surely the solution to this problem is to offer a bunch of templates
that perform the most common predicates in place of unary/binaryFun?

So rather than: func!((a, b) => a < b)(args)
You use: func!binaryLess(args)

Or something like that?



How about just "less"?  It's what C++ STL uses (std::less,
std::greater, std::negate, etc...). In C++, however, you have to
do some truly ugly stuff to actually make use of the predefined
function objects...bind1st...eww (the new C++11 bind is only
marginally better but C++11 does have lambdas now at least).

[...]

Or imitate bash:

Binary:
- gt: a > b
- ge: a >= b
- lt: a < b
- le: a <= b
- eq: a == b
- ne: a != b

Unary:
- z: (zero) a == 0 (if range, a.empty?)
- n: (non-zero) a != 0

Perhaps this is *too* terse?


That's a bit too terse. What about this:

less// a < b
less!(5)// a < 5
lessEq  // a <= b
lessEq!(5)  // a <= 5
more// a > b
more!(5)// a > 5
moreEq  // a >= b
moreEq!(5)  // a >= 5
equal   // a == b
equal!(5)   // a == 5
notEqual// a != b
notEqual!(5)// a != 5


At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes 
awfully attractive.


Andrei

Re: Package module not working properly


On Wednesday, 14 August 2013 at 15:45:58 UTC, Kapps wrote:

On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
Looks to me like you are trying to import the package. It 
never worked. That is why over the time two groups of D 
developers emerged. Those who use the /path/to/package/all.d 
and those who use /path/to/package/_.d ... I belong to the 
first group, and would expect something like: import 
std.serialization.all; or import std.serialization._;
Some guys rightfully argued about not being able to be more 
selective, but so far I think the approach above works 
perfectly.


Package imports work now with 'import std.serialization' 
actually importing std.serialization.package which then 
publicly imports what it needs. I don't remember which version 
this feature is in but I think it was 2.063(?) or perhaps 
master.


Yeah, I was too fast, did not see the package.d, as I said in my 
previous post... Sorry... :)

Re: Package module not working properly

On Wednesday, 14 August 2013 at 15:32:25 UTC, Andrej Mitrovic 
wrote:

On 8/14/13, Jacob Carlborg  wrote:

And in std/serialization/archives/package.d

module std.archives;


I think that should be 'module std.serialization.archives'.


Good catch Andrej! :)

Re: Package module not working properly

2013-08-14 Thread Kapps


On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
Looks to me like you are trying to import the package. It never 
worked. That is why over the time two groups of D developers 
emerged. Those who use the /path/to/package/all.d and those who 
use /path/to/package/_.d ... I belong to the first group, and 
would expect something like: import std.serialization.all; or 
import std.serialization._;
Some guys rightfully argued about not being able to be more 
selective, but so far I think the approach above works 
perfectly.


Package imports work now with 'import std.serialization' actually 
importing std.serialization.package which then publicly imports 
what it needs. I don't remember which version this feature is in 
but I think it was 2.063(?) or perhaps master.

Re: working on the dlang.org website

2013-08-14 Thread Kapps


On Wednesday, 14 August 2013 at 15:25:09 UTC, Flamaros wrote:

I found a nice documentation website :
http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/index.html?url=cpp_ref/_common_2_common_8cxx-example.html,topicNumber=cpp_ref__common_2_common_8cxx_example_htmlc507b7ce-aa2f-4c44-b08f-90c94f43730b

There is all sources of sample, and code is highlighted with 
link to methods docs.
I think it will be a good thing to have real unittest linked 
with the documentation of D, just because instead embedded 
samples we are sure that is executable as it (no missing 
import, syntax error,...).
It seems that is a bad idea to have specific code samples for 
the documentation, it's generally out of date,... Is it 
feasible to have docs that extract chunks of real unittest as 
samples?


D has documented unit tests (Documented Unittests section at 
http://dlang.org/unittest.html) but they're a relatively new 
feature so most of the documentation doesn't yet use them.

Re: Package module not working properly


On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
On Wednesday, 14 August 2013 at 14:43:47 UTC, Jacob Carlborg 
wrote:
I'm trying to the get the "package modules" working in the new 
package std.serialization I'm working on. I have a sample file 
I'm compiling, looking like this:


import std.serialization;
import std.serialization.archives;

class Foo
{
   int a;
}

void main ()
{
   auto archive = new XmlArchive!();
   auto serializer = new Serializer(archive);

   auto foo = new Foo;
   foo.a = 3;

   serializer.serialize(foo);
   auto foo2 = 
serializer.deserialize!(Foo)(archive.untypedData);


   assert(foo2.a == 3);
   assert(foo.a == foo2.a);
}

When I compile it I get these linker errors:

Undefined symbols for architecture x86_64:
 "_D3std13serialization12__ModuleInfoZ", referenced from:
 _D4main12__ModuleInfoZ in main.o
 "_D3std13serialization8archives12__ModuleInfoZ", referenced 
from:

 _D4main12__ModuleInfoZ in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
--- errorlevel 1

If I instead only import the exact modules that are needed, 
like this:


import std.serialization.serializer;
import std.serialization.archives.xmlarchive;

Everything works as expected.

I have a module declaration in std/serialization/package.d, 
like this:


module std.serialization;

And in std/serialization/archives/package.d

module std.archives;

First, I don't know if I should have any module declarations 
at all in these "package modules". Or if they should be like 
above or something like "module std.archives.package;".


If I remove the module declarations in the package modules I 
get this assertion in the compiler:


Assertion failed: (p->isPkgMod == PKGmodule), function load, 
file import.c, line 136.

Abort trap:

I don't know if I'm doing something wrong of if this new 
feature isn't working properly.


The code is available there: 
https://github.com/jacob-carlborg/phobos/tree/serialization


Looks to me like you are trying to import the package. It never 
worked. That is why over the time two groups of D developers 
emerged. Those who use the /path/to/package/all.d and those who 
use /path/to/package/_.d ... I belong to the first group, and 
would expect something like: import std.serialization.all; or 
import std.serialization._;
Some guys rightfully argued about not being able to be more 
selective, but so far I think the approach above works 
perfectly.


Ignore this, I did not see your package.d file there...

Re: Parameter-less templates?


On Tuesday, 13 August 2013 at 09:41:45 UTC, monarch_dodra wrote:


In regards to template (I mean the actual "template"), I guess 
I wish we could either:

1. Allow non-parameterized templates (eg template foo {...})
2. Allow invoking a template without parameters (provided the 
template has 0 parameters, or default parameters), without 
doing "!()"


I think your proposal no. 1 is good, but there's a problem with 
your proposal no. 2. This is current D code:


template get(int n = 1)
{
static if (n == 1) {
alias get = one;
}
else static if (n == 0) {
enum get = 0;
}
}

template one(int n)
{
enum one = 1;
}

template wrap(alias a)
{
enum wrap = a!0;
}

void main()
{
static assert(wrap!get == 0);
static assert(wrap!(get!()) == 1);
}

So, if we go with your proposal no. 2 (allow invoking a template 
without a parameter list), then the meaning of 'get' in:

wrap!get
...becomes ambiguous. We could be either passing an alias to 
'get', or an alias to a parameterless instantiation of template 
'get', i.e. get!().

Re: Package module not working properly

On Wednesday, 14 August 2013 at 14:43:47 UTC, Jacob Carlborg 
wrote:
I'm trying to the get the "package modules" working in the new 
package std.serialization I'm working on. I have a sample file 
I'm compiling, looking like this:


import std.serialization;
import std.serialization.archives;

class Foo
{
int a;
}

void main ()
{
auto archive = new XmlArchive!();
auto serializer = new Serializer(archive);

auto foo = new Foo;
foo.a = 3;

serializer.serialize(foo);
auto foo2 = 
serializer.deserialize!(Foo)(archive.untypedData);


assert(foo2.a == 3);
assert(foo.a == foo2.a);
}

When I compile it I get these linker errors:

Undefined symbols for architecture x86_64:
  "_D3std13serialization12__ModuleInfoZ", referenced from:
  _D4main12__ModuleInfoZ in main.o
  "_D3std13serialization8archives12__ModuleInfoZ", referenced 
from:

  _D4main12__ModuleInfoZ in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
--- errorlevel 1

If I instead only import the exact modules that are needed, 
like this:


import std.serialization.serializer;
import std.serialization.archives.xmlarchive;

Everything works as expected.

I have a module declaration in std/serialization/package.d, 
like this:


module std.serialization;

And in std/serialization/archives/package.d

module std.archives;

First, I don't know if I should have any module declarations at 
all in these "package modules". Or if they should be like above 
or something like "module std.archives.package;".


If I remove the module declarations in the package modules I 
get this assertion in the compiler:


Assertion failed: (p->isPkgMod == PKGmodule), function load, 
file import.c, line 136.

Abort trap:

I don't know if I'm doing something wrong of if this new 
feature isn't working properly.


The code is available there: 
https://github.com/jacob-carlborg/phobos/tree/serialization


Looks to me like you are trying to import the package. It never 
worked. That is why over the time two groups of D developers 
emerged. Those who use the /path/to/package/all.d and those who 
use /path/to/package/_.d ... I belong to the first group, and 
would expect something like: import std.serialization.all; or 
import std.serialization._;
Some guys rightfully argued about not being able to be more 
selective, but so far I think the approach above works perfectly.

Re: Package module not working properly

2013-08-14 Thread Andrej Mitrovic

On 8/14/13, Jacob Carlborg  wrote:
> And in std/serialization/archives/package.d
>
> module std.archives;

I think that should be 'module std.serialization.archives'.

Re: working on the dlang.org website

2013-08-14 Thread Flamaros


I found a nice documentation website :
http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/index.html?url=cpp_ref/_common_2_common_8cxx-example.html,topicNumber=cpp_ref__common_2_common_8cxx_example_htmlc507b7ce-aa2f-4c44-b08f-90c94f43730b

There is all sources of sample, and code is highlighted with link 
to methods docs.
I think it will be a good thing to have real unittest linked with 
the documentation of D, just because instead embedded samples we 
are sure that is executable as it (no missing import, syntax 
error,...).
It seems that is a bad idea to have specific code samples for the 
documentation, it's generally out of date,... Is it feasible to 
have docs that extract chunks of real unittest as samples?

Re: qtD

2013-08-14 Thread David Nadlinger


On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote:
I don't think I got that far as I got a "Can't find the D 
compiler

problem. It seems the build rebuilds the build in some way but
fails. :-((


The cmake/FindD.cmake script searched for 'ldc' only, not 'ldc2'.

Am on the way home right now, but I just pushed a commit (yay for 
git-hg) that should fix that issue (but only that issue).


David

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 17:08, Kapps wrote:


If you had UDAs available to you from the start, would you have included the 
mixins?


No.


If not, why include them now?


You do have a point.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread Kapps

On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 16:15, ilya-stromberg wrote:


I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use 
it.
Of course, we can leave template NonSerialized(Fields...) for 
backwards

compatible with Orange and, maybe, deprecate it.


Of course UDA's should be the primary use for this. The 
question is should NonSerialized be included at all? Should it 
be included and deprecated or should it just be included?


I don't think it should be included. The UDAs replace it nicely, 
and though std.serialization would be essentially Orange it's 
still a different library. Some breaking changes are to be 
expected, and in this case I think worth-while. Having multiple 
ways of specifying options such as non-serialized is confusing. 
If you had UDAs available to you from the start, would you have 
included the mixins? If not, why include them now? This is 
essentially a fresh start, one inside Phobos rather than a 
separate library.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Manu

I like the direction this thread is going :)


On 15 August 2013 00:50, Mr. Anonymous  wrote:

> On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:
>
>> A computer doesn't mind if its programs are put to purposes that don't
>> match their names. -- D. Knuth
>>
>
> Heh :)
> Sometimes I read your replies just for the signature.
>
> On the topic, I think the variant with the operators is more
> straightforward, e.g.:
>
>> less// a < b
>>
> op!"<"
>
>> less!(5)// a < 5
>>
> op!"<"(5)
>
> etc.
>

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 14:50:45 UTC, ilya-stromberg 
wrote:

I did not use Orange at all.
But the most terrible for library is losing backwards 
compatiblity. So, if Orange uses NonSerialized, we have to 
include it. We can just add documentation notice that 
NonSerialized will be deprecated after, for example, 6 months.


std.serialization is not Orange and should not be considered as 
one. Once it is included into Phobos it is a brand new library 
and must be treated as such, no matter what origin it has. Users 
of Orange expect compatibility from Orange, not Phobos.

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread ilya-stromberg

On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 16:15, ilya-stromberg wrote:


I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use 
it.
Of course, we can leave template NonSerialized(Fields...) for 
backwards

compatible with Orange and, maybe, deprecate it.


Of course UDA's should be the primary use for this. The 
question is should NonSerialized be included at all? Should it 
be included and deprecated or should it just be included?


I did not use Orange at all.
But the most terrible for library is losing backwards 
compatiblity. So, if Orange uses NonSerialized, we have to 
include it. We can just add documentation notice that 
NonSerialized will be deprecated after, for example, 6 months.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Mr. Anonymous


On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:
A computer doesn't mind if its programs are put to purposes 
that don't match their names. -- D. Knuth


Heh :)
Sometimes I read your replies just for the signature.

On the topic, I think the variant with the operators is more 
straightforward, e.g.:

less// a < b

op!"<"

less!(5)// a < 5

op!"<"(5)

etc.

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg 
wrote:
Should it be included and deprecated or should it just be 
included?


What is the point of including something into Phobos and 
immediately deprecating it? It is first inclusion, so there are 
no backwards compatibility concerns.

Re: Future of string lambda functions/string predicate functions

2013-08-14 Thread Wyatt


On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:


more// a > b
more!(5)// a > 5
moreEq  // a >= b
moreEq!(5)  // a >= 5


Nitpick, but I'd personally prefer "greater" rather than "more".

-Wyatt

Package module not working properly

I'm trying to the get the "package modules" working in the new package 
std.serialization I'm working on. I have a sample file I'm compiling, 
looking like this:


import std.serialization;
import std.serialization.archives;

class Foo
{
int a;
}

void main ()
{
auto archive = new XmlArchive!();
auto serializer = new Serializer(archive);

auto foo = new Foo;
foo.a = 3;

serializer.serialize(foo);
auto foo2 = serializer.deserialize!(Foo)(archive.untypedData);

assert(foo2.a == 3);
assert(foo.a == foo2.a);
}

When I compile it I get these linker errors:

Undefined symbols for architecture x86_64:
  "_D3std13serialization12__ModuleInfoZ", referenced from:
  _D4main12__ModuleInfoZ in main.o
  "_D3std13serialization8archives12__ModuleInfoZ", referenced from:
  _D4main12__ModuleInfoZ in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
--- errorlevel 1

If I instead only import the exact modules that are needed, like this:

import std.serialization.serializer;
import std.serialization.archives.xmlarchive;

Everything works as expected.

I have a module declaration in std/serialization/package.d, like this:

module std.serialization;

And in std/serialization/archives/package.d

module std.archives;

First, I don't know if I should have any module declarations at all in 
these "package modules". Or if they should be like above or something 
like "module std.archives.package;".


If I remove the module declarations in the package modules I get this 
assertion in the compiler:


Assertion failed: (p->isPkgMod == PKGmodule), function load, file 
import.c, line 136.

Abort trap:

I don't know if I'm doing something wrong of if this new feature isn't 
working properly.


The code is available there: 
https://github.com/jacob-carlborg/phobos/tree/serialization


--
/Jacob Carlborg

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread Wyatt


On Wednesday, 14 August 2013 at 14:26:12 UTC, Adam D. Ruppe wrote:


Of course, you do want just "blit this image" as a generic 
fallback, and we can do better than X too, by just making it 
use png+jpg or something. Boom, transparency (yes, X has this 
in the render extension) and some big compression boosts.


I recall NX does something like this, plus a number of other neat 
tricks.

http://www.nomachine.com/documents/NX-XProtocolCompression.php

-Wyatt

Re: Future of string lambda functions/string predicate functions

On Wed, Aug 14, 2013 at 09:10:37AM +0200, Tyler Jameson Little wrote:
> On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:
> >On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
> >>Can you give an example where you've actually used a string lambda
> >>before where the predicate is more complex than a basic comparison?
> >>Surely the solution to this problem is to offer a bunch of templates
> >>that perform the most common predicates in place of unary/binaryFun?
> >>
> >>So rather than: func!((a, b) => a < b)(args)
> >>You use: func!binaryLess(args)
> >>
> >>Or something like that?
> >>
> >
> >How about just "less"?  It's what C++ STL uses (std::less,
> >std::greater, std::negate, etc...). In C++, however, you have to
> >do some truly ugly stuff to actually make use of the predefined
> >function objects...bind1st...eww (the new C++11 bind is only
> >marginally better but C++11 does have lambdas now at least).
[...]
> Or imitate bash:
> 
> Binary:
> - gt: a > b
> - ge: a >= b
> - lt: a < b
> - le: a <= b
> - eq: a == b
> - ne: a != b
> 
> Unary:
> - z: (zero) a == 0 (if range, a.empty?)
> - n: (non-zero) a != 0
> 
> Perhaps this is *too* terse?

That's a bit too terse. What about this:

less// a < b
less!(5)// a < 5
lessEq  // a <= b
lessEq!(5)  // a <= 5
more// a > b
more!(5)// a > 5
moreEq  // a >= b
moreEq!(5)  // a >= 5
equal   // a == b
equal!(5)   // a == 5
notEqual// a != b
notEqual!(5)// a != 5


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match 
their names. -- D. Knuth

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 16:15, ilya-stromberg wrote:


I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use it.
Of course, we can leave template NonSerialized(Fields...) for backwards
compatible with Orange and, maybe, deprecate it.


Of course UDA's should be the primary use for this. The question is 
should NonSerialized be included at all? Should it be included and 
deprecated or should it just be included?


--
/Jacob Carlborg

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread Adam D. Ruppe

On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson
Little wrote:
I'm in the opposite camp. The server is never going to be able
to support everything, and people are just going to fall back
to rendering themselves anyway.

Couldn't you make the same argument against any gui library? But
there's a lot of stuff in common that might be sped up. Menus are
very slow on Qt over remote X11 (at least with the default
theme). Ironically though, the tabbed widgets are pretty fast,
aside from a somewhat slow startup.

But menus are pretty much the same for any application, so that'd
be a good thing to put in the display library.

Of course, you do want just "blit this image" as a generic
fallback, and we can do better than X too, by just making it use
png+jpg or something. Boom, transparency (yes, X has this in the
render extension) and some big compression boosts.

Add display side scaling, perhaps make the pixmap be implemented
as an opengl texture so you can scale, rotate, quickly paint,
etc., and that's pretty useful for a lot of things. But I don't
think it replaces the usefulness of higher level concepts like
menus, buttons, etc. Sure, the app might have to customize them,
but do they have to customize *all* of them?

You may find this interesting:
http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland

hmm, indeed.

I would love attach/reattach for UIs. This seems like it would
have to be supported at the protocol level.

Yeah, and probably a middle man of some sort too so each
application doesn't have to be listening on a port. But with the
client state, if it can just send that back to the new
connection, it shouldn't be too hard.

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread ilya-stromberg

On Wednesday, 14 August 2013 at 09:28:20 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 11:25, Tyler Jameson Little wrote:

I like this a lot more. Phobos just needs to be compatible 
with the

current release, so backwards compat is a non-issue here.


I guess this is why we have this thread. I would like to hear 
comments from a couple of others as well about this before 
deciding.


I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use it.
Of course, we can leave template NonSerialized(Fields...) for 
backwards compatible with Orange and, maybe, deprecate it.

Re: std.serialization: pre-voting review / discussion


On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:

Wishful thinking aside, they are competitors.


They are not. `std.serialization` does not and should not compete 
in Thrift domain. In fact, if something like this can be found in 
proposal you should point to it and it will be discussed as a 
possible removal candidate.


Your input is valuable put please reconsider it without this 
wrong assumption.

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread glycerine

On Wednesday, 14 August 2013 at 07:40:13 UTC, Jacob Carlborg 
wrote:
I have documented the package for what it is, not for what it's 
not. It's a package for serialization, not a RCP or network 
package


You seem to like me to write a comparison to Thrift in the 
documentation. You have to make the comparison yourself.


Wishful thinking aside, they are competitors. The fact that you 
haven't already done this comparison is unfortunate. I've already 
done that comparison, tried Orange, and found it wanting. If you 
don't want everyone else to do the same, you should answer the 
questions outlined so that it can be positioned appropriately in 
people's minds.


If you'd like examples of how to present design rationale, using 
contrast for illustration, consider the example of Stroustrup's 
presentation of C++ features in any of his several books. 
Contrasting analysis is often essential in describing the 
history, design and rationale for your work; the "related work" 
section of any technical publication is required by reviewers. 
You should provide it if you don't want your work to be dismissed 
out of hand.


Many if not most modern serialization libraries do address 
transport, and it is critical to the most common use case for 
serialization: as a developer, I want to move data between two 
different environments, be they hosts, memories, disk, process, 
thread, or different languages; so that I can store and process 
data non-locally and in a non-sequential fashion.


For Orange, you can simply say that you have no transport 
support, and perhaps describe why you don't consider it (e.g. 
what use case were you designing for?), and that will suffice to 
answer number three (3).  In addition, there are still eight 
other salient issues.


I provided this outline to assist you in describing your work. 
You'll need to be more specific about where you are confused if 
you don't understand a particular issue. Ignoring issues won't 
make them go away, it will just make others ignore and go away 
from your work.

Re: Designing a consistent language is very hard


On Saturday, 28 April 2012 at 11:42:19 UTC, Paulo Pinto wrote:
On Saturday, 28 April 2012 at 09:41:06 UTC, Nick Sabalausky 
wrote:

"Paulo Pinto"  wrote in message
news:jngarb$14un$1...@digitalmars.com...

Am 28.04.2012 10:18, schrieb Guillaume Chatelet:
Sorry for the noise but I think a few language designer out 
there might

like this one :
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

I think Walter and Andrei will smile ( or cry ) reading it.
It's no trolling here, I do think this post is very valuable 
and

relevant from a language design perspective.


Well, I cry everytime I am using it on my web site, but the 
effort to

port the scripts is not worth it.


Abandoning PHP is *always* "worth it".


Rewriting seldom brings anything new. It almost like starting
from zero, without the benefit from all the bug fixes the
software has had along the years.

The hours wasted porting to a new language, could be used adding
features to existing code base, or refactoring.

I know how I am speaking about, many of the big bucks we get on
consultancy jobs, are from companies that decide to keep 
rewriting
their software on the flavour of the month framework, just 
because

"everyone else is doing it".

So I rather keep my "almost clean" PHP scripts running, as 
getting
to the trouble of switching ISP just to be able to rewrite the 
site

in a more sane language.

--
Paulo


Nicely said. Precisely my experience. We are all Java programmers 
in my team, yet we maintain old ASP and PHP code that previous 
colleagues did in the past. Redoing them from scratch in Java or 
D is out of question.


Speaking about PHP... I believe we all read that article. I could 
say worse about ASP than what that article says about PHP.

Re: Designing a consistent language is very hard

2013-08-14 Thread Joakim

On Saturday, 28 April 2012 at 08:18:34 UTC, Guillaume Chatelet 
wrote:
Sorry for the noise but I think a few language designer out 
there might like this one :

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

I think Walter and Andrei will smile ( or cry ) reading it.
It's no trolling here, I do think this post is very valuable 
and relevant from a language design perspective.
Bump.  Nick linked this blog post in another thread and after 
nosing around his blog, I found another good blog post the guy 
wrote earlier this year:


http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/

This could be an important strength to highlight in D, since it 
doesn't have the OO constraints that Java imposes.  Although, I 
have run into this problem myself when poking around a D project 
filled with OO boilerplate, with the single function that 
actually did anything hidden away in a private method in some 
unexpected class.  Perhaps it's because the project was still 
being written and the author found it easier to write all his 
class superstructure first, but I suspect even the finished 
project had far too much of this OO debris.


The problems of that project can't be blamed on D of course, but 
that unfortunate mentality seeps in from other languages, which 
hopefully blog posts like this and better idiomatic D can combat.

Re: Alternative to Github downloads

2013-08-14 Thread Iain Buclaw


On Tuesday, 13 August 2013 at 17:38:15 UTC, Jacob Carlborg wrote:
Is there anyone that have a good alternative to Github 
downloads?


Floppy disks. :o)

Re: std.serialization: pre-voting review / discussion


On Wednesday, 14 August 2013 at 09:17:44 UTC, Tove wrote:
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 10:19, Tyler Jameson Little wrote:

- Typo: NonSerialized example should read NonSerialized!(b)


No, it's not a typo. If you read the documentation you'll see 
that:


"If no fields or "this" is specified, it indicates that the 
whole class/struct should not be (de)serialized."


I understand the need for Orange to be backwards compatible, 
but for std.serialization, why isn't the old-style mixin simply 
removed in favor of the UDA.


Furthermore for "template NonSerialized(Fields...)" there is an 
example, while for the new style "struct nonSerialized;" there 
isn't!


I find the newstyle both more intuitive and you also more dry 
not duplicating the identifier: "int b; mixin NonSerialized!(b)"


@nonSerialized struct Foo
{
int a;
int b;
int c;
}

struct Bar
{
int a;
int b;
@nonSerialized int c;
}


I like this a lot more. Phobos just needs to be compatible with 
the current release, so backwards compat is a non-issue here.

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 11:17, Tove wrote:


I understand the need for Orange to be backwards compatible, but for
std.serialization, why isn't the old-style mixin simply removed in favor
of the UDA.


I don't know, it doesn't really hurt to be present. And for anyone using 
Orange they only need to change the imports to have it work with 
std.serialization.



Furthermore for "template NonSerialized(Fields...)" there is an example,
while for the new style "struct nonSerialized;" there isn't!


Good point, I'll add an example.


I find the newstyle both more intuitive and you also more dry not
duplicating the identifier: "int b; mixin NonSerialized!(b)"

@nonSerialized struct Foo
{
 int a;
 int b;
 int c;
}

struct Bar
{
 int a;
 int b;
 @nonSerialized int c;
}


Absolutely.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 11:25, Tyler Jameson Little wrote:


I like this a lot more. Phobos just needs to be compatible with the
current release, so backwards compat is a non-issue here.


I guess this is why we have this thread. I would like to hear comments 
from a couple of others as well about this before deciding.


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 11:15, Tyler Jameson Little wrote:


Well, std.xml needs to be replaced anyway, so it's probably not a good
limitation to have. It may take some work to replace it correctly though...


No, but should std.serialization be on hold until std.xml is replaced?


I'm mostly interested in reducing memory. If I'm (de)serializing a large
object or lots of objects, this could become an issue.

Related question: Have you looked at how much this relies on the GC?


I haven't done any measurements. It will use the GC to deserialize 
values that are normally heap allocated, that is: arrays, associative 
arrays, objects, strings and so on. In addition to that, a pointer to 
each deserialized value is stored in an associative array.


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

2013-08-14 Thread Tove

On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 10:19, Tyler Jameson Little wrote:

- Typo: NonSerialized example should read NonSerialized!(b)


No, it's not a typo. If you read the documentation you'll see 
that:


"If no fields or "this" is specified, it indicates that the 
whole class/struct should not be (de)serialized."


I understand the need for Orange to be backwards compatible, but 
for std.serialization, why isn't the old-style mixin simply 
removed in favor of the UDA.


Furthermore for "template NonSerialized(Fields...)" there is an 
example, while for the new style "struct nonSerialized;" there 
isn't!


I find the newstyle both more intuitive and you also more dry not 
duplicating the identifier: "int b; mixin NonSerialized!(b)"


@nonSerialized struct Foo
{
int a;
int b;
int c;
}

struct Bar
{
int a;
int b;
@nonSerialized int c;
}

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 10:19, Tyler Jameson Little wrote:

Serious:

- doesn't use ranges
  - does this store the entire serialized output in memory?


That's up to the archive how it chooses to implement it. But 
the current XmlArchive does so, yes. I becomes quite limited 
because of std.xml.


Well, std.xml needs to be replaced anyway, so it's probably not a 
good limitation to have. It may take some work to replace it 
correctly though...


  - I would to serialize to a range (file?) and deserialize 
from a

range (file?)


The serialized data is returned as an array, so that is 
compatible with the range interface, it just won't be lazy.


The input data used for deserializing excepts a void[], I don't 
think that's compatible with the range interface.


I'm mostly interested in reducing memory. If I'm (de)serializing 
a large object or lots of objects, this could become an issue.


Related question: Have you looked at how much this relies on the 
GC?



Minor

- Indentation messed up in Serializable example


Right, I'll fix that.


- Typo: NonSerialized example should read NonSerialized!(b)


No, it's not a typo. If you read the documentation you'll see 
that:


"If no fields or "this" is specified, it indicates that the 
whole class/struct should not be (de)serialized."


Ah, missed that.

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 10:19, Tyler Jameson Little wrote:

Serious:

- doesn't use ranges
   - does this store the entire serialized output in memory?


That's up to the archive how it chooses to implement it. But the current 
XmlArchive does so, yes. I becomes quite limited because of std.xml.



   - I would to serialize to a range (file?) and deserialize from a
range (file?)


The serialized data is returned as an array, so that is compatible with 
the range interface, it just won't be lazy.


The input data used for deserializing excepts a void[], I don't think 
that's compatible with the range interface.



Minor

- Indentation messed up in Serializable example


Right, I'll fix that.


- Typo: NonSerialized example should read NonSerialized!(b)


No, it's not a typo. If you read the documentation you'll see that:

"If no fields or "this" is specified, it indicates that the whole 
class/struct should not be (de)serialized."


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


Serious:

- doesn't use ranges
  - does this store the entire serialized output in memory?
  - I would to serialize to a range (file?) and deserialize from 
a range (file?)


Minor

- Indentation messed up in Serializable example
- Typo: NonSerialized example should read NonSerialized!(b)

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 09:46, Dicebot wrote:


I did not mean to answer these questions specifically - just provide a
high-level overview of what std.serialization is. Architecture, use case
domain etc. - to avoid similar confusion from people exploring standard
library documentation. If such misunderstanding has happened once, it is
likely to happen again.


Ok, ok, I'll do that.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 07:43:22 UTC, Jacob Carlborg 
wrote:

On 2013-08-14 09:19, Dicebot wrote:

Jacob, can you add a high-level overview which answers this 
questions?
(in any place you find convenient, until proper place for 
package-wide

documentation is decided).


Actually, I'm not so sure about that. He wants me to do a 
comparison to Thrift.


I did not mean to answer these questions specifically - just 
provide a high-level overview of what std.serialization is. 
Architecture, use case domain etc. - to avoid similar confusion 
from people exploring standard library documentation. If such 
misunderstanding has happened once, it is likely to happen again.

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 09:19, Dicebot wrote:


Jacob, can you add a high-level overview which answers this questions?
(in any place you find convenient, until proper place for package-wide
documentation is decided).


Actually, I'm not so sure about that. He wants me to do a comparison to 
Thrift.


--
/Jacob Carlborg

Re: Ideas for a brand new widget toolkit

On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson 
Little wrote:
Just tried to X forward Chrome on a local lan. It worked, but 
it was dog slow. I can't imagine trying this over a dodgy 
network. The problem is likely that Chrome (like most apps) 
makes extensive use of x frame buffer. This is the way many 
apps are going, and that trend is not likely to change.


Yep, this is pretty much the issue. Any application that needs 
own rendering (any 3d, web browsers, custom widgets) does not 
make use of efficient X primitives - it just renders everything 
into buffer and provides it to server as a whole picture. Of 
course, X wasn't designed to work remotely in such model.


And I actually doubt primitive-based protocol can be created that 
does it generic enough.

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 00:54, glycerine wrote:


I'm included to prefer the Thrift bindings over Orange since I need
binary compression and type safety (XML??? yikes), inter-language
operability, and most essentially, data versioning.

Nonetheless, in order to make a realistic comparison and evaulation, I
need much more of the theory of operation, and a description of the
Orange design.  I appreciate that you worked hard with the
documentation.  But most of the essential description is missing.


It seems like we have a different meaning of "essential". I have 
documented the package for what it is, not for what it's not. It's a 
package for serialization, not a RCP or network package. SSL support 
doesn't make sense, it's like asking "Does std.algorithm.map has SSL 
support?".


You seem to like me to write a comparison to Thrift in the 
documentation. You have to make the comparison yourself.



Here is an outline of serialization tradeoffs and architectural issues
that should be discussed in the documentation.

1. Interface Definition Language (IDL): required or not? If not, how do
know the details of what to serialize. If not, how do you handle/support
data versioning? If not, how do you interoperate without another
language? If yes, which types are supported and what is the syntax and
grammar of the IDL?

2. Is the serialized format independently de-marshallable, or is meta
information required in addition?

3. Which transports if any, are integrated/supported?  Memory buffer,
file descriptor, framed, zero-copy, socket, SSL support, JSON, etc.

4. Are service definitions supported (methods on objects or functions)?
Are they versioned?

5. How compatible is the format with other languages?

6. How compact is the encoding?

7. How fast is to marshal and unMarshal?  What tradeoffs were made.

8. Is there a debug encoding, text that is human readable?

9. To emphasize the important point of the first item again: data
versioning: how do you upgrade your cluster when a data definition
changes?  If your serailization format requires simultaneous downtime
for the entire cluster instead of supporting incremental upgrade, I'd
say your architecture is seriously antiquated.


Many of these questions doesn't even make sense, as I stated above.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 09:32, Dicebot wrote:


http://dlang.org/changelog.html#documentedunittest


Thanks.

--
/Jacob Carlborg

Re: database applications


On Tuesday, 13 August 2013 at 22:42:31 UTC, John Joyus wrote:

On 08/09/2013 07:24 AM, Dejan Lekic wrote:

The answer is NO to all your questions.


I appreciate the straight answer! :)

However, my curiosity for D language has grown recently after I 
read this article,

http://www.drdobbs.com/parallel/the-case-for-d/217801225

So, I will sill learn this language, albeit a little slowly!
I'll start with Ali's book and finish with Andrei's.

Thanks to all,
JJ


I like your spirit.

The main things that led me to like D were:

- GC, but you can go without (a little painful, but not bad)
- simpler templates than C++, but still powerful
- CTFE (not "done" yet, but usable today)

And I stayed because:

- community driven
  - community intelligent and helpful, albeit a little small
- still in development
  - I can still pitch cool ideas and have a chance at them landing
- /+ /* */ +/
  - seriously, why don't other languages allow this?!?

Re: Ideas for a brand new widget toolkit

2013-08-14 Thread qznc


On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:

On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
You mentioned X11 to me before, when we talked about this idea 
over email.


Ah yes. I think X's biggest problem though is that it doesn't 
do *enough*. The protocol is fairly efficient for what it does, 
but it just doesn't do enough so the commands aren't 
particularly compact when you start to get fancier.


For instance, in my crappygui.d, I used XDrawString to draw 
text. This was the result: http://arsdnet.net/gui.png


That's a true type font (Bitstream Vera Sans, a fairly good 
looking font), but X doesn't support antialiasing.


There's a library called Xft that draws fonts prettier. But how 
does it work? Instead of sending DrawText(x, y, "hello world!") 
to the display server, it uses a drawing library to render the 
text as an image in the application, then sends that image to 
the display server.


And BTW if the display doesn't support the alpha blending 
extension (the XRender extension), it first takes a partial 
screenshot, does the blending in library, and sends that image 
back!


Note that the X protocol does not compress the image data. So 
if you send a 100x30 pixel image of text, you're shooting some 
10 KB - or double that without XRender - down the network wire 
instead of the  idk exactly for sure, but I think it is 
about 32 bytes to just send the draw instruction.


Font rendering is often application specific and very
 complex. This is why it is done client-side in X11 nowadays.

State of Text Rendering on Linux: http://behdad.org/text/

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 07:29:48 UTC, Jacob Carlborg 
wrote:
Note that current DDocs version supports to generate 
documentation from
unittests - it lets as make shure that documentation is 
correct. Shall
we add the condition of examples generation from unittests as 
required?


How do I do that?


http://dlang.org/changelog.html#documentedunittest

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 09:19, Dicebot wrote:


Jacob, can you add a high-level overview which answers this questions?
(in any place you find convenient, until proper place for package-wide
documentation is decided).


Yes, I could do that.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion


On 2013-08-14 08:29, ilya-stromberg wrote:


Sorry, I think that example is WRONG!
Your example:

void main ()
{
 auto archive = new XmlArchive!();
 auto serializer = new Serializer;

 auto foo = new Foo;
 foo.a = 3;

 serializer.serialize(foo);
 auto foo2 = serializer.deserialize!(Foo)(archive.untypedData);

 writeln(foo2.a); // prints "3"
 assert(foo.a == foo2.a);
}

As I can see, it should be:

 auto archive = new XmlArchive!();
 auto serializer = new Serializer(archive);

Please fix example or correct me.


Right, good catch.


Note that current DDocs version supports to generate documentation from
unittests - it lets as make shure that documentation is correct. Shall
we add the condition of examples generation from unittests as required?


How do I do that?

--
/Jacob Carlborg

Re: qtD

2013-08-14 Thread Benjamin Thaut


Am 01.08.2013 16:36, schrieb michaelc37:


I compiled against Qt4, I want to try it on Qt5 soon but there is
another annoying issue I discovered when trying to update and compile
all of the qtd exmples: All slot functions must now be declared public..
I'm guessing something changed in traits recently.



Yes since dmd 2.061 typeof no longer works on members you don't have 
access to. But it is possible to bypass this using the tupleof property. 
See typeOfFieldImpl in


https://github.com/Ingrater/druntime/blob/master/src/core/traits.d

Kind Regards
Benjamin Thaut

Re: std.serialization: pre-voting review / discussion

On Wednesday, 14 August 2013 at 02:32:20 UTC, Jonathan M Davis 
wrote:
In general, the tests should be right after the functions that 
they're testing
and not in a separate file. I don't know that it's never 
appropriate to put the
tests in a separate file, but none of Phobos does this right 
now, and I think
that a very good reason is needed for doing it. I also don't 
know that it
works very well with how the Posix makefiles compile and run 
each module's unit

tests separately.

- Jonathan M Davis


There have been no real packages in Phobos so far. Tricky part 
comes when you need to test some functionality that is split 
across several modules - those are technically not _unit_ tests 
and do not belong to any specific module. I don't know what is 
the right approach here but I doubt existing practice can be 
taken blindly.

Re: std.serialization: pre-voting review / discussion


On Tuesday, 13 August 2013 at 22:54:05 UTC, glycerine wrote:

...


Jacob, can you add a high-level overview which answers this 
questions? (in any place you find convenient, until proper place 
for package-wide documentation is decided).

Re: Future of string lambda functions/string predicate functions