Re: more fun with ubuntu
On 05/25/2013 10:20 PM, estew wrote:
On Sunday, 26 May 2013 at 05:01:10 UTC, Ellery Newcomer wrote:
I have a project here which fails on link on ubuntu 12.10.
It give undefined reference errors for functions in libdl and libutil.
For some reason, ld won't cooperate unless you pass -ldl -lutil at the
end of the command string. Holy Ubuntu!
I can't seem to get dmd to do this though. Any suggestions?
I am using the beta, but apparently this is a thing with ubuntu.
I have the same on Fedora 18 using derelict and some other D libs which
I can't remember right now. My understanding is derelict requires libdl
for dynamic loading of libs at runtime.
My compiler flags are similar to this:
dmd -gc -w -Iderelict_import_dir -L-Lderelict_lib_dir -L-lDerelictGL3
-L-lDerelictGLFW3 -L-lDerelictUtil -L-lGL -L-lGLU -L-lglfw -L-ldl myapp.d
Could you post your compiler command line?
Cheers,
Stewart
huh. I haven't run into it on fedora. python is built differently, though.
dmd -L-lpthread -L-ldl -L-lutil -L-L/usr/lib -L-lz
/usr/lib/python2.7/config/libpython2.7.a -debug
-ofbuild/lib.linux-x86_64-2.7/link {lotsaobjectfiles} -L-ldl -L-lutil -v
Re: more fun with ubuntu
huh. I haven't run into it on fedora. python is built
differently, though.
dmd -L-lpthread -L-ldl -L-lutil -L-L/usr/lib -L-lz
/usr/lib/python2.7/config/libpython2.7.a -debug
-ofbuild/lib.linux-x86_64-2.7/link {lotsaobjectfiles} -L-ldl
-L-lutil -v
Well, that should work fine, although the libs are generally
referenced after the object files that require them, which you
have for dl and util.
ld changed a while back now (around Fedora 13 or 14 I think)
which introduced similar behaviour. This may provide some more
information or links:
http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
Sorry I cannot really helphopefully a D/Linux guru out there
know more?
Cheers,
Stewart
Re: Passing large or complex data structures to threads
On 05/24/2013 04:39 PM, Simen Kjaeraas wrote:
First, *is* it read-only? If so, store it as immutable and enjoy free
sharing. If not, how and why not?
I can confess that it's as simple as feeling extremely uncomfortable dealing
with immutable where it relates to any kind of complex data structure.
I mean, for that double array structure I'd have to do something like,
Tuple!(size_t, size_t)[][] dataCopy;
foreach(x; data) {
Tuple!(size_t, size_t)[] xCopy;
foreach(y; x) {
immutable(Tuple!(size_t, size_t)) yCopy = y.idup;
xCopy ~= cast(Tuple!(size_t, size_t)) yCopy;
}
immutable xImm = assumeUnique(xCopy);
dataCopy ~= cast(Tuple!(size_t, size_t)[]) xImm;
}
immutable dataImm = assumeUnique(dataCopy);
... no? Which feels like a lot of hassle compared to just being able to pass
each thread the information to independently load the required data.
I'd be delighted to discover I'm wrong about the hassle of converting the data
to immutable -- I don't think I understand how to use it at all well, bad
experiences in the past have meant that I've tended to avoid it.
Re: Passing large or complex data structures to threads
On 05/24/2013 05:59 PM, Ali Çehreli wrote: The following simple example uses mutable data but it should work with 'const' too. Limiting ourselves to read-only, won't there still be a slowdown caused by multiple threads trying to access the same data? The particular case I have will involve continuous reading from the data concerned.
Re: Passing large or complex data structures to threads
On Sun, 26 May 2013 14:06:39 +0200, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 05/24/2013 04:39 PM, Simen Kjaeraas wrote:
First, *is* it read-only? If so, store it as immutable and enjoy free
sharing. If not, how and why not?
I can confess that it's as simple as feeling extremely uncomfortable
dealing
with immutable where it relates to any kind of complex data structure.
I mean, for that double array structure I'd have to do something like,
Tuple!(size_t, size_t)[][] dataCopy;
foreach(x; data) {
Tuple!(size_t, size_t)[] xCopy;
foreach(y; x) {
immutable(Tuple!(size_t, size_t)) yCopy = y.idup;
xCopy ~= cast(Tuple!(size_t, size_t)) yCopy;
}
immutable xImm = assumeUnique(xCopy);
dataCopy ~= cast(Tuple!(size_t, size_t)[]) xImm;
}
immutable dataImm = assumeUnique(dataCopy);
... no? Which feels like a lot of hassle compared to just being able to
pass
each thread the information to independently load the required data.
I'd be delighted to discover I'm wrong about the hassle of converting
the data
to immutable -- I don't think I understand how to use it at all well, bad
experiences in the past have meant that I've tended to avoid it.
That looks very complex for what it purports to do.
I understand data is the original data before sharing?
If so, will that a
--
Simen
Re: Passing large or complex data structures to threads
On Sun, 26 May 2013 14:06:39 +0200, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 05/24/2013 04:39 PM, Simen Kjaeraas wrote:
First, *is* it read-only? If so, store it as immutable and enjoy free
sharing. If not, how and why not?
I can confess that it's as simple as feeling extremely uncomfortable
dealing
with immutable where it relates to any kind of complex data structure.
I mean, for that double array structure I'd have to do something like,
Tuple!(size_t, size_t)[][] dataCopy;
foreach(x; data) {
Tuple!(size_t, size_t)[] xCopy;
foreach(y; x) {
immutable(Tuple!(size_t, size_t)) yCopy = y.idup;
xCopy ~= cast(Tuple!(size_t, size_t)) yCopy;
}
immutable xImm = assumeUnique(xCopy);
dataCopy ~= cast(Tuple!(size_t, size_t)[]) xImm;
}
immutable dataImm = assumeUnique(dataCopy);
... no? Which feels like a lot of hassle compared to just being able to
pass
each thread the information to independently load the required data.
I'd be delighted to discover I'm wrong about the hassle of converting
the data
to immutable -- I don't think I understand how to use it at all well, bad
experiences in the past have meant that I've tended to avoid it.
That looks very complex for what it purports to do.
I understand data is the original data before sharing?
If so, will that array ever change again?
I think a bit more information is needed. I'm going to assume this is
(roughly) how things work:
1. Read from file/generate/load from database/create data.
2. Share data with other threads.
3. Never change data again.
If this is correct, this should work:
Tuple!(size_t, size_t)[][] data = createData();
immutable dataImm = assumeUnique(data);
data = null; // Simply to ensure no mutable references exist.
sendToOtherThreads(dataImm);
And that's it. If nobody's going to change the data again, it's perfectly
safe to tell the compiler 'this is now immutable'. No copies need to be
made, no idup, no explicit casting (except that done internally by
assumeUnique), no troubles.
--
Simen
Re: Passing large or complex data structures to threads
On Sunday, 26 May 2013 at 12:08:41 UTC, Joseph Rushton Wakeling wrote: On 05/24/2013 05:59 PM, Ali Çehreli wrote: The following simple example uses mutable data but it should work with 'const' too. Limiting ourselves to read-only, won't there still be a slowdown caused by multiple threads trying to access the same data? The particular case I have will involve continuous reading from the data concerned. Not necessarily. It really depends on the memory access patterns of the algorithms, the number of threads, the size of the data, the number/size/hierarchy of cpu caches, the number of CPUs. Hard and fast rule: If your threads are reading data that is distant (i.e. one thread reading from around the beginning of a long array, the second reading from the end) then the fact that they happen to be the same data object is irrelevant. Also, remember that in the short term the CPUs are all keeping their own independent copies of the relevant parts of the data in caches anyway.
lookup fields struct
Hi!
I am want to get list of fields types and offsets in struct by
the template.
I.e., lookup through this struct:
struct S {
int a;
string b;
someptr* c;
};
template Lookup!( S )(); returns something as:
field #0, int, offset 0
field #1, string, offset 8,
field #2, someptr, offset 16
How I can do this?
Re: more fun with ubuntu
On Sunday, 26 May 2013 at 05:01:10 UTC, Ellery Newcomer wrote: I have a project here which fails on link on ubuntu 12.10. It give undefined reference errors for functions in libdl and libutil. For some reason, ld won't cooperate unless you pass -ldl -lutil at the end of the command string. Holy Ubuntu! I can't seem to get dmd to do this though. Any suggestions? I am using the beta, but apparently this is a thing with ubuntu. It is not uncommon to request the libraries needed to build your app. Dmd passes a couple/one for phobos dependencies, but other libraries need to be reqested.
Re: lookup fields struct
On Sunday, 26 May 2013 at 14:19:13 UTC, mimi wrote:
Hi!
I am want to get list of fields types and offsets in struct by
the template.
I.e., lookup through this struct:
struct S {
int a;
string b;
someptr* c;
};
template Lookup!( S )(); returns something as:
field #0, int, offset 0
field #1, string, offset 8,
field #2, someptr, offset 16
How I can do this?
std.traits and built-in traits should do what u asking.
http://dlang.org/phobos/std_traits.html
http://dlang.org/traits.html
Re: more fun with ubuntu
On 05/26/2013 07:55 AM, Jesse Phillips wrote: On Sunday, 26 May 2013 at 05:01:10 UTC, Ellery Newcomer wrote: I have a project here which fails on link on ubuntu 12.10. It give undefined reference errors for functions in libdl and libutil. For some reason, ld won't cooperate unless you pass -ldl -lutil at the end of the command string. Holy Ubuntu! I can't seem to get dmd to do this though. Any suggestions? I am using the beta, but apparently this is a thing with ubuntu. It is not uncommon to request the libraries needed to build your app. Dmd passes a couple/one for phobos dependencies, but other libraries need to be reqested. I am doing that. I think the problem is libpython2.7.a requires libdl and libutil, and ld requires -ldl and -lutil be positioned after libpython2.7.a, but dmd very stubbornly arranges them before libpython2.7.a in the call to gcc.
Re: more fun with ubuntu
On 05/26/2013 08:10 AM, Ellery Newcomer wrote: On 05/26/2013 07:55 AM, Jesse Phillips wrote: On Sunday, 26 May 2013 at 05:01:10 UTC, Ellery Newcomer wrote: I have a project here which fails on link on ubuntu 12.10. It give undefined reference errors for functions in libdl and libutil. For some reason, ld won't cooperate unless you pass -ldl -lutil at the end of the command string. Holy Ubuntu! I can't seem to get dmd to do this though. Any suggestions? I am using the beta, but apparently this is a thing with ubuntu. It is not uncommon to request the libraries needed to build your app. Dmd passes a couple/one for phobos dependencies, but other libraries need to be reqested. I am doing that. I think the problem is libpython2.7.a requires libdl and libutil, and ld requires -ldl and -lutil be positioned after libpython2.7.a, but dmd very stubbornly arranges them before libpython2.7.a in the call to gcc. dmd -unittest -property -debug -gc -version=Python_2_7_Or_Later -version=Python_2_6_Or_Later -version=Python_2_5_Or_Later -version=Python_2_4_Or_Later -L-ldl /usr/lib/python2.7/config/libpython2.7.a object_.d -ofobject_.x -I../../infrastructure/ -L-ldl -L-lutil -v dmd turns the above into: gcc object_.o -o object_.x -g -m64 -ldl -ldl -lutil -L/usr/lib/x86_64-linux-gnu -L/usr/lib/i386-linux-gnu -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic /usr/lib/python2.7/config/libpython2.7.a -l:libphobos2.a -lpthread -lm -lrt which fails, but gcc object_.o -o object_.x -g -m64 -ldl -ldl -lutil -L/usr/lib/x86_64-linux-gnu -L/usr/lib/i386-linux-gnu -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic /usr/lib/python2.7/config/libpython2.7.a -l:libphobos2.a -lpthread -lm -lrt -ldl -lutil works.
Re: lookup fields struct
On Sunday, 26 May 2013 at 14:19:13 UTC, mimi wrote:
Hi!
I am want to get list of fields types and offsets in struct by
the template.
I.e., lookup through this struct:
struct S {
int a;
string b;
someptr* c;
};
template Lookup!( S )(); returns something as:
field #0, int, offset 0
field #1, string, offset 8,
field #2, someptr, offset 16
How I can do this?
To get a TypeTuple containing this information you can do this:
template Lookup(S)
{
template Field(int index_, Type_, int offset_)
{
enum index = index_;
alias Type = Type_;
enum offset = offset_;
}
template impl(int i)
{
static if(i == S.tupleof.length)
alias impl = TypeTuple!();
else
alias impl = TypeTuple!(
Field!(i, typeof(S.tupleof[i]),
S.init.tupleof[i].offsetof),
impl!(i + 1));
}
alias Lookup = impl!0;
}
If you only want to format this information to a string it's even
simpler:
string lookup(S)()
{
auto r = ;
S s;
foreach(i, e; s.tupleof)
r ~= xformat(field #%s, %s, offset %s\n,
i, typeof(s.tupleof[i]).stringof,
s.tupleof[i].offsetof);
return r;
}
Then lookup!S will give you the string and you can use it at
compile time or at run time.
Re: Passing large or complex data structures to threads
On 05/26/2013 05:38 AM, Simen Kjaeraas wrote: Tuple!(size_t, size_t)[][] data = createData(); immutable dataImm = assumeUnique(data); data = null; // Simply to ensure no mutable references exist. The last line is not needed. assumeUnique already does that. :) Ali
Re: more fun with ubuntu
On 05/26/2013 06:50 PM, Ellery Newcomer wrote: On Sunday, 26 May 2013 at 16:28:33 UTC, Mike Wey wrote: Try prefixing the python lib with -L like so: dmd -unittest -property -debug -gc -version=Python_2_7_Or_Later -version=Python_2_6_Or_Later -version=Python_2_5_Or_Later -version=Python_2_4_Or_Later -L-ldl -L/usr/lib/python2.7/config/libpython2.7.a object_.d -ofobject_.x -I../../infrastructure/ -L-ldl -L-lutil -v Hey, that worked! now go report that to issue 7044 :) It works in this case because it's treating the path to the python lib as just an other linker flag. You would still need to be able to control the order of the arguments passed to the linker by dmd if you want to use std.net.curl for example since -lcurl should be passed to the linker after -lphobos2. -- Mike Wey
Re: Passing large or complex data structures to threads
On Sun, 26 May 2013 17:59:32 +0200, Ali Çehreli acehr...@yahoo.com wrote: On 05/26/2013 05:38 AM, Simen Kjaeraas wrote: Tuple!(size_t, size_t)[][] data = createData(); immutable dataImm = assumeUnique(data); data = null; // Simply to ensure no mutable references exist. The last line is not needed. assumeUnique already does that. :) Cool. I thought it might. -- Simen
Bug or feature?
import std.stdio;
struct S
{
int bigUglyName;
void foo( S s )
{
alias bigUglyName local;
alias s.bigUglyName b;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
}
void main()
{
S s1;
S s2;
s1.bigUglyName = 1;
s2.bigUglyName = 2;
s1.foo( s2 );
}
returns to console:
bigUglyName (AKA local)=1 b=1
Why? I am expected that b=2
Re: lookup fields struct
Wow! thanks!
Re: lookup fields struct
On Sunday, 26 May 2013 at 23:37:01 UTC, mimi wrote: Wow! thanks! offsetof will automatically distribute over the arguments so to get the offsets of a tuple you can just do: auto tmp = TP.offsetof; And tmp will be a tuple of the offsets.
Re: Bug or feature?
On Sunday, 26 May 2013 at 23:35:43 UTC, mimi wrote:
import std.stdio;
struct S
{
int bigUglyName;
void foo( S s )
{
alias bigUglyName local;
alias s.bigUglyName b;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
}
void main()
{
S s1;
S s2;
s1.bigUglyName = 1;
s2.bigUglyName = 2;
s1.foo( s2 );
}
returns to console:
bigUglyName (AKA local)=1 b=1
Why? I am expected that b=2
alias does not capture this pointer, it is rewritten as
S.bigUglyName and you can refer to non-static fields as
Type.member which is this.member in member functions (in D
semantic differences of accessing static and non-static members
are diluted)
