Re: [Somewhat OT] Textadept 6.6 released
On Sunday, 2 June 2013 at 08:06:52 UTC, Michael wrote: Looks good. Definitely will try. up Text Adept 7.0 beta 2 (11 Aug 2013) available ;)
Re: OT; Will MS kill .NET ?
On Thursday, 22 August 2013 at 01:40:05 UTC, Gambler wrote: On 8/20/2013 3:18 PM, Paulo Pinto wrote: On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote: http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx How would you implement this in native code? Like we use to do in the old days when we were forced to rewrite Assembly on the fly. Allocate a memory buffer with the required sizes and perform the required set of initializations. This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors. Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code. Yes, I am aware that this requires the ability to execute code from the data segment. -- Paulo Isn't the approach you're describing *much* more error-prone than the example above? It is the compiler that generates the code, what is error prone about it? -- Paulo
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote: On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote: Moor's law is kaput, finish, niet, we don't know how to use the extra transistor. Even if that were true, we have gone quite some distance. Not even talking about Sparc T4 or 8-core X86, my smartphone is more powerful than what I had as computer 10 years or so ago. Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed. A vast amount of software is written in javascript, java, C#, PHP and many safe languages, and still are crippled with bugs. Do I get you right considering js, java, C# and PHP being safe languages? They are dramatically superior to C in term of safety. Like Modula-2, Pascal dialects (mainly Turbo/Apple Pascal) and Ada are, but lost their place in developer's hearts. Now with D, Rust and even Go we can have another go at making system programming a better world. -- Paulo
Re: Why I chose D over Ada and Eiffel
On 08/21/2013 07:12 PM, Andrei Alexandrescu wrote:
The deduper would be insensitive to alpha renaming, e.g. int a = 10;
and int b = 10; would be identical.
This is not alpha renaming, it is just renaming. :o)
Eg. {int a = 10; foo(a);} and {int b = 10; foo(b);} would be identical.
Re: Why I chose D over Ada and Eiffel
On 08/21/2013 07:17 PM, deadalnix wrote: You want no bugs ? Go for Haskell. If you want no bugs, go for formal correctness proof. But you'll get no convenience Yes you do. A lot. or performance. Let's say easily predictable performance. The good thing if that if it does compile, you are pretty sure that it does the right thing.
Re: Range interface for std.serialization
On 2013-08-21 22:21, Dicebot wrote:
It should be range of strings - one call to popFront should serialize
one object from input object range and provide matching string buffer.
How should nesting been handled for a format like XML? Example:
class Bar
{
int a;
}
class Foo
{
int b;
Bar bar;
}
Currently the following XML is procured when serializing Foo:
object runtimeType=main.Foo type=main.Foo key=0 id=0
int key=b id=14/int
object runtimeType=main.Bar type=main.Bar key=bar id=2
int key=a id=33/int
/object
/object
If I shouldn't return the whole object, Foo, how can we know that when
the string for Bar is returned it should actually be nested inside Foo?
I can't imagine a use case for this. Adding ranges just because you can
is not very good :)
Ok.
What this snippet should do?
That was just a dummy snippet to set the data. This is a slightly better
example:
auto archive = new XmlArchive!(string);
auto serializer = new Serializer(archive);
serializer.serialize(new Object);
writeToFile(foo.xml, archive.data);
Now I want to deserialize the data back:
archive.data = readFromFile(foo.xml); // Error, cannot covert
ReadFromFileRange to string
Range-based algorithms don't assign ranges. Transferring data from one
range to another is done via copy(sourceRange, destRange) and similar
tools.
So how should the API look like for setting the data used when
deserializing, like this?
auto data = readFromFile(foo.xml);
auto archive = new XmlArchive!(string);
copy(data, archive.data);
It looks like difficulties come from your initial assumption that one
call to serialize/deserialize implies one object - in that model ranges
hardly are useful. I don't think it is a reasonable restriction. What is
practically useful is (de)serialization of large list of objects lazily
- and this is a natural job for ranges.
It depends on how you look at it. Currently it's only possible to
serialize a single object with a single call to serialize. So if you
want to serialize multiple objects you do as you would do normally in
your code, use an array, a linked list or similar. An array is still a
single object, though it contains multiple objects, that is handled
perfectly fine.
The question is if a range should be treated as multiple objects, and
not a single object (which it really is). How should it be serialized?
* Something like an array, resulting in this XML:
array type=int length=5 key=0 id=0
int key=0 id=11/int
int key=1 id=22/int
int key=2 id=33/int
int key=3 id=44/int
int key=4 id=55/int
/array
* Or like calling serialize multiple times, resulting in this XML:
int key=0 id=01/int
int key=1 id=12/int
int key=2 id=23/int
int key=3 id=34/int
int key=4 id=45/int
* Or as a single object:
Then it would actually serialize the struct/class representing the range.
And the most important question, how should ranges be deserialized? One
have to tell the serializer what type to return, otherwise it won't
work. But the whole point of ranges is that you shouldn't need to know
the type. Sometimes you cannot even name the type, i.e. Voldemort types.
--
/Jacob Carlborg
Re: Range interface for std.serialization
On 2013-08-22 05:13, Tyler Jameson Little wrote:
I don't like this because it still caches the whole object into memory.
In a memory-restricted application, this is unacceptable.
It need to store all serialized reference types, otherwise it cannot
properly serialize a complete object graph. We don't want duplicates.
Example:
The following code:
auto bar = new Bar;
bar.a = 3;
auto foo = new Foo;
foo.a = bar;
foo.b = bar;
Is serialized as:
object runtimeType=main.Foo type=main.Foo key=0 id=0
object runtimeType=main.Bar type=main.Bar key=a id=1
int key=a id=23/int
/object
reference key=b1/reference
/object
When foo.b is just serializes a reference, not the complete object,
because that has already been serialized. The serializer needs to keep
track of that.
I think one call to popFront should release part of the serialized
object. For example:
struct B {
int c, d;
}
struct A {
int a;
B b;
}
The JSON output of this would be:
{
a: 0,
b: {
c: 0,
d: 0
}
}
There's no reason why the serializer can't output this in chunks:
Chunk 1:
{
a: 0,
Chunk 2:
b: {
Etc...
It seems hard to keep track of nesting. I can't see how pretty printing
using this technique would work.
This is just a read-only property, which arguably doesn't break
misconceptions. There should be no reason to assign directly to a range.
How should I set the data used for deserializing?
I agree that (de)serializing a large list of objects lazily is
important, but I don't think that's the natural interface for a
Serializer. I think that each object should be lazily serialized instead
to maximize throughput.
If a Serializer is defined as only (de)serializing a single object, then
serializing a range of Type would be as simple as using map() with a
Serializer (getting a range of Serialize). If the allocs are too much,
then the same serializer can be used, but serialize one-at-a-time.
My main point here is that data should be written as it's being
serialized. In a networked application, it may take a few packets to
encode a larger object, so the first packets should be sent ASAP.
As usual, feel free to destroy =D
Again, how does one keep track of nesting in formats like XML, JSON and
YAML?
--
/Jacob Carlborg
Re: Benchmarking a SIMD implementation of dot product
On 2013-08-22 02:24, Manu wrote: Me... I guess it's time you start :) -- /Jacob Carlborg
Re: s/type tuple/template pack/g please
On 2013-08-21 21:48, captaindet wrote: abstract tuples they are. (we have to alias them to maintain their full function) i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though). concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation. We could call the built-in ones for tuple and typecons.Tuple for anonymous structs. -- /Jacob Carlborg
Re: DQuick a GUI Library (prototype)
On 2013-08-22 01:35, Sebastian Graf wrote: +1 from me too. I had exactly the same idea some time ago, but was overwhelmed by the shear complexity. If you go the lua route, you should look into MoonScript.org (CoffeeScript for lua = nicer function literals) and dig into reactive programming and my take on it: https://github.com/sgraf812/push CoffeeScript is nice too. But I don't see a reason to use something other than a markup language if only a GUI builder should read and write those files. -- /Jacob Carlborg
Re: s/type tuple/template pack/g please
On Thursday, August 22, 2013 09:21:05 Jacob Carlborg wrote: On 2013-08-21 21:48, captaindet wrote: abstract tuples they are. (we have to alias them to maintain their full function) i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though). concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation. We could call the built-in ones for tuple and typecons.Tuple for anonymous structs. Considering that std.typecons.Tuple actually acts like a full-on tuple (it actually nests) and the built-in tuple doesn't, that would be an odd choice IMHO. - Jonathan M Davis
Re: Download page needs a tidy up
On 2013-08-22 05:07, Manu wrote: Where are they? Turns out there are links to the GDC binaries (hosted on bitbucket) on dlang.org/download http://dlang.org/download. ...I didn't previously notice they were there, never scrolled down far enough. The impression you get from the top of the page is that dlang.org http://dlang.org is just DMD related, and I quickly dismissed it previously _ I had no idea there were GDC binaries on http://dlang.org/download.html But there's still no LDC binary there... where is it? I don't know if they were recently added but they are below the GDC binaries. This needs to be fixed. You can argue I'm retarded and ignorant, but as an end user, it should take me no more than 5 seconds to find the download button. I suggest, on the front page of dlang.org http://dlang.org, there should be a MASSIVE button: DOWNLOAD D COMPILERS, and the download page should be tweaked to be more obviously compiler agnostic. I agree. At the top, of the download page there should be three buttons, one for each compiler. Then JavaScript should be used to figure out the platform. Of course we need a fallback for when JavaScript is disabled or one wants to download for a different platform. -- /Jacob Carlborg
Re: Download page needs a tidy up
On 2013-08-22 06:28, Tyler Jameson Little wrote: Why not sniff the platform? I think Firefox Dart websites do this. This can be retrieved with navigator.platform: https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.platform Of course, the others should be easily accessible. Or just using the user agent, since it has to work on all major browsers. -- /Jacob Carlborg
Re: Download page needs a tidy up
On 2013-08-22 05:33, Manu wrote: I was also briefly confused by the 32bit/64bit scattered everywhere. My initial assumption was that it specified the toolchain's target architecture :/ But since it's the compiler's host arch, I'd say that for Windows where 32bit binaries will run on any version of windows and no 64bit binary is offered, and OSX which has only ever been 64bit, there's no need to write it for those platforms. It's just confusing. The architecture are basically never mentioned for Mac OS X downloads. Because everyone assumes universal binaries that will work everywhere. -- /Jacob Carlborg
Re: Download page needs a tidy up
On 2013-08-22 05:37, Tyler Jameson Little wrote: Also, where's the Linux (FreeBSD?, Mac OS X?) downloads for GDC? I get it through my package manager, but it seems there should be a download for it as well. If not a binary, then at least a tar.gz... I don't think there have ever been any self contained packages for Posix with binaries for GDC. -- /Jacob Carlborg
Re: s/type tuple/template pack/g please
On 2013-08-22 09:29, Jonathan M Davis wrote: Considering that std.typecons.Tuple actually acts like a full-on tuple (it actually nests) and the built-in tuple doesn't, that would be an odd choice IMHO. I don't know the exact definition of tuple but what have nesting to do with it? You can add names to the values using std.typecons.Tuple alias Tuple!(int, index, string, value) Entry; Entry e; e.index = 4; e.value = Hello; assert(e[1] == Hello); assert(e[0] == 4); The above is basically exactly like an anonymous struct. -- /Jacob Carlborg
Re: Why I chose D over Ada and Eiffel
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to achieve what quite usually is the goal of generics,
namely generic algorithms in way, i.e. by having to write code
for an algorithm just once. That might seem to be a minor
difference, in particular when looking from a Huh? I can get
it done, so what's the fuss all about, eh? perspective.
Of course, there the C and successors worlds proponents are
right, this incurs a price (which templates do, too ...) and,
yes, in the end, somewhere someone or something must sort the
types out anyway (because of the way CPUs work).
There are basically two ways to implement generics. Type erasure
(Java,Haskell) or template instantiation (C++,D). Instantiation
provides better performance, but sacrifices error messages
(fixable?), binary code size, and compilation modularity
(template implementation must be available for instantiation).
Type safety is not a problem in either approach.
Longer form: http://beza1e1.tuxen.de/articles/generics.html
An interesting twist would be to use type erasure for reference
types and instantiation for value types. Another idea could be to
use instantiation selectively as an optimization and erasure in
general.
Another example is data types, concretely integers. Ada offers
a nice way do precisely nail down precision/storage. If I want
to store days_of_month I can have an integer type holding ints
between 1 and 31 (which, due to the way they implemented it can
be a PITA). Eiffel gives me something quite similar (in a more
elegant way) and additionally a dumb INTEGER (32 or 64 bit)
and than a gazillion subtypes like INTEGER_16. That's great
because in a quick and dirty script a plain integer (max size
of CPU) is good enough and keeps life simple. If I need
days_of_month I can very easily have that as int type.
In D you can use structs:
struct days_of_month {
int day;
/* fill in operator overloading etc */
}
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to achieve what quite usually is the goal of
generics, namely generic algorithms in way, i.e. by having to
write code for an algorithm just once. That might seem to be a
minor difference, in particular when looking from a Huh? I
can get it done, so what's the fuss all about, eh?
perspective.
Of course, there the C and successors worlds proponents are
right, this incurs a price (which templates do, too ...) and,
yes, in the end, somewhere someone or something must sort the
types out anyway (because of the way CPUs work).
There are basically two ways to implement generics. Type
erasure (Java,Haskell) or template instantiation (C++,D).
Instantiation provides better performance, but sacrifices error
messages (fixable?), binary code size, and compilation
modularity (template implementation must be available for
instantiation). Type safety is not a problem in either approach.
Longer form: http://beza1e1.tuxen.de/articles/generics.html
An interesting twist would be to use type erasure for reference
types and instantiation for value types. Another idea could be
to use instantiation selectively as an optimization and erasure
in general.
Which is the way .NET does it.
http://blogs.msdn.com/b/carlos/archive/2009/11/09/net-generics-and-code-bloat-or-its-lack-thereof.aspx
Another example is data types, concretely integers. Ada offers
a nice way do precisely nail down precision/storage. If I want
to store days_of_month I can have an integer type holding ints
between 1 and 31 (which, due to the way they implemented it
can be a PITA). Eiffel gives me something quite similar (in a
more elegant way) and additionally a dumb INTEGER (32 or 64
bit) and than a gazillion subtypes like INTEGER_16. That's
great because in a quick and dirty script a plain integer (max
size of CPU) is good enough and keeps life simple. If I need
days_of_month I can very easily have that as int type.
In D you can use structs:
struct days_of_month {
int day;
/* fill in operator overloading etc */
}
Thanks for the Eiffel info.
Re: s/type tuple/template pack/g please
On Wednesday, 21 August 2013 at 18:50:30 UTC, Ali Çehreli wrote:
On 08/21/2013 11:40 AM, Atash wrote:
I don't see wording 'template pack' being problematic,
assuming that there's
really no other way to use them but through templates (which
AFAIK they
can't).
TypeTuple can represent function parameter lists and array
literal lists as well:
Under the assumption that the following was meant to be a
counterpoint...
import std.typetuple;
void func(int, int)
{}
struct S(int a, int b)
{}
void main()
{
alias tt = TypeTuple!(1, 2);
^ I'm not seeing the case given that TypeTuple is a template.
== What are we *actually* talking about?
I feel like this wasn't well defined, because now I'm feeling
mildly confused with where the discussion has gone.
template Stuff(A...) { stuff } // a sequence/tuple of template
parameters
alias TypeTuple!(stuff) B; // std.TypeTuple
TypeTuple!(stuff) C; // value tuple
I'm inclined to say that the debate is currently about A, but
just to make sure... are we talking about A, B, C, or something
else entirely?
== Annnddd more general stuff
Under the assumption that we are talking about A in the section
above...
IMO, it's almost inevitable that whatever noun you guys decide on
is going to be preceded by the word 'template' in conversation
and in written communication if it isn't there already. While
that sort of casual wording may be easily relegated to a synonym,
it's still worth thinking about, methinks.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 07:24:10 UTC, Jacob Carlborg wrote: On 2013-08-22 01:35, Sebastian Graf wrote: +1 from me too. I had exactly the same idea some time ago, but was overwhelmed by the shear complexity. If you go the lua route, you should look into MoonScript.org (CoffeeScript for lua = nicer function literals) and dig into reactive programming and my take on it: https://github.com/sgraf812/push CoffeeScript is nice too. But I don't see a reason to use something other than a markup language if only a GUI builder should read and write those files. The GUI editor will allow to write expression in addition of a classic value setter. It's really useful to have few pieces of code directly on the GUI side notably when it's only related to the organisations of GUI elements.
Re: Possible solution to template bloat problem?
On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote: On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote: On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote: Happily I'm stupid and completely missed the condescending tone of an evident genius. Instead I'll just be grateful that it pleased one of the D masters to drop some statement down at me at all. Awesome, thank you and keep destroying. destroying??? Which part of not to bash it and of D means a lot to me and of D is, no doubts, an excellent and modern incarnation of C/C++. As far as I'm concerned D is *the* best C/C++ incarnation ever, hands down. was too complicated to understand for your genius brain? I knew this would happen at some point: Andrei uses destroy as a positive term to denote a well-reasoned powerful argument/response. Chill :) Uhum. Well, where I live to destroy has a pretty clear and very negative meaning. I took that post (of Mr. Alexandrescu) as very rude and condescending and I do not intend to change my communication habits so as to understand to destroy as a positive statement or even a compliment. Have you heard the phrase when in Rome... Seriously, you would rather assume a negative meaning/intent even after someone has taken the time to explain the intent/usage of the word/phrase in this grand forum? I sense that you may be beyond reasonable advice at this point? But, if not.. Always start by assuming good intent, if you're right (and you will be 90% of the time) no problem. If you're wrong, well at least you've not gotten worked up about it (so they have failed in their goal) and chances are it will annoy the abuser even more that you haven't (so ultimately, you win). Communication in written form is fraught with pitfalls, and this thread demonstrates how comments can be taken in completely the wrong way. Dicebot's I am dangerously close to hating you. was meant in a friendly way, /you/ decided not to read it that way. Likewise Andrei's style is abrupt but there are good reasons for this, none of which include the goal of offending but /you/ have chosen to read them that way. Sure, more effort could be taken to make it clearer with excess smileys etc. But, that stuff isn't necessary for communicating the content, and isn't necessary between established forum members, and isn't necessary if everyone just assumes good intent from the outset. All the best, Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DQuick a GUI Library (prototype)
On 2013-08-22 10:29, Flamaros wrote: The GUI editor will allow to write expression in addition of a classic value setter. What do you mean with expression ? -- /Jacob Carlborg
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 09:15:27 UTC, Jacob Carlborg wrote: On 2013-08-22 10:29, Flamaros wrote: The GUI editor will allow to write expression in addition of a classic value setter. What do you mean with expression ? something like : function() return parent.width end That the way of how works property binding.
Re: Why I chose D over Ada and Eiffel
On Wednesday, 21 August 2013 at 17:48:49 UTC, Andrei Alexandrescu wrote: No random access. I didn't know about drop-last though - does it work in O(1)? There is nth http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/nth but the O(n) cited there is rather disturbing. More accurately was the point that Clojure's sequence API is (to the best of my understanding) only dealing with forward access, whereas D distinguishes between one-pass, forward, bidirectional, and random, and designs algorithms around these notions. I'll check up with my friend on the forward access side. What certainly seems to be true is that the API doesn't make the useful distinctions/classifications that D does.
Re: s/type tuple/template pack/g please
On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: There's an inordinate amount of confusion around what we currently call type tuple (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years. So: shall we use template pack going forward exclusively whenever we refer to that stuff? That way we can unambiguously use tuple for value tuples, i.e. like mini-structs that group values together. Destroy. I mean criticize. After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key Using this as a reference to my understanding: http://wiki.dlang.org/The_D_Programming_Language/Seq In particular the section: Q: What's the deal with auto-expansion? I think .. type tuples are: - Compile time - A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes) - Flat i.e. auto expanded where used, not nested. - An alias for the elements it contains - A thing in which the ordering is important I am leaning toward the fact that they are an alias being a key property, that and the fact that they are a list or set of things. Sequence may be even better than list as it imples more heavily that the ordering is important. So, I am personally leaning toward dennis's suggestion of Alias Sequence. But, I do worry a little about overloading the term alias. However.. TypeTuple is defined using alias so maybe they are the same thing after all. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: s/type tuple/template pack/g please
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote: There's an inordinate amount of confusion around what we currently call type tuple (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years. So: shall we use template pack going forward exclusively whenever we refer to that stuff? That way we can unambiguously use tuple for value tuples, i.e. like mini-structs that group values together. Destroy. I mean criticize. Many people started to use the sequence term. I think we should stick for that one. Pack is kind of misleading IMO, as they automagically unpack. So template argument sequence. If they happen to all be types/alias/values, types/alias/values sequence.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little wrote: - array operations (int[] a; int[]b; auto c = a * b;) - I don't think these are automagically SIMD'd, but there's always hope =D That isn't allowed. The memory for c must be pre-allocated, and the expression then becomes c[] = a[] * b[]; Is it SIMD'd? It depends. There is a whole load of hand-written assembler for simple-ish expressions on builtin types, on x86. x86_64 is only supported with 32bit integer types because I haven't finished writing the rest yet... However, I'm not inclined to do so at the moment as we need a complete overhaul of that system anyway as it's currently a monster*. It needs to be re-implemented as a template instantiated by the compiler, using core.simd. Unfortunately it's not a priority for anyone right now AFAIK. * hand-written asm loops. If fully fleshed out there would be: ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback loop) * number of supported expressions * number of different types of them. Then there's unrolling considerations. See druntime/src/rt/arrayInt.d
Re: s/type tuple/template pack/g please
Am 22.08.2013 12:05, schrieb Regan Heath: On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: There's an inordinate amount of confusion around what we currently call type tuple (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years. So: shall we use template pack going forward exclusively whenever we refer to that stuff? That way we can unambiguously use tuple for value tuples, i.e. like mini-structs that group values together. Destroy. I mean criticize. After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key Using this as a reference to my understanding: http://wiki.dlang.org/The_D_Programming_Language/Seq In particular the section: Q: What's the deal with auto-expansion? I think .. type tuples are: - Compile time - A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes) - Flat i.e. auto expanded where used, not nested. - An alias for the elements it contains - A thing in which the ordering is important I am leaning toward the fact that they are an alias being a key property, that and the fact that they are a list or set of things. Sequence may be even better than list as it imples more heavily that the ordering is important. So, I am personally leaning toward dennis's suggestion of Alias Sequence. But, I do worry a little about overloading the term alias. However.. TypeTuple is defined using alias so maybe they are the same thing after all. R ~but~ an alias sequence item is different to an alias an alias can't contain untyped values: alias x = 5; alias y = hallo; an alias is an real accessible symbol - not just an position in a sequence or am i wrong here?
Re: Thoughts on possible tuple semantics
So, I took some time to think about this. Let me propose
something close, but different.
I'll try to define sequences more precisely and define some tools
that allow to implement tuples in a nice way on top of it.
A sequence is an ordered set. You can have types, alias and
values sequences. Values sequence can be runtime or compile time.
You can ask for sequences as parameter template using ... and
using the regular template parameter syntax.
template(T) = template(T...)
template(alias T) = template(alias T...)
template(T U, T) = template(T U, T...)
template(T alias U) = template(T alias U..., T...)
Obviously, we want template(T...) to be a special for a
transition period. T... being a subset of alias T..., we can
start with a warning when the use it outside the subset.
It is a breaking change, but reduce the confusion by reusing the
template parameter mechanism. Considering that most people here
are very confused by type tuples, I highly doubt a lot of code is
outside abusing this feature.
A type sequence can be used to define a value sequence :
auto foo(T...)(T args) { ... }
args is a value sequence. It isn't packed as a struct or
anything, simply several values (here several function
parameters) hidden behing one identifier. As a result, args do
not have address or type.
typeof(args) returns T, which is a type sequence (not a type !)
typeid(args) is invalid.
Each member of args however have an address, a type and
everything a function parameter have.
A sequence provide an access to its member via [index] and length
to indicate its length. index need to be a compile time value,
and length is a compile time value.
It is possible to use a sequence to define any ordered set of
stuff (value sequence can be used for function call, type
sequence to create multiple fields in a struct, etc . . .).
Right, most of what is described here is close from what we
already have. Types sequence in a struct can be used to create
tuples and IFTI can make it very handy.
Sequences can be built using the coma operator. int, float is a
type sequence. args[0], args[1] is a value sequence. They can be
returned from functions :
int, int foo() {
return 3, 4;
}
int, int a = foo();
However, due to syntax conflict, int, int a = 3, 4; is not
possible (it the value on the right is an assignment, it conflict
with multiple declarations). () can be used to disambiguate :
int, int a = (3, 4);
The missing piece is an auto dispatch function. I propose here a
simple rewrite rule, as this is simple to implement and can be
really effective.
auto (a, b) = foo();
is rewritten as
auto tmp = foo(); // Here tmp is a sequence of declaration of
value. No need to create lvalues (especially is a complex copy is
involved).
assert(tmp.length == 2); // Should be removed anyway for
sequences.
auto a = tmp[0];
auto b = tmp[1];
This allow to make any user type unpackable. Or even arrays,
slices, randomAccessRanges, etc . . .
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 10:32:06 UTC, dennis luehring wrote: ~but~ an alias sequence item is different to an alias an alias can't contain untyped values: alias x = 5; alias y = hallo; an alias is an real accessible symbol - not just an position in a sequence or am i wrong here? Function literal are passed around via alias all over the place.
Re: DQuick a GUI Library (prototype)
On 2013-08-22 11:28, Flamaros wrote: something like : function() return parent.width end That the way of how works property binding. Can't you bind that to a named method in a controller, or similar? Then you would store the name of the controller/class and the name of the method. -- /Jacob Carlborg
Re: s/type tuple/template pack/g please
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu
wrote:
So: shall we use template pack going forward exclusively
whenever we refer to that stuff?
I think it should be called either a compile-time list or a
static list, because it's a list of things which can be
referred to at compile-time.
import std.typetuple;
void main()
{
int n;
alias T = TypeTuple!(int, 4, n);
static assert(T[1] == 4);
T[2]++;
assert(n == 1);
}
Re: std.serialization: pre-voting review / discussion
On Sunday, 18 August 2013 at 19:46:00 UTC, Jacob Carlborg wrote:
If versioning is crucial it can be added.
Can std.serialization load data if class definition was changed?
For example, we have class Foo:
class Foo
{
int a;
int b;
}
and we serialize it in some file. After that class Foo was
changed:
class Foo
{
int b;
int a;
}
Can std.serialization load data from old file to the new class?
Re: DQuick a GUI Library (prototype)
On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality Could I recommend you evaluate IUP first? (http://www.tecgraf.puc-rio.br/iup/) It is cross-platform, MIT licensed, mature, and is by the same guys that _wrote_ Lua. Oh, and Lua is bundled already, of course. Plus it has a pure C interface (easy to wrap), canvas, GL support, imaging, plotting, webkit, scintilla editor support plus more. I certainly don't want to discourage any input in pure D, but it would be a much less daunting exercise, IMO. I personally think the way D has adopted the CURL library to gain some quick wins in the network protocol area is probably a more sustainable model given the size of the community. Its gonna take a long time to get anywhere if everything is NIH. Just my 2c.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList.
Re: s/type tuple/template pack/g please
On Thu, 22 Aug 2013 11:32:06 +0100, dennis luehring dl.so...@gmx.net
wrote:
Am 22.08.2013 12:05, schrieb Regan Heath:
On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
There's an inordinate amount of confusion around what we currently call
type tuple (embodied in std's TypeTuple). I've been furious
immediately as I got word that Walter called it that way, and it hasn't
failed to make everybody else feel the same over the years.
So: shall we use template pack going forward exclusively whenever we
refer to that stuff? That way we can unambiguously use tuple for
value tuples, i.e. like mini-structs that group values together.
Destroy. I mean criticize.
After reading the thread I think it might help to try to define the
important characteristics of them, and from that select the key
Using this as a reference to my understanding:
http://wiki.dlang.org/The_D_Programming_Language/Seq
In particular the section:
Q: What's the deal with auto-expansion?
I think .. type tuples are:
- Compile time
- A kind of (list, set, group, or collection) of (parameters/arguments,
initialisers, parent classes)
- Flat i.e. auto expanded where used, not nested.
- An alias for the elements it contains
- A thing in which the ordering is important
I am leaning toward the fact that they are an alias being a key
property, that and the fact that they are a list or set of things.
Sequence may be even better than list as it imples more heavily that
the
ordering is important.
So, I am personally leaning toward dennis's suggestion of Alias
Sequence.
But, I do worry a little about overloading the term alias. However..
TypeTuple is defined using alias so maybe they are the same thing
after all.
R
an alias is an real accessible symbol - not just an position in a
sequence
or am i wrong here?
That's not quite what I was trying to say.
I see it as the Alias Sequence being an alias for the entire sequence of
symbols/expressions in the ordering in which they are given/defined.
That said, to actually use them as aliases you need to name them, with an
alias expression, e.g.
// inspired by http://wiki.dlang.org/The_D_Programming_Language/Seq
import std.stdio;
template AliasSeqence(T...){ alias AliasSeqence = T; }
alias one = AliasSeqence!(1);
alias onetwo = AliasSeqence!(one,2);
alias parented = AliasSeqence!(B,C);
alias orphaned = AliasSeqence!();
// Parent list:
interface C { }
class B: orphaned { } // meaning: class B{ }
class A: parented // meaning: class A: B,C{ }
{
this(int a, int b) { writefln(A.a = %d, A.b = %d, a, b); }
}
// Array literal element list:
int[] digits = [0,onetwo,3]; // meaning: [0,1,2,3]
void foo(int a, int b, int c) { writefln(foo(%d,%d,%d), a, b, c); }
void Foo(int a, int b, int c)() { writefln(Foo(%d,%d,%d), a, b, c); }
void main()
{
writefln(digits = %s, digits);
// Function argument list (including struct constructor calls, excluding
arguments to overloaded operators):
foo(onetwo,3); // meaning: foo(1,2,3)
// Template argument list (this is why you cannot have argument lists
nested within argument lists).
Foo!(0,onetwo)(); // meaning: Foo!(0,1,2)
// Index argument list:
int[] arr = new int[2];
arr[one] = 2; // meaning: arr[1]
writefln(arr[one]=%d, arr[one]);
// New argument list(s):
A a = new A(onetwo); // meaning new A(1,2)
}
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: s/type tuple/template pack/g please
On Thu, 22 Aug 2013 12:55:55 +0100, Tommi tommitiss...@hotmail.com wrote: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. +1 I like this suggestion also. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: s/type tuple/template pack/g please
On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote: On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? strictly speaking I think it would be an alias list, so perhaps .aliasList
Re: Possible solution to template bloat problem?
On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote: On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote: On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote: On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote: Happily I'm stupid and completely missed the condescending tone of an evident genius. Instead I'll just be grateful that it pleased one of the D masters to drop some statement down at me at all. Awesome, thank you and keep destroying. destroying??? Which part of not to bash it and of D means a lot to me and of D is, no doubts, an excellent and modern incarnation of C/C++. As far as I'm concerned D is *the* best C/C++ incarnation ever, hands down. was too complicated to understand for your genius brain? I knew this would happen at some point: Andrei uses destroy as a positive term to denote a well-reasoned powerful argument/response. Chill :) Uhum. Well, where I live to destroy has a pretty clear and very negative meaning. I took that post (of Mr. Alexandrescu) as very rude and condescending and I do not intend to change my communication habits so as to understand to destroy as a positive statement or even a compliment. Have you heard the phrase when in Rome... Seriously, you would rather assume a negative meaning/intent even after someone has taken the time to explain the intent/usage of the word/phrase in this grand forum? I sense that you may be beyond reasonable advice at this point? But, if not.. Always start by assuming good intent, if you're right (and you will be 90% of the time) no problem. If you're wrong, well at least you've not gotten worked up about it (so they have failed in their goal) and chances are it will annoy the abuser even more that you haven't (so ultimately, you win). Communication in written form is fraught with pitfalls, and this thread demonstrates how comments can be taken in completely the wrong way. Dicebot's I am dangerously close to hating you. was meant in a friendly way, /you/ decided not to read it that way. Likewise Andrei's style is abrupt but there are good reasons for this, none of which include the goal of offending but /you/ have chosen to read them that way. Sure, more effort could be taken to make it clearer with excess smileys etc. But, that stuff isn't necessary for communicating the content, and isn't necessary between established forum members, and isn't necessary if everyone just assumes good intent from the outset. All the best, Regan Wow. Now I even get general advice for my life like Always start by assuming good intent. How about some honesty? It happens to everybody of us. We hadn't any bad intentions but, alas, someone feels offended, improperly treated, etc. There is exactly 1 proper reaction for a responsible adult: To honestly look Did I contribute to that? and if so, to explain oneself. It would have cost pretty nothing to Mr. A. to simply say OOps. Didn't mean any bad. When I say 'destroy' it's actually in between an invitation to continue hitting with constructive criticism and a compliment. Weird habit of mine. Not even a sorry would be needed. Well, he didn't. Instead he relied on his alpha-dog factor and the fact that there had already been some group members explaining and excusing him (and, in fact and very funnily, when he finally decided to comment he addressed not me but someone else). Meanwhile I'd be better placed to start trouble - if that ever were my intention. I've read a good part of Mr. A's book, watched quite some youtube, both with Mr. Bright and Mr. A. - and I have, to put it in prosecutor like wording, generously enough material in my hands (where Bright/AA basically say something I said too and got bad reactions. But then, it's not really new that it matters in social groups _who_ says sth.). One simple example: Is Mr. A perfectly well capable to talk/write within usual social limits? Yes, he is. His (btw. very well done, if somewhat jumpy) book proves it. He just happens to feel free to behave like an *** in this group, where he is an alpha and where tough lingo and weird personal rites are part of the culture - and glue - of this D crowd. I don't feel hurt, I am not after Mr. A., I'm not looking for trouble and I'm not in fight mode or anti-D or anything like that. But would you (all) kindly refrain from playing your group games with me and telling me bullsh*t? I'm not interested. Mr. A. has written the book on D and he did that quite well. He has largely contributed to D and he did that well and some of his work is even brilliant (for scope alone I'd be willing to praise him gleefully). And he also happened to show himself capable of gross social and human incompetence - and I don't care; I'm interested in his work, not in his person. If at all, I'd point out the professional component, i.e. the question, if it is wise for a relatively new, unknown and little used language to drive newcomers off rather
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote: On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? I think it could be .fieldsof
Re: DQuick a GUI Library (prototype)
On 8/22/13, goughy and...@goughy.org wrote: Could I recommend you evaluate IUP first? (http://www.tecgraf.puc-rio.br/iup/) It doesn't seem to support OSX, Unicode, cascading menus: http://www.tecgraf.puc-rio.br/iup/en/to_do.html But otherwise I agree starting from scratch is really difficult.
Re: DQuick a GUI Library (prototype)
On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 8/22/13, goughy and...@goughy.org wrote: Could I recommend you evaluate IUP first? (http://www.tecgraf.puc-rio.br/iup/) It doesn't seem to support OSX I meant to say native OSX, It uses GTK on that platform.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to achieve what quite usually is the goal of
generics, namely generic algorithms in way, i.e. by having to
write code for an algorithm just once. That might seem to be a
minor difference, in particular when looking from a Huh? I
can get it done, so what's the fuss all about, eh?
perspective.
Of course, there the C and successors worlds proponents are
right, this incurs a price (which templates do, too ...) and,
yes, in the end, somewhere someone or something must sort the
types out anyway (because of the way CPUs work).
There are basically two ways to implement generics. Type
erasure (Java,Haskell) or template instantiation (C++,D).
Instantiation provides better performance, but sacrifices error
messages (fixable?), binary code size, and compilation
modularity (template implementation must be available for
instantiation). Type safety is not a problem in either approach.
Longer form: http://beza1e1.tuxen.de/articles/generics.html
An interesting twist would be to use type erasure for reference
types and instantiation for value types. Another idea could be
to use instantiation selectively as an optimization and erasure
in general.
Another example is data types, concretely integers. Ada offers
a nice way do precisely nail down precision/storage. If I want
to store days_of_month I can have an integer type holding ints
between 1 and 31 (which, due to the way they implemented it
can be a PITA). Eiffel gives me something quite similar (in a
more elegant way) and additionally a dumb INTEGER (32 or 64
bit) and than a gazillion subtypes like INTEGER_16. That's
great because in a quick and dirty script a plain integer (max
size of CPU) is good enough and keeps life simple. If I need
days_of_month I can very easily have that as int type.
In D you can use structs:
struct days_of_month {
int day;
/* fill in operator overloading etc */
}
Thank you.
Well in an OO language the actual type(s) is/are known. So real
genericity boils done to whether an object has the required
functions or not.
D has, obviously piously following the C++ way (which can be a
good thing), chosen to go the template way, that is, to handle it
compile time. Other languages have chosen to do it runtime which
is no worse or better per se but happens to be more consistent
with OO.
Some here argued that, well, in the end, say, a simple int and a
bank account, need different data types and operations because it
matters to CPUs whether it does sth. with a DWORD or a char[].
And, so they argued, therefore you have to pay a runtime penalty
for real generics. I don't think so.
Sure, one evidently pays a penalty for OO in general (as opposed
to simple scalars). But it's not the genericity that costs.
Last but not least, there simply isn't a either/or issue. Once
can perfectly well have both. And no, that doesn't necessarily
bring a performance penalty with it.
Another point of view that doesn't match precisely but may help
to understand it is this:
True OOP is basically about It's the *data*! while systems
programming understandably is closer to it's the *code*!
Where the former has data carrying the operations with them the
latter has data as something that is fed in and processed and
spit out by the machinery. And it's that what brings up the
question Well, but how would the CPU know what kind of data it's
working on? That requires expensive extra steps.
Again, for systems programming that's just fine. But the whole
penalty assumption largely stems from looking at true OOP through
the C/C++ model.
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 11:19:55 UTC, deadalnix wrote: A sequence is an ordered set. You can have types, alias and values sequences. Values sequence can be runtime or compile time. typeof(args) returns T, which is a type sequence (not a type !) typeid(args) is invalid. 1) You propose typeof to result not a type entity. Well, if it can be result of typeof, can be used to declare variables and can be aliased - what makes it different from a type? 2) is(typeof(tuple(42, 42)) == typeof(ctseq(42, 42))) == ? (assuming typeof(args) == T and you don't make distinction between runtime and compile-time value sequences. Also you don't seem to cover mixed sequences which are essential to D templates.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote: Well in an OO language the actual type(s) is/are known. So real genericity boils done to whether an object has the required functions or not. Polymorphism say no, you don't know the actual type, and this is the whole point of OOP : being able to interact with object of various type as long as they provide the needed interface to interact with. D has, obviously piously following the C++ way (which can be a good thing), chosen to go the template way, that is, to handle it compile time. Other languages have chosen to do it runtime which is no worse or better per se but happens to be more consistent with OO. D recognize that OO isn't the only paradigm on earth. And generic won't work with non OO code. Some here argued that, well, in the end, say, a simple int and a bank account, need different data types and operations because it matters to CPUs whether it does sth. with a DWORD or a char[]. And, so they argued, therefore you have to pay a runtime penalty for real generics. I don't think so. Sure, one evidently pays a penalty for OO in general (as opposed to simple scalars). But it's not the genericity that costs. Indirections, opaque calls, and heap allocation are probably the 3 first performance killers on modern architecture. OO embrace the 3 of them. True OOP is basically about It's the *data*! while systems programming understandably is closer to it's the *code*! Where the former has data carrying the operations with them the latter has data as something that is fed in and processed and spit out by the machinery. And it's that what brings up the question Well, but how would the CPU know what kind of data it's working on? That requires expensive extra steps. No true OOP is about behavioral abstraction. See Liskov's substitution principle. Data is merely a tool and OOP promote its encapsulation. In other term, data is an implementation detail in OOP. Again, for systems programming that's just fine. But the whole penalty assumption largely stems from looking at true OOP through the C/C++ model. The whole penalty assumptions come from how actual compilers and CPU works. If you have new idea to revolution both and change the deal, great, but I highly doubt so.
Re: A possible suggestion for the Foreach loop
On 08/21/2013 07:45 PM, Andrei Alexandrescu wrote:
On 8/21/13 4:52 AM, John Colvin wrote:
On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson wrote:
Hello,
I'd like to open up discussion regarding allowing foreach loops which
iterate over a tuple of types to exist outside of function bodies.
I would *LOVE* to have this.
however, once we go down that route, it would be very tempting to allow
a whole lot of other compile-time imperative style programming. Which
would be awesome.
Not necessarily. We could allow static foreach as a functional
construct that binds in turn a symbol to each element in a collection.
...
Yup.
A static foreach in conjunction with string mixins would be great for
simplifying code generation, e.g. for each method in that class
generate a method here.
AFAIK one only reason why it hasn't made it in yet were implementation
issues related to DMD internals? The design was discussed in 2007's
dconf IIRC.
Andrei
We really need to define a consistent semantics for compile time symbol
manipulation though.
Eg:
class C{
int a;
static foreach(x;__traits(allMembers,C)){
mixin(int ~__traits(identifier,x)~b;);
}
}
What is this supposed to do? class C{ int a,ab; }? Non-terminating
compilation? Error?
My best guess is that the above code should be illegal, but there is a
lot of similar code already out in the wild that works by chance. Eg. I
guess some of Manu's bindings only work by luck. Thrift for D also
contains one or two questionable constructs, as David has shown me
recently. (It is possible that this is related to the recent breakage,
DMD does not necessarily behave consistently w.r.t. to this kind of code
across versions.)
Most of the times this has been brought up it was simply ignored, but it
is a glaring hole in D's design.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote: Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed. Well, I can give you a link to some paper that says that the world will break down and stop next tuesday. Interested? A vast amount of software is written in javascript, java, C#, PHP and many safe languages, and still are crippled with bugs. Do I get you right considering js, java, C# and PHP being safe languages? They are dramatically superior to C in term of safety. I know bridges in Siberia that are vastly superior to bridges in the Andes. Frankly, I'd prefer to use a european bridge. And one *can* be in the C/C++ family and have a vastly safer system. Look at D. Some codebase are trully scary. Look at gdb's source code or gtk's. Written in C/C++ ... Well look at phpBB's source code then. Horrible codebase isn't language specific. So? Is this a who knows most programs with lousy coding? contest? All I see there is that programmers, in particular hobby hackers will spot - and use - any chance to wildly shoot around unless they are mildly (or less mildly) guided by a sound and safe system. And I see (and confess for myself) that even seasoned programmers can very much profit from a system that makes it easier to do the right thing and harder to do the wrong thing. You want no bugs ? Go for Haskell. But you'll get no convenience or performance. The good thing if that if it does compile, you are pretty sure that it does the right thing. Why should I? Isn't that what D promises, too (and probably is right)? D promise a pragmatic balance between safety, performance, ease of use, productivity, etc . . . Well, being a systems programming language D is condemned to keep quite some doors open. It seems (as far as I can that now) however to have done an excellent job in terms of safety (give or take some minor sins like '=' as assignment). One might put Java against D. But frankly, I do not consider Javas approach Subdue them with pervert bureaucracy, hehe approach as acceptable (and it creates a whole set of problems, too). Frankly, if I had to work on a highly safety critical and reliable project (say in the medical area) I would have a hard time to spot just 5 languages that I would consider. Ada comes to mind (but I don't like it) and Eiffel, which is great but that great pragmatically. I'm afraid I'd end up where I ended up in the first place: Eiffel vs. D. I'm probably not counted as a happy D protagonist around here but I'd happily state that D is way ahead of 99% of the known languages. And that expressly includes safety. On another perspective: Consider this question Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like? My guess: Upwards of 80% would happily chime YES!. Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ? I refuse to answer that because it's way out of reality.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 11:39:29 UTC, Jacob Carlborg wrote: On 2013-08-22 11:28, Flamaros wrote: something like : function() return parent.width end That the way of how works property binding. Can't you bind that to a named method in a controller, or similar? Then you would store the name of the controller/class and the name of the method. That not always so simple. With DQuick the D application is like a slave that contains data, and the GUI is free to display the data in many ways. Property binding act like a part of the controller if we are talking about the MVC model. Notice that if a data in the application side change, depending properties binding will be updated, so the GUI too. At my office we port an application from iOS to Android, Windows and MacOSX. We actually rewrite the GUI for other platforms in QtQuick, which allow us to let the main code has it. We only add few wrappers because QtQuick support only Qt types for objects we need to bind in QML (javascript language used for GUI).
Re: A possible suggestion for the Foreach loop
On 08/21/2013 09:17 PM, Dicebot wrote: They are orthogonal and not exclusive. declaration foreach can appear whenever declaration can appear and insert new declarations, contrary to statements of normal foreach. static foreach is simply an improvement over existing tuple foreach concept which allows it to work with a wider variety of input. Former is about context of foreach itself, latter - about behavior of the loop. I disagree. I think the relationship between foreach and static foreach should essentially mirror that of if and static if.
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 12:50:06 UTC, Dicebot wrote:
On Thursday, 22 August 2013 at 11:19:55 UTC, deadalnix wrote:
A sequence is an ordered set. You can have types, alias and
values sequences. Values sequence can be runtime or compile
time.
typeof(args) returns T, which is a type sequence (not a type !)
typeid(args) is invalid.
1) You propose typeof to result not a type entity. Well, if
it can be result of typeof, can be used to declare variables
and can be aliased - what makes it different from a type?
It is a sequence of types. It can be used to declare a sequence
of variables.
2) is(typeof(tuple(42, 42)) == typeof(ctseq(42, 42))) == ?
(assuming typeof(args) == T and you don't make distinction
between runtime and compile-time value sequences.
In my proposal, tuple are a library construct. The proposal
introduce the necessary tooling to implement them nicely.
is(typeof(42, 42) == (int, int));
is(typeof(tuple(42, 42)) == a library defined struct);
It could be defined as follow :
struct Tuple(T...) {
T expand;
alias expand this;
}
Also you don't seem to cover mixed sequences which are
essential to D templates.
Theses are alias sequences.
Re: A possible suggestion for the Foreach loop
On 08/21/2013 10:53 PM, Dylan Knutson wrote:
I do like the idea of it being called 'static foreach' instead of
'foreach', to keep in step with how the rest of the language handles
other compile time constructs (static assert). Plus, as you said in your
bugreport, visual disambiguation between that and a runtime foreach is
nice feedback for the programmer to pick up instantly.
It's important to keep them separate regardless. static foreach is close
to useless if it introduces a new scope for its body.
I.e.:
int main(){
foreach(_;Seq!int){
int x;
}
return x; // error
}
int main(){
static foreach(_;Seq!int){
int x;
}
return x; // ok
}
Re: A possible suggestion for the Foreach loop
On 08/22/2013 02:56 PM, Timon Gehr wrote: AFAIK one reason why it hasn't made it in yet were implementation issues related to DMD internals? The design was discussed in 2007's dconf IIRC. fixed.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote: On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? This feature should be dropped and provided as library using compile time reflection.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 12:34:20 UTC, Andrej Mitrovic wrote: But otherwise I agree starting from scratch is really difficult. That the reason we only tell that is a prototype, we firstly want to test the property binding concept, and we choose D because we like it.
Re: DQuick a GUI Library (prototype)
On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality If you do decide to use Lua, I strongly recommend checking out LuaD[1]. Shameless self-promotion, yes; but the goal of LuaD is to be an uncompromising, superior alternative to using the Lua C API directly, for any project. [1] https://github.com/JakobOvrum/LuaD
Re: s/type tuple/template pack/g please
On 08/22/2013 03:07 PM, deadalnix wrote: On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote: On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? This feature should be dropped and provided as library using compile time reflection. How to bypass protection attributes?
Re: std.serialization: pre-voting review / discussion
On 2013-08-22 13:57, ilya-stromberg wrote:
Can std.serialization load data if class definition was changed?
For example, we have class Foo:
class Foo
{
int a;
int b;
}
and we serialize it in some file. After that class Foo was changed:
class Foo
{
int b;
int a;
}
Can std.serialization load data from old file to the new class?
Yes. In this case it will use the name of the instance fields when
searching for values in the archive.
--
/Jacob Carlborg
Re: Download page needs a tidy up
On Thursday, 22 August 2013 at 03:23:57 UTC, Manu wrote: I got the latest GDC from dlang.org/download, but it doesn't work. libiconv-2.dll (and possibly others?) is not included in the package. If this depends on another package being present, there is no text anywhere along the download path to inform the user. On 22 August 2013 13:07, Manu turkey...@gmail.com wrote: So I'm trying to find windows binaries for GDC and LDC... First place I look is dlang.org/download. Appears to be for DMD... keep looking. I look at the GDC/LDC wiki pages. No links to binaries anywhere. GDC and LDC home pages... no links to binaries. Github doesn't host binaries anymore... Where are they? Turns out there are links to the GDC binaries (hosted on bitbucket) on dlang.org/download. ...I didn't previously notice they were there, never scrolled down far enough. The impression you get from the top of the page is that dlang.orgis just DMD related, and I quickly dismissed it previously _ But there's still no LDC binary there... where is it? This needs to be fixed. You can argue I'm retarded and ignorant, but as an end user, it should take me no more than 5 seconds to find the download button. I suggest, on the front page of dlang.org, there should be a MASSIVE button: DOWNLOAD D COMPILERS, and the download page should be tweaked to be more obviously compiler agnostic. D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC (surely basically nobody is looking for those?), perhaps they should be reduced to small test links with the other links down the bottom of the page? This will allow room to present GDC and LDC without scrolling. And why is there no LDC binary? I am completely with you, Manu. Same with me with GDC under Windows. Missing libiconv-2.dll... The same happened to me when looking around for the other two D compilers. It took me a couple of days until I found the link on the dlang.org's download page. Any suggestions on where to get a working copy of GDC to run on Windows, please? Thanks, Ludovit
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:10:28 UTC, Timon Gehr wrote: On 08/22/2013 03:07 PM, deadalnix wrote: On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote: On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said: On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote: I think it should be called either a compile-time list ... And if we go with compile-time list, then we can follow the example of std.regex.ctRegex and name the thing ctList. Will .tupleof become .ctlistof? This feature should be dropped and provided as library using compile time reflection. How to bypass protection attributes? compile time reflection should be able to do it. Discussion has been raised many time.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote: On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote: On another perspective: Consider this question Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like? My guess: Upwards of 80% would happily chime YES!. Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ? I would, because my experience with Native Oberon and AOS (Blue Bottle), teached me that those real time capabilities are possible in a desktop OS written in a GC enabled systems programming language. As example, BlueBottle has a video player, just the decoder has some snippets written in Assembly. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?action=downloadupname=AosScreenshot1.jpg -- Paulo
Re: DQuick a GUI Library (prototype)
On 2013-08-22 15:01, Flamaros wrote: That not always so simple. With DQuick the D application is like a slave that contains data, and the GUI is free to display the data in many ways. Property binding act like a part of the controller if we are talking about the MVC model. Notice that if a data in the application side change, depending properties binding will be updated, so the GUI too. If I understand you correctly that's how it work on using Xcode on Mac OS X as well. But Apple manage without a script language for the GUI code. It's XML and a binary format. -- /Jacob Carlborg
Re: DQuick a GUI Library (prototype)
On 2013-08-22 14:39, Andrej Mitrovic wrote: I meant to say native OSX, It uses GTK on that platform. Thank you, otherwise you might have made some Mac OS X users angry :) -- /Jacob Carlborg
Re: DQuick a GUI Library (prototype)
On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: It doesn't seem to support OSX, Unicode, cascading menus: http://www.tecgraf.puc-rio.br/iup/en/to_do.html But otherwise I agree starting from scratch is really difficult. Plus it seems to flicker on resize. It's not looking good.
Re: DQuick a GUI Library (prototype)
On 8/22/13, Jacob Carlborg d...@me.com wrote: On 2013-08-22 14:39, Andrej Mitrovic wrote: I meant to say native OSX, It uses GTK on that platform. Thank you, otherwise you might have made some Mac OS X users angry :) Hey I'm not on the OSX hate-train. :)
Re: Download page needs a tidy up
On Thursday, 22 August 2013 at 03:38:26 UTC, Tyler Jameson Little wrote: Do we really want D1 compilers that easily accessable? Considering D1 has an entire site of its own[0], why are they even there? Move them to where they belong with a BIG RED BANNER saying they're EOL and an are you sure you want this? confirmation to download them. -Wyatt [0] http://www.digitalmars.com/d/1.0/
Re: s/type tuple/template pack/g please
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote: There's an inordinate amount of confusion around what we currently call type tuple (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years. So: shall we use template pack going forward exclusively whenever we refer to that stuff? That way we can unambiguously use tuple for value tuples, i.e. like mini-structs that group values together. I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple: TypeTuple!(int, string) myExpressionTuple; myExpressionTuple[0] = 42; myExpressionTuple[1] = foo; // etc If we don't have an easy way to refer to this distinction with the new naming, it may not be adequate enough for everyone to discard the old, confusing names, which could potentially seriously stall adoption, as it would be tempting to use the old terms in certain situations. We also have the naming of std.traits' `isTypeTuple` and `isExpressionTuple` to think about. On a different tangent; changes like this are probably easier to push through when they have a strong air of officialness. Thank you for starting the process with this thread. An idea would be to have Walter and/or yourself (Andrei) pick a short list of names you think make the most sense after the discussion has unfolded, then put them on a vote. If it ends in a tie, the two of you could exercise executive discretion in choosing the winner. The result could then be an official announcement that we could share in the community to further adoption. Destroy. I mean criticize. Oh please, I think destroy reflects a healthy prevalence of openness to criticism in this community, let's not stop using it just because one or two newbies have announced some mild displeasure with it :P
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 13:20:25 UTC, Jacob Carlborg wrote: On 2013-08-22 15:01, Flamaros wrote: That not always so simple. With DQuick the D application is like a slave that contains data, and the GUI is free to display the data in many ways. Property binding act like a part of the controller if we are talking about the MVC model. Notice that if a data in the application side change, depending properties binding will be updated, so the GUI too. If I understand you correctly that's how it work on using Xcode on Mac OS X as well. But Apple manage without a script language for the GUI code. It's XML and a binary format. A lot of GUI system that respect the MVC system put the controller in the native code.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote: I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple: TypeTuple!(int, string) myExpressionTuple; myExpressionTuple[0] = 42; myExpressionTuple[1] = foo; // etc One extra source of confusion is that expression tuple was often used for TypeTuple!(42, foo) ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.
Re: Benchmarking a SIMD implementation of dot product
On Wednesday, 21 August 2013 at 21:11:48 UTC, Andrei Alexandrescu wrote: Loosely related question I've always been curious about: are there people who follow this newsgroup but not the announce group? Hi there. I assumed announce was for...well, announcements. Like official releases and such. Looking, I'm even sort of correct. Incidentally, it may be kind of cool to aggregate release announcements of various D-related tools into a sidebar of the Downloads Tools page or similar. -Wyatt
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 13:29:10 UTC, Andrej Mitrovic wrote: On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: It doesn't seem to support OSX, Unicode, cascading menus: http://www.tecgraf.puc-rio.br/iup/en/to_do.html But otherwise I agree starting from scratch is really difficult. Plus it seems to flicker on resize. It's not looking good. Yep, it's a known issue. I don't know why the resize event of window come so late, it seems to be a SDL issue. I began a direct win32 implementation, but their is no display for the moment, something seems to be wrong with the opengl context.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote: One extra source of confusion is that expression tuple was often used for TypeTuple!(42, foo) ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed. They are one and the same.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:46:12 UTC, Jakob Ovrum wrote: On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote: One extra source of confusion is that expression tuple was often used for TypeTuple!(42, foo) ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed. They are one and the same. Almost, but not completely. They share implementation and much of observable behavior (and former can be used to initialize latter) but one is mutable run-time entity and other - compile-time (and thus, of course, constant). As they don't have proper representation in the type system, it makes them quite different.
Re: Benchmarking a SIMD implementation of dot product
On 22 August 2013 17:24, Jacob Carlborg d...@me.com wrote: On 2013-08-22 02:24, Manu wrote: Me... I guess it's time you start :) Surely there's nothing interesting there that doesn't end up here anyway? ;)
Re: Download page needs a tidy up
On 22 August 2013 17:33, Jacob Carlborg d...@me.com wrote: On 2013-08-22 05:33, Manu wrote: I was also briefly confused by the 32bit/64bit scattered everywhere. My initial assumption was that it specified the toolchain's target architecture :/ But since it's the compiler's host arch, I'd say that for Windows where 32bit binaries will run on any version of windows and no 64bit binary is offered, and OSX which has only ever been 64bit, there's no need to write it for those platforms. It's just confusing. The architecture are basically never mentioned for Mac OS X downloads. Because everyone assumes universal binaries that will work everywhere. ... what? Isn't that what I just said? Did you actually look at Brad's page upgrade?
Re: Download page needs a tidy up
On 22 August 2013 17:32, Jacob Carlborg d...@me.com wrote: On 2013-08-22 05:07, Manu wrote: But there's still no LDC binary there... where is it? I don't know if they were recently added but they are below the GDC binaries. Can't see any. I can only see binaries for platforms that nobody uses ;)
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 13:01:51 UTC, deadalnix wrote:
It is a sequence of types. It can be used to declare a sequence
of variables.
That implies defining sequence of X as special entity on
official spec and update 'alias', 'typeof' and template docs to
reference it as a special case.
In my proposal, tuple are a library construct. The proposal
introduce the necessary tooling to implement them nicely.
is(typeof(42, 42) == (int, int));
is(typeof(tuple(42, 42)) == a library defined struct);
It could be defined as follow :
struct Tuple(T...) {
T expand;
alias expand this;
}
It is exactly what we have right now. So you think having two
different types of expression/value tuples is fine?
Also you don't seem to cover mixed sequences which are
essential to D templates.
Theses are alias sequences.
As I have already said, it is no less confusing to classify as
alias sequence something that is not limited to aliases.
Re: Possible solution to template bloat problem?
On Thursday, 22 August 2013 at 12:11:29 UTC, Ramon wrote: On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote: On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote: On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote: On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote: Look, is not about alphas, crowds and so on. It is a simple misunderstanding that escalated. Let's end this trouble. There is a lot of work that awaits to be done.
std.logger
I'm still missing a logging facility in D and as the last attempt seam to have stopped I want to throw in my version. After reading through the std.log thread I made my conclusions and created my own logger. People seamed to be unhappy with the naming and the way of configuration. Additionally when to throw or not to throw seamed to be an argument. My attempt is to provide a very small functional interface to logging. IMO it is impossible to fulfill all requirements a D developer can have through configuration classes and such, I designed the a abstract Logger class that can be easily implemented to one's own needs. As a quick start feature I created a Stdio- and File-Logger. If no Logger is provided to the log function a defaultLogger will be used. Docu: http://burner.github.io/phobos/phobos-prerelease/std_logger.html Pull Request: https://github.com/D-Programming-Language/phobos/pull/1500 I hope this will lead to some progress in phobos, when it comes to message logging.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote: There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach. See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D. That said, I like the D approach of putting a lot of power in the macro-like template system. I worry more about the reliance on GC in a systems programming language, as historically that's been a losing proposition. -- Brian
Re: Range interface for std.serialization
On Thursday, 22 August 2013 at 07:16:11 UTC, Jacob Carlborg wrote:
On 2013-08-22 05:13, Tyler Jameson Little wrote:
I don't like this because it still caches the whole object
into memory.
In a memory-restricted application, this is unacceptable.
It need to store all serialized reference types, otherwise it
cannot properly serialize a complete object graph. We don't
want duplicates. Example:
The following code:
auto bar = new Bar;
bar.a = 3;
auto foo = new Foo;
foo.a = bar;
foo.b = bar;
Is serialized as:
object runtimeType=main.Foo type=main.Foo key=0 id=0
object runtimeType=main.Bar type=main.Bar key=a
id=1
int key=a id=23/int
/object
reference key=b1/reference
/object
When foo.b is just serializes a reference, not the complete
object, because that has already been serialized. The
serializer needs to keep track of that.
Right, but it doesn't need to keep the serialized data in memory.
I think one call to popFront should release part of the
serialized
object. For example:
struct B {
int c, d;
}
struct A {
int a;
B b;
}
The JSON output of this would be:
{
a: 0,
b: {
c: 0,
d: 0
}
}
There's no reason why the serializer can't output this in
chunks:
Chunk 1:
{
a: 0,
Chunk 2:
b: {
Etc...
It seems hard to keep track of nesting. I can't see how pretty
printing using this technique would work.
Can't you just keep a counter? When you enter anything that would
increase the indentation level, increment the indentation level.
When leaving, decrement. At each level, insert whitespace equal
to indentationLevel * whitespacePerLevel. This seems pretty
trivial, unless I'm missing something.
Also, I didn't check, but it turns off pretty-printing be
default, right?
This is just a read-only property, which arguably doesn't break
misconceptions. There should be no reason to assign directly
to a range.
How should I set the data used for deserializing?
How about passing it in with a function? Each range passed this
way would represent a single object, so the current
deserialize!Foo(InputRange) would work the same way it does now.
I agree that (de)serializing a large list of objects lazily is
important, but I don't think that's the natural interface for a
Serializer. I think that each object should be lazily
serialized instead
to maximize throughput.
If a Serializer is defined as only (de)serializing a single
object, then
serializing a range of Type would be as simple as using map()
with a
Serializer (getting a range of Serialize). If the allocs are
too much,
then the same serializer can be used, but serialize
one-at-a-time.
My main point here is that data should be written as it's being
serialized. In a networked application, it may take a few
packets to
encode a larger object, so the first packets should be sent
ASAP.
As usual, feel free to destroy =D
Again, how does one keep track of nesting in formats like XML,
JSON and YAML?
YAML will take a little extra care since whitespace is
significant, but it should work well enough as I've described
above.
Re: Possible solution to template bloat problem?
On Thu, 22 Aug 2013 13:11:28 +0100, Ramon s...@thanks.no wrote: On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote: On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote: Well, where I live to destroy has a pretty clear and very negative meaning. I took that post (of Mr. Alexandrescu) as very rude and condescending and I do not intend to change my communication habits so as to understand to destroy as a positive statement or even a compliment. Have you heard the phrase when in Rome... Seriously, you would rather assume a negative meaning/intent even after someone has taken the time to explain the intent/usage of the word/phrase in this grand forum? I sense that you may be beyond reasonable advice at this point? But, if not.. Always start by assuming good intent, if you're right (and you will be 90% of the time) no problem. If you're wrong, well at least you've not gotten worked up about it (so they have failed in their goal) and chances are it will annoy the abuser even more that you haven't (so ultimately, you win). Communication in written form is fraught with pitfalls, and this thread demonstrates how comments can be taken in completely the wrong way. Dicebot's I am dangerously close to hating you. was meant in a friendly way, /you/ decided not to read it that way. Likewise Andrei's style is abrupt but there are good reasons for this, none of which include the goal of offending but /you/ have chosen to read them that way. Sure, more effort could be taken to make it clearer with excess smileys etc. But, that stuff isn't necessary for communicating the content, and isn't necessary between established forum members, and isn't necessary if everyone just assumes good intent from the outset. All the best, Regan Wow. Now I even get general advice for my life like Always start by assuming good intent. .. and have you taken that advice as it was intended? With good intent? Or are you still assuming the worst in people? How about some honesty? Who isn't being honest? It happens to everybody of us. We hadn't any bad intentions but, alas, someone feels offended, improperly treated, etc. There is exactly 1 proper reaction for a responsible adult: To honestly look Did I contribute to that? and if so, to explain oneself. It would have cost pretty nothing to Mr. A. to simply say OOps. Didn't mean any bad. When I say 'destroy' it's actually in between an invitation to continue hitting with constructive criticism and a compliment. Weird habit of mine. Not even a sorry would be needed. The issue is that you've got this totally backwards. In some countries people carry bodily fluids around in a small square of cloth in their pockets, in others they blow them straight onto the side walk. If one is the norm and you're offended by it does someone owe you an apology? Here, on this forum, destroy has a well known meaning which is the norm. If someone uses it, and you are offended, do they owe you an apology? The answer in both case, IMO, is no. snip I can't think of anything constructive to say in response to the rest of that, except that you seem to have a very different view of this community than I do... R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 14:03:13 UTC, Dicebot wrote: It is exactly what we have right now. So you think having two different types of expression/value tuples is fine? One is a tuple, the other is a sequence. They are different beast and have different behavior. The fact that it is similar to what we have now is on purpose, so we don't need to break a lot of code. Plus, with the proposed addition, it allow for nice library tuples. Also you don't seem to cover mixed sequences which are essential to D templates. Theses are alias sequences. As I have already said, it is no less confusing to classify as alias sequence something that is not limited to aliases. It is what alias parameter for templates are. Simply keeping the terminology here.
Re: Possible solution to template bloat problem?
Human language rarely has any clear and well-defined meanings. Without cultural context it is almost nothing. Actually, in fact people almost never understand each other, they always operate within some amount of false assumptions. In that regard, Andrei, who has been using well-established communication protocol understood by most part of this community was most honest and reasonable in expressing his intentions. Failure to understand that is always your failure as proper communication is always defined by community and never by beliefs of some people. Scorning from my side is not because of opinions you express or technical goals you find important. It is because of sermon flavor that overwhelms all your comments. No reasonable man can think his beliefs and/or habits are any exceptional. Denying this and refusing to properly study domain you oppose is quite reliable indicator of ignorance or trolling. Probably both and I shouldn't really care about the difference. I must admit I am quite fast to lose my temper and tend to overreact sometimes. However, it makes me sad to see that D community falls into completely opposite extreme - wasting time and efforts in useless attempts to satisfy people who are simply mocking it, whenever form it may take.
Re: Thoughts on possible tuple semantics
On Thu, 22 Aug 2013 15:03:12 +0100, Dicebot pub...@dicebot.lv wrote: Also you don't seem to cover mixed sequences which are essential to D templates. Theses are alias sequences. As I have already said, it is no less confusing to classify as alias sequence something that is not limited to aliases. I was thinking of it the other way round, as in .. It is not a sequence of aliases, but an alias for a sequence of .. expressions(?). Perhaps calling it an aliased sequence makes that clearer? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: windows .lib files (dmc has them, dmd doesn't)
So, what's the plan here?
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 14:22:50 UTC, deadalnix wrote: One is a tuple, the other is a sequence. They are different beast and have different behavior. The fact that it is similar to what we have now is on purpose, so we don't need to break a lot of code. Plus, with the proposed addition, it allow for nice library tuples. I am confused. You proposed tuple implementation is essentially the very same current std.typecons.Tuple is. So I can see only two differences between value sequence and tuple: 1) latter has address and ABI 2) former auto-expands Anything else? Theses are alias sequences. As I have already said, it is no less confusing to classify as alias sequence something that is not limited to aliases. It is what alias parameter for templates are. Simply keeping the terminology here. Wait, what? Alias parameters for templates have nothing to do with template argument lists (other than being one possible type of that list element). In other words, T... can contain more stuff than alias T... (imaginary syntax). And, considering the fact that we already have two different alias semantics (for template alias parameters and normal aliases), it is a dangerous terminology to chose anyway.
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 14:32:27 UTC, Dicebot wrote: Well, it falls into the same issue named after what you can do with it vs named after what it is. The very meaning of word alias suggests that calling something alias for X is just adding naming indirection on top of X ;) That is what an alias parameter is, and I do think that regular alias and alias parameter should converge.
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 14:29:50 UTC, Dicebot wrote: Wait, what? Alias parameters for templates have nothing to do with template argument lists (other than being one possible type of that list element). In other words, T... can contain more stuff than alias T... (imaginary syntax). other than being one possible type of that list element Indeed it is the only possible meaning and it the right one. And, considering the fact that we already have two different alias semantics (for template alias parameters and normal aliases), it is a dangerous terminology to chose anyway. Yes, the term have 2 meanings. I simply reuse one of theses meaning without adding a new one.
Re: Thoughts on possible tuple semantics
On Thursday, 22 August 2013 at 14:27:01 UTC, Regan Heath wrote: On Thu, 22 Aug 2013 15:03:12 +0100, Dicebot pub...@dicebot.lv wrote: Also you don't seem to cover mixed sequences which are essential to D templates. Theses are alias sequences. As I have already said, it is no less confusing to classify as alias sequence something that is not limited to aliases. I was thinking of it the other way round, as in .. It is not a sequence of aliases, but an alias for a sequence of .. expressions(?). Perhaps calling it an aliased sequence makes that clearer? R Well, it falls into the same issue named after what you can do with it vs named after what it is. The very meaning of word alias suggests that calling something alias for X is just adding naming indirection on top of X ;)
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:53:45 UTC, Dicebot wrote: Almost, but not completely. They share implementation and much of observable behavior (and former can be used to initialize latter) but one is mutable run-time entity and other - compile-time (and thus, of course, constant). As they don't have proper representation in the type system, it makes them quite different. I don't think it's correct or useful to label one as compile-time and the other as runtime. I think the mutability or immutability of the expression tuple is an obvious result of its lvalue-ish or rvalue-ish nature, respectively. As such - with the current semantics - I'm not sure it's important to be able to easily distinguish the two. I'd be happy to be convinced otherwise if you think it's important.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote: See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D. Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons. As have been discussed recently, ancient object file / linker tool stack harms it much more when comes to practice.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote: On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote: I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple: TypeTuple!(int, string) myExpressionTuple; myExpressionTuple[0] = 42; myExpressionTuple[1] = foo; // etc One extra source of confusion is that expression tuple was often used for TypeTuple!(42, foo) ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed. That is in the doc : A Tuple whose elements consist entirely of types is called a TypeTuple. A Tuple whose elements consist entirely of expressions is called an ExpressionTuple. http://dlang.org/template.html#TemplateTupleParameter
Re: Range interface for std.serialization
On Thursday, 22 August 2013 at 03:13:46 UTC, Tyler Jameson Little wrote: On Wednesday, 21 August 2013 at 20:21:49 UTC, Dicebot wrote: It should be range of strings - one call to popFront should serialize one object from input object range and provide matching string buffer. I don't like this because it still caches the whole object into memory. In a memory-restricted application, this is unacceptable. Well, in memory-restricted applications having large object at all is unacceptable. Rationale is that you hardly ever want half-deserialized object. If environment is very restrictive, smaller objects will be used anyway (list of smaller objects). ... There's no reason why the serializer can't output this in chunks Outputting on its own is not useful to discuss - in pipe model output matches input. What is the point in outputting partial chunks of serialized object if you still need to provide it as a whole to the input?
Re: Benchmarking a SIMD implementation of dot product
On 22 August 2013 15:59, Manu turkey...@gmail.com wrote: On 22 August 2013 17:24, Jacob Carlborg d...@me.com wrote: On 2013-08-22 02:24, Manu wrote: Me... I guess it's time you start :) Surely there's nothing interesting there that doesn't end up here anyway? ;) I never announcement anything in here at least. ;-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Range interface for std.serialization
I'll focus on part I find crucial: On Thursday, 22 August 2013 at 07:08:28 UTC, Jacob Carlborg wrote: The question is if a range should be treated as multiple objects, and not a single object (which it really is). How should it be serialized? * Something like an array, resulting in this XML: array type=int length=5 key=0 id=0 int key=0 id=11/int int key=1 id=22/int int key=2 id=33/int int key=3 id=44/int int key=4 id=55/int /array * Or like calling serialize multiple times, resulting in this XML: int key=0 id=01/int int key=1 id=12/int int key=2 id=23/int int key=3 id=34/int int key=4 id=45/int Is there a reasons arrays needs to be serialized as (1), not (2)? I'd expect any input-range compliant data to be serialized as (2) and lazy. That allows you to use deserializer as a pipe over some sort of network-based string feed to get a potentially infinite input range of deserialized objects.
Re: Range interface for std.serialization
On Thursday, 22 August 2013 at 14:48:57 UTC, Dicebot wrote: Outputting on its own is not useful to discuss - in pipe model output matches input. What is the point in outputting partial chunks of serialized object if you still need to provide it as a whole to the input? Partial chunks of serialized objects can be useful for applications that aren't immediately deserializing: E.g. sending over a network, storing to disk etc.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote: I don't think it's correct or useful to label one as compile-time and the other as runtime. I think the mutability or immutability of the expression tuple is an obvious result of its lvalue-ish or rvalue-ish nature, respectively. As such - with the current semantics - I'm not sure it's important to be able to easily distinguish the two. I'd be happy to be convinced otherwise if you think it's important. I don't know either :) I am just trying to find some order in existing scheme. What frustrates me most in expression sequences being both runtime and compile-time is that compile-time still can act as if they are almost types: alias a = TypeTuple!(1, 2); // ok auto b = TypeTuple!(1, 2); // also ok! Isn't it the only entity in the whole language that can be used in type context (alias) and value context (initializer) at the same time?
Re: DQuick a GUI Library (prototype)
On 8/22/13, Flamaros flamaros.xav...@gmail.com wrote: Yep, it's a known issue. I don't know why the resize event of window come so late, it seems to be a SDL issue. I began a direct win32 implementation, but their is no display for the moment, something seems to be wrong with the opengl context. I was referring to the IUP library though, not your library. As for flicker, this is usually handled by returning 1 for the WM_ERASEBKGND message. The IUP flicker I saw was in its hbox example, which had buttons in a layout (horizontal box), and as the buttons moved when you resize the window they would flicker. Maybe they should try using a backbuffer if they don't already do. But anyway, I don't know IUP internals to know what is going wrong.
Re: s/type tuple/template pack/g please
On Thursday, 22 August 2013 at 15:01:23 UTC, Meta wrote:
One question, wasn't the fact that template Test(T...) can
accept literals as well as types originally a bug? Or am I
thinking of template Test(alias T)?
Well it is necessity that comes from the fact that it denotes
variadic template argument list. If this is legal (and it is):
template Test(int N, T) { }
than variadic list must accept both too.
