Re: Weird error message.
Decided to do a fresh install of windows, and problem has one away. It seems no matter how careful you are to keep your system lean and clean windows eventually starts grinding gears. Thanks,
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 14:43:35 UTC, D_Learner wrote: Hello everyone . I need advice on my first D-project . I have uploaded it at :- [...] I wouldn't compare benchmarks without optimisations turned on. Atila
Re: Real OOP with D
On Monday, 17 August 2015 at 06:08:35 UTC, Ali Çehreli wrote:
On 08/16/2015 10:57 PM, Ozan wrote:
[...]
From the way you use it below, a better name for that class
would be FamilyMember but I get the point.
Yes, you're right.
[...]
father.greeting;
son.greeting;
What you mean is that the call above causes a compilation error:
Error: no property 'greeting' for type 'deneme.Family'
}
[...]
My experience with OOP is limited to C++ and D. I think what
you are describing is how dynamically typed languages work. It
is impossible in compiled languages like C++ and D. When a type
is used in an expression, the compiler ensures that the call is
bound to a function.
In D, it starts with the class definition.
Actually, 'interface' is a better fit in most cases:
interface FamilyMember
{
// ...
}
class Dad : FamilyMember
{
// ...
}
[...]
Ali
Interfaces are very helpful to avoid large inheritance trees in
OOP. On the other hand, there are not designed as workarounds
for OOP implementation problems.
The kind of OOP in D is a classical way to handle it. Dynamic
languages tries to close the gap between theoretical and
practical OOP for the price of speed.
I think that Adam's jsvar idea is a great way to bring more
flexibility into D. The same in OOP would be also great.
Regards, Ozan
Re: Real OOP with D
On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote: On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote: Hi [...] Is there any way to get real OOP with D? Regards, Ozan Can you name an OOP oriented language that allows this ? Your example is eroneous OOP. The 2 other answers you 've got (the first using an interface and the second using an abstract class) are valid OOP. One of the fundamental concept OOP is that a function defined in a class exists also in its subclasses. So how do you expect `greeting()` to exist in Family if it's only defined in its sub-classes ? You can verify that with the 'Liskov substitution principle' (https://en.wikipedia.org/wiki/Liskov_substitution_principle). Actually your sample violates this principle. Languages like Groovy or JavaScript (with the help of frameworks ;-) And I believe many more the newer ones. But that's not the point. And... This was not a criticism against D (... bad D, has no understanding of OOP. Boahh ;-) It was only a question about handling of a typical OOP problem in a class-typed implementation of OOP like D has. Thanks to every existing or new creative programming language, today we have so many other ways to solve our programming problems. Regards Ozan
Re: Real OOP with D
On Monday, 17 August 2015 at 06:10:38 UTC, Rikki Cattermole wrote:
On 17/08/2015 5:57 p.m., Ozan wrote:
Hi
[...]
import std.stdio;
abstract class Family { void greeting(); }
class Dad : Family { void greeting() { writeln(I'm dad); } }
class Boy : Family { void greeting() { writeln(I'm daddy's
boy); } }
void main() {
Family dad = new Dad;
Family boy = new Boy;
dad.greeting;
boy.greeting;
}
I'm confused how this isn't real OOP?
Replace 'real' with 'theoretical' OOP. Every instance of a class
(object) is like an independent black box. Every public message
(method / function) of the class definition could be called when
ever you want. Variables are like pointers to objects. With
inheritance and overriding you're losing in class type
implementations of OOP a lot of 'theoretical' flexibility. I was
asking for a possibility to avoid this.
Regards Ozan
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:03:09 UTC, Ozan wrote: I think that Adam's jsvar idea is a great way to bring more flexibility into D. The same in OOP would be also great. Dynamic typing in D can be emulated in the same way jsvar and Variant do it. If jsvar doesn't support it, you can look into libraries like luad, which AFAIK can generate dynamic wrappers for static types, I suppose there was something similar for IDispatch.
Re: Compiletime Vs Runtime bencmarks
On Tuesday, 18 August 2015 at 07:16:32 UTC, D_Learner wrote: On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D profiler's. Though am not searching for exact, but theyy must be comparable atleast. When you say D profiler, you mean dmd's built-in profiler, yes? That is an instrumenting profiler which adds a not insignificant cost to function calls, which means you have to be careful interpreting the results
Re: Real OOP with D
On Tuesday, 18 August 2015 at 07:19:02 UTC, BBasile wrote:
On Tuesday, 18 August 2015 at 06:27:53 UTC, Ozan wrote:
On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote:
On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote:
Hi
[...]
Is there any way to get real OOP with D?
Regards, Ozan
Can you name an OOP oriented language that allows this ? Your
example is eroneous OOP.
The 2 other answers you 've got (the first using an interface
and the second using an abstract class) are valid OOP.
One of the fundamental concept OOP is that a function defined
in a class exists also in its subclasses. So how do you
expect `greeting()` to exist in Family if it's only defined
in its sub-classes ?
You can verify that with the 'Liskov substitution principle'
(https://en.wikipedia.org/wiki/Liskov_substitution_principle).
Actually your sample violates this principle.
Languages like Groovy or JavaScript (with the help of
frameworks ;-)
And I believe many more the newer ones. But that's not the
point.
And... This was not a criticism against D (... bad D, has no
understanding of OOP. Boahh ;-)
It was only a question about handling of a typical OOP problem
in a class-typed implementation of OOP like D has. Thanks to
every existing or new creative programming language, today we
have so many other ways to solve our programming problems.
Regards Ozan
You example is not valid strongly-typed OOP. In D you could do
something similar but not with the OO paradigm but rather with
compile-time refexion (introspection):
---
import std.stdio;
static bool isFamilyMember(T)()
{
import std.traits: isCallable;
return __traits(hasMember, T, greeting);
}
void FamilyMemberSayHello(T)(ref T t)
{
static if (isFamilyMember!T)
t.greeting;
}
struct Dad{
void greeting(){hello from a Dad.writeln;}
}
struct Boy{
void greeting(){hello from a Boy.writeln;}
}
struct IdiotDuBled{}
void main()
{
auto dad = new Dad;
auto boy = new Boy;
auto idiotDuBled = new IdiotDuBled;
FamilyMemberSayHello(dad);
FamilyMemberSayHello(boy);
FamilyMemberSayHello(idiotDuBled);
}
---
The idea is rather to check at compile time if a variable will
have the trait which characterizes a FamilyMember, without
using inheritence.
I believe D allows what you want to do using generic programming.
Being a compiled and strongly typed language, the information
about the type, needs to be available during compilation, but
this makes no difference from a theoretic OOP view.
BBasiles example can also be done without the trait. Then the
check for greeting() will be done by the compiler.
void FamilyMemberSayHello(T)(ref T t)
{
t.greeting;
}
struct Dad{
void greeting(){hello from a Dad.writeln;}
}
struct Boy{
void greeting(){hello from a Boy.writeln;}
}
struct IdiotDuBled{}
void main()
{
auto dad = new Dad;
auto boy = new Boy;
auto idiotDuBled = new IdiotDuBled;
FamilyMemberSayHello(dad);
FamilyMemberSayHello(boy);
FamilyMemberSayHello(idiotDuBled); //will not compile
}
The OOP Model of D is fairly close to that of Eiffel which I
consider pretty pure Object Oriented. The only exception is
multiple inheritance, which I do not miss at all.
In my Opinion D is a great language for Object Oriented Design
and Programming.
It awesomely supports Contracts and Constraint Generics, which
many languages lack.
I never missed multiple inheritance, as I was able to cover all
my use cases with mixins.
The support for functional programming and CTFE allows to
elegantly handle the cases, where inheritance based OOP feels
awkward.
Actually I urge all the people who say: Smalltalk was the last
(only) good OOP language! to try out D.
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:03:09 UTC, Ozan wrote: I think that Adam's jsvar idea is a great way to bring more flexibility into D. The same in OOP would be also great. Looks like jsvar can invoke opCall method for wrapped object: https://github.com/adamdruppe/arsd/blob/master/jsvar.d#L729 you can extend it to support invocation of other methods.
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D profiler's. Though am not searching for exact, but theyy must be comparable atleast.
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:27:53 UTC, Ozan wrote:
On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote:
On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote:
Hi
[...]
Is there any way to get real OOP with D?
Regards, Ozan
Can you name an OOP oriented language that allows this ? Your
example is eroneous OOP.
The 2 other answers you 've got (the first using an interface
and the second using an abstract class) are valid OOP.
One of the fundamental concept OOP is that a function defined
in a class exists also in its subclasses. So how do you
expect `greeting()` to exist in Family if it's only defined in
its sub-classes ?
You can verify that with the 'Liskov substitution principle'
(https://en.wikipedia.org/wiki/Liskov_substitution_principle).
Actually your sample violates this principle.
Languages like Groovy or JavaScript (with the help of
frameworks ;-)
And I believe many more the newer ones. But that's not the
point.
And... This was not a criticism against D (... bad D, has no
understanding of OOP. Boahh ;-)
It was only a question about handling of a typical OOP problem
in a class-typed implementation of OOP like D has. Thanks to
every existing or new creative programming language, today we
have so many other ways to solve our programming problems.
Regards Ozan
You example is not valid strongly-typed OOP. In D you could do
something similar but not with the OO paradigm but rather with
compile-time refexion (introspection):
---
import std.stdio;
static bool isFamilyMember(T)()
{
import std.traits: isCallable;
return __traits(hasMember, T, greeting);
}
void FamilyMemberSayHello(T)(ref T t)
{
static if (isFamilyMember!T)
t.greeting;
}
struct Dad{
void greeting(){hello from a Dad.writeln;}
}
struct Boy{
void greeting(){hello from a Boy.writeln;}
}
struct IdiotDuBled{}
void main()
{
auto dad = new Dad;
auto boy = new Boy;
auto idiotDuBled = new IdiotDuBled;
FamilyMemberSayHello(dad);
FamilyMemberSayHello(boy);
FamilyMemberSayHello(idiotDuBled);
}
---
The idea is rather to check at compile time if a variable will
have the trait which characterizes a FamilyMember, without
using inheritence.
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D compilers.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from not
being in a messy nesting.
...
What's wrong with just putting all the foreach statements on a
single line?
foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10)
{
writeln(i, j, k);
}
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from
not being in a messy nesting.
...
What would you do with associative arrays?
void main() {
auto aa = [1:1, 2:2];
foreach (a, b ; aa, 1..10)
foo(a, b);
}
Prevent both iterator count and associative value variables for
foreach loops with nested loops. This behaviour of associative
arrays is already an odd case as it clashes with the iterator
behaviour for other arrays.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 17:44:00 UTC, Xinok wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from
not being in a messy nesting.
...
What's wrong with just putting all the foreach statements on a
single line?
foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10)
{
writeln(i, j, k);
}
This.
And it's more obvious what you're trying to do.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 16:51:01 UTC, ixid wrote:
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from
not being in a messy nesting.
...
What would you do with associative arrays?
void main() {
auto aa = [1:1, 2:2];
foreach (a, b ; aa, 1..10)
foo(a, b);
}
Prevent both iterator count and associative value variables for
foreach loops with nested loops. This behaviour of associative
arrays is already an odd case as it clashes with the iterator
behaviour for other arrays.
It is not iterator count, it is key and value. And actually, it
is pretty consistent.
import std.stdio;
void main () {
foreach (index, value; [2, 4, 8])
writefln (a[%s] = %s, index, value);
foreach (index, value; ['x': 2, 'y': 4, 'z': 8])
writefln (b[%s] = %s, index, value);
}
The output is:
a[0] = 2
a[1] = 4
a[2] = 8
b[z] = 8
b[x] = 2
b[y] = 4
Re: Starting a HTTPS session with D
On Thursday, 12 February 2015 at 12:34:21 UTC, Vladimir Panteleev wrote: On Windows, if you are using the curl library included with DMD 2.066.1, curl will use the Windows certificate store. Did this changed? I use 2.068.0 and still have problems with SSL. Sorry for necroposting.
Re: unusual bare metal target: Amazon Dash
On 19/08/2015 3:24 a.m., Laeeth Isharc wrote: On Tuesday, 18 August 2015 at 04:36:49 UTC, Rikki Cattermole wrote: On 18/08/2015 1:32 p.m., Laeeth Isharc wrote: I don't know whether D can run on one, but from a quick look perhaps feasible. Running D on something like this (perhaps it's underpowered, but looked to have similar spec to what people had been doing with related ARM cortex processors) would certainly make the point very vivid that it can be a bare metal programming language. Only 1Mb of flash RAM for the program - is that enough? https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/programming https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/overview The Amazon Dash button is a tiny device that orders products from Amazon.com at the press of a button. It's designed to be put wherever you store consumeables like paper towels, trash bags, etc. so that you can easily order more when they run out. The Dash is great at what it's designed to do, but did you know inside the Dash is a powerful ARM Cortex-M3 processor and WiFi module that are very similar to wireless development boards like the Particle Photon? You'll even find there are easily accessible test pads on the Dash which allow you to reprogram its CPU and turn it into your own $5 internet button! This guide will explore how to take apart the Dash and reprogram its CPU to run your own code. ... The CPU is a STM32F205RG6 processor which is an ARM Cortex-M3 that can run up to 120mhz and has 128 kilobytes of RAM and 1 megabyte of flash memory for program storage. The WiFi module is a BCM943362 module which in combination with the CPU make it a platform for Broadcom's WICED SDK. There's a 16 megabit SPI flash ROM which is typically used in conjunction with the WICED SDK for storing application data. An ADMP441 microphone is connected to the CPU and used by the Dash iOS application to configure the device using the speaker on a phone/tablet. There's a single RGB LED and a button. By what you are saying, I believe it should be doable. Although I'm a little worried for the WiFi support. Do you need to include the code to drive it beyond wrap up some communication to it? 1mb flash should be enough to run D code on it. If you strip out a good percentage of druntime and definitely no Phobos. Although you may be able to mark and use some of that 16mb flash rom as executable code storage. If that's so, you'll be in a good place to have more then 1mb. It would require some clever runtime linking tricks however. I'm probably not the best person to go more in depth about it or the specific chips. So I won't. Most of my knowledge comes from reading what others says and talking with Jens Bauer. I think its doable too. Nobody seems to have figured out the wifi yet - more at LED flashing stage. It's funny these wifi devices have microphones in them ! I was thinking about that. Maybe for speech recognition? Of course there is no way that device could actually analyze it.
Promises/A+ spec implementations?
Hi, folks. Over ten years ago I had some interest in the D language. I'm starting to think about it again... I've been using Mozilla's Promises implementations for quite a while, now, and they're surprisingly nice to work with. They are the next generation beyond the callback function patterns I learned in JavaScript. I've been thinking that writing a Promises/A+ library for D would be a good task for a relatively inexperienced D programmer. I didn't see any Promises/A+ implementations in the standard library or on code.dlang.org. Now, whether I write that library or someone else beats me to it, I don't really care right now. I'm interested in doing it, but my time is extremely limited. I'm mainly posting this as a request to get a Promises/A+ library started, and for me to observe the process of crafting a library. If someone wants to be a mentor for me on this, answering direct questions, that'd be great. The spec for Promises/A+ is at https://promisesaplus.com/ . Mozilla's Bobby Holley recently wrote a good blog post about a MozPromise implementation which includes supporting multithreading (a concept I don't fully understand how to write for, yet) and cancelling a Promise (which isn't in the spec, but makes sense for Mozilla's purposes). That blog post is at http://bholley.net/blog/2015/mozpromise.html . Finally, I had an old login to this forum (kb7iuj), which I've long forgotten the password for. I did see that there's no password recovery support, so could someone just terminate that login for good?
Re: ReturnType of lambda templates
On Tuesday, 18 August 2015 at 14:25:34 UTC, Roland Hadinger wrote:
Hi!
Suppose I wanna do this (which already works, which is why D is
pretty cool):
import std.traits;
import std.typecons : Nullable;
// Retrofit Nullable to allow for monadic chaining
//
auto apply( alias fun, T )( Nullable!T nullable )
if( isSomeFunction!fun )
{
enum returnsVoid = is( ReturnType!fun == void );
enum returnsNullable = is( ReturnType!fun : Nullable!X,
X );
static if( returnsVoid ) {
if( !nullable.isNull )
fun( nullable.get );
} else static if( returnsNullable ) {
alias NR = ReturnType!fun;
if( nullable.isNull )
return NR();
else
return fun( nullable.get );
} else {
alias NR = Nullable!( ReturnType!fun );
if( nullable.isNull )
return NR();
else
return NR( fun( nullable.get ) );
}
}
void main()
{
Nullable!int a = 1;
Nullable!int b = a.apply!( (int x) = 2 * x );
// .apply!( (double x) = foo( x, u ) )
// .apply!( (double x) = bar( x, v ) )
// .apply!( (string x) = baz( x, w ) );
}
...but without explicitly specifying the type of the lambda
parameter:
void main()
{
Nullable!int a = 1;
Nullable!int b = a.apply!( x = 2 * x );
// .apply!( x = foo( x, u ) )
// .apply!( x = bar( x, v ) )
// .apply!( x = baz( x, w ) );
}
Problem is, the shorter form involves lambda templates, and
both 'isSomeFunction' and 'ReturnType' currently don't seem to
work
with those. No problems with the other version.
Can I fix my 'apply' function to still allow for the less
verbose form?
If that's impossible, is it a theoretical possibility to
improve D's type deduction to handle this?
Or should I just not attempt to write code like this for the
time being (after all, functional code like this incurs some
overhead, but in this particular case, I'd prefer legibility
over performance)?
Thanks!
for simple lambdas like that (i.e. function templates with one
template arguments that corresponds to the type of the first and
only argument), just add this template overload:
auto apply( alias fun, T )( Nullable!T nullable )
if( !isSomeFunction!fun )
{
return .apply!(fun!T, T)(nullable);
}
and it should work (give or a take a few typos on my part).
ReturnType of lambda templates
Hi!
Suppose I wanna do this (which already works, which is why D is
pretty cool):
import std.traits;
import std.typecons : Nullable;
// Retrofit Nullable to allow for monadic chaining
//
auto apply( alias fun, T )( Nullable!T nullable )
if( isSomeFunction!fun )
{
enum returnsVoid = is( ReturnType!fun == void );
enum returnsNullable = is( ReturnType!fun : Nullable!X, X
);
static if( returnsVoid ) {
if( !nullable.isNull )
fun( nullable.get );
} else static if( returnsNullable ) {
alias NR = ReturnType!fun;
if( nullable.isNull )
return NR();
else
return fun( nullable.get );
} else {
alias NR = Nullable!( ReturnType!fun );
if( nullable.isNull )
return NR();
else
return NR( fun( nullable.get ) );
}
}
void main()
{
Nullable!int a = 1;
Nullable!int b = a.apply!( (int x) = 2 * x );
// .apply!( (double x) = foo( x, u ) )
// .apply!( (double x) = bar( x, v ) )
// .apply!( (string x) = baz( x, w ) );
}
...but without explicitly specifying the type of the lambda
parameter:
void main()
{
Nullable!int a = 1;
Nullable!int b = a.apply!( x = 2 * x );
// .apply!( x = foo( x, u ) )
// .apply!( x = bar( x, v ) )
// .apply!( x = baz( x, w ) );
}
Problem is, the shorter form involves lambda templates, and both
'isSomeFunction' and 'ReturnType' currently don't seem to work
with those. No problems with the other version.
Can I fix my 'apply' function to still allow for the less verbose
form?
If that's impossible, is it a theoretical possibility to improve
D's type deduction to handle this?
Or should I just not attempt to write code like this for the time
being (after all, functional code like this incurs some overhead,
but in this particular case, I'd prefer legibility over
performance)?
Thanks!
Re: Getting a TypeTuple of a Template's Arguments
On Tuesday, 18 August 2015 at 07:41:00 UTC, thedeemon wrote: On Monday, 17 August 2015 at 21:23:49 UTC, Meta wrote: For functions, we have std.traits.ParameterTypeTuple. Is there any equivalent functionality for templates? I've recently searched for this thing and haven't found anything for uninstantiated templates, only for instantiated. As I'd thought. I can't think of a way to do it, either, so I guess that's a no-go for the time being.
Re: ReturnType of lambda templates
On Tuesday, 18 August 2015 at 15:11:34 UTC, John Colvin wrote:
for simple lambdas like that (i.e. function templates with one
template arguments that corresponds to the type of the first
and only argument), just add this template overload:
auto apply( alias fun, T )( Nullable!T nullable )
if( !isSomeFunction!fun )
{
return .apply!(fun!T, T)(nullable);
}
and it should work (give or a take a few typos on my part).
That was quick - and it works :)
Now, where is my thinking cap again?
foreach multiple loop sugar
Though sugar seems to be somewhat looked down upon I thought I'd
suggest this- having seen the cartesianProduct function from
std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more elegant
and reduces indentation significantly for multiple nested loops.
Braces make nested loops very messy and any significant quantity
of code in the loop body benefits from not being in a messy
nesting.
import std.algorithm, std.range, std.stdio;
void main() {
// Standard
foreach(i; 0..10)
foreach(j; 0..10)
foreach(k; 0..10)
writeln(i, j, k);
// Better
foreach(k, j, i; cartesianProduct(10.iota, 10.iota, 10.iota))
writeln(i, j, k);
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
writeln(i, j, k);
//Following brace rules
// Standard
foreach(i; 0..10)
{
foreach(j; 0..10)
{
foreach(k; 0..10)
{
writeln(i, j, k);
}
}
}
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
{
writeln(i, j, k);
}
}
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from not
being in a messy nesting.
import std.algorithm, std.range, std.stdio;
void main() {
// Standard
foreach(i; 0..10)
foreach(j; 0..10)
foreach(k; 0..10)
writeln(i, j, k);
// Better
foreach(k, j, i; cartesianProduct(10.iota, 10.iota, 10.iota))
writeln(i, j, k);
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
writeln(i, j, k);
//Following brace rules
// Standard
foreach(i; 0..10)
{
foreach(j; 0..10)
{
foreach(k; 0..10)
{
writeln(i, j, k);
}
}
}
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
{
writeln(i, j, k);
}
You can create a multi-loop quite easily in template form for
avoid the nesting.
Essentially use an array for the the index instead of individual
variables, e.g.,
mutliloop([0..10, 0..10, 0..10], (i)=
{
writeln(i[0], i[1], i[2]);
});
I'm not sure how efficient it is but essentially achieves what
you are asking without too much overhead. Obviously having good
language support is always nice...
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from not
being in a messy nesting.
...
What would you do with associative arrays?
void main() {
auto aa = [1:1, 2:2];
foreach (a, b ; aa, 1..10)
foo(a, b);
}
Re: unusual bare metal target: Amazon Dash
On Tuesday, 18 August 2015 at 04:36:49 UTC, Rikki Cattermole wrote: On 18/08/2015 1:32 p.m., Laeeth Isharc wrote: I don't know whether D can run on one, but from a quick look perhaps feasible. Running D on something like this (perhaps it's underpowered, but looked to have similar spec to what people had been doing with related ARM cortex processors) would certainly make the point very vivid that it can be a bare metal programming language. Only 1Mb of flash RAM for the program - is that enough? https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/programming https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/overview The Amazon Dash button is a tiny device that orders products from Amazon.com at the press of a button. It's designed to be put wherever you store consumeables like paper towels, trash bags, etc. so that you can easily order more when they run out. The Dash is great at what it's designed to do, but did you know inside the Dash is a powerful ARM Cortex-M3 processor and WiFi module that are very similar to wireless development boards like the Particle Photon? You'll even find there are easily accessible test pads on the Dash which allow you to reprogram its CPU and turn it into your own $5 internet button! This guide will explore how to take apart the Dash and reprogram its CPU to run your own code. ... The CPU is a STM32F205RG6 processor which is an ARM Cortex-M3 that can run up to 120mhz and has 128 kilobytes of RAM and 1 megabyte of flash memory for program storage. The WiFi module is a BCM943362 module which in combination with the CPU make it a platform for Broadcom's WICED SDK. There's a 16 megabit SPI flash ROM which is typically used in conjunction with the WICED SDK for storing application data. An ADMP441 microphone is connected to the CPU and used by the Dash iOS application to configure the device using the speaker on a phone/tablet. There's a single RGB LED and a button. By what you are saying, I believe it should be doable. Although I'm a little worried for the WiFi support. Do you need to include the code to drive it beyond wrap up some communication to it? 1mb flash should be enough to run D code on it. If you strip out a good percentage of druntime and definitely no Phobos. Although you may be able to mark and use some of that 16mb flash rom as executable code storage. If that's so, you'll be in a good place to have more then 1mb. It would require some clever runtime linking tricks however. I'm probably not the best person to go more in depth about it or the specific chips. So I won't. Most of my knowledge comes from reading what others says and talking with Jens Bauer. I think its doable too. Nobody seems to have figured out the wifi yet - more at LED flashing stage. It's funny these wifi devices have microphones in them !
