Re: Getting DAllegro 5 to work in Windows
On Friday, 30 January 2015 at 06:16:21 UTC, Joel wrote: What happens is, that I run the script file (in DAllegro folder) and it is suppose to create lib files from the DLL ones. On my system, it says its done it but no lib files pop up! You can try procmon to watch, what happens with files.
Re: Getting DAllegro 5 to work in Windows
On 1/30/2015 3:16 PM, Joel wrote: Update. What happens is, that I run the script file (in DAllegro folder) and it is suppose to create lib files from the DLL ones. On my system, it says its done it but no lib files pop up! It happens on another computer too. (maybe from my dodgy flash drive). The guy at the computer shop said he didn't think it was a virus. There's an idea that the files get wiped off as soon as they are created. So I've just been using an older version of Allegro/DAllegro. FYI, I have a nearly finished dynamic binding to Allegro 5 that doesn't require any link-time dependencies. I'll be adding it to DerelictOrg as soon as it's done. I hope that to be sometime on the other side of this coming weekend. I only have a couple more addons to work through.
Re: Deducing a template retrun parameter type based on an assignment?
On Friday, 30 January 2015 at 07:13:09 UTC, Jeremy DeHaan wrote: That seems strange. I figured that it would be smart enough to deduce the parameter type based on the type that it was trying to be assigned to. It seems sensible to me, as changing string to auto would leave the type of the expression undefined. But maybe your expectation is a reasonable enhancement, I'll leave it for someone more knowledgeable than myself to judge. That is good to hear. It seemed like that was the way it would work, but I've never had to specify a default template parameter type. I'm hoping to avoid having to specify a template parameter, but it seems like it can't be helped if users want to get their string type as a wstring or dstring though. It doesn't seem too bad to me. I used a similar pattern quite recently to wrap glGetIntegeriv into gl.get!int. One way or another you'll have to specify the type, but if you want to cut down on redundant code then auto ret = thing.getString!wchar; is a good bet. And I'm fairly certain that since you're using a default param of char, auto ret = thing.getString; should compile and result in ret being a char string.
Re: Deducing a template retrun parameter type based on an assignment?
On Friday, 30 January 2015 at 06:58:58 UTC, Vlad Levenfeld wrote: On Friday, 30 January 2015 at 06:35:31 UTC, Jeremy DeHaan wrote: A bunch of stuff for template type deduction to work, you have to supply an argument. Your type signature would need to look like this: immutable(T)[] getString(T)(T arg) const and then T would be deduced from arg. That seems strange. I figured that it would be smart enough to deduce the parameter type based on the type that it was trying to be assigned to. But string ret = thing.getString(); won't compile because it is rewritten to getString(thing), but your getString function takes no runtime parameters. It looks like the signature I wrote earlier is what you actually want. Whoops. I should have mentioned that this is a member function in a class and not a free fiction. Not that it changes much about the deduction. As to your second example, it'll work fine. Basically your signature says "only accept dchar, wchar or char, but if nothing's been specified, default to char". But if you rewrite getString to take one parameter, then the default template arg is redundant. That is good to hear. It seemed like that was the way it would work, but I've never had to specify a default template parameter type. I'm hoping to avoid having to specify a template parameter, but it seems like it can't be helped if users want to get their string type as a wstring or dstring though.
Re: Deducing a template retrun parameter type based on an assignment?
On Friday, 30 January 2015 at 06:35:31 UTC, Jeremy DeHaan wrote: I have a template fuction that looks like this: immutable(T)[] getString(T)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Basically, I was hoping that the type would be deduced based on the prameter that was being assigned to like so. string ret = thing.getString(); Apparently that does not work, though. I get informed that the type of the template is not able to be deduced. I'm curious as to why it was not able to deduce it on its own. Additionally, and I haven't run my code to try this yet, but giving T a default type compiled to my surprise. immutable(T)[] getString(T=char)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Is something like this supposed even to work? for template type deduction to work, you have to supply an argument. Your type signature would need to look like this: immutable(T)[] getString(T)(T arg) const and then T would be deduced from arg. But string ret = thing.getString(); won't compile because it is rewritten to getString(thing), but your getString function takes no runtime parameters. It looks like the signature I wrote earlier is what you actually want. As to your second example, it'll work fine. Basically your signature says "only accept dchar, wchar or char, but if nothing's been specified, default to char". But if you rewrite getString to take one parameter, then the default template arg is redundant.
Deducing a template retrun parameter type based on an assignment?
I have a template fuction that looks like this: immutable(T)[] getString(T)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Basically, I was hoping that the type would be deduced based on the prameter that was being assigned to like so. string ret = thing.getString(); Apparently that does not work, though. I get informed that the type of the template is not able to be deduced. I'm curious as to why it was not able to deduce it on its own. Additionally, and I haven't run my code to try this yet, but giving T a default type compiled to my surprise. immutable(T)[] getString(T=char)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Is something like this supposed even to work?
Re: Getting DAllegro 5 to work in Windows
On Friday, 26 December 2014 at 08:43:24 UTC, Joel wrote: On Wednesday, 24 December 2014 at 09:57:31 UTC, Kagamin wrote: Works for me on allegro-5.0.10-mt.dll, produced 391kb lib file. I think my Windows 7 on my Mac has system damage - I used a doggy flash drive. I plan to install Window 8.1, and hopefully that will fix the problem. Update. What happens is, that I run the script file (in DAllegro folder) and it is suppose to create lib files from the DLL ones. On my system, it says its done it but no lib files pop up! It happens on another computer too. (maybe from my dodgy flash drive). The guy at the computer shop said he didn't think it was a virus. There's an idea that the files get wiped off as soon as they are created. So I've just been using an older version of Allegro/DAllegro.
Re: class is forward referenced when looking for 'v'
It's a bit hard to know where to start here. It's not obvious from your code what you are trying to achieve. In essence, you do have a circular reference as Base has functions that use a types A and B which are derived from the Base. I don't see how the complier could be asked to resolve this. You are using a curious mix of tempting and inheritance, but depending one what you are trying to achieve, you may only need one or the other. If you want classes other than A to recognise the value "v", then you should define a "v" property either in the Base class, a class derived from it or in an interface. This will allow you to use the correct overloading (or "static if" in templating) to catch the scenario of it being passed into the Foo function. As I say. This is not a great real world example so it's hard to answer without a better explanation of what you are trying to do. It is not, however a bug in the compiler. Just another note. "public" is redundant for a class.
class is forward referenced when looking for 'v'
I ran into an issue with cross referencing to classes, that I
can't figure out. I reproduced the issue below:
import std.stdio;
class Base(t)
{
public void Foo(A!(t) a)
{
writeln("Base.Foo(A a)");
}
public void Foo(B!(t) a)
{
writeln("Base.Foo(B a)");
}
};
class A(t) : Base!(t)
{
public t v;
this(t v)
{
this.v = v;
}
}
class B(t) : Base!(t)
{
public override void Foo(A!(t) a)
{
writeln("A: ", a.v);
}
}
int main()
{
A!int a = new A!(int)(1);
B!int b = new B!(int)();
a.Foo(b);
b.Foo(a);
return 0;
}
And the errors dmd returns:
test.d(16): Error: class test.A!int.A is forward referenced when
looking for 'v'
test.d(16): Error: class test.A!int.A is forward referenced when
looking for 'opDot'
test.d(16): Error: class test.A!int.A is forward referenced when
looking for 'opDispatch'
test.d(29): Error: no property 'v' for type 'test.A!int.A'
test.d(10): Error: template instance test.B!int error
instantiating
test.d(16):instantiated from here: Base!int
test.d(35):instantiated from here: A!int
Is this a bug in D? Or am I doing something wrong?
Re: cpu % usage decreases when (unrelated) memory usage increases
On 01/29/2015 12:33 PM, Christiaan wrote: > Can someone please explain what might be the issue here? If the memory is too large, needing to be swapped to and from disk, then your program may be waiting for I/O instead of doing actual work. Ali
Re: spawn/executeInNewThread and module this/~this
On 01/29/2015 12:11 PM, Fyodor Ustinov wrote: Hi! Nowhere is it written that the start of a new thread also launch this() for module (and stop a thread launch ~this()). It really is not written anywhere or I just missed? WBR, Fyodor. I imply it here: http://ddili.org/ders/d.en/modules.html#ix_modules.static%20this and here: http://ddili.org/ders/d.en/concurrency_shared.html#ix_concurrency_shared.shared%20static%20this Ali
Re: spawn/executeInNewThread and module this/~this
On Thursday, 29 January 2015 at 20:50:16 UTC, ref2401 wrote: It's written here: http://dlang.org/module.html#staticorder Oops. Thnx!
Re: cpu % usage decreases when (unrelated) memory usage increases
Can you post any of the code itself? My guess would be that something is being cached by the processor - is the code itself faster or slower when the cpu changes?
Re: spawn/executeInNewThread and module this/~this
It's written here: http://dlang.org/module.html#staticorder
cpu % usage decreases when (unrelated) memory usage increases
Dear reader, I have a class X that has a (possibly) heavy array of data S as a member. A method f of X makes use of a foreach loop over taskPool(some_other_array Y). The thing is that when I increase the length of S, linux/top shows me that my D program only uses 10% of my cpu capacity. This percentage varies with the length of S. From my perspective, S has nothing to do with X.f. Can someone please explain what might be the issue here? regards, Chris
spawn/executeInNewThread and module this/~this
Hi! Nowhere is it written that the start of a new thread also launch this() for module (and stop a thread launch ~this()). It really is not written anywhere or I just missed? WBR, Fyodor.
Re: Import paths do not work
Let me try to explain the compilation process which may help you to understand where your problem lies. * Build system * Maintain program/library dependencies * Execute commands resulting in a usable program/library * Compiler * Lexical Analysis * Parsing * Language translation * Optimizations * Linker * Combine machine code from multiple locations * Optimizations Each stage is feeding into the next and interacting with one may not require explicit interaction for the next. === Linker The linker is at the bottom of our list because it will be the final step in creating an executable/library. There is not one single linker, there are many for different operating systems and programming languages. The 'ld' linker is common on Linux, Windows has a linker called link, and DMD makes use of optlink for its 32-bit build. At the time the linker is called the source code has already been translated into machine code by the compiler. So the linker has a simple task of packaging up the machine code which makes up your program. This means locating the machine code for libraries being used and combining it with the instructions you've specified. One of the most common errors you'll receive from a linker is that it can't find the corresponding machine code. Consider yourself the linker and, as the compiler, I will request that you do some work for me. The programmer has asked me to compile decentApp.d for them and makes a call to spiral(). If I give you the machine code for decentApp could you please include the machine code for famous.awesome.spiral() too? Are you able to locate machine code for famous.awesome.spiral? The answer is that you can't, not with out being told where to look, what to look for, or searching every location for any machine code matching that symbol (when you make function calls the linker doesn't care it is a function, it considers it a symbol or reference for some chunk of machine code). The solution, tell the linker where it will find the code, it is just a polite thing to do. Once the linker has all the code it can perform optimizations, one of the most common is throwing out code which isn't being used. === Compiler The compiler is a translation tool, making conversion from one language to another. When it translates a chunk of code, there can be references to other chunks some of which may have already been compiled, and some that may still need compiled. What is important to the compiler is making sure that the call out to that chuck of code is formed in the agreed upon structure. It does this by examining the function signature, in C/C++ we see this information provided through a header file. Since the compiler doesn't have to build every chunk of code that the program is being run, as long as it has the function signature it can translate code that call into some unknown location. And this is where the -I flag comes in play. When you provide the -I with a location, it signals to the compiler that it should look for the function signatures of this code chunk in the locations specified. However, the compiler does not build the code that it finds, it expects you have already done that because you're not telling it to build that code. It will then pass off the translated code to the linker and request an executable be built. The linker however only knows about the code the compiler has told it about (and some default search locations). If it can find it in the code provided by the compiler, or the places it was told to search then it will fail. This is where the -l linker flag comes in (assuming Linux), when passed on the compiler it would be -L-l (pass to the linker the flag -l). Using -l specifies what libraries to find reference code in, and -L is used to specify what directories to look in for the requested library. When you tell the compiler to build your code and it will find some of the code over here in -I"foo" it is probably wrong if you don't also include a -L-l and possibly -L-L in that same command. Most likely you want a build system that handles dependencies for you, check out DUB.
Re: Virtual functions and inheritance
This is almost the same code as written initially,
let somone explain why the hell this is working:
---
module test;
import std.conv;
class Parent {
@property final string typeName() {
return to!string(this);
}
}
class Child : Parent {
}
void main() {
auto p = new Parent;
auto c = new Child;
assert(p.typeName == __MODULE__ ~ ".Parent");
assert(c.typeName == __MODULE__ ~ ".Child");
}
---
Because to!string calls toString, which is a virtual function.
It's the same as the NVI-Idiom in C++.
Re: Virtual functions and inheritance
even more weird:
---
module test;
import std.conv;
interface Meh{
final string typeName()
{return to!string(this);}
}
class Parent : Meh {}
class Child : Parent {}
void main() {
auto p = new Parent;
auto c = new Child;
assert(p.typeName == __MODULE__ ~ ".Parent");
assert(c.typeName == __MODULE__ ~ ".Child");
}
---
Re: Virtual functions and inheritance
On Tuesday, 27 January 2015 at 04:38:59 UTC, David Monagle wrote:
Hi guys,
I'm a former C++ developer and really enjoying working with D
now. I have a question that I hope some of you may be able to
answer.
class Parent {
@property string typeName() {
return typeof(this).stringof;
}
}
class Child : Parent {
}
void main() {
auto p = new Parent;
auto c = new Child;
assert(p.typeName == "Parent");
assert(p.typeName == "Child");
}
I'm looking for an explanation as to why this doesn't work,
then a suggestion for how I may achieve child classes being
able to generate a string description of their own type,
without redefining the typeName property on each child. (I'm
currently solving this with a mixin, but I was hoping for a
better solution.
I'm assuming it doesn't work because either typeof(this) or
.stringof is evaluated at compile time?
This is almost the same code as written initially,
let somone explain why the hell this is working:
---
module test;
import std.conv;
class Parent {
@property final string typeName() {
return to!string(this);
}
}
class Child : Parent {
}
void main() {
auto p = new Parent;
auto c = new Child;
assert(p.typeName == __MODULE__ ~ ".Parent");
assert(c.typeName == __MODULE__ ~ ".Child");
}
---
Re: Overloading equality operator for classes
On 01/29/2015 09:48 AM, rumbu wrote:
bool opEquals(Object obj, int value)
{
//do something to compare them
return false;
}
void main(string[] args)
{
Object obj;
if (obj == 12) {}
//ERROR function object.Object.opEquals (Object o) is not callable
using argument types (int)
}
According to paragraph (2) -
http://dlang.org/operatoroverloading.html#eqcmp), the compiler must try
obj.opEquals(12) and 12.opEquals(obj) but this is not happening.
Is there any other way to overload the equality operator? (except
overriding opEquals in each class intended to be compared with an integer)
In D, operator overloading is only for user-defined types and through
their member functions.
class C
{
int value;
bool opEquals(int value)
{
return value == this.value;
}
}
void main(string[] args)
{
auto c = new C;
if (c == 12) {}
}
Ali
Re: What is @return?
On Thursday, 29 January 2015 at 05:02:58 UTC, ketmar wrote: http://wiki.dlang.org/DIP25 this is a very recent thing, it wasn't coded when 2.066 was released. Thanks, I like it.
Re: Check if type is from specific template?
On Thu, Jan 29, 2015 at 12:58:46PM +, Tofu Ninja via Digitalmars-d-learn wrote: [...] > Incidentally, while trying to see how its used I found that a lot of > the links on the std.traits doc page do not work and have no > documentation. [...] Please file bugs for these. We need to fix the docs. T -- "I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information
Re: Overloading equality operator for classes
On Thursday, 29 January 2015 at 17:48:04 UTC, rumbu wrote:
bool opEquals(Object obj, int value)
{
//do something to compare them
return false;
}
void main(string[] args)
{
Object obj;
if (obj == 12) {}
//ERROR function object.Object.opEquals (Object o) is not
callable using argument types (int)
}
According to paragraph (2) -
http://dlang.org/operatoroverloading.html#eqcmp), the compiler
must try obj.opEquals(12) and 12.opEquals(obj) but this is not
happening.
Is there any other way to overload the equality operator?
(except overriding opEquals in each class intended to be
compared with an integer)
UFCS is not used when operators are involved. I think this is
intentional.
Overloading equality operator for classes
bool opEquals(Object obj, int value)
{
//do something to compare them
return false;
}
void main(string[] args)
{
Object obj;
if (obj == 12) {}
//ERROR function object.Object.opEquals (Object o) is not
callable using argument types (int)
}
According to paragraph (2) -
http://dlang.org/operatoroverloading.html#eqcmp), the compiler
must try obj.opEquals(12) and 12.opEquals(obj) but this is not
happening.
Is there any other way to overload the equality operator? (except
overriding opEquals in each class intended to be compared with an
integer)
Re: Import paths do not work
On Thursday, 29 January 2015 at 10:26:56 UTC, Atila Neves wrote: I would suggest instead of using make, use dub[0] build manager instead. It'll handle grabbing all the files and compiling them correctly. [0] http://code.dlang.org/package-format Or for simple projects such as this one seems to be, just use rdmd. Atila I am using Mono-D on MonoDevelop. I was normally keeping all library files in the same project. But copying same library codes between different projects didn't seem like a good idea. Then I copied library files as "symbolic link" to project, but this time, if I put a new module in library folder, Mono-D doesn't see it automatically. Then I saw "Include" part in project properties which uses "-I" flag while compiling the project. I removed all symbolic links from project, and added full folder paths of libraries to that "Include" list. As you can guess, as I asked in the question, it doesn't see library files now. I still have a solution as linking to library modules, but I wondered whether it was possible in another "easier" way.
Re: What is RTInfo?
On 1/29/15 3:47 AM, Mike wrote: object.d [1] says it's infomation for the precise GC (which I thought wasn't implemented yet). It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. So, what is RTInfo and what is its purpose. And how is it different from TypeInfo? For every TypeInfo generated by the compiler, it also instantiates the RTInfo(T) template [1] and puts the result into m_rtInfo. This allows anyone to generate anything they want at compile time and put it into the TypeInfo system. Could be Precise GC stuff, could be reflection stuff, anything you want. At the moment it's just a toy for tinkerers to try nifty things with :) There has been discussion as to how we can make the system extensible, so you don't have to build a new runtime to add things to TypeInfo. But nothing concrete so far has been added. It's just a hook from the compiler. -Steve [1] https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L682
Re: What is RTInfo?
On Thursday, 29 January 2015 at 08:47:18 UTC, Mike wrote: It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. It can actually return anything: RTInfo is a template that is automatically instantiated for each user-defined struct or class in a program. https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L682 It isn't actually doing anything yet in the lib, but it could if you wanted to modify druntime. IT can do anything - custom, user extensions to TypeInfo, building trees of types, or making maps of things for the GC (which is why it is there, just nobody has actually used it yet). It is one of the cool hidden gems there that is unutilized so far.
Re: What is @return?
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote:
@property auto info() @safe @nothrow @pure @return const {
return this; }
It is mesmerizing... (@ _ @)
And soon its gong to look like this:
export @property auto info() @safe @nothrow @pure @return const {
return this; }
Re: Threads and stdio and HANDLE
On Wednesday, 28 January 2015 at 11:50:46 UTC, Danny wrote:
Hello,
I'm trying to write some toy examples using threads in D.
Is the std.stdio.File thread-local or shared? Is flockfile used
when I synchronize on it?
I tried checking phobos myself and found some things I don't
get (in stdio.d):
alias FLOCK = flockfile;
this(this) { @trusted
if(fps_)
FLOCK(fps_);
}
What is "this(this)"?
this(this) is the constructor syntax for construction of an
already
initialised struct. (sort of equivalent to the C++
class foo {
foo(const foo& other)
{
...
}
} )
used like
struct somestruct
{
...
this()
{
writeln("calling this()");
}
this(this)
{
writeln("calling this(this)");
}
}
...
auto foo = somestruct(); //prints calling this()
auto baz = foo; //prints calling this(this)
If I want to write to stdout from a thread, do I use
LockingTextWriter? File? shared File? Does each thread have the
same stdout?
Yes
Finally, I'm trying to come to grips with "shared":
What does specifying "shared class" or "shared struct" do?
all methods are marked as shared
(similar to what final class quux { ... } does compared to just
class quux { ... } )
The first use of shared is to signal to the compiler that it
should not store the variable in thread-local storage. But when
I acquire a lock (using "synchronized", say), I'm supposed to
cast away the "shared", right?
IIRC ,yes.
as in
class Bar { ... }
auto foo(shared Bar bar)
{
synchronized(bar) //acquire lock
{
Bar not_shared_bar = cast(Bar) bar;
...
//use not_shared_bar here as thread local.
// No races can occur because of the lock.
// DO NOT allow references to non_shared_bar to escape
// as using them outside the synchronised could lead to
racing
}
}
Does it then still know that it's not thread-local (but that I
ensured that nobody else accesses it for the time being)?
No. it's up to you to make sure that no non-shared references
escape
Re: Check if type is from specific template?
On Thursday, 29 January 2015 at 12:10:41 UTC, bearophile wrote: Tofu Ninja: Basically what the title says, how do I check if a type T is an instantiation of a specific template? If you have an updated Phobos std.traits.isInstanceOf could be what you look for. Bye, bearophile Yep, exactly what I needed. Incidentally, while trying to see how its used I found that a lot of the links on the std.traits doc page do not work and have no documentation. For instance http://dlang.org/phobos/std_traits.html#isInstanceOf does not actually appear on the page but has a link to it up in the navigation header. Other links on that page that don't work... isAssignable, isBoolean, isIntegral, isFloatingPoint, isNumeric, isScalarType, isBasicType, isUnsigned, isSigned, isSomeChar, isSomeString, isNarrowString, isStaticArray, isDynamicArray, isArray, isAssociativeArray, isBuiltinType, isPointer, isAggregateType, isIterable, isMutable, isInstanceOf, unsigned It seems that all the variable template's docs are not getting generated...
Re: Check if type is from specific template?
Tofu Ninja: Basically what the title says, how do I check if a type T is an instantiation of a specific template? If you have an updated Phobos std.traits.isInstanceOf could be what you look for. Bye, bearophile
Check if type is from specific template?
Basically what the title says, how do I check if a type T is an instantiation of a specific template?
Re: What is @return?
@property auto info() @safe @nothrow @pure @return const { return this; }
It is mesmerizing... (@ _ @)
Re: shared Variant[string]
On Wednesday, 28 January 2015 at 12:29:09 UTC, Fyodor Ustinov
wrote:
On Wednesday, 28 January 2015 at 11:27:53 UTC, Kagamin wrote:
Associative array doesn't support thread-safe operations,
that's why they don't work on shared instance. You should use
std.concurrency or implement low-level concurrency mechanism.
If associative array does not support "share" attribute, this
code should not be compiled without any warning or error, I
think:
shared string[string] t;
void main() {
t["t"] = "bebebe";
}
But will.
string is a shorthand for "immutable char" - and immutables are
shared by default. No thread can modify them, so default shared
is safe for them.
Re: Import paths do not work
I would suggest instead of using make, use dub[0] build manager instead. It'll handle grabbing all the files and compiling them correctly. [0] http://code.dlang.org/package-format Or for simple projects such as this one seems to be, just use rdmd. Atila
What is RTInfo?
object.d [1] says it's infomation for the precise GC (which I thought wasn't implemented yet). It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. So, what is RTInfo and what is its purpose. And how is it different from TypeInfo? Thanks, Mike [1] https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L180
