Re: Nobody understands templates?
On Sunday, 2 March 2014 at 06:50:02 UTC, Steve Teale wrote: On Saturday, 1 March 2014 at 22:16:54 UTC, woh wrote: You probably don't have a good understanding of templates if you have only used 2 in your entire codebase. Or you are talking about a very tiny codebase. That's just what us template-blind people want to hear - confirmation that we are in fact stupid. The project I'm talking about is about 3 loc excluding blank lines and comments. What I'd like to see is a tool, or a switch on the compiler that emits the code generated by templates. We - the template-blind - would have it sussed in a heartbeat then. Steve There is nothing wrong about not using templates. Almost any compile-time design can be moved to run-time and expressed in more common OOP form. And using tool you have mastery of is usually more beneficial in practice than following the hype.
Re: Nobody understands templates?
On Sunday, 2 March 2014 at 10:05:05 UTC, Dicebot wrote: There is nothing wrong about not using templates. Almost any compile-time design can be moved to run-time and expressed in more common OOP form. And using tool you have mastery of is usually more beneficial in practice than following the hype. Yes DB, we can soldier on happily, but it would not do any harm to understand templates. The documentation examples quickly make your eyes glaze over, looking at the code in Phobos is doubtless instructive, but you can wade through a lot of that without finding what you want. Also I discovered an interesting fact today. the word 'mixin' does not appear in the language reference Templates section of dlang.org. It should be used in at least one example. I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before. While I'm here, has anyone discovered a way to fudge a constructor super(..) call in a mixin template that's included in a class constructor. Since the mixin template is evaluated in the scope of the constructor, it seems like it should be OK. I'm sure I'll get there in time ;=) Steve
Re: Nobody understands templates?
On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote: On Sunday, 2 March 2014 at 10:05:05 UTC, Dicebot wrote: There is nothing wrong about not using templates. Almost any compile-time design can be moved to run-time and expressed in more common OOP form. And using tool you have mastery of is usually more beneficial in practice than following the hype. Yes DB, we can soldier on happily, but it would not do any harm to understand templates. The documentation examples quickly make your eyes glaze over, looking at the code in Phobos is doubtless instructive, but you can wade through a lot of that without finding what you want. Also I discovered an interesting fact today. the word 'mixin' does not appear in the language reference Templates section of dlang.org. It should be used in at least one example. I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before. While I'm here, has anyone discovered a way to fudge a constructor super(..) call in a mixin template that's included in a class constructor. Since the mixin template is evaluated in the scope of the constructor, it seems like it should be OK. I'm sure I'll get there in time ;=) Steve This is quite a nice read on D templates: http://ddili.org/ders/d.en/templates.html
Re: Nobody understands templates?
On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote: The documentation examples quickly make your eyes glaze over, looking at the code in Phobos is doubtless instructive, but you can wade through a lot of that without finding what you want. Try this: http://nomad.so/2013/07/templates-in-d-explained/
Re: Colons and brackets
evilrat wrote in message news:mxhmgkljrzqhaymec...@forum.dlang.org...
On Friday, 28 February 2014 at 04:19:47 UTC, Etienne Cimon wrote:
How do you stop statements from belonging to the specific version of
code without using brackets?
add version(all): after code where specific version ends.
This is incorrect, there is no way to do this.
The compiler translates
version(...):
...
into
version(...)
{
...
}
So any version labels after the first are moved inside the first.
You can see it with this code:
version = y;
version(x):
pragma(msg, versionx);
version(y):
pragma(msg, versiony);
Nothing is printed, because the version(y) block is inside the version(x)
block, and version(x) is not set.
The answer: use braces.
Re: Nobody understands templates?
https://semitwist.com/articles/article/view/template-primer-in-d http://nomad.so/2013/07/templates-in-d-explained/ http://ddili.org/ders/d.en/templates.html That's a nice list. Is there a place on the wiki where these could be linked to?
Re: Nobody understands templates?
On Saturday, 1 March 2014 at 18:00:21 UTC, Steve Teale wrote: On Friday, 28 February 2014 at 19:06:26 UTC, Dicebot wrote: On Friday, 28 February 2014 at 18:42:57 UTC, Steve Teale wrote: Is this typical - libraries use templates, applications don't, or am I just being unimaginative? Steve Also every time you catch yourself doing any sort of copy-paste, it is quite possible that it can be replaced by mixin / template mixin instead. Application that are built in more declarative way benefit more from such tool set than traditional imperative ones. In have a couple of case that always require me to find some other instance of it, and then copy/paste, But then I need to edit the pasted code anyway because in any particular case it needs to deal with different command info, so how can mixins help me? I have already dealt with the yada-yada cases by old-fashioned OOP. From the various answers to this question I have concluded that I should not worry about it. If there's a need for a template I think I am already recognizing it. Thanks!all() Steve This is the best think I've read: https://github.com/PhilippeSigaud/D-templates-tutorial
Re: Colons and brackets
On 2014-03-01 16:42, anonymous wrote: I.e. version(all): doesn't cancel a former version(foo):. There may or may not be a way to cancel a version(foo):. I can't think of anything. Also, I don't see the problem with brackets. Brackets (braces) with good practice requires changing the indentation of everything in it :/ To keep it clean I decided to put the different sources in separate files and put the version clause near the import or with version (DEFINES): at the top of the page..
Re: How to build DMD on windows ?
On Friday, 28 February 2014 at 22:27:12 UTC, Vladimir Panteleev wrote: On Friday, 28 February 2014 at 20:14:26 UTC, Remo wrote: How to build DMD on windows ? And then run all the test for it? README.md is pretty empty at the moment. Of course it is possible to wait for some Fixes in DMD compiler may be it could be faster just to fix them by my self and then hope that the fix will be accepted... There is a guide for building DMD on the wiki: http://wiki.dlang.org/Building_DMD Maybe it should be linked to from the README... Thanks you. Yes it could be be really helpful is this link was already in the README.
Is it possible to elegantly craft a class that can be used as shared and as normal?
Is it possible to elegantly craft a class that can be used as
shared and as normal?
I have a class which functions fine when instantiated as normal
but i want to enable it for use for shared objects.
auto t = T();
auto t = shared(T)(); //--- like this.
Then i have the problem that a shared object can not call non
shared methods. The only solution i can see is to have multiple
overloads of the class' methods to handle being shared, like this:
class T
{
public void Foo() {...}
public shared void Foo() {...}
}
Is this the right way of going about this? The reason i ask is
that both methods have exactly the same code and to avoid
duplication i'm using mixins for each method body, yuk! help?
Re: Is it possible to elegantly craft a class that can be used as shared and as normal?
shared and non-shared entities have different implementation. You unlikely want to have one for both.
Re: Nobody understands templates?
On Sunday, 2 March 2014 at 15:23:03 UTC, H. S. Teoh wrote: This is a pretty good primer to templates: https://semitwist.com/articles/article/view/template-primer-in-d The trouble is with most of these tutorials that they offer examples that are things you would probably never want to do. I can already add an int to an int, or a double to a double, or an int to a double. Perhaps the examples should pick on something like vector operations, but then who would be doing those with int, or some class? It would be doubles or pairs of, as in struct Coord. I believe readers would study documentation and examples much more carefully if they were things they might realistically want to do. And that won't be type conversion - std.conv already does a pretty good job on that. So what? We could really do with a place where template savvy open source contributors could publish interesting examples of template use. Otherwise, Joe Soap, like me, can spend a great deal of time and effort in: a) Determining when the use of a template might be advantageous, b) Hacking at test programs to determine what the documentation means, and what works, and what doesn't. c) After that, deciding whether it would be just as effective to use two or three separate methods. Steve Steve
Re: Is it possible to elegantly craft a class that can be used as shared and as normal?
On Sunday, 2 March 2014 at 18:04:06 UTC, Dicebot wrote: shared and non-shared entities have different implementation. You unlikely want to have one for both. It's part of my unit-testing toolkit that handles mocking of objects. I want to use the same code to handle shared and non-shared entities.
Re: Is it possible to elegantly craft a class that can be used as shared and as normal?
On Sunday, 2 March 2014 at 20:16:42 UTC, Gary Willoughby wrote: On Sunday, 2 March 2014 at 18:04:06 UTC, Dicebot wrote: shared and non-shared entities have different implementation. You unlikely want to have one for both. It's part of my unit-testing toolkit that handles mocking of objects. I want to use the same code to handle shared and non-shared entities. I didn't like this feature as well, though after a while, you start getting used to it. Anyway, defining all methods as shared, using `cast()` when you don't want to use it as non-shared can be the best option for you I think. I discovered that `cast()` recently, and was writing whole class name all times.
Re: GC.BlkAttr.FINALIZE
On Sat, 01 Mar 2014 09:57:44 -0500, Namespace rswhi...@googlemail.com wrote: I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate. Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right... -Steve
Re: enum abuse
On Sat, 01 Mar 2014 00:39:23 -0500, Meta jared...@gmail.com wrote: On Friday, 28 February 2014 at 19:09:06 UTC, Steven Schveighoffer wrote: For a *VERY* short time (I think one version perhaps), we had the 'manifest' keyword which was supposed to mean manifest constant. It was removed, Andrei was a very stanch supporter of enum being the manifest constant keyword. This comment in an early debate about what became the inout feature is pretty explanatory: https://d.puremagic.com/issues/show_bug.cgi?id=1961#c3 And enum... you'll have to yank that out from my dead cold hands. Extending enum instead of adding yet another way of defining symbolic constants is The Right Thing to do. I am sure people would have realized how ridiculous the whole manifest thing is if we first proposed it. We just can't define one more way for each kind of snow there is. -Steve Hmm, I didn't know that. Interesting. I think this was a mistake on Andrei's part, though. The concept of enumerations doesn't have anything to do with evaluating an expression at compile time other than how it's implemented in D and C++, so overloading the keyword to mean evaluate this expression at compile time does not seem like a good choice. I think it's not so much that enum doesn't always mean enumeration in D, it doesn't in C or C++ either. It can be used to define bitfields, whatever. The point I think Andrei was trying to make is that enum in C and C++ does what we want, we just need to extend the types it works with. To change the name of enum would be catastrophic for existing D and C code, and to create a new name for something so totally similar would be bikeshedding. -Steve
Re: GC.BlkAttr.FINALIZE
On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote: On Sat, 01 Mar 2014 09:57:44 -0500, Namespace rswhi...@googlemail.com wrote: I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate. Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right... -Steve Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?
Re: GC.BlkAttr.FINALIZE
On Sun, 02 Mar 2014 15:44:47 -0500, Namespace rswhi...@googlemail.com wrote: On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote: On Sat, 01 Mar 2014 09:57:44 -0500, Namespace rswhi...@googlemail.com wrote: I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate. Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right... -Steve Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...? You HAVE to recompile phobos, because druntime is statically included inside it ;) -Steve
Re: GC.BlkAttr.FINALIZE
On Sunday, 2 March 2014 at 20:45:42 UTC, Steven Schveighoffer wrote: On Sun, 02 Mar 2014 15:44:47 -0500, Namespace rswhi...@googlemail.com wrote: On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote: On Sat, 01 Mar 2014 09:57:44 -0500, Namespace rswhi...@googlemail.com wrote: I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate. Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right... -Steve Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...? You HAVE to recompile phobos, because druntime is statically included inside it ;) -Steve Ahh.. I thought it is enough to recompile druntime... :)
Disabling the Garbage Collector
How to disable D's Garbage Collector? I have read stuff about editing Phobos and simply take it out, and replace it with your own to have stuff like the new keyword still work. Surely there must be an easier way, where you can still allocate like you normally would, as long as you deallocate too. I've read about ways to disable the garbage collector, but that'd mean it was initially enabled.
Re: Is it possible to elegantly craft a class that can be used as shared and as normal?
On Sunday, 2 March 2014 at 20:23:26 UTC, Tolga Cakiroglu wrote: On Sunday, 2 March 2014 at 20:16:42 UTC, Gary Willoughby wrote: On Sunday, 2 March 2014 at 18:04:06 UTC, Dicebot wrote: shared and non-shared entities have different implementation. You unlikely want to have one for both. It's part of my unit-testing toolkit that handles mocking of objects. I want to use the same code to handle shared and non-shared entities. I didn't like this feature as well, though after a while, you start getting used to it. Anyway, defining all methods as shared, using `cast()` when you don't want to use it as non-shared can be the best option for you I think. I discovered that `cast()` recently, and was writing whole class name all times. Have you got a small example?
Re: Disabling the Garbage Collector
Jeroen Bollen:
I've read about ways to disable the garbage collector, but
that'd
mean it was initially enabled.
You can disable and then enable the garbage collector like this:
void main() {
import core.memory;
GC.disable;
// Do stuff here.
GC.enable;
}
But if you perform GC-managed operations, they will not free
their memory, like array appending, array concat, inserts in
associative arrays, and so on.
You can also stub away the GC in a more complex way.
Bye,
bearophile
Re: Disabling the Garbage Collector
On Sunday, 2 March 2014 at 23:17:12 UTC, bearophile wrote:
Jeroen Bollen:
I've read about ways to disable the garbage collector, but
that'd
mean it was initially enabled.
You can disable and then enable the garbage collector like this:
void main() {
import core.memory;
GC.disable;
// Do stuff here.
GC.enable;
}
But if you perform GC-managed operations, they will not free
their memory, like array appending, array concat, inserts in
associative arrays, and so on.
You can also stub away the GC in a more complex way.
Bye,
bearophile
That'd mean that the garbage collector was initialized in the
first place, wouldn't it?
Is there maybe a way to disable the garbage collector from
running unless you explicitly call it?
Re: Disabling the Garbage Collector
Jeroen Bollen: Is there maybe a way to disable the garbage collector from running unless you explicitly call it? I often seem to ask silly questions, but why do you need that? Bye, bearophile
Re: Disabling the Garbage Collector
On Sunday, 2 March 2014 at 23:21:49 UTC, Jeroen Bollen wrote: Is there maybe a way to disable the garbage collector from running unless you explicitly call it? That's really the default. The GC in D runs if and only if you do a GC allocation and there isn't enough memory in its existing pool. Then it tries to do a collection to make room (and if that fails, it asks the operating system for more memory to grow its arena, and if that fails, it throws OutOfMemoryError). If you call GC.disable, it just sets a flag to skip the try collection step. But, in any case, the GC doesn't sit around in the background constantly running at random times. It only runs when you call on it to allocate.
Re: GC.BlkAttr.FINALIZE
It's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :P
Mutexes and locking
I think I'm missing something big, but I'm having troubles with
mutexes (using in a parallel foreach loop somewhere else); Why do
the trylocks return true shouldn't they return false because the
mutex is already locked? I don't think this is a phobos bug, I'm
on OSX using dmd 2.065
import core.sync.mutex;
import std.stdio;
void main()
{
Mutex m = new Mutex;
m.lock();
writefln(%s, m.tryLock());
writefln(%s, m.tryLock());
return;
}
produces:
true
true
Thanks!
Alex
Re: Mutexes and locking
On 03/02/2014 10:38 PM, alexhairyman wrote:
I think I'm missing something big, but I'm having troubles with mutexes
(using in a parallel foreach loop somewhere else); Why do the trylocks
return true shouldn't they return false because the mutex is already
locked?
The documentation says that Mutex is a recursive lock, meaning that the
holder of the lock can lock it even further. :) There is an internal
reference count so that the lock must be unlocked the equal number of
times that it has been locked.
I don't think this is a phobos bug, I'm on OSX using dmd 2.065
import core.sync.mutex;
import std.stdio;
void main()
{
Mutex m = new Mutex;
m.lock();
writefln(%s, m.tryLock());
writefln(%s, m.tryLock());
The lock count is now 3. You must unlock it 3 times so that another
thread can lock it.
return;
}
produces:
true
true
Thanks!
Alex
Ali
