Re: linker errors after upgrade to Ubuntu 11.10
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article > Ubuntu made some changes to the linker. See if this information helps and > report back. This is from a post in digitalmars.D > "Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent > linker errors referencing librt. "-L-lphobos2" needs to be added to DFLAGS > before "-L-lrt". I spent a long time trying to figure the problem out > before I realized that gcc was tacking on a -lphobos2 to the END of the > command (after the -lrt flag). > "This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may > explain the behavior, I'm not sure." Justin Whear Yup, that did the trick! Everything is working just fine now as far as I can tell.
Re: linker errors after upgrade to Ubuntu 11.10
On Monday, October 24, 2011 03:45:14 Jesse Phillips wrote: > Ubuntu made some changes to the linker. See if this information helps and > report back. This is from a post in digitalmars.D > > "Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent > linker errors referencing librt. "-L-lphobos2" needs to be added to DFLAGS > before "-L-lrt". I spent a long time trying to figure the problem out > before I realized that gcc was tacking on a -lphobos2 to the END of the > command (after the -lrt flag). > > "This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may > explain the behavior, I'm not sure." Justin Whear It will be fixed with the next release. -L-lrt won't even be needed in dmd.conf anymore. It's being linked in by the compiler just like libpthread is. - Jonathan M Davis
Re: linker errors after upgrade to Ubuntu 11.10
Ubuntu made some changes to the linker. See if this information helps and report back. This is from a post in digitalmars.D "Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent linker errors referencing librt. "-L-lphobos2" needs to be added to DFLAGS before "-L-lrt". I spent a long time trying to figure the problem out before I realized that gcc was tacking on a -lphobos2 to the END of the command (after the -lrt flag). "This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may explain the behavior, I'm not sure." Justin Whear
Re: Looking for documentation of D's lower-level aspects.
== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article > Less efficient is a moot point. > When you do iteration and other stuff you'd use range, like you'd use > iterators in c++. Range gets stack/register allocated pointers directly > to data (or close to it, that depends on container) so the only extra > cost in reference type compared to value is the first indirect access to > construct range and it's negligible. The problem isn't the speed of iteration, it's the extra heap traffic that is involved. I mean, for you average app this isn't going to matter; those are the apps that can just as easily be written in Java/C#. But it can be a problem for serious systems code (the kind that is pretty much always written in C/C++). For example, if you look in the LLVM source tree, you'll see that they bend over backwards to avoid heap allocations. For example, in some cases, std::vector causes too much heap traffic so they have SmallVector which preallocates a certain amount of storage *inside* of the object itself in order to avoid heap traffic if the number of elements doesn't exceed some predetermined amount. Even still, LLVM uses std::vector all over the place, and it I've never seen a std::vector embedded in a class by reference; it is always held by value precisely because then you don't do an unnecessary heap allocation. I'm positive that if std::vector involved a heap allocation for the vector object itself, llvm would basically have rewritten a heap-less vector object, just like they have done in the more extreme case for SmallVector. But the thing is that in D, it is possible to write an easy-to-use vector for which it is a one-liner to switch between GC heap-allocated vector object, by-value vector, preallocated internal vector (like SmallVector), and beyond! I admit, I'm very biased because my use case for D is low-level systems programming a la C/C++, so naturally I want a standard library that will not compromise on aspects that are important for the kinds of programs that I write. Nonetheless, if the goal is to have "good enough" containers, then it doesn't matter, but if the goal is to have "truly optimal" containers (as I think it should be; D is certainly powerful enough to pull it off elegantly), then it does matter.
linker errors after upgrade to Ubuntu 11.10
I just upgraded to Ubuntu 11.10 (from 11.04). I have attached the error
message. It looks like it is a problem with a reference to
`clock_gettime`.
Any suggestions?
begin 644 errs.txt
M+W5S"UG;G4O-"XV+C$O+BXO+BXO+BXO
M+BXO;&EB+VQI8G!H;V)O'0N7T0S&ET('-T
%871U
Re: What is shared functions?
Jonathan M Davis: > my general take on it is that dmd should _never_ ignore attributes, I agree. Such sloppiness is a very good source for problems, long term ones too, and it makes it harder to learn D. Bye, bearophile
Re: Random, not so random?
I'm thinking something like this is appropriate, though I removed the save () feature. https://gist.github.com/1307739
Re: What is shared functions?
On Sunday, October 23, 2011 20:22:01 simendsjo wrote:
> On 23.10.2011 20:14, Jonathan M Davis wrote:
> > On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
> >> What does shared for functions mean? I thought it was supposed to
> >> automatically synchronize access, but this doesn't seem to be the
> >> case.
> >>
> >> void f() shared {
> >> // no synchronization
> >> }
> >>
> >> void f() {
> >>
> >> synchronized {
> >>
> >> // do stuff
> >>
> >> }
> >>
> >> }
> >
> > shared doesn't automatically synchronize anything. I believe that it
> > makes some guarantees about instruction ordering not being messed with
> > by the compiler, but I'm not sure. I'd have to go look it up in TDPL
> > though. Regardless, on a _function_, I don't think that shared does
> > anything. D probably ignores it. It tends to do that with incorrect
> > attributes. It _might_ do something though. I don't know.
> >
> > - Jonathan M Davis
>
> Guess it's about time to buy TDPL.
> I remember D ignoring protection attributes before, but this is a bug now:
> private public class C {}
> t.d(1): redundant protection attribute
>
> So I guess shared has an effect on functions (or the missing error is a
> bug).
Not necessarily. There are a number of attributes that I belive that it will
continue to ignore in the interest of reducing errors with generated code.
Just because it happens to complain in one particular case doesn't mean that
it's been fixed in general. I believe that it's always been the case that dmd
complains in some cases and not in others. It _is_ a bit annoying though.
Maybe it would cause problems for generated code, by my general take on it is
that dmd should _never_ ignore attributes, but that's not the way that it
works unfortunately,
So, it may be that shared does something here. It may be that it's ignored,
and if it's ignored it may or may not be a bug that it compiles without error.
- Jonathan M Davis
Re: What is shared functions?
On 23.10.2011 20:14, Jonathan M Davis wrote:
On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
What does shared for functions mean? I thought it was supposed to
automatically synchronize access, but this doesn't seem to be the case.
void f() shared {
// no synchronization
}
void f() {
synchronized {
// do stuff
}
}
shared doesn't automatically synchronize anything. I believe that it makes
some guarantees about instruction ordering not being messed with by the
compiler, but I'm not sure. I'd have to go look it up in TDPL though.
Regardless, on a _function_, I don't think that shared does anything. D
probably ignores it. It tends to do that with incorrect attributes. It _might_
do something though. I don't know.
- Jonathan M Davis
Guess it's about time to buy TDPL.
I remember D ignoring protection attributes before, but this is a bug now:
private public class C {}
t.d(1): redundant protection attribute
So I guess shared has an effect on functions (or the missing error is a
bug).
Re: What is shared functions?
On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
> What does shared for functions mean? I thought it was supposed to
> automatically synchronize access, but this doesn't seem to be the case.
>
> void f() shared {
> // no synchronization
> }
>
> void f() {
>synchronized {
> // do stuff
>}
> }
shared doesn't automatically synchronize anything. I believe that it makes
some guarantees about instruction ordering not being messed with by the
compiler, but I'm not sure. I'd have to go look it up in TDPL though.
Regardless, on a _function_, I don't think that shared does anything. D
probably ignores it. It tends to do that with incorrect attributes. It _might_
do something though. I don't know.
- Jonathan M Davis
Re: AI Challenge - Ants
On Sun, 23 Oct 2011 16:24:09 +0200, maarten van damme wrote: > I'm noticing some problems, there are some methods missing used in the > tutorial like "unocupied", the do_setup part and the visible method. Is > this package complete or am I missing something? > I'm noticing some problems, there are some methods missing used in > the tutorial like "unocupied", the do_setup part and the > visible method. Is this package complete or am I missing something? It doesn't appear to perfectly match the tutorial. I'm not sure if the tutorial is intended to have you write in the details (didn't check if the Java version provided them). But that is what I did anyway. The one issue I've run into is trying to use the seed, details in the Random, not so random? post.
Random, not so random?
In this little code example I'm trying to use the same random number
generator to produce a randomCover over an array multiple times.
I make 4 assertions, the first two pass, the last two fail. One of the
benefits for providing a seed to a generator is that you can reproduce
the behavior, but at the same time the generator can be used throughout
the program to create random events. Instead, the events are the same.
This is a bug right?
import std.array;
import std.conv;
import std.random;
void main() {
auto arr = [1,2,3,4];
auto gen = Random(unpredictableSeed);
assert(randomCover(arr,gen) != randomCover(arr,gen));
auto result1 = randomCover(arr,gen);
auto result2 = randomCover(arr,gen);
assert(result1 != result2);
auto arr1 = array(randomCover(arr,gen));
auto arr2 = array(randomCover(arr,gen));
assert(arr1 != arr2);
auto str1 = to!string(randomCover(arr,gen));
auto str2 = to!string(randomCover(arr,gen));
assert(str1 != str2);
}
Re: AI Challenge - Ants
I'm noticing some problems, there are some methods missing used in the tutorial like "unocupied", the do_setup part and the visible method. Is this package complete or am I missing something?
Re: ZeroMQ wrapper for D2
On 23.10.2011 14:25, Kean Forrest wrote: ZMQ seems almost too good, I never knew it existed. If D had this as a networking/concurrency method it would be a huge plus AFAIK. Together with std.parallelism, std.concurrency and the upcoming Thrift implementation this makes D quite capable for writing high-performance distributed applications.
Re: ZeroMQ wrapper for D2
On 23.10.2011 14:25, Kean Forrest wrote:
On 22/10/11 23:24, simendsjo wrote:
I saw someone mention ZeroMQ in a subthread the other day. I watched a
few videos, and it looks to me like a good fit for D. The philosophies
matches pretty well: small, clean api, no bloat (only transport, no
protocols), very flexible setup/usage and message passing for
communication.
+1
ZMQ seems almost too good, I never knew it existed. If D had this as a
networking/concurrency method it would be a huge plus AFAIK.
Agreed. IPC doesn't work on windows though. Not sure if this
could/should be simulated to some degree.
This wrapper (2.1.10 stable) is closer to the python version:
http://min.us/lOZ88QxPWyB6q
Hello world:
import zmq.zmq;
import std.stdio;
void main()
{
auto ctx = new Context();
version(client)
{
auto sock = ctx.socket(ZMQ_REQ);
sock.connect("tcp://localhost:");
sock.send("hello");
writeln(sock.recv!string);
}
else
{
auto sock = ctx.socket(ZMQ_REP);
sock.bind("tcp://*:");
writeln(sock.recv!string);
sock.send("world");
}
}
Pretty similar to what I did. Zeromq's porting guide recommend using
available language features and naming standards, so I added a default
context using shared and module ctor/dtor's and named enums according to
phobos rules. Already found some bugs with my wrapper though :)
version(client)
{
auto sock = connect("tcp://localhost:", SocketType.request);
sock.send("hello");
writeln(sock.receive!string());
}
else
{
auto sock = bind("tcp://*:");
writeln(sock.receive!string());
sock.send("world");
}
The default context is only created on the first call to connect/bind,
so you can avoid this and write it as:
auto ctx = new Context();
auto sock = ctx.create(SocketType.request);
...
I'm in the process of porting more of the examples to my wrapper to see
how it holds up. I'll post updated code once I get a little further.
But I really don't know enough D or zmq to write a good wrapper. It
would be great if you (or someone else) could write a wrapper.
Re: ZeroMQ wrapper for D2
On 23.10.2011 14:47, Johannes Pfau wrote: simendsjo wrote: I saw someone mention ZeroMQ in a subthread the other day. I watched a few videos, and it looks to me like a good fit for D. The philosophies matches pretty well: small, clean api, no bloat (only transport, no protocols), very flexible setup/usage and message passing for communication. Someone with experience with D and zmq could probably finish a good wrapper in a couple of days. The D binding on their website is for v2.1 using D1 and tango, so I hacked together a wrapper for 3.0.2 with several examples from the guide. Hopefully this hack motivates someone to write a complete wrapper. http://dl.dropbox.com/u/36543537/dzmq.zip zmq.d = zmq.h translation dzmq.d = d-ified wrapper zguide-examples/* = translated examples from the guide. It's only tested on windows, and the .lib and .dll is included in the archive. Shouldn't be much problems running on linux either though, but you'll have to download zmq from github. Have you thought about submitting the zmq.d file to deimos? https://github.com/D-Programming-Language/deimos That would probably boost it's publicity in the D community. Not sure how we should handle versioning. This is a translation of the unstable 3.0.2. We should also have the stable version there.
Re: ZeroMQ wrapper for D2
simendsjo wrote: >I saw someone mention ZeroMQ in a subthread the other day. I watched a >few videos, and it looks to me like a good fit for D. The philosophies >matches pretty well: small, clean api, no bloat (only transport, no >protocols), very flexible setup/usage and message passing for >communication. > >Someone with experience with D and zmq could probably finish a good >wrapper in a couple of days. > >The D binding on their website is for v2.1 using D1 and tango, so I >hacked together a wrapper for 3.0.2 with several examples from the >guide. Hopefully this hack motivates someone to write a complete >wrapper. > >http://dl.dropbox.com/u/36543537/dzmq.zip > >zmq.d = zmq.h translation >dzmq.d = d-ified wrapper >zguide-examples/* = translated examples from the guide. > >It's only tested on windows, and the .lib and .dll is included in the >archive. Shouldn't be much problems running on linux either though, >but you'll have to download zmq from github. Have you thought about submitting the zmq.d file to deimos? https://github.com/D-Programming-Language/deimos That would probably boost it's publicity in the D community. -- Johannes Pfau
What is shared functions?
What does shared for functions mean? I thought it was supposed to
automatically synchronize access, but this doesn't seem to be the case.
void f() shared {
// no synchronization
}
void f() {
synchronized {
// do stuff
}
}
Re: ZeroMQ wrapper for D2
On 22/10/11 23:24, simendsjo wrote:
I saw someone mention ZeroMQ in a subthread the other day. I watched a
few videos, and it looks to me like a good fit for D. The philosophies
matches pretty well: small, clean api, no bloat (only transport, no
protocols), very flexible setup/usage and message passing for
communication.
+1
ZMQ seems almost too good, I never knew it existed. If D had this as a
networking/concurrency method it would be a huge plus AFAIK.
This wrapper (2.1.10 stable) is closer to the python version:
http://min.us/lOZ88QxPWyB6q
Hello world:
import zmq.zmq;
import std.stdio;
void main()
{
auto ctx = new Context();
version(client)
{
auto sock = ctx.socket(ZMQ_REQ);
sock.connect("tcp://localhost:");
sock.send("hello");
writeln(sock.recv!string);
}
else
{
auto sock = ctx.socket(ZMQ_REP);
sock.bind("tcp://*:");
writeln(sock.recv!string);
sock.send("world");
}
}
Re: scope struct?
Steve Teale , dans le message (digitalmars.D.learn:30117), a écrit :
> Is not needed because structs are inherently scope.
>
> I'm sure experienced D programmers do this all the time when they want
> something done on exit from a scope, but I never had, and maybe there are
> others who haven't, particularly if coming from a C++ 'use classes for
> everything' background.
>
> import std.stdio;
>
> bool glob;
>
> struct Sentinel
> {
>void function() doit;
>bool already;
>this(void function() f)
>{
> doit = f;
> already = false;
>}
>
>~this()
>{
> if (!already)
> {
> writeln("Doing it now");
> doit();
> }
> else
> writeln("Won't bother");
>}
>
>void dontBother() { already = true; }
> }
>
> void reset() { glob = false; }
>
> void main(string[] args)
> {
>glob = true;
>{
> Sentinel s = Sentinel(&reset);
> writeln("Doing stuff in the scope");
> if (args.length >= 2 && args[1] == "db")
> s.dontBother();
>}
>writeln(glob);
> }
void main(string[] args)
{
glob = true;
{
dontBother=false;
scope(exit)
{
if (!dontBother)
{
writeln("Doing it now");
glob = false;
}
else
{
writeln("Don't bother");
}
}
writeln("Doing stuff in the scope");
if (args.length >= 2 && args[1] == "db")
dontBother() = true;
}
writeln(glob);
}
If you're not running a test with a lot of writing, the scope clause is
just:
scope(exit) if (!dontBother) glob() = false;
The scope exit clause will be run even if you exit via an exception
(just like the sentinel's dstructor).
As you can see, D as its own syntax to make things when the scope exits,
so you don't need to build a sentinel struct.
http://d-programming-language.org/exception-safe.html
Re: Looking for documentation of D's lower-level aspects.
On 23.10.2011 7:25, Sean Silva wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article On Sunday, October 23, 2011 00:01:42 Sean Silva wrote: They're all supposed to be reference types. What prompted the decision for that? Doesn't that incur an extra heap allocation for the containers, and an extra level of indirection? I mean, with value-semantics like STL containers, you can use it like a value, e.g. as a local in a function, and have no overhead, AFAIK using e.g. local vector only a small bunch of info is stored on stack (ptr, length, capacity, whatever else). It still allocates it's elements on heap. Plus there are ways to place class instance on stack or anywhere else (e. g. some scratch memory page) if you really need to, look for emplace in phobos. but if you want to wrap a class around it and have it by reference, then you can, and it is no less efficient than if the containers were written that way. But if the containers are already by reference, you can't return them to having value semantics without adding even more indirection and inefficiency. Less efficient is a moot point. When you do iteration and other stuff you'd use range, like you'd use iterators in c++. Range gets stack/register allocated pointers directly to data (or close to it, that depends on container) so the only extra cost in reference type compared to value is the first indirect access to construct range and it's negligible. -- Dmitry Olshansky
