Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 20:38:46 UTC, Andrei Alexandrescu wrote: On 01/04/2016 01:25 PM, Russel Winder via Digitalmars-d wrote: [snip] What is Boost.Sprint? I haven't heard of it, and can't find it. Thanks! -- Andrei I think he miss-typed or miss-remembered. It is Boost.Spirit. http://boost-spirit.com/home/
Re: Wait, what? What is AliasSeq?
On Thursday, 9 July 2015 at 08:03:06 UTC, deadalnix wrote: [..] Additionally, we have this language concept that is autounpacking and so on and have no name. It needs a name. [..] Unrolling?
Re: What IDE/EDITOR do you use for D?
On Wednesday, 29 October 2014 at 19:38:16 UTC, dan wrote: What IDE/EDITOR do you use for D? What plugins if you use Vim? Visual Studio + VisualD. That way everyone thinks I'm doing C++ at work (I'm the only one doing C++ in a big Java shop!). Oh, and of course Notepad2 (as Total Commander Editor) for quick-and-dirty editing/viewing/whatever!
Re: new DIP47: Outlining member functions of aggregates
On Monday, 9 September 2013 at 17:34:23 UTC, Joseph Rushton
Wakeling wrote:
On 09/09/13 18:41, Ettienne Gilbert wrote:
I would argue that it is actually better this way (that not
all functions need
to be in the declarations list) - its way more flexible! This
way you can leave
out function declarations that you are not really interested
to see from a
"functional overview perspective" of the class.
AFAICS the request is for separation of declaration and
definition, so you'd be able to do things like this:
class Foo
{
void foo();
int bar(double x);
void goo(int n);
// ... etc.
}
... and then later in the same file:
void Foo.foo()
{
/* ... function body ... */
}
int Foo.bar(double x)
{
/* ... ditto ... */
}
void Foo.goo(int n)
{
/* ... and so on ... */
}
Now, you'd be at liberty to mix declarations and definitions in
the _class_ (or struct) declaration, e.g.:
class Foo
{
void foo(); // we define this somewhere else
int bar(double x)
{
/* ... but we define this here */
}
// ... etc.
}
But supposing that a function is declared but not defined
inside the class declaration, it should be obligatory that it
_is_ defined somewhere else in the file -- and conversely, if a
class function is defined somewhere else in the file, it should
be obligatory that it's declared in the class declaration.
And on top of that, it should be obligatory that the
declaration and definition match perfectly. (Note that for any
function defined in the class declaration, this is
automatically and unavoidably true:-)
Ahh, ok. I see where you are coming from - you were evaluating
the implications of what Jacob Carlborg proposed if "mixed" in
with Walter's DIP47, right? My points though was specifically on
the implications of Jacob Carlborg's proposal "in isolation" i.e.
as an acceptable alternative to DIP47. And, AFAICS, Jacob posed
the question to Manu this way as well (I think - but maybe Jacob
can confirm/deny).
If you mix the 2 I agree with you for the most part. But the real
question for me (and I suspect Jacob) is this:
Is this...
class Foo
{
void foo();
int bar(double x);
void goo(int n);
// ... etc.
}
void Foo.foo()
{
/* ... function body ... */
}
int Foo.bar(double x)
{
/* ... ditto ... */
}
void Foo.goo(int n)
{
/* ... and so on ... */
}
...really so much better than this?
class Foo
{
void foo();
int bar(double x);
void goo(int n);
// ... etc.
void foo()
{
/* ... function body ... */
}
int bar(double x)
{
/* ... ditto ... */
}
void goo(int n)
{
/* ... and so on ... */
}
}
Granted, this sacrifices some flexibility from DIP47. But these
are of such dubious quality/use/potential pitfalls (as discussed
in this thread), that I hardly think DIP47 is worth implementing
as a result. Especially since, what we currently have (as shown
by Carl,) already gives you arguably 90%+ (IMHO) of Manu's
request for (I quote) "You don't need to see the function bodies
in the class definition, you want to quickly see what a class has
and does". Does it really matter that the function definitions
are also present inside the class definition, as long as you can
also see "what a class has and does" in the declarations list at
the top?
Of course fixing the current issues with .di generation is
important as a separate issue.
Re: new DIP47: Outlining member functions of aggregates
On Monday, 9 September 2013 at 13:51:20 UTC, Joseph Rushton
Wakeling wrote:
On 09/09/13 15:12, Daniel Murphy wrote:
[snip]
/
Whoa, I didn't think of applying that to member functions.
This seems like
the answer. Put your variables and function prototypes at the
top of your
class. Done.
Problem -- what about:
class Foo
{
// Declarations
void foo();
int bar(double n);
// Definitions
void foo() { }
int bar(double n) { }
// Whoops! Forgot to include this one in the
// declarations list, but it's still accepted
// as part of the class
void goo() { ... }
}
A well-defined rule for separating out declarations and
definitions would check for that and throw a compile error.
I would argue that it is actually better this way (that not all
functions need to be in the declarations list) - its way more
flexible! This way you can leave out function declarations that
you are not really interested to see from a "functional overview
perspective" of the class.
AFAIC the cost of implementing this would be way too high for any
potential benefit gained from this. And, since Walter already
stated that this would "no way be mandatory", the implications
are that the compiler would need to enforce it once any one
function is declared in the declarations list, but... not enforce
it if no functions are declared in the list!
Also, leaving it flexible as it is now cannot silently break
anything. Worse that can happen is that you may inadvertently try
to implement goo() twice (since you may think the missing
declaration imply there is no definition), but then the compiler
will anyway complain about the duplicate definition.
So I agree with Jacob Carlborg - I would also like to know why
the above is not already sufficient...?
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 13:00:11 UTC, Dmitry Olshansky
wrote:
08-Sep-2013 16:02, Michel Fortin пишет:
[Snip]
Example:
// test.di
module test;
class A {
void foo(int a, int b);
}
// test.d
import module test; // import declarations from the .di
file
void A.foo(int a, int b) {
// member function definition
}
With this suggestion it finally becomes sane.
+1
Re: RES file not linking anymore with DMD v2.052
On Wednesday, 24 April 2013 at 06:33:22 UTC, Rainer Schuetze wrote: XP support for DLLs seems to have been broken between rc3 and rc4 ;-( I'll have to investigate... The fix for the command line is in rc1. Hi Rainer, OK, that's no problem - I'll just stick to rc3 for now then. Thanks for analyzing the problem. Cheers, Ettienne
Re: RES file not linking anymore with DMD v2.052
On Monday, 22 April 2013 at 22:19:39 UTC, Rainer Schuetze wrote: Yes, it should be fixed in the rc for the next version: http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.36rc5.exe Hi Rainer, With VisualD-v0.3.36rc5 (Win XP 32bit, VS 2008) I get an install error: "Error loading C:\Program Files\VisualD\visuald.dll. Invalid access to memory location" I tried also with VisualD-v0.3.36rc4 - but get the same error. If I re-install VisualD-v0.3.35 it installs fine. Regards, Ettienne
Re: RES file not linking anymore with DMD v2.052
On Monday, 22 April 2013 at 17:51:26 UTC, Rainer Schuetze wrote: On 22.04.2013 14:02, Ettienne Gilbert wrote: Hi, I've finally gotten round to upgrading my DMD to v2.062 (from v2.059) - running on Win XP. I've had no issues recompiling the (quite old) DFL library I use with the latest DMD, so went on to rebuild a tool I previously developed (that uses DFL). Everything compiled ok, but the linker choked on my RES file. (This project build fine and worked perfectly on previous versions of DMD up to and including v2.059). The error is: OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html atrchecker.RES(3) : Error 52: .DEF Syntax Error DO I suspect your build script has somehow omitted a ',' from the command line in its invocation of optlink. The usage is LINK obj[,out[,map[,lib[,def[,res] so if a comma misses, your resource file is interpreted as a def file. If you are invoking the linker through dmd, you might want to check the linker call by adding "-v" to the command line. Hi Rainer, I am actually using Visual-D (v0.3.35), so I've tested your idea by copying + pasting from .\Debug\.buildlog.html into a batch file - and then building using this batch file rather than Visual-D. And your hunch was spot on! If I modify the the linker invocation with an extra comma (i.e. as in ... "C:\dmd2\windows\lib\",,atrchecker.RES/NOMAP/CO/NOI /SUBSYSTEM:WINDOWS ..) it builds fine; without the extra comma it fails with the same error as before. I suppose this is then a Visual-D issue and not a DMD linker issue, right? Regards, Ettienne
Re: RES file not linking anymore with DMD v2.052
On Monday, 22 April 2013 at 12:33:52 UTC, Andrej Mitrovic wrote:
On 4/22/13, Ettienne Gilbert wrote:
Any ideas?
Resource scripts can use one of two syntaxes - an older one and
a new
one, one uses BEG/END, the other { }, and Optlink only supports
one of
the two.
I think you can use ResEdit[1] to convert the syntax so Optlink
can
understand it.
[1] : http://www.resedit.net/
Hi Andrej,
Thanks for the very speedy response. Handy to know about resedit
as well, but it turned out that the problem was as Rainer
Schuetze suspected.
Regards,
Ettienne
RES file not linking anymore with DMD v2.052
Hi, I've finally gotten round to upgrading my DMD to v2.062 (from v2.059) - running on Win XP. I've had no issues recompiling the (quite old) DFL library I use with the latest DMD, so went on to rebuild a tool I previously developed (that uses DFL). Everything compiled ok, but the linker choked on my RES file. (This project build fine and worked perfectly on previous versions of DMD up to and including v2.059). The error is: OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html atrchecker.RES(3) : Error 52: .DEF Syntax Error DO ^ I am sure that the "D0" and "^" is suppose to indicate the position of the error, but is pretty useless in this case. I've googled on ".DEF Syntax Error" and, according to http://www.digitalmars.com/ctg/OptlinkErrorMessages.html, this indicates a "An invalid .def file syntax could not be parsed. ", which does not help much at all. I am pretty confident though that it is not a DEF file issue since I am building a EXE (no DEF should be required). The Tool also builds fine if I remove the RES file from the project. Googling on "Error 52" bought up nothing substantial either. The RC file for the RES file is extremely simple: Code: 101 ICON DISCARDABLE ".\\Resources\\scope4.ico" 205 BITMAP DISCARDABLE ".\\Resources\\SomeBitmap.bmp" STRINGTABLE DISCARDABLE BEGIN 3001 "some string!." END I've tried compiling the RC file with both the MS as well as the DM resource compiler: For DM: rcc -32 atrchecker.rc For MS: "c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\rc" /r /v atrchecker.rc The symptoms are exactly the same in both cases. I can open the RES file with any number of resource editors (including Visual Studio and XN Resource Editor) and they all display the relevant BMPs and ICOs without errors. Any ideas? Regards, Ettienne
Re: Incomprehensible compiler errors
On Monday, 30 July 2012 at 22:54:59 UTC, Stuart wrote: On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote: A ModuleInfo is generated for each compiled module and inserted into its corresponding .obj file. If the linker cannot find it, then it is likely that you need to specify that .obj on the link command. Ah, it would seem that my problem is with DFL not compiling. Look guys, I'm about ready to give up here. I like the idea of D, but it's like using fucking Linux: Absolutely everything needs to be compiled before you can use it; and nothing will compile because you need to do fifty other goddamn things that aren't mentioned in the readme, so you have to post on dozens of sodding forums for a week hoping someone throws you a bone. I really empathize with you - I went through similar pains when I started using DFL some years ago (along with VisualD). In the end it wasn't too bad, but there are some "catcha"s to be aware of. So I figure the best I can do for you (and to avoid one extremely long message) is to do a blog posting on this - see http://objectmonkey.wordpress.com/2012/07/31/using-dfl-with-visuald/. Hope it helps! All I want is to be able to write a GUI application using phrases like "button1.dock = Fill". Is that so much to ask? Apparently it is. DFL won't compile. D-IDE doesn't work at all. VisualD crashes all the time. The Eclipse IDE plugin doesn't work either. None of the IDEs have any kind of reliable intellisense. The optional "module" keywords aren't optional. The whole fucking thing's a shambles, just like everything else designed for Linux. It's really getting on my tits. Even using MFC is easier than this. Actually, if you are stuck in Windows land and really need to use VS for whatever reason (and don't need portability to other OS's) I found the DFL+VisualD combo to be acceptable for doing GUI development. It isn't as polished as C#/Delphi/C++ Builder as far as all the RAD Form stuff goes, but it is useable - so hang in there! Ettienne
