Re: DirectX bindings
On Friday, 8 November 2013 at 02:57:25 UTC, Andrej Mitrovic wrote: On 11/3/13, evilrat evilrat...@gmail.com wrote: https://github.com/evilrat666/directx-d Nice! I tried porting one of the samples from the SDK but it uses D3DX11CompileFromFile which is missing in the bindings. MSDN says they recommend not using it (well.. why are they using it in the samples then?: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476261%28v=vs.85%29.aspx So maybe it's not worth binding it? No idea. :) indeed this is not recommended to use, and there are no more such function on windows 8. i'm also need to fix xaudio example too :(
Static Parameter Function Specialization in D
I've read somewhere that D supports specialization of functions
to calls where arguments are compile-time constants. Typical use
of this is in matrix power functions (if exponent is 2 `x*x` is
often faster than the general case).
I want this in my member function
bool opIndexAssign(bool b, size_t i) @trusted pure nothrow
in {
assert(i len);// TODO: Add static assert(i
len) when i is constant
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
of a statically sized `BitSet` struct I'm writing. This in order
to, when possible, get compile-time bounds checking on the index
variable `i`. I thought
bool opIndexAssign(bool b, const size_t i) @trusted pure
nothrow in {
static assert(i len);
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
would suffice but then DMD complains as follows
dmd -debug -gc -gs -unittest -D
-Dd/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/
-w -main ~/Work/justd/bitset.d /home/per/Work/justd/assert_ex.d
-of/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/bitset
/home/per/Work/justd/bitset.d(58): Error:
bitset.BitSet!2.BitSet.opIndexAssign called with argument types
(bool, int) matches both:
/home/per/Work/justd/bitset.d(49): opIndexAssign(bool b,
ulong i)
and:
/home/per/Work/justd/bitset.d(65): opIndexAssign(bool b,
const(ulong) i)
/home/per/Work/justd/bitset.d(66): Error: variable i cannot
be read at compile time
/home/per/Work/justd/bitset.d(66):while evaluating:
static assert(i 2LU)
/home/per/Work/justd/bitset.d(58): Error:
bitset.BitSet!2.BitSet.opIndexAssign called with argument types
(bool, int) matches both:
/home/per/Work/justd/bitset.d(49): opIndexAssign(bool b,
ulong i)
Do I have to make parameter `i` a template parameter, say using
type `U`, and then use static if `someTypeTrait!U`. I tried this
but isMutable!Index always evaluates to true.
import std.traits: isIntegral;
bool opIndexAssign(Index)(bool b, Index i) @trusted pure
nothrow if (isIntegral!Index) in {
import std.traits: isMutable;
// See also:
http://stackoverflow.com/questions/19906516/static-parameter-function-specialization-in-d
static if (isMutable!Index) {
assert(i len);
} else {
import std.conv: to;
static assert(i len,
Index ~ to!string(i) ~ must be
smaller than BitSet length ~ to!string(len));
}
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
Re: Static Parameter Function Specialization in D
On Monday, 11 November 2013 at 13:41:04 UTC, Nordlöw wrote:
I've read somewhere that D supports specialization of functions
to calls where arguments are compile-time constants. Typical
use of this is in matrix power functions (if exponent is 2
`x*x` is often faster than the general case).
I want this in my member function
bool opIndexAssign(bool b, size_t i) @trusted pure
nothrow in {
assert(i len);// TODO: Add static
assert(i len) when i is constant
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
of a statically sized `BitSet` struct I'm writing. This in
order to, when possible, get compile-time bounds checking on
the index variable `i`. I thought
bool opIndexAssign(bool b, const size_t i) @trusted pure
nothrow in {
static assert(i len);
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
would suffice but then DMD complains as follows
dmd -debug -gc -gs -unittest -D
-Dd/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/
-w -main ~/Work/justd/bitset.d
/home/per/Work/justd/assert_ex.d
-of/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/bitset
/home/per/Work/justd/bitset.d(58): Error:
bitset.BitSet!2.BitSet.opIndexAssign called with argument types
(bool, int) matches both:
/home/per/Work/justd/bitset.d(49): opIndexAssign(bool b,
ulong i)
and:
/home/per/Work/justd/bitset.d(65): opIndexAssign(bool b,
const(ulong) i)
/home/per/Work/justd/bitset.d(66): Error: variable i cannot
be read at compile time
/home/per/Work/justd/bitset.d(66):while evaluating:
static assert(i 2LU)
/home/per/Work/justd/bitset.d(58): Error:
bitset.BitSet!2.BitSet.opIndexAssign called with argument types
(bool, int) matches both:
/home/per/Work/justd/bitset.d(49): opIndexAssign(bool b,
ulong i)
Do I have to make parameter `i` a template parameter, say using
type `U`, and then use static if `someTypeTrait!U`. I tried
this but isMutable!Index always evaluates to true.
import std.traits: isIntegral;
bool opIndexAssign(Index)(bool b, Index i) @trusted pure
nothrow if (isIntegral!Index) in {
import std.traits: isMutable;
// See also:
http://stackoverflow.com/questions/19906516/static-parameter-function-specialization-in-d
static if (isMutable!Index) {
assert(i len);
} else {
import std.conv: to;
static assert(i len,
Index ~ to!string(i) ~ must be
smaller than BitSet length ~ to!string(len));
}
} body {
b ? bts(ptr, i) : btr(ptr, i);
return b;
}
It's possible that the compiler can inline the function and
optimize the code from there, but I don't know of any language
feature that can do this explicitly.
Re: Static Parameter Function Specialization in D
Please never post such questions to announcement list. There is a D.learn for that.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/11/13, Sergei Nosov sergei.no...@gmail.com wrote: I've done some experiments regarding dmd/ldc comparison. Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU @ 3.20GHz × 4 Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler (0.12.0): based on DMD v2.063.2 and LLVM 3.3.1 Default target: x86_64-unknown-linux-gnu Host CPU: core-avx-i I've made 2 builds: $ dub --build=release $ dub --build=release --compiler=ldc2 Which flags does release imply? So, the ratio is something like 0.81-0.83 in favor of ldc. Cool! Thanks for benchmarking.
Re: Static Parameter Function Specialization in D
On Monday, 11 November 2013 at 14:41:14 UTC, Dicebot wrote: Please never post such questions to announcement list. There is a D.learn for that. I'm very sorry. It was a mistake. Can I move or delete this post?
Re: The D in Novosibirsk State University
On Sunday, 10 November 2013 at 20:05:29 UTC, Michael wrote: Yes, Russia) Topic: The D Programming Language: features and application. Author: Nikolai Tolstokulakov. Event: NSU Tech Talks Date: Nov 05, 2013 Slides: https://speakerdeck.com/techtalksnsu/iazyk-proghrammirovaniia-d-nikolai-tolstokulakov Heh, funny to see this said about D in slide 6, It is complex (more 100 keywords vs 50 in Java), especially since one of the selling points of D1 was its simplicity compared to C++. I suppose in the feature race with C++, it was inevitable that that would get lost along the way. Still, interesting to see that is now the public perception of D2 also. Regarding the slide deck, nice job of summarizing D2 and pulling out the unique features that would interest new users. :)
Re: dmd 2.064.2
On 2013-11-05 23:08, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb The version says DMD64 D Compiler v2.064 instead of DMD64 D Compiler v2.064.2. The Mac OS X installer is an old version. It's installs the correct version of the compiler but the text in the installer is outdated. -- /Jacob Carlborg
Re: dmd 2.064.2
El 11/11/13 19:00, Jacob Carlborg ha escrit: The version says DMD64 D Compiler v2.064 instead of DMD64 D Compiler v2.064.2. Same on Linux. On v2.064.2: ... DMD64 D Compiler v2.064 ... On v2.063.2: ... DMD64 D Compiler v2.063.2 ... -- Jordi Sayol
Re: The D in Novosibirsk State University
On Sunday, 10 November 2013 at 23:19:22 UTC, Froglegs wrote: Slides are in English, do most Russian programmers speak English? Not only programmers and English. It's mix of education, culture and pro activity (Internet helps). Also additional language adds additional + to karma ;)
Re: dmd 2.064.2
On 11 Nov 2013 20:32, Jordi Sayol g.sa...@yahoo.es wrote: El 11/11/13 19:00, Jacob Carlborg ha escrit: The version says DMD64 D Compiler v2.064 instead of DMD64 D Compiler v2.064.2. Walter said the version number was not updated before compile, sounded like he preferred not to have to recompile everything just for the version number.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Monday, 11 November 2013 at 15:29:20 UTC, Andrej Mitrovic wrote: On 11/11/13, Sergei Nosov sergei.no...@gmail.com wrote: I've done some experiments regarding dmd/ldc comparison. Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU @ 3.20GHz × 4 Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler (0.12.0): based on DMD v2.063.2 and LLVM 3.3.1 Default target: x86_64-unknown-linux-gnu Host CPU: core-avx-i I've made 2 builds: $ dub --build=release $ dub --build=release --compiler=ldc2 Which flags does release imply? In my version of dub it's -release -inline -O. I've tried also adding the -noboundscheck flag and it yielded the same results. I guess the setup for ldc is similar.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/12/13, Sergei Nosov sergei.no...@gmail.com wrote: In my version of dub it's -release -inline -O. I've tried also adding the -noboundscheck flag and it yielded the same results. I guess the setup for ldc is similar. What about using -version=CHIP_USE_DOUBLES ? I get quite a slowdown when using it with DMD, I'm wondering whether it's compiler-specific.
Re: Static Parameter Function Specialization in D
On Monday, November 11, 2013 17:56:38 Nordlöw wrote: On Monday, 11 November 2013 at 14:41:14 UTC, Dicebot wrote: Please never post such questions to announcement list. There is a D.learn for that. I'm very sorry. It was a mistake. Can I move or delete this post? No. This forum has three front-ends - nntp newsgroup, mailing list, and the website - with nntp as the backend. So, in general, once it's out there, it's out there. Occasionally, Walter will remove spam from the nntp server so that it doesn't end up in the archives, but that's pretty much it. Just be more careful about where you post in the future. - Jonathan M Davis
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Tuesday, 12 November 2013 at 04:07:14 UTC, Andrej Mitrovic wrote: On 11/12/13, Sergei Nosov sergei.no...@gmail.com wrote: In my version of dub it's -release -inline -O. I've tried also adding the -noboundscheck flag and it yielded the same results. I guess the setup for ldc is similar. What about using -version=CHIP_USE_DOUBLES ? I get quite a slowdown when using it with DMD, I'm wondering whether it's compiler-specific. For some reason, DMD (v2.064.2) fails to compile with that flag. The error is: Internal error: ../ztc/cg87.c 331 Error: DMD compile run failed with exit code 1 LDC slows down for about 20-25%. Timings: 5797.39 2779.01 537.136 13459.3 4483.73 865.685 9324.52 4311.65 809.551 1088.42 1705.75 1701.38 6041.41 11310.5 409.587 726.283 10.6212
Re: Visual D 0.3.37 released
On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote: ok i forgot about output pane. so what i see here... ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL so the problem with debug server formats? i wish it would work with visual studio 2013 soon, but at least x64 debug works so i can continue using it for now \0/
Re: D parsing
On 2013-11-10 23:49, Andrei Alexandrescu wrote: The way I see this is, these preexisting features (which shan't be thrown away) diminish the motivation for adding another feature. I think the opposite. It shows how powerful macros are and that they will most likely be able to implement other new features that haven't been proposed yet. Adding a bunch of new features to the language instead of taking a step back and thinking if something else can be added that implement these features and many more shows bad judgement. -- /Jacob Carlborg
Re: D parsing
On 2013-11-11 00:37, Andrei Alexandrescu wrote: But the API would add them in exactly the same rote manner. I really don't see an advantage here. An argument for macros would have to do a lot more than we don't need __FILE__ etc. anymore. They do, and several examples have already been shown. I'll also add more as I come up with them. -- /Jacob Carlborg
Re: D parsing
On 2013-11-11 02:54, Andrei Alexandrescu wrote:
What do you have in mind? I find it difficult to grab e.g. the file and
the line unless there's some plumbing in the language that allows you to.
The language just need to provide a way to introspect the AST. If we're
talking about a specific API I can think of something like this:
macro foo (Context context, Ast!(string) str)
{
auto line = context.caller.line;
auto file = context.caller.file;
}
foo(asd);
--
/Jacob Carlborg
Re: DIP 50 - AST macros
On 10.11.2013. 22:20, Jacob Carlborg wrote: I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is: http://wiki.dlang.org/DIP50 Thumbs up!
Re: DIP 50 - AST macros
On 2013-11-11 09:08, luka8088 wrote: Thumbs up! Thanks. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 08:46, Rikki Cattermole wrote:
One of our targets for AST macros should be the ability to replicate
roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
This isn't a thought out design but it should at least be a target or a
possibility.
Absolutely. One of my favorite examples is the database query:
auto person = Person.where(e = e.name == John);
Which translates to the following SQL:
select * from person where name = 'John'
Also c#'s get set should be rather similar as well.
Example:
getset {
public int id;
private bool exit;
}
Would translate to:
private int id;
private bool exit;
@property {
void id(int v) {this.id = v;}
void exit(bool v) { this.exit = v; }
int id() { return this.id; }
bool exit() { return this.exit; }
}
This would definitely open new possibilities up.
Disclaimer I don't like c# or .net but I am partial to these features.
That's quite similar one of the examples, I like to call it property
shortcut:
http://wiki.dlang.org/DIP50#Attribute_macros
At current point I think the DIP does have the necessary features to
implement this. However it would be nice for safety to be able to get
all scope variables of where the macro was initiated from. Being able to
check for if a variable exists could provide much needed compile safety
and better error messages.
Why not? There's quite a lot that is not specified in this DIP. Mostly
because I haven't decided/figured out how it should work exactly. Of
course, any help is always appreciated.
--
/Jacob Carlborg
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote: I think a C backend would get us farther than an LLVM backend. Hi, LLVM has a C++ backend in the git tree. The old C backend is still maintained outside the git tree (search the dev mailing list for an url). So if you like C-output, you can start with LDC today. For sure, you have to port druntime to this new environemnt... Regards, Kai
Re: DIP 50 - AST macros
On Sunday, 10 November 2013 at 22:33:34 UTC, bearophile wrote: Jacob Carlborg: http://wiki.dlang.org/DIP50 I suggest to add some more use cases (possibly with their implementation). Bye, bearophile I agree examples would help a lot. Trying to define what information actually exists within these types would also help a lot. In the first example, would Ast!(bool) be something like this? opBinary!== left = opBinary!+ left = Literal type = int value = 1 right = Literal type = int value = 2 right = Literal type = int value = 4 Would there be helpers for matching part of the structure? The same applies to the other types used - what information should they have? As for examples, here's a couple of suggestions: * Expression to prefix notation * Expression to SQL * AutoImplement properties (like C#) * Number intervals, like int i = int[10..20]; where only 10 to 20 are legal values * Discriminated union * Pattern matching
AA literals/initialisation
immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065?
Re: AA literals/initialisation
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
immutable string[string] priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
main.d(56): Error: non-constant expression [1:blocker,
2:critical,
3:critical, 4:major, 5:major, 6:major,
7:minor,
8:minor, 9:trivial]
This is tedious, how long has it been now?
Seriously, static map's are super-important, they should be
able to be made
immutable, and also be able to be initialised.
Maybe this could be factored into the improvements for 2.065?
The workaround is simple at global scope, but I agree it clutters
the code:
immutable string[string] priorityMap;
shared static this() {
priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
}
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 08:12:59 UTC, Jacob Carlborg wrote:
On 2013-11-11 08:46, Rikki Cattermole wrote:
One of our targets for AST macros should be the ability to
replicate
roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
This isn't a thought out design but it should at least be a
target or a
possibility.
Absolutely. One of my favorite examples is the database query:
auto person = Person.where(e = e.name == John);
Which translates to the following SQL:
select * from person where name = 'John'
Also c#'s get set should be rather similar as well.
Example:
getset {
public int id;
private bool exit;
}
Would translate to:
private int id;
private bool exit;
@property {
void id(int v) {this.id = v;}
void exit(bool v) { this.exit = v; }
int id() { return this.id; }
bool exit() { return this.exit; }
}
This would definitely open new possibilities up.
Disclaimer I don't like c# or .net but I am partial to these
features.
That's quite similar one of the examples, I like to call it
property shortcut:
http://wiki.dlang.org/DIP50#Attribute_macros
At current point I think the DIP does have the necessary
features to
implement this. However it would be nice for safety to be able
to get
all scope variables of where the macro was initiated from.
Being able to
check for if a variable exists could provide much needed
compile safety
and better error messages.
Why not? There's quite a lot that is not specified in this DIP.
Mostly because I haven't decided/figured out how it should work
exactly. Of course, any help is always appreciated.
Theres a few other things I think would need to be cleared up.
For example take this code:
shader {
program
vertex {
#version 150
void main() {
}
}
fragment {
#version 150
void main() {
}
}
}
At this point the vertex / fragment segments would be treated as
strings instead of calling their macros. So perhaps a rule to
identify macros inside macros calls? It would save a lot of time
for parsing reasons.
Also can you alias a macro?
alias fragment = tostring;
That would make things a lot simpler creating nice structures of
them.
Perhaps a condition on a macro like the if's we got for templates
would be useful in the sense of being able to say:
if (lexer.compareLine(0, [a-zA-Z]{1}[a-zA-Z_0-9]*)
lexer.isSymbol(1, SymbolTypes.Macro, vertex))
This would require us to develop a lexer library. But if done
right I don't see why it wouldn't be usable for more than just D
macro checks. Preferably also for e.g. c/c++ wink wink for when
D's front end is in D.
Re: DIP 50 - AST macros
On 2013-11-11 09:28, simendsjo wrote: I agree examples would help a lot. Trying to define what information actually exists within these types would also help a lot. I can tell you right now that I haven't figured out everything, far from everything. In the first example, would Ast!(bool) be something like this? opBinary!== left = opBinary!+ left = Literal type = int value = 1 right = Literal type = int value = 2 right = Literal type = int value = 4 Would there be helpers for matching part of the structure? I don't know. As I said above, I haven't figured out everything. I don't see any support for this in the language. But of course, there can be library functions that help with this. The same applies to the other types used - what information should they have? Suggestions are welcome. Also, see my reply to bearophile http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com#post-l5q1p5:242bs4:241:40digitalmars.com As for examples, here's a couple of suggestions: * Expression to prefix notation * Expression to SQL * AutoImplement properties (like C#) Would that be something like the attribute macro example? http://wiki.dlang.org/DIP50#Attribute_macros * Number intervals, like int i = int[10..20]; where only 10 to 20 are legal values * Discriminated union * Pattern matching Pattern matching usually requires new syntax, which this proposal does not support. -- /Jacob Carlborg
Re: DIP 50 - AST macros
Jacob Carlborg: One of my favorite examples is the database query: auto person = Person.where(e = e.name == John); Which translates to the following SQL: select * from person where name = 'John' Can't you do the same thing with functions similar (same API but different semantics) to std.algorithm ones that generate expression templates? auto person = persons.filter!(e = e.name == John); simendsjo: * Number intervals, like int i = int[10..20]; where only 10 to 20 are legal values What's wrong with this syntax that doesn't reqiire macros? It's more uniform with the rest of the language: Ranged!(int, 10, 20) i; Bye, bearophile
Re: DIP 50 - AST macros
One of our targets for AST macros should be the ability to
replicate roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
could you add the example to the DIP wiki page
Re: DIP 50 - AST macros
Am 11.11.2013 09:28, schrieb simendsjo: On Sunday, 10 November 2013 at 22:33:34 UTC, bearophile wrote: Jacob Carlborg: http://wiki.dlang.org/DIP50 I suggest to add some more use cases (possibly with their implementation). Bye, bearophile I agree examples would help a lot. Trying to define what information actually exists within these types would also help a lot. In the first example, would Ast!(bool) be something like this? opBinary!== left = opBinary!+ left = Literal type = int value = 1 right = Literal type = int value = 2 right = Literal type = int value = 4 Would there be helpers for matching part of the structure? The same applies to the other types used - what information should they have? As for examples, here's a couple of suggestions: * Expression to prefix notation * Expression to SQL * AutoImplement properties (like C#) * Number intervals, like int i = int[10..20]; where only 10 to 20 are legal values * Discriminated union * Pattern matching can you add the example to the DIP?
Re: DIP 50 - AST macros
On Sunday, 10 November 2013 at 21:20:34 UTC, Jacob Carlborg wrote: I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is: http://wiki.dlang.org/DIP50 I like it, Jacob. With or without [ ] it is a good proposal, and I see several places where I would use it. +1
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 09:02:01 UTC, bearophile wrote: Jacob Carlborg: One of my favorite examples is the database query: auto person = Person.where(e = e.name == John); Which translates to the following SQL: select * from person where name = 'John' Can't you do the same thing with functions similar (same API but different semantics) to std.algorithm ones that generate expression templates? auto person = persons.filter!(e = e.name == John); The problem here is that a library need to know that it has to create SELECT * FROM persons WHERE name = 'John'; and not SELECT * FROM persons; and filter it locally. So it needs a way to inspect the body of the delegate and extract name == and John. simendsjo: * Number intervals, like int i = int[10..20]; where only 10 to 20 are legal values What's wrong with this syntax that doesn't reqiire macros? It's more uniform with the rest of the language: Ranged!(int, 10, 20) i; Bye, bearophile Nothing wrong with it, I was just trying to come up with some examples. I don't say they're necessarily good :)
Re: DIP 50 - AST macros
On 2013-11-11 09:31, Rikki Cattermole wrote:
Theres a few other things I think would need to be cleared up.
For example take this code:
shader {
program
vertex {
#version 150
void main() {
}
}
fragment {
#version 150
void main() {
}
}
}
At this point the vertex / fragment segments would be treated as strings
instead of calling their macros. So perhaps a rule to identify macros
inside macros calls? It would save a lot of time for parsing reasons.
They way I see that is the AST of the whole block would be passed to
shader. I have though a bit about macros inside macros, but I haven't
come to a conclusion. The easiest way from a design point of view seems
to be that shader to basically return the whole AST it receives plus
any addition it needs to do. The the vertex and fragment macros are
expanded recursively.
Also can you alias a macro?
alias fragment = tostring;
That would make things a lot simpler creating nice structures of them.
I don't see why not.
Perhaps a condition on a macro like the if's we got for templates would
be useful in the sense of being able to say:
if (lexer.compareLine(0, [a-zA-Z]{1}[a-zA-Z_0-9]*)
lexer.isSymbol(1, SymbolTypes.Macro, vertex))
I don't think I understand how this should be used.
This would require us to develop a lexer library. But if done right I
don't see why it wouldn't be usable for more than just D macro checks.
Preferably also for e.g. c/c++ wink wink for when D's front end is in D.
--
/Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 10:02, bearophile wrote: Can't you do the same thing with functions similar (same API but different semantics) to std.algorithm ones that generate expression templates? auto person = persons.filter!(e = e.name == John); I have been thinking about that, a solution where e is a proxy that implements opDispatch and which returns a new proxy which overloads ==. The problem with this is that you cannot separately overload the equal and comparison operators. In D the all the comparisons operators are implement with the single overload, opCmp. You cannot know from inside of opCmp if it's the or the operator that is being called. Same problem with opEquals. -- /Jacob Carlborg
Re: D french-speaking community
On Saturday, 9 November 2013 at 20:15:19 UTC, Raphaël Jakse wrote: Le 09/11/2013 18:26, Ali Çehreli a écrit : On 11/08/2013 11:43 PM, Raphaël Jakse wrote: I didn't know this word. My dictionary (Le Petit Larousse 2006) only says that is a Swiss word for pochoir, which is a stencil, which indeed can be considered as a template. In Switzerland, it came from German (and, maybe, in Turkish too): http://de.wikipedia.org/wiki/Schablone French equivalent: http://fr.wikipedia.org/wiki/Pochoir Another choice: http://fr.wikipedia.org/wiki/Template_(programmation)
Re: Applications that created on D Programming
On Thursday, 7 November 2013 at 05:34:28 UTC, Vincent wrote: My instructor ask me a sample application that created in D. Can you give me an application that has created in D programming not the code but a title? Here are some Windows apps with GUI and multithreading: http://www.infognition.com/blogsort/ - image processor http://www.infognition.com/undup/ - disk space visualizer and duplicates searcher
Re: DIP 50 - AST macros
On 2013-11-11 10:07, Dejan Lekic wrote: I like it, Jacob. With or without [ ] it is a good proposal, and I see several places where I would use it. +1 Thank you. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 10:23, simendsjo wrote: On Monday, 11 November 2013 at 09:02:01 UTC, bearophile wrote: auto person = persons.filter!(e = e.name == John); The problem here is that a library need to know that it has to create SELECT * FROM persons WHERE name = 'John'; and not SELECT * FROM persons; and filter it locally. So it needs a way to inspect the body of the delegate and extract name == and John. This particular example would work. e would be a proxy which implements opDispatch which returns another proxy which overloads opEquals. The problem is that != and all the comparison operators won't work. See my reply to bearophile: http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com?page=3#post-l5q892:242kpf:241:40digitalmars.com -- /Jacob Carlborg
Re: Applications that created on D Programming
On 2013-11-07 06:34, Vincent wrote: My instructor ask me a sample application that created in D. Can you give me an application that has created in D programming not the code but a title? Need help... Thanks Entice Designer. A GUI builder for DFL and DWT: http://www.dprogramming.com/entice.php -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 09:24:31 UTC, Jacob Carlborg wrote:
On 2013-11-11 09:31, Rikki Cattermole wrote:
Theres a few other things I think would need to be cleared up.
For example take this code:
shader {
program
vertex {
#version 150
void main() {
}
}
fragment {
#version 150
void main() {
}
}
}
At this point the vertex / fragment segments would be treated
as strings
instead of calling their macros. So perhaps a rule to identify
macros
inside macros calls? It would save a lot of time for parsing
reasons.
They way I see that is the AST of the whole block would be
passed to shader. I have though a bit about macros inside
macros, but I haven't come to a conclusion. The easiest way
from a design point of view seems to be that shader to
basically return the whole AST it receives plus any addition it
needs to do. The the vertex and fragment macros are
expanded recursively.
Also can you alias a macro?
alias fragment = tostring;
That would make things a lot simpler creating nice structures
of them.
I don't see why not.
Perhaps a condition on a macro like the if's we got for
templates would
be useful in the sense of being able to say:
if (lexer.compareLine(0, [a-zA-Z]{1}[a-zA-Z_0-9]*)
lexer.isSymbol(1, SymbolTypes.Macro, vertex))
I don't think I understand how this should be used.
This would require us to develop a lexer library. But if done
right I
don't see why it wouldn't be usable for more than just D macro
checks.
Preferably also for e.g. c/c++ wink wink for when D's front
end is in D.
An example of this might be:
macro foo (Context context, Ast!(string) str)
if (lexer.isSymbol(0, SymbolTypes.Class))
{
return str;
}
class Bar {
int i;
}
foo {
Bar(7);
}
The above code would succeed however the below code will give a
compiler error stating that the given macro is not found.
struct Haz {
int i;
}
foo {
Haz(9);
}
The above code is based on the assumption of a D lexer in phobos.
This is simpler set of code which won't require a lexer.
macro foo (Context context, Ast!(string) str)
if (str == working)
{
return ;
}
foo {fails}
foo {working}
In these cases its a simple string test to determine if the text
given is specified value.
In the original example I gave, I was using regex to make the
point of validation for a given line passed to the macro.
Re: AA literals/initialisation
A work-around of that type required by a core language feature is not a
sign of quality...
It get's me every single time, and I forget and have to go and find out why
again each time.
Please, fix it finally.
On 11 November 2013 18:33, simendsjo simend...@gmail.com wrote:
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
immutable string[string] priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
main.d(56): Error: non-constant expression [1:blocker, 2:critical,
3:critical, 4:major, 5:major, 6:major, 7:minor,
8:minor, 9:trivial]
This is tedious, how long has it been now?
Seriously, static map's are super-important, they should be able to be
made
immutable, and also be able to be initialised.
Maybe this could be factored into the improvements for 2.065?
The workaround is simple at global scope, but I agree it clutters the code:
immutable string[string] priorityMap;
shared static this() {
priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
}
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring
wrote:
One of our targets for AST macros should be the ability to
replicate roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
could you add the example to the DIP wiki page
Adding use case section with Linq example.
Please remove / modify as required as is first time editing wiki.
curl
auto response = std.net.curl.get(http://website.com/api/blah;); I'm getting this: First-chance exception: std.net.curl.CurlException Peer certificate cannot be authenticated with given CA certificates on handle 8C5090 at std\net\curl.d(3504) Even on non-SSL connections. Am I being redirected? And why does curl crash when it encounters HTTPS anyway? Surely it should be ideal if it 'just worked'?
Re: DIP 50 - AST macros
On 2013-11-11 10:38, Rikki Cattermole wrote:
An example of this might be:
macro foo (Context context, Ast!(string) str)
if (lexer.isSymbol(0, SymbolTypes.Class))
{
return str;
}
class Bar {
int i;
}
foo {
Bar(7);
}
The above code would succeed however the below code will give a compiler
error stating that the given macro is not found.
struct Haz {
int i;
}
foo {
Haz(9);
}
The above code is based on the assumption of a D lexer in phobos.
This is simpler set of code which won't require a lexer.
macro foo (Context context, Ast!(string) str)
if (str == working)
{
return ;
}
foo {fails}
foo {working}
In these cases its a simple string test to determine if the text given
is specified value.
In the original example I gave, I was using regex to make the point of
validation for a given line passed to the macro.
My idea of handling errors in macros is more something like triggering a
real compile error. That could be done via the context parameter,
something like:
macro foo (Context context, Ast!(string) str)
{
if (str.eval() == bar)
context.error(Illegal value 'bar'); // this will trigger the
compile error
}
--
/Jacob Carlborg
Re: DIP 50 - AST macros
I would really like to use AST macros for the following use case:
myAssert( x y);
//will print, on failure, a message, along with all values appearing inside
macro myAssert:
xy failed: x=..., y=...
myAssert( fun(x,y)==z1+z2)
//likewise, but nesting down to all individual variables appearing inside
the macro:
x=..., y=..., fun(x,y)=..., z1=..., z2=..., bar(z1+z2)=...
This would advantageously replace the plethora of unittest helpers found in
other languages, eg: CHECK_EQ, CHECK_LEQ, etc.
Invaluable for debugging or informative unittests and logs.
On Mon, Nov 11, 2013 at 1:52 AM, Rikki Cattermole
alphaglosi...@gmail.comwrote:
On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring wrote:
One of our targets for AST macros should be the ability to
replicate roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
could you add the example to the DIP wiki page
Adding use case section with Linq example.
Please remove / modify as required as is first time editing wiki.
Re: AA literals/initialisation
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? this work ok for me: immutable priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ];
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:04:31 UTC, Jacob Carlborg wrote:
On 2013-11-11 10:38, Rikki Cattermole wrote:
An example of this might be:
macro foo (Context context, Ast!(string) str)
if (lexer.isSymbol(0, SymbolTypes.Class))
{
return str;
}
class Bar {
int i;
}
foo {
Bar(7);
}
The above code would succeed however the below code will give
a compiler
error stating that the given macro is not found.
struct Haz {
int i;
}
foo {
Haz(9);
}
The above code is based on the assumption of a D lexer in
phobos.
This is simpler set of code which won't require a lexer.
macro foo (Context context, Ast!(string) str)
if (str == working)
{
return ;
}
foo {fails}
foo {working}
In these cases its a simple string test to determine if the
text given
is specified value.
In the original example I gave, I was using regex to make the
point of
validation for a given line passed to the macro.
My idea of handling errors in macros is more something like
triggering a real compile error. That could be done via the
context parameter, something like:
macro foo (Context context, Ast!(string) str)
{
if (str.eval() == bar)
context.error(Illegal value 'bar'); // this will
trigger the compile error
}
For errors I was thinking a new pragma.
pragma(error, You did x wrong);
This would fire an error and display the text given. Returning
error code as expected. It is after all in the same league as msg.
It would also remove our current static asserts in our code.
So other words it could be replicated by:
pragma(msg, You did x wrong);
static assert(0);
Just without the whole failed assert message.
Although what I was showing was the idea of overloading of macros
like we have in templates.
Re: AA literals/initialisation
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? And even this works ok: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ];
Re: AA literals/initialisation
On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote: On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? And even this works ok: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; Ohh, but non works on module scope, so yes, it would be fine to fix this
Re: AA literals/initialisation
On Monday, 11 November 2013 at 10:13:02 UTC, Daniel Kozak wrote: On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote: On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? And even this works ok: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; Ohh, but non works on module scope, so yes, it would be fine to fix this but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ];
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:10:33 UTC, Timothee Cour wrote:
I would really like to use AST macros for the following use
case:
myAssert( x y);
//will print, on failure, a message, along with all values
appearing inside
macro myAssert:
xy failed: x=..., y=...
myAssert( fun(x,y)==z1+z2)
//likewise, but nesting down to all individual variables
appearing inside
the macro:
x=..., y=..., fun(x,y)=..., z1=..., z2=..., bar(z1+z2)=...
This would advantageously replace the plethora of unittest
helpers found in
other languages, eg: CHECK_EQ, CHECK_LEQ, etc.
Invaluable for debugging or informative unittests and logs.
On Mon, Nov 11, 2013 at 1:52 AM, Rikki Cattermole
alphaglosi...@gmail.comwrote:
On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring
wrote:
One of our targets for AST macros should be the ability to
replicate roughly linq from c# / .net.
An example syntax for use with AST could be:
auto data = [5, 7, 9];
int[] data2;
query {
from value in data
where value = 6
add to data2
}
Could be unwrapped to:
auto data = [5, 7, 9];
int[] data2;
foreach(value; data) {
if (value = 6) data2 ~= value;
}
could you add the example to the DIP wiki page
Adding use case section with Linq example.
Please remove / modify as required as is first time editing
wiki.
Perhaps an alternative would be:
asserts {
x y
z == z
}
Where the macro would do something like this once converted:
if (!(x y)) writeln(x y failed with x=, x, y= , y);
if (!(z == z)) writeln(z == z failed with z=, z);
This would also have the benefit of allowing for multiple assert
statements for one block.
Re: DIP 50 - AST macros
On 2013-11-11 11:11, Rikki Cattermole wrote: For errors I was thinking a new pragma. pragma(error, You did x wrong); This would fire an error and display the text given. Returning error code as expected. It is after all in the same league as msg. It would also remove our current static asserts in our code. So other words it could be replicated by: pragma(msg, You did x wrong); static assert(0); Just without the whole failed assert message. I like the context parameter better. I'm imagine the context parameter containing a lot of information and functionality to interact with the compiler. A pragma seems not be general enough. Although what I was showing was the idea of overloading of macros like we have in templates. Ok, I see. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 11:10, Timothee Cour wrote: I would really like to use AST macros for the following use case: myAssert( x y); //will print, on failure, a message, along with all values appearing inside macro myAssert: xy failed: x=..., y=... myAssert( fun(x,y)==z1+z2) //likewise, but nesting down to all individual variables appearing inside the macro: x=..., y=..., fun(x,y)=..., z1=..., z2=..., bar(z1+z2)=... This would advantageously replace the plethora of unittest helpers found in other languages, eg: CHECK_EQ, CHECK_LEQ, etc. Invaluable for debugging or informative unittests and logs. Agree. That's the first example in the DIP. Although a very simplified version. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:19:49 UTC, Jacob Carlborg wrote: On 2013-11-11 11:11, Rikki Cattermole wrote: For errors I was thinking a new pragma. pragma(error, You did x wrong); This would fire an error and display the text given. Returning error code as expected. It is after all in the same league as msg. It would also remove our current static asserts in our code. So other words it could be replicated by: pragma(msg, You did x wrong); static assert(0); Just without the whole failed assert message. I like the context parameter better. I'm imagine the context parameter containing a lot of information and functionality to interact with the compiler. A pragma seems not be general enough. I can understand wanting to have a high level version of it in context. I'm just considering a high reuse language feature that could back it. Really it should have been added a while ago given the static assert trick is used a bit. I do actually like the idea of having the ability to call it on context with a bunch of extra information given to it for you. e.g. line number of initiation ext.
Re: DIP 50 - AST macros
On Mon, Nov 11, 2013 at 2:21 AM, Jacob Carlborg d...@me.com wrote: On 2013-11-11 11:10, Timothee Cour wrote: I would really like to use AST macros for the following use case: myAssert( x y); //will print, on failure, a message, along with all values appearing inside macro myAssert: xy failed: x=..., y=... myAssert( fun(x,y)==z1+z2) //likewise, but nesting down to all individual variables appearing inside the macro: x=..., y=..., fun(x,y)=..., z1=..., z2=..., bar(z1+z2)=... This would advantageously replace the plethora of unittest helpers found in other languages, eg: CHECK_EQ, CHECK_LEQ, etc. Invaluable for debugging or informative unittests and logs. Agree. That's the first example in the DIP. Although a very simplified version. yes, I think your initial example becomes more interesting with this, as in its current form it can already be done in current D. This would make error messages self-documenting: myAssert(!file.exists ); // !file. exists failed: dump of AST: file: string =foobar.d |_file.exists: bool = false |_!file. exists: bool = false In many cases, this would be so much more useful than an out of date / incomplete string error message, esp w a lot of variables involved.
Re: DIP 50 - AST macros
On 2013-11-11 11:28, Rikki Cattermole wrote: I can understand wanting to have a high level version of it in context. I'm just considering a high reuse language feature that could back it. Really it should have been added a while ago given the static assert trick is used a bit. I do actually like the idea of having the ability to call it on context with a bunch of extra information given to it for you. e.g. line number of initiation ext. I think we want to have as much as possible of this collected in the same place. I don't think pragmas are a good fit for this. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:47:37 UTC, Jacob Carlborg wrote: On 2013-11-11 11:28, Rikki Cattermole wrote: I can understand wanting to have a high level version of it in context. I'm just considering a high reuse language feature that could back it. Really it should have been added a while ago given the static assert trick is used a bit. I do actually like the idea of having the ability to call it on context with a bunch of extra information given to it for you. e.g. line number of initiation ext. I think we want to have as much as possible of this collected in the same place. I don't think pragmas are a good fit for this. Yes I do agree with that. I'm just more worried about what backs it then pleasantries that we can give the developer. Also if you're not looking towards pragma's to hook into stopping compilation what are your ideas and thoughts around this issue? Because at this point I only know of static assert to do it.
Re: DIP 50 - AST macros
On 2013-11-11 11:39, Timothee Cour wrote: yes, I think your initial example becomes more interesting with this, as in its current form it can already be done in current D. The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D This would make error messages self-documenting: myAssert(!file.exists ); // !file. exists failed: dump of AST: file: string =foobar.d |_file.exists: bool = false |_!file. exists: bool = false In many cases, this would be so much more useful than an out of date / incomplete string error message, esp w a lot of variables involved. I agree. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:55:23 UTC, Jacob Carlborg wrote: The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D I made a suggestion regarding a macro able to get scoped variables from initiation point with Linq. And why that would be a good thing. This is another use case for it. Perhaps add it as a use case for having that feature on the DIP?
Re: DIP 50 - AST macros
On 2013-11-11 11:51, Rikki Cattermole wrote: Yes I do agree with that. I'm just more worried about what backs it then pleasantries that we can give the developer. Also if you're not looking towards pragma's to hook into stopping compilation what are your ideas and thoughts around this issue? Because at this point I only know of static assert to do it. A function call on the context parameter as I've already showed. This would just call error which is already implemented in the compiler. Although I don't know how to actually do the connection between the compiler internals the user code. I think this is one of the big challenges with this DIP. For this function I guess it could be done like an intrinsic (is that the correct word?). -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 10:59:28 UTC, Jacob Carlborg wrote: A function call on the context parameter as I've already showed. This would just call error which is already implemented in the compiler. Although I don't know how to actually do the connection between the compiler internals the user code. I think this is one of the big challenges with this DIP. For this function I guess it could be done like an intrinsic (is that the correct word?). Ok pragmas essentially call functions like error in the compiler [0]. What I am thinking error will do is instead of outputting like msg it'll call error[1]. This is exactly what you want. [0] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2862 [1] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2957
Re: DIP 50 - AST macros
On 2013-11-11 11:58, Rikki Cattermole wrote: I made a suggestion regarding a macro able to get scoped variables from initiation point with Linq. And why that would be a good thing. This is another use case for it. Perhaps add it as a use case for having that feature on the DIP? I already have an example with the assert (not among the use cases but at the top). Or were you referring to something else? -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Mon, Nov 11, 2013 at 2:55 AM, Jacob Carlborg d...@me.com wrote: On 2013-11-11 11:39, Timothee Cour wrote: yes, I think your initial example becomes more interesting with this, as in its current form it can already be done in current D. The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D I'm using a modified assert that uses the ugly import(file)[line] trick, so that can be done (but is really ugly and has impact either runtime or compile time). But we're essentially in agreement. This would make error messages self-documenting: myAssert(!file.exists ); // !file. exists failed: dump of AST: file: string =foobar.d |_file.exists: bool = false |_!file. exists: bool = false In many cases, this would be so much more useful than an out of date / incomplete string error message, esp w a lot of variables involved. I agree. -- /Jacob Carlborg
Re: AA literals/initialisation
On 11 November 2013 20:14, Daniel Kozak kozz...@gmail.com wrote: On Monday, 11 November 2013 at 10:13:02 UTC, Daniel Kozak wrote: On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote: On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? And even this works ok: immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; Ohh, but non works on module scope, so yes, it would be fine to fix this but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;)
Re: curl
On Monday, 11 November 2013 at 09:53:38 UTC, Manu wrote: First-chance exception: std.net.curl.CurlException Peer certificate cannot be authenticated with given CA certificates on handle 8C5090 at std\net\curl.d(3504) And why does curl crash when it encounters HTTPS anyway? https://d.puremagic.com/issues/show_bug.cgi?id=9737 SSL usage example: - auto http = HTTP(); // Set the CA certificate bundle file to use for SSL peer verification // To dowload this file (or generate it yourself) see http://curl.haxx.se/docs/caextract.html // For more information about SSL peer verification see http://curl.haxx.se/docs/sslcerts.html http.caInfo(cacert.pem); auto resp = get(https://google.com;, http);
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 11:01:41 UTC, Jacob Carlborg wrote:
I already have an example with the assert (not among the use
cases but at the top). Or were you referring to something else?
I was referring to the use case as to why we should have the
ability to get scoped variables from the initiation point.
Example:
void func(int i) {
bool b;
macr {}
}
macro foo (Context context, Ast!(string) str)
{
writeln(context.scopeVariables!int(i));
writeln(context.scopeVariables!bool(b));
return ;
}
Re: AA literals/initialisation
Manu turkey...@gmail.com wrote in message news:mailman.355.1384158631.9546.digitalmar...@puremagic.com... immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? I think yes, it can be done for 2.065. Someone remind me if we get close and it isn't done yet.
Re: DIP 50 - AST macros
11-Nov-2013 01:20, Jacob Carlborg пишет: I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is: http://wiki.dlang.org/DIP50 I have to say I like it. I find it nice that it would allow one to finally ensure that inlining is always done by making critical primitives macros instead of functions. This is vastly superior compared to the _only_ current option of generating unrolled code with string mixins. I'd call attribute macros - declaration macros in line with statement macros, then describe how they look - a lot like attributes. Things to note though: - Can't implement scope(exit/success/failure) because that would need to capture the outer scope to pack it into try/catch/finally. - Can't implement foreach if only because of the syntax of the latter. - There is no definition of Ast!(T) construct - I take it's a struct or a class of sorts and the whole thing works with the CTFE engine. Then it also needs specification of Statements, Declarations. - It seems like I can use AST literal in R-T code as well? That would be useful but only if some library actually accepted these AST nodes. -- Dmitry Olshansky
Re: AA literals/initialisation
11-Nov-2013 15:06, Manu пишет: but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;) ... copy pastes that literal everywhere, I'm sure you'll like it ;) -- Dmitry Olshansky
Re: AA literals/initialisation
On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky wrote: 11-Nov-2013 15:06, Manu пишет: but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;) ... copy pastes that literal everywhere, I'm sure you'll like it ;) Yes, it is perfect :D
Re: AA literals/initialisation
On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky wrote: 11-Nov-2013 15:06, Manu пишет: but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;) ... copy pastes that literal everywhere, I'm sure you'll like it ;) Will it be copied even if you just use it (1 in priorityMap), or only if you pass it around as a parameter or assign it to variables?
Re: AA literals/initialisation
11-Nov-2013 15:55, simendsjo пишет: On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky wrote: 11-Nov-2013 15:06, Manu пишет: but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;) ... copy pastes that literal everywhere, I'm sure you'll like it ;) Will it be copied even if you just use it (1 in priorityMap), or only if you pass it around as a parameter or assign it to variables? It will do whatever it does when written as literal by hand. And it's nothing clever still, last time I checked - allocation, everywhere. -- Dmitry Olshansky
Re: AA literals/initialisation
On Monday, November 11, 2013 12:55:09 simendsjo wrote: On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky wrote: 11-Nov-2013 15:06, Manu пишет: but enum works fine: enum priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; So it does... I didn't think of an enum AA ;) ... copy pastes that literal everywhere, I'm sure you'll like it ;) Will it be copied even if you just use it (1 in priorityMap), or only if you pass it around as a parameter or assign it to variables? Every time you use an enum, it's replaced with its value. So, if an enum is an AA, then that literal is copy-pasted everywhere that the enum is used. So, it would almost certainly be foolish to use it anywhere other than to assign to a variable (and then all of the operations are done on the variable). Really, having an enum that's an AA is almost certainly a foolish thing to do. It's one case where the behavior of enums doesn't help and definitely hurts. - Jonathan M Davis
Re: DIP 50 - AST macros
Am Sun, 10 Nov 2013 22:20:30 +0100 schrieb Jacob Carlborg d...@me.com: I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is: http://wiki.dlang.org/DIP50 Wow, some topics really explode recently. Is the D user base growing or are AST macros drawing so much attention? -- Marco
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 12:13:54 UTC, Marco Leise wrote: Wow, some topics really explode recently. Is the D user base growing or are AST macros drawing so much attention? I'd like to say both. AST macros are one of those few things that I wouldn't mind seeing breaking changes for and I'm in the camp of avoid breaking changes at all cost. AST macros are to code what templates are to data. Despite it being possible to go without templates, I'm not at all tempted to switch to Go.
Re: DIP 50 - AST macros
On 2013-11-11 12:04, Rikki Cattermole wrote: Ok pragmas essentially call functions like error in the compiler [0]. What I am thinking error will do is instead of outputting like msg it'll call error[1]. This is exactly what you want. [0] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2862 [1] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2957 Yes, I still don't understand why you would want it as a pragma. Be usable outside of macros? -- /Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 12:08, Rikki Cattermole wrote:
I was referring to the use case as to why we should have the ability to
get scoped variables from the initiation point.
Example:
void func(int i) {
bool b;
macr {}
}
macro foo (Context context, Ast!(string) str)
{
writeln(context.scopeVariables!int(i));
writeln(context.scopeVariables!bool(b));
return ;
}
Ok, I see. Please add additional examples to the DIP if you think it's
missing.
--
/Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 12:06, Timothee Cour wrote: I'm using a modified assert that uses the ugly import(file)[line] trick, so that can be done (but is really ugly and has impact either runtime or compile time). But we're essentially in agreement. Right, that ugly trick :) -- /Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 12:30:07 UTC, Jacob Carlborg wrote: Yes, I still don't understand why you would want it as a pragma. Be usable outside of macros? Yes outside of macros would be useful. For example code like this would become redundant: pragma(msg, Support for x is not implemented on platform y); static assert(0); Becoming: pragma(error, Support for x is not implemented on platform y); Also pragma's core responsibility is to cause the compiler to do something. In this case to say we hit an error during compilation please tell the user/dev and die. It is a hook to the compilers workings. Currently working on getting this implemented. Nearly done with it. Just got some extra spaces that shouldn't be in output.
Re: AA literals/initialisation
enum - compile time constant immutable - run time constant thread about it was somewhere here
Re: curl
Okay, I have something working. Pretty annoying process though. This could really do with some solid documentation + examples by someone who knows what they're talking about. I'd like to think get(url) should be really easy, and shouldn't waste hours of someone's time to understand and call. On 11 November 2013 21:06, Tavi Cacina octavian.cac...@outlook.com wrote: On Monday, 11 November 2013 at 09:53:38 UTC, Manu wrote: First-chance exception: std.net.curl.CurlException Peer certificate cannot be authenticated with given CA certificates on handle 8C5090 at std\net\curl.d(3504) And why does curl crash when it encounters HTTPS anyway? https://d.puremagic.com/issues/show_bug.cgi?id=9737 SSL usage example: - auto http = HTTP(); // Set the CA certificate bundle file to use for SSL peer verification // To dowload this file (or generate it yourself) see http://curl.haxx.se/docs/caextract.html // For more information about SSL peer verification see http://curl.haxx.se/docs/sslcerts.html http.caInfo(cacert.pem); auto resp = get(https://google.com;, http);
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
I will definitely back up this project on kickstarter, if the mentioned Java backend is going to be somewhere at the top priorities. Being able to target JVM is extremely important to me. Before you do the kickstarter please make a list of features that you plan to be in XDC after the release, and when do you plan the release to happen.
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 01:49:45 UTC, Timothee Cour wrote: People have shunned proposals to have @mixin functions because it wouldn't be obvious at call site that some statement is executed under a mixin (which could access all variables in scope etc). The same will happen here; I think it should be clear at call site that a macro is used. How about: macro!myAssert(1 + 2 == 4); instead of myAssert(1 + 2 == 4); If macros are supposed to access outer scope, I agree, this is a necessary restriction.
Re: DIP 50 - AST macros
On 2013-11-11 12:34, Dmitry Olshansky wrote:
I have to say I like it.
Cool :)
I find it nice that it would allow one to finally ensure that inlining
is always done by making critical primitives macros instead of
functions. This is vastly superior compared to the _only_ current option
of generating unrolled code with string mixins.
I'd call attribute macros - declaration macros in line with statement
macros, then describe how they look - a lot like attributes.
Ok, I can change that.
Things to note though:
- Can't implement scope(exit/success/failure) because that would need
to capture the outer scope to pack it into try/catch/finally.
Right. scope(exit) could perhaps be implement with a custom struct and
calling a block in the destructor.
- Can't implement foreach if only because of the syntax of the latter.
I would think something like this:
macro foreach (T) (Context context, Ast!(Symbol) var, Ast!(T)
collection, Statement block)
{
if (isRange(collection))
{
return [
for (auto __r = $collection; !__r.empty; __r.popFront())
{
auto $var = __r.front;
block;
}
];
}
else if (hasOpApply(collection))
{
...
}
else ...
}
Perhaps not all of the existing syntax can fit in a macro.
- There is no definition of Ast!(T) construct - I take it's a struct
or a class of sorts and the whole thing works with the CTFE engine. Then
it also needs specification of Statements, Declarations.
Yes, something like that. I don't know exactly how the Ast type need to
look like. See one of my replies to bearophile:
http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com
- It seems like I can use AST literal in R-T code as well? That would
be useful but only if some library actually accepted these AST nodes.
Actually, I haven't thought about this. I think my original idea was
that [ ] should only work inside macros. But that it would be possible
to pass Ast nodes to other functions.
--
/Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 13:13, Marco Leise wrote: Wow, some topics really explode recently. Is the D user base growing or are AST macros drawing so much attention? AST macros are drawing so much attension. For some, it's like the holy grail. -- /Jacob Carlborg
Re: Thoughts about D package management on Gentoo
On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote: Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for eselect dlang. To clarify, gcc-config copies the executables from /usr/x86_64-pc-linux-gnu/gcc-bin/version/* to /usr/bin/* I guess I should just stick to DMD and LDC for it then? By the way dc is already the name of an arbitrary precision expression evaluator and cannot be used for a symlink to the D compiler of choice. :p I ignore gcc-config for GDC and explicitly maintain list of files to install and their target locations (it is very short). Not very gcc-ish but more allows more consistent deployment between different D compilers.
Re: DIP 50 - AST macros
On 2013-11-11 13:36, Rikki Cattermole wrote: Yes outside of macros would be useful. For example code like this would become redundant: pragma(msg, Support for x is not implemented on platform y); static assert(0); Becoming: pragma(error, Support for x is not implemented on platform y); Also pragma's core responsibility is to cause the compiler to do something. In this case to say we hit an error during compilation please tell the user/dev and die. It is a hook to the compilers workings. Currently working on getting this implemented. Nearly done with it. Just got some extra spaces that shouldn't be in output. I just don't want to add a bunch of pragmas. I don't know what's the best solution. -- /Jacob Carlborg
Re: DIP 50 - AST macros
Am 11.11.2013 13:36, schrieb Rikki Cattermole: On Monday, 11 November 2013 at 12:30:07 UTC, Jacob Carlborg wrote: Yes, I still don't understand why you would want it as a pragma. Be usable outside of macros? Yes outside of macros would be useful. For example code like this would become redundant: pragma(msg, Support for x is not implemented on platform y); static assert(0); Becoming: pragma(error, Support for x is not implemented on platform y); Also pragma's core responsibility is to cause the compiler to do something. In this case to say we hit an error during compilation please tell the user/dev and die. It is a hook to the compilers workings. Currently working on getting this implemented. Nearly done with it. Just got some extra spaces that shouldn't be in output. but in macros the context information is much more interesting then anything else - so #pragma(error,...) won't fully fit the needs to context error returning - it could be much more then just a message example: to help the compiler forming better error messages - or maybe recover from deep macro expansion etc...) what you want is just #pragma(error,...) - break compiliation now Jacob is talking about the feedback for the compiler thing...
Re: Thoughts about D package management on Gentoo
On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote: True. This why I have them all in a single PKGBUILD (ebuild analog I guess) despite those looking separate in package manager. So a single PKGBUILD can advertise multiple items to install? And when you later install more from the same package you just run the PKGBUILD again and it reinstalls everything plus the new options? `PKGBUILD` in Arch Linux is simply a standard package building script, essentially a bash script with metadata. It is not a package on its own, in is used to create ones. It is convenient for maintenance to generate packages with a shared/related built process from a single PKGBUILD. This, for example, is the one for dmd stack : https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/dmd/PKGBUILD AFAIK no one uses D1 but company I am working for :P Yeah, and they hopefully don't use Gentoo... maybe it is time to drop that version if it causes trouble. I'll try to have at least an dmd-1.076 ebuild though. It is also a good test for the whole multiple versions at once idea. Well, wish you good best luck with it :) I don't have any plans to support it in main repositories (actually, other TU's would have yelled at me even if I did as it is against Arch design :P) Too many smilies, hehe. Well, it should be possible to have at least one installable version of every package at any time. Unless that package hasn't been updated for 10 months or so. I don't want to run into a situation where you can't update dmd because some application isn't updated or where I do update dmd early and D programs can't be installed any longer until they work with that latest version of D. If such package is a stand-alone application and does not seem to be maintained for some time it can be adjusted to use DVM to retrieve older version specifically to build itself. Not very convenient, but won't at least pollute the system with dozens of different compiler/phobos versions.
Re: DIP 50 - AST macros
On Sunday, 10 November 2013 at 21:20:34 UTC, Jacob Carlborg wrote: I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is: http://wiki.dlang.org/DIP50 I don't have time to investigate this in details but I'd like to mention that this is one of few possible new features where ROI is really worth it. It removes lot of burden from core language and allows to replace some very arcane template hacks with cleaner code. I'd say it is a bit too early to go for it (really, we need at least to figure out how to make releases without issues first :)) but it is a good future goal even in context of general feature freezing.
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 13:16:23 UTC, Jacob Carlborg wrote:
I just don't want to add a bunch of pragmas. I don't know
what's the best solution.
I am only suggesting one :)
We only need one that'll output any text we want it to and make
the compiler consider it an error.
On the macro side of things we can build a string which then can
be given to the pragma.
All of the wrapping giving the goodness would go into the context.
Current what I have enables this:
void main() {
U u;
}
alias T!(hi, bye) U;
struct T(string a, string b) {
pragma(error, a ~ \n ~ b);
}
test.d(8): Error: hi
bye
test.d(5): Error: template instance test.T!(hi, bye) error
instantiating
Not really in pull state but thats the best I can do. Really that
final error should be omitted.
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 13:22:34 UTC, dennis luehring wrote: example: to help the compiler forming better error messages - or maybe recover from deep macro expansion etc...) what you want is just #pragma(error,...) - break compiliation now Jacob is talking about the feedback for the compiler thing... Jacob mentioned originally he wanted to create a compiler error. Or at least thats is how I took it. Hence pragma(error, text); We can already message out at both compile and runtime its simply does the compiler recognise it as an error part.
Re: DIP 50 - AST macros
On 2013-11-11 14:32, Rikki Cattermole wrote:
I am only suggesting one :)
What about warnings? And no, the current pragma(msg) isn't the same.
We only need one that'll output any text we want it to and make the
compiler consider it an error.
On the macro side of things we can build a string which then can be
given to the pragma.
All of the wrapping giving the goodness would go into the context.
Current what I have enables this:
void main() {
U u;
}
alias T!(hi, bye) U;
struct T(string a, string b) {
pragma(error, a ~ \n ~ b);
}
test.d(8): Error: hi
bye
test.d(5): Error: template instance test.T!(hi, bye) error
instantiating
Not really in pull state but thats the best I can do. Really that final
error should be omitted.
I wouldn't say no to this if macros are completely off the table.
Perhaps it's a good addition regardless.
--
/Jacob Carlborg
Re: DIP 50 - AST macros
On Monday, 11 November 2013 at 13:36:14 UTC, Jacob Carlborg wrote: What about warnings? And no, the current pragma(msg) isn't the same. I'm not doing one for warnings. See how the error one goes. The warning one won't stop compilation and pragma msg can be used to fake it. I wouldn't say no to this if macros are completely off the table. Perhaps it's a good addition regardless. Personally I think it was already needed even without macros. Just this has started me off on actually looking into it. We'll see what the compiler devs think though.
Re: Thoughts about D package management on Gentoo
On 11 November 2013 13:14, Dicebot pub...@dicebot.lv wrote: On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote: Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for eselect dlang. To clarify, gcc-config copies the executables from /usr/x86_64-pc-linux-gnu/gcc-bin/version/* to /usr/bin/* I guess I should just stick to DMD and LDC for it then? By the way dc is already the name of an arbitrary precision expression evaluator and cannot be used for a symlink to the D compiler of choice. :p I ignore gcc-config for GDC and explicitly maintain list of files to install and their target locations (it is very short). Not very gcc-ish but more allows more consistent deployment between different D compilers. What do you define as being a consistent deployment ? -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Thoughts about D package management on Gentoo
On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote: Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for eselect dlang. To clarify, gcc-config copies the executables from /usr/x86_64-pc-linux-gnu/gcc-bin/version/* to /usr/bin/* I guess I should just stick to DMD and LDC for it then? By the way dc is already the name of an arbitrary precision expression evaluator and cannot be used for a symlink to the D compiler of choice. :p On this point, it may be time to get on Freenode and hit up #gentoo-dev-help and see what they say. Off the top of my head, EAPI 2 introduced USE deps, so you may be able to get away with specifying sys-devel/gcc[d] as fulfilling your virtual. As far as eselect goes, I would use that only for fixing up the environment and the paths in sc.ini (and the primary compiler symlink, if you choose to go that route). I'm not familiar with the guts of it, but from what I've been told, an eselect module for gcc has been tried several times, but has always met unfortunate circumstances. -Wyatt
Re: Thoughts about D package management on Gentoo
On Monday, 11 November 2013 at 13:45:10 UTC, Iain Buclaw wrote: What do you define as being a consistent deployment ? Similar path patterns for binaries, standard libraries and import modules. Similar compilation defaults. Use of FE version as primary one (GDC is especially useless here as its native version is tied to GCC version and says nothing about supported language).
Re: DIP 50 - AST macros
On 2013-11-11 14:36, Rikki Cattermole wrote: Jacob mentioned originally he wanted to create a compiler error. Or at least thats is how I took it. Hence pragma(error, text); We can already message out at both compile and runtime its simply does the compiler recognise it as an error part. error would be just a single function that is available in the context parameter. There would be many others. From the DIP: * The arguments used when the compiler was invoked * Functions for emitting messages of various verbosity level, like error, warning and info * Functions for querying various types of settings/options, like which versions are defined, is debug or release defined and so on * In general providing as much as possible of what the compiler knows about the compile run * The context should have an associative array with references to all scoped variables at initiation point. -- /Jacob Carlborg
Re: DIP 50 - AST macros
On 2013-11-11 14:40, Rikki Cattermole wrote: I'm not doing one for warnings. See how the error one goes. The warning one won't stop compilation and pragma msg can be used to fake it. Yes, but I want warnings to be available in the context parameter as well. That's what I've been talking about all along. It's not just errors, it's all of the stuff that can be added. Warnings can be turned off, pragma(msg) cannot (at least not as far as I know). Personally I think it was already needed even without macros. Just this has started me off on actually looking into it. We'll see what the compiler devs think though. I see. I'm not saying that we don't need it. -- /Jacob Carlborg
