Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
Bug reported as https://issues.dlang.org/show_bug.cgi?id=14298
Re: How to generate a random string ...
On Monday, 16 March 2015 at 22:19:52 UTC, Gary Willoughby wrote: I guess it depends on the encoding? No the character itself are encoding independent. Some references: http://stackoverflow.com/questions/23853489/generate-a-random-unicode-string This will not work as the caller has to specify the code range. I want to specify the string length and the random use is not even uniform (see channel 9 link) http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful http://www.bonf.net/2009/01/14/generating-random-unicode-strings-in-c/ I'm not use how that is going to give me the 113,021 unicode defined characters let alone in a uniform way.
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote: On Saturday, 14 March 2015 at 13:52:13 UTC, Craig Dillabaugh wrote: I don't have any C# experience so I can't compare those languages much, but I've heard people say their are D / C# similarities. Anyway, this isn't a criticism of your comment, I was just curious what (other than the shared C++ syntax heritage) you find so Java-like in D? Cheers, Craig I've been using C# pretty extensively for the last year or so. Superficially, at least, C# and D are pretty similar, eg auto (var), foreach, lambdas, classes and structs. C# is more biased towards OO than D. Metaprogramming is significantly weaker in C#. This is probably the one area where I've wished for some of D's functionality. Reflection is all runtime. C# has some AST capabilities that D doesn't. This is probably the main area where I envy C# when using D. And C# has LINQ, which when combined with the last point is fricken awesome. You should give C# a try, its actually great. The only thing that holds me back is that its maintained by microsoft, Multi Platform support is sub par, and it cant be targeted towards other architectures.
Re: A bug on the website dlang.org
On Monday, 16 March 2015 at 20:03:36 UTC, Marc Schütz wrote: You can file bugs against component websites there. Thanks. This has already been fixed AFAIK, it's just not yet deployed. OK.
Re: struct / cast / ? design problem
The problem in your example is that your making a copy of the
returned data. Of course any changes to that copy won't affect
the original. You need to return a pointer to it (`ref` won't do
if you want to store it in a local variable, because these can't
be `ref`).
struct BlockHead
{
uint magic = 20150312;
uint magic2;
uint blockSize;
uint unused1;
ulong unused2;
ulong spare[61];
T* embedded(T)() {
static assert(T.sizeof spare.length);
return cast(T*) spare.ptr;
}
}
How to use it:
void useIt(ref BlockHead bh) {
static struct InternalData {
int foo;
ubyte[20] bar;
}
auto data = bh.embedded!InternalData;
data.foo = 42;
}
Re: ref for (const) variables
On Monday, 16 March 2015 at 19:20:09 UTC, anonymous wrote: On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. It is, for example, not nullable. ;) Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed. I will research this. Thank you.
Re: Using std.format required std.string?
On Mon, 16 Mar 2015 12:32:01 +0100, Robert M. Münch wrote:
I prefer to move things to the far future compatibility path ASAP.
Reduce a lot of maintenance headaches.
then you can check properties, not versions. ;-)
static if (__traits(compiles, {import std.string : format;})) {
import std.string : format;
} else {
import std.format : format;
}
signature.asc
Description: PGP signature
Re: Dlang seems like java now,but why not let d more like C# Style?
On Monday, 16 March 2015 at 12:18:42 UTC, Ellery Newcomer wrote: On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote: Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL. There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability. At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way. overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards.. I don't think the problem is the lack of pattern matching. I think the problem is that by forcing the query syntax into lambda expression syntax, you obfuscate the syntax tree without really gaining any value.
How to generate a random string ...
... from all Unicode characters in an idiomatic D way?
(std.interal.unicode_*)
```
T genUnicodeString(T)(size_t minChars, size_t maxChars)
if(isSomeString!T) {
...
}
```
Re: DlangUI EditLine question
Thanks! I'll try this out after I get home.
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On Monday, 16 March 2015 at 09:03:18 UTC, Lukasz Wrzosek wrote:
Hello
I was just exploring possibility to mimic multiple inheritance
from C++ (do not ask why, just for fun).
I've stumbled on below issue (let's say corner case) and most
likely this is bug in implementation of template Proxy, isn't
it ?
import std.typecons;
class IA {}
class IB {}
class C : IB {
IA a;
mixin Proxy!a;
public this() {
a = new IA;
}
}
void main() {
C c = new C;
IA a = cast(IA)c;
IB b_ok = c;
IB b_not_ok = cast(IB)c;
assert(c !is null);
assert(a !is null);
assert(b_ok !is null);
assert(b_not_ok !is null); //fails
}
What behaviour would you expect if both IA and C inherited from
IB?
Re: Dlang seems like java now,but why not let d more like C# Style?
On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote: Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL. There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability. At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way. overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards..
Re: DlangUI EditLine question
On Sunday, 15 March 2015 at 16:21:21 UTC, Kyle wrote:
I have a variable, x, which I want to update when the content
of a DlangUI EditLine is modified. I tried making this work
with the onContentChange method listed in the API
documentation, but dmd told me it's not there. I've got this
working now by implementing a custom subclass of EditLine as
below:
class XEditLine : EditLine
{
this(string ID, dstring initialContent = null)
{
super(ID, initialContent);
}
override bool onKeyEvent(KeyEvent e)
{
super.onKeyEvent(e);
x = to!double(this.text);
return true;
}
}
This works but it seems like there should be a cleaner way to
do this, any suggestions? Thanks.
You can either override onContentChange or use
onContentChangeListener
override void onContentChange(EditableContent content,
EditOperation operation, ref TextRange rangeBefore, ref TextRange
rangeAfter, Object source) {
super.onContentChange(content, operation, rangeBefore,
rangeAfter, source);
// do something
x = to!double(this.text);
}
or
EditLine line = new EditLine();
line.onContentChangeListener = delegate(EditableContent) {
// do something
x = to!double(line.text);
}
of a DlangUI EditLine is modified. I tried making this work
with the onContentChange method listed in the API
documentation, but dmd told me it's not there. I've got this
If you don't see onContentChange method, probably you have older
version of DlangUI. Try dub upgrade --force-remove
Re: Using std.format required std.string?
On 2015-03-15 19:16:52 +, anonymous said: Answerting myself: static if (__traits(compiles, version_minor 67)) import std.string; // format() for versions 2.0.67 else import std.format; // format() for versions = 2.0.67 That doesn't do what you want. You need to `import std.compiler;` for version_minor. Without that import, `__traits(compiles, version_minor 67)` is always false, because version_minor is undefined. I have std.compiler imported. And if you add the import, `__traits(compiles, version_minor 67)` is always true, no matter the value of version_minor. Use `static if(version_minor 67)` instead. Ah, ok. Got it. so __traits(compiles,...) checks if the code can be compiled, that's it. Finally, there's need for this (yet). `std.string.format` is fine with 2.067, too. So unless you're going for (far) future compatiblity, you can just do `import std.string;`. I prefer to move things to the far future compatibility path ASAP. Reduce a lot of maintenance headaches. Thanks for the feedback. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: GDC fails to link with GSL and fortran code
On Mon, 16 Mar 2015 16:44:45 +, Andrew Brown wrote: can you please show output of `dmd -v` and `gdc -v`, so we can see the actual commands they both using for linking? signature.asc Description: PGP signature
Re: What is the best practice of organization multi-threading ?
UP
Re: struct / cast / ? design problem
On 03/15/2015 04:51 PM, ketmar via Digitalmars-d-learn wrote:
On Sun, 15 Mar 2015 16:34:14 -0700, Charles Hixson via Digitalmars-d-learn
wrote:
if you know the exact layouts of `spare`, you can use union for that:
struct S {
// ...
union {
ulong[61] spare;
struct { int vala; ubyte valb; }
// etc.
}
}
and then you can use it like this:
auto s = S();
s.vala = 42;
assert(s.spare[0] == 42);
you can also write a CTFE function that builds struct to cast where
`spare` is changed to something else, using `S` as a source, but this
solution will not be pretty. ;-)
The original method had no knowledge of the layout that the using module
will need, merely that it will need to store some information. (In this
particular case I *could* just modify the header in the original file,
but that isn't solving the design problem, and means that working code
needs to be modified to accommodate new code in a different file.)
IOW, if I could write the union, I wouldn't have needed to label the
unused header memory spare. That solution *would* allow for multiple
secondary users, with different union values, but it would again mean
that new code would require the modifying of the file containing
existing code. This is normally considered bad practice.
GDC fails to link with GSL and fortran code
Hi, I'm trying to compile code which calls C and fortan routines from D on the linux cluster at work. I've managed to get it to work with all 3 compilers on my laptop, but LDC and GDC fail on the cluster (though DMD works perfectly). I'm using the precompiled compiler binaries on these systems, the cluster doesn't have the prerequistites for building them myself and I don't have admin rights. For GDC the commands I run are: gcc -c C_code.c Fortran_code.f gdc D_code.d C_code.o Fortran_code.f -lblas -lgsl -lgslcblas -lm -lgfortran -o out The error messages are: /software/lib64/libgsl.so: undefined reference to `memcpy@GLIBC_2.14' /software/lib64/libgfortran.so.3: undefined reference to `clock_gettime@GLIBC_2.17' /software/lib64/libgfortran.so.3: undefined reference to `secure_getenv@GLIBC_2.17' collect2: error: ld returned 1 exit status I can remove the gsl messages by statically linking to libgsl.a, but this doesn't solve the gfortran issues. If anyone knows a way round these issues, I'd be very grateful. I'd also eventually like to find a way to easily share linux biniaries with people, so they can use this code without these kinds of headaches. If anyone has any advice for making this portable, that would also help me out a lot. Thanks very much Andrew
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On Monday, 16 March 2015 at 12:03:12 UTC, John Colvin wrote: What behaviour would you expect if both IA and C inherited from IB? This case should assert at compile time. But my example shows that case with implicit case is working, but the explicit cast is not. That seems to be incorrect IMO.
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On 03/16/2015 08:28 AM, Lukasz Wrzosek wrote:
On Monday, 16 March 2015 at 12:03:12 UTC, John Colvin wrote:
What behaviour would you expect if both IA and C inherited from IB?
This case should assert at compile time.
But my example shows that case with implicit case is working, but the
explicit cast is not. That seems to be incorrect IMO.
Yes, it's a bug because Proxy mixes in an opCast that always casts to T
(IA in your case):
auto ref opCast(T, this X)() { return cast(T)a; }
Please file an issue for Phobos at
https://issues.dlang.org/enter_bug.cgi
Thank you,
Ali
Re: struct / cast / ? design problem
On 03/16/2015 09:16 AM, Charles Hixson via Digitalmars-d-learn wrote:
On 03/15/2015 04:51 PM, ketmar via Digitalmars-d-learn wrote:
On Sun, 15 Mar 2015 16:34:14 -0700, Charles Hixson via
Digitalmars-d-learn
wrote:
if you know the exact layouts of `spare`, you can use union for that:
struct S {
// ...
union {
ulong[61] spare;
struct { int vala; ubyte valb; }
// etc.
}
}
and then you can use it like this:
auto s = S();
s.vala = 42;
assert(s.spare[0] == 42);
you can also write a CTFE function that builds struct to cast where
`spare` is changed to something else, using `S` as a source, but this
solution will not be pretty. ;-)
The original method had no knowledge of the layout that the using
module will need, merely that it will need to store some information.
(In this particular case I *could* just modify the header in the
original file, but that isn't solving the design problem, and means
that working code needs to be modified to accommodate new code in a
different file.)
IOW, if I could write the union, I wouldn't have needed to label the
unused header memory spare. That solution *would* allow for
multiple secondary users, with different union values, but it would
again mean that new code would require the modifying of the file
containing existing code. This is normally considered bad practice.
My current best answer is to turn the unused into a vector of bytes,
and then pass that to the using routines as a ref. This still is wide
open to errors at the calling end, but the BlockHead end can ensure that
the length of the vector remains constant whenever it accesses it (well,
whenever the head is being written to disk. The byte vector would be a
static array at the BlockHead end. This would seem to allow the using
end to cast the byte vector into an appropriate struct for its own use,
and that writes to it would be seen by BlockHead as writes to the
header...but only to restricted parts of the header. The problem here
is that the ref array might allow itself to be resized at the user end.
That's not a problem as long as the resizing is to something smaller,
but I'm not sure what happens if it gets resized to something larger.
It looks like allowing a buffer overflow.
Re: What is the best practice of organization multi-threading ?
On 03/15/2015 01:53 PM, Suliman wrote:
I have App that read config sections. If the section is true I want to
run it in new thread.
if (parseconfig.obsmpplots_load == true)
{
auto obsmpplots = new ObsmpPlots(db);
auto theTask = task(obsmpplots.getPlots);
theTask.executeInNewThread();
}
if(parseconfig.nadisa_load == true)
{
auto nadisa = new Nadisa(db);
auto theTask = task(nadisa.getPlots);
theTask.executeInNewThread();
}
It's seems work, but I do not sure that I doing it's right.
I don't see any problem. The threads start, do their jobs, and terminate.
If the threads need to produce results that they need to pass to their
owner (as messages), then std.concurrency is another option.
Ali
Re: std.typecons.Proxy + inheritance breaks cast'ing to inherited type
On 03/16/2015 04:59 PM, Lukasz Wrzosek wrote:
Bug reported as
https://issues.dlang.org/show_bug.cgi?id=14298
Thanks...
I have carried the discussion over to the main newsgroup:
http://forum.dlang.org/thread/me8e0a$1kp6$1...@digitalmars.com
As I mention there, there is a workaround: Add a catch-all opCast to the
class in question, which can simply forward to the all-powerful std.conv.to:
T opCast(T)()
{
import std.conv;
return this.to!T;
}
Now it compiles and works as expected.
Ali
Re: struct / cast / ? design problem
On Mon, 16 Mar 2015 12:49:40 -0700, Charles Hixson via Digitalmars-d-learn
wrote:
yep, you're doing it wrong, as Marc already wrote. ;-)
it's not very obvious, but this line makes a copy:
auto val = tst.value;
there are no `ref` type in D. `ref` is modifier for function arguments,
but not part of the type, and you can't declare `ref int`, for example.
so that line transforms to this:
ubyte[400] val = tst.value;
which, obviously, does copying. yet this will work as expected:
import iv.writer;
struct tstHead {
ubyte[400] data;
ubyte[] value () { return data; }
void write (int i) { writeln(data[i]); }
}
void test (ref ubyte[400] a) {
a[2] = 42;
}
void main () {
tstHead tst;
auto val = tst.value;
val[23] = 23;
writeln(val[23]);
tst.write(23);
tst.write(0);
test(val[0..400]);
tst.write(2);
}
signature.asc
Description: PGP signature
Re: What is the best practice of organization multi-threading ?
On 03/16/2015 12:04 PM, Suliman wrote: Ali, please add text above to your book! Will do. Please email me your full name at acehr...@yahoo.com so that I can add it to the Acknowledgments section. Thank you, Ali
Re: How to generate a random string ...
On Monday, 16 March 2015 at 18:48:29 UTC, bearophile wrote: Perhaps by rejection? I mean, generating a uint, test if it's a character and repeat until the result is true. hm, that must not even terminate.
Re: struct / cast / ? design problem
On 03/16/2015 01:24 PM, via Digitalmars-d-learn wrote:
The problem in your example is that your making a copy of the returned
data. Of course any changes to that copy won't affect the original.
You need to return a pointer to it (`ref` won't do if you want to
store it in a local variable, because these can't be `ref`).
struct BlockHead
{
uint magic = 20150312;
uint magic2;
uint blockSize;
uint unused1;
ulong unused2;
ulong spare[61];
T* embedded(T)() {
static assert(T.sizeof spare.length);
return cast(T*) spare.ptr;
}
}
How to use it:
void useIt(ref BlockHead bh) {
static struct InternalData {
int foo;
ubyte[20] bar;
}
auto data = bh.embedded!InternalData;
data.foo = 42;
}
Nice! That looks like exactly what I was hoping for.
Re: How to generate a random string ...
On Monday, 16 March 2015 at 13:33:55 UTC, Robert burner Schadek
wrote:
... from all Unicode characters in an idiomatic D way?
(std.interal.unicode_*)
```
T genUnicodeString(T)(size_t minChars, size_t maxChars)
if(isSomeString!T) {
...
}
```
I guess it depends on the encoding?
Some references:
http://stackoverflow.com/questions/23853489/generate-a-random-unicode-string
http://www.bonf.net/2009/01/14/generating-random-unicode-strings-in-c/
Re: struct / cast / ? design problem
On Mon, 16 Mar 2015 11:18:16 -0700, Charles Hixson via Digitalmars-d-learn
wrote:
My current best answer is to turn the unused into a vector of bytes,
and then pass that to the using routines as a ref. This still is wide
open to errors at the calling end, but the BlockHead end can ensure that
the length of the vector remains constant whenever it accesses it (well,
whenever the head is being written to disk. The byte vector would be a
static array at the BlockHead end. This would seem to allow the using
end to cast the byte vector into an appropriate struct for its own use,
and that writes to it would be seen by BlockHead as writes to the
header...but only to restricted parts of the header. The problem here
is that the ref array might allow itself to be resized at the user end.
That's not a problem as long as the resizing is to something smaller,
but I'm not sure what happens if it gets resized to something larger. It
looks like allowing a buffer overflow.
if you passing the array, not a slice, it can't be resized. i.e.:
void foo (ref ubyte[8] a) {
a[2] = 42;
//a.length = 6; // this will not compile: constant a.length is not an
lvalue
}
void main () {
ubyte[8] aa;
assert(aa[2] == 0);
foo(aa);
assert(aa[2] == 42);
}
signature.asc
Description: PGP signature
Re: What is the best practice of organization multi-threading ?
Ali, please add text above to your book!
Re: Garbage collector returning pointers
On 2015-03-15 15:57:43 +, Marc Schütz said: Ok. I need to dig into how the interpreter handles the returned pointer and how the stack is handled. C usually uses manual memory management, therefore I would expect that the interpreter actually documents whom the pointer belongs to, and who is responsible for cleaning it up. What I'm trying to understand is how the returned pointer is used and when the GC can kick in. I tracked the return code from the DLL. The returned pointer is returned in EAX register (conforming to the C calling convention). Then the interpreter uses this pointer for some time (in my case to create a copy). It than continues, and at some point the EAX register gets some other value. This is the point, wher no reference to the D GC allocated memory can anylonger be found. Hence the GC should be free to free the memory. If the interpreter takes ownership, you should just allocate the data with malloc(), and the interpreter will then call free() on it when it doesn't need it any longer. Not sure whether .dup is compatible with that, maybe you'd need to write a small helper that copies things to the C heap. Yes, exactly. And the problem is, that it's not clear to me (yet) when the interpreter takes ownership and when not. Am I right, that I can query() the D GC to check if a pointer is known / can be found or not? It would be cool if I could query D from the interpreter and ask: Will this pointer be freed in the next collector run? and get back: Yes, or already has been. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What is the best practice of organization multi-threading ?
Ali, again big thanks for your book, without it I was not able how to work with D. But for me now absolutely clear what difference between: auto theTask = task(someFunction); and: auto theTask = task!anOperation();
ref for (const) variables
Currently, if you want to store a long getter into a variable
without copying it (because it may be a big struct), your only
way is to store it as a pointer:
struct Matrix {
float[16] values= [
1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1
];
}
struct Test {
private:
Matrix _matrix;
public:
ref const(Matrix) getCurrentModelViewMatrix() const pure
nothrow {
return _matrix;
}
}
void main() {
Test t;
const(Matrix)* m = t.getCurrentModelViewMatrix(); //
currently
}
But IMO it would be a lot nicer if I could store the reference
like this:
ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer
[Of course the name is exaggerated for the purpose of
demonstration.]
May this be worth of an enhancement request? Or was this already
rejected?
And, no, I want no mutable references such as C++.
Re: What is the best practice of organization multi-threading ?
On 03/16/2015 11:28 AM, Suliman wrote:
difference between:
auto theTask = task(someFunction);
and:
auto theTask = task!anOperation();
tl;dr - Prefer task!anOperation() unless you can't. :)
task() is flexible enough to take what to execute either as a function
(or delegate) pointer (task(someFunction)) or as a template parameter
(task!anOperation).
The template method is more flexible because it can take anything that
can be executed. For that reason, I would prefer task!anOperation.
However, because it is a template parameter, the Task template instances
that are generated would not have the same type (even though two
functions have the same signature). This would e.g. prevent you from
putting two Task instances in an array:
import std.parallelism;
void foo()
{}
void bar()
{}
void main()
{
auto tasks = [ task!foo(), task!bar() ]; // COMPILATION ERROR
}
Error: incompatible types for ((task()) : (task())): 'Task!(foo)*' and
'Task!(bar)*'
So, you would have to give the function as a pointer:
auto tasks = [ task(foo), task(bar) ];
However, this overload actually do the same thing behind the scenes and
calls task!run(myFunc) behind the scenes (run() is a function template
defined in parallelism.d).
Ali
Re: How to generate a random string ...
Robert burner Schadek: ... from all Unicode characters in an idiomatic D way? Perhaps by rejection? I mean, generating a uint, test if it's a character and repeat until the result is true. Bye, bearophile
Re: ref for (const) variables
On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed.
Re: GDC fails to link with GSL and fortran code
Am Mon, 16 Mar 2015 16:44:45 + schrieb Andrew Brown aabrow...@hotmail.com: Hi, I'm trying to compile code which calls C and fortan routines from D on the linux cluster at work. I've managed to get it to work with all 3 compilers on my laptop, but LDC and GDC fail on the cluster (though DMD works perfectly). I'm using the precompiled compiler binaries on these systems, the cluster doesn't have the prerequistites for building them myself and I don't have admin rights. For GDC the commands I run are: gcc -c C_code.c Fortran_code.f gdc D_code.d C_code.o Fortran_code.f -lblas -lgsl -lgslcblas -lm -lgfortran -o out You could try to do the linking with the local compiler: gdc D_code.d gcc D_code.o C_code.o Fortran_code.o -lgphobos2 -lpthread -lblas -lgsl -lgslcblas -lm -L path/to/x86_64-gdcproject-linux-gnu/lib/ The error messages are: /software/lib64/libgsl.so: undefined reference to `memcpy@GLIBC_2.14' /software/lib64/libgfortran.so.3: undefined reference to `clock_gettime@GLIBC_2.17' /software/lib64/libgfortran.so.3: undefined reference to `secure_getenv@GLIBC_2.17' collect2: error: ld returned 1 exit status Seems like the binary GDC toolchain somehow picks up a wrong libc. The toolchains are built with GLIBC 2.14. But IIRC we don't ship the libc in the binary packages (for native compilers) and it should pick up the local libc. Please run gdc with the '-v' and '-Wl,--verbose' options and post a link to the full output. I can remove the gsl messages by statically linking to libgsl.a, but this doesn't solve the gfortran issues. If anyone knows a way round these issues, I'd be very grateful. I'd also eventually like to find a way to easily share linux biniaries with people, so they can use this code without these kinds of headaches. If anyone has any advice for making this portable, that would also help me out a lot. Usually the best option is to compile on old linux systems. Binaries often run on newer systems but not on older ones. You could setup debian wheezy or an older version in a VM or using docker. Or you use docker.io ;-) I personally think the docker approach is kind of overkill but avoiding compatibility issues is one of docker's main selling points.
Re: A bug on the website dlang.org
On Monday, 16 March 2015 at 20:00:24 UTC, Dennis Ritchie wrote: I don't know where to write about a bug on the website, so I decided to write in this section. This is the official bug tracker: https://issues.dlang.org/enter_bug.cgi You can file bugs against component websites there. This page is not displayed correctly: http://dlang.org/phobos/std_format.html This has already been fixed AFAIK, it's just not yet deployed.
A bug on the website dlang.org
I don't know where to write about a bug on the website, so I decided to write in this section. This page is not displayed correctly: http://dlang.org/phobos/std_format.html
Re: ref for (const) variables
On Monday, 16 March 2015 at 19:20:09 UTC, anonymous wrote: On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed. The last time we discussed about scope, Walter suggested allowing `ref` for local variables. He might not be opposed to extend it further to members. On the other hand, `ref` has gained different semantics with DIP25 (something like scope, more or less), so this might collide with such a change. Anyway, the situation in D is not the same as in C++, because `ref` is not a type modifier, but a storage class.
Re: struct / cast / ? design problem
On 03/16/2015 11:55 AM, ketmar via Digitalmars-d-learn wrote:
On Mon, 16 Mar 2015 11:18:16 -0700, Charles Hixson via Digitalmars-d-learn
wrote:
My current best answer is to turn the unused into a vector of bytes,
and then pass that to the using routines as a ref. This still is wide
open to errors at the calling end, but the BlockHead end can ensure that
the length of the vector remains constant whenever it accesses it (well,
whenever the head is being written to disk. The byte vector would be a
static array at the BlockHead end. This would seem to allow the using
end to cast the byte vector into an appropriate struct for its own use,
and that writes to it would be seen by BlockHead as writes to the
header...but only to restricted parts of the header. The problem here
is that the ref array might allow itself to be resized at the user end.
That's not a problem as long as the resizing is to something smaller,
but I'm not sure what happens if it gets resized to something larger. It
looks like allowing a buffer overflow.
if you passing the array, not a slice, it can't be resized. i.e.:
void foo (ref ubyte[8] a) {
a[2] = 42;
//a.length = 6; // this will not compile: constant a.length is not an
lvalue
}
void main () {
ubyte[8] aa;
assert(aa[2] == 0);
foo(aa);
assert(aa[2] == 42);
}
Yes, but if I pass an array, the using program can't change it's own
values (which need to be stored in the header). Additionally, if I pass
an array I'm passing over 400 bytes rather than around 16, but that's
very secondary.
So, attempting to rewrite your example into more what I am talking about:
importstd.stdio;
structtstHead
{
ubytedata[400];
refubyte[400]value()
{returndata;}
voidwrite(int i)
{writefln (%d, data[i]);}
}
voidmain()
{tstHeadtst;
autoval=tst.value;
val[23]=23;
writefln(%d, val[23]);
tst.write(23);
tst.write(0);
}
Yields:
23
0
0
instead of:
23
23
0
And:importstd.stdio;
structtstHead
{
ubytedata[400];
voidvalue(ref byte[400] val)
{val.ptr=data;}
voidwrite(int i)
{writefln (%d, data[i]);}
}
voidmain()
{tstHeadtst;
ubyteval[400];
tst.value (val);
val[23]=23;
writefln(%d, val[23]);
tst.write(23);
tst.write(0);
}
Yields:
test.d(8): Error: val.ptr is not an lvalue
test.d(17): Error: function test.tstHead.value (ref byte[400] val) is
not callable using argument types (ubyte[400])
Failed: [dmd, -unittest, -Dddocs, -v, -o-, test.d, -I.]
It is *necessary* that the using routine be able to store its data into
the parts of the header reserved for it. Perhaps multiple copying will
be necessary. I could write getter and setter routines, but they will
inevitably be doing a lot of excess copying as the base routine doesn't
know what data the calling routine will need. Every solution I've
thought of either requires a lot of excess copying, or requires a very
tight coupling between the library routine and the using routine.
std.typecons.Proxy + inheritance breaks cast'ing to inherited type
Hello
I was just exploring possibility to mimic multiple inheritance
from C++ (do not ask why, just for fun).
I've stumbled on below issue (let's say corner case) and most
likely this is bug in implementation of template Proxy, isn't it ?
import std.typecons;
class IA {}
class IB {}
class C : IB {
IA a;
mixin Proxy!a;
public this() {
a = new IA;
}
}
void main() {
C c = new C;
IA a = cast(IA)c;
IB b_ok = c;
IB b_not_ok = cast(IB)c;
assert(c !is null);
assert(a !is null);
assert(b_ok !is null);
assert(b_not_ok !is null); //fails
}
Removing structs from assoc array while iterating over it
I am creating a simple SDL_Texture manager, and was wondering if
the following code would work:
---
// 'list' is am assoc array of a struct containing a pointer and
ref counter.
// max_list_length is set to 20 if it's ever found to be 0
// compact list
if(list.length == max_list_length){
string to_remove;
foreach(string st, entry; list){
if(to_remove.length){
list.remove(to_remove);
to_remove = ;
}
if(entry.ref_count == 0){
to_remove = st;
}
}
if(to_remove.length){
list.remove(to_remove);
to_remove = ;
}
}
---
I previously kept track of the keys of all entries found to have
a ref_count of 0, and ran over those to remove them in a while
loop, but was wondering if this would work, only needing to run
over the list once. If there's a faster, cleaner way to do this,
please do explain.
Many thanks in advance.
