monodevelop mono-d versions
I can't seem to install mono-d. It always seems to want a newer version of MonoDevelop. I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have this file called MonoDevelop.D-1.9.6.mpack Tools-Add In Manager-Install From File Select the MonoDevelop.D-1.9.6.mpack file. Press Open Dialog Window: The Following Packages will be Installed. D Language Binding v2.1.14 (In User Directory)
Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 04:52:35 UTC, Jonathan M Davis wrote: On Thursday, 31 July 2014 at 22:21:10 UTC, Vlad Levenfeld wrote: Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. It's Andrei's fault. I'm not quite sure what he was thinking. But unfortunately, we're stuck with it. So, it's just become one of D's little quirks that we have to learn and live with. Can we not at least deprecate it? And while we're at it, the same for `dup` and `idup`?
Re: monodevelop mono-d versions
On Friday, 1 August 2014 at 09:12:49 UTC, sclytrack wrote: I can't seem to install mono-d. It always seems to want a newer version of MonoDevelop. I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have this file called MonoDevelop.D-1.9.6.mpack Tools-Add In Manager-Install From File Select the MonoDevelop.D-1.9.6.mpack file. Press Open Dialog Window: The Following Packages will be Installed. D Language Binding v2.1.14 (In User Directory) Follow the info here: http://wiki.dlang.org/Mono-D Mono-d requires a MonoDevelop 5.0, which at the moment you have to build yourself on Ubuntu 14.04. You can find a precompiled version of it here: http://simendsjo.me/files/abothe (Which is also linked to in the wiki above) Hope that helps!
Re: monodevelop mono-d versions
On Friday, 1 August 2014 at 09:12:49 UTC, sclytrack wrote: I can't seem to install mono-d. It always seems to want a newer version of MonoDevelop. I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have this file called MonoDevelop.D-1.9.6.mpack Tools-Add In Manager-Install From File Select the MonoDevelop.D-1.9.6.mpack file. Press Open Dialog Window: The Following Packages will be Installed. D Language Binding v2.1.14 (In User Directory) MonoDevelop has a terrible plugin API compatibility policy which makes Mono-D author only stick to latest released API version unless he wants to maintain dozen of different Mono-D builds :( In practice that means that you pretty much will never be able to use MonoDevelop version from repositories in Ubuntu - need to either build recent version on your own or use /opt/ bundle by simendsjo
Re: monodevelop mono-d versions
On Friday, 1 August 2014 at 13:35:52 UTC, Colin wrote: Which is a pity, as it's otherwise a pretty nice IDE. Still, vim with NERDTree + dub on the command line. What more do you need? DCD vim plugin ;) https://github.com/Hackerpilot/DCD
Re: monodevelop mono-d versions
On Friday, 1 August 2014 at 13:15:25 UTC, Dicebot wrote: On Friday, 1 August 2014 at 09:12:49 UTC, sclytrack wrote: I can't seem to install mono-d. It always seems to want a newer version of MonoDevelop. I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have this file called MonoDevelop.D-1.9.6.mpack Tools-Add In Manager-Install From File Select the MonoDevelop.D-1.9.6.mpack file. Press Open Dialog Window: The Following Packages will be Installed. D Language Binding v2.1.14 (In User Directory) MonoDevelop has a terrible plugin API compatibility policy which makes Mono-D author only stick to latest released API version unless he wants to maintain dozen of different Mono-D builds :( In practice that means that you pretty much will never be able to use MonoDevelop version from repositories in Ubuntu - need to either build recent version on your own or use /opt/ bundle by simendsjo Which is a pity, as it's otherwise a pretty nice IDE. Still, vim with NERDTree + dub on the command line. What more do you need?
Re: Checking for Callabilty of either f(x) or x.f
On Friday, 1 August 2014 at 14:20:55 UTC, Nordlöw wrote: I'm currently developing a pretty printing system in D with backend support for text, html, mathml, latex, etc. See also: https://github.com/nordlow/justd/blob/master/pprint.d
Checking for Callabilty of either f(x) or x.f
I'm currently developing a pretty printing system in D with
backend support for text, html, mathml, latex, etc.
To make it loosely decoupled in compile-time if currently make
use __traits in the following way.
static if (__traits(hasMember, arg, toHTML))
{
if (viz.form == VizForm.HTML)
{
return viz.ppRaw(arg.toHTML);
}
}
else static if (__traits(hasMember, arg, toMathML)) //
TODO: Change to __traits(compiles, auto x = arg.toMathML()) or
*callable*
{
if (viz.form == VizForm.HTML)
{
// TODO: Check for MathML support on backend
return viz.ppRaw(arg.toMathML);
}
}
else static if (__traits(hasMember, arg, toLaTeX))
{
if (viz.form == VizForm.LaTeX)
{
return viz.ppRaw(arg.toLaTeX);
}
}
A more flexible solution is to not require toX to be a member
function of type specific (system) types to printed.
What is the preffered (fast) way to check at compile-time if an
instance x of a type T can be used *either* as
f(x)
or
x.f?
Re: Checking for Callabilty of either f(x) or x.f
On Friday, 1 August 2014 at 14:20:55 UTC, Nordlöw wrote: A more flexible solution is to not require toX to be a member function of type specific (system) types to printed. My suggestions is something like __traits(compiles, auto x = arg.toMathML()) Is this my best option? The snippet __traits(compiles is quite fast right?
Re: monodevelop mono-d versions
On Friday, 1 August 2014 at 09:12:49 UTC, sclytrack wrote: I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have had no problems using this ppa ppa:ermshiperete/monodevelop it has packages for versions 4 and 5: monodevelop-4.0 monodevelop-5
Re: Checking for Callabilty of either f(x) or x.f
On Fri, Aug 01, 2014 at 02:20:53PM +, Nordlöw via Digitalmars-d-learn wrote: [...] What is the preffered (fast) way to check at compile-time if an instance x of a type T can be used *either* as f(x) or x.f? if (is(typeof(f(x))) || is(typeof(x.f))) Basically, is(X) checks if X has a valid type (which include void if f doesn't return anything), and typeof(Y) returns the type of Y if it exists, otherwise it is an error and has no type. So if f(x) doesn't compile, then typeof(f(x)) has no type, and so is(typeof(f(x))) will be false. Ditto for x.f. T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Re: How to detect current executable file name?
On Monday, 18 February 2013 at 03:28:59 UTC, eGust wrote:
I need to locate the directory of current executable file, but
I can't find how to do that in Phobos. I tried
core.runtime.Runtime.args[0], but failed. Is there a standard
method of Phobos to do that? I only know the way of Windows
(GetModuleFileName), but I think as a common task there should
be a platform-independent way to get it in the standard library.
import std.stdio;
import std.file : thisExePath;
import std.path : dirName;
void main(string[] args)
{
writeln(dirName(thisExePath()));
}
Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 11:51:55 UTC, Marc Schütz wrote: On Friday, 1 August 2014 at 04:52:35 UTC, Jonathan M Davis wrote: On Thursday, 31 July 2014 at 22:21:10 UTC, Vlad Levenfeld wrote: Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. It's Andrei's fault. I'm not quite sure what he was thinking. But unfortunately, we're stuck with it. So, it's just become one of D's little quirks that we have to learn and live with. Can we not at least deprecate it? And while we're at it, the same for `dup` and `idup`? It would break too much code to change save at this point. There's no way that you're going to talk Andrei or Walter into changing something like that over whether it makes sense for it to be a property or not. That's not the kind of thing that they think is important, and you're more likely to get Andrei to try and kill of @property again rather than anything useful. As for dup and idup, they were replaced with functions recently (maybe for 2.066 but not 2.065 - i'm not sure when the changes were made), so they might actually work with parens now. I'm not sure. But since dup and idup aren't being implemented by lots of different people like the range API is, changing those doesn't risk breaking code where folks made it a variable. - Jonathan M Davis
Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 19:59:16 UTC, Jonathan M Davis wrote: But since dup and idup aren't being implemented by lots of different people like the range API is, changing those doesn't risk breaking code where folks made it a variable. Well, I probably shouldn't put it quite that way, since that's not the only problem with changing save (which I guess that that statement implies). The real problem with changing save is that we'd have to change the template constraint to use save() to make sure that no one declared it as a variable, and that would break everyone's code who declared save as a property - so, everyone. And _that_ is why save isn't going to change. - Jonathan M Davis
Re: monodevelop mono-d versions
On 08/01/2014 03:15 PM, Dicebot wrote: (...) or use /opt/ bundle by simendsjo By Alexander Bothe. The files are just hosted at my domain.
Re: Emacs d-mode cannot handle backquoted backslashe
On Thursday, 31 July 2014 at 10:04:57 UTC, Nordlöw wrote: Great! See also: https://stackoverflow.com/questions/25089090/emacs-d-mode-cannot-handle-backquoted-backslashes
Re: Checking for Callabilty of either f(x) or x.f
On Friday, 1 August 2014 at 17:17:57 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
if (is(typeof(f(x))) || is(typeof(x.f)))
Here's my try:
template isCallableWith(alias fun, T)
{
enum bool isCallable = is(typeof(fun(T.init))) ||
is(typeof(T.init.fun));
}
unittest {
auto sqr(T)(T x) { return x*x; }
auto xf = isCallableWith!(sqr, int);
}
but errs as
traits_ex.d(182,15): Error: cannot infer type from template
instance isCallableWith!(sqr, int)
Could someone, please, explain how to f and x should be passed in
a template here?
A complete implementation of, say isCallableWith, would be nice.
:)
unittest affects next unittest
Code: http://dpaste.dzfl.pl/51bd62138854 (It was reduced by DustMite.) Have I missed something about structs? Or this simply a bug?
Re: unittest affects next unittest
On Friday, 1 August 2014 at 23:09:39 UTC, sigod wrote: Code: http://dpaste.dzfl.pl/51bd62138854 (It was reduced by DustMite.) Have I missed something about structs? Or this simply a bug? Isn't this the same mistake as: http://forum.dlang.org/thread/muqgqidlrpoxedhyu...@forum.dlang.org#post-mpcwwjuaxpvwiumlyqls:40forum.dlang.org In other words: private Node * _root = new Node(); looks wrong.
Is there a way to map associative arrays
#!/usr/bin/rdmd
import std.algorithm;
import std.stdio;
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
$ ./test.d
./test.d(8): Error: template std.algorithm.map cannot deduce
function from argument types !((a) = a - 2)(uint[uint]),
candidates are:
/usr/include/dmd/phobos/std/algorithm.d(375):
std.algorithm.map(fun...) if (fun.length = 1)
Failed: [dmd, -v, -o-, ./test.d, -I.]
Re: Is there a way to map associative arrays
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue (the first two are eager). If you need both you are out
of luck, and if you want to write safe code it's better to use a
foreach loop. If you want to live dangerously you can use a
test.byKey.zip(test.byValue).
Take a look in Rosettacode, there are examples for all of them.
Bye,
bearophile
Re: Is there a way to map associative arrays
On Friday, 1 August 2014 at 23:22:06 UTC, bearophile wrote:
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue (the first two are eager). If you need both you are
out of luck, and if you want to write safe code it's better to
use a foreach loop. If you want to live dangerously you can use
a test.byKey.zip(test.byValue).
Take a look in Rosettacode, there are examples for all of them.
Bye,
bearophile
Sorry, i wasn't very clear.
I wanted to know if there a way to lazily change the look up
operation
eg:
assert(test[1]==1);
assert(test[2]==2);
Re: Is there a way to map associative arrays
On Friday, 1 August 2014 at 23:33:22 UTC, Freddy wrote:
On Friday, 1 August 2014 at 23:22:06 UTC, bearophile wrote:
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue (the first two are eager). If you need both you are
out of luck, and if you want to write safe code it's better to
use a foreach loop. If you want to live dangerously you can
use a test.byKey.zip(test.byValue).
Take a look in Rosettacode, there are examples for all of them.
Bye,
bearophile
Sorry, i wasn't very clear.
I wanted to know if there a way to lazily change the look up
operation
eg:
assert(test[1]==1);
assert(test[2]==2);
Give your struct/class a method called opIndex.
http://dlang.org/operatoroverloading.html#Array
Trouble linking to static library with Visual D
Hello D'ers, I've been really impressed with Visual D and I've decided to undertake my first D project using Visual D in Visual Studio 2012. However, I've had trouble trying to figure out how to link a static library. I've outlined my situation in this Stack Overflow question. http://stackoverflow.com/questions/25071649/how-to-link-to-packages-in-static-libraries-using-visual-d I would very much appreciate any insight into what I can do to correct the described behavior. Thanks, quakkels
