Re: Dynamic bindings for OpenCL, libsndfile, FANN and BASS libraries
I've updated my derelictified dynamic bindings for: - OpenCL the Computing Library (thanks goes to vuaru) - BASS, an audio library - FANN, a neural network library - libsndfile, a library which read and write a variety of audio files Added Enet bindings: https://github.com/p0nce/DerelictENet
Re: [OT] My C++ talk at GoingNative 2013
On Friday, 13 September 2013 at 06:51:52 UTC, deadalnix wrote: There is 2 ask us anything. Can you tell us which one and approximately when ? Yes, the first one ( http://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-Anything ) around 01:14:20.
Re: [OT] My C++ talk at GoingNative 2013
On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei Just wanted to say thanks for posting the link, it was a great talk. Of the other talks I especially enjoyed those by the backend VC compiler guys, Compiler++ and Compiler Confidential. Watching your second talk on tuples I couldn't help thinking how much easier templates are in D. When reading C++ I find I have to make a context switch between run-time and compile-time thinking. It's quite jarring. In D, however, templates come naturally and it's very seamless.
Implementing and optimizing a simple graph metric
Hello all,
I thought I'd do a writeup of the process of implementing and
optimizing one of the graph metrics in Dgraph, starting from a
fairly straight copy of pseudo-code in a research paper all
through the various incremental tweaks that improve performance.
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
I guess the optimizations made in this process are trivial for
anyone experienced in D, but I hope the detailed description of
what changes produce useful speedups might be useful for people
new to the language.
{Enj,Destr}oy :-)
Best wishes,
-- Joe
Re: Implementing and optimizing a simple graph metric
Joseph Rushton Wakeling:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
Some small improvements:
T[] betweenness(Graph, T = double)(ref Graph g, bool[] ignore =
null)
if (isGraph!Graph isFloatingPoint!T)
{
enum T T0 = 0;
enum T T1 = 1;
auto centrality =
minimallyInitializedArray!(typeof(return))(g.vertexCount);
centrality[] = T0;
auto stack = new size_t[g.vertexCount];
auto sigma = minimallyInitializedArray!T(g.vertexCount);
sigma[] = T0;
auto delta = minimallyInitializedArray!T(g.vertexCount);
delta[] = T0;
auto d = minimallyInitializedArray!long(g.vertexCount);
d[] = -1;
auto q = VertexQueue(g.vertexCount);
auto p = new Appender!(size_t[])[g.vertexCount];
foreach (immutable s; 0 .. g.vertexCount)
{
if (ignore ignore[s])
{
continue;
}
size_t stackLength = 0;
assert(q.empty);
sigma[s] = T1;
d[s] = 0;
q.push(s);
while (!q.empty)
{
immutable size_t v = q.front;
q.pop;
stack[stackLength] = v;
++stackLength;
foreach (immutable w; g.neighboursOut(v))
{
if (ignore ignore[w])
{
continue;
}
if (d[w] 0)
{
q.push(w);
d[w] = d[v] + 1;
assert(sigma[w] == T0);
sigma[w] = sigma[v];
p[w].clear;
p[w].put(v);
}
else if (d[w] (d[v] + 1))
{
/* w has already been encountered, but we've
found a shorter path to the source. This
is probably only relevant to the weighted
case, but let's keep it here in order to
be ready for that update. */
d[w] = d[v] + 1L;
sigma[w] = sigma[v];
p[w].clear;
p[w].put(v);
}
else if (d[w] == (d[v] + 1))
{
sigma[w] += sigma[v];
p[w].put(v);
}
}
}
while (stackLength 0)
{
--stackLength;
immutable w = stack[stackLength];
foreach (immutable v; p[w].data)
{
delta[v] += ((sigma[v] / sigma[w]) * (T1 +
delta[w]));
}
if (w != s)
{
centrality[w] += delta[w];
}
sigma[w] = T0;
delta[w] = T0;
d[w] = -1;
}
}
static if (!g.directed)
{
centrality[] /= 2;
}
return centrality;
}
Just for a test, try to allocate all those arrays in a different
way:
- First try a std.array.Array using the LDC2 compiler;
- Another thing to try is to allocate them on the stack using
core.stdc.stdlib.alloca:
auto p = cast(T*)alloca(T.sizeof * g.vertexCount);
if (!p) throw new MemoryError...
auto centrality = p[0 .. g.vertexCount];
This probably can't be used for very large graphs, so you have to
add even more logic to allocate the arrays on the C heap if they
are too much large. This could be useful if you call
betweenness() many many times.
- Try to optionally accept the buffers from outside.
Bye,
bearophile
Re: Implementing and optimizing a simple graph metric
On Wednesday, 18 September 2013 at 13:39:29 UTC, bearophile wrote: Just for a test, try to allocate all those arrays in a different way: - First try a std.array.Array using the LDC2 compiler; - Another thing to try is to allocate them on the stack using core.stdc.stdlib.alloca: auto p = cast(T*)alloca(T.sizeof * g.vertexCount); if (!p) throw new MemoryError... auto centrality = p[0 .. g.vertexCount]; This probably can't be used for very large graphs, so you have to add even more logic to allocate the arrays on the C heap if they are too much large. This could be useful if you call betweenness() many many times. - Try to optionally accept the buffers from outside. Nice suggestions, I'll try those out! :-) I think I did give std.array.Array a trial when trying to speed up its performance, and I don't remember it making any difference (if anything it may have slowed things down). But I'll give it a second look and report back. I haven't yet tried alloca or other manual memory management -- I felt a bit resistant to this as I'd prefer to keep the code simple and readable -- but I'll give that a go too just to see how it goes. It's interesting that you pick up on my use of to!T(0) etc. I had some concern about whether that would affect speed at all. At the time of originally writing the code, my impression was that not having it actually made things worse, and that the compiler was smart enough to carry out the conversion at compile-time. However, my impression now is that having or not having it, or any other method (e.g. enum T0, T1, etc.) makes absolutely no difference, and that I might as well be simple and write 0 for integral-types, 0.0 for floating-point.
Re: Implementing and optimizing a simple graph metric
Joseph Rushton Wakeling: I haven't yet tried alloca or other manual memory management -- I felt a bit resistant to this as I'd prefer to keep the code simple and readable -- but I'll give that a go too just to see how it goes. I'd like some stack-allocated variable-length array in D+Phobos, as in C++14. It's also a basis to build several other stack-allocated data structures. However, my impression now is that having or not having it, or any other method (e.g. enum T0, T1, etc.) makes absolutely no difference, and that I might as well be simple and write 0 for integral-types, 0.0 for floating-point. Right. And this could be right even if you want T=Rational. Bye, bearophile
Re: [OT] My C++ talk at GoingNative 2013
On Wednesday, 18 September 2013 at 10:18:43 UTC, growler wrote: Watching your second talk on tuples I couldn't help thinking how much easier templates are in D. When reading C++ I find I have to make a context switch between run-time and compile-time thinking. It's quite jarring. In D, however, templates come naturally and it's very seamless. This is how i feel too, templates in D are an absolute joy to use and so natural!
Re: Implementing and optimizing a simple graph metric
On Wednesday, 18 September 2013 at 15:22:51 UTC, bearophile wrote: Joseph Rushton Wakeling: I haven't yet tried alloca or other manual memory management -- I felt a bit resistant to this as I'd prefer to keep the code simple and readable -- but I'll give that a go too just to see how it goes. I'd like some stack-allocated variable-length array in D+Phobos, as in C++14. It's also a basis to build several other stack-allocated data structures. Yes, that'd be useful, although in the case of this code I think that stack vs. heap probably isn't that important. If the data is small enough for stack allocation, the calculation will be quick anyway. However, my impression now is that having or not having it, or any other method (e.g. enum T0, T1, etc.) makes absolutely no difference, and that I might as well be simple and write 0 for integral-types, 0.0 for floating-point. Right. And this could be right even if you want T=Rational. Actually, on re-testing this just now, I'm returning to my original view. I find that if you put in raw floating-point numbers like 0.0, 1.0 etc. the resulting code can be slower in the case where T = float. Putting to!T or using enums as you suggest appears to make no difference. This is a guess rather than confirmed by looking at assembly, but I'm presuming that to!T(0) and other conversions of compile-time constants are evaluated at compile time, so you don't in practice carry the cost you'd normally get from using to().
Re: Implementing and optimizing a simple graph metric
On Wednesday, 18 September 2013 at 15:17:25 UTC, Joseph Rushton Wakeling wrote: I think I did give std.array.Array a trial when trying to speed up its performance, and I don't remember it making any difference (if anything it may have slowed things down). But I'll give it a second look and report back. I tried rewriting the variable declarations: Array!T centrality; centrality.length = g.vertexCount; centrality[] = to!T(0); Array!size_t stack; stack.length = g.vertexCount; Array!T sigma; sigma.length = g.vertexCount; Array!T delta; delta.length = g.vertexCount; Array!long d; d.length = g.vertexCount; auto q = VertexQueue(g.vertexCount); Appender!(size_t[])[] p = new Appender!(size_t[])[g.vertexCount]; It results in a moderate slowdown of the code, at a guess because it increases the total number of mallocs/deallocs. I note that there seems to be no way to initialize std.container.Array as having a certain length ... ? I tried instead using std.array.uninitializedArray to initialize the arrays in the betweenness() function -- it was a bit difficult to judge here: with a relatively small number of calls to betweenness() it seems to have resulted in a speedup, but with very many calls, it seems to have been slower.
Re: Implementing and optimizing a simple graph metric
Joseph Rushton Wakeling: in the case of this code I think that stack vs. heap probably isn't that important. If the data is small enough for stack allocation, the calculation will be quick anyway. How many times or how often do you need to call betweenness()? If it's called only few times or once in a while then using the GC is good enough. But if you have to call it many millions of times, all those GC array allocations could cost some time, even if they are small arrays. In this case allocating them on the stack (or not allocating them, using externally allocated buffers) helps. Bye, bearophile
Re: Implementing and optimizing a simple graph metric
On Wednesday, 18 September 2013 at 13:39:29 UTC, bearophile wrote:
- Try to optionally accept the buffers from outside.
Does this look good to you?
/
auto ref betweenness(T = double, Graph)(ref Graph g, bool[]
ignore = null)
if (isFloatingPoint!T isGraph!Graph)
{
T[] centrality = new T[g.vertexCount];
return betweenness!(T, Graph)(g, centrality, ignore);
}
auto ref betweenness(T = double, Graph)(ref Graph g, ref T[]
centrality, bool[] ignore = null)
{
centrality.length = g.vertexCount;
centrality[] = to!T(0);
// ... the rest as before
}
/
Re: I'm porting some go code to D
I've made the scheduler a bit more inteligent and the channel
implementation is now backed by a lock free queue.
https://github.com/rjmcguire/goport/blob/tip/wrapper2.d for a example using
libev
https://github.com/rjmcguire/goport/blob/tip/goroutine.d for the go
routines
https://github.com/rjmcguire/goport/blob/tip/channel.d channel
implementation, the channel still has a read lock because I didn't like
looping wasting cpu cycles/battery, I may change this to use the same loop
as the select(...) expression with a timeout that backs off.
https://github.com/rjmcguire/goport/blob/tip/concurrentlinkedqueue.d queue
implementation
there is a problem with the file EV handler in that it can get spurios READ
events and I can't seem to set it to non-blocking.
The select(...) implementation and usage is quite interesting because it
works very much like Go's select statement.
On Mon, Aug 26, 2013 at 1:28 AM, Rory McGuire rjmcgu...@gmail.com wrote:
Awesome thanks, thought what I did there was dodgy. It was really weird
when this() started multiple schedulers at least now I see the obvious
reason.
BTW: gist is at: https://gist.github.com/rjmcguire/6336931
Could someone point me at the correct linked list to use inside the
channel. I'd prefer to use a range container of some kind if it exists in
the std lib. I tried SList and had a bad experience hence the custom
implementation.
On Mon, Aug 26, 2013 at 1:21 AM, Timon Gehr timon.g...@gmx.ch wrote:
On 08/26/2013 12:55 AM, Rory McGuire wrote:
shared chan!Fiber scheduler; // channel contains Fibers waiting for
their time slice
static this () {
if (scheduler is null) {
You want 'shared static this' instead to avoid a race condition.
Re: How Compilers Work
On Wednesday, 18 September 2013 at 05:23:03 UTC, Walter Bright wrote: http://i.imgur.com/OnMc8HO.jpg Today I learned that mixin(*msg.base. ~ member ~ _assign)(msg, value); is valid D syntax.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 17 September 2013 at 15:34:15 UTC, Bruno Medeiros wrote: On 17/09/2013 15:48, eles wrote: On Monday, 16 September 2013 at 15:52:26 UTC, Bruno Medeiros wrote: On 13/09/2013 08:46, eles wrote: On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright (In hindsight I do agree it might have been better to have it hosted on Github. I encourage you to do that, in the beginning. After the VisualD move will mature a bit and, hopefully, DDT will integrate with the debugger, it will become official. Speaking about that, did you have the time to have a look at Descent's debugging module? Recently, Iain really improved gdc's gdb debugging support, and supporting at least gdb (it is usable on Windows, too) would be a break-through.
Re: Had another 48hr game jam this weekend...
On 18 September 2013 14:09, Dicebot pub...@dicebot.lv wrote: On Wednesday, 18 September 2013 at 00:47:09 UTC, Manu wrote: Mint15... Link me? I can't find it. Mint is Debian/Ubuntu based so you should look at PPA mentioned above: That looks thoroughly unofficial. Why should I trust it? MonoDevelop's website points to badgerports which is thoroughly out of date: http://monodevelop.com/Download My friend also found this: http://software.opensuse.org/download/package?project=home:tpokorra:monopackage=monodevelop-opt I'm not sure what to trust if I can't even trust the official website... If you're on some sort of ubuntu variant: https://launchpad.net/~keks9n/** +archive/monodevelop-latesthttps://launchpad.net/~keks9n/+archive/monodevelop-latest
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 00:45:58 UTC, Manu wrote: On 18 September 2013 00:35, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 17/09/13 16:19, Manu wrote: I had some experience with kdevelop this past weekend trying to find a reasonable working environment on linux. It's fairly nice. Certainly come along since I last tried to take it seriously a year or 2 back. It would be nice if there was D support though. It has rudimentary support that some whipped up, but it could do a lot better. Do you have any experience/opinion on Qt Creator as an IDE? My impression is that it's nice in and of itself but limited compared to others in the range of languages/tools it supports -- but it's a very superficial impression so may be wrong. The extent of my experience with QtCreator is that it has a button Generate VS Project in the menu, which I clicked on, and then I opened visual studio. For the few moments that I used it, I was surprised by now un-like-eclipse it looked :) Maybe it's decent? What's it's underlying project/build system? I have ex-trolltech mates who are now all unemployed... so what's the future of the tool? It is the official IDE for Qt development, so I guess while Digia has customers it will be developed.
Re: Had another 48hr game jam this weekend...
On Tuesday, 17 September 2013 at 15:15:09 UTC, Bruno Medeiros wrote: On 17/09/2013 15:19, Manu wrote: On 17 September 2013 23:46, Bruno Medeiros brunodomedeiros+...@gmail.com mailto:brunodomedeiros+...@gmail.com wrote: On 17/09/2013 07:24, Manu wrote: I closed about half my open tabs after my last email (~50 left open). Down to 93mb. You must all use some heavy plugins or something. My current solution has 10 projects, one is an entire game engine with over 500 source files, hundreds of thousands of LOC. Intellisense info for all of it... dunno what to tell you. Eclipse uses more than 4 times that much memory idling with no project open at all... 4 times ? You must have a pretty light instance of eclipse ! It's a fairly fresh eclipse install, and I just boot it up. It showed the home screen, no project loaded. It was doing absolutely nothing and well into 400mb. When I do use it for android and appengine, it more or less works well enough, but the UI feels like it's held together with stickytape and glue, and it's pretty sluggish. Debugging (native code) is slow and clunky. How can I take that software seriously? I probably waste significant portion of my life hovering and waiting for eclipse to render the pop-up variable inspection windows. That shit needs to be instant, no excuse. It's just showing a value from ram. Then I press a key, it doesn't take ages for the letter to appear on the screen... Android and Appengine? There are two flaws in that comparison, the first is that apparently you are comparing an Eclipse installation with a lot more tools than your VS installation (which I'm guessing has only C++ tools, perhaps some VCS tools too?). No wonder the footprint is bigger. For example, my Eclipse instance with only DDT and Git installed, and opened on a workspace with D projects takes up 130Mb: http://i.imgur..com/VmKzrRU.png http://i.imgur.com/VmKzrRU.png My VS installation has VisualD, VCS tools, xbox 360, ps3, android, emsscripten, nacl, clang and gcc tools. (I don't think these offer any significant resource burden though, they're not really active processes) If Eclipse has a lot more tools as you say, then it's a problem is that I never selected them, and apparently they hog resources even when not being used. That seems like a serious engineering fail if that's the case. As far as I know, I don't have DDT and git installed, so you're 2 up on me :) .. I only have android beyond default install (and no project was open). No appengine in this installation. Eclipse is designed such that plugins should be lazy-loaded: they are only loaded when needed (for example if you open a view/editor/preference-page/project, etc., contributed from a plugin). But that requires the plugin to be well-behaved in that regards, and some plugins might not be so. I'm not familiar at all with the Eclipse Android plugins or AppEngine plugins so I have no idea how these behave performance wise. I can't comment on that. Again it should noted that Eclipse is not a monolithic application, and a lot of things are going to depend on what plugins/tools you have installed. (neither is VisualStudio a monolithic application, but I would argue that Eclipse has more plugins and extensions available, and thus more variation in setup and quality of installations) With the recommend JVM memory settings (see http://code.google.com/p/ddt/__wiki/UserGuide#Eclipse_basics http://code.google.com/p/ddt/wiki/UserGuide#Eclipse_basics ), the usage in that startup scenario goes up to 180Mb. But even so that is not a fair comparison, the second flaw here is that Eclipse is running on a VM, and is not actually using all the memory that is taken from the OS. It's perfectly fair. Let's assume for a second that I couldn't care less that it runs in a VM (I couldn't), all you're really saying is that VM's are effectively a waste of memory and performance, and that doesn't redeem Eclipse in any way. You're really just suggesting that Eclipse may be inherently inefficient because it's lynched by it's VM. So there's no salvation for it? :) If you wanna see how much memory the Java application itself is using for its data structures, you have to use a tool like jconsole (included in the JDK) to check out JVM stats. For example, in the DDT scenario above, after startup the whole of Eclipse is just using just 40Mb for the Java heap: http://i.imgur..com/yCPtS52.png http://i.imgur.com/yCPtS52.png I don't care how much memory the app is 'really' using beneath it's
Re: Had another 48hr game jam this weekend...
On 18 September 2013 17:45, PauloPinto pj...@progtools.org wrote: It is mostly C# actually. The VS 2010 rewrite was a way to fix WPF bugs and prove the developers at large that big applications could be done in WPF. As far as I can tell from MSDN blogs, the only C++ bits left standing were the ones related to C++ development. This most likely changed with the whole Going Native story afterwards. It's clear that MS have no idea WTF they're doing with VisualStudio, that's been clear for half a decade... I'm just waiting for a viable alternative to emerge. Still nothing...
Re: How Compilers Work
On Wednesday, 18 September 2013 at 06:11:44 UTC, Brian Schott wrote: On Wednesday, 18 September 2013 at 05:23:03 UTC, Walter Bright wrote: http://i.imgur.com/OnMc8HO.jpg Today I learned that mixin(*msg.base. ~ member ~ _assign)(msg, value); is valid D syntax. Where is value used?
[OT] Language Cocktail
http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D?
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it). Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Vodka plus orangeade or just vodka for real men, yes? )))
Re: [OT] Language Cocktail
On 18 September 2013 09:38, Namespace rswhi...@googlemail.com wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Should make a cocktail named 'Garbage Collector' -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 09:09:45 UTC, Iain Buclaw wrote: On 18 September 2013 09:38, Namespace rswhi...@googlemail.com wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Should make a cocktail named 'Garbage Collector' Ingredients?
Re: [OT] Which IDE / Editor do you use?
On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote: On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it). Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons. Enjoying gold cage prisons since 1991. :)
Re: [OT] Which IDE / Editor do you use?
On Wednesday, 18 September 2013 at 09:15:36 UTC, PauloPinto wrote: On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote: On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it). Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons. Enjoying gold cage prisons since 1991. :) We are all just prisoners here, of our own device - Hotel California
Re: Had another 48hr game jam this weekend...
On 18/09/13 02:45, Manu wrote: The extent of my experience with QtCreator is that it has a button Generate VS Project in the menu, which I clicked on, and then I opened visual studio. For the few moments that I used it, I was surprised by now un-like-eclipse it looked :) Maybe it's decent? What's it's underlying project/build system? I have ex-trolltech mates who are now all unemployed... so what's the future of the tool? I had the impression the future was very positive, ever since Digia acquired Qt from Nokia a couple of years back. AFAIK it can use make, cmake or qmake as project build systems and can use GDB, CDB (Microsoft?) and Valgrind for debugging. I don't have enough IDE experience to really make any judgement, but I wondered if it might meet your needs as a light, cross-platform IDE.
Re: [OT] Which IDE / Editor do you use?
On 18 September 2013 10:38, Chris wend...@tcd.ie wrote: On Wednesday, 18 September 2013 at 09:15:36 UTC, PauloPinto wrote: On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote: On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it). Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons. Enjoying gold cage prisons since 1991. :) We are all just prisoners here, of our own device - Hotel California Hanging on in quiet desperation is the English way - Time -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Something with templates or a pun on mixins? OnTheRocks(T): T 4cl Ice
Re: Zimbu
On Sunday, 15 September 2013 at 13:32:52 UTC, David Nadlinger wrote: On Sunday, 15 September 2013 at 11:39:28 UTC, Sönke Ludwig wrote: Am 15.09.2013 08:54, schrieb Nick Sabalausky: But I could swear I've seen a LLVM IR - C before... I'm pretty sure that IR - C just outputs C code that feeds LLVM with the original IR and not an equivalent of the IR itself. So it's usually no more useful than directly compiling to machine code for the target architecture. That's the C++ backend you are talking about. The C backend - which was defunct some time ago, no idea about its current state - actually generated a C code equivalent of the IR (with some limitations). Indeed. A PhD student tried to revive it last year, last updated earlier this year: http://www.es.ele.tue.nl/~rjordans/llvm-cbe-patches/
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 07:59:43 UTC, Manu wrote: On 18 September 2013 17:45, PauloPinto pj...@progtools.org wrote: It is mostly C# actually. The VS 2010 rewrite was a way to fix WPF bugs and prove the developers at large that big applications could be done in WPF. As far as I can tell from MSDN blogs, the only C++ bits left standing were the ones related to C++ development. This most likely changed with the whole Going Native story afterwards. It's clear that MS have no idea WTF they're doing with VisualStudio, that's been clear for half a decade... I'm just waiting for a viable alternative to emerge. Still nothing... I think it is all very political what is driving them. With Longhorn, there was the plan to make the OS .NET based, similar to how OS/400 works, and to certain extent Android and WP7 were done. As Longhorn project was rebooted and Vista came out, whatever problems the teams were having with Longhorn rewrite of Win32 into .NET was attributed to the tooling. As we all know in our jobs it is easier to blame tooling as the people. As such the native tools group inside Microsoft felt empowered and started pushing into the back to native direction we see nowadays. Even the WinRT runtime is nothing new, it was actually developed in 1999. Microsoft Research proposed a language neutral COM runtime, which eventually became .NET instead. http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-32-72-38/Ext_2D00_VOS.pdf Full story here, http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-generics-history-the-msr-white-paper-from-mid-1999.aspx I have no idea how far or close from the truth this is, but it is my gut feeling how these events developed themselves. Typical enterprise political games, which affect everyone that wants to target Windows as well. -- Paulo
Re: Had another 48hr game jam this weekend...
On 18 September 2013 19:44, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 18/09/13 02:45, Manu wrote: The extent of my experience with QtCreator is that it has a button Generate VS Project in the menu, which I clicked on, and then I opened visual studio. For the few moments that I used it, I was surprised by now un-like-eclipse it looked :) Maybe it's decent? What's it's underlying project/build system? I have ex-trolltech mates who are now all unemployed... so what's the future of the tool? I had the impression the future was very positive, ever since Digia acquired Qt from Nokia a couple of years back. AFAIK it can use make, cmake or qmake as project build systems and can use GDB, CDB (Microsoft?) and Valgrind for debugging. I don't have enough IDE experience to really make any judgement, but I wondered if it might meet your needs as a light, cross-platform IDE. The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, or incremental linking?
Re: Had another 48hr game jam this weekend...
On 18 September 2013 21:45, Manu turkey...@gmail.com wrote: On 18 September 2013 19:44, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 18/09/13 02:45, Manu wrote: The extent of my experience with QtCreator is that it has a button Generate VS Project in the menu, which I clicked on, and then I opened visual studio. For the few moments that I used it, I was surprised by now un-like-eclipse it looked :) Maybe it's decent? What's it's underlying project/build system? I have ex-trolltech mates who are now all unemployed... so what's the future of the tool? I had the impression the future was very positive, ever since Digia acquired Qt from Nokia a couple of years back. AFAIK it can use make, cmake or qmake as project build systems and can use GDB, CDB (Microsoft?) and Valgrind for debugging. I don't have enough IDE experience to really make any judgement, but I wondered if it might meet your needs as a light, cross-platform IDE. The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, or incremental linking? And of course their edit-and-continue support to update a binary while debugging and continue debugging the edited binary with your code tweak (an extension from incremental linking)...
Re: [OT] Which IDE / Editor do you use?
On Wed, 2013-09-18 at 11:38 +0200, Chris wrote: […] We are all just prisoners here, of our own device - Hotel California but note: You can check out any time you like, but you can never leave ibid. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Output contract's arguements
This came up in learn:
Say you have this code:
//
size_t msb(T)(T v)
in
{
assert(v != 0);
}
out(ret)
{
assert(v != 0); //Fails? Passes?
}
body
{
size_t ret = 0;
while(v = 1) ++ret;
return ret;
}
//
Question, can this output contract fail?
Apparently, it does fail, since it is passed the variable v,
*after* the body of the function is done with it.
IMO, this is wrong. When calling a function with an out contract,
the arguments should *also* be passed to the out contract
directly. out should not be expected to run on the body's
sloppy seconds.
In particular if/when we will have contracts are
managed/compiled by caller, then that behavior is the only
behavior we will be able to do (AFAIK).
Or is there something that explicitly states it works that way?
Should I file a bug report? ER?
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 09:11:06 UTC, Namespace wrote: On Wednesday, 18 September 2013 at 09:09:45 UTC, Iain Buclaw wrote: On 18 September 2013 09:38, Namespace rswhi...@googlemail.com wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Should make a cocktail named 'Garbage Collector' Ingredients? Definitely crystal clear vodka)
Re: Output contract's arguements
There are probably implementation reasons for it working this
way. I think it's perfectly acceptable for the majority of cases,
and for the edge cases where you want something like this, you
can of course always do this.
void foo(int y)
out(val) {
...
} body {
int val;
...
assert(y != 0);
return val;
}
Of course, you'd need to return only at the end of the function
for that, but there are ways around that, like inner functions,
or perhaps goto end. (Although I don't advocate use of goto.)
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote: That looks thoroughly unofficial. Why should I trust it? You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo for hosting) I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time.
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 12:37:28 UTC, Dicebot wrote: On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote: That looks thoroughly unofficial. Why should I trust it? You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo for hosting) I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time. Well, Miguel is no longer interested in Linux I guess.
Re: Had another 48hr game jam this weekend...
On 18 September 2013 22:37, Dicebot pub...@dicebot.lv wrote: On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote: That looks thoroughly unofficial. Why should I trust it? You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/**abothehttp://simendsjo.me/files/abothe(with generous help of simendsjo for hosting) I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time. So... is MonoDevelop effectively a one-man project? How is it that it doesn't have a Debian distribution? It's the most popular form of linux by far.
Re: Had another 48hr game jam this weekend...
On 18/09/13 14:37, Dicebot wrote: You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo for hosting) MonoDevelop 4 is in the proposed repository of Ubuntu 13.10: https://launchpad.net/ubuntu/saucy/+source/monodevelop ... which I hope means that it will make it into the regular repositories of the final release next month. It's also in Debian Unstable: http://packages.debian.org/sid/monodevelop
Re: Output contract's arguements
monarch_dodra: IMO, this is wrong. When calling a function with an out contract, the arguments should *also* be passed to the out contract directly. out should not be expected to run on the body's sloppy seconds. In particular if/when we will have contracts are managed/compiled by caller, then that behavior is the only behavior we will be able to do (AFAIK). Or is there something that explicitly states it works that way? Should I file a bug report? ER? This is an example of leaky abstraction, caused by the D implementation of contracts. What is the behavior of Ada and C# contracts on this? Bye, bearophile
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 12:44:07 UTC, Manu wrote: So... is MonoDevelop effectively a one-man project? https://github.com/mono/monodevelop/graphs/contributors ;) How is it that it doesn't have a Debian distribution? It's the most popular form of linux by far. There is package for older version. Version 4 branch is rather new and it will take some time until maintainer of non-bleeding edge Linux distributions will consider it stable enough to be allowed into official repositories. It is a common approach on its own. Problem is the plugin API incompatibility they do which does not allow Alex to maintain Mono-D for older version without effectively spending twice more time/efforts. I don't know the details but he was ranting about it quite a lot :) There is a certain unpleasant similarity between MonoDevelop and DMD development process :D
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 12:47:43 UTC, Joseph Rushton Wakeling wrote: MonoDevelop 4 is in the proposed repository of Ubuntu 13.10: https://launchpad.net/ubuntu/saucy/+source/monodevelop ... which I hope means that it will make it into the regular repositories of the final release next month. It's also in Debian Unstable: http://packages.debian.org/sid/monodevelop Most frustrating thing here is that that `proposed` repo has 4.0.5 while Mono-D will only work on 4.1.7+ (judging by http://mono-d.alexanderbothe.com/) :)
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 12:55:14 UTC, Dicebot wrote: On Wednesday, 18 September 2013 at 12:47:43 UTC, Joseph Rushton Wakeling wrote: MonoDevelop 4 is in the proposed repository of Ubuntu 13.10: https://launchpad.net/ubuntu/saucy/+source/monodevelop ... which I hope means that it will make it into the regular repositories of the final release next month. It's also in Debian Unstable: http://packages.debian.org/sid/monodevelop Most frustrating thing here is that that `proposed` repo has 4.0.5 while Mono-D will only work on 4.1.7+ (judging by http://mono-d.alexanderbothe.com/) :) P.S. I guess that makes Arch Linux 4.0.12 package unusable too. Love that versioning hell.
Re: Had another 48hr game jam this weekend...
On 18/09/13 14:56, Dicebot wrote: On Wednesday, 18 September 2013 at 12:55:14 UTC, Dicebot wrote: Most frustrating thing here is that that `proposed` repo has 4.0.5 while Mono-D will only work on 4.1.7+ (judging by http://mono-d.alexanderbothe.com/) :) P.S. I guess that makes Arch Linux 4.0.12 package unusable too. Love that versioning hell. That's annoying. A minor version number bump shouldn't render plugins etc. incompatible. It doesn't say many good things about the development process of MonoDevelop ... :-(
Re: [OT] Which IDE / Editor do you use?
On Wed, Sep 18, 2013 at 07:29:24AM +0200, Michael wrote: Besides, we aren't on 300 baud serial lines! As backup line I have 56k dial-up modem ;) We still trolling each other about IDE ?) Or Win 8.1 UI is the best UI? Linux is my IDE. ;-) T -- VI = Visual Irritation
Re: [OT] Language Cocktail
On 18 September 2013 13:26, Michael p...@m1xa.com wrote: On Wednesday, 18 September 2013 at 09:11:06 UTC, Namespace wrote: On Wednesday, 18 September 2013 at 09:09:45 UTC, Iain Buclaw wrote: On 18 September 2013 09:38, Namespace rswhi...@googlemail.com wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Should make a cocktail named 'Garbage Collector' Ingredients? Definitely crystal clear vodka) I think a nice mix of natural spirits would do nicely - something that doesn't leave a hangover in the morning. ;-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Move VisualD to github/d-programming-language ?
On 18/09/2013 07:58, eles wrote: Speaking about that, did you have the time to have a look at Descent's debugging module? Recently, Iain really improved gdc's gdb debugging support, and supporting at least gdb (it is usable on Windows, too) would be a break-through. Not yet. -- Bruno Medeiros - Software Engineer
Re: Move VisualD to github/d-programming-language ?
On Wednesday, 18 September 2013 at 13:21:45 UTC, Bruno Medeiros wrote: On 18/09/2013 07:58, eles wrote: Not yet. How could I help?
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. or incremental linking? This is a bit harder. If you're using the Gold linker, -Wl,--incremental sounds like your medicine, though I'm not sure if Gold is ready for primetime, yet. -Wyatt
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? D-programmers don't drink cocktails. They drink beer! But if you're trying to come up with a recipe for a cocktail, make sure that one of the ingredients is a Mars bar, and let's call it a Ducktail.
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 13:53:29 UTC, Chris wrote: On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? D-programmers don't drink cocktails. They drink beer! But if you're trying to come up with a recipe for a cocktail, make sure that one of the ingredients is a Mars bar, and let's call it a Ducktail. American beer or real beer?
Re: [OT] Language Cocktail
On 18 September 2013 14:53, Chris wend...@tcd.ie wrote: On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? D-programmers don't drink cocktails. They drink beer! But if you're trying to come up with a recipe for a cocktail, make sure that one of the ingredients is a Mars bar, and let's call it a Ducktail. Is duck typing still an advertised feature of D? -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Had another 48hr game jam this weekend...
On 18/09/13 15:54, Wyatt wrote: As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. More like, top-down vs. bottom-up resolution of dependencies. E.g. suppose you've built GDC from source -- this means you've built both the GCC backend (and C/C++ compilers etc.) and the D frontend. Now you pull in the latest updates to the frontend, and you want to rebuild. Theoretically, you shouldn't need to care about the backend at all -- it's already built -- and all that you should need to do is rebuild the frontend and the resulting GDC executable and libraries. In practice, the GCC make process will trawl through all the different subdirectories related to the backend -- it'll find that nothing needs to be rebuilt, but it takes quite some time to check all of that, when you'd like your built system to be smart enough to avoid that kind of bottom-up checking.
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 13:55:11 UTC, Namespace wrote: American beer or real beer? I said beer. This should answer your question.
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 14:31:48 UTC, Chris wrote: On Wednesday, 18 September 2013 at 13:55:11 UTC, Namespace wrote: American beer or real beer? I said beer. This should answer your question. Right answer. Are you German?
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 14:35:59 UTC, Namespace wrote: On Wednesday, 18 September 2013 at 14:31:48 UTC, Chris wrote: On Wednesday, 18 September 2013 at 13:55:11 UTC, Namespace wrote: American beer or real beer? I said beer. This should answer your question. Right answer. Are you German? In fairness, there is some really good stuff being brewed in the U.S. Sierra Nevada for example (http://www.sierranevada.com/), and there are some nice micro-breweries that produce quality stuff that is as good as any of the better German, British, Irish or Belgian beers/ales.
Qt Creator and D
Hello all, Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. My general impression is that this is a fast, light cross-platform IDE which is (as its name indicates) state-of-the-art for C++ and Qt development. Currently it has fairly good D/Ddoc syntax highlighting (it literally copies the latest d.xml syntax definition file from KDE's text editor Kate). However, I wasn't able to get things like auto-indent working, and haven't yet put any serious effort into investigating build/compiler or debugging support. It also has a FakeVim mode that enables vim-like editing and should be able to operate from the local .vimrc settings, but my brief experiments weren't so far able to get it to reproduce my current vim behaviour. The last related discussion that I'm aware of is from about 3 years back, when several D users discussed implementing Qt Creator support: http://www.digitalmars.com/d/archives/digitalmars/D/ide/Qt_Creator_with_D_707.html ... but I'm not aware of any follow-up since then. I'm just wondering how many people would be interested in seeing better D support in this IDE, and how many people have more experience or can offer insight into how to proceed. Best wishes, -- Joe
Re: Had another 48hr game jam this weekend...
On 9/18/13 6:54 AM, Wyatt wrote: On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. Plus rdmd --make-depend, yum. Andrei
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Without having looked at the link, I had a few ideas for different languages: C: Straight vodka. It's a concrete base for many things. Does the job. Fortran: Gin. Not as popular as it used to be. Many have moved to vodka. C++: Earthquake or Concrete Mixer, I can't decide. Earthquake because it's an immensely powerful mix but also unsatisfying and will royally fuck you up. Concrete mixer because of the jarring clash between templates and normal code. Python: Mojito. Little bit exotic, but very popular. Easy to do badly, but still ok even when you do. Ruby: Pina Colada. Fruity. A good blend of flavours with a unified feel. PHP: A badly made bloody mary. A complete mess. JavaScript: Sambucca. Ok in small quantities, but for gods sake don't use it as base for anything. Java: Light beer. You have to drink a lot to get anywhere, unsatisfying and falling out of fashion somewhat, but still hugely widespread. D: A well stocked, well organised drinks cabinet, with a variety of automated mixing machines. Very few glasses, some of the bottles are actually almost empty (or off) and you can't find any tools. Has been known to rearrange critical sections of itself overnight. Lacks customers. asm: chemistry set. You can definitely make cocktails with it, you just have to put in the work and concentrate :)
Re: Qt Creator and D
On Wednesday, 18 September 2013 at 14:49:27 UTC, Joseph Rushton Wakeling wrote: Hello all, Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. My general impression is that this is a fast, light cross-platform IDE which is (as its name indicates) state-of-the-art for C++ and Qt development. Currently it has fairly good D/Ddoc syntax highlighting (it literally copies the latest d.xml syntax definition file from KDE's text editor Kate). However, I wasn't able to get things like auto-indent working, and haven't yet put any serious effort into investigating build/compiler or debugging support. It also has a FakeVim mode that enables vim-like editing and should be able to operate from the local .vimrc settings, but my brief experiments weren't so far able to get it to reproduce my current vim behaviour. The last related discussion that I'm aware of is from about 3 years back, when several D users discussed implementing Qt Creator support: http://www.digitalmars.com/d/archives/digitalmars/D/ide/Qt_Creator_with_D_707.html ... but I'm not aware of any follow-up since then. I'm just wondering how many people would be interested in seeing better D support in this IDE, and how many people have more experience or can offer insight into how to proceed. Best wishes, -- Joe I would be interested in this. I usually use Kate for small/non-Qt C++/D projects, but have used QtCreator for Qt-projects on Linux and for C++ development on Windows. Craig
Re: [OT] Language Cocktail
On Wednesday, 18 September 2013 at 15:18:19 UTC, John Colvin wrote: On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? Without having looked at the link, I had a few ideas for different languages: C: Straight vodka. It's a concrete base for many things. Does the job. Fortran: Gin. Not as popular as it used to be. Many have moved to vodka. C++: Earthquake or Concrete Mixer, I can't decide. Earthquake because it's an immensely powerful mix but also unsatisfying and will royally fuck you up. Concrete mixer because of the jarring clash between templates and normal code. Python: Mojito. Little bit exotic, but very popular. Easy to do badly, but still ok even when you do. Ruby: Pina Colada. Fruity. A good blend of flavours with a unified feel. PHP: A badly made bloody mary. A complete mess. JavaScript: Sambucca. Ok in small quantities, but for gods sake don't use it as base for anything. Java: Light beer. You have to drink a lot to get anywhere, unsatisfying and falling out of fashion somewhat, but still hugely widespread. D: A well stocked, well organised drinks cabinet, with a variety of automated mixing machines. Very few glasses, some of the bottles are actually almost empty (or off) and you can't find any tools. Has been known to rearrange critical sections of itself overnight. Lacks customers. asm: chemistry set. You can definitely make cocktails with it, you just have to put in the work and concentrate :) +1
Re: Had another 48hr game jam this weekend...
On 18 September 2013 23:54, Wyatt wyatt@gmail.com wrote: On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. I've had lots of problems in the past where a header included by another header doesn't prompt the dependent code to be rebuilt, and I ended up in a conservative state of rebuild-all-ing every time... :/ Maybe I should try working with that environment more... or incremental linking? This is a bit harder. If you're using the Gold linker, -Wl,--incremental sounds like your medicine, though I'm not sure if Gold is ready for primetime, yet. How does that work? Can you re-link while paused in the debugger, and then continue with the new code?
Re: Qt Creator and D
On Wednesday, 18 September 2013 at 14:49:27 UTC, Joseph Rushton Wakeling wrote: Hello all, Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. My general impression is that this is a fast, light cross-platform IDE which is (as its name indicates) state-of-the-art for C++ and Qt development. Currently it has fairly good D/Ddoc syntax highlighting (it literally copies the latest d.xml syntax definition file from KDE's text editor Kate). However, I wasn't able to get things like auto-indent working, and haven't yet put any serious effort into investigating build/compiler or debugging support. It also has a FakeVim mode that enables vim-like editing and should be able to operate from the local .vimrc settings, but my brief experiments weren't so far able to get it to reproduce my current vim behaviour. The last related discussion that I'm aware of is from about 3 years back, when several D users discussed implementing Qt Creator support: http://www.digitalmars.com/d/archives/digitalmars/D/ide/Qt_Creator_with_D_707.html ... but I'm not aware of any follow-up since then. I'm just wondering how many people would be interested in seeing better D support in this IDE, and how many people have more experience or can offer insight into how to proceed. Best wishes, -- Joe It's the best IDE for C++ development I have encountered so far. And it's the only drawback of DMD making the change to D: I cannot use it to fix bugs anymore.
Re: Had another 48hr game jam this weekend...
On 19 September 2013 01:04, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/18/13 6:54 AM, Wyatt wrote: On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. Plus rdmd --make-depend, yum. I actually only just realised how cool rdmd was last weekend. Never occurred to me really to use it before. Very handy! Problem is, 80% of the code I write is C code still... :(
Re: Had another 48hr game jam this weekend...
On 9/18/13 8:44 AM, Manu wrote: On 19 September 2013 01:04, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org wrote: On 9/18/13 6:54 AM, Wyatt wrote: On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. Plus rdmd --make-depend, yum. I actually only just realised how cool rdmd was last weekend. Never occurred to me really to use it before. Very handy! yay 2 dat Problem is, 80% of the code I write is C code still... :( join me Andrei
Re: Opaque handles...
On 19 September 2013 02:14, Andrej Mitrovic andrej.mitrov...@gmail.comwrote:
On 9/18/13, Manu turkey...@gmail.com wrote:
And in D:
struct Thing;
extern (C) Thing* MakeThing();
The question is, does this suck?
D currently can't allocate an array of Thing*'s for some weird reason.
This is just a current bug that will be fixed. As a workaround you can use
this:
struct Thing
{
@disable this();
@disable this(this);
}
This will ensure Thing will never be copied by value, and you can
only use it with a pointer.
But since I'm always dealing with a pointer rather than a real type, I
can't implement logic to inc/dec the ref-count on assignment. And how do I
handle destruction/garbage collection?
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 16:09:46 UTC, Manu wrote: rdmd implies rebuild-all every time. It doesn't really scale. Have you actually tried it? My biggest D program is coming up on 100,000 lines of code, plus phobos, and I still compile it all at once, every time. The compile time is ~15 seconds, slower than I'd like (due to ctfe more than anything else) but not bad. Compiling all of phobos at once, 100,000 lines of D, takes about 2 seconds on my computer, excluding linking.
Re: Had another 48hr game jam this weekend...
On 18 September 2013 17:15, Adam D. Ruppe destructiona...@gmail.com wrote: On Wednesday, 18 September 2013 at 16:09:46 UTC, Manu wrote: rdmd implies rebuild-all every time. It doesn't really scale. Have you actually tried it? My biggest D program is coming up on 100,000 lines of code, plus phobos, and I still compile it all at once, every time. The compile time is ~15 seconds, slower than I'd like (due to ctfe more than anything else) but not bad. Compiling all of phobos at once, 100,000 lines of D, takes about 2 seconds on my computer, excluding linking. Takes about 30-40 seconds with gdc. ;-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Opaque handles...
On 9/18/13, Manu turkey...@gmail.com wrote: But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do I handle destruction/garbage collection? Ah I see, well you could try using RefCounted from std.typecons. For some usage examples you may want to look at how CairoD uses it. It exposes D classes and some D structs in the D API which use reference counting: https://github.com/jpf91/cairoD Johannes also did a nice job documenting how memory management is dealt with for interfacing with cairo, so this page might be helpful: https://github.com/jpf91/cairoD/wiki/Memory-Management
Code::Blocks
Has anyone been using Code::Blocks for D programming recently. The page http://wiki.dlang.org/CodeBlocks seems seriously out of date and could do with an update. Is a plugin needed for using Code::Blocks for D? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Opaque handles...
On 9/18/13, Manu turkey...@gmail.com wrote:
And in D:
struct Thing;
extern (C) Thing* MakeThing();
The question is, does this suck?
D currently can't allocate an array of Thing*'s for some weird reason.
This is just a current bug that will be fixed. As a workaround you can use this:
struct Thing
{
@disable this();
@disable this(this);
}
This will ensure Thing will never be copied by value, and you can
only use it with a pointer.
Re: [OT] Language Cocktail
On 18 September 2013 23:53, Chris wend...@tcd.ie wrote: On Wednesday, 18 September 2013 at 08:38:05 UTC, Namespace wrote: http://consoleblog.me/posts/**cocktails-for-programmershttp://consoleblog.me/posts/cocktails-for-programmers Any suggestions for D? D-programmers don't drink cocktails. They drink beer! Actually, judging by the efforts at dconf, I think it's safe to say D programmer don't really drink much at all! As a proud Australian, I wasn't too sure what to make of it ;)
Re: Qt Creator and D
On 9/18/13, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. Personally I've tried Qt Creator a few times a few years ago, and it had a doesn't work by default mode when I tried to use it with MinGW (compilation errors with their sample apps, because their makefiles seem to have been hardcoded for Visual Studio..). Really strange when it was a Qt distribution that contained MinGW to begin with. I'm gonna give it another go today to see if things have improved.
Re: Qt Creator and D
I'm also interested in this. I use Qt Creator all the time for my usual projects and my job, and having D support would be fantastic and would really help motivate me to spend more time with D. At some point I'd like to look into how to add new language support in there, if I can find some spare time. On Wednesday, 18 September 2013 at 14:49:27 UTC, Joseph Rushton Wakeling wrote: Hello all, Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. My general impression is that this is a fast, light cross-platform IDE which is (as its name indicates) state-of-the-art for C++ and Qt development. Currently it has fairly good D/Ddoc syntax highlighting (it literally copies the latest d.xml syntax definition file from KDE's text editor Kate). However, I wasn't able to get things like auto-indent working, and haven't yet put any serious effort into investigating build/compiler or debugging support. It also has a FakeVim mode that enables vim-like editing and should be able to operate from the local .vimrc settings, but my brief experiments weren't so far able to get it to reproduce my current vim behaviour. The last related discussion that I'm aware of is from about 3 years back, when several D users discussed implementing Qt Creator support: http://www.digitalmars.com/d/archives/digitalmars/D/ide/Qt_Creator_with_D_707.html ... but I'm not aware of any follow-up since then. I'm just wondering how many people would be interested in seeing better D support in this IDE, and how many people have more experience or can offer insight into how to proceed. Best wishes, -- Joe
Opaque handles...
I've seen some discussions before about people dealing with opaque
pointers, or handle types in D.
It's a common C practise, and there seems to be uncertainty about the best
way to implement this on the D side of the fence.
So I'm looking for opinions... hit me?
I have this in C:
struct Thing;
Thing* MakeThing();
And in D:
struct Thing;
extern (C) Thing* MakeThing();
The question is, does this suck?
D currently can't allocate an array of Thing*'s for some weird reason.
Are there any concerns relating to the GC that I should be aware of when
handling pointers returned to me from C code?
So a further goal, and maybe I'll add a little back-story; my 30th birthday
game jam from a few weeks back (which is still an active thread!) was
interfacing with my engine using basically an extern(C) API precisely
mirroring the C headers.
I'm planning on joining another game jam in a couple of week, using D again
(maybe I can start another thread as long and controversial as the last
one!) ;)
But this time, I want to spend some preparation time building a much more
D-styled API to interact with. Again, I'm struggling with just how I should
wrap the C calls and opaque types up.
What do people feel is conventional, and has proven to work well?
Again, wrt the opaque pointer problem. I don't really feel using an opaque
pointer on the D side is really right.
What I really want to use is something that feels more like a class
reference, and I toyed with the idea of abusing class references to hold my
handles, and methods would internally case 'this' to my handle type before
passing it back into the C code it wraps up.
This seems okay at first, but then you realise there are serious problems
with new (wants to return new memory, I can't hook the new operator?), and
there's no way to free it automatically, since D is garbage collected
rather than ref counted _
(Note: I'm still fairly certain that I want a ref-counting GC in D)
So... should I make it a struct with a single void* member?
struct MyThing { void* handle; }
I kinda hate this. the struct keyword totally gives the user the wrong
impression, and people have a natural instinct to avoid passing structs
around by value, which is exactly how these objects should be handled...
So if I can't present it as a class, and a struct is a pretty shit
solution... what?
My objects are opaque handles to engine-managed resources. They are
ref-counted, and there is extern(C) API to add/release references to stuff,
which I would rather have automated in the D code...
One final problem with ref-counting in D. Since it's not a 1st class
feature and requires you to store a ref-count in your object, you can't
make your objects immutable anymore because the ref-count needs to be
bumped about as the object moves around. Anyone approached this problem?
Re: [OT] Language Cocktail
On Wed, 18 Sep 2013 16:42:55 +0200 Chris wend...@tcd.ie wrote: On Wednesday, 18 September 2013 at 14:35:59 UTC, Namespace wrote: On Wednesday, 18 September 2013 at 14:31:48 UTC, Chris wrote: On Wednesday, 18 September 2013 at 13:55:11 UTC, Namespace wrote: American beer or real beer? I said beer. This should answer your question. Right answer. Are you German? In fairness, there is some really good stuff being brewed in the U.S. Sierra Nevada for example (http://www.sierranevada.com/), and there are some nice micro-breweries that produce quality stuff that is as good as any of the better German, British, Irish or Belgian beers/ales. Or Yuengling. Mainly German-style (although apparently Yuengling does use corn?), by a German immigrant and his descendants, made in Pennsylvania and Florida. Roughly the price of Budweiser Shitty Corn Beer, but actually worth drinking. There's certainly better bier out there, but not at that price point. Can only get it in a few states though, but luckily Ohio here was added a couple years ago :) Personally though, I'm more rum or sake than beer. (And that's sah-kay, not sah-kee.)
Re: Had another 48hr game jam this weekend...
On 19 September 2013 01:46, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/18/13 8:44 AM, Manu wrote: On 19 September 2013 01:04, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:SeeWebsiteForEmail@**erdani.orgseewebsiteforem...@erdani.org wrote: On 9/18/13 6:54 AM, Wyatt wrote: On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in only rebuild the files that changed? In my experience, that comes with using make. Even really ancient versions. Plus rdmd --make-depend, yum. I actually only just realised how cool rdmd was last weekend. Never occurred to me really to use it before. Very handy! yay 2 dat Problem is, 80% of the code I write is C code still... :( join me You never know... it could happen.
Re: Had another 48hr game jam this weekend...
On 19 September 2013 02:05, Andrej Mitrovic andrej.mitrov...@gmail.comwrote: On 9/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Problem is, 80% of the code I write is C code still... :( join me I don't suppose GCC and other compilers have some kind of verbose output that exports include declarations? Or maybe just modify an RDMD fork to run the preprocessor over a C/C++ file. What I'm saying is, I think a tool like RDMD could be used for C/C++ (with some trickery). rdmd implies rebuild-all every time. It doesn't really scale. If you have a few hundred thousand LOC, its probably not the man for the job.
Re: Had another 48hr game jam this weekend...
On 9/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Problem is, 80% of the code I write is C code still... :( join me I don't suppose GCC and other compilers have some kind of verbose output that exports include declarations? Or maybe just modify an RDMD fork to run the preprocessor over a C/C++ file. What I'm saying is, I think a tool like RDMD could be used for C/C++ (with some trickery).
Re: Opaque handles...
Here's an example of a typical C API that's begging to be wrapped up all
nice:
http://fujiengine.org/docs/group___m_f_material.html
And it's counterpart:
https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d
You can see some initial experiments I toyed with down the bottom. Abusing
the class syntax, and implementing a range interface for the material
parameters, but this sucks in a variety of ways...
On 19 September 2013 02:19, Manu turkey...@gmail.com wrote:
On 19 September 2013 02:14, Andrej Mitrovic andrej.mitrov...@gmail.comwrote:
On 9/18/13, Manu turkey...@gmail.com wrote:
And in D:
struct Thing;
extern (C) Thing* MakeThing();
The question is, does this suck?
D currently can't allocate an array of Thing*'s for some weird reason.
This is just a current bug that will be fixed. As a workaround you can
use this:
struct Thing
{
@disable this();
@disable this(this);
}
This will ensure Thing will never be copied by value, and you can
only use it with a pointer.
But since I'm always dealing with a pointer rather than a real type, I
can't implement logic to inc/dec the ref-count on assignment. And how do I
handle destruction/garbage collection?
Re: Opaque handles...
One final problem with ref-counting in D. Since it's not a 1st class feature and requires you to store a ref-count in your object, you can't make your objects immutable anymore because the ref-count needs to be bumped about as the object moves around. Anyone approached this problem? I use a shared_ptr (especially if I deal with C memory).
Re: Qt Creator and D
On Wednesday, 18 September 2013 at 15:58:43 UTC, Andrej Mitrovic wrote: On 9/18/13, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. Personally I've tried Qt Creator a few times a few years ago, and it had a doesn't work by default mode when I tried to use it with MinGW (compilation errors with their sample apps, because their makefiles seem to have been hardcoded for Visual Studio..). Really strange when it was a Qt distribution that contained MinGW to begin with. I'm gonna give it another go today to see if things have improved. I had some similar experiences with Qt Creator and MinGW on Windows a couple of years ago. Can't remember how I ended up solving them, but I recall that I managed to get things working somehow.
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 16:05:18 UTC, Andrej Mitrovic wrote: On 9/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Problem is, 80% of the code I write is C code still... :( join me I don't suppose GCC and other compilers have some kind of verbose output that exports include declarations? Or maybe just modify an RDMD fork to run the preprocessor over a C/C++ file. What I'm saying is, I think a tool like RDMD could be used for C/C++ (with some trickery). You can get this information from gcc and use it to define 100% correct dependencies. However, it highlights another issue common for build tools not coupled with compiler - to generate dependency graph reliably you need now to parse all the source files which contradicts one of core motivations to do it. The way C preprocessor works does not help the matter either.
Re: Qt Creator and D
On 9/18/13, Craig Dillabaugh cdill...@cg.scs.carleton.ca wrote: I had some similar experiences with Qt Creator and MinGW on Windows a couple of years ago. Can't remember how I ended up solving them, but I recall that I managed to get things working somehow. It seems to be much better now, the samples build by default. Although they're still hardcoding some visual settings that you can't override (like the caret). Oh well..
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 16:22:27 UTC, Iain Buclaw wrote: Takes about 30-40 seconds with gdc. ;-) Yikes. Though that reminds me of something, I don't use dmd -O very often, which is horribly slow too. I guess in game dev, even when debugging/toying around, you'd probably want to optimize so maybe that is a problem.
Re: Opaque handles...
On 9/18/13, Manu turkey...@gmail.com wrote: And it's counterpart: https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d I think those pointers in the MFMaterialCallbacks struct should likely be marked extern(C).
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 15:43:21 UTC, Manu wrote: I've had lots of problems in the past where a header included by another header doesn't prompt the dependent code to be rebuilt, and I ended up in a conservative state of rebuild-all-ing every time... :/ Maybe I should try working with that environment more... This is what makes tup so interesting to me. It tracks every file that is read in during a compile so it knows what to recompile when a particular header changes.
Re: Code::Blocks
On 9/18/13, Russel Winder rus...@winder.org.uk wrote: Has anyone been using Code::Blocks for D programming recently. The page http://wiki.dlang.org/CodeBlocks seems seriously out of date and could do with an update. This is actually the only IDE I've ever really liked back when I experimented with C++. Maybe it's because it has a Scintilla editor, but also because it's very lightweight. That wiki page could definitely use an update. So you say it works with D automatically nowadays? Is this using the 12.x release or some nightly build?
Re: Code::Blocks
On Wed, 2013-09-18 at 17:24 +0100, Russel Winder wrote: Has anyone been using Code::Blocks for D programming recently. The page http://wiki.dlang.org/CodeBlocks seems seriously out of date and could do with an update. Is a plugin needed for using Code::Blocks for D? Belay that question, Code::Blocks has done the right thing and found all the D compilers I have all by itself. Crickey, I am close to being impressed. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Qt Creator and D
On 18/09/13 18:02, Mike Farnsworth wrote: I'm also interested in this. I use Qt Creator all the time for my usual projects and my job, and having D support would be fantastic and would really help motivate me to spend more time with D. At some point I'd like to look into how to add new language support in there, if I can find some spare time. It would be great if you could follow up on this. I have been reading around where I can and also asked for advice on the Qt Forums, but so far no responses. I'll continue to research what needs to be done, but you may get better mileage than me as you obviously know Qt Creator better than I do!
Re: Qt Creator and D
On 18/09/13 17:21, Henning Pohl wrote: It's the best IDE for C++ development I have encountered so far. And it's the only drawback of DMD making the change to D: I cannot use it to fix bugs anymore. All the more reason for us to make sure that it works with D too, I'd say :-)
Re: Opaque handles...
On 19 September 2013 02:38, Andrej Mitrovic andrej.mitrov...@gmail.comwrote: On 9/18/13, Manu turkey...@gmail.com wrote: And it's counterpart: https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d I think those pointers in the MFMaterialCallbacks struct should likely be marked extern(C). Good catch! ;) But ideally I intend to wrap this all up, and present something that's actually kinda nice. There's a few angles of attack though.
Re: Qt Creator and D
On Wednesday, 18 September 2013 at 16:02:04 UTC, Mike Farnsworth wrote: I'm also interested in this. I use Qt Creator all the time for my usual projects and my job, and having D support would be fantastic and would really help motivate me to spend more time with D. At some point I'd like to look into how to add new language support in there, if I can find some spare time. May be an interesting use case to check DCD applicability for full-blown IDE.
Re: Qt Creator and D
Am 18.09.2013 18:46, schrieb Joseph Rushton Wakeling: On 18/09/13 18:02, Mike Farnsworth wrote: I'm also interested in this. I use Qt Creator all the time for my usual projects and my job, and having D support would be fantastic and would really help motivate me to spend more time with D. At some point I'd like to look into how to add new language support in there, if I can find some spare time. It would be great if you could follow up on this. I have been reading around where I can and also asked for advice on the Qt Forums, but so far no responses. I'll continue to research what needs to be done, but you may get better mileage than me as you obviously know Qt Creator better than I do! For starters, Qt creator can make use of Kate configuration files. So we could at very least have D syntax highlighting available. -- Paulo
Re: Opaque handles...
On Wednesday, 18 September 2013 at 16:05:00 UTC, Manu wrote:
This seems okay at first, but then you realise there are
serious problems with new (wants to return new memory, I can't
hook the new operator?),
There is an override for new, but it is deprecated in d2.
http://dlang.org/memory.html#newdelete
I kinda hate this. the struct keyword totally gives the user
the wrong impression, and people have a natural instinct to
avoid passing structs around by value
...just don't do that? You don't write ref Class obj in D, so
just pretend the struct is a class and do it the same way.
The only time you'd even need to know it is a struct is if you
look at the source, and there you can write
struct /* but pretend it is a class! */ whatever {
}
Here's how I might do it. Given this simple C test header:
struct Test;
struct Test* makeTest(int num);
void addTestRef(struct Test* t);
void killTest(struct Test* t); // i should have called that
releaseref lol
int getNumber(struct Test* t);
void setNumber(struct Test* t, int n);
We might use it in D like this:
// this represents the struct Test in C, our opaque pointer
// (the disabled stuff is to workaround a minor dmd bug)
struct c_Test {
@disable this();
@disable this(this);
}
// and this is our D wrapper
// always pass this by value
struct Test {
// the internal reference
private c_Test* c_ptr;
// construction can only be done publicly through the static
make method
@disable this();
private this(c_Test* ptr) {
c_ptr = ptr;
}
public static Test make(int num) {
return Test(makeTest(num));
}
// the alias this lets us call the rest of the binded C
functions with UFCS without manually writing wrappers
c_Test* getCPointer() { return c_ptr; } // it does a property so
you can't assign to the internal pointer
// you CAN break the refcounting with this, but since you have
to specifically ask for the uglier c_Test* to trigger
// this, it is unlikely to happen by accident.
alias getCPointer this;
// refcount stuff
~this() {
c_ptr.killTest();
}
this(this) {
c_ptr.addTestRef();
}
}
// you might notice the above is pretty generic, perhaps it could
all be a single template so you don't rewrite it for too many
types.
// and the C function prototypes
extern(C) {
c_Test* makeTest(int num);
void addTestRef(c_Test* t);
void killTest(c_Test* t);
int getNumber(c_Test* t);
void setNumber(c_Test* t, int n);
}
// test program
import core.stdc.stdio;
void foo(Test t) {
printf(foo on %d\n, t.getNumber());
t.setNumber(20);
}
void main() {
auto t = Test.make(12);
auto t2 = Test.make(24);
printf(about to call foo\n);
foo(t);
printf(done calling foo\n);
printf(main with t == %d\n, t.getNumber());
printf(main with t2 == %d\n, t2.getNumber());
}
You don't have my c implementation but it isn't special and
running the program produced the following output:
Test made with number 12
Test made with number 24
about to call foo
aref refcount now 2 on Test 12 # refcount increased properly for
the function call
foo on 12
dtor refcount now 1 on Test 20 # and properly decreased when
ending
done calling foo
main with t == 20 # setting the number in foo() correctly did it
by reference
main with t2 == 24
dtor refcount now 0 on Test 24 # and main is dead, so we release
the ref automatically
Test killed with number 24 # refcount == 0, so C free()'d it
dtor refcount now 0 on Test 20
Test killed with number 20
Using UFCS for the C functions might be a little bit weird, but
saves tediously writing them all out again to forward inside the
struct.
Re: [OT] Language Cocktail
On 2013-09-18 16:42, Chris wrote: In fairness, there is some really good stuff being brewed in the U.S. Sierra Nevada for example (http://www.sierranevada.com/), and there are some nice micro-breweries that produce quality stuff that is as good as any of the better German, British, Irish or Belgian beers/ales. Samuel Adams, Brooklyn, Flying Dog to mention a few more. -- /Jacob Carlborg
Re: Had another 48hr game jam this weekend...
On Wed, Sep 18, 2013 at 06:36:19PM +0200, David Eagen wrote: On Wednesday, 18 September 2013 at 15:43:21 UTC, Manu wrote: I've had lots of problems in the past where a header included by another header doesn't prompt the dependent code to be rebuilt, and I ended up in a conservative state of rebuild-all-ing every time... :/ Maybe I should try working with that environment more... This is what makes tup so interesting to me. It tracks every file that is read in during a compile so it knows what to recompile when a particular header changes. +1. Anyone who's ever had to 'make clean; make' just to make sure everything was up-to-date seriously should ditch make and use a real build system like tup. SCons is also pretty good, though algorithm-wise, tup is probably better. T -- Just because you can, doesn't mean you should.
