Re: lookuptable

2020-04-22 Thread Steven Schveighoffer via Digitalmars-d-announce

On 4/22/20 5:21 PM, Sebastiaan Koppe wrote:

On Wednesday, 22 April 2020 at 20:27:12 UTC, Steven Schveighoffer wrote:
Just wanted to throw this out there on a slow day. I wrote this little 
utility to generate static lookup tables, because using an AA is too 
expensive for something like e.g. looking up database row data by 
column name.


It's very crude, but very short and sweet. Hopefully people find a use 
for it.


Let me know if you have any requests or find any bugs on github.

https://code.dlang.org/packages/lookuptable



Nice.

For the indexLookup you can also use https://github.com/skoppe/perfect-hash


Hm... thanks for the suggestion. I'm not sure if it fits here, as the 
point is to avoid runtime cost and GC allocation, not make lookups 
uber-fast.


These are meant to be short-lived things. My main target was e.g. 
mysql-native has an "asAA" function which generates an AA with keys 
being the column names. This is kind of crappy, because if you do that 
for each row, then you are generating and throwing away a LOT of data.


But if you generate the lookup index once per sequence, and you reuse 
that, you have much more efficiency, and are only generating one array. 
Possibly if I can figure out a good API, you could do it with 
malloc/free instead of using GC, but I'm happy with it right now anyway.


-Steve


Re: lookuptable

2020-04-22 Thread Sebastiaan Koppe via Digitalmars-d-announce
On Wednesday, 22 April 2020 at 21:21:31 UTC, Sebastiaan Koppe 
wrote:
For the indexLookup you can also use 
https://github.com/skoppe/perfect-hash


That is not quite true, only for strings.



Re: lookuptable

2020-04-22 Thread Sebastiaan Koppe via Digitalmars-d-announce
On Wednesday, 22 April 2020 at 20:27:12 UTC, Steven Schveighoffer 
wrote:
Just wanted to throw this out there on a slow day. I wrote this 
little utility to generate static lookup tables, because using 
an AA is too expensive for something like e.g. looking up 
database row data by column name.


It's very crude, but very short and sweet. Hopefully people 
find a use for it.


Let me know if you have any requests or find any bugs on github.

https://code.dlang.org/packages/lookuptable

-Steve


Nice.

For the indexLookup you can also use 
https://github.com/skoppe/perfect-hash


lookuptable

2020-04-22 Thread Steven Schveighoffer via Digitalmars-d-announce
Just wanted to throw this out there on a slow day. I wrote this little 
utility to generate static lookup tables, because using an AA is too 
expensive for something like e.g. looking up database row data by column 
name.


It's very crude, but very short and sweet. Hopefully people find a use 
for it.


Let me know if you have any requests or find any bugs on github.

https://code.dlang.org/packages/lookuptable

-Steve


Re: describe-d: an introspection library

2020-04-22 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Wednesday, 22 April 2020 at 17:32:33 UTC, Stefan Koch wrote:


It's going to be part of the compiler.
You can look at the ... expression DIP.
which Manu posted in General, for taste of where my stuff is 
going.


I think I see the point - I am familiar with C++ variadic 
templates.


Yes, speeding up `staticMap`, and often eliminating the need to 
use it, will hugely benefit meta-programming.


However, that will not solve the problem of unnecessary 
instantiations that my example above demonstrates (it has a bug 
btw, the parameters should have been wrapped in a 
bolts.meta.AliasPack, but it doesn't alter the spirit).


Thank you for the `-vcg-ast` switch! It looks like I am going to 
use it a lot.


I am rewriting my system to express the accessors in terms of 
free functions taking meta-objects, instead of meta-objects 
containing properties. I have a hunch that that will curb 
instantiation, compile time and .o size.





Re: describe-d: an introspection library

2020-04-22 Thread Stefan Koch via Digitalmars-d-announce
On Wednesday, 22 April 2020 at 17:27:48 UTC, Jean-Louis Leroy 
wrote:

On Wednesday, 22 April 2020 at 17:16:28 UTC, Stefan Koch wrote:

I am working on a much more powerful and efficient meta 
programming system.


Great! Is it going to be in a library, or part of the compiler? 
Can we get a preview somewhere?


It's going to be part of the compiler.
You can look at the ... expression DIP.
which Manu posted in General, for taste of where my stuff is 
going.
Basically I will give CTFE the ability to modify type-lists 
directly.




Re: describe-d: an introspection library

2020-04-22 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Wednesday, 22 April 2020 at 17:16:28 UTC, Stefan Koch wrote:

I am working on a much more powerful and efficient meta 
programming system.


Great! Is it going to be in a library, or part of the compiler? 
Can we get a preview somewhere?





Re: describe-d: an introspection library

2020-04-22 Thread Stefan Koch via Digitalmars-d-announce
On Wednesday, 22 April 2020 at 13:32:03 UTC, Jean-Louis Leroy 
wrote:


I tried compiling my example with `dmd -vcg-ast -c tmt.d` and I 
did got neither an AST nor an error, and the option is not in 
`dmd -h`, where can I read about it?


-vcg-ast is a debugging tool I original built to fix an bug in 
the inliner.
when you through the switch a new file of the form 
"soucefilename.d.cg" should get written out for every sourcefile 
in the same directory that the source file is in.


As for your other point.
I am working on a much more powerful and efficient meta 
programming system.
It's no where near done. So I will not commit to any release date 
... I've learned my lesson.




Re: describe-d: an introspection library

2020-04-22 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Wednesday, 22 April 2020 at 05:20:18 UTC, Stefan Koch wrote:
On Tuesday, 21 April 2020 at 14:43:04 UTC, Jean-Louis Leroy 
wrote:



I wonder if templates are lazily expanded. I haven't looked at 
the compiler's code, my guess is: maybe not.


If the template gets used it gets instantiated (and cached).


I did not word my question precisely, I meant: is it instantiated 
in its *entirety*.


Consider:

import std.meta;

template Function(Attributes...)
{
  enum isPure = Attributes[0];
  enum isNogc = Attributes[1];
  alias parameters = Attributes[2];
}

template Parameter(int i)
{
  // static assert(false);
}

template reflectFunction(alias Fun)
{
  alias reflectFunction = Function!(
true, true, staticMap!(Parameter, 1, 2, 3));
}

void foo();
pragma(msg, reflectFunction!(foo).isPure);

Is `Parameter` instantiated in this example? If I uncomment the 
assert, it fires. This is what gives me the impression that more 
is instantiated than is really used. And that is probably why 
reflecting runtime entities as template meta-objects with 
properties for all aspects of them is slow.


I am way of my field of competence here, but I have the 
impression that speeding this up would not require a change in 
the language (unless it is stated that templates are greedily 
expanded, and common idioms rely on this).


you can use the -vcg-ast switch to look at how your souce code 
looks "expandend".


I tried compiling my example with `dmd -vcg-ast -c tmt.d` and I 
did got neither an AST nor an error, and the option is not in 
`dmd -h`, where can I read about it?



They already gained traction, unfortunately.


Well...Two things. I ended up developing this approach because I 
needed to copy function attributes, UDAs, function parameter 
storage classes and UDAs to a generated function. If the 
language, or Phobos, provided me a more direct way, trust me, I 
would have used it. For example, storage classes are not part of 
a parameter's type. OK. Now you can use `Parameter!F[0]` to 
declare a parameter in a new function (great!), but you cannot 
say `__traits(getStorageClasses, F)[0] Parameter!F[0]`.


Also, one of D's selling points is that it does templates and 
meta-programming better. It's only natural that people use these 
features then (note that in C++, sorry for mentioning it, in my 
example Parameter would *not* be instantiated).




Discussion Thread: DIP 1033--Implicit Conversion of Expressions to Delegates--Community Review Round 1 Begins

2020-04-22 Thread Mike Parker via Digitalmars-d-announce
The first round of Community Review of DIP 1033, "Implicit 
Conversion of Expressions to Delegates", has begun.


Feedback Thread:
https://forum.dlang.org/post/nxahrsukobybkezib...@forum.dlang.org

Discussion Thread:
https://forum.dlang.org/post/ecxdylguqkhtmdoml...@forum.dlang.org