Re: DConf 2016 announces programme, general registration opened thrugh April 22
On 02/04/2016 5:45 AM, Jack Stouffer wrote: On Tuesday, 29 March 2016 at 04:42:17 UTC, Dicebot wrote: I am not sure this has much value. The main benefit of live stream is that everyone can ask questions online and those will be forwarded to speakers. Isn't it better to simply wait for recorded high quality videos otherwise? P.S. devs from Europe did indeed have to stay awake through the night to watch previous dconfs ;) If you're going to live stream it, can you do it through Twitch so it's archived for a couple of days for people who can't stay up? livecoding.tv will archive it for a lot longer and unlike Twitch, we are friendly with them :)
Re: Typed D allocators based on Google Thread caching memory allocators
On Friday, 1 April 2016 at 09:33:27 UTC, Basile B. wrote: And maybe more (TCMMapAllocator TCCAllocator). Nothing will be added actually, there are only two possible allocator kinds with TC allocs. Example of how semantic versioning can be stupid: v0.2.0 and it's finished.
Re: Units of Measurement Library: units-d
On Friday, 1 April 2016 at 22:54:53 UTC, Simen Kjaeraas wrote:
On Friday, 1 April 2016 at 21:46:35 UTC, ag0aep6g wrote:
On 01.04.2016 22:59, Simen Kjaeraas wrote:
The usual way to fix it would be to include __FILE__ and
__LINE__ in the
template arguments:
Right, no mixin this way. I wouldn't call this "truly nice",
though.
It depends on code formatting to work. Put everything on one
line and it breaks. Significant whitespace is a pain when
generating code. Though this is not nearly as bad as
significant indentation, of course.
__FILE__ also kind of breaks separate compilation. All object
files have to be compiled from the same directory. Otherwise
__FILE__ will be different.
__LINE__ has a similar (maybe even more obscure) issue. Add or
remove a newline before compiling dependent modules and things
break. Usually, one recompiles all dependents when a
dependency changes, but a significant newline, really?
I kinda agree. And looking at
https://dlang.org/spec/traits.html, I see there's __MODULE__,
which would probably be a better choice than __FILE__.
As for __LINE__, what we'd want is basically something like
__CONTEXT__, which doesn't exist, but might be the .mangleof of
the surrounding scope:
struct S(string ctx = __CONTEXT__) {
pragma(msg, ctx);
}
S!() a; // "3foo"
void bar() {
S!() b; // "_D3foo3barFZv"
}
struct S2 {
S!() c; // "S3foo2S2"
void baz() {
S!() d; // "_D3foo2S23bazMFZv"
}
}
That'd remove the problem of significant whitespace. In fact,
it'd also eliminate the need for __MODULE__ in this case.
Still though, that's not enough if we want this to work:
void foo() {
alias a = Foo!(); alias b = Foo!();
assert(!isSame!(a, b));
}
We could also add __COLUMN__, which would be the horizontal
index of the instantiation's beginning:
foo(3, Bar!3.baz);
// ^Here. Position 11.
Next problem:
void main() {
pragma(msg, __LINE__);
mixin("pragma(msg, __LINE__);\npragma(msg, __LINE__);");
pragma(msg, __LINE__);
}
That prints '4' twice - once for the actual line 4, the other
for the second line of the mixin. However, __FILE__ is
different, so I guess __CONTEXT__ could also be.
--
Simen
What is needed is Lisp's gensym construct.
Re: Units of Measurement Library: units-d
On Friday, 1 April 2016 at 21:46:35 UTC, ag0aep6g wrote:
On 01.04.2016 22:59, Simen Kjaeraas wrote:
The usual way to fix it would be to include __FILE__ and
__LINE__ in the
template arguments:
Right, no mixin this way. I wouldn't call this "truly nice",
though.
It depends on code formatting to work. Put everything on one
line and it breaks. Significant whitespace is a pain when
generating code. Though this is not nearly as bad as
significant indentation, of course.
__FILE__ also kind of breaks separate compilation. All object
files have to be compiled from the same directory. Otherwise
__FILE__ will be different.
__LINE__ has a similar (maybe even more obscure) issue. Add or
remove a newline before compiling dependent modules and things
break. Usually, one recompiles all dependents when a dependency
changes, but a significant newline, really?
I kinda agree. And looking at https://dlang.org/spec/traits.html,
I see there's __MODULE__, which would probably be a better choice
than __FILE__.
As for __LINE__, what we'd want is basically something like
__CONTEXT__, which doesn't exist, but might be the .mangleof of
the surrounding scope:
struct S(string ctx = __CONTEXT__) {
pragma(msg, ctx);
}
S!() a; // "3foo"
void bar() {
S!() b; // "_D3foo3barFZv"
}
struct S2 {
S!() c; // "S3foo2S2"
void baz() {
S!() d; // "_D3foo2S23bazMFZv"
}
}
That'd remove the problem of significant whitespace. In fact,
it'd also eliminate the need for __MODULE__ in this case.
Still though, that's not enough if we want this to work:
void foo() {
alias a = Foo!(); alias b = Foo!();
assert(!isSame!(a, b));
}
We could also add __COLUMN__, which would be the horizontal index
of the instantiation's beginning:
foo(3, Bar!3.baz);
// ^Here. Position 11.
Next problem:
void main() {
pragma(msg, __LINE__);
mixin("pragma(msg, __LINE__);\npragma(msg, __LINE__);");
pragma(msg, __LINE__);
}
That prints '4' twice - once for the actual line 4, the other for
the second line of the mixin. However, __FILE__ is different, so
I guess __CONTEXT__ could also be.
--
Simen
Re: Units of Measurement Library: units-d
On 01.04.2016 22:59, Simen Kjaeraas wrote: The usual way to fix it would be to include __FILE__ and __LINE__ in the template arguments: Right, no mixin this way. I wouldn't call this "truly nice", though. It depends on code formatting to work. Put everything on one line and it breaks. Significant whitespace is a pain when generating code. Though this is not nearly as bad as significant indentation, of course. __FILE__ also kind of breaks separate compilation. All object files have to be compiled from the same directory. Otherwise __FILE__ will be different. __LINE__ has a similar (maybe even more obscure) issue. Add or remove a newline before compiling dependent modules and things break. Usually, one recompiles all dependents when a dependency changes, but a significant newline, really?
Re: Graylog integration for std.experimental.logger
On Friday, 1 April 2016 at 11:14:19 UTC, 9il wrote: Graylog Extended Log Format (GELF) D implementation was released. Great, thanks a lot.
Re: Units of Measurement Library: units-d
On Friday, 1 April 2016 at 19:03:03 UTC, ag0aep6g wrote:
I dislike that the type depends only on the given name. This
effectively means that the names are in a global namespace.
[snip]
I can't think of a truly nice way to accomplish this, though.
As far as I see, it needs a mixin of some kind.
The usual way to fix it would be to include __FILE__ and __LINE__
in the template arguments:
// In units/package.d:
struct BaseUnit(string name, string symbol = null, string file =
__FILE__, size_t line = __LINE__)
{
// ...
}
// in foo.d:
import experimental.units;
struct A
{
// Actual type is BaseUnit!("Ampere", "A", "foo", 5):
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}
struct B
{
// Actual type is BaseUnit!("Ampere", "A", "foo", 12):
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}
void main() {
assert(!is(B.Ampere == A.Ampere));
}
--
Simen
Re: Units of Measurement Library: units-d
On Thursday, 31 March 2016 at 23:58:54 UTC, Nordlöw wrote: I've put David Nadlinger work together with my tweaks on top at https://github.com/nordlow/units-d to make it easier to experiment with. PR are very welcome. Nice work. I have yet to play around with it, but this is definitely going to need pre-made symbols for the United States customary system like SI has before it goes into Phobos.
Re: Units of Measurement Library: units-d
On 01.04.2016 01:58, Nordlöw wrote:
https://github.com/nordlow/units-d
From there:
* Example:
* ---
* alias BaseUnit!("Ampere", "A") Ampere;
* enum ampere = Ampere.init;
* // or
* enum ampere = baseUnit!("Ampere", "A");
* ---
I dislike that the type depends only on the given name. This effectively
means that the names are in a global namespace.
For example:
import experimental.units;
struct A
{
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}
struct B
{
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}
A.Ampere and B.Ampere are the same type here. I think it would be more
useful if they weren't. When two unrelated sources define a new unit
with the same name, then they shouldn't be compatible. Think of all the
different kinds of pounds and miles there used to be in the world.
I can't think of a truly nice way to accomplish this, though. As far as
I see, it needs a mixin of some kind.
Like this, for example:
enum string baseUnit = q{
{
static struct BaseUnit {/* ... */}
return BaseUnit.init;
}()
};
struct A
{
enum ampere = mixin(baseUnit);
}
struct B
{
enum ampere = mixin(baseUnit);
}
static assert(!is(typeof(A.ampere) == typeof(B.ampere)));
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On Tuesday, 29 March 2016 at 04:42:17 UTC, Dicebot wrote: I am not sure this has much value. The main benefit of live stream is that everyone can ask questions online and those will be forwarded to speakers. Isn't it better to simply wait for recorded high quality videos otherwise? P.S. devs from Europe did indeed have to stay awake through the night to watch previous dconfs ;) If you're going to live stream it, can you do it through Twitch so it's archived for a couple of days for people who can't stay up?
Re: Small rdmd wrapper for windows
On Thursday, 31 March 2016 at 10:54:50 UTC, Kagamin wrote: Maybe rdmd should parse D_INCLUDE_PATH itself? Then it would work on its own. You could also use the DFLAGS environment variable for that, but I think it's cleaner to seperate the scripting environment from the normal build environment.
Graylog integration for std.experimental.logger
Graylog Extended Log Format (GELF) D implementation was released. Supported transport: - UDP, sends big messages by chunks - plain - compressed (deflate or gzip) -TCP - plain - HTTP - plain - compressed (deflate or gzip) Git: https://github.com/9il/gelf DuB: http://code.dlang.org/packages/gelf GELF format: http://docs.graylog.org/en/latest/pages/gelf.html GrayLog server: https://www.graylog.org/? Best regards, Ilya
Typed D allocators based on Google Thread caching memory allocators
This new DUB package uses the "Thread Caching" memory allocators from Google performance tools to make typed D allocators, conform with the interface defined in std.experimental.allocator. - Posix only. - TCMallocator (= Mallocator). - TCAlignedMallocator (= AlignedMallocator). And maybe more (TCMMapAllocator TCCAllocator). about Thread caching memory allocators: http://goog-perftools.sourceforge.net/doc/tcmalloc.html the repo: https://github.com/BBasile/tcmallocd PR and BR obviously welcome if you see an error.
