Re: AST like coding syntax. Easy upgrade!
On 07-Sep-2015 08:25, anonymous wrote: On Monday 07 September 2015 02:24, Idan Arye wrote: That's not considered as syntax check - that's an earlier stage of the compilation process called "lexical analysis"(https://en.wikipedia.org/wiki/Lexical_analysis) From the Wikipedia article: "a lexer is generally combined with a parser, which together analyze the syntax". No in this case obviously. -- Dmitry Olshansky
Re: Benchmarking suite
On Sunday, 30 August 2015 at 13:21:42 UTC, qznc wrote: On Saturday, 29 August 2015 at 19:17:47 UTC, Dmitry Olshansky wrote: On 29-Aug-2015 21:14, qznc wrote: On Saturday, 29 August 2015 at 12:35:14 UTC, Dmitry Olshansky wrote: Well, here is the regex-dna one with 3 versions including C-T regex: https://github.com/DmitryOlshansky/FReD/blob/master/bench/regex-dna/d_dna.d Thanks Dmitry! Which version should be used? I'd try all of them, I think C-T was the fastest (as it should). Yes, C-T is fastest. Even dmd is faster than C/C++ now. :) Unfortunately, I have to take that back. C is faster than D even with compile-time regexes. I used the short running benchmarks first, where compile-time regex wins, probably because it saves some startup time. For large data, C is faster. It uses the regex engine from TCL. Maybe std.regex has just space for optimization? I updated the benchmark results: https://qznc.github.io/d-shootout/
Re: Benchmarking suite
On 07-Sep-2015 11:29, qznc wrote: Maybe std.regex has just space for optimization? Sure thing, see WIP here (~25% faster but not yet complete): https://github.com/D-Programming-Language/phobos/pull/3314 -- Dmitry Olshansky
Re: Benchmarking suite
On Monday, 7 September 2015 at 08:33:33 UTC, Dmitry Olshansky wrote: On 07-Sep-2015 11:29, qznc wrote: Maybe std.regex has just space for optimization? Sure thing, see WIP here (~25% faster but not yet complete): https://github.com/D-Programming-Language/phobos/pull/3314 Could anybody add C# version of examples?
Re: Behavior of opEquals
On 09/05/2015 08:18 AM, Jonathan M Davis wrote: On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote: On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote: Wait, wait, did I miss something? Since when was operator overloading allowed as free functions? Since UFCS, but DMD does not implement it. There is nothing in the spec about supporting operator overloading with free functions, so I don't know where you get the idea that it's even intended to be a feature. UFCS applies to functions which use the member function call syntax, and operators aren't used that way. Specifying semantics via lowering is somewhat pointless if rewrites are not transitive. There is no plan whatsoever to support operator overloading via free functions. ... Then specify operator overloading using __traits(getMember,...). (I consider this unwise though.)
Re: AST like coding syntax. Easy upgrade!
On Monday, 7 September 2015 at 02:50:06 UTC, Adam D. Ruppe wrote: On Sunday, 6 September 2015 at 23:33:17 UTC, Walter Bright wrote: I'd always thought Javascript was an ideal extension language for a text editor. Well, I don't think *ideal*, but indeed, it wouldn't be bad. C'mon, kind sirs! Haven't you heard anything about Emacs Lisp? =)
Re: dmd codegen improvements
On 2015-09-06 15:24, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= wrote: Oh, actually it appears to run on both OS-X and Linux. I didn't know that. Looks very promising, thanks! Yeah, it's built on the same framework as Atom. Or were you hoping for Visual Studio, sans Code, on OS X and Linux? -- /Jacob Carlborg
Re: AST like coding syntax. Easy upgrade!
On 2015-09-06 21:32, Prudence wrote:
template X(Y)
{
string X = Y.stringof;
}
auto s = X({int 3;})
Of course, doesn't work!!
You might be interested in this [1].
[1] http://wiki.dlang.org/DIP50
--
/Jacob Carlborg
Re: dmd codegen improvements
On Monday, 7 September 2015 at 13:41:31 UTC, Jacob Carlborg wrote: On 2015-09-06 15:24, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= wrote: Oh, actually it appears to run on both OS-X and Linux. I didn't know that. Looks very promising, thanks! Yeah, it's built on the same framework as Atom. Or were you hoping for Visual Studio, sans Code, on OS X and Linux? I knew there was an Atom based type script editor (or several?), but didn't know that Microsoft was behind it and that "VS Code" was different from "VS"/"VS Express" ;). Typescript seems to have a lot of momentum. I'm thinking about the possibility of a transpiler TypeScript->D (and other languages).
A collection of DIPs
https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy!
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... Thanks for taking the time to write up your ideas. There has been much discussion on the GC in the past and I agree that a GC-tracking mechanism that can enable precise scanning is needed, but to get that level of speed you need some of the mechanisms in Rust. 1. You need to make sure that pointers to the interior of a GC object are not live when the last pointer to the start of the GC objects disappears. 2. You need to annotate C functions that take pointers with a guarantee that they don't hold on to references through that pointer. Or simply ban C functions from taking GC memory. What do you think?
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:52:21 UTC, Ola Fosheim Grøstad wrote: On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... Thanks for taking the time to write up your ideas. There has been much discussion on the GC in the past and I agree that a GC-tracking mechanism that can enable precise scanning is needed, but to get that level of speed you need some of the mechanisms in Rust. precise GC scanning could be enabled easily if the allocation calls were templates instead of raw C function. RTInfo is just a hack(IMO,) and pretty much ignoring one of the areas D excels in.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:52:21 UTC, Ola Fosheim Grøstad wrote: 1. You need to make sure that pointers to the interior of a GC object are not live when the last pointer to the start of the GC objects disappears. 2. You need to annotate C functions that take pointers with a guarantee that they don't hold on to references through that pointer. Or simply ban C functions from taking GC memory. 3. You need give up on destructors for GC objects too, and not allow them to own heap allocated objects. A reasonable restriction IMHO.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy! OK, here are a few comments on what i agree with or not. The other point simply don't interest me. ## Managed, unmanaged, something between? - pointers You can already create, allocate new class, struct and union instances that are not known by the GC. This is not well known because I've explained this several time on several boards to several people. So this proposal is simply consequence of a lack of knowledge. But, even if... using the '^' symbol, would be bad since it's already used to xor. ## Why need alias this while we have opCast? an "alias this" expression doesn't require to cast. Maybe you don't really see "alias this" as it is widely used: - custom type. - composition. So your proposal to use cast is pointless. ## InExpression is meaningless No it doesn't. :) ## ?? operator Yes, the 'Null coalescing operator' would be great. ## Templates should use exclamation! No, you can clearly differentiate declaration from instantiation thanks to the current syntax. ## friend classes You can put the classes in different modules and then 'private' and 'protected' are sufficient to get something like friend classes.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Destroy! Yea ill admit, i came from C# and i hate underscores. I prefer PascalCase above anything.
Re: A collection of DIPs
On Monday, 7 September 2015 at 15:34:21 UTC, BBasile wrote: You can already create, allocate new class, struct and union instances that are not known by the GC. This is not well known because I've explained this several time on several boards to several people. So this proposal is simply consequence of a lack of knowledge. You have to scan all memory that MAY contain a pointer to a reference chain that contains a pointer to GC heap. That's a lot of cache lines to scan over on today's computers that soon have terrabytes of memory.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
https://github.com/NightmareX1337/DX
Don't kill me, I'm just trying to help...
You can report issues and create pull requests :)
Destroy!
Hi NX,
Thanks for the document. A lot of what you say about UDA and
compile time reflection is absolutely true. We should fix it so
it isn't so darn convoluted.
w/ regards to __traits() those are call outs to the compiler and
generally should not be used directly. Thus std.traits, and why
they're prefixed with __. Unfortunately, the current state of
compile time reflection requires that you must use __traits
directly (at least, I've had to)
However, I can't agree with you about alias this, UFCS, or global
functions in phobos. The "idiomatic" way to code in D is use
local named imports. e.g.:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy! - Your point against undisciplined UFCS: Completely agree. I'm writing a 'DIP' that I'm probably never gonna submit to add "extension interfaces" (my syntax ATM is leaning towards "alias class/interface") that add callable-with-method-syntax free functions in a way that they're treated as native parts of the supporting type (one case: when passing the type name into a foreign template they're picked up as if they were methods instead of being out-of-scope). In a (very big) way, they're stolen whole-sale and are being adopted to fit from Rust's traits. - Null-coalescing operator: No. Pattern matching and a `std.typecons.Option(T)` would do better IMHO and are more general. - I've stayed away from UDAs but your points make me finally want to stay away a bit more. (except for a small side project but, well, necessities) - Managed~unManaged pointers: needlessly complicated. Just provide a non-GC 'new'. What wouldn't that solve as well as your `type*` vs `type^` pointers? (btw, `^` wouldn't conflict with the xor-operator as I understand it. `!` is already used both as a unary prefix and binary infix operator). - Not sure about `alias this`/`opCast`. I just use `opDispatch` whenever I need something more complicated than alias this (not much at all). - I VERY strongly believe in the inherent superiority of kebab-case compared to CamelCase and snake_case. KEBAB-CASE FOR PRESIDENT! - I hated D's module system at first. I still hate that I have to create separate files just to have a small internal namespace-separation. But I like being able to just go find something in a file in a project based on its compile-time path (granted, good design should enforce this but...). I dunno; on a fence about it. - `__traits(callerName) & __traits(callerChain) & __traits(callerPath)`: I want a `__traits(instanceContext, symbol)` that returns an alias allowing me to access all compile-time info on surrounding symbols to the passed one (which are local to the /instance/ so include imported names and local types and such). That would solve SO MANY THINGS with template adventures. Not sure on what it'd make worse, though. - Partial lock for arrays: Sounds complicated for D's current analysis abilities. But sounds cool. - pragma(inline): ABSOLUTELY. The idea that `pragma(inline)` verbatim tells the compiler precisely nothing hurts my OCD so much. - Old attributes got a space in the keyword list. There were proposals to shift them all to `@` syntax but it stalled early on. - Runtime reflection: Hmmm... Runtime UDA's sound suspiciously like a type-state system. Complicated, interesting. - Templates are obvious enough as they are IMHO. - Friend classes: Um, maybe make a separate MyTypeImpl struct/class that takes a MyType instance and initializes itself with a pointer and through it you can access all the private stuff you want? (MyTypeImpl would be in the same module as MyType, of course.) Good stuff ;)
Re: A collection of DIPs
On 09/07/2015 08:55 PM, Enamex wrote: - Templates are obvious enough as they are IMHO. It's also obvious that declaration syntax mimicking use syntax would be superior.
Re: A collection of DIPs
> void main()
> {
> std.stdio.writeln("Hello world!"); // Error: undefined identifier 'std'
> }
struct Mod(string B="") {
template opDispatch(string M) {
static if (__traits(compiles, { mixin(`import `~B~"."~M~`;`); }))
mixin(`import opDispatch = `~B~"."~M~`;`);
else
alias opDispatch = Mod!((B!=""?B~".":"")~M);
}
}
alias mod = Mod!"";
alias std = mod.std;
// Could also place above declarations in "object.d".
void main() {
std.stdio.writeln("Hello world!");
mod.core.stdc.stdio.printf("%d\n", 42);
}
SCNR
artur
Re: A collection of DIPs
On Monday, 7 September 2015 at 16:10:31 UTC, Israel wrote: On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Destroy! Yea ill admit, i came from C# and i hate underscores. I prefer PascalCase above anything. 3 of the keys in my keychain are of the same brand, so they are shaped pretty much the same. The pin arrangement is different, of course, but they all have similar blades of the same height and width, and plastic-cased bows of the same rectangular shape. The orange key opens the front door. The yellow key opens the back door. The blue key opens the old bicycle storage room. I prefer the looks of the blue key. The shape is the same, but the color does make a difference - the orange and yellow ones look kinda toyish - the colors "scream" too hard. The blue one looks professional - as much as a key can look professional. Still, I wouldn't want them all to be blue Because then I wouldn't be able to tell the freaking difference! Maybe you think PascalCase is the best case. Maybe you are right, and there is an objectively "best" case, which is better than all the rest. It doesn't matter - the problem is not which single case you choose to rule them all, but that you insist on choosing one and making the convention to use only it for everything you define. At the very least, the convention should specify two cases - for types and for variables(=fields/arguments/scoped variables) - because you want to be able to name variables after their types. This might be considered a bad practice for the built-in types, but with user defined types you can usually get the type specific enough and the scope small enough for this to be the natural choice. The C# standard library is filled with member fields named after their types, and since both type and field use PascalCase, they had to use separate namespaces for types and variables. Now, for a language that has context sensitive keywords having context-sensitive identifier namespaces is not that weird - but I really don't want to see this misfeature in D...
template UDA
Currently this will compile
Note:
-no type is supplied to @MyAttribute
-"instantiated" will not be printed
struct MyAttribute(T) {
pragma(msg, "instantiated");
}
@MyAttribute class SomeClass { }
void main(string[] args) {
A a = new A();
}
Is there any real(and plausible) use case where providing a
template with no argument as a UDA would be useful?
If not, could the above usage be made to instantiate MyAttribute
using the type of whatever it's applied to?
So in the above example, MyAttribute would be(or attempted to be)
instantiated with type 'SomeClass'.
Currently, you can achieve this(annoyingly and redundantly) like
this:
@MyAttribute!SomeClass class SomeClass { }
So if there is no valid usage for untyped template UDA's, can D
be made to act as I am proposing?
Re: template UDA
On Monday, 7 September 2015 at 22:00:07 UTC, bitwise wrote:
Is there any real(and plausible) use case where providing a
template with no argument as a UDA would be useful?
Yes, you actually wrote it yourself!
@MyAttribute!SomeClass class SomeClass { }
That right there is a reason. When you are looking for UDAs, you
look for declarations. The usage code looks like:
foreach(member; getMembers!module)
if(member.hasUDA!(MyAttribute)) {
// do something
}
The beauty of it is that member is right there! So your
reflection code could instantiate it right there:
// do something becomes...
MyAttribute!(member);
so it instantiates the template with the given member in the
reflection code itself.
Re: template UDA
On Monday, 7 September 2015 at 22:03:13 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 22:00:07 UTC, bitwise wrote:
Is there any real(and plausible) use case where providing a
template with no argument as a UDA would be useful?
Yes, you actually wrote it yourself!
@MyAttribute!SomeClass class SomeClass { }
That right there is a reason. When you are looking for UDAs,
you look for declarations. The usage code looks like:
I kinda understand what you're saying, but I still don't think
there is any benefit to tagging something with a template which
has no type. The attribute in the above example doesn't need to
be a template.
I imagine that if I were to search for a template UDA, the next
step would probably be to enumerate the template parameters and
take special action. Otherwise, the type is not needed. I suppose
a template UDA could either have some args, or no args, but I
can't imaging a use case where this would actually happen.
foreach(member; getMembers!module)
if(member.hasUDA!(MyAttribute)) {
// do something
}
The beauty of it is that member is right there! So your
reflection code could instantiate it right there:
// do something becomes...
MyAttribute!(member);
so it instantiates the template with the given member in the
reflection code itself.
My goal is not to have this reflection code at all(the loop which
looks through the module instantiating things). I want the
attribute itself to do that.
Example:
struct Reflection {
string typeName;
string[] members;
static Reflection[string] reflections;
}
struct Reflected(T)
{
static this() {
string[] members;
foreach(memberName; __traits(allMembers, T))
{
members ~= memberName;
}
enum typeName = fullyQualifiedName!T.stringof[1..$-1];
writeln("registering type: " ~ typeName);
Reflection.reflections[typeName] = Reflection(typeName,
members);
}
}
Reflection* reflect(Object obj) {
writeln("retrieving type for: " ~ typeid(obj).toString);
return typeid(obj).toString in Reflection.reflections;
}
@Reflected!A class A {
int x;
float y;
string z;
}
void main(string[] args)
{
A a = new A();
foreach(n; a.reflect.members)
writeln(n);
}
But I would like to have the attribute pick up the type that's
attached.
I saw an example, in another post that went something like this:
struct MyAttribute(T = _UDA_OBJECT_) { }
This would be acceptable too, but for some reason, the response
received almost no attention.
Bit
Re: template UDA
On Monday, 7 September 2015 at 22:03:13 UTC, Adam D. Ruppe wrote: [...] A more useful example: http://dpaste.dzfl.pl/82a3d65be4be
Re: template UDA
On Monday, 7 September 2015 at 22:03:13 UTC, Adam D. Ruppe wrote:
[...]
digging deeper, this very contrived example compiles:
struct S(T) { int x; }
auto fun(alias T, S)(S x) {
return T!S(x);
}
void main(string[] args) {
auto s = fun!S(123);
writeln(s.x);
}
So I suppose the existing behaviour shouldn't really be
considered a bug.
This syntax would sure be nice though:
struct MyAttribute(T = _UDA_TARGET_) { }
When you find a solution to a weird problem, post it!
Some great advice: http://rentes.github.io/programming/stackoverflow/2015/09/03/Wisdom-of-the-Ancients/
Re: A collection of DIPs
On 08/09/15 5:27 AM, Shammah Chancellor wrote:
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
https://github.com/NightmareX1337/DX
Don't kill me, I'm just trying to help...
You can report issues and create pull requests :)
Destroy!
Hi NX,
Thanks for the document. A lot of what you say about UDA and compile
time reflection is absolutely true. We should fix it so it isn't so
darn convoluted.
w/ regards to __traits() those are call outs to the compiler and
generally should not be used directly. Thus std.traits, and why they're
prefixed with __. Unfortunately, the current state of compile time
reflection requires that you must use __traits directly (at least, I've
had to)
However, I can't agree with you about alias this, UFCS, or global
functions in phobos. The "idiomatic" way to code in D is use local
named imports. e.g.:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
It's not just an idiomatic way to code with local imports, it's a
compilation performance technique too.
Re: When you find a solution to a weird problem, post it!
On Tuesday, 8 September 2015 at 02:07:04 UTC, Walter Bright wrote: Some great advice: http://rentes.github.io/programming/stackoverflow/2015/09/03/Wisdom-of-the-Ancients/ Totally agree. Just posted a solution to my own problem: http://forum.dlang.org/thread/ldtjxbyhxclfinkaj...@forum.dlang.org
How To Compile D2SQLite3 on OSX?
LOL, I feel like I need to do one of these "Explain like I'm 5"
kind of posts you see on Reddit. I'm stuck. I'm on OSX
(Yosemite). I seem to have properly installed homebrew, and then
dub, and then sqlite3, and I have the dmd D compiler installed
and working. Now I'm trying to get D2SQLite3 installed on OSX so
that I can interact with a SQLite database. I downloaded and
expanded the zip from Github:
https://github.com/biozic/d2sqlite3
...and then cd'd to this directory. I then edited the dub.json
file like so:
{
"name": "d2sqlite3",
"description": "A thin wrapper around SQLite3",
"homepage": "https://github.com/biozic/d2sqlite3";,
"authors": ["Nicolas Sicard", "Other contributors: see Github
repo"],
"copyright": "Copyright 2011-15 Nicolas Sicard",
"license": "BSL-1.0",
"targetType": "library",
"libs": ["sqlite3"],
"systemDependencies": "SQLite version >= 3.8.7",
"lflags":
["-L/usr/local/Cellar/sqlite/3.8.11.1/lib/libsqlite3.dylib"]
}
...although I'm not quite clear if I did the lflags line
properly. I then ran "dub build" and it seems to have created the
file: libd2sqlite3.a
Now I don't know what to do with that file. I also created a
test.d script to test the SQLite out, but it's complaining of
missing symbols, even though I'm importing the right .d files:
import d2sqlite3;
import std.array;
import std.conv;
import std.exception;
import std.file;
import std.path;
import std.stdio;
import std.string;
import std.c.stdlib : exit;
import core.stdc.time : time_t;
import etc.c.zlib;
void main(){
auto db = Database("test.sqlite");
auto results = db.execute("SELECT * FROM test");
while (!results.empty) {
auto row = results.front;
writeln(row.peek!string(0));
results.popFront();
}
}
When I compile this, it complains of missing the d2SQLite symbols:
$ dmd test.d
Undefined symbols for architecture x86_64:
"_D9d2sqlite311ResultRange11__fieldDtorMFZv", referenced from:
__Dmain in test.o
"_D9d2sqlite311ResultRange5emptyMFNdZb", referenced from:
__Dmain in test.o
"_D9d2sqlite311ResultRange5frontMFNdZS9d2sqlite33Row",
referenced from:
__Dmain in test.o
"_D9d2sqlite311ResultRange8_Payload11__fieldDtorMFZv",
referenced from:
_D42TypeInfo_S9d2sqlite311ResultRange8_Payload6__initZ in
test.o
"_D9d2sqlite311ResultRange8_Payload11__xopEqualsFKxS9d2sqlite311ResultRange8_PayloadKxS9d2sqlite311ResultRange8_PayloadZb", referenced from:
_D42TypeInfo_S9d2sqlite311ResultRange8_Payload6__initZ in
test.o
"_D9d2sqlite311ResultRange8popFrontMFZv", referenced from:
__Dmain in test.o
"_D9d2sqlite312__ModuleInfoZ", referenced from:
_D4test12__ModuleInfoZ in test.o
"_D9d2sqlite33Row13internalIndexMFiZi", referenced from:
_D9d2sqlite33Row13__T4peekTAyaZ4peekMFiZAya in test.o
"_D9d2sqlite38Database11__fieldDtorMFZv", referenced from:
__Dmain in test.o
"_D9d2sqlite38Database6__ctorMFNcAyaiZS9d2sqlite38Database",
referenced from:
__Dmain in test.o
"_D9d2sqlite38Database7executeMFAyaZS9d2sqlite311ResultRange",
referenced from:
__Dmain in test.o
"_D9d2sqlite38Database8_Payload6__dtorMFZv", referenced from:
_D38TypeInfo_S9d2sqlite38Database8_Payload6__initZ in test.o
"_D9d2sqlite39Statement8_Payload10__aggrDtorMFZv", referenced
from:
_D39TypeInfo_S9d2sqlite39Statement8_Payload6__initZ in
test.o
"_D9d2sqlite39Statement8_Payload11__xopEqualsFKxS9d2sqlite39Statement8_PayloadKxS9d2sqlite39Statement8_PayloadZb", referenced from:
_D39TypeInfo_S9d2sqlite39Statement8_Payload6__initZ in
test.o
"_sqlite3_column_text", referenced from:
_D9d2sqlite33Row13__T4peekTAyaZ4peekMFiZAya in test.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
--- errorlevel 1
How do I get this going?
