Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On Sun, Mar 11, 2012 at 08:51, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I was thinking of ANTLR-style operators in which you say where the root
should be and you get to drop unnecessary nodes.
(Post on 2012/02/29 10:19AM GMT-0600.)
Get it, thanks for the ref!
There is an operator to drop unnecessary nodes (':'). Apart from that,
a Pegged grammar is a self-contained entity: it automatically cuts
nodes coming from other grammars, to simplify the tree (it keeps the
matcheds substrings, of course). I plan to code different type of
grammars, to play with the way the deal with nodes coming from outside
rules and grammar composition.
As for the root, the PEG rule is that the first rule in the grammar is
the root. But currently, I deliberately made my grammars unsealed, in
that the user can call any rule inside the grammar to begin parsing:
mixin(grammar(
A - B C
B - ...
C -
));
A.parse(some input); // standard way to do it, the parse tree will
be rooted on an 'A' node.
B.parse(some input); // also possible, the parse tree will be rooted
on a 'B' node.
I'll add what I called closed and sealed grammars. I'll also add named
grammars and such in the days to come. I can add a root note
indication (unless told otherwise, when asked to parse with grammar
G, begin with rule R).
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 08:22, Philippe Sigaud wrote: On Sun, Mar 11, 2012 at 00:34, Alex Rønne Petersenxtzgzo...@gmail.com wrote: Admittedly I have not heard of PEGs before, so I'm curious: Is this powerful enough to parse a language such as C? I think so. But you'd have to do add some semantic action to deal with typedefs and macros. Oh, I should have mentioned I only meant the actual language (ignoring the preprocessor). Why do you need semantic actions for typedefs though? Can't you defer resolution of types until after parsing? People parsed Java and Javascript with them. I personnally never used Pegged for more than JSON and custom formats, but I intend to try the D grammar. -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
Question: Are the generated parsers, AST nodes, etc classes or structs?
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
By the way, bootstrap.d seems to fail to build at the moment:
../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
../pegged/utils/bootstrap.d(1433): members expected
../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
../pegged/utils/bootstrap.d(1466): unrecognized declaration
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 16:02, Alex Rønne Petersen wrote:
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
By the way, bootstrap.d seems to fail to build at the moment:
.../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
.../pegged/utils/bootstrap.d(1433): members expected
.../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
.../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
.../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
.../pegged/utils/bootstrap.d(1466): unrecognized declaration
Also, I have sent a pull request to fix the build on 64-bit:
https://github.com/PhilippeSigaud/Pegged/pull/1
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On Sun, Mar 11, 2012 at 00:34, Alex Rønne Petersenxtzgzo...@gmail.com wrote: [Parsing C?] I think so. But you'd have to do add some semantic action to deal with typedefs and macros. Oh, I should have mentioned I only meant the actual language (ignoring the preprocessor). OK. I admit I downloaded the C spec online, but was a bit taken aback by the size of it. mot of it was the definition of the standard library, but still... Why do you need semantic actions for typedefs though? Can't you defer resolution of types until after parsing? Yes, that the way I'd do it. But some people seem to want to do it while parsing. Maybe it blocks some parsing, if the parser encounter an identifier where there should be a type?
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
Quick question, you mention the ability to opt-out of the space-insensitivity, where might one find this? Yes, undocumented. Use the '' operator. You know, I introduced space-insensitivity recently, to simplify some rules and it keeps biting me back. For example Line - (!EOL .)* EOL The catch is, the (!EOL .) sequence accepts spaces (so, line terminators) between the !EOL and the . Crap. So, I keep writing Line - (!EOL .)* EOL And I'm more and more convinced that ws a bbad move on my part. Or, at least, give the user a way to opt-out for an entire rule.
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
Also, I have sent a pull request to fix the build on 64-bit: https://github.com/PhilippeSigaud/Pegged/pull/1 Merged, thanks!
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:06, Philippe Sigaud wrote: On Sun, Mar 11, 2012 at 00:34, Alex Rønne Petersenxtzgzo...@gmail.com mailto:xtzgzo...@gmail.com wrote: [Parsing C?] I think so. But you'd have to do add some semantic action to deal with typedefs and macros. Oh, I should have mentioned I only meant the actual language (ignoring the preprocessor). OK. I admit I downloaded the C spec online, but was a bit taken aback by the size of it. mot of it was the definition of the standard library, but still... Why do you need semantic actions for typedefs though? Can't you defer resolution of types until after parsing? Yes, that the way I'd do it. But some people seem to want to do it while parsing. Maybe it blocks some parsing, if the parser encounter an identifier where there should be a type? Hm, I don't *think* C has such ambiguities but I could well be wrong. In any case, if it can handle the non-ambiguous case, that's enough for me. :) -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
By the way, bootstrap.d seems to fail to build at the moment:
../pegged/utils/bootstrap.d(1433): found ':' when expecting ')' following
template argument list
../pegged/utils/bootstrap.d(1433): members expected
../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
../pegged/utils/bootstrap.d(1466): unrecognized declaration
Hmm, it compiled for me a few hours ago. I'll see if I broke something
while pushing.
I'll also try to make the whole grammar-modification process easier. Since
users can modify Pegged own grammar, I might as well make that fluid and
easy to do.
I'll put the Pegged grammar as a string in a separate module and create a
function that does the rest: modify the string, it will recompile the
entire grammar for you.
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
Hm, I don't *think* C has such ambiguities but I could well be wrong. In any case, if it can handle the non-ambiguous case, that's enough for me. I wanted to tackle D this week, but I might as well begin with C :) Do you happen to have any handy and readable EBNF grammar for C? At least for D, I have dlang.org.
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:19, Philippe Sigaud wrote: Hm, I don't *think* C has such ambiguities but I could well be wrong. In any case, if it can handle the non-ambiguous case, that's enough for me. I wanted to tackle D this week, but I might as well begin with C :) Do you happen to have any handy and readable EBNF grammar for C? At least for D, I have dlang.org http://dlang.org. Yep, see: http://ssw.jku.at/Coco/ (C.atg) Coco/R is more or less EBNF. -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:17, Philippe Sigaud wrote:
By the way, bootstrap.d seems to fail to build at the moment:
../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
../pegged/utils/bootstrap.d(1433): members expected
../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
../pegged/utils/bootstrap.d(1466): unrecognized declaration
Hmm, it compiled for me a few hours ago. I'll see if I broke something
while pushing.
I'll also try to make the whole grammar-modification process easier.
Since users can modify Pegged own grammar, I might as well make that
fluid and easy to do.
I'll put the Pegged grammar as a string in a separate module and create
a function that does the rest: modify the string, it will recompile the
entire grammar for you.
Is bootstrap.d currently essential to actually use Pegged?
--
- Alex
Low feature GNUPlot controller for D2
I have been using a GNUPlot controller for my scientific work with D for some time now, so I just wanted to announce that such a thing exists if anybody is interested in using it or whatnot. It supports very some basic features (hence being low feature) which you can view in the example file: https://github.com/SiegeLord/DGnuplot/blob/master/example.d One unique feature that comes for free by virtue of using an external plotting program is that you don't have to plot things right away, but instead save the commands to a file and plot them at a different time (by piping them to gnuplot). I use this technique combined with sshfs to plot things remotely. Anyway, the repository for it is here: https://github.com/SiegeLord/DGnuplot It requires TangoD2 to build and gnuplot 4.4.3 to run (unless you're saving commands to a file as described above). It works on Linux, and maybe on Windows (untested). -SiegeLord
Re: Low feature GNUPlot controller for D2
On Sunday, 11 March 2012 at 21:45:02 UTC, SiegeLord wrote: I have been using a GNUPlot controller for my scientific work with D for some time now, so I just wanted to announce that such a thing exists if anybody is interested in using it or whatnot. It supports very some basic features (hence being low feature) which you can view in the example file: https://github.com/SiegeLord/DGnuplot/blob/master/example.d One unique feature that comes for free by virtue of using an external plotting program is that you don't have to plot things right away, but instead save the commands to a file and plot them at a different time (by piping them to gnuplot). I use this technique combined with sshfs to plot things remotely. Anyway, the repository for it is here: https://github.com/SiegeLord/DGnuplot It requires TangoD2 to build and gnuplot 4.4.3 to run (unless you're saving commands to a file as described above). It works on Linux, and maybe on Windows (untested). -SiegeLord Forgot to mention, in case people miss it, documentation is also available: http://siegelord.github.com/DGnuplot/doc/gnuplot.html -SiegeLord
Re: Low feature GNUPlot controller for D2
On 3/11/2012 2:45 PM, SiegeLord wrote: Anyway, the repository for it is here: https://github.com/SiegeLord/DGnuplot It requires TangoD2 to build and gnuplot 4.4.3 to run (unless you're saving commands to a file as described above). It works on Linux, and maybe on Windows (untested). Great! Are any parts of it suitable for inclusion in https://github.com/D-Programming-Deimos ?
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
Hm, since ' is used in the grammar of Pegged, how do I express it in my
grammar spec? Is there a predefined rule for it, or is \' supposed to work?
--
- Alex
Re: Low feature GNUPlot controller for D2
On Monday, 12 March 2012 at 01:02:06 UTC, Walter Bright wrote: Are any parts of it suitable for inclusion in https://github.com/D-Programming-Deimos ? Doubt it, as it literally simply opens up a gnuplot process and pipes commands into it. There is no such thing as a libgnuplot or anything. -SiegeLord
Re: Can getHash be made pure?
On 10.03.2012 21:48, H. S. Teoh wrote: On Sat, Mar 10, 2012 at 06:21:08PM +0100, Jacob Carlborg wrote: On 2012-03-10 04:21, Martin Nowak wrote: On Sat, 10 Mar 2012 03:18:59 +0100, Walter Bright Yeah, I know, it's viral. Can't do it piecemeal. Bottom-up instead of top-down? Hard to find somewhere to start? [...] Not that hard. Just search for toString in Object, and add qualifiers to it, then compile. You'll find a ton of errors caused by propagated qualifiers. Fix those, and you'll find more, ad nauseaum. After a few iterations of this, I found myself labelling almost every method in Object, TypeInfo, and a whole bunch of other places. I'll need to sit down someday to properly and thoroughly do this. Currently my git branch is uncompilable due to a couple o' nasty places, and I'm ready to throw in the towel. :-( Maybe I'll just finish up the actual AA implementation first, then come back to revisit pure/nothrow/const/@safe after the code itself is actually working. T At least @safe 'leak' could be temporarily plugged with @trusted. -- Dmitry Olshansky
Re: Breaking backwards compatiblity
so s...@so.so wrote in message news:pzghdzojddybajugu...@forum.dlang.org... On Saturday, 10 March 2012 at 19:54:13 UTC, Jonathan M Davis wrote: LOL. I'm the complete opposite. I seem to end up upgrading my computer every 2 or 3 years. I wouldn't be able to stand being on an older computer that long. I'm constantly annoyed by how slow my computer is no matter how new it is. No matter how much hardware you throw at it, somehow it gets slower and slower. New hardware can't keep up with (ever increasing) writing bad software. http://www.agner.org/optimize/blog/read.php?i=9 That is a *FANTASTIC* article. Completely agree, and it's very well-written. That's actually one of reasons I like to *not* use higher-end hardware. Every programmer in the world, no exceptions, has a natural tendancy to target the hardware they're developing on. If you're developing on high-end hardware, your software is likely to end up requiring high-end hardware even without your noticing. If you're developing on lower-end hardware, your software is going to run well on fucking *everything*. Similar thing for server software. If your developing on a low-end local machine, it's going to run that much better under heavier loads. I think it's a shame that companies hand out high-end hardware to their developers like it was candy. There's no doubt in my mind that's significantly contributed to the amount of bloatware out there.
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On Sunday, 11 March 2012 at 03:45:36 UTC, Chad J wrote: On 03/10/2012 10:29 PM, bioinfornatics wrote: Le samedi 10 mars 2012 à 21:23 -0500, Chad J a écrit : I've been looking for a good way to render font in OpenGL with D. Back in they day I was very impressed with Tomasz's article on the subject: http://h3.gd/dmedia/?n=Tutorials.TextRendering1 I was wonder if anyone has ported it. take derelict2 http://www.dsource.org/projects/derelict [stable] derelict3 in development https://github.com/aldacron/Derelict3 I already have OpenGL working with derelict2. How do these links help with rendering text in OpenGL? I have some code based on that tutorial in https://github.com/kiith-sa/ICE, but beware that it's not the most effective code and not particularly readable either. However, I abstracted it away it to pack any textures instead of just font glyphs, and it is spread over many files. The relevant files are: video/glvideodriver.d video/texturepage.d video/gltexturebackend.d video/binarytexturepacker.d video/font.d video/fontmanager.d Works with DMD 2.058, but it'd probably be nontrivial to rip it out and use separately.
Re: Breaking backwards compatiblity
On 3/10/2012 2:44 PM, Lars T. Kyllingstad wrote: But... writefln is still there. Is it incompatible with the D1 one in some way? Try writefln(3);
Re: Arbitrary abbreviations in phobos considered ridiculous
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.454.1331448329.4860.digitalmar...@puremagic.com... On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.447.1331426602.4860.digitalmar...@puremagic.com... [...] In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional. I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends. :-) I admire that :) Personally, I don't have the patience. I just bitch and moan :) Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway. So I just leave and never come back to the site. I'd prefer to do that (leave and never come back), but unfortunately, the modern regression of tying data/content to the interface often makes that impossible: For example, I can't see what materials my library has available, or manage my own library account, without using *their* crappy choice of software. It's all just fucking data! Crap, DBs are an age-old thing. Or, I'd love to be able leave GitHub and never come back. But DMD is on GitHub, so I can't create/browse/review pull requests, check what public forks are available, etc., without using GitHub's piece of shit site. I'd love to leave Google Code, Google Docs and YouTube and never come back, but people keep posting their content on those shitty sites which, naturally, prevent me from accessing said content in any other way. Etc... And most of that is all just because some idiots decided to start treating a document-transmission medium as an applications platform. I swear to god, interoperability was better in the 80's. (And jesus christ, *Google Docs*?!? How the fuck did we ever get a document platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out the free crazy-pills?) [...] In 1994, games had to come with their own sound/video drivers. In 1995, MS fixed that and there was much rejoicing. But in 2012: - Every piece of content is packaged with a pre-chosen viewer. Blame flash. And JS. It's more than that. Even without one line of JS or Flash, a purely (X)HTML/CSS web app is *still* likely tying content to interface. The only exceptions are things like forum.dlang.org which merely present data from an already-publically-accessible external source. Of course, even *then* the URLs are still tied to the (inevitably web-based) NG client (What's needed is a universal NNTP URL system that's 100% independent of NG client - Just like we already have for HTTP, and FTP, and SSH and five billion other damn things. Image that!) [...] - If you want to use GitHub/BitBucket-style DVCS features you have to use whichever interface is *provided* by whoever's hosting the repo. BitBucket can't access GitHub-hosted repos/projects. GitHub can't acces BitBucket-histed repos/projects. Neither can access local or self-hosted repos/projects. WTF is this, 1990 all over again? Yeah seriously. So much for semantic web. Smells like a pipe dream to me. Yup. Fortunately, HTTP APIs are becoming more and more common though, so at least there's that ray of hope that some of those can consolodate into some standards. Speaking of all of this though, I have to *rave* about Linode: I just switched to them from my old (and recently bought-out) shared web host a few days ago, and already I *LOVE* it. Not only is it a fantastic service all around, and they *actually* seem to know what they're doing (unlike *every* shared web host I've *ever* encountered), but *everything* about their site and control panel is *PERFECT*. Absolutely flawless, from the functionality and content, to the security, the speed, the compatibility and graceful degredation, all the way down to just simply the *style*: Flawless every step of the way. And they offer an HTTP API for the control panel. I can't remember the last time I saw a site this *professional* and well built. It's one of those exceedingly rare things that's created by grown-ups, for grown-ups. I'm genuinely stunned by it.
Re: Arbitrary abbreviations in phobos considered ridiculous
Daniel Murphy yebbl...@nospamgmail.com wrote in message news:jjhcj8$25sv$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:jjh9uh$1vto$1...@digitalmars.com... My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source? That's not really it... The problem is that vtables contain every virtual function of a class - and if you instantiate a template function with a new type, it would require a new vtable entry. Therefore you need to know how every template function in every derived class is instantiated before you can build the base class vtable. This doesn't work with D's compilation model. Right, but when I tell something like rdmd to pass all my files into DMD, then DMD *does* have all the information needed. I understand that it can't be done in *all* build setups, but it would seem to be possible in many build setups, so why should *all* projects suffer when really only *some* projects have to have that limitation? That's what I've never understood. Now, as for whether or not D actually *does* omit the vtable entry for non-override finals, I wouldn't know. Although I seem to vaguely remember doing optimizations once that seemed to imply it did. If that's so, I don't know whether its guaranteed per D spec or just implementation-defined. A UFCS approach would definitely be guaranteed not to affect the vtable, of course. D (dmd) does not create a vtable entry for final functions that don't override anything. It's in the frontend, so it should be the same for all the d compilers. I see. Thanks.
Re: Arbitrary abbreviations in phobos considered ridiculous
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.453.1331446837.4860.digitalmar...@puremagic.com... On Sat, Mar 10, 2012 at 11:31:47PM -0500, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.436.1331412193.4860.digitalmar...@puremagic.com... [...] My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source? I thought the reason was that every instance of the template will need a vtable entry, and the compiler may not be able to know beforehand which instances will actually exist? You *could* in theory have the compiler scan the entire program for all instances, I suppose, but that will prevent incremental compilation and loading of dynamic libs, OSS or not. Plus it may slow down the compiler significantly. What I'm suggesting is flipping that around: Instead of saying Virtual template functions prevent incremental compilation and dynamic libs: And that's an unreasonable limitation, we say Incremental compilation and dynamic libs prevent virtual template functions: So *if you need to use those*, you can't use virtual template functions. Keep in mind too, that even incremental compilation and dynamic libs *can* still work with virtual template functions *provided that* there's no overriding across compilation unit boundaries. I don't think that's a totally unreasonable limitation for virtual template functions to be worthwhile for _many_ people, even if it doesn't make virtual template functions practical for *everyone*. [...] Another great one, which is very similar to one I've enjoyed repeating: What are a redneck's last words? Hey y'all, watch this! [...] And another one in response: Famous last words: I *think* this will work... Yet another one, I just recently came across (not actually for real, but it would be funny): Written on someone's tombstone: I *told* you I was sick! Along similar lines (this one's a true story), my Dad's Aunt and Uncle bought their own tombstone ahead of time, and had their picture taken sitting on each side of it, both of them smoking. (The irony was, of course, deliberate. My family's a bit weird ;) )
Re: Breaking backwards compatiblity
Walter Bright newshou...@digitalmars.com wrote in message news:jjho0a$2qdu$1...@digitalmars.com... On 3/10/2012 2:44 PM, Lars T. Kyllingstad wrote: But... writefln is still there. Is it incompatible with the D1 one in some way? Try writefln(3); Having been accustomed to C's printf, I don't think it would have ever even occurred to me to try that. (FWIW/YMMV)
Idea: A library non-OOP dispatch!()()
Maybe it's just half-asleep crazy-talk, but you know what I think would be
great in Phobos (I don't *think* it's already there)? A virtual-like
dispatch function, which would help ease the rift between template code
and OOP. For example, if you have a class hierarchy, you can do
single-dispatch via method overriding. But if you have a function implemeted
outside the class that uses overloading on type, you have to dispatch
manually:
class FooBase {}
class Foo1 : FooBase {}
class Foo2 : FooBase {}
class Foo3 : FooBase {}
void bar(FooBase f)
{
if(auto _f = cast(Foo1)f)
bar(_f);
else if(auto _f = cast(Foo1)f)
bar(_f);
else if(auto _f = cast(Foo2)f)
bar(_f);
else
throw new Exception(Can't dispatch);
}
void bar(T f) if(is(T : FooBase))
{
// use 'f'
}
Thats a lot of boilerplate!
I'm finding I need to do that sort of thing a lot when using my Goldie lib.
It could be improved with a foreach over a TypeTuple, but it'd be great to
have a dispatch!()() or even a multiple dispatch version to just automate
all of that entirely. That would grant D the feature of multidispatch and
non-OOP dispatch *in library*, and really help ease the rift between OOP and
non-OOP styles of coding.
Or, the same thing but without a class hierarchy. For example, if you have
ten different ForwardRange types you want to deal with.
My half-asleep self thinks that that *should* probably be possible to
create. The real trick I think would be in figuring out the
interface/semantics for controlling what types to actually try to dispatch
on.
[OT] Re: Arbitrary abbreviations in phobos considered ridiculous
On 11/03/2012 09:15, Nick Sabalausky wrote: Written on someone's tombstone: I *told* you I was sick! Spike Milligan's epitaph reads Duirt mé leat go raibh mé breoite, Irish for I told you I was ill. A...
Re: Multiple return values...
On 11 March 2012 03:45, Robert Jacques sandf...@jhu.edu wrote: On Sat, 10 Mar 2012 19:27:05 -0600, Manu turkey...@gmail.com wrote: On 11 March 2012 00:25, Sean Cavanaugh worksonmymach...@gmail.com wrote: On 3/10/2012 4:37 AM, Manu wrote: If I pass a structure TO a function by value, I know what happens, a copy is written to the stack which the function expects to find there. This is only true if the compiler is forced to use the ABI, when inlining is impossible, or the type being passed is too complex. Structs of pods, most compilers do magical things to provided you don't actively work against the code gen (virtual methods, dllexports etc), too many separate .obj units in C++ etc. Talking about the typical case here, obviously not inlined, calling through the ABI, struct may be simple, just 2-3 values, can you show me a case where C++ is able to to anything particularly fancy? I've never seen the compiler do wildly unexpected things unless whole program optimisation is enabled, which I don't imagine D will be able to support any time real soon? ...and even then, relying on WPO for the language to generate good code in certain circumstances is a really really bad idea. This makes the task of implementing an efficient compiler for the language extremely difficult. In most cases, making concise expression of the operation you want to perform possible in the language will generate better results anyway, without depending on an aggressive optimiser. It will also make the code more explicit and readable. Manu, please go read the D ABI (http://dlang.org/abi.html). Remember, your example of returning two values using Tuple vs 'real' MRV? The D ABI states that those values will be returned via registers. Returning something larger? Then the NVRO kicks in which gives you a zero copy approach. On x86-64 these limits are different, since you have more registers to play with, but the concept is the same. In fact, returning arguments has always been more efficient than passing arguments. Please go read my prior posts. This has absolutely no bearing on what I'm talking about. In fact, it fuels my argument in some cases. That said, I've read it, and it scares the hell out of me. D states that a small struct may be returned in up to 2 registers (8 bytes/16 bytes), I suspect this is a hack introduced specifically to make ranges efficient? If it is not simply a struct of 2 register sized things, they get packed into a magic 8-16 byte struct implicitly for return, and this makes my brain explode. If I wanted to perform a bunch of shifts, or's, and and's until it's snugly packed into a 8-16 byte block before returning, I'd do that explicitly... I DON'T want to do that however, and I *really* don't want the language doing that for me. If I want to return 4 byte values, they should be returned in 4 registers, not packed together into a 32bit word and returned in one. Also, if there are mixed ints, floats, vectors, even other structs, none of it works; what if there is float data? Swapping registers now? That's one of the worst penalties there is.
Re: Multiple return values...
On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push EAX, EDX into a stack
fld stack values into st0, st1
do something with st0, st1
}
As opposed to:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
ret
}
void caller() {
call callee()
do something with st0, st1
}
Is there something I miss here?
Yes, the fact the FPU stack is deprecated :)
Don't dismiss the point, the same still stands true with XMM regs.
Re: Multiple return values...
On 11 March 2012 05:04, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 3/10/12 4:37 AM, Manu wrote: I still fundamentally see a clear divide between a Tuple, which is a deliberately structured association of multiple values, and 'multiple return values' which is an explicit non-association of multiple returned things. There is no difference. A Tuple is a product type, exactly like superposing arbitrary values together. So you're saying that whatever I think about the implementation of Tuple is wrong? It is not actually a structured type? You need to address that principle before I can begin to accept the idea of abusing a structured tuple as a substitute for this important language feature. My analogy is the function argument list. You don't think of the arguments you pass to a function as a Tuple (is it implemented internally in this way? if so, it is well hidden, and perhaps similar magic can be done...) You pass, TO a function, multiple un-associated values. This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. I don't know how 'major' they'd really work out to be. It's not a paradigm buster. There are some details, but I don't even think it would need to be a breaking change to the language (maybe some very subtle tweaks). Can you quantify 'little' benefit? I started this thread because I have found myself wishing for this feature every other day. It would be of huge value, and many others seem to agree. D has it all, there are so many features in D which make it feel like a modern language, but this is a missed(/rejected?) opportunity. It's a natural thing to want to ask a computer to do, but we're mentally trained into the returns-a-single-thing model from C and whatever and apparently it was never considered at the initial design stage, but apart from the expressive side, more importantly in D's case as a native language, it is an opportunity to implement an important low level feature that no other language offers me; an efficient multi-return syntax+ABI. In the tight loops of every program I've ever written, I can't recall a time when I haven't had a function that needs to return multiple things, and C/C++ has always forced me into unnecessary memory access to express this (ref parameters). For the first time in language/compiler history, D would finally be able to eliminate the last of the redundant memory accesses in my hottest code in a portable way, at a language/expression level. Are you saying it's impossible, that you don't think it should be done, or it's already solved? Is it that you don't see the value in it? Is that what I need to convince you of? You haven't argued with any of the other points I raised, which leads me to suspect you either see my points, or you think the entire premise of my rant is wrong... if so, can you show how, and present a solution that's workable within existing constructs that meets my criteria without adding other implicit/logical baggage? Nobody has acknowledged or disputed the majority of my points :/ D is a native language, that's it's most attractive feature, and while I appreciate all the high-level correct-ness D offers, it still needs to get the low level right and ideally improve on existing offerings in meaningful ways to motivate new users to switch. This is a big un-checked checkbox for me and my colleagues, and I'd wager any low level realtime programmer out there who has had to struggle with the codegen in their inner loops.. doubly so if they ever work on non-x86 systems since the penalties are so much greater.
Re: Breaking backwards compatiblity
I find the point on developing on a slower computer very interesting, and here's my story. I've been using an EeePC for everything for the past 2.5 years and until now, I could cope. I'm getting a new laptop this week because I direly need it at the faculty (some robotics/image processing/computer vision — no way to run these on an EeePC realtime). However, I could notice an interesting trend between my colleagues' programs and mine. For example, solving the 15-game with heuristics took ~0.01 secs on the Eee, and comparing to others' programs theirs took several seconds and found worse solutions (not all of them of course, but most). When doing some local search optimisation, the difference was seconds-to-HOURS. I guess someone was really sloppy, but still. This has also been one of the reasons I became interested in languages like C and D. Believe it or not, in our university, you don't ever get to see C officially if you don't learn it yourself. I consider this pathetic. The official and only taught language is Java. Which I grant them is at least cross-platform, but I believe that every university-educated programmer must know C. I am convinced that my university produces bad programmers and as such don't find it surprising that new written programs are terribly slow, if they even work at all. Matej
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-10 20:41, Nick Sabalausky wrote: You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. But they're redirecting to http://m.drdobbs.com/, which seems to be adapted for mobile devices. When I used one of my web developer plugins to disable meta redirects, the screwy behavior stopped. And like you, I have JS off by default (WTF do you need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts over at Dr Dobbs did. Yeah, probably. -- /Jacob Carlborg
Re: Multiple return values...
On 11 March 2012 05:04, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. I do appreciate this point though... Is it currently possible to enumerate a functions argument list? How do you express that? The problems seem very similar to me.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-10 21:27, H. S. Teoh wrote: On Sat, Mar 10, 2012 at 02:41:53PM -0500, Nick Sabalausky wrote: [...] You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. When I used one of my web developer plugins to disable meta redirects, the screwy behavior stopped. And like you, I have JS off by default (WTF do you need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts over at Dr Dobbs did. [...] I've always believed that Javascript is the hellspawn of evil incarnate. I usually agree, but there are useful and cool things you can do with JavaScript. Two of the tools I'm using when I'm doing web development uses JavaScript: * LiveReload - A browser plugin that will automatically reload the a web page when a file has changed in a specified folder. http://livereload.com/ * TextMate Rails stack trace - A greasemonkey script that will make your stack trace lines open in TextMate https://github.com/ryankshaw/rails-stacktrace-textmate-linker-greasemonkey-script -- /Jacob Carlborg
Re: Multiple return values...
On 03/11/2012 01:30 PM, Manu wrote: On 11 March 2012 05:04, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org wrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. I do appreciate this point though... It is not a valid concern. typeof(fun(args)) would just be a tuple of types. Is it currently possible to enumerate a functions argument list? Yes it is. How do you express that? The problems seem very similar to me. Language built-in tuples, of course. See std.traits.ParameterTypeTuple. It is extremely obvious how multiple return values should work.
Re: Multiple return values...
On 03/11/2012 12:50 PM, Manu wrote: Nobody has acknowledged or disputed the majority of my points :/ I agree with the majority of your points.
Re: Multiple return values...
On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu wrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. TypeTuple!(ReturnType1, ReturnType2)? David
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On 03/11/2012 09:09 AM, Jacob Carlborg wrote: On 2012-03-11 03:23, Chad J wrote: I've been looking for a good way to render font in OpenGL with D. Back in they day I was very impressed with Tomasz's article on the subject: http://h3.gd/dmedia/?n=Tutorials.TextRendering1 I was wonder if anyone has ported it. Just use FreeType? FreeType is quite cool, but it will only render glyphs onto small bitmaps. Getting those glyphs onto the screen becomes more complicated after that: you can't just blit them like in SDL or somesuch. Since textures don't come in supersmall size, it is effective to pack the glyphs into a larger texture like the article suggests. Then you have to texture-map correctly to only render the glyphs you want. Somewhere in there is a bunch of other font-setting stuff like kerning, sub-pixel anti-aliasing, line offsets, etc. FreeType doesn't do that stuff for anyone, it just provides the tools necessary to make it possible. It's fairly complicated; I'd rather just write Font f = new Font(Courier New); f.draw(100, 100, Hello world!);.
Re: Multiple return values...
On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch wrote: On 03/11/2012 12:50 PM, Manu wrote: Nobody has acknowledged or disputed the majority of my points :/ I agree with the majority of your points. Cool, well that's encouraging :) I can't really argue the implementation details, all I can do is assert criteria/requirements as I see them. So what was the perceived issue with the pull request you mentioned in an earlier post? I presume it only implemented the syntax, and not the ABI bits? On 11 March 2012 15:08, David Nadlinger s...@klickverbot.at wrote: On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu wrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. TypeTuple!(ReturnType1, ReturnType2)? Right, well I'm glad I'm not the only one :) I figured this must have some important implication that I totally missed...
Re: Multiple return values...
On 03/11/2012 02:23 PM, Manu wrote: On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote: On 03/11/2012 12:50 PM, Manu wrote: Nobody has acknowledged or disputed the majority of my points :/ I agree with the majority of your points. Cool, well that's encouraging :) I can't really argue the implementation details, all I can do is assert criteria/requirements as I see them. So what was the perceived issue with the pull request you mentioned in an earlier post? This is the pull request. https://github.com/D-Programming-Language/dmd/pull/341 I think the issue with it is that there are no obvious issues with it. I presume it only implemented the syntax, and not the ABI bits? Exactly. It implements the assignment from built-in/library tuples to multiple newly declared variables, but it does not implement multiple return values.
Re: Multiple return values...
On 03/11/12 02:27, Manu wrote: I've never seen the compiler do wildly unexpected things unless whole program optimisation is enabled The compiler can only ignore the ABI when it knows it sees the whole picture, ie whole program, or whole unit in case of private/local functions. which I don't imagine D will be able to support any time real soon? Umm, GDC supports WPO, both as LTO and std WPO, though i don't remember if i ever tried the latter. In fact, until GDC learns cross-module inlining, using these modes is the only way to make the compiler generate sane code, w/o reverting to turning all D functions into templates or compiling all sources together (at which point you could just as well turn on WPO...). Also, unit-at-a-time, which is on by default, can help. It (gdc) still has a few LTO bugs which sometimes cause trouble, but often can be worked around. And you may need to use the *.d runtime files (instead of *.di) etc. ...and even then, relying on WPO for the language to generate good code in certain circumstances is a really really bad idea. This makes the task of implementing an efficient compiler for the language extremely difficult. There is a reason why i never even considered trying out a non-gcc-based D compiler... [1] For a language like D, WPO in some form is almost required; w/o it you'd need to always think about how the compiler will treat your code; which, while possible, would often result in more unnatural and tricky solutions. (In C/C++ there's a *.h/*.c split, which helps mitigate the problem) artur [1] LLVM is possibly an option too, but i haven't yet found the time to investigate.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Sun, Mar 11, 2012 at 01:45:19PM +0100, Jacob Carlborg wrote: On 2012-03-10 21:27, H. S. Teoh wrote: [...] I've always believed that Javascript is the hellspawn of evil incarnate. I usually agree, but there are useful and cool things you can do with JavaScript. Two of the tools I'm using when I'm doing web development uses JavaScript: [...] Oh, I know how useful it is. I've written some cool stuff with it too. That's what makes it so evil. :-) It's so cool and so easy to write, that everybody and his neighbour's dog writes it and sticks it everywhere it doesn't belong. T -- Change is inevitable, except from a vending machine.
Re: Multiple return values...
On 11 March 2012 15:35, Timon Gehr timon.g...@gmx.ch wrote: On 03/11/2012 02:23 PM, Manu wrote: On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote: On 03/11/2012 12:50 PM, Manu wrote: Nobody has acknowledged or disputed the majority of my points :/ I agree with the majority of your points. Cool, well that's encouraging :) I can't really argue the implementation details, all I can do is assert criteria/requirements as I see them. So what was the perceived issue with the pull request you mentioned in an earlier post? This is the pull request. https://github.com/D-**Programming-Language/dmd/pull/**341https://github.com/D-Programming-Language/dmd/pull/341 I think the issue with it is that there are no obvious issues with it. I presume it only implemented the syntax, and not the ABI bits? Exactly. It implements the assignment from built-in/library tuples to multiple newly declared variables, but it does not implement multiple return values. How does the syntax work precisely? Is it possible to do each of those things I mentioned earlier; assign to existing locals, ignore individual return values, etc? How would the language distinguish from this implementation of implicitly building/returning/unpacking a tuple, and from explicit intent to do so structurally? Does the syntax give the code generation enough information to distinguish multiple-return from struct byval?
Re: Multiple return values...
On 11 March 2012 16:01, Artur Skawina art.08...@gmail.com wrote: which I don't imagine D will be able to support any time real soon? In fact, until GDC learns cross-module inlining, using these modes is the only way to make the compiler generate sane code Yeah I'm very concerned by this currently. But it seems to we a well known issue with a plan/intent to fix it right? (Side note: I'd still really like an explicit @forceinline attribute) ...and even then, relying on WPO for the language to generate good code in certain circumstances is a really really bad idea. This makes the task of implementing an efficient compiler for the language extremely difficult. There is a reason why i never even considered trying out a non-gcc-based D compiler... [1] For a language like D, WPO in some form is almost required; w/o it you'd need to always think about how the compiler will treat your code; which, while possible, would often result in more unnatural and tricky solutions. (In C/C++ there's a *.h/*.c split, which helps mitigate the problem) think about how the compiler will treat your code ... 'unnatural' and tricky solutions ... Outside of cross module inlining, what are some other common problem cases? C/C++ .h files only really simplify 2 things, inlining, and templates, but I can't see how the situation is any different in D? My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining? C/C++ can't inline something from a foreign object either without a definition in a header...
Re: Breaking backwards compatiblity
On Sun, Mar 11, 2012 at 04:12:12AM -0400, Nick Sabalausky wrote: so s...@so.so wrote in message news:pzghdzojddybajugu...@forum.dlang.org... [...] No matter how much hardware you throw at it, somehow it gets slower and slower. New hardware can't keep up with (ever increasing) writing bad software. http://www.agner.org/optimize/blog/read.php?i=9 That is a *FANTASTIC* article. Completely agree, and it's very well-written. I really liked the point about GUIs. Many resources are used for graphical elements that only have aesthetic value AND tends to distract the user from actual work. IOW, you're wasting CPU, RAM, and disk time (which comes from spending lots of hard-earned cash for that expensive hardware upgrade) just for some silly eye-candy that has no value whatsoever except to distract from the task at hand, that is, to accomplish what you set out to do in the first place. That's why I use ratpoison as my WM. Who needs title bars with fancy colored icons, gradient shading, and *shadows*?! I mean, c'mon. You're trying to get work done, not admire how clever the UI designers were and how cool a color gradient is. If I wanted to admire eye-candy, I'd be playing computer games, not working. (That said, though, I did at one point have a Compiz installation for the sole purpose of showing off Linux to clueless people. :-P) Then the points about background processes, auto-updates, and boot-up times. These are things about Windows that consistently drive me up the wall. Background processes are all nice and good as long as they are (1) necessary, and (2) don't do stupid things like hog your CPU or thrash your disk every 12 seconds. But the way Windows works, every time you install something, it insists on starting up at boot-time, incessantly checking for auto-updates every 12 seconds, downloading crap from online without your knowledge, and THEN pop up those intrusive, distracting, and utterly annoying Plz Update M! dialogs. Ugh. Everytime I see one of those dialogs I have this urge to delete the app and expunge all traces of it from the system with extreme prejudice. At least on Linux you can turn off this crap and/or otherwise prevent it from doing stupid things. But on Windows you have no choice. Attempting to disable stuff usually breaks said apps, or affects system usability in some way. That's actually one of reasons I like to *not* use higher-end hardware. Every programmer in the world, no exceptions, has a natural tendancy to target the hardware they're developing on. If you're developing on high-end hardware, your software is likely to end up requiring high-end hardware even without your noticing. If you're developing on lower-end hardware, your software is going to run well on fucking *everything*. True. I suppose it's a good thing at my day job that we don't get free upgrades. Whatever was current when we first got the job is whatever we have today. It does have a certain value to it, in that we notice how idiotically long it takes to compile the software we're working on, and how much CPU and RAM a particular ludicrously-long linker command-line eats up at a certain point in the build (which, not too surprisingly, is the linking of the GUI component). It does provide a disincentive against doing more stupid things to make this worse. Now if only everyone (particular the people working on the GUI component :-P) had 5-year old development machines, perhaps that ludicrously-long linker command would never have existed in the first place. Well, I can dream. :-) T -- Ignorance is bliss... but only until you suffer the consequences!
Re: Breaking backwards compatiblity
Le 09/03/2012 23:32, Walter Bright a écrit : This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. I think Linus is mostly right. But I don't think this is a reason not put the bar very high. Especially with the current state of D. This is more about providing a nice, and long, transition process. The way @property evolve is a good example of what we should do. An example of management the change (even breaking change) is PHP. PHP has so much improved if you consider what have changed between v4 and v5, and then v5 and v5.3, that it is a factual proof that breaking change can be done to great benefit.
Re: Breaking backwards compatiblity
On Sun, Mar 11, 2012 at 12:20:43PM +0100, Matej Nanut wrote: [...] This has also been one of the reasons I became interested in languages like C and D. Believe it or not, in our university, you don't ever get to see C officially if you don't learn it yourself. I consider this pathetic. The official and only taught language is Java. Ugh. Which I grant them is at least cross-platform, but I believe that every university-educated programmer must know C. +1. Java is a not-bad language. In fact, as a language it has quite a few good points. However, one thing I could never stand about Java culture is what I call the bandwagon-jumping attitude. It's this obsessive belief that Java is the best thing invented since coffee (har har) and that it's the panacea to solve all programming problems, cure world hunger, and solve world peace, and that whoever doesn't use Java must therefore be some inferior antiquated dinosaur from the last ice age. Every new trend that comes out must be blindly adopted without any question, because obviously new == good, and therefore whatever diseased fancy some self-appointed genius dreamed up one night must be adopted without regard for whether it actually adds value. C is therefore a fossilized relic from bygone times and nobody uses it anymore, and we've never heard of what on earth an assembler is, neither do we care, since the JVM is obviously superior anyway. As the saying goes, if you don't know history, you'll end up repeating it. I am convinced that my university produces bad programmers and as such don't find it surprising that new written programs are terribly slow, if they even work at all. [...] Obligatory quote: If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell :-) T -- Question authority. Don't ask why, just do it.
Re: Breaking backwards compatiblity
Le 10/03/2012 00:24, Jonathan M Davis a écrit : On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote: On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote: On 09-03-2012 23:32, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages... [...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality. Note that he didn't say that we should _never_ make breaking changes but rather that we need to have a very high bar for making such changes. In particular, it's stuff like renaming functions without changing functionality that he's against. Just about that, having a consistent naming convention is an issue of first importance. In the given topic, I did argue for some convention, but, let's look at the larger picture and how it relate to this topic. Whatever the naming convention is, it mandatory to have one. So at some point, renaming stuff are going to happen, or phobos will become completely opaque when growing. Renaming just one function isn't important enough to justify to break compatibility. Having a consistent naming convention is.
Re: Breaking backwards compatiblity
Le 10/03/2012 20:37, Walter Bright a écrit : On 3/10/2012 10:58 AM, H. S. Teoh wrote: Win9x's success is mainly attributable to Microsoft's superior marketing strategies. It can hardly be called a success technology-wise. Oh, I disagree with that. Certainly, Win9x was a compromise, but it nailed being a transition operating system from 16 to 32 bit, and it nailed making Windows an attractive target for game developers. Windows 3.1 had patches provided by microsoft to handle 32bits. But this is quite offtopic. Win9x was good back then. Now it is crap. When doing something new (like D) you don't only need to provide something as good as what existed before. Actually, providing better isn't enough either. You need to provide enough to compensate the cost of the change, and additionally communication/marketing must convince user to switch.
Re: Breaking backwards compatiblity
Le 10/03/2012 20:38, Walter Bright a écrit : On 3/10/2012 11:31 AM, Nick Sabalausky wrote: I still like the name better. Do we really need an alphabet soup appended to write just to spit out one string? It's not about whether it was a better name. It was about having to constantly edit code. I do think better name isn't the problem. The problem is about consistency, and will persist as long as we don't agree on a guideline on that in phobos. Changing a name just for changing it doesn't worth the cost, unless the original name is horribly misleading - rare case. But getting the naming convention consistent is of much greater importance, and justify breaking code.
Re: Breaking backwards compatiblity
Le 10/03/2012 06:47, Walter Bright a écrit : On 3/9/2012 8:40 PM, Adam D. Ruppe wrote: On Windows though, even if you relied on bugs twenty years ago, they bend over backward to keep your app functioning. It is really an amazing feat they've accomplished, both from technical and business perspectives, in doing this while still moving forward. I agree that Windows does a better job of it than Linux. MS really does pour enormous effort into backwards compatibility. You could legitimately call it heroic - and it has paid off for MS. Micsrosoft being incompatible with mostly everything, they sure can't afford to not be compatible with themselves. This is of strategic importance for microsoft. I don't think this is as important for us as it is for microsoft (even if it is).
Re: DDoc and logically structured HTML
On 11/03/2012 02:26, Kevin Cox wrote: snip I hate to say it but I think the ddoc system was way overthought. It would be better to use a markup language such as Creole that is meant to look nice and you can convert that into anything you want. You could leave the default html but provide an api for accessing a parsed tree. I think this is more or less how Java doclets work. It works because Java's bytecode and dynamic class loading provide a means to call an arbitrary method of an arbitrary compiled class that need not be part of the same app. But how are we going to do this with D? It seems we would need to either: (a) compile the doclet on the fly and pass the parse tree into it (b) have in said API a parse tree constructor that translates it from a textual representation received through stdin. Stewart.
override and @trusted
As suggested, override will propagate function's qualifier of the superclass. What about the @trusted attribute ? It seems to be quite dangerous attribute to propagate. And if we don't, we could ends up with strange stuffs dues to @safe inference in the subclasse. I suggest override to propagate @safe in the case of @trusted function overload, except if overloaded function is explicitly tagged as @trusted . @trusted isn't something that we want to propagate automatically.
Re: Multiple return values...
On 03/11/12 15:59, Manu wrote: On 11 March 2012 16:01, Artur Skawina art.08...@gmail.com mailto:art.08...@gmail.com wrote: which I don't imagine D will be able to support any time real soon? In fact, until GDC learns cross-module inlining, using these modes is the only way to make the compiler generate sane code Yeah I'm very concerned by this currently. But it seems to we a well known issue with a plan/intent to fix it right? (Side note: I'd still really like an explicit @forceinline attribute) Just '@forceinline' is IMHO too specific and not enough -- because you also want @noinline, @noclone, @flatten, @cold and more of theses kind of /generic/ attributes, not to mention the target-specific ones. So a way to specify function (and data) attributes is needed, together with a way to bundle them. Maybe something like alias @attr(noinline, noclone, cold, nothrow) @errorpath;. ...and even then, relying on WPO for the language to generate good code in certain circumstances is a really really bad idea. This makes the task of implementing an efficient compiler for the language extremely difficult. There is a reason why i never even considered trying out a non-gcc-based D compiler... [1] For a language like D, WPO in some form is almost required; w/o it you'd need to always think about how the compiler will treat your code; which, while possible, would often result in more unnatural and tricky solutions. (In C/C++ there's a *.h/*.c split, which helps mitigate the problem) think about how the compiler will treat your code ... 'unnatural' and tricky solutions ... Outside of cross module inlining, what are some other common problem cases? C/C++ .h files only really simplify 2 things, inlining, and templates, but I can't see how the situation is any different in D? Traditionally, the pre-WPO way, the coder would put the things expected to become part of the caller in header files. In D, header files are unnecessary, other than for the binary-lib-interface case. And currently even if you duplicate part of the code in a *.di file, it doesn't really change anything, other than preventing some optimizations like inlining or cloning (for the omitted parts). If you have a complex data type which exports eg a range, you may want just '.front' etc to be inlined, and creating a *.di file just for this purpose shouldn't be required. Template definitions need to be visible to the caller/user too - having to place them all in a *.di file would not be a good solution - in many cases most of the code would move there... Other than that, there is devirtualization - D does not have 'virtual'; the compiler can still do it and even inline the virtual methods, but it needs to know that nothing overrides the functions - impossible w/o WPO for public non-final classes. [1] My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining? C/C++ can't inline something from a foreign object either without a definition in a header... It's the same for D, I just don't think *.di files should be necessary for _internal_ cross-module interfaces, or when the full source is available anyway. Currently, cross-module inlining is a problem for GDC, but even when that's fixed, WPO will help things like devirtualization or changing calling conventions (gcc does it already, but i don't know if it clones non-local functions just for this, when not in WPO mode). artur [1] BTW, this means that a @virtual attribute might be needed - to prevent devirtualizing methods for classes used by plugins or other dynamically loaded code.
EBNF grammar for D?
Hello, I'm looking for a D grammar in (E)BNF form. Did any of you write something like that or do you think I can use the grammar parts on dlang.org? I remember different threads on this subject and saw the docs being updated regularly on github, but my google-fu is weak today.
Re: Multiple return values...
On Sun, 11 Mar 2012 05:57:05 -0500, Manu turkey...@gmail.com wrote:
On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push EAX, EDX into a stack
fld stack values into st0, st1
do something with st0, st1
}
As opposed to:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
ret
}
void caller() {
call callee()
do something with st0, st1
}
Is there something I miss here?
Yes, the fact the FPU stack is deprecated :)
Don't dismiss the point, the same still stands true with XMM regs.
And Walter has talked about using the XMM registers to return floating point
data for exactly this reason. But those optimization apply to all structs and
all data types. There's nothing special about MRV. It has to return a set of
data in a structured manner; this is identical to the case of returning a
struct.
Re: Compile Time D Expression Parser?
dcoder: I need to parse simple D expressions at compile time. I was wondering if somebody on the list has some example code that could be of help to me. I am working on an opensource constraint solver and expressions that I need to parse can be reasonably complex such as x + y*n 32 x 4. I want to code a string mixin that parses such expressions and writes out code that creates a parse tree for the given expression. OK, doing a bit of thread necromancy here (3 weeks, still acceptable here?) Puneet, I might have something for you. IIUC, you want to parse expressions that are - an association of boolean expressions (, ||, !) - each boolean expression is an equation (=, =, , etc) - each equation lhs or rhs is an arithmetic expression (+, -, *, /) - atoms in an arithmetic expression can be numbers or variables Is that it? You do realize that any parse tree will for these constructs will be quite deep, right? I mean, 10-levels deep or somesuch. Philippe
Re: DDoc and logically structured HTML
Am 11.03.2012 03:26, schrieb Kevin Cox: On Mar 10, 2012 8:10 PM, Stewart Gordon smjg_1...@yahoo.com mailto:smjg_1...@yahoo.com wrote I don't know how far we can go short of a doclet system like JavaDoc has. Nor even how exactly a doclet system would work under a language that compiles to native code Stewart. I hate to say it but I think the ddoc system was way overthought. It would be better to use a markup language such as Creole that is meant to look nice and you can convert that into anything you want. You could leave the default html but provide an api for accessing a parsed tree. This is a bit what Go does with the go packages (ast, doc, etc) http://tip.golang.org/pkg/go/ -- Paulo
Re: Multiple return values...
On 11 March 2012 18:50, Robert Jacques sandf...@jhu.edu wrote:
On Sun, 11 Mar 2012 05:57:05 -0500, Manu turkey...@gmail.com wrote:
On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com
wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push EAX, EDX into a stack
fld stack values into st0, st1
do something with st0, st1
}
As opposed to:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
ret
}
void caller() {
call callee()
do something with st0, st1
}
Is there something I miss here?
Yes, the fact the FPU stack is deprecated :)
Don't dismiss the point, the same still stands true with XMM regs.
And Walter has talked about using the XMM registers to return floating
point data for exactly this reason. But those optimization apply to all
structs and all data types. There's nothing special about MRV. It has to
return a set of data in a structured manner; this is identical to the case
of returning a struct.
Well you can't build these sorts of tightly packed structs in XMM
registers... and even for the GPR's, it's very inefficient to do so. I
haven't done tests, but I suspect this feature is probably a
de-optimisation in all cases other than an int-pair struct (ranges,
delegates? I suspect that's why this was invented). Structure
packing/unpacking code will likely be slower than a store/load.
We just need proper multiple return values, then this can go away. And the
earlier any ABI breaking changes are implemented, the better, while there
are still few(/none?) closed source, binary distributed D libraries.
Re: Multiple return values...
On 11 March 2012 18:45, Artur Skawina art.08...@gmail.com wrote: Other than that, there is devirtualization - D does not have 'virtual'; the compiler can still do it and even inline the virtual methods, but it needs to know that nothing overrides the functions - impossible w/o WPO for public non-final classes. [1] Oh don't get me started! (...oops, too late!) This is my single greatest complaint about D, and if I were to adopt D professionally, I would almost certainly fork the language and fix this. virtual-by-default seems like the single biggest and most harmful *mistake*in the whole language. Defaulting a feature that introduces very costly damage that ONLY a WPO pass can possibly un-do can only be described as insanity. Choosing to do this intentionally... does DMD have a powerful WPO? _ I genuinely fear for this decision. Junior programmers will write really slow code unknowingly, and it's too easy for anyone to simply forget to declare 'final'. Seniors will spend god only knows how much time (late nights?) trawling through the codebase verifying non-virtuals, and marking them final, time you probably can't afford when crunching to ship a product. Add to that the fact that *validating* a method is not overridden anywhere is NOT a trivial task. Being able to do this with confidence will be tedious and waste unimaginable amounts of time and frustration... and why? What was the harm in explicit virtual? I expect explicit 'final' will surely overwhelm virtuals in number too when considering keyword clutter (trivial accessors, properties, etc make up the majority of methods) :/ If I were evaluating D to use commercially, this would be the biggest red flag to consider. The time/efficiency costs could potentially be very high. My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining? C/C++ can't inline something from a foreign object either without a definition in a header... It's the same for D, I just don't think *.di files should be necessary for _internal_ cross-module interfaces, or when the full source is available anyway. Currently, cross-module inlining is a problem for GDC, but even when that's fixed, WPO will help things like devirtualization or changing calling conventions (gcc does it already, but i don't know if it clones non-local functions just for this, when not in WPO mode). So assuming that most libraries will be closed source, what's the implication here for inlines and tempaltes long term? It sounds no different than .h files. Is there a plan to be able to store that metadata inside lib/object files somehow? (I assume not, if there was, why need .di files at all)
Re: Compile Time D Expression Parser?
Hello Philippe OK, doing a bit of thread necromancy here (3 weeks, still acceptable here?) You are more than welcome. I am still working on the stuff. Puneet, I might have something for you. IIUC, you want to parse expressions that are - an association of boolean expressions (, ||, !) - each boolean expression is an equation (=, =, , etc) - each equation lhs or rhs is an arithmetic expression (+, -, *, /) - atoms in an arithmetic expression can be numbers or variables Is that it? That would be sufficient for a start. But later I would also like to parse simple D style if-else conditionals and foreach loops. You do realize that any parse tree will for these constructs will be quite deep, right? I mean, 10-levels deep or somesuch. 10 levels would be good enough. Regards - Puneet
Romans, rubies and the D
Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Andrei
Re: Compile Time D Expression Parser?
On 11-03-2012 18:54, d coder wrote: Hello Philippe OK, doing a bit of thread necromancy here (3 weeks, still acceptable here?) You are more than welcome. I am still working on the stuff. Puneet, I might have something for you. IIUC, you want to parse expressions that are - an association of boolean expressions (, ||, !) - each boolean expression is an equation (=, =, , etc) - each equation lhs or rhs is an arithmetic expression (+, -, *, /) - atoms in an arithmetic expression can be numbers or variables Is that it? That would be sufficient for a start. But later I would also like to parse simple D style if-else conditionals and foreach loops. You do realize that any parse tree will for these constructs will be quite deep, right? I mean, 10-levels deep or somesuch. 10 levels would be good enough. Regards - Puneet Pegged should have no problem parsing all of D, at least theoretically (I don't know of any severe ambiguities in D). So IOW, it can probably do what you need it to do. -- - Alex
Re: Compile Time D Expression Parser?
Pegged should have no problem parsing all of D, at least theoretically (I don't know of any severe ambiguities in D). So IOW, it can probably do what you need it to do. Oh. I realized that I had missed Pegged announcement by Philippe. I will have a look at it. Regards - Puneet
Re: Romans, rubies and the D
On 03/11/2012 06:53 PM, Andrei Alexandrescu wrote: Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Andrei Roman.IX crashes the compiler.
Re: Feq questions about the D language
D is not ready for anything. At the very best, It's in alpha. Don't let others make you think otherwise. DMD is one of the buggiest compilers out there. If you are a non-DMD/Phobos developer and think that D is ready for any kind of work then you must be high on dope. If you want to learn a new programming language and experience D, then go for it. The language itself is very enjoyable, specially if you are coming from C/C++/Java. However, anything more than a 1K LOC is going to get you in trouble, specially if you decide to use one of the _nice_ features of the language. Yes, things are improving rapidly, but I would say it's going take at least another year before DMD is stable.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/11/2012 05:47 AM, Nick Sabalausky wrote: H. S. Teohhst...@quickfur.ath.cx wrote in message news:mailman.454.1331448329.4860.digitalmar...@puremagic.com... On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote: H. S. Teohhst...@quickfur.ath.cx wrote in message news:mailman.447.1331426602.4860.digitalmar...@puremagic.com... [...] In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional. I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.:-) I admire that :) Personally, I don't have the patience. I just bitch and moan :) Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway. So I just leave and never come back to the site. I'd prefer to do that (leave and never come back), but unfortunately, the modern regression of tying data/content to the interface often makes that impossible: For example, I can't see what materials my library has available, or manage my own library account, without using *their* crappy choice of software. It's all just fucking data! Crap, DBs are an age-old thing. Or, I'd love to be able leave GitHub and never come back. But DMD is on GitHub, so I can't create/browse/review pull requests, check what public forks are available, etc., without using GitHub's piece of shit site. I'd love to leave Google Code, Google Docs and YouTube and never come back, but people keep posting their content on those shitty sites which, naturally, prevent me from accessing said content in any other way. Etc... And most of that is all just because some idiots decided to start treating a document-transmission medium as an applications platform. I swear to god, interoperability was better in the 80's. (And jesus christ, *Google Docs*?!? How the fuck did we ever get a document platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out the free crazy-pills?) Nick, how would you implement (protocols, architecture, whatever) an online document editor?
Re: Romans, rubies and the D
On Sunday, 11 March 2012 at 18:37:34 UTC, Timon Gehr wrote: On 03/11/2012 06:53 PM, Andrei Alexandrescu wrote: Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Andrei Roman.IX crashes the compiler. http://d.puremagic.com/issues/show_bug.cgi?id=7638
Re: Multiple return values...
On 3/11/12 7:52 AM, Timon Gehr wrote: It is extremely obvious how multiple return values should work. (int, int) fun(); writeln(fun()); auto a = fun(); writeln(a); What should happen? Andrei
Re: Multiple return values...
On 3/11/12 8:08 AM, David Nadlinger wrote: On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu wrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. TypeTuple!(ReturnType1, ReturnType2)? So how is the proposed feature any different from Tuple? Andrei
Re: Multiple return values...
On 3/11/12 6:50 AM, Manu wrote:
On 11 March 2012 05:04, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
There is no difference. A Tuple is a product type, exactly like
superposing arbitrary values together.
So you're saying that whatever I think about the implementation of Tuple
is wrong? It is not actually a structured type?
I don't know what you mean by structured type. What I mean by product
type is this: http://en.wikipedia.org/wiki/Product_type
This analogy is tenuous for D because functions are defined to
return one type, e.g. typeof(fun(args)) is defined. Once we get into
disallowing that for certain functions, we're looking at major
language changes for little benefit.
I don't know how 'major' they'd really work out to be. It's not a
paradigm buster. There are some details, but I don't even think it would
need to be a breaking change to the language (maybe some very subtle
tweaks).
I am convinced you are underestimating. The notion that a function
returns one typed value is strongly embedded in the language and the
standard library.
Can you quantify 'little' benefit? I started this thread because I have
found myself wishing for this feature every other day. It would be of
huge value, and many others seem to agree.
I think you and others are concerned with different aspects
(incrementally pleasant syntax vs. efficiency).
D has it all, there are so many features in D which make it feel like a
modern language, but this is a missed(/rejected?) opportunity. It's a
natural thing to want to ask a computer to do, but we're mentally
trained into the returns-a-single-thing model from C and whatever and
apparently it was never considered at the initial design stage, but
apart from the expressive side, more importantly in D's case as a native
language, it is an opportunity to implement an important low level
feature that no other language offers me; an efficient multi-return
syntax+ABI.
D can return multiple values from a function by putting them in a tuple.
This approach has many advantages, mostly related to avoiding awkward
ambiguities (e.g. forwarding the result of a multi-return to a variadic
or overloaded function). Regarding syntax, I am not convinced by
arguments predicated on removing Tuple! from Tuple!(int, int). It's
not progress, and pouring more magic in tuples that is not available
anywhere else does not strike me as a good path to go.
Regarding low-level efficiency, the main issue is that structs and
function argument lists have distinct layouts. Consider:
import std.stdio, std.typecons;
int a(int b, int c) {
return b + c;
}
auto foo() {
return tuple(1, 1);
}
void main() {
writeln(a(foo().expand));
}
An adjustment may be needed from the output of a() to the arguments of
foo(). (Probably not in this case.) I understand that someone very
concerned with low-level performance would scrutinize such code
carefully. But I also believe that the same person is willing to forgo a
whole category of language and library features that don't fulfill a
demanding performance profile.
In the tight loops of every program I've ever written, I can't recall a
time when I haven't had a function that needs to return multiple things,
and C/C++ has always forced me into unnecessary memory access to express
this (ref parameters). For the first time in language/compiler history,
D would finally be able to eliminate the last of the redundant memory
accesses in my hottest code in a portable way, at a language/expression
level.
Are you saying it's impossible, that you don't think it should be done,
or it's already solved?
I understand your pledge, and all I'm saying is that it is very
difficult to implement (Walter and I discussed the matter many times
over the years) and the feature will benefit only very, very few.
Is it that you don't see the value in it? Is that what I need to
convince you of?
You haven't argued with any of the other points I raised, which leads me
to suspect you either see my points, or you think the entire premise of
my rant is wrong... if so, can you show how, and present a solution
that's workable within existing constructs that meets my criteria
without adding other implicit/logical baggage? Nobody has acknowledged
or disputed the majority of my points :/
Your points are understood, but please also understand what exceptional
circumstances you are invoking. You mention how transferring function
results costs extra operations. If that cost is significant, that means
the cost of the function proper is extremely low. So you want to call
extremely small functions in extremely core loops. The first advice
would be avoid calling extremely small functions in extremely core loops!
D is a native language, that's it's most attractive feature, and while I
appreciate all the high-level correct-ness D offers, it still needs to
get the low level right and ideally improve on
Re: DDoc and logically structured HTML
On 03/11/2012 12:46 PM, Stewart Gordon wrote: On 11/03/2012 02:26, Kevin Cox wrote: snip I hate to say it but I think the ddoc system was way overthought. It would be better to use a markup language such as Creole that is meant to look nice and you can convert that into anything you want. You could leave the default html but provide an api for accessing a parsed tree. I think this is more or less how Java doclets work. It works because Java's bytecode and dynamic class loading provide a means to call an arbitrary method of an arbitrary compiled class that need not be part of the same app. But how are we going to do this with D? It seems we would need to either: (a) compile the doclet on the fly and pass the parse tree into it (b) have in said API a parse tree constructor that translates it from a textual representation received through stdin. Stewart. I don't understand why you related dynamic class' loading with a documentation system/syntax for D. Some hours ago you closed a very old enhancement report I submited: http://d.puremagic.com/issues/show_bug.cgi?id=3161 (in fact I had totally forgotten I implemented that :-P, so thanks for reminding it to me... thought I didn't like that you closed it as invalid) Now, I implemented it purely based on dmd's code. I didn't add anything else to get that done. And D is not dynamic or doesn't have dynamic class loading. So... can you explain a bit more? And does somebody know why, being dmd able to compile files, which requires having exact type information for every method/template,whatever, generates such a poor documentation? Another question: ddoc is used (or was used) to generate d's main site. Wut?? So it's much more than just documenting D classes. I think this is wrong. That's when you end up having macros and all of that, because when generating a page you want to reuse things. But when documentation a library, hmmm... I never needed such thing. And even though I do care about the format of the documentation (how it looks), I definitely don't put formatting information inside a method's documentation (except for code snippets and lists). Some simple like markdown or rdoc (well, the idea, not rdoc itself for D :-P) should be more than enough. If there's interesent, I can hack dmd into producing such documentation, and send a pull request.
Re: Multiple return values...
On 03/11/12 18:45, Manu wrote:
On 11 March 2012 18:45, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
Other than that, there is devirtualization - D does not have 'virtual';
the compiler
can still do it and even inline the virtual methods, but it needs to know
that
nothing overrides the functions - impossible w/o WPO for public non-final
classes. [1]
[...]
virtual-by-default seems like the single biggest and most harmful _mistake_
in the whole language.
Defaulting a feature that introduces very costly damage that ONLY a WPO pass
can possibly un-do can only be described as insanity.
Well, there is 'final' and limiting the visibility can help too ('private' etc).
/validating/ a method is not overridden anywhere is NOT a trivial task. Being
able to do this with confidence will be tedious and waste unimaginable
amounts of time and frustration...
CPUs won't complain and their time is relatively cheap. :)
IOW, if it can be done by the compiler then it should.
If I were evaluating D to use commercially, this would be the biggest red
flag to consider. The time/efficiency costs could potentially be very high.
If it can be done automatically in C++, by looking just at the generated RTTI
in object
files, then a similar approach should work for D. I don't think this is such a
big
problem, especially compared to some things which currently are inexpressible
in D.
eg: http://drdobbs.com/184401938
My understanding is that templates depends on .d/.di files being
present during compilation? So why doesn't D do inlining the same way? If I
declare some inline function in a .d/.di file, surely it should be capable of
inlining?
C/C++ can't inline something from a foreign object either without a
definition in a header...
It's the same for D, I just don't think *.di files should be necessary
for _internal_
cross-module interfaces, or when the full source is available anyway.
Currently, cross-module inlining is a problem for GDC, but even when
that's fixed,
WPO will help things like devirtualization or changing calling
conventions (gcc does
it already, but i don't know if it clones non-local functions just for
this, when not
in WPO mode).
So assuming that most libraries will be closed source, what's the implication
here for inlines and tempaltes long term? It sounds no different than .h
files.
Is there a plan to be able to store that metadata inside lib/object files
somehow? (I assume not, if there was, why need .di files at all)
Well, if you distribute your library as closed source, you can't expect compile
time
optimizations to work across the app/lib boundary - you can't both have the
cake and
eat it. Note you *can* add enough information to the object files so that the
compiler
can do a better job -- simply by compiling your library with LTO enabled. While
this
effectively turns closed-source into obfuscated-source, it's possible to do this
selectively on a by unit basis - which can be acceptable in some situations.
And if your closed-source library exports non-final classes you may not really
want
devirtualization; marking certain members as final would probably be good idea
anyway.
So *.di files work the same as *.h -- you only have to expose the API and can
add as
much extras as you can/want.
artur
Re: Multiple return values...
On 3/11/12 8:23 AM, Manu wrote: On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote: On 03/11/2012 12:50 PM, Manu wrote: Nobody has acknowledged or disputed the majority of my points :/ I agree with the majority of your points. Cool, well that's encouraging :) I can't really argue the implementation details, all I can do is assert criteria/requirements as I see them. So what was the perceived issue with the pull request you mentioned in an earlier post? I presume it only implemented the syntax, and not the ABI bits? Yes. Just to clarify, Kenji's pull request only improves the syntax. On 11 March 2012 15:08, David Nadlinger s...@klickverbot.at mailto:s...@klickverbot.at wrote: On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu wrote: This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. TypeTuple!(ReturnType1, ReturnType2)? Right, well I'm glad I'm not the only one :) I figured this must have some important implication that I totally missed... Of course it does. If you create a variable of type TypeTuple!(ReturnType1, ReturnType2), what's its layout? Andrei
Re: Breaking backwards compatiblity
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.478.1331478431.4860.digitalmar...@puremagic.com... On Sun, Mar 11, 2012 at 04:12:12AM -0400, Nick Sabalausky wrote: so s...@so.so wrote in message news:pzghdzojddybajugu...@forum.dlang.org... [...] No matter how much hardware you throw at it, somehow it gets slower and slower. New hardware can't keep up with (ever increasing) writing bad software. http://www.agner.org/optimize/blog/read.php?i=9 That is a *FANTASTIC* article. Completely agree, and it's very well-written. I really liked the point about GUIs. Many resources are used for graphical elements that only have aesthetic value AND tends to distract the user from actual work. IOW, you're wasting CPU, RAM, and disk time (which comes from spending lots of hard-earned cash for that expensive hardware upgrade) just for some silly eye-candy that has no value whatsoever except to distract from the task at hand, that is, to accomplish what you set out to do in the first place. That's why I use ratpoison as my WM. Who needs title bars with fancy colored icons, gradient shading, and *shadows*?! I mean, c'mon. Actually, I rather like my black windows with dark-blue to light-purple gradient title bars. I've been using that scheme for years and I don't think I'll ever change it: http://www.semitwist.com/download/img/shots/myColorScheme.png You're trying to get work done, not admire how clever the UI designers were and how cool a color gradient is. If I wanted to admire eye-candy, I'd be playing computer games, not working. (That said, though, I did at one point have a Compiz installation for the sole purpose of showing off Linux to clueless people. :-P) Before I upgraded my Linux box to Kubuntu 10.04, it was Ubuntu...umm...something before 10.04, and although I'm not normally a UI-eye-candy guy, I fell in love with the window physics effect whle draggng windows. And it was properly hardware accellerated, so it worked very fast even being on an old 32-bit single-core. My brother, who had recently gotten a Mac laptop (although he's now become the third member of my family who's gotten fed up with Apple) saw it and exclaimed I want jelly windows! But then in Kubuntu 10.04, the effect no longer works (or maybe it just doesn't work with hardware accelleration, I don't remember now), so I had to give it up :( 'Course, I'm more than ready to give up KDE itself now. Move to something like Trinity or LXDE or XFCE. And Debian 6. Canonincal just keeps getting crazier and crazier. I don't want their new Linux-based iOS of an operating system. OTOH, Debian's versioning system is irritationly moroninc. Squeeze, wheeze, wtf? They don't even have any natural ordering for god's sake! At least Ubuntu's moronic names have *that* much going for them! I don't care what Pixar character my OS is pretending to be, and I don't *want* to care. Then the points about background processes, auto-updates, and boot-up times. These are things about Windows that consistently drive me up the wall. Background processes are all nice and good as long as they are (1) necessary, and (2) don't do stupid things like hog your CPU or thrash your disk every 12 seconds. But the way Windows works, every time you install something, it insists on starting up at boot-time, incessantly checking for auto-updates every 12 seconds, downloading crap from online without your knowledge, and THEN pop up those intrusive, distracting, and utterly annoying Plz Update M! dialogs. Ugh. Everytime I see one of those dialogs I have this urge to delete the app and expunge all traces of it from the system with extreme prejudice. At least on Linux you can turn off this crap and/or otherwise prevent it from doing stupid things. But on Windows you have no choice. Attempting to disable stuff usually breaks said apps, or affects system usability in some way. I just avoid those programs (and immediately disable the upgrade nag screens). For example, I will *not* allow Safari or Chrome to even *touch* my computer. (When I want to test a page in Chrome, I use SRWare Iron instead. If SRWare Iron ever goes away, then Chrome users will be on their own when viewing my pages.) -- Ignorance is bliss... but only until you suffer the consequences! So very true :)
Re: Breaking backwards compatiblity
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.456.1331450402.4860.digitalmar...@puremagic.com... On Sat, Mar 10, 2012 at 10:41:48PM -0800, Walter Bright wrote: On 3/10/2012 1:20 PM, H. S. Teoh wrote: It's no fun at all if you had to wait 2 hours just to find out you screwed up some parameters in your test render. Imagine if you had to wait 2 hours to know the result of every 1 line code change. 2 hours? Man, you got good service. When I submitted my punched card decks, I'd be lucky to get a result the next day! (Yes, I did learn to program using punch cards. And to be fair, the programs were trivial compared with the behemoths we write today.) And also today, the complexity of the compile/link process can lead to dainbramaged makefiles that sometimes fail to recompile a changed source, and the linker picks up leftover junk .o's from who knows how many weeks ago, causing heisenbugs that don't exist in the source code but persistently show up in the binary until you rm -rf the entire source tree, checkout a fresh copy from the repos, reapply your changes, and rebuild the whole thing from scratch. (And that's assuming that in the meantime somebody didn't check in something that doesn't compile, or that introduces new and ingenious ways of breaking the system.) *cough*DMD*cough*
Re: Multiple return values...
On 03/11/2012 07:57 PM, Andrei Alexandrescu wrote: On 3/11/12 6:50 AM, Manu wrote: On 11 March 2012 05:04, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org There is no difference. A Tuple is a product type, exactly like superposing arbitrary values together. So you're saying that whatever I think about the implementation of Tuple is wrong? It is not actually a structured type? I don't know what you mean by structured type. What I mean by product type is this: http://en.wikipedia.org/wiki/Product_type This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit. I don't know how 'major' they'd really work out to be. It's not a paradigm buster. There are some details, but I don't even think it would need to be a breaking change to the language (maybe some very subtle tweaks). I am convinced you are underestimating. The notion that a function returns one typed value is strongly embedded in the language and the standard library. static assert(is(TypeTuple!(int, double))); // it is a valid type. static assert(is(typeof(TypeTuple!(int, double).init)));// there are values of that type. Can you quantify 'little' benefit? I started this thread because I have found myself wishing for this feature every other day. It would be of huge value, and many others seem to agree. I think you and others are concerned with different aspects (incrementally pleasant syntax vs. efficiency). He and others are concerned with both. =) D has it all, there are so many features in D which make it feel like a modern language, but this is a missed(/rejected?) opportunity. It's a natural thing to want to ask a computer to do, but we're mentally trained into the returns-a-single-thing model from C and whatever and apparently it was never considered at the initial design stage, but apart from the expressive side, more importantly in D's case as a native language, it is an opportunity to implement an important low level feature that no other language offers me; an efficient multi-return syntax+ABI. D can return multiple values from a function by putting them in a tuple. This approach has many advantages, mostly related to avoiding awkward ambiguities (e.g. forwarding the result of a multi-return to a variadic or overloaded function). Regarding syntax, I am not convinced by arguments predicated on removing Tuple! from Tuple!(int, int). It's not progress, and pouring more magic in tuples that is not available anywhere else does not strike me as a good path to go. The suggestion was for language tuples. static assert(TypeTuple!(int,int).stringof=(int, int)); // =o! There is nothing extremely bad about having to use Tuple!, even if it is not that beautiful. The more annoying bit is unpacking them. More flexible type inference is desirable. Adding magic to the library tuple obviously is not. Therefore I was aiming at making the built-in tuples more powerful. I currently see the issue this way: - There is a pull for tuple unpacking syntax sugar. - This is not merged because it is possibly not general enough. - A more general solution will probably not be added to the language. [snip.] Good points. However, adding multiple return values after the implementation is fleshed out still seems like a good idea.
Re: Breaking backwards compatiblity
Matej Nanut matejna...@gmail.com wrote in message news:mailman.471.1331466712.4860.digitalmar...@puremagic.com... I'm getting a new laptop this week because I direly need it at the faculty (some robotics/image processing/computer vision Neat stuff!! However, I could notice an interesting trend between my colleagues' programs and mine. For example, solving the 15-game with heuristics took ~0.01 secs on the Eee, and comparing to others' programs theirs took several seconds and found worse solutions (not all of them of course, but most). When doing some local search optimisation, the difference was seconds-to-HOURS. I guess someone was really sloppy, but still. Yup. Not surprised. This has also been one of the reasons I became interested in languages like C and D. Believe it or not, in our university, you don't ever get to see C officially if you don't learn it yourself. I consider this pathetic. The official and only taught language is Java. Which I grant them is at least cross-platform, but I believe that every university-educated programmer must know C. Yea, Java has been pretty much the de facto standard College Computer Science language since I left college (close to 10 years ago now...god, that just seems so *wrong* that's it's been that long...) I am convinced that my university produces bad programmers and as such don't find it surprising that new written programs are terribly slow, if they even work at all. I'm convinced that colleges in general produce very bad programmers. The good programmers who have degrees, for the most part (I'm sure there are rare exceptions), are the ones who learned on their own, not in a classroom. It's sad that society brainwashes people into believing the opposite.
Re: Breaking backwards compatiblity
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.479.1331479176.4860.digitalmar...@puremagic.com... Java is a not-bad language. In fact, as a language it has quite a few good points. +1 Java's actually the reason I got fed up with C++'s *cough*module system*cough* and header files. The lack of - was nice too. However, one thing I could never stand about Java culture is what I call the bandwagon-jumping attitude. [...] +1, or two, or three Obligatory quote: If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell :-) Hah! Fantastic. -- Question authority. Don't ask why, just do it. Fantastic, too. :)
Re: Multiple return values...
On 03/11/2012 07:58 PM, Andrei Alexandrescu wrote: On 3/11/12 7:52 AM, Timon Gehr wrote: It is extremely obvious how multiple return values should work. (int, int) fun(); writeln(fun()); auto a = fun(); writeln(a); What should happen? Andrei That largely depends on fun. For instance, if it terminates without side effects and always returns (1,2), then the program output should be: 12 12 This is already given by the current language semantics: writeln(tuple(1,2).expand); auto a = tuple(1,2).expand; writeln(a);
Re: Romans, rubies and the D
On 3/11/12 1:37 PM, Timon Gehr wrote: On 03/11/2012 06:53 PM, Andrei Alexandrescu wrote: Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Andrei Roman.IX crashes the compiler. worksforme Andrei
Re: Breaking backwards compatiblity
deadalnix deadal...@gmail.com wrote in message news:jjif2l$1cdi$1...@digitalmars.com... Le 09/03/2012 23:32, Walter Bright a écrit : This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. I think Linus is mostly right. But I don't think this is a reason not put the bar very high. Especially with the current state of D. This is more about providing a nice, and long, transition process. The way @property evolve is a good example of what we should do. An example of management the change (even breaking change) is PHP. PHP has so much improved if you consider what have changed between v4 and v5, and then v5 and v5.3, that it is a factual proof that breaking change can be done to great benefit. PHP could have handled the changes MUCH better than it did, though.
Re: Breaking backwards compatiblity
Nick Sabalausky a@a.a wrote in message news:jjiv40$2aba$1...@digitalmars.com... deadalnix deadal...@gmail.com wrote in message news:jjif2l$1cdi$1...@digitalmars.com... An example of management the change (even breaking change) is PHP. PHP has so much improved if you consider what have changed between v4 and v5, and then v5 and v5.3, that it is a factual proof that breaking change can be done to great benefit. PHP could have handled the changes MUCH better than it did, though. Ermm, the transition, I mean.
Re: Multiple return values...
On 03/11/2012 08:17 PM, Andrei Alexandrescu wrote:
If you create a variable of type
TypeTuple!(ReturnType1, ReturnType2), what's its layout?
That is context-dependent:
union U{
TypeTuple!(int, double) x; // superimposed according to union abi
}
struct S{
TypeTuple!(int, double) x; // sequential according to struct ABI
}
void foo(){
TypeTuple!(int, double) x; // two non-overlapping memory areas on
the stack
}
void bar(TypeTuple!(int, double) x){ // according to function call ABI
// ...
}
TypeTuple!(int, double) qux(){ // D'oh!
// ...
}
Re: Arbitrary abbreviations in phobos considered ridiculous
Ary Manzana a...@esperanto.org.ar wrote in message news:jjis50$23se$1...@digitalmars.com... On 03/11/2012 05:47 AM, Nick Sabalausky wrote: H. S. Teohhst...@quickfur.ath.cx wrote in message news:mailman.454.1331448329.4860.digitalmar...@puremagic.com... On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote: H. S. Teohhst...@quickfur.ath.cx wrote in message news:mailman.447.1331426602.4860.digitalmar...@puremagic.com... [...] In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional. I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.:-) I admire that :) Personally, I don't have the patience. I just bitch and moan :) Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway. So I just leave and never come back to the site. I'd prefer to do that (leave and never come back), but unfortunately, the modern regression of tying data/content to the interface often makes that impossible: For example, I can't see what materials my library has available, or manage my own library account, without using *their* crappy choice of software. It's all just fucking data! Crap, DBs are an age-old thing. Or, I'd love to be able leave GitHub and never come back. But DMD is on GitHub, so I can't create/browse/review pull requests, check what public forks are available, etc., without using GitHub's piece of shit site. I'd love to leave Google Code, Google Docs and YouTube and never come back, but people keep posting their content on those shitty sites which, naturally, prevent me from accessing said content in any other way. Etc... And most of that is all just because some idiots decided to start treating a document-transmission medium as an applications platform. I swear to god, interoperability was better in the 80's. (And jesus christ, *Google Docs*?!? How the fuck did we ever get a document platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out the free crazy-pills?) Nick, how would you implement (protocols, architecture, whatever) an online document editor? I wouldn't make it an online editor. Just let a normal editor access remote files. Done. As for specifically html documents on the web, doesn't http already have provisions for updating anyway? Hell, the *original* web browser was *both* an editor and a viewer. But then Mosaic came along, scrapped the editor part, and everything since has followed suit.
Re: Feq questions about the D language
On 3/11/12 1:44 PM, Caligo wrote: D is not ready for anything. At the very best, It's in alpha. Don't let others make you think otherwise. What happened here? Andrei
Re: Romans, rubies and the D
On 03/11/2012 08:38 PM, Andrei Alexandrescu wrote: On 3/11/12 1:37 PM, Timon Gehr wrote: On 03/11/2012 06:53 PM, Andrei Alexandrescu wrote: Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Andrei Roman.IX crashes the compiler. worksforme Andrei It seems to have been fixed in 2.059head indeed. Relevant bug report: http://d.puremagic.com/issues/show_bug.cgi?id=7527
Re: Arbitrary abbreviations in phobos considered ridiculous
Jacob Carlborg d...@me.com wrote in message news:jji5fa$qma$1...@digitalmars.com... On 2012-03-10 20:41, Nick Sabalausky wrote: You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. But they're redirecting to http://m.drdobbs.com/, which seems to be adapted for mobile devices. Mobile sites have traditionally required less-fancy implementations, so it's not unreasonable to think that some sites would use their mobile version *as* their low-tech fallback version. That's becoming less and less true these days, of course. But looking at http://m.drdobbs.com/ I have a strong feeling that was originally created for things like AvantGo (ie, on PalmOS) which really were very limited: no JS, no nested tables, very low resolution, often not even any color, very low memory, etc. Not that anything about what they're doing really makes a whole lot of sense anyway, though.
Re: Feq questions about the D language
On 11-03-2012 19:44, Caligo wrote: D is not ready for anything. At the very best, It's in alpha. Don't let others make you think otherwise. DMD is one of the buggiest compilers out there. If you are a non-DMD/Phobos developer and think that D is ready for any kind of work then you must be high on dope. If you want to learn a new programming language and experience D, then go for it. The language itself is very enjoyable, specially if you are coming from C/C++/Java. However, anything more than a 1K LOC is going to get you in trouble, specially if you decide to use one of the _nice_ features of the language. False. MCI is 20k+ lines. We have around 4 workarounds for DMD bugs in the source. That is all. Yes, things are improving rapidly, but I would say it's going take at least another year before DMD is stable. -- - Alex
Re: Breaking backwards compatiblity
On 3/11/2012 8:29 AM, deadalnix wrote: Win9x was good back then. Now it is crap. Sure, but it's only fair to assess it in the context of its times, not current times. When doing something new (like D) you don't only need to provide something as good as what existed before. Actually, providing better isn't enough either. You need to provide enough to compensate the cost of the change, and additionally communication/marketing must convince user to switch. Yup.
Re: Breaking backwards compatiblity
On 3/11/2012 4:20 AM, Matej Nanut wrote: I've been using an EeePC for everything for the past 2.5 years and until now, I could cope. You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has. I have an EeePC, but I find I could not cope with the tiny screen and tiny keyboard :-)
Re: Breaking backwards compatiblity
On 3/11/2012 12:32 PM, Nick Sabalausky wrote: I'm convinced that colleges in general produce very bad programmers. The good programmers who have degrees, for the most part (I'm sure there are rare exceptions), are the ones who learned on their own, not in a classroom. Often the best programmers seem to have physics degrees!
Re: Breaking backwards compatiblity
On Sunday, 11 March 2012 at 19:22:04 UTC, Nick Sabalausky wrote: I just avoid those programs (and immediately disable the upgrade nag screens). For example, I will *not* allow Safari or Chrome to even *touch* my computer. (When I want to test a page in Chrome, I use SRWare Iron instead. If SRWare Iron ever goes away, then Chrome users will be on their own when viewing my pages.) http://code.google.com/p/smoothgestures-chromium/issues/detail?id=498
Re: Breaking backwards compatiblity
On 3/11/2012 8:34 AM, deadalnix wrote: I do think better name isn't the problem. The problem is about consistency, and will persist as long as we don't agree on a guideline on that in phobos. Changing a name just for changing it doesn't worth the cost, unless the original name is horribly misleading - rare case. But getting the naming convention consistent is of much greater importance, and justify breaking code. Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results. I'm not suggesting no naming convention. Naming conventions are good. But they don't trump everything else in importance, not even close. And sometimes, a name change can be a huge win - the invariant=immutable one is an example. But I think that's an exceptional case, not a rule.
Re: Multiple return values...
On Sun, 11 Mar 2012 12:39:56 -0500, Manu turkey...@gmail.com wrote: On 11 March 2012 18:50, Robert Jacques sandf...@jhu.edu wrote: On Sun, 11 Mar 2012 05:57:05 -0500, Manu turkey...@gmail.com wrote: On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote: On 3/10/2012 8:08 PM, Mantis wrote: [snip] And Walter has talked about using the XMM registers to return floating point data for exactly this reason. But those optimization apply to all structs and all data types. There's nothing special about MRV. It has to return a set of data in a structured manner; this is identical to the case of returning a struct. Well you can't build these sorts of tightly packed structs in XMM registers... and even for the GPR's, it's very inefficient to do so. I haven't done tests, but I suspect this feature is probably a de-optimisation in all cases other than an int-pair struct (ranges, delegates? I suspect that's why this was invented). Structure packing/unpacking code will likely be slower than a store/load. We just need proper multiple return values, then this can go away. And the earlier any ABI breaking changes are implemented, the better, while there are still few(/none?) closed source, binary distributed D libraries. Manu, why are you assuming that the struct is returned in any sort of fixed memory layout? You can _not_ take the memory address, etc of a register so maintaining the layout of a struct is a) impossible and b) not necessary, if you're returning it via registers. The compiler is free to use XMM registers for floats/doubles and GPRs for pointers/ints. And there's no need for the caller to place those struct register values on the stack if they're never used. Furthermore, even on the stack, the struct's memory layout is only ever valid immediately before (and forever after due to pointer escapes) a non-inlined function call or address taking. At a low level, MRV is a structured set of value, ergo it's a struct.
Re: DDoc and logically structured HTML
On 11/03/2012 19:04, Ary Manzana wrote: snip I don't understand why you related dynamic class' loading with a documentation system/syntax for D. Because that's what Javadoc relies on as a means for a program distributed in binary form to call custom code. OK, so there are native ways to do this, like DLLs and SOs. I don't really know whether these are fit for the purpose. It might get a bit complicated supporting the D object model with DMD being written in C++. Some hours ago you closed a very old enhancement report I submited: http://d.puremagic.com/issues/show_bug.cgi?id=3161 (in fact I had totally forgotten I implemented that :-P, so thanks for reminding it to me... thought I didn't like that you closed it as invalid) Now, I implemented it purely based on dmd's code. I didn't add anything else to get that done. And D is not dynamic or doesn't have dynamic class loading. OK, so writing a new documentation generator based on the DMD front end code is another approach. Did you just write it in C++, or do the extra work so that you could write it in D? Either way, it's good that you've written a D documentation generator that's better than standard Ddoc, and no doubt handles D much better than Doxygen does. Have you released it anywhere? So... can you explain a bit more? And does somebody know why, being dmd able to compile files, which requires having exact type information for every method/template,whatever, generates such a poor documentation? I guess because not that much work has gone into Ddoc so far. Another question: ddoc is used (or was used) to generate d's main site. Wut?? So it's much more than just documenting D classes. I think this is wrong. That's when you end up having macros and all of that, because when generating a page you want to reuse things. But when documentation a library, hmmm... I never needed such thing. And even though I do care about the format of the documentation (how it looks), I definitely don't put formatting information inside a method's documentation (except for code snippets and lists). By formatting information are you talking about semantic/logical markup or presentational/physical markup? http://webtips.dan.info/logical.html talks about the differences between them - written from an HTML point of view but I suppose equally applicable to Ddoc macros. Some simple like markdown or rdoc (well, the idea, not rdoc itself for D :-P) should be more than enough. If there's interesent, I can hack dmd into producing such documentation, and send a pull request. To replace the current Ddoc comment format, or to give the user the choice between that and whatever else? Replacing the current format would be a breaking change. Having two formats built into DMD would seem silly, aside from the question of how you would specify which is being used in a given project. The idea of Ddoc is that it's the standard D way of doing documentation. If a compiler has built-in documentation generation, it should use either a format that is part of the language standard or some established format such as Doxygen, rather than some non-portable ad-hoc format. Which is what what you're thinking of doing would be, unless it's incorporated into the language standard. But having two documentation comment formats in the language standard is itself something that doesn't seem to make sense. It would be like the whole D language having two syntaxes. Stewart.
Re: Multiple return values...
On 03/11/2012 09:30 PM, Robert Jacques wrote: On Sun, 11 Mar 2012 12:39:56 -0500, Manu turkey...@gmail.com wrote: On 11 March 2012 18:50, Robert Jacques sandf...@jhu.edu wrote: On Sun, 11 Mar 2012 05:57:05 -0500, Manu turkey...@gmail.com wrote: On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote: On 3/10/2012 8:08 PM, Mantis wrote: [snip] And Walter has talked about using the XMM registers to return floating point data for exactly this reason. But those optimization apply to all structs and all data types. There's nothing special about MRV. It has to return a set of data in a structured manner; this is identical to the case of returning a struct. Well you can't build these sorts of tightly packed structs in XMM registers... and even for the GPR's, it's very inefficient to do so. I haven't done tests, but I suspect this feature is probably a de-optimisation in all cases other than an int-pair struct (ranges, delegates? I suspect that's why this was invented). Structure packing/unpacking code will likely be slower than a store/load. We just need proper multiple return values, then this can go away. And the earlier any ABI breaking changes are implemented, the better, while there are still few(/none?) closed source, binary distributed D libraries. Manu, why are you assuming that the struct is returned in any sort of fixed memory layout? Because that is what the ABI says. * 1, 2 and 4 byte structs are returned in EAX. * 8 byte structs are returned in EDX,EAX, where EDX gets the most significant half. * For other struct sizes, the return value is stored through a hidden pointer passed as an argument to the function. You can _not_ take the memory address, etc of a register so maintaining the layout of a struct is a) impossible and b) not necessary, if you're returning it via registers. The compiler is free to use XMM registers for floats/doubles and GPRs for pointers/ints. And there's no need for the caller to place those struct register values on the stack if they're never used. Furthermore, even on the stack, the struct's memory layout is only ever valid immediately before (and forever after due to pointer escapes) a non-inlined function call or address taking. At a low level, MRV is a structured set of value, ergo it's a struct. Multiple function arguments are a structured set of values too.
Re: Multiple return values...
On 11 March 2012 20:57, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
I don't know what you mean by structured type. What I mean by product
type is this:
http://en.wikipedia.org/wiki/**Product_typehttp://en.wikipedia.org/wiki/Product_type
The first line on that page states my meaning verbatim:
In programming languageshttp://en.wikipedia.org/wiki/Programming_language
and type theory http://en.wikipedia.org/wiki/Type_theory, a *product* of
*types* is another, compounded, type *in a structure*.
The objectionable part to me is that as soon as it becomes 'structured'
there are additional details in the mix; a defined memory layout and
requirement to adhere by said layout. This allows the coder to do some
things that should be conceptually impossible; take the pointer of the
first item, perform some math, and arrive at another member. This shouldn't
be applicable to a passing in registers ABI.
I don't know how 'major' they'd really work out to be. It's not a
paradigm buster. There are some details, but I don't even think it would
need to be a breaking change to the language (maybe some very subtle
tweaks).
I am convinced you are underestimating. The notion that a function returns
one typed value is strongly embedded in the language and the standard
library.
You're probably right, and I don't entirely object to the Tuple solution
(given a nice little bit of sugar), as I've said before (and above), my
concern is that it confuses 2 distinct operations (returning multiple
things, and returning a struct by value), both of which should remain
expressible by the language.
D can return multiple values from a function by putting them in a tuple.
This approach has many advantages, mostly related to avoiding awkward
ambiguities (e.g. forwarding the result of a multi-return to a variadic or
overloaded function). Regarding syntax, I am not convinced by arguments
predicated on removing Tuple! from Tuple!(int, int). It's not progress,
and pouring more magic in tuples that is not available anywhere else does
not strike me as a good path to go.
Well the feature becomes very ugly, clutters the intent with syntax,
requires ugly lines of unpacking syntax, and also asserts to the programmer
that they're exploiting a template library. When I encounter anything like
this in C (*cough* STL), I will immediately lose all trust in the compilers
codegen between compilers (even if the language implements some hacks to
define an efficient ABI for this feature).
None of those are hard reasons against *IF* the codegen does exactly what
it is supposed to. I'll swallow any of those if the codegen works, but it
seems a crying shame to refuse some sugar to interact nicely:
void func(int x)
{
someStruct s;
(x, _, s.member, int err) = multiFunc();
if(err == ...) { ... }
}
Results are written directly where they need to end up, saves lines, it's
clear what I'm doing, I think that's valuable.
Regarding low-level efficiency, the main issue is that structs and function
argument lists have distinct layouts. Consider:
import std.stdio, std.typecons;
int a(int b, int c) {
return b + c;
}
auto foo() {
return tuple(1, 1);
}
void main() {
writeln(a(foo().expand));
}
An adjustment may be needed from the output of a() to the arguments of
foo(). (Probably not in this case.) I understand that someone very
concerned with low-level performance would scrutinize such code carefully.
Wow, I can't imagine how '.expand' could possibly work :) .. that looks
like total magic. A parameter list can be populated by items collected in a
tuple via a property?
If such magic is possible, surely the other stuff is equally possible...
This is an example of where the return-multi ABI mirroring the call args
ABI verbatim would really shine.
In this example, assuming the codegen did it's job, the call to foo() would
return with the arg regs for the call to a() pre-populated. It could just
call straight through without doing anything at all to setup the arguments.
Beautiful!
In C, you could only get this via inline asm.
That said though, I feel this is an extension of the basic multi-return
requirement, perhaps also of significantly lesser importance; chaining
together this way would be rare I would imagine. Of course, if it's easily
possible, no reason against :)
But I also believe that the same person is willing to forgo a whole
category of language and library features that don't fulfill a demanding
performance profile.
I'm not sure what you're getting at here, this is a feature designed to
enhance performance (and also enhance convenience + readability while at it)
In the tight loops of every program I've ever written, I can't recall a
time when I haven't had a function that needs to return multiple things,
and C/C++ has always forced me into unnecessary memory access to express
this (ref parameters). For the first time in language/compiler history,
D would finally be able to eliminate
Re: Romans, rubies and the D
On 3/11/2012 10:53 AM, Andrei Alexandrescu wrote: Just found this: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ Pretty neat-o example! Me like.
