Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 14:14:43 UTC, Tobias Pankrath
wrote:
On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote:
Hi,
right now I am truing to figure out how the constructors
behave in D2.
Question 1: why it is not possible to create custom ctor for
struct?
The design of D relies on the fact that every type has a T.init
property that is known to the compiler and used when in C++ the
default ctor would get called. In constructors you can rely on
(this == T.init), for example.
You need to pick one T.init or default constructors and D
picked T.init.
The design of D relies on Andrei opinion. He is indeed convinced
that default constructors are impossible.
However, you can write default constructor right now like:
struct S
{
Type t;
this(int)
{
t = whather_is_callable_in_CTFE();
}
}
enum E : S
{
A = S(0)
}
void main()
{
E e;
assert (e.t == whather_is_callable_in_CTFE());
}
Since compiler does this, it can also accept straight syntax and
semantic:
struct S
{
Type t;
this() // proxibited default constructor now
{
t = whather_is_callable_in_CTFE();
}
}
What D really lacks is ability to call function in runtime after
struct instance creation like:
struct S
{
@runtime this() {}
~this(){}
}
lowering to:
S s;
s.__runtime_ctor();
However, since compiler does this all over the place (postblits,
copy constructors, destructors, etc.) There is no conceptual
difference between having:
S s
s.__runtime_ctor();
and
S s;
s.__dtor();
In other words, there is no objective necessity not to have
compile time and runtime default struct constructors since
compiler already heavily does conceptually and technically
similar things.
Re: Scalability in std.parallelism
On Monday, 24 February 2014 at 14:34:14 UTC, Russel Winder wrote: Two cores with hyperthreads generally means a maximum speed up of 2 with optimized native code. Not true. If the code is not trivial and the threads are not doing exactly same instructions (i.e. they can do some search where number of operations depends on data) then 2 cores x 2 hyperthreads can easily provide more than 2x speed up (but far from 4x of course). I see it very often in my video processing code.
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote: Hello I want to define an enum int, but I want to make it possible to set its value when I run dmd from the command line. Is it possible in D? No, D does not allow passing values via the compiler command line. You can use the -debug=xxx or -version=xxx to enable debug(xxx) or version(xxx) blocks. For arbitrary values, you will need intermediary files. You can use the import(filename) construct to read a file from disk during compilation, like so: echo 42 foo.txt cat test.d import std.conv, std.string; enum foo = to!int(import(foo.txt).strip()); ^D dmd -J. test.d
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 12:57:51 UTC, Dejan Lekic wrote:
On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote:
Hello
I want to define an enum int, but I want to make it possible
to set its value when I run dmd from the command line. Is it
possible in D?
Regards
Cherry
D offers version blocks: http://dlang.org/version.html#version
It would be great if D compiler had a way to substitute enums
with given values. (This is a nice candidate for a DIP)
Imagine you have a code like this:
module myproggy;
import std.stdio;
enum foo = 5;
enum bar = walter;
int main() {
writeln(bar);
return foo;
}
... and you call compiler like:
dmd myproggy.d -Dfoo=42 -Dbar=hello
smart, new D compiler would replace enums (iff they exist in
the source code) with the given arguments, so when you run
myproggy, you get walter as output, and the exit code is 42.
And yes, if someone builds multiple modules, he/she would have to
use fully-qualified name. Example: dmd foo.d bar.d -Dfoo.var1=5
-Dbar.var4=walter
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote:
Hello
I want to define an enum int, but I want to make it possible to
set its value when I run dmd from the command line. Is it
possible in D?
Regards
Cherry
D offers version blocks: http://dlang.org/version.html#version
It would be great if D compiler had a way to substitute enums
with given values. (This is a nice candidate for a DIP)
Imagine you have a code like this:
module myproggy;
import std.stdio;
enum foo = 5;
enum bar = walter;
int main() {
writeln(bar);
return foo;
}
... and you call compiler like:
dmd myproggy.d -Dfoo=42 -Dbar=hello
smart, new D compiler would replace enums (iff they exist in the
source code) with the given arguments, so when you run myproggy,
you get walter as output, and the exit code is 42.
Re: D alternative for C/C++ -Dfoo=42
module myproggy;
import std.stdio;
enum foo = 5;
enum bar = walter;
int main() {
writeln(bar);
return foo;
}
... and you call compiler like:
dmd myproggy.d -Dfoo=42 -Dbar=hello
smart, new D compiler would replace enums (iff they exist in
the source code) with the given arguments, so when you run
myproggy, you get walter as output, and the exit code is 42.
I don't like it. I would prefer a CTFE-able counter part to
boost::program_options that generates thouse enums from a config
file.
D alternative for C/C++ -Dfoo=42
Hello I want to define an enum int, but I want to make it possible to set its value when I run dmd from the command line. Is it possible in D? Regards Cherry
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 13:21:38 UTC, bearophile wrote: Dejan Lekic: And yes, if someone builds multiple modules, he/she would have to use fully-qualified name. Example: dmd foo.d bar.d -Dfoo.var1=5 -Dbar.var4=walter If you are interested in such things I suggest you to take a look at how the Fortress language does them. Bye, bearophile No, I am not interested, but thanks. I am interested how D does them, or better say how it may do them...
Re: D alternative for C/C++ -Dfoo=42
Dejan Lekic: And yes, if someone builds multiple modules, he/she would have to use fully-qualified name. Example: dmd foo.d bar.d -Dfoo.var1=5 -Dbar.var4=walter If you are interested in such things I suggest you to take a look at how the Fortress language does them. Bye, bearophile
Re: D alternative for C/C++ -Dfoo=42
I don't like it. I would prefer a CTFE-able counter part to boost::program_options that generates thouse enums from a config file. If you want a config file, you do not need -D args. You simply import() it. Right?
Re: D alternative for C/C++ -Dfoo=42
I don't like it. I would prefer a CTFE-able counter part to boost::program_options that generates thouse enums from a config file. That would be good. I would have taken that approach for my current needs, but I do not see any way to have a fallback if the config file does not exist. I mean mixin import would just fail to compile if the configuration file is not present. I need an option to live with default values if the configuration file is not there. Something like static if(fileExists!config.d) mixin(import(config.d)) else Thoughts? Regards - Cherry
Re: D alternative for C/C++ -Dfoo=42
I would have taken that approach for my current needs, but I do not see any way to have a fallback if the config file does not exist. I mean mixin import would just fail to compile if the configuration file is not present. I need an option to live with default values if the configuration file is not there. Something like static if(fileExists!config.d) mixin(import(config.d)) else For now maybe I could keep an empty/default config.d somewhere in the library source path. And I could use that with multiple -J options. This way dmd configuration from the default path unless it finds the config file in the user path. That should be good enough for me. But I believe this could be made more friendly. Regards - Cherry
Re: D alternative for C/C++ -Dfoo=42
Just a few clarifications For now maybe I could keep an empty/default config.d somewhere in the library source path. I am creating a DSL (Domain Specific Language) library. I am talking about the library src path of my DSL library. And I could use that with multiple -J options. This way dmd configuration from the default path unless it finds the config file in the user path. I figured that DMD will pick import file from the left-most -J path it finds the file in. So all I need is a wrapper over rdmd/dmd that adds a -J. and -Jdefault path (in that order) to the user compile command. Regards - Cherry
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 13:26:20 UTC, Dejan Lekic wrote: I don't like it. I would prefer a CTFE-able counter part to boost::program_options that generates thouse enums from a config file. If you want a config file, you do not need -D args. You simply import() it. Right? Yep, that would be a cleaner solution since it would avoid some pitfalls with the current flags proposal: Should those enums be fully qualified? What if I put all the source files into a single command line (which leads to faster compilation with dmd)? May that override enums by accident? Should every enum be overwriteable or only those that have a specific UDA etc. etc. ? And in the end you are using a build tool anyway and you'll put your config flags into a makefile or something that then becomes an ugly config file.
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
DUB Error
What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve
Re: Struct constructor, opCall mess.
On Tuesday, 25 February 2014 at 07:59:33 UTC, Maxim Fomin wrote:
On Monday, 24 February 2014 at 14:14:43 UTC, Tobias Pankrath
wrote:
On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote:
Hi,
right now I am truing to figure out how the constructors
behave in D2.
Question 1: why it is not possible to create custom ctor for
struct?
The design of D relies on the fact that every type has a
T.init property that is known to the compiler and used when in
C++ the default ctor would get called. In constructors you can
rely on (this == T.init), for example.
You need to pick one T.init or default constructors and D
picked T.init.
The design of D relies on Andrei opinion. He is indeed
convinced that default constructors are impossible.
However, you can write default constructor right now like:
struct S
{
Type t;
this(int)
{
t = whather_is_callable_in_CTFE();
}
}
enum E : S
{
A = S(0)
}
void main()
{
E e;
assert (e.t == whather_is_callable_in_CTFE());
}
Since compiler does this, it can also accept straight syntax
and semantic:
struct S
{
Type t;
this() // proxibited default constructor now
{
t = whather_is_callable_in_CTFE();
}
}
What D really lacks is ability to call function in runtime
after struct instance creation like:
struct S
{
@runtime this() {}
~this(){}
}
lowering to:
S s;
s.__runtime_ctor();
However, since compiler does this all over the place
(postblits, copy constructors, destructors, etc.) There is no
conceptual difference between having:
S s
s.__runtime_ctor();
and
S s;
s.__dtor();
In other words, there is no objective necessity not to have
compile time and runtime default struct constructors since
compiler already heavily does conceptually and technically
similar things.
Thanks for all this replies.
Now I have better idea how it supposed to work.
Yes something like @runtime this() {} would be really great!
https://d.puremagic.com/issues/show_bug.cgi?id=3438
I think at some point we'll need to support default
constructors that execute
code.
This was posted 2009-10-23 and now years later it is still not
possible. :(
Unfortunately this problems and workarounds makes porting C++ to
D2 more complicated.
Here are is also a small experiment that also show that 'ref' is
also necessary in D2 just like in C++.
There seems to be no optimization for this so using 'in' or
nothing at all is slower and may have side effects.
http://melpon.org/wandbox/permlink/FyaksIPW4u1dNpwh
http://d.godbolt.org/#{%22version%22%3A3%2C%22filterAsm%22%3A{%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%2C%22colouriseAsm%22%3Atrue}%2C%22compilers%22%3A[{%22sourcez%22%3A%22JYWwDg9gTgLgBAZxgEwHROcCBuAULgegIFcFgA7AczjCgpgDM4AjAUwGMBDU1uYeLjwSIQnADZjWUOJwQJWIZmICecdhGS9ZcAO50YrMeVT4kUYu3gBlXAG9ccR33LxgeJ3AdOYAC2AIACno%2BAEp7Dw9gOABePncIx1p6BgCAIis1GGg4AFIogB1yVIAaYBDsJy9HAF8qzw8iKAUIADcKaiamHyktcmQ4ZCzpHWAJFl4kl1Z%2BgGY4GFBWBBMPTrgMiDAAQTlgSnIAtfVyJACrEMQwuo9JxjSN7d39uELU8sqExyjY5bcvAEh%2Fk0YMQoOR5n4EHh%2FrUPHUAH6%2BfwBK6fW4pdIDIYvIrvD5OWq1XAtCDAfqiCgoux1DIIACM8UcRFpACYYutGetEHNYlYUZz6eyEDM8NUgAAA%3D%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fgdc%22%2C%22options%22%3A%22-O2%22}]}
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:30:23 UTC, Francesco Cattoglio
wrote:
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
Ok, MY BAD! It works, but I gave him a folder instead of a file.
When you give it a folder instead of a file, it still works but
also outputs an error:
read error, errno = 21
However the else branch is still taken. Well, this went better
than expected!
Re: Scalability in std.parallelism
On Tue, 2014-02-25 at 12:33 +, thedeemon wrote: On Monday, 24 February 2014 at 14:34:14 UTC, Russel Winder wrote: Two cores with hyperthreads generally means a maximum speed up of 2 with optimized native code. Not true. If the code is not trivial and the threads are not doing exactly same instructions (i.e. they can do some search where number of operations depends on data) then 2 cores x 2 hyperthreads can easily provide more than 2x speed up (but far from 4x of course). I see it very often in my video processing code. I suspect the issue here is how compute intensive the code is, are there cache line misses, are there requests out to memory, etc. i.e. non-trivial. My observation and gross over-simplification stems from CPU bound jobs with very localized data, no need for memory writes, and definitely no I/O. This leads to no opportunity for the hyperthreads to contribute anything. I would guess that your video processing uses a cache-friendly (streaming?) algorithm so that the hyperthreads can operate with data already in cache whilst the other gets more data into the cache. This could easily get a 2x speed up on 2 core, 2 hyperthreads machine if the data chunks are of a suitable size and the memory reads and writes are in good rhythm with the calculation done on the data. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Odd Linux linking error
I built some C shared libraries on Mint a while back and everything with my binding worked out fine. I decided to try out ubuntu and on getting everything set up there(using the same previously built shared libs), I am getting an error that I am unfamiliar with. /usr/bin/ld: -f may not be used without -shared I have tried googling it with little success, so I was wondering if someone here could at least help to point me in the right direction. I'm not building a shared library so the addition of a shared switch doesn't seem like the way to go.(Also, I tried adding it anyways, and it just gave me different errors) Is this a D mistake on my part? Should I recompile the libs for ubuntu specifically? Any help would be much appreciated. Thanks as usual!
Re: Odd Linux linking error
Can you post the full command line of the linker invocation?
Re: How to install dmd2 in centos 5.3 x64
same problem: $DMDLOC/dmd2/linux/bin64/dmd hello.d /usr/bin/ld: cannot find -l:libphobos2.a collect2: ld returned 1 exit status --- errorlevel 1 $ cat $DMDLOC/dmd2/linux/bin64/dmd.conf [Environment] DFLAGS=-I%@P%/../../src/phobos -I%@P%/../../src/druntime/import -L-L%@P%/../lib64 -L-L%@P%/../lib32 -L--export-dynamic extracted src from dmd.2.064.2.zip and built phobos and dmd from there. fails even on setting LOAD_LIBRARY paths $ export LD_LOAD_LIBRARY=$DMDLOC/dmd2/linux/lib64 $ export LOAD_LIBRARY=$DMDLOC/dmd2/linux/lib64 $ $DMDLOC/dmd2/linux/bin64/dmd hello.d /usr/bin/ld: cannot find -l:libphobos2.a collect2: ld returned 1 exit status --- errorlevel 1 $ ls $DMDLOC/dmd2/linux/lib64 hello.o libphobos2.a libphobos2.so libphobos2.so.0. libphobos2.so.0..0 libphobos2.so.0..o $ lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: CentOS Description:CentOS release 5.10 (Final) Release:5.10 Codename: Final am i doing something silly here? On Wednesday, 4 December 2013 at 01:27:24 UTC, Puming wrote: On Tuesday, 3 December 2013 at 17:47:47 UTC, Dejan Lekic wrote: On Tuesday, 3 December 2013 at 10:43:06 UTC, Puming wrote: Hi: I followed the steps in http://dlang.org/dmd-linux.html, but when I build a simple hello world program with: rdmd hello.d I get the following error: rdmd hello.d /usr/bin/ld: cannot find -l:libphobos2.a I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but ld still can't find it. Now I really wish all our servers are using ubuntu server.. Could anybody shed some light on where the problem is? I don't have much experience in linux except using apt-get in ubuntu. Thanks. Puming. What architecture that CentOS box is, and give us your /etc/dmd.conf please. model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz Linux 2.6.18-308.el5 #1 SMP EST 2012 x86_64 x86_64 x86_64 GNU/Linux I'm using the the dmd.conf in dmd.2.064.2.zip [Environment] #DFLAGS=-I%@P%/../../src/phobos -I%@P%/../../src/druntime/import -L-L%@P%/../lib64 -L-L%@P%/../lib32 -L--no-warn-search-mismatch -L--export-dynamic DFLAGS=-I%@P%/../../src/phobos -I%@P%/../../src/druntime/import -L-L%@P%/../lib64 -L-L%@P%/../lib32 -L--export-dynamic I commented out the -L--no-warn-search-mismatch because when building there's an error: /usr/bin/ld: unrecognized option '--no-warn-search-mismatch'
alias declaration spec
Grammar spec (http://dlang.org/grammar.html#AliasDeclaration) allows: AliasDeclaration: alias BasicType Declarator DMD allows: alias ref int MyRefInt; Is the ref storage class allowed by the current grammar spec?
Re: How to install dmd2 in centos 5.3 x64
It's not dmd problem, it's up to ld linker and the issue is same for other compiled languages including C and C++. You should specify LD_LIBRARY_PATH variable in your system before executing any compiled D application. You can add export of this environment variable to your $HOME/.profile or $HOME/.bashrc depending on your system or edit paths in /etc/ld.so.conf.d or /etc/ld.so.conf. The other way is to copy libphobos to path where ld can find it by default, for example, /usr/local/lib.
Re: alias declaration spec
On Tuesday, February 25, 2014 22:32:44 cal wrote: Grammar spec (http://dlang.org/grammar.html#AliasDeclaration) allows: AliasDeclaration: alias BasicType Declarator DMD allows: alias ref int MyRefInt; Is the ref storage class allowed by the current grammar spec? No. ref is not part of the BasicType grammar rule. ref is only legal on function parameters, return types, and the variable in a foreach loop and is not part of the type. - Jonathan M Davis
Re: alias declaration spec
On Tuesday, 25 February 2014 at 23:09:43 UTC, Jonathan M Davis wrote: On Tuesday, February 25, 2014 22:32:44 cal wrote: Grammar spec (http://dlang.org/grammar.html#AliasDeclaration) allows: AliasDeclaration: alias BasicType Declarator DMD allows: alias ref int MyRefInt; Is the ref storage class allowed by the current grammar spec? No. ref is not part of the BasicType grammar rule. ref is only legal on function parameters, return types, and the variable in a foreach loop and is not part of the type. - Jonathan M Davis Thanks, I'll file this a grammar bug.
Re: A little of coordination for Rosettacode
Is someone willing to write a D entry for this? http://rosettacode.org/wiki/Rendezvous Bye, bearophile
Runtime dependency checking
http://dpaste.dzfl.pl/80c6225ed090
The code above demonstrates run-time contracts using interface
based programming.
It provides two co-benfits: Simplified class implementation(you
do not have to use interfaces for types which then requires
casting that type for orthogonal behavior) and run-time contracts.
e.g., The WindowsGui class is implemented using WindowsButton and
not iButton. This allows one to avoid having to cast the iButton
to a WindowsButton when one wants to use the featuers of a
WindowsButton.
A contract is created that every iButton used in WindowsGui must
be a WindowsButton or an error is thrown. This creates a run-time
contract or dependency between WindowsGui and WindowsButton.
Normally in such interface based programming the contract is not
automatic and any iButton(for example, a linux button) could be
used for the WindowsGui. Normally this is not desired behavior as
it limits what WindowsGui can do.
Basically when we lift a class to an interface and any objects
used in that class to interfaces we create contract that is in
general too generic(but easier to specify in the language). This
creates generally creates a problem for the implementations of
the interface by forcing them to be more generic than one wants.
To solve this requires casting and type checking to get the more
specific type. The mixin attempts to automate this. It would be
nice if the language was extended to allow covariance on argument
types, e.g.,
interface iGui
{
@property T button(T : iButton)(T button); // Syntax says
that any T can be used as long as it is derived from
iButton(instead of just an iButton)
}
class WindowsGui : iGui
{
@property WindowsButton button(WindowsButton button) { }
// implements the iGui.button property since it satisfies the
contract and also allows us to use the type we actually want to
use. (no explicit casts or checks)
}
Now, WindowsGui.button might be used with an iButton, so an
implicit check is required to make sure that iButton is of
WindowsButton type.
The compiler could handle this quite easily. The mixin emulates
such a feature. The mixin is not robust though.
I seriously doubt that we'll ever get the semantics to handle
this though.
In any case, I think there is real benefit here and it makes it
easier to do modular programming in D with proper dependency
checking(WindowsGui is dependent on WindowsButton, not iButton or
LinuxButton and this dependency is retained even when we use the
iGui and iButton interface).
Now, in the meantime I'll work on tidying up the mixin code but I
was thinking about adding versioning. I could have a version
property in all the types only if the versions have the same
major version are they compatible. So a WindowsGui 3.42 is not
compatible with a WindowsButton 2.89. Not sure if this a good way
or if it will cause headaches later on. (I could keep a file of
all the version compatibilities but that seems excessive)
Any ideas?
output
Trying WindowsButton with WindowsGui!
Do(): WindowsButton
WindowsButton.foo(): I'm an extra WindowsButton feature!
...WindowsButton works in WindowsGui!
Trying WindowsBorder with WindowsGui!
Do(): WindowsBorder
WindowsBorder.foo(): I'm an extra WindowsBorder feature!
...WindowsBorder works in WindowsGui!
Trying LinuxBorder with WindowsGui!
Invalid object type dependency mismatch! Type: f872.LinuxBorder
Type Expected: WindowsBorder
Trying LinuxButton with WindowsGui!
Invalid object type dependency mismatch! Type: f872.LinuxButton
Type Expected: WindowsButton
Trying WindowsButton with LinuxGui!
Invalid object type dependency mismatch! Type: f872.WindowsButton
Type Expected: LinuxButton
Trying LinuxButton with LinuxGui!
Do(): LinuxButton
...LinuxButton works in LinuxGui!
Trying WindowsBorder with LinuxGui!
Invalid object type dependency mismatch! Type: f872.WindowsBorder
Type Expected: LinuxBorder
Trying LinuxBorder with LinuxGui!
Do(): LinuxBorder
...LinuxBorder works in LinuxGui!
Re: How to install dmd2 in centos 5.3 x64
i already tried LD_LIBRARY_PATH (and alternatives), however, looking deeper it seems like the admin has disabled LD_LIBRARY_PATH on this system (work terminal): http://stackoverflow.com/questions/9843178/linux-capabilities-setcap-seems-to-disable-ld-library-path On Tuesday, 25 February 2014 at 22:37:28 UTC, FreeSlave wrote: It's not dmd problem, it's up to ld linker and the issue is same for other compiled languages including C and C++. You should specify LD_LIBRARY_PATH variable in your system before executing any compiled D application. You can add export of this environment variable to your $HOME/.profile or $HOME/.bashrc depending on your system or edit paths in /etc/ld.so.conf.d or /etc/ld.so.conf. The other way is to copy libphobos to path where ld can find it by default, for example, /usr/local/lib.
Re: DUB Error
On Tuesday, 25 February 2014 at 14:32:42 UTC, Steve Teale wrote: What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve The path you have provide is an absolute path, I suspect that somewhere in the code it is doing something like: buildPath(curDir, importPath); However, buildPath doesn't have a check for appending absolute path, so probably a custom path library which is basically saying your ignoring the working directory.
Re: A little of coordination for Rosettacode
On 02/25/2014 03:48 PM, bearophile wrote:
Is someone willing to write a D entry for this?
http://rosettacode.org/wiki/Rendezvous
Bye,
bearophile
I think the following satisfies the requirements. Improve at will! :p
import std.stdio;
import std.exception;
import std.array;
import std.concurrency;
import std.datetime;
import core.thread;
class OutOfInk : Exception
{
this()
{
super(Out of ink.);
}
}
struct Printer
{
string id;
size_t ink;
void print(string line)
{
enforce(ink != 0, new OutOfInk);
writefln(%s: %s, id, line);
--ink;
}
}
struct PrinterRendezvous
{
Printer[] printers;
void print(string[] lines) shared
{
Exception savedException;
while (true) {
if (lines.empty) {
break;
}
if (printers.empty) {
// No more printers to try
assert(savedException !is null);
throw savedException;
}
try {
synchronized {
(cast(Printer)printers.front).print(lines.front);
}
lines.popFront();
// Increase the chance of interleaved output
Thread.sleep(10.msecs);
} catch (OutOfInk exc) {
savedException = exc;
synchronized {
// Switch to the next printer
printers = printers[1..$];
}
}
}
}
}
void humptyDumptyTask(ref shared(PrinterRendezvous) rendezvous)
{
auto humptyDumpty = [ Humpty Dumpty sat on a wall.,
Humpty Dumpty had a great fall.,
All the king's horses and all the king's men,,
Couldn't put Humpty together again., ];
rendezvous.print(humptyDumpty);
}
void motherGooseTask(ref shared(PrinterRendezvous) rendezvous)
{
auto motherGoose = [ Old Mother Goose,,
When she wanted to wander,,
Would ride through the air,,
On a very fine gander.,
Jack's mother came in,,
And caught the goose soon,,
And mounting its back,,
Flew up to the moon., ];
rendezvous.print(motherGoose);
}
void main()
{
auto rendezvous = shared(PrinterRendezvous)([ Printer(main, 5),
Printer(reserve, 5) ]);
spawn(humptyDumptyTask, rendezvous);
spawn(motherGooseTask, rendezvous);
}
Sample output:
main: Humpty Dumpty sat on a wall.
main: Old Mother Goose,
main: Humpty Dumpty had a great fall.
main: When she wanted to wander,
main: All the king's horses and all the king's men,
reserve: Would ride through the air,
reserve: Couldn't put Humpty together again.
reserve: On a very fine gander.
reserve: Jack's mother came in,
reserve: And caught the goose soon,
deneme.OutOfInk@deneme.d([...]): Out of ink.
Ali
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 13:26:20 UTC, Dejan Lekic wrote: I don't like it. I would prefer a CTFE-able counter part to boost::program_options that generates thouse enums from a config file. If you want a config file, you do not need -D args. You simply import() it. Right? or import myconfig; and specify -I path to myconfig.d instead of -J path.
Re: DUB Error
On Wednesday, 26 February 2014 at 03:33:38 UTC, Jesse Phillips wrote: On Tuesday, 25 February 2014 at 14:32:42 UTC, Steve Teale wrote: What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve The path you have provide is an absolute path, I suspect that somewhere in the code it is doing something like: buildPath(curDir, importPath); However, buildPath doesn't have a check for appending absolute path, so probably a custom path library which is basically saying your ignoring the working directory. I guess I was misunderstanding 'importPaths'. I got a little further along when I used dflags: [/usr/local/include/d/gtkd-2] instead. But you'd think that since it is targeting D, importFlags might have that purpose. Steve
Re: Odd Linux linking error
On Tuesday, 25 February 2014 at 19:41:54 UTC, Marc Schütz wrote: Can you post the full command line of the linker invocation? It was done through Mono-D, so to answer this for you I went and tried do it on a command line. I got some different errors, so I'm currently working on fixing them. It looks like ubuntu really just didn't like the pre built shared libraries I had. I'm post again tomorrow if I'm still getting the same issue.
