Re: Linkage runaround
On Thursday, 26 March 2015 at 13:17:04 UTC, Steven Schveighoffer wrote: On 3/26/15 8:37 AM, Steve Teale wrote: If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo .../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone. It looks like you are missing a required library. Are you linking with ld? If so, make sure you run dmd with -v to see the link line it uses. Telling the linker to use the dynamic linking so - on Ubuntu, that appears to be /lib/i386-linux-gnu/ld-linux.so.2 - makes no difference. -Steve
Linkage runaround
If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo ../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone.
Re: Trying to build my app with DMD2.66 and GtkD 2.4.2
On Sunday, 15 March 2015 at 12:57:42 UTC, Rikki Cattermole wrote: On 16/03/2015 1:49 a.m., Steve Teale wrote: On Sunday, 15 March 2015 at 12:32:31 UTC, Rikki Cattermole wrote: On 16/03/2015 1:28 a.m., Steve Teale wrote: I'm trying to build my app after upgrading to DMD2.66 and the latest GtkD. I get a slew of unsatisfied references, all of which seem to feature '_D3gtk6Widget6Widget10__mixin469.' I just built gtkd 2.4.2, and am linking against a libgtkd-2.a in /usr/local/lib with today's date. Any ideas? It sounds like a old binaries are being used. Assuming dub is being used. Senility! I had installed 2.66, and then recompiled my app. Then I rebuilt the library, and the makefile tried to link it, since it had been compiled later than any changes. Duh! Don't mix programming and plumbing. used, add --force. Nope, was having trouble with dub, so I retreated to GNU make. That should use the file I tell it, right? Urgh, I'll say yes? I don't really use make nor can see your makefile/environment.
Re: Trying to build my app with DMD2.66 and GtkD 2.4.2
On Sunday, 15 March 2015 at 12:32:31 UTC, Rikki Cattermole wrote: On 16/03/2015 1:28 a.m., Steve Teale wrote: I'm trying to build my app after upgrading to DMD2.66 and the latest GtkD. I get a slew of unsatisfied references, all of which seem to feature '_D3gtk6Widget6Widget10__mixin469.' I just built gtkd 2.4.2, and am linking against a libgtkd-2.a in /usr/local/lib with today's date. Any ideas? It sounds like a old binaries are being used. Assuming dub is being used, add --force. Nope, was having trouble with dub, so I retreated to GNU make. That should use the file I tell it, right?
Trying to build my app with DMD2.66 and GtkD 2.4.2
I'm trying to build my app after upgrading to DMD2.66 and the latest GtkD. I get a slew of unsatisfied references, all of which seem to feature '_D3gtk6Widget6Widget10__mixin469.' I just built gtkd 2.4.2, and am linking against a libgtkd-2.a in /usr/local/lib with today's date. Any ideas?
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 17:16:40 UTC, Walter Bright wrote: On 4/23/2014 2:00 AM, Dmitry Olshansky wrote: If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong. I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so. The thing is, I work all day every day on D. I cannot do more. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in. Well said Walter!
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote: Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator. But on the right hand side, it simply is a [] operator, not tied to the =. I erroneously thought the arr[] = ... syntax was special for arrays, but I forgot that it's simply another operator. Steve, where do I find the []= operator in the documentation? It does not seem to be under Expressions like the other operators. Has it just not got there yet? Steve
Re: mysql-native: newbie questions
On Tuesday, 8 April 2014 at 22:06:51 UTC, Nick Sabalausky wrote: On 4/8/2014 11:49 AM, Steve Teale wrote: On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote: Those who want something completely different are most welcome to use our stuff and do it themselves. Deal? Is there some specific disagreement this is referring to, or just a general "proposed ground rules" statement? Ground rules-but rules are meant to be broken ;=) Steve
Re: mysql-native: newbie questions
On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote: On 04/08/2014 04:00 PM, Steve Teale wrote: On Tuesday, 8 April 2014 at 07:58:58 UTC, simendsjo wrote: On a more specific topic, Nick S mentioned purging of result sets. I have a mixed view of this. One half of me says "if you cant present a SQL query that selects what you want, then put up with the inefficiency of waiting for the thread to read through all the stuff until it finds an EOF". The other half wonders if there should be a connection pool, and then situations like that could just switch to a new connection, and leave the existing one at lower priority to clean up the garbage. But the latter is not systems programming approach. Writing that down cleared my mind. The level we should aim at should I think be just what is needed to exploit the capabilities of the MySQL/MariaDB protocol version. The protocol is what it is, and is unfriendly toward sloppy SQL. Steve
Re: mysql-native: newbie questions
On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote: I think most of what's needed for stored procedures is implemented. OK, can you give me a brief run-down on the changes you would like to see/are working on. Then we can get together and agree on an outcome that makes the best of both our points of view. I am not inflexible. When I dropped out it was because there was just no consensus. Now, I don't give a **ck if there's consensus or not. The main thing is 1) does it work, ans 2) does it provide what D programmers might expect in the context of the language features and Phobos custom and practice. Those who want something completely different are most welcome to use our stuff and do it themselves. Deal? Steve
Re: mysql-native: newbie questions
On Tuesday, 8 April 2014 at 07:58:58 UTC, simendsjo wrote: On 04/08/2014 09:52 AM, Nick Sabalausky wrote: On 4/8/2014 2:51 AM, simendsjo wrote: What comes to mind is * Stored Procedures * Purging results (cancelling queries) * Sending and receiving large blobs The original did all of these, and user-defined functions. At the time MySQL did not support strored procedures that returned a result set. Maybe it does not but I have not investigated that yet. Steve
Re: mysql-native: newbie questions
On Monday, 17 February 2014 at 22:54:58 UTC, salvari wrote: Hi all! After 14 years using Perl for programming at job I'm now learning D. (And enjoying it) We've been using Perl (at job) for years for loading input data (UTF files) into a database and using these data for different purposes. The volume of input data files has been constantly increasing along the years and, eventually, we need a faster solution, that's the reason to switch back to compiled languages, and D seemed interesting enough to give it a try. :-) As a newbie I've a few questions. I'm already using D and it's working fine, although I'm writing baby-D the performance improvement is impressive, I'm now trying to use mysql native access. It seems there are two possibilities: - https://github.com/simendsjo/mysqln - https://github.com/rejectedsoftware/mysql-native Quite by accident/coincidence, I recently returned to my mysqln effort to see if it would still build with the latest dmd. I had also reinstalled MySQL recently so it was a different version, and that resulted in a few tweaks to the unit tests. However, other than that, I had no great problem. I then set about trying to minimize memory allocations, and hopefully get the thing to be a bit more speedy. I think I have made some improvements there. Now I realize that the code is pretty impenetrable. It's dealing with a protocol that is really very basic, badly documented, and consists of streams of ubytes minimized as much as possible, probably by disparate authors. You don't know what the next byte might represent until you've looked at the current one in context, so that makes it as bad a candidate for an input range as UTF8, or worse. However, on a return visit, I'm not inclined to change my mind about the higher level interactions. I think the ability to read a specific table row into a tuple of D types, or to populate a D struct is quite cool. Also result sets with multiple rows can constitute an input range, so the std.algorithm stuff should be fine for doing finer graded selection than that provided by the SQL query. If you want to do database stuff that avoids knowledge of how to use SQL, then I'd say it could be wrapped to provide that sort of thing - but then I always hated Visual Basic. If you give me a couple of weeks or less, I'll convert it into a tidy module that will build with dub, and then I will invite the D aficionados to tell me how I can improve the efficiency of the protocol handling, and the template stuff that I used. From previous experience, I'm fairly confident that I won't get any takers, so I'll just keep up with the newsgroup and do the best I can to keep up with idiomatic D usage, as long as it's not just to show how cleverly things can be done. I still quite like it, and if I had to seriously write something in D that needed MySQL, I would use it in preference to my earlier attempt at a wrapper around the C library. But thanks for the interest Steve.
Re: Cumulative
On Wednesday, 2 April 2014 at 14:23:57 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote: > Yes. This is "inner virtual functions" as opposed to "outer virtual functions" (C++). The successor to Simula, BETA (http://daimi.au.dk/~beta/), has this. Simula has this in the constructor of a class (which syntactically is the body), but BETA has the concept everywhere: somefunction:<(# statements1; inner; statements2; #) When you specialize a function/class the extra stuff you add is replacing the "inner" statement (and can provide it's own "inner"). I had gone some distance along that course. A virtual function to handle events examined the event to see if it could deal with it. If it could not, it called a 'specificHandler' virtual function. But that approach only works if you have a hierarchy of known depth, when specificHandler only gets called for the leaf classes. Later, I have had the constructors of derived classes add a handler delegate to a list of potential handlers maintained in the base class. The actual handler in the base class is a final method that simply iterates that list until some derived class handles the event, or throws if none do. But both of these approaches are clumsy compared to what I would like to see. It would help if D had 'direct' class methods (as opposed to final or virtual), as then I think it would be more straightforward to generate the delegate list. I'm pleased to see though that some other languages have noted this deficiency. Steve
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. As an alternative, python could be modified to make it more D like. Steve
Re: Should we deprecate comma?
On Tuesday, 25 March 2014 at 13:08:59 UTC, bearophile wrote: Steve Teale: I classify that as quite tricky code, it's a negative example :-( Bye, bearophile I was not recommending it, I was just trying to think of when I'd used comma, and that popped into my head. Basically I agree that it is likely to introduce errors (like mine in my example perhaps ;=), though in that case the compiler catches it.) I could certainly live without it Steve
Re: Should we deprecate comma?
On Tuesday, 25 March 2014 at 13:15:17 UTC, Timon Gehr wrote: On 03/25/2014 02:08 PM, bearophile wrote: Steve Teale: The only place I have tended to use the comma operator is in ternary expressions bool universal; atq = whatever? 0: universal = true, 42; I classify that as quite tricky code, it's a negative example :-( Bye, bearophile It's not tricky code. It is not even valid code. Operator precedence from lowest to highest: , = ?. Yes, I most likely used atq = whatever? 0: (universal = true, 42);
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 10:57:45 UTC, Regan Heath wrote:
On Sun, 23 Mar 2014 20:56:25 -, Andrei Alexandrescu
wrote:
Discuss:
https://github.com/D-Programming-Language/dmd/pull/3399
Would it have any effect on:
int *p, q;
R
I presume that
for (int i = 0, j = m;;) {}
Is in the same category?
The only place I have tended to use the comma operator is in
ternary expressions
bool universal;
atq = whatever? 0: universal = true, 42;
Re: Improve D's syntax to make it more python like
On Saturday, 22 March 2014 at 01:47:48 UTC, Andrei Alexandrescu wrote: On 3/21/14, 5:18 PM, w0rp wrote: A dozen people are doing the simple work and the complicated work, while the rest of the forum sits on the sidelines wringing hands about what to do about the future of D. Andrei, Is there a list of grunt jobs that need to be done? Steve
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 08:05:09 UTC, monarch_dodra wrote: On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote: Can someone tell me where this is written up? Thanks Steve You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a "as needed" basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as "dumb" as TypeTuple: => need std.typetuple => pulls traits => pulls typecons and algorithm => pulls array, string, uni, ascii, utf, conv => pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to "pollute" your namespace with imported symbols. OK, so what happens that's different when I pull in std.typetuple at the point where I need it? Does that avoid pulling in all the other stuff? How does this problem manifest itself - code bloat, or slower compilations, or what? Thanks Steve
New guideline to place import statements as locally as possible
Can someone tell me where this is written up? Thanks Steve
Re: Plugins and D programs
On Saturday, 15 March 2014 at 22:56:19 UTC, Martin Nowak wrote: On 03/15/2014 11:04 PM, Martin Nowak wrote: On 03/15/2014 09:50 PM, Martin Nowak wrote: I'm still investigating why it crashes when using --export-dynamic though. When you've fixed this, you should also be able to mark issue 10719 as fixed ;=)
Re: Plugins and D programs
On Saturday, 15 March 2014 at 22:56:19 UTC, Martin Nowak wrote: On 03/15/2014 11:04 PM, Martin Nowak wrote: On 03/15/2014 09:50 PM, Martin Nowak wrote: I'm still investigating why it crashes when using --export-dynamic though. Looks like a revenant of https://d.puremagic.com/issues/show_bug.cgi?id=9729. The problem is that nobody sets ebx before calling the interface thunk, therefor resolving the @PLT entry fails. _TMP5 LABEL NEAR sub eax, 8 ; 0078 _ 83. E8, 08 jmp _D6plugin6Plugin12saySomethingMFZAya; 007B _ E9, FFFC(PLT r) I prepared a fix here (https://github.com/MartinNowak/dmd/tree/thunkEBX) but it needs more work. Currently it violates the platform ABI because the interface thunk destroys EBX. Thanks Martin - it's good to have you involved. I'd got as far as dissasembling it and stepping single instructions in GDB while looking at that, so I could have told you where it crashed, but had no idea what was going on
Re: UFCS and delegates
On Saturday, 15 March 2014 at 11:02:08 UTC, Daniel Murphy wrote:
"Steve Teale" wrote in message
news:uhledfeisciwpvtvm...@forum.dlang.org...
Yes, I'm asking for the wrong thing. What I should have said
is that given UFCS, should there be an alternate way of
initializing a delegate, something along the lines of:
void delegate(int) dg = (a, &bar);
Well, if you know the instance, you can do this:
void delegate(int) dg = (int v) { a.bar(v); }
But this would have to go inside main.
This seems a long way around the houses, is difficult to
understand, and the result is a delegate with a frame pointer for
the main function, which then has a nested function
void anon(int v) { a.bar(v); }
which somehow does not feel right, and if the compiler isn't
clever, seems like another level of indirection.
Syntax like this (changed my mind ;=)) would be nice:
void delegate(int) dg = &a.bar;
I'm not particularly looking for a way of doing it at this
moment, just whether it's something that could be done in the
future.
Re: UFCS and delegates
On Saturday, 15 March 2014 at 09:51:53 UTC, Daniel Murphy wrote: Yes, that's what I was talking about. UFCS is and always has been a rewrite rule. Yes, I'm asking for the wrong thing. What I should have said is that given UFCS, should there be an alternate way of initializing a delegate, something along the lines of: void delegate(int) dg = (a, &bar); Steve
Re: UFCS and delegates
On Saturday, 15 March 2014 at 09:09:23 UTC, Daniel Murphy wrote: "Steve Teale" wrote in message news:dtevbsedsbbvqhaie...@forum.dlang.org... Doesn't the logic of UFCS rather suggest that this should compile? Nope, UFCS is a rewrite rule, it doesn't change function signatures. I was asking about the logic - as expounded in the discussions before its introduction, as opposed to the implementation rules adopted. Steve
Re: UFCS and delegates
On Saturday, 15 March 2014 at 09:13:47 UTC, Rikki Cattermole wrote: yours no. Because a delegate stores a context ptr aka this. As well as a function pointer. What you were doing meant that no content pointer was being stored. Essentially it was just a function pointer without the first argument added. Why isn't the first argument, removed in the rewrite, used as the context? In cases where the type of the first argument was not suitable, the compiler could issue an error message.
UFCS and delegates
Doesn't the logic of UFCS rather suggest that this should compile?
struct A
{
int m;
void foo(int n) { m += n; }
}
void bar(ref A a, int n)
{
a.foo(n*n);
}
void delegate(int) dg = &bar;
void main()
{
A a;
a.bar(3);
dg(3);
assert(a.m == 18);
}
Re: Plugins and D programs
On Friday, 14 March 2014 at 07:22:06 UTC, Mathias LANG wrote: On Thursday, 13 March 2014 at 13:22:55 UTC, Steve Teale wrote: Does anyone have any suggestions as to what might be going wrong here? I have further examples, but I guess I should do them one at a time. Steve Copied your files, added: -L-rpath=/home/geod/bin/dmd-master/linux/lib64/ as dmd is not on the system path for me. It was working. So try to update your compiler and check if that's the reason. Everything works OK with 64 bit anyway!
Re: Plugins and D programs
On Friday, 14 March 2014 at 09:08:17 UTC, Steve Teale wrote: I'll work up a minimal test case just using an interface, then submit it, yes? There's an equivalent in the system already - issue 10719, but that does not mention the fact that the problem is 32 bit specific. I updated it. Will install 2.065 and test with that.
Re: Plugins and D programs
On Friday, 14 March 2014 at 08:56:25 UTC, Steve Teale wrote: On Friday, 14 March 2014 at 08:15:00 UTC, Mathias LANG wrote: ./main plugin ctor I am plugin I am plugin I am plugin Same result with master branch. Long story short: I can't reproduce it on my machine (Debian x86_64). Which platform are you working on ? 32 bits ? Ubuntu 12.04 32 bit. I'll reboot into 64 bit and try there. Sure enough, works OK on 12.04 64 bit, so I guess it's a bug. Probably not core.runtime, because I think the problem still occurs if I use dlopen() directly, so code generation? I'll work up a minimal test case just using an interface, then submit it, yes? Steve
Re: Plugins and D programs
On Friday, 14 March 2014 at 08:15:00 UTC, Mathias LANG wrote: ./main plugin ctor I am plugin I am plugin I am plugin Same result with master branch. Long story short: I can't reproduce it on my machine (Debian x86_64). Which platform are you working on ? 32 bits ? Ubuntu 12.04 32 bit. I'll reboot into 64 bit and try there.
Re: Plugins and D programs
On Friday, 14 March 2014 at 06:54:34 UTC, Steve Teale wrote:
On Thursday, 13 March 2014 at 21:20:10 UTC, Tolga Cakiroglu
It is not just a shut-down artefact, since if I repeat the
exercise with an exemplar class instead of an interface, then
it will work.
OK, so here's an example using an exemplar base class instead of
an interface. This includes making the exemplar class implement
an interface.
Here's the exemplar class, and another class that references an
instance of it:
module bc;
import std.stdio;
interface I
{
string saySomething();
}
class Bc: I
{
string saySomething() { return null; };
}
class Other
{
I target;
this(I i) { target = i; }
void invokeWithCast() { writeln((cast(Bc)
target).saySomething()); }
void invoke() { writeln(target.saySomething()); }
}
Then the plugin:
module plugin;
import bc;
import std.stdio;
class Plugin: Bc
{
this() { writeln("plugin ctor"); }
override string saySomething() { return "I am plugin"; }
}
Bc getInstance()
{
return new Plugin();
}
And the program:
module main;
import core.runtime;
import std.stdio;
import bc;
extern(C) void* dlsym(void*, const char*);
alias Bc function() pfi;
Bc getPlugin(string name)
{
void* lib = Runtime.loadLibrary(name~".so");
void* vp = dlsym(lib, "_D6plugin11getInstanceFZC2bc2Bc\0".ptr);
pfi f = cast(pfi) vp;
Bc x = f();
return x;
}
void main()
{
Bc x = getPlugin("plugin");
writeln(x.saySomething());// OK
Other other = new Other(x);
other.invokeWithCast(); // OK
other.invoke(); // Crash
}
Built with:
main : bc.d main.d
dmd -c bc.d
dmd -c main.d
dmd main.o bc.o -L-L/usr/local/lib -L-ldl -L-lgtkd-2
-defaultlib=libphobos2.so -L-rpath=.
plugin : plugin.d
dmd -c -shared -fPIC plugin.d
dmd plugin.o -shared -defaultlib=libphobos2.so -map
clean :
rm *.o
rm main
rm plugin.so
Output:
steve@steve-desktop:~/scratch/pibc$ ./main
plugin ctor
I am plugin
I am plugin
Segmentation fault (core dumped)
If you comment out the last call via the interface instance with
no cast, the program exits cleanly. So the problem does seem to
relate to interfaces.
So you can do it, but if the base class conforms to some
interface, then you have to special-case calls to the interface
functions. That rather destroys the utility of classes like Other
which provide services to the installed plugin.
My gut-feeling question is "is the vtable in the program or the
plugin, and does this vary when the plugin implements an
interface?"
I'm hoping Martin Nowak might join in this discussion.
Steve
Re: Plugins and D programs
On Thursday, 13 March 2014 at 23:44:23 UTC, Sean Kelly wrote: It might be purely a matter of historic interest at this point, but DDL was basically doing plugins in D ages ago: http://www.dsource.org/projects/ddl I /think/ this was the dynamic loading scheme h3r3tic used in his game engine back in the day. I'm sure someone with a better memory than me could explain it better. Sean, Yes, been there years ago - maybe 2006. I could never get the full edifice working, so I extracted the parts that would enable me to just load a single .o file, and that would work most of the time, but then sometimes it would just crash. Maybe that would work with today's runtime, but the machine that particular code was on got stolen, so I'd have to start from scratch. Steve
Re: Plugins and D programs
On Thursday, 13 March 2014 at 21:20:10 UTC, Tolga Cakiroglu wrote: dmd main.o ifd.o -L-ldl -defaultlib=libphobos2.so -L-rpath=. Hmm. I saw that you are using libphobos2.so. I wasn't using this. Yes, you have to make the program and the plugin both use the same runtime, presumably so they are using the same memory allocation system, so you link both with libphobos2.so. It is not just a shut-down artefact, since if I repeat the exercise with an exemplar class instead of an interface, then it will work. But then if I make the exemplar class an instance of an interface, and call one of the methods that is part of the interface it goes back to crashing, so it does seem that this behaviour is linked to interfaces. I will get stuck in with GDB and see if I can find out more, but that's not an agreeable experience, so I thought I would ask first. Steve
Re: Final by default?
On Thursday, 13 March 2014 at 18:03:42 UTC, Andrej Mitrovic wrote: On 3/13/14, Andrei Alexandrescu wrote: There must be a way to convey that a decision has been made. It is understood it won't please everybody, just like going the other way won't please everybody. Please let me know what that way is. Voting. I recall someone telling me already that this is not a democracy. Even if we had it I think some sane person would have to make a choice on a 51/49 decision to change something. It would have to be 75% or whatever. Who is to write the constitution? Steve
Re: Broken?
On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu wrote: On 3/11/14, 11:36 PM, Steve Teale wrote: On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote: I'd like to point out that Walter and Andrei can't do it all themselves. It takes a team and part of pulling it off is well defined goals and job descriptions with devoted people. This is one of the motivations for my remark. They both have probably more than enough to do without having to wade through the tremendous volume of responses. Walter is a very nice man. He dislikes saying "no" to people on account of them getting mad at him or the language. So he'd rather not answer. Walter is a complex and proud man, like most of us. I love him dearly - he (along with John Haggins - who you maybe never heard of), changed my life. I'm getting old now, so the old adage "if it ain't broken, don't mend it" becomes very appealing. Except, of course for 'direct' ;=) I think, looking at the current arguments, that C++ may have got it right there. And, since it wasn't there before, can it break anything? Steve Steve
Re: Broken?
On Wednesday, 12 March 2014 at 23:53:52 UTC, Walter Bright wrote: I rely on the fresh blood of unborn kittens. I must try it. Sadly our youngest cat has disappeared over about 4 days now, and we're feeling worried.
Re: dlang.sexy
On Thursday, 13 March 2014 at 13:33:26 UTC, Nick Sabalausky wrote: On 3/13/2014 8:28 AM, Steven Schveighoffer wrote: Speaking of which, there is also the new top-level domain .sucks. We should snatch up cpp.sucks and golang.sucks, and dlang.sucks should redirect to cpp.sucks ;) I want 'myvacuum.sucks' Oh, yours too?!!
Plugins and D programs
One of the primary uses of dynamic loading of libraries might
well be to provide plugins. By plugins I mean extensions to an
existing program that can be added to the program at run-time,
and can be written by separate authors who don't necessarily have
access to the source code of the program, but who do understand
the rules provided by the program documentation as to what
capabilities the plugin must have.
The most obvious way to allow a D program to cope with plugins,
is to specify an interface to which the plugin is expected to
conform. Communication between the program and the plugin, after
the latter is loaded would then be restricted to calls provided
by that interface.
One further library method would likely be necessary to allow for
the acquisition of an instance of the plugin, and its attachment
to the program.
So, we could have
module ifd;
interface I
{
string saySomething();
}
The plugin could then be:
module plugin;
import ifd;
import std.stdio;
class Plugin: I
{
this() { writeln("plugin ctor"); }
string saySomething() { return "I am plugin"; }
}
I getInstance()
{
return new Plugin();
}
And our program could be:
module main;
import core.runtime;
import std.stdio;
import ifd;
extern(C) void* dlsym(void*, const char*);
extern(C) void* dlopen(const char*, int);
alias I function() pfi;
I getPlugin(string name)
{
// Take your pick from these two - makes no odds
//void* lib = dlopen("plugin.so\0".ptr, 1);
void* lib = Runtime.loadLibrary(name~".so");
if (lib is null)
{
writeln("failed to load plugin shared object");
return null;
}
void* vp = dlsym(lib, "_D6plugin11getInstanceFZC3ifd1I\0".ptr);
if (vp is null)
{
writeln("plugin creator function not found");
return null;
}
pfi f = cast(pfi) vp;
I x = f();
if (x is null)
{
writeln("creation of plugin failed");
return null;
}
return x;
}
void main()
{
I x = getPlugin("plugin");
writeln(x.saySomething());
}
Unfortunately, the result of running the program is:
steve@steve-desktop:~/scratch/piif$ ./main
plugin ctor
Segmentation fault (core dumped)
Which suggests that the library was loaded, the symbol found, and
an instance of plugin created.
The two pieces were built using dmd2.064 with:
main : ifd.d main.d
dmd -c ifd.d
dmd -c main.d
dmd main.o ifd.o -L-ldl -defaultlib=libphobos2.so -L-rpath=.
plugin : plugin.d
dmd -c -shared -fPIC plugin.d
dmd plugin.o -shared -defaultlib=libphobos2.so -map
clean :
rm *.o
rm main
rm plugin.so
Does anyone have any suggestions as to what might be going wrong
here? I have further examples, but I guess I should do them one
at a time.
Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 19:05:40 UTC, Iain Buclaw wrote: My GDB work is yet to be fully released into the wild, but it's looking as a good solid base from where I'm testing. You're a hero Iain. Steve
Re: dlang.sexy
On Wednesday, 12 March 2014 at 11:08:38 UTC, Iain Buclaw wrote: I came across this for EMACS. http://emacs.sexy/ Which got me thinking, now we have a new .sexy domain available for the public, who wants to go out and buy dlang.sexy (and talk about how sexy D is :) Andrei, I'm looking at you. Regards, Iain. A couple of posts back from this, there's one called "anyMembersatisfies' - we could use that as a logo ;=) Steve
Re: Broken?
On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote: when you do it in a separate module, an error? What if you want to define that function name, but it's taken by the base class, what happens? -Steve That's when you need 'direct' ;=) Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 14:28:02 UTC, Steven Schveighoffer wrote: > I saw that, but I think what you encountered was a bug in the compiler or differently-generated vtables. I think you should focus on trying to identify and fix the bug rather than trying to exploit a workaround. One thing to try is re-compiling all your code. Any changes in vtables will mess up the linkage. If the compiler thinks your function to call is in index 2 in one compilation, but it's in index 3 in another, bad things will happen :) Steve, Recompilation has been frequent, and the makefile for the plugin refers to the sources for the app, and is otherwise just a single source file, so I don't think it is that. My primary suspicion is that I am linking both the plugin and the app using the static gtkd-2 library. I believe the next step is to link both against a shared library version of gtkd-2. So far, I've had no success in building that. If the library code has static module constructors/destructors, or some such alternative down at the GTK+3 OOP C level, that uses a distinct text or data segment or something, then I can understand that I might well be hosed. It's also noteworthy that I can't use an interface as a 'base class' for the plugin, even though the system should work with quite a limited set of methods. That works to the extent that methods that don't access data work OK, but if they do, the edifice comes tumbling down. I'll have to brush up my command-line GDB skills to get much further - something I'm not looking forward to. Last time I did it was pre Iain Bucklaw when I was trying to sort out crashes in GDC. The ability to dynamically load D shared libraries into a D program is something that's been way up my wish list since about 2006. Seems like there's some way to go yet. Even further for Windows, where we probably need a new linker! At present, the app seems to be working pretty well with a plugin, as I have special cased the calls to host.onCSNotify() etc to apply the cast when the target is my main base class. Other uses will generally be entirely local to a plugin. So it might just stay like that for a while until I break it again. Thanks Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:34:33 UTC, Steve Teale wrote:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and then
the cast should cause a call to A or B.
Aargh - not final void foo() and final void bar(), just void
foo() in each case - a virtual function not mentioned by the
interface.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:12:20 UTC, Steven Schveighoffer
wrote:
On Wed, 12 Mar 2014 09:05:05 -0400, Steve Teale
wrote:
How is the compiler to build it's one copy of bad? Should x be
typed as A or B? Or something not even seen in this module that
could derive from I?
-Steve
Let's take bad() away, and instead:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and then
the cast should cause a call to A or B.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:45:30 UTC, Steven Schveighoffer wrote: What is typeof(x)? It needs to be decided at compile time. -Steve OK, squirm, squirm - I misunderstood the examples for typeof. Will you take a look at my last post on d.learn please. What I describe there is the motivation for my squirming. Can you suggest a compile-time way of telling ControlSet what class it is targeting at the point where an instance of it is declared? Sorry Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 11:56:43 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 06:57:08 -0400, Steve Teale wrote: What you want simply isn't possible. An interface binds at runtime, and you need to declare types at compile-time. You can't use an interface method to define the type of y. -Steve Steve OK, it was a bad illustrative example, but (cast(typeof(a.myType()) whatever).foo(); could be useful, when foo() is not in the interface. It was the failure of auto in an interface that I was remarking on - should at least be documented. Also the covariant return values as suggested by md don't work either. Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 11:13:00 UTC, monarch_dodra wrote:
That said, I'd expect this to work:
//
interface I
{
I myType();
}
class A: I
{
//auto myType() { return cast(A) null; } //Nope
A myType() { return cast(A) null; } //OK
}
//
Yup, covariance desired, but
import std.stdio;
interface I
{
I myType();
}
class A: I
{
A myType() { return cast(A) null; }
void foo() { writeln("foo"); }
}
void main()
{
I a = new A();
writeln(typeof(a.myType()).stringof);
}
returns I
Seems like a bug to me.
Steve
Restriction on interface function types
interface I
{
auto myType();
}
class A: I
{
auto myType() { return cast(A) null; }
}
void main()
{
I x = getSomeI();
typeof(x.myType()) y;
}
Re: Broken?
On Tuesday, 11 March 2014 at 20:43:07 UTC, Walter Bright wrote: On 3/11/2014 10:47 AM, Steve Teale wrote: What D needs at this point is a dictator. http://www.youtube.com/watch?v=poDaTeyqIm4 Ace Walter - how do you find the time? I believe that you are becoming truly benevolent as you grow older ;=)
Re: Broken?
On Tuesday, 11 March 2014 at 22:24:15 UTC, Nick Sabalausky wrote: On 3/11/2014 2:42 PM, Steve Teale wrote: Well if we're going there, we should go the whole hog and have final, direct, and virtual. Pardon my ignorance: What's 'direct'? > It's a system programming language, so you should be able to walk down the street naked as long as you are prepared to put up with the consequences. There has been much debate in the programming community over what exactly "system programming language" means. I think you, sir, have found the winner! Gets my vote, anyway! :) What I meant by final is simply the third leg of a tuffet. As I understand it, final means called directly, and you can't override, virtual means called through the vtable and you can override, direct means called directly, but you can override (hide) in a derived class, like if you define a method with the same signature in a derived class in C++ when the base class method is not marked as virtual. I tried that with G++ the other day, and it still seems to compile. There may be other possibilities, I have not attempted to draw the matrix table. Steve
Re: Broken?
On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote: I'd like to point out that Walter and Andrei can't do it all themselves. It takes a team and part of pulling it off is well defined goals and job descriptions with devoted people. This is one of the motivations for my remark. They both have probably more tan enough to do without having to wade through the tremendous volume of responses. Steve
Re: Broken?
On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote: On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote: On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven Schveighoffer wrote: On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh! Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea Well if we're going there, we should go the whole hog and have final, direct, and virtual. It's a system programming language, so you should be able to walk down the street naked as long as you are prepared to put up with the consequences. Steve
Re: Broken?
On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven Schveighoffer wrote: On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Re: Broken?
On Tuesday, 11 March 2014 at 18:01:23 UTC, John Colvin wrote: The buck does stop with Walter and Andrei. What you're seeing is community discussion, which informs their ultimate decisions. Are you saying that people shouldn't be discussing language decisions and that it should just be left to a couple of people? Also, of course Walter can decide not to do something due to community pressure. He has the ultimate say, it's his language, but that doesn't mean he shouldn't listen. I'm probably thinking more of some organization where if a discussion went off scale, something would happen, like a vote on the 3 main protagonists. If those 3 were not willing or able to get together and come up with a compromise, then the status quo should prevail until W/A decide otherwise. Lacking some compromise of that sort, D just becomes Balkanized. It did, and it recovered, but I think it sets things back. Steve
Broken?
What D needs at this point is a dictator. There are about 30 pages of discussion about Walter's std.array.front post, and Steve S's counter post. It reminds me of the way it was maybe 4 years ago, when there was so much bickering that I just gave up for some time, and went away. Who is going to go through all that stuff, and winnow a compromise out of it. Everyone has a job, or some vital preoccupation with their own project. The buck has to stop somewhere - is it Walter, or Andrei, or can any proposal or comment be stalled by sheer weight of contrary views? This is probably a management issue, not a technical one. Trouble is there's no manager, and even if their was, he'd have no minions. What to do? Steve
Re: Cumulative
On Friday, 7 March 2014 at 10:05:56 UTC, John Colvin wrote:
On Friday, 7 March 2014 at 09:43:07 UTC, Steve Teale wrote:
On Friday, 7 March 2014 at 09:04:29 UTC, John Colvin wrote:
How would these plain functions be different from final ones?
You would be able to redefine them in a derived class using
override to tell the compiler that it was intentional.
So the compiler would choose which function is called based on
the compile-time type of the class reference, instead of the
runtime type info? Inheritance without the polymorphism.
Twould be as in this C++, is that what you mean?
#include
class A
{
public:
void foo() { std::cout << "This is A\n"; }
};
class B: A
{
public:
void foo() { std::cout << "This is B\n"; }
};
int main()
{
A* a = new A();
B* b = new B();
a->foo();
b->foo();
}
My, it was painful writing that!
Re: Cumulative
On Friday, 7 March 2014 at 09:04:29 UTC, John Colvin wrote: How would these plain functions be different from final ones? You would be able to redefine them in a derived class using override to tell the compiler that it was intentional. Final would remain as-is - final. I think Walter made a good choice for the times when he chose to have functions virtual by default, but a system programming language should allow you to do dangerous things if you give the compiler your permission. Steve
Re: Cumulative
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
I can get tantalizingly close to what I want using the extra
constructor argument.
In the base class I define a template function:
string initString(T)()
{
return "string sname =
\""~T.stringof~"\"~to!string(++nextOid);"
"HandlerDelegates[] ahdg = [ HandlerDelegates( &"~
T.stringof~".notifyHandler, &"~T.stringof~".undoHandler)];";
}
Then in the leaf class constructor I can just do:
mixin(initString!Arrow());
super(aw, parent, sname, AC_ARROW, ACGroups.SHAPES, ahdg);
Sadly the compiler does not complain if I comment out the leaf
notifyHandler()
method, cos its virtual, and there's one in its parent class.
Does contract programming to provide a way to say that some
function definition is required?
This is where I'd like to be able to say:
class Base
{
// Method is called directly, but unlike a final
// method it can be overidden in a derived class.
direct bool notifyHandler(...) { ... }
}
class Inter
{
// Kill the warning about hiding the base class method with
override
override bool notifyHandler(...) { ... }
}
As a side benefit, I think that mixing in a string generated by a
template function gives me a way of generating something
approximating a mixin template that allows more than just
declarations - insertion of parameterized code at compile time ;=)
Steve
Re: Cumulative
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
class MyBaseClass {
bool addHandlersCalled = false;
bool delegate(int)[] handlers;
/// Subclasses must call this in their ctor.
protected void addHandlers(bool delegate(int)[] handlers)
{
this.handlers = handlers;
addHandlersCalled = true;
}
invariant() {
assert(addHandlersCalled);
}
}
Thanks Nick. A voice of sanity. Interestingly I'd decided on the
argument to the constructor while programming in bed last night.
The change of fashion is very noticeable though - structs for
everything seems to be a mantra these days. I have started to
wonder if the two styles could be bridged somewhat if we had the
default class method type as virtual, and then 'plain' functions
as well as final ones.
Steve
Re: Cumulative
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
25 years ago, when I was trying to write some sort of library
to go with Walter's C++ compiler, I had a wish, and it still
pops into my head from time to time.
What I wanted was functions that were declared in a base class
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler would then automatically add a
call to the same function in whatever base class last defined
or extended the method.
OK, I'm back to this because I have done quite a bit of work
trying to get to what I wanted. I have converted my app so that
it conforms roughly to the above, as a test.
I've also noticed from the responses, and from responses to
associated questions, that OOP has become almost a dirty word in
the D community. It's old fashioned and slow. So if you're in
that camp, you can stop reading now.
I need to handle signals of some sort - let's say just
represented by an int.
In my base class I define a method final void handleSignal(int),
to which all signals are directed. In the same place there's a
virtual function bool signalHandler(int).
The base class also has a data member bool delegate(int)[]
handlers.
In classes Base, Intermediate, and Leaf, say, the constructor has
a statement:
handlers ~= &Base.signalHandler;
handlers ~= &Intermediate.signalHandler;
handlers ~= &Leaf.signalHandler;
The final handleSignal() method in the base class just traverses
the array, calling each delegate in turn until one returns true,
and then throws an exception or something if none of them do.
This works nicely. A lot of duplicate code in my original handler
functions is eliminated. Any particular leaf class just has to
cover the cases peculiar to it's own requirements. Intermediate
classes just deal with their generic cases, and the base class
handles all the signals that all leaves require.
The compiler doesn't help to ensure that the 'handlers ~=' bit is
present in all constructors, so I thought I would be clever, and
provide some mixin template or template function that all the
constructors in the hierarchy used, so that it was a fairly
simple thing to insist on, even if only by example.
But I have been frustrated in this desire. A member function like
final void doMyThing(string CLASSNAME)()
{
handlers ~= mixin("&"~CLASSNAME~".signalHandler;");
}
defined in the base class does not work, because the compiler
complains about the type of the this pointer being Base, despite
the fact that I am being explicit about the class name.
Attempts from other directions like calling back down the super()
chain don't work because I can't have anything but declarations
in a mixin template, and a super() call inside a template
function called by the constructor fails because the call is not
in a constructor.
Anyone have any bright ideas about how this could be regulated? I
can't say forced, because I think the compiler would have to do
that.
Steve
Re: super(...) in mixin template
On Tuesday, 4 March 2014 at 07:23:29 UTC, Jacob Carlborg wrote: Perhaps you already figured this out but template mixins can only mixin declarations, not expression or statements. -- /Jacob Carlborg Damn! Yup, first sentence of the documentation. Wishful reading. Thanks. Steve
Re: super(...) in mixin template
On Monday, 3 March 2014 at 16:20:22 UTC, Gary Willoughby wrote:
On Monday, 3 March 2014 at 16:11:48 UTC, Steve Teale wrote:
I did not get any takers in D Learn, so I'll try again here.
Mixin templates are supposed to be instantiated in the scope
where they were invoked. I have tried one that I want to
invoke in the body of a constructor, but it fails when it
calls super(...).
Should this be so, or is it a bug?
Steve
Have you got an example please?
There's an example below, but it is probably not necessary.
The thing is that the mixin won't compile because it's seeing
super(whatever) as an attempt to define a function.
mixin.d(35): Error: function declaration without return type.
(Note that constructors are always named 'this')
mixin.d(35): Error: no identifier for declarator super(s, t, g)
If you move the mixin definition inside a constructor, you get a
slew of other errors.
What I really want the mixin to do should I think be done after
the class hierarchy is complete - without the super call the rest
of it is hardly worth bothering.
I should also mention that the example below compiles OK if you
move the super call out of the mixin, but for some reason it
won't link - it works OK in my app, so I didn't pursue it.
import std.conv;
enum
{
COX,
WILLIAM,
GREEN
}
enum Groups
{
APPLES,
PEARS,
BANANAS
}
class App
{
this();
}
class Base
{
string name;
int type;
Groups group;
mixin template Preamble(alias NAME, alias GNAME, alias T)
{
string s = NAME~" "~to!string(nextOid);
Groups g = mixin("Groups."~GNAME);
static int t = T;
// Mixin must be syntactically correct - the following
isn't because
// we are not in a constructor
super(s, t, g);
}
this(App app, string s, int t, Groups g)
{
name = s;
type = t;
group = g;
}
}
class Intermediate : Base
{
this(App app, string s, int t, Groups g)
{
super(app, s, t, g);
}
}
class CoxPipin : Intermediate
{
static int nextOid = 0;
this(App app)
{
mixin Preamble!("CoxPipin", "APPLES", COX);
// Move the super call out, and everything is fine
//super(app, s, t, g);
}
}
void main()
{
App a = new App();
Base x = new CoxPipin(a);
}
super(...) in mixin template
I did not get any takers in D Learn, so I'll try again here. Mixin templates are supposed to be instantiated in the scope where they were invoked. I have tried one that I want to invoke in the body of a constructor, but it fails when it calls super(...). Should this be so, or is it a bug? Steve
Re: D, Dub and distributions
On Sunday, 2 March 2014 at 17:29:21 UTC, Russel Winder wrote: Has anyone investigated whether Dub is an acceptable tool for use by Debian and Fedora packagers for building Debian and Fedora packages? I would hate to start a D+GtkD project (*) using Dub only to find that Debian and Fedora would refuse to package the project. Have not quite got to that point yet, but as you know, I am skirting around it. I have built my own .deb files, but they rely on the user to make sure the dependencies are satisfied, so clearly I have to come up with something better. We should stay in touch on this. Two is often better than one! Steve
Re: Old Machines and XP for Linux(not really a D topic)
On Friday, 28 February 2014 at 21:05:01 UTC, Stanislav Blinov wrote: On Friday, 28 February 2014 at 18:04:44 UTC, Steve Teale wrote: You keep repeating this as if no one in this NG understands what you're saying. Respectfully, I'll say that you are wrong. I know all too well what it is to not have access to the latest greatest hardware or money to buy that new slick hoptoshop or whatever. Not to mention not having an affordable and stable Internet connection. I hope I don't need to go down the chain to more meaningful problems. You're being dismissive just because people most of which you can safely assume to be younger than you disagree with you. I'll repeat myself just to clarify: even if it so happened that XP continued its life, in the near future you won't be finding any software that would run on it. At least not proprietary software. Outdated hardware is not the only issue here. I take your points. Thanks Steve
Re: Old Machines and XP for Linux(not really a D topic)
On Friday, 28 February 2014 at 12:20:14 UTC, Stanislav Blinov wrote: If you're talking Linux, why not just use Linux? To people who can just about manage to use outdated software on XP, it's probably a big deal to switch to Linux. And is that outdated version of Quickbooks available to run under Linux? You are living in a different world, so don't just assume that the knowledge and availability of equipment that you are accustomed to exists elsewhere. I was being semi-sarcastic, since as far as I'm concerned, Windows could die tomorrow. What I said was that Microsoft might be doing themselves a favour in the long term if ... Steve
Re: Old Machines and XP for Linux(not really a D topic)
On Friday, 28 February 2014 at 12:20:53 UTC, John Colvin wrote: My question would be: why bother? Why not just use linux? People who can't afford modern machines or expensive proprietary software is a market that linux caters for (almost) uniquely well already. John, Please see my answer to Stanilaw. Steve
Re: Old Machines and XP for Linux(not really a D topic)
On Friday, 28 February 2014 at 08:07:12 UTC, John Colvin wrote: On Friday, 28 February 2014 at 04:31:01 UTC, Steve Teale wrote: I was in a discussion here recently about 64 bit and how much memory people had in their machines these days. A somewhat unrelated topic is that Microsoft are in the process of dumping XP. Perhaps of interest: http://www.reactos.org/ http://zorin-os.com/ Mmm, interesting, but I don't think either of them are the right thing. I used the term XP lookalike by accident. I should have said XP clone or replicate or something. The Linux kernel must be powerful enough these days to support complete replication of XP functionality Steve
Re: Cumulative
On Thursday, 27 February 2014 at 21:44:20 UTC, Shammah Chancellor wrote: On 2014-02-26 16:05:19 +, Steve Teale said: Actually, D has the ability to walk the object hierarchy at compile time, and generate a function call containing all the super classes's handleCommands. You could also even tag them with an attribute structure to list which command #'s they accept to be able to generate a switch, or bunch of if's to avoid function calls. -S. Yes, I'd been thinking about tagging them at least.
Old Machines and XP for Linux(not really a D topic)
I was in a discussion here recently about 64 bit and how much memory people had in their machines these days. A somewhat unrelated topic is that Microsoft are in the process of dumping XP. Now all those old desktop boxes with only 500k of memory will increasingly migrate in containers to Africa, like the discarded mountain bikes, and old banger cars. When they get here they have traditionally had XP installed, since that is readily available for free - legal or not. Microsoft might do itself a favour in the long term if instead of just dumping XP, it started from the Wine code, and made an XP lookalike Linux distro. That way, the old boxes would have an extended life, Microsoft would have goodwill from a lot of users, and would not have to spend a lot of money keeping the old OS, the spammers would be blocked in their process of taking over all those unprotected XP machines, and lots of young African girls and boys could learn to program in D ;=) Steve
Re: A Proposal to Add 2D Graphics Rendering and Display to C++
On Wednesday, 26 February 2014 at 17:10:01 UTC, Russel Winder wrote: On Wed, 2014-02-26 at 16:40 +, NA wrote: This is an updated document and is quite interesting. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf https://groups.google.com/a/isocpp.org/forum/#! msg/std-proposals/IaaG316uPjo/9N4YsRYX4nkJ Is worth a look. It seems to favour Cairo as a starting point. I bet the D community could win a race with the C++ lot to implement it. D makes you much more productive. For any who don't know what Cairo does, the app I'm working on - COMPO - is pretty much a showcase for what it, and the associated text rendering library Pango, can do - britseyeview.com/compo/.
Re: A Proposal to Add 2D Graphics Rendering and Display to C++
On Wednesday, 26 February 2014 at 16:40:59 UTC, NA wrote: This is an updated document and is quite interesting. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf NA Don't we already have it? Called gtkD. Steve
Re: Cumulative
On Wednesday, 26 February 2014 at 13:30:15 UTC, Leandro Motta Barros wrote: Hello, I'm coming late to the discussion, but I believe that you can use the following idiom to achieve the same results in a different way: Yes we went through that, if you go back a page you'll find a post I did that makes the thing work better using a class variable in the base class that is an array of delegates. That way you don't have to do super, super, super back to root, you just have to iterate over the delegates until you find one that accepts the command. It does just what I wanted to do in the first place without compiler assistance ;=). Steve
Re: Cumulative
On Tuesday, 25 February 2014 at 11:04:24 UTC, Steve Teale wrote: On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote: I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through. OK, it's at britseyeview.com/cumulative.txt. However, I now realize you can do better in D. The base class needs to define an array of delegates. It appends its handler to the array, then derived classes each append their handler. The append is done like: handlers ~= &Red.handleCommand; Am I right in thinking that this makes the calls non-virtual? Anyway, the result is I think exactly what I wanted. The example is at britseyeview.com/cum2.txt. Steve
Re: Cumulative
On Tuesday, 25 February 2014 at 03:13:23 UTC, Shammah Chancellor wrote: So far as I'm understanding this thread, Steve Teale is asking for a way to inject code before and after a call to a function from other places in the program. E.g. Write some function foo, write some function bar, and specify that any time foo is called, bar should be called immediately after *automagically*. The reason this hasn't been done in any language I'm aware of is because you can solve the same problem using existing polymorphism, and it's a horribly awful design practice to have hidden code like that. It's a bit more specific than 'from other places in the program', and anyway, once you've accepted virtual functions, you've accepted 'automagic' ;=) I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through. Steve
Re: Cumulative
On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote: I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through. OK, it's at britseyeview.com/cumulative.txt. I think enforcement of the call to super.handleCommand() would get most of the way down the road. More could be done if the compiler inserted the super call, and maintained an implicit class member equivalent to my 'cmdResult' that could be tested in override implementations of handleCommand(). But I think that is OTT. Steve
Re: Cumulative
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
25 years ago, when I was trying to write some sort of library
to go with Walter's C++ compiler, I had a wish, and it still
pops into my head from time to time.
What I wanted was functions that were declared in a base class
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler would then automatically add a
call to the same function in whatever base class last defined
or extended the method.
extend void foo() // Declared in base class as cumulative
void foo()
{
(cast(BaseClass) this).foo(); // Compiler does this for you
// similar to changing a
light bulb ;=)
// the extra stuff
}
I think also that it might be necessary for the base class
function to return on behalf of the derived method as opposed
to to it.
Does this make any sense?
Steve
Sorry, I had two foo()s in the 'example'. What I meant was
extend void foo() // Declared in base class as cumulative
{
Cumulative
25 years ago, when I was trying to write some sort of library to
go with Walter's C++ compiler, I had a wish, and it still pops
into my head from time to time.
What I wanted was functions that were declared in a base class as
'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify the
extra code. The compiler would then automatically add a call to
the same function in whatever base class last defined or extended
the method.
extend void foo() // Declared in base class as cumulative void
foo()
{
(cast(BaseClass) this).foo(); // Compiler does this for you
// similar to changing a light
bulb ;=)
// the extra stuff
}
I think also that it might be necessary for the base class
function to return on behalf of the derived method as opposed to
to it.
Does this make any sense?
Steve
Re: $ for length?
On Thursday, 20 February 2014 at 13:52:20 UTC, Chris wrote: Why not have both? I was not suggesting otherwise.
$ for length?
How difficult would it be to allow the '$' to be used instead of length in something like: Thing[] ta; for (size_t i = 0; i < ta.$; i++) It can be used in slices, and indexes, so it might well be unambiguous here.
Re: One more question - an untapped audience.
On Wednesday, 19 February 2014 at 17:22:37 UTC, Iain Buclaw wrote: I expect any issues encountered with the other platforms to be minor, and hopefully switching gdc and ldc will be fairly painless too. Once you get past the 6 months spent re-writing 70% of the existing gdc and ldc glue code. ;) Iain, there are two groups of programmers. One says "That should be quite straightforward." The other says "That sounds like a lot of work." My experience in the software industry suggests that it is usually the latter group that gets the job done! Steve
Re: mysql-native: newbie questions
On Tuesday, 18 February 2014 at 01:04:10 UTC, simendsjo wrote: > The rejectedsoftware repo is based on an earlier version of mine which in turn is based on the original by Steve Teale (britseye). Thanks for the nod. It's good to see that all those hours were not wasted.
Re: Two Questions
On Friday, 14 February 2014 at 00:10:13 UTC, Jonathan M Davis wrote: But the fact that you're even asking the question shows that you have a very different world-view than I do with regards to computers. - Jonathan M Davis Jonathan, I find your response distinctly elitist. I certainly do have a different world view. I live in Africa where most of what you can get is probably old stock that got dumped here. Of the last 3 2G memory cards I bought, 2 were duff, and that's at $50 apiece, and little chance of getting your money back. Even when I got two that worked, my motherboard could only support 3 of the 4G, even though the processor is quite capable. We're stuck with 32 bit for a long time here, and telling us to get into the 21st century doesn't help much. Steve
Re: One more question - an untapped audience.
On Wednesday, 12 February 2014 at 02:43:36 UTC, Tofu Ninja wrote: Steve Oh I am sorry, by developing world I thought you were talking about the world of developers, why are you interested in getting D to the developing world? Seems kinda odd... Because if we can't get those young men into something with intellectual content, we're going to be back in the dark ages before we know it. I just happen to think D is a great language!
Re: One more question - an untapped audience.
Probably noting to do with D, but if D were to get into the appropriate place firs , then ...
Re: D as A Better C?
On Tuesday, 11 February 2014 at 21:13:56 UTC, Walter Bright wrote: On 2/11/2014 12:37 PM, Dmitry Olshansky wrote: The idea is it would not require any library other than the C runtime. This somehow reminds me of the first C++ compiler, which generated C. I quite like the idea. Steve
Re: Two Questions
On Sunday, 9 February 2014 at 19:58:48 UTC, Russel Winder wrote: Developers with a decent system should have no problem at all building both 32-bit and 64-bit versions Pensioner, limited budget, want to contribute?
Re: One more question - an untapped audience.
On Tuesday, 11 February 2014 at 11:00:18 UTC, Chris wrote: On Tuesday, 11 February 2014 at 05:03:29 UTC, Mike Parker wrote: The most important thing for newbies, either new to the language or new to programming, is "instant gratification". If it compiles and works, people are more likely to be enthusiastic about it. Give them useful examples and use cases and they will begin to see how useful programming is and start thinking about applications, however trivial they may be, they can write themselves for their own personal use (a little clock, a calculator for VAT ...) In this way they will start to think as both developer and user, add features, go ever deeper into programming. Creating useful things, that's what it's all about, isn't it? Thanks for your last paragraph. That's what I was talking about.
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote: I am only 20 and am still in university so I feel like I can answer this with at least my own experiences. Personally I think D would capture the attention of more young people if it was simply easier to use. The first "real" language I really got into was C#(about 5-6 years ago) and I think the main You hijacked my topic and converted it into the usual arguments about lack of infrastructure for D. I'm talking about guys and girls who don't have a computer, let alone C#. They just have a cheap smart phone that maybe they succeeded in getting rooted. So is your answer that they should just use Java? And yes, the C# library is excellent, but D is a better language, and is easy to use. Get out of the wood and see the trees! I'm at the other end of my life, with a long view of history. We should do our bit to help to bring civilization and reason (back) to the world, not just tell people 'use C#'. A more relevant criticism would be that people who only know say Swahili won't be able to find out about and use D anyway - Java either. Sadly my Swahili is not up to it. Sorry, but you asked for it ;=) Steve
Re: Two Questions
On Sunday, 9 February 2014 at 21:12:57 UTC, Jonathan M Davis wrote: so it's nice to have a lot of overhead (and with memory being as cheap as it is, I don't see much reason not to put as much memory in the box as it can Jonathan, you live in a different world. Memory is not cheap everywhere - maybe not even available, and not everyone - probably a minority in fact in world terms, has a recent processor, or even enough memory slots.
One more question - an untapped audience.
What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve
Re: Two Questions
On Tuesday, 4 February 2014 at 16:18:24 UTC, Steve Teale wrote: Popped into my head today. What proportion of the D community develops on Linux of some sort, and what proportion works with a 64 bit OS? And why? OK, I'm clear about why Linux, but 64 bit I'm less clear about. What's the attraction about a system that's a memory hog, but not noticeably quicker, and where you have to do cross compilation to make applications that are usable by the vast proportion of world computer users?
Re: Idiotmatic D
On Monday, 3 February 2014 at 07:30:45 UTC, Brian Schott wrote: Right now we have a mess of inaccurate specs, a compiler front end that accepts whatever the heck it feels like, and a culture of rumors and legends surrounding what's (going to be) deprecated and what isn't. Are you proposing to fork DMD and lead the way?
Two Questions
Popped into my head today. What proportion of the D community develops on Linux of some sort, and what proportion works with a 64 bit OS? And why?
Re: override deprecated
Based on my C++ memories it is quite common issue when working in a teams because "Big Picture" is lacking. When you are main sole contributor, keeping overall class layout in mind does not seem to be any demanding. That is of course true. The worst case then being that other users add functions with colliding signatures without being aware of the same method in some remote base class. So yes, override has to be there, but I want my pound of flesh also ;=)
override deprecated
I'm sure this was discussed at great length sometime, but yesterday (and the day before) I had one of those days where I turned on warnings , and told the compiler not to ignore deprecated things. Most of the warnings were probably due to keyboard repeats where I had held a key down fractionally too long while typing the semicolon to end whatever. The other common case was fall-through in case statements - in that case, very insidious, and the warnings very helpful All of the deprecated things in in my cleanup were those many cases where I had provided alternative definitions for virtual functions in derived classes without using override. Now I can vaguely see the reasoning for insistence on the override keyword. It's kind of a consequence of Walter's decision that all member functions are virtual unless ... But as I plodded through my code base, I came across not a single situation where the declaration of a virtual function in some derived class was an error. I found a few where the declarations were redundant, in that they were the same in effect as the function defined in the parent class, but I was left feeling cheated. Being picky about the code had not given me any tangible benefit. Would it be reasonable to ask for the compiler to generate a warning if it found that the definition of a virtual function was the same - disregarding white space - as that in the parent class. That would make me feel that there was some small benefit for the insistence on 'override'.
Re: Which tools do you miss in D?
On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote: In order: 1. A debugger (that works properly) 2. Go-to definition (that always works) 3. Auto-complete (that always works) 4. Import management (missing/duplicate/unused imports) 5. Typical suite of modern refactoring tools It amazed me that your post was the first that mentioned a working debugger!
Re: GUI Editors for D
On Sunday, 26 January 2014 at 05:35:38 UTC, Mike Parker wrote: I use Sublime Text 3 + dub. It's... sublime. I quite like the look of Sublime. Is it possible to integrate it and DUB? If so is that described anywhere?
Re: GUI Editors for D
On Saturday, 25 January 2014 at 18:09:16 UTC, Tofu Ninja wrote: I use monoD and it is by far the best IDE for D that I have tried, I have tried to mess with Visual D on 3 different occasions but I have never got it working properly and I didn't want to use eclipse either as it is kinda bloated. Its super simple as well, just get monoDevelop running and download the D plugin from the plugin manager, set your paths and your done. OK, I looked again, but for Ubuntu, the latest version offered on the monoD web site is 2 major versions old. That does not encourage me.
