Re: Wrapping C that uses compiler extensions
simendsjo wrote:
> On 04.03.2011 22:42, "Jérôme M. Berger" wrote:
>> int main(string[] args) {
>> auto s1 =(); // MH MH
>> auto s2 =(); // OK
>> s2.c =ull; // OK
>> return 0;
>> }
>
> Is part of your message gone?
>
Uh, I did not write that.
>> You can safely ignore the “ATTRIBUTE_FORMAT_FPTR(printf, 4, 5)”.
>
> That I understood :) Thanks!
Then if the issue is with the rest of the definition, it is more or
less equivalent to (you will need to translate the argument
declaration too):
alias size_t function (struct charset_info_st *, char *to, size_t n,
const char *fmt,
...) snprintf;
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: C const
Jesse Phillips wrote: simendsjo Wrote: On 04.03.2011 23:10, Jesse Phillips wrote: > Remember that const/immutable, and other attributes/properties aren't going to change the ABI so dropping them will be safer then leaving them. Thanks. Does this apply to all uses of const, or just complex members? Hopefully I'm not wrong on this, but you should even be able to change the type as long as the size is the same. So instead of int you could use uint or byte[8]... granted the library will still interpret it as int. And of course that is assuming you are on a machine with a 32 bit int. And 4-bit bytes? :p -- Simen
Re: Wrapping C that uses compiler extensions
On 05.03.2011 08:58, "Jérôme M. Berger" wrote:
simendsjo wrote:
On 04.03.2011 22:42, "Jérôme M. Berger" wrote:
int main(string[] args) {
auto s1 =(); // MH MH
auto s2 =(); // OK
s2.c =ull; // OK
return 0;
}
Is part of your message gone?
Uh, I did not write that.
Checked the web newsinterface, and I see your post. In thunderbird I got
another post from Tom with the subject "Struct reference returning
function and const members" in your post...
You can safely ignore the “ATTRIBUTE_FORMAT_FPTR(printf, 4, 5)”.
That I understood :) Thanks!
Then if the issue is with the rest of the definition, it is more or
less equivalent to (you will need to translate the argument
declaration too):
alias size_t function (struct charset_info_st *, char *to, size_t n,
const char *fmt,
...) snprintf;
Jerome
The definition is inside a struct. I shouldn't use an alias then..?
This is the C struct:
typedef struct my_charset_handler_st
{
// snip
size_t (*snprintf)(struct charset_info_st *, char *to, size_t n,
const char *fmt,
...) ATTRIBUTE_FORMAT_FPTR(printf, 4, 5);
// snip
}
And this is my D struct:
struct my_charset_handler_st
{
// snip
size_t function(charset_info_st*, char* to, size_t n,
const char* fmt,
...) snprintf;
// snip
}
Re: Template type parameters with their own type parameters
On 03/05/2011 04:02 AM, Peter Lundgren wrote:
I have a function that I think should look something like this:
MyStruct!T myFunc(T)(MyStruct!T x, ...) {
...
return MyStruct!T(...);
}
and the closest I can get to is:
T myFunc(T)(T x, ...) {
...
return T(...);
}
which works, but doesn't make clear the intended use and gets in the way of
overloading. How can I express the intent of the first version.
Maybe I do not exactly understand your problem; anyway, the following runs fine
by me:
struct S (T) {
T v;
}
S!T inc (T) (S!T s) {
return S!T(s.v + 1);
}
unittest {
auto s1 = S!int(1);
auto s2 = inc(s1);
assert ( s2.v == 2 );
}
Could you provide (1) context (2) example (3) errors?
Denis
--
_
vita es estrany
spir.wikidot.com
Re: in/out with -release
Jonathan M Davis: > Asserts are for > debugging, testing, and verifying code when developing, not for code which is > released. If you take a look at the dmd compiler, it's released with asserts in, and they give all those nice error messages I put in Bugzilla :-) Bye, bearophile
Re: in/out with -release
On 03/05/2011 01:58 PM, bearophile wrote: Jonathan M Davis: Asserts are for debugging, testing, and verifying code when developing, not for code which is released. If you take a look at the dmd compiler, it's released with asserts in, and they give all those nice error messages I put in Bugzilla :-) lol! I have a similar problem in designing the implementation of a toy language: the issue is that users of the runtime are, for instance, lib developpers, which own users are developpers in the source language beeing implemented, for their own final users... This makes it rather abstract to think at what is, or should be, the realisation of an error spit by the runtime. It cannot be a normal error from the implementation language, and also not an error of the source language. I had to write my own // error system. Denis -- _ vita es estrany spir.wikidot.com
Re: Help learning how to interface with c(++)
Kai Meyer Wrote: > I can't seem to get this to work right: > > gcc -m32 -shared -fPIC Test.cpp -o libTest.so > g++ -m32 test_c.cpp -L. -lTest -o test_c > wine htod.exe Test.h Test.d > dmd test_d.d Test.d -L-L. -L-lTest -oftest_d > test_d.o: In function `_Dmain': > Test.d:(.text._Dmain+0x20): undefined reference to `increment' > collect2: ld returned 1 exit status > --- errorlevel 1 > make: *** [test_d] Error 1 > > The resulting test_c binary from g++ works as intented (With either > LD_LIBRARY_PATH="." or LD_RUN_PATH="."): > $ ./test_c > Count = 0 > Count = 1 > $ ldd test_c > linux-gate.so.1 => (0x00ad1000) > libTest.so (0x005b9000) try non-shared libTest, dmd prefers single executable compilations.
Re: in/out with -release
On 3/5/11, bearophile wrote: > Jonathan M Davis: > >> Asserts are for >> debugging, testing, and verifying code when developing, not for code which >> is >> released. > > If you take a look at the dmd compiler, it's released with asserts in, and > they give all those nice error messages I put in Bugzilla :-) > > Bye, > bearophile > Hmm. Are those shown when compiling a file with -debug? Or do I need to compile DMD itself in debug/nonrelease mode to activate those error messages?
Re: Wrapping C that uses compiler extensions
simendsjo wrote:
> On 05.03.2011 08:58, "Jérôme M. Berger" wrote:
>> simendsjo wrote:
>>> On 04.03.2011 22:42, "Jérôme M. Berger" wrote:
int main(string[] args) {
auto s1 =(); // MH MH
auto s2 =(); // OK
s2.c =ull; // OK
return 0;
}
>>>
>>> Is part of your message gone?
>>>
>> Uh, I did not write that.
>
> Checked the web newsinterface, and I see your post. In thunderbird I got
> another post from Tom with the subject "Struct reference returning
> function and const members" in your post...
>
You can safely ignore the “ATTRIBUTE_FORMAT_FPTR(printf, 4, 5)”.
>>>
>>> That I understood :) Thanks!
>>
>> Then if the issue is with the rest of the definition, it is more or
>> less equivalent to (you will need to translate the argument
>> declaration too):
>>
>> alias size_t function (struct charset_info_st *, char *to, size_t n,
>> const char *fmt,
>> ...) snprintf;
>>
>> Jerome
>
> The definition is inside a struct. I shouldn't use an alias then..?
>
No, you are right, I thought there was a typedef in the C code...
> This is the C struct:
> typedef struct my_charset_handler_st
> {
> // snip
> size_t (*snprintf)(struct charset_info_st *, char *to, size_t n,
> const char *fmt,
> ...) ATTRIBUTE_FORMAT_FPTR(printf, 4, 5);
> // snip
> }
>
> And this is my D struct:
> struct my_charset_handler_st
> {
> // snip
> size_t function(charset_info_st*, char* to, size_t n,
> const char* fmt,
> ...) snprintf;
> // snip
> }
Yes, that should be about right.
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Some weird crashes
On 28.02.2011 18:52, simendsjo wrote: I'm trying to wrap the newest mysql c connector, but I get some weird bugs. I don't know any assembly, so I don't even know if I've included enough info.. I hope this is a small enough test case so someone can understand the issue. I've used implib on the included dll and rdmd and dmd 2.051 to compile. Asked on SO too: http://stackoverflow.com/questions/5204460/problems-convering-a-c-header-to-d
Re: C const
Simen kjaeraas Wrote: > > Hopefully I'm not wrong on this, but you should even be able to change > > the type as long as the size is the same. So instead of int you could > > use uint or byte[8]... granted the library will still interpret it as > > int. And of course that is assuming you are on a machine with a 32 bit > > int. > > And 4-bit bytes? :p Right, leave me alone I keep switching which number goes here. :)
Re: in/out with -release
On 03/04/2011 09:22 PM, Jonathan M Davis wrote: On Friday 04 March 2011 20:14:32 Kai Meyer wrote: I have an 'enforce' function call in an 'in' block for a function. When I compile with "-release -O -inline", the in/out blocks appear to be skipped. It's a simple verification for a dynamic array to not have a length of 0. In debug mode, the test condition hits the enforce in the 'in' block, but in release mode it does not. In both release and debug mode, the same exact enforce function works properly. So am I to understand that -release will skip in/out blocks entirely? Of course. It uses asserts. asserts are disabled in -release. Asserts are for debugging, testing, and verifying code when developing, not for code which is released. So, you get the benefit of the test when you don't have -release and the benefit of speed when you do have -release. If an assertion fails, your code logic is invalid. It's for validating your code, not user input or whatnot. enforce, on the other hand, is not a language primitive. It's not intended for testing or debugging. It's intended to be used in production code to throw an exception when its condition fails. If an enforce fails, that generally means that you had bad input somewhere or that an operation failed or whatnot. It's not intended for testing the logic of your code like assert is intended to do. It's simply a shorthand way to throw an exception when your program runs into a problem. - Jonathan M Davis I don't think I understand your response entirely. I understand that asserts are disabled in -release mode. I understand that enforce is a function that comes with std.exception, and the code isn't hard to follow. What I'm confused about is the in block, and why it is skipped in -release mode. You say "It uses asserts." I didn't put an assert in my in block, I put an enforce. So I'm guessing that you are indicating that the in block is treated like an assert, and is disabled with the -release flag. But I think after reading your post you've helped clarify that what I'm checking (that you can't pop an empty stack) based on user input is something I should be checking with an enforce inside the function, and not an assert or enforce inside the in block. I still think I would like it if you could be a little more explicit about the in/out blocks. Are they always disabled entirely (skipped) with -release, or just certain things? Thanks for your help! -Kai Meyer
Re: in/out with -release
On Sat, 05 Mar 2011 10:15:48 -0700, user wrote: > On 03/04/2011 09:22 PM, Jonathan M Davis wrote: >> On Friday 04 March 2011 20:14:32 Kai Meyer wrote: >>> I have an 'enforce' function call in an 'in' block for a function. >>> When I compile with "-release -O -inline", the in/out blocks appear to >>> be skipped. It's a simple verification for a dynamic array to not have >>> a length of 0. In debug mode, the test condition hits the enforce in >>> the 'in' block, but in release mode it does not. In both release and >>> debug mode, the same exact enforce function works properly. >>> >>> So am I to understand that -release will skip in/out blocks entirely? >> >> Of course. It uses asserts. asserts are disabled in -release. Asserts >> are for debugging, testing, and verifying code when developing, not for >> code which is released. So, you get the benefit of the test when you >> don't have -release and the benefit of speed when you do have -release. >> If an assertion fails, your code logic is invalid. It's for validating >> your code, not user input or whatnot. >> >> enforce, on the other hand, is not a language primitive. It's not >> intended for testing or debugging. It's intended to be used in >> production code to throw an exception when its condition fails. If an >> enforce fails, that generally means that you had bad input somewhere or >> that an operation failed or whatnot. It's not intended for testing the >> logic of your code like assert is intended to do. It's simply a >> shorthand way to throw an exception when your program runs into a >> problem. >> >> - Jonathan M Davis > > I don't think I understand your response entirely. I understand that > asserts are disabled in -release mode. I understand that enforce is a > function that comes with std.exception, and the code isn't hard to > follow. > > What I'm confused about is the in block, and why it is skipped in > -release mode. You say "It uses asserts." I didn't put an assert in my > in block, I put an enforce. So I'm guessing that you are indicating that > the in block is treated like an assert, and is disabled with the > -release flag. > > But I think after reading your post you've helped clarify that what I'm > checking (that you can't pop an empty stack) based on user input is > something I should be checking with an enforce inside the function, and > not an assert or enforce inside the in block. > > I still think I would like it if you could be a little more explicit > about the in/out blocks. Are they always disabled entirely (skipped) > with -release, or just certain things? > > Thanks for your help! > > -Kai Meyer That's right. in, out and invariant blocks are not included in release mode. -Lars
Re: in/out with -release
On Sat, 05 Mar 2011 18:12:30 +, Lars T. Kyllingstad wrote: > On Sat, 05 Mar 2011 10:15:48 -0700, user wrote: > >> On 03/04/2011 09:22 PM, Jonathan M Davis wrote: >>> On Friday 04 March 2011 20:14:32 Kai Meyer wrote: I have an 'enforce' function call in an 'in' block for a function. When I compile with "-release -O -inline", the in/out blocks appear to be skipped. It's a simple verification for a dynamic array to not have a length of 0. In debug mode, the test condition hits the enforce in the 'in' block, but in release mode it does not. In both release and debug mode, the same exact enforce function works properly. So am I to understand that -release will skip in/out blocks entirely? >>> >>> Of course. It uses asserts. asserts are disabled in -release. Asserts >>> are for debugging, testing, and verifying code when developing, not >>> for code which is released. So, you get the benefit of the test when >>> you don't have -release and the benefit of speed when you do have >>> -release. If an assertion fails, your code logic is invalid. It's for >>> validating your code, not user input or whatnot. >>> >>> enforce, on the other hand, is not a language primitive. It's not >>> intended for testing or debugging. It's intended to be used in >>> production code to throw an exception when its condition fails. If an >>> enforce fails, that generally means that you had bad input somewhere >>> or that an operation failed or whatnot. It's not intended for testing >>> the logic of your code like assert is intended to do. It's simply a >>> shorthand way to throw an exception when your program runs into a >>> problem. >>> >>> - Jonathan M Davis >> >> I don't think I understand your response entirely. I understand that >> asserts are disabled in -release mode. I understand that enforce is a >> function that comes with std.exception, and the code isn't hard to >> follow. >> >> What I'm confused about is the in block, and why it is skipped in >> -release mode. You say "It uses asserts." I didn't put an assert in my >> in block, I put an enforce. So I'm guessing that you are indicating >> that the in block is treated like an assert, and is disabled with the >> -release flag. >> >> But I think after reading your post you've helped clarify that what I'm >> checking (that you can't pop an empty stack) based on user input is >> something I should be checking with an enforce inside the function, and >> not an assert or enforce inside the in block. >> >> I still think I would like it if you could be a little more explicit >> about the in/out blocks. Are they always disabled entirely (skipped) >> with -release, or just certain things? >> >> Thanks for your help! >> >> -Kai Meyer > > That's right. in, out and invariant blocks are not included in release > mode. > > -Lars It's documented here, by the way: http://www.digitalmars.com/d/2.0/dmd-linux.html#switches (Scroll down to -release.) -Lars
Re: C const
On 3/4/2011 11:19 AM, simendsjo wrote: It also says "char const* q". Is "const char*" the same thing in C? For reference: In C, const T* x is the same as T const* x; both declare a mutable pointer to const T. T* const x declares a const pointer to mutable T, for which D has no analogue. In D, const T* x declares a const pointer to const T, which differs from the C syntax. In C, that would be const T* const x (or T const * const x). Thank God for D.
Re: htod and system files
On 3/4/2011 3:31 PM, simendsjo wrote: The htod page, http://www.digitalmars.com/d/2.0/htod.html, says that system files will be included using the -hs option. htod mysql.h -hs Fatal error: unable to open input file 'sys/types.h' Does it try to find these files through an environment variable? htod is compatible with the -I and -D compiler switches from dmc. Use -I to reference to the directory containing the system headers you want to use.
Re: htod and system files
On 05.03.2011 20:04, Bekenn wrote: On 3/4/2011 3:31 PM, simendsjo wrote: The htod page, http://www.digitalmars.com/d/2.0/htod.html, says that system files will be included using the -hs option. htod mysql.h -hs Fatal error: unable to open input file 'sys/types.h' Does it try to find these files through an environment variable? htod is compatible with the -I and -D compiler switches from dmc. Use -I to reference to the directory containing the system headers you want to use. Ah, thanks. Doesn't seem dmc is a supported compiler though.. htod -hs -Ic:\d\dm\include mysql.h my_socket fd; /* For Perl DBI/dbd */ ^ mysql_com.h(268) : Error: ';' expected following declaration of struct member my_bool net_realloc(NET *net, size_t length); ^ mysql_com.h(422) : Error: ')' expected my_bool my_net_write(NET *net,const unsigned char *packet, size_t len); ^ mysql_com.h(424) : Error: ')' expected const unsigned char *header, size_t head_len, ^ mysql_com.h(426) : Error: ')' expected int net_real_write(NET *net,const unsigned char *packet, size_t len); ^ mysql_com.h(428) : Error: ')' expected Fatal error: too many errors
Re: in/out with -release
On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote: > On 3/5/11, bearophile wrote: > > Jonathan M Davis: > >> Asserts are for > >> debugging, testing, and verifying code when developing, not for code > >> which is > >> released. > > > > If you take a look at the dmd compiler, it's released with asserts in, > > and they give all those nice error messages I put in Bugzilla :-) > > > > Bye, > > bearophile > > Hmm. Are those shown when compiling a file with -debug? Or do I need > to compile DMD itself in debug/nonrelease mode to activate those error > messages? You would need to compile dmd in debug mode if you wanted it to have assertions enabled, the same as any other C or C++ program in existence. That's the way that C/C++'s assert library works. - Jonathan M Davis
Re: in/out with -release
On Saturday 05 March 2011 13:54:08 Jonathan M Davis wrote: > On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote: > > On 3/5/11, bearophile wrote: > > > Jonathan M Davis: > > >> Asserts are for > > >> debugging, testing, and verifying code when developing, not for code > > >> which is > > >> released. > > > > > > If you take a look at the dmd compiler, it's released with asserts in, > > > and they give all those nice error messages I put in Bugzilla :-) > > > > > > Bye, > > > bearophile > > > > Hmm. Are those shown when compiling a file with -debug? Or do I need > > to compile DMD itself in debug/nonrelease mode to activate those error > > messages? > > You would need to compile dmd in debug mode if you wanted it to have > assertions enabled, the same as any other C or C++ program in existence. > That's the way that C/C++'s assert library works. Actually, I take that back. The way that C/C++'s assert library works is that assertions are compiled in if NDEBUG is _not_ defined. What the "debug" build of a project does is entirely up to the project. The concept of debug and release versions isn't really built in to the language per se. Normally, debug versions compile in the debug symbols and release versions do not, and release versions typically are set up such that they don't run unnecessary stuff which would harm efficiency (such as assertions). But _exactly_ how debug and release versions are set up depends on the project. In the case of dmd, it may be that some assertions are left in on the theory that this it's _really_ critical code and you _still_ want it to fail immediately when an assertion would have failed (whereas more typically, you'd compile out the assertions in release mode, assuming that you'd done enough testing in debug mode to find and fix all the bugs that they relate to). But to know exactly what dmd does with assertions, you'd have to look at its makefiles and possibly the code itself. - Jonathan M Davis
Re: in/out with -release
On Saturday 05 March 2011 09:15:48 user@domain.invalid wrote: > On 03/04/2011 09:22 PM, Jonathan M Davis wrote: > > On Friday 04 March 2011 20:14:32 Kai Meyer wrote: > >> I have an 'enforce' function call in an 'in' block for a function. When > >> I compile with "-release -O -inline", the in/out blocks appear to be > >> skipped. It's a simple verification for a dynamic array to not have a > >> length of 0. In debug mode, the test condition hits the enforce in the > >> 'in' block, but in release mode it does not. In both release and debug > >> mode, the same exact enforce function works properly. > >> > >> So am I to understand that -release will skip in/out blocks entirely? > > > > Of course. It uses asserts. asserts are disabled in -release. Asserts are > > for debugging, testing, and verifying code when developing, not for code > > which is released. So, you get the benefit of the test when you don't > > have -release and the benefit of speed when you do have -release. If an > > assertion fails, your code logic is invalid. It's for validating your > > code, not user input or whatnot. > > > > enforce, on the other hand, is not a language primitive. It's not > > intended for testing or debugging. It's intended to be used in > > production code to throw an exception when its condition fails. If an > > enforce fails, that generally means that you had bad input somewhere or > > that an operation failed or whatnot. It's not intended for testing the > > logic of your code like assert is intended to do. It's simply a > > shorthand way to throw an exception when your program runs into a > > problem. > > > > - Jonathan M Davis > > I don't think I understand your response entirely. I understand that > asserts are disabled in -release mode. I understand that enforce is a > function that comes with std.exception, and the code isn't hard to follow. > > What I'm confused about is the in block, and why it is skipped in > -release mode. You say "It uses asserts." I didn't put an assert in my > in block, I put an enforce. So I'm guessing that you are indicating that > the in block is treated like an assert, and is disabled with the > -release flag. > > But I think after reading your post you've helped clarify that what I'm > checking (that you can't pop an empty stack) based on user input is > something I should be checking with an enforce inside the function, and > not an assert or enforce inside the in block. > > I still think I would like it if you could be a little more explicit > about the in/out blocks. Are they always disabled entirely (skipped) > with -release, or just certain things? > > Thanks for your help! You're not really supposed to throw exceptions from in, out, or invariant blocks. You're supposed to use assertions in there. That's how the whole DbC thing is designed in D ( http://www.digitalmars.com/d/2.0/dbc.html ). So, while you _can_ throw exceptions from in, out, and invariant blocks, they _will_ be compiled out when compiling with -release. in, out, invariant just aren't intended for exceptions. - Jonathan M Davis
Release build headache: -inline
I have some kind of a middle-size project written in D2. I've been compiling always with -debug -unittest switches and, despite having to workaround two or three bugs since the beginning, I could always build everything. Now I'm ready to give release build a try, so I go with -O -release -noboundscheck -inline and get: E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): expression expected, not 'EOF' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when exp ecting ']' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ')' following template argument list E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ']' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ')' following template argument list E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ']' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ')' following template argument list E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ']' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ')' following template argument list E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ']' E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' when expecting ')' following template argument list E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): no identifier for declarator Identity!(field[Identity!(field[Identity!(field[Identity!(field[Identity!(field[0])])])])]) E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): semicolon expected, not 'EOF' If I remove -inline, it compiles, but I need performance and to track this DMD bug at this point is too damn hard. Any suggestions? :'( Sometimes I have sinful thoughts and I regret having done this in D... But now is too late. Thanks in advance, Tom;
Re: Release build headache: -inline
On Saturday 05 March 2011 15:37:15 Tom wrote: > I have some kind of a middle-size project written in D2. I've been > compiling always with -debug -unittest switches and, despite having to > workaround two or three bugs since the beginning, I could always build > everything. Now I'm ready to give release build a try, so I go with -O > -release -noboundscheck -inline and get: > > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): expression > expected, not 'EOF' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when exp ecting ']' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ')' following template argument list > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ']' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ')' following template argument list > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ']' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ')' following template argument list > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ']' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ')' following template argument list > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ']' > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF' > when expecting ')' following template argument list > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): no > identifier for declarator > Identity!(field[Identity!(field[Identity!(field[Identity!(field[Identity!(f > ield[0])])])])]) > E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): semicolon > expected, not 'EOF' > > If I remove -inline, it compiles, but I need performance and to track > this DMD bug at this point is too damn hard. Any suggestions? :'( Hmm. It looks like it's probably failing due to a bad string mixin related to a tuple - though the fact that it only happens with -inline would make it so that it's a dmd bug of some kind (regardless of how good of bad the string mixin is). It's mixing in an alias for each of the types in the tuple, and somehow, it ends up with mismatched brackets. To really debug this, it's probably going to require know _exactly_ what the tuple is that's failing. It looks like it's a tuple which holds several levels of tuples for its first type/field - something like 4 or 5 of them. Maybe it's blowing up on some kind of recursive template instantiation or something. So, if you can, _please_ find which tuple is dying. Splitting up the build so that you only build one file at a time should make it so that you can find the offending file, which should make it much easier to find the offending line. > Sometimes I have sinful thoughts and I regret having done this in D... > But now is too late. The reality of the matter is that as fantastic as D2 is, it is still in development, and you run into bugs from time to time. Usually, they're not too bad, but sometimes they can be pretty nasty. Fortunately, things have been steadily improving. Unfortunately, bugs need to be _found_ before they can be fixed, and using D for real projects helps us find bugs and make it so that you _won't_ have problems with D in real projects. I suppose that it's a bit like KDE 4.0's situation. They felt that they had to release it or the developers wouldn't port their applications to it, and it wouldn't be ready in any kind of reasonable time frame, but releasing it in the state that it was meant that they were releasing a version which really wasn't ready for general use yet. However, as applications were ported to it and brave/foolish people used it, it improved. And now, the current KDE 4 is quite solid. So, I feel for you, but at the same time, we _need_ people to be developing in D and running into the bugs in dmd, druntime, and Phobos if it's going to become fully fit for general development. - Jonathn M Davis
Re: Release build headache: -inline
El 05/03/2011 20:56, Jonathan M Davis escribió:
On Saturday 05 March 2011 15:37:15 Tom wrote:
I have some kind of a middle-size project written in D2. I've been
compiling always with -debug -unittest switches and, despite having to
workaround two or three bugs since the beginning, I could always build
everything. Now I'm ready to give release build a try, so I go with -O
-release -noboundscheck -inline and get:
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): expression
expected, not 'EOF'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when exp ecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): no
identifier for declarator
Identity!(field[Identity!(field[Identity!(field[Identity!(field[Identity!(f
ield[0])])])])])
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): semicolon
expected, not 'EOF'
If I remove -inline, it compiles, but I need performance and to track
this DMD bug at this point is too damn hard. Any suggestions? :'(
Hmm. It looks like it's probably failing due to a bad string mixin related to a
tuple - though the fact that it only happens with -inline would make it so that
it's a dmd bug of some kind (regardless of how good of bad the string mixin is).
It's mixing in an alias for each of the types in the tuple, and somehow, it ends
up with mismatched brackets. To really debug this, it's probably going to
require know _exactly_ what the tuple is that's failing. It looks like it's a
tuple which holds several levels of tuples for its first type/field - something
like 4 or 5 of them. Maybe it's blowing up on some kind of recursive template
instantiation or something.
So, if you can, _please_ find which tuple is dying. Splitting up the build so
that you only build one file at a time should make it so that you can find the
offending file, which should make it much easier to find the offending line.
Sometimes I have sinful thoughts and I regret having done this in D...
But now is too late.
The reality of the matter is that as fantastic as D2 is, it is still in
development, and you run into bugs from time to time. Usually, they're not too
bad, but sometimes they can be pretty nasty. Fortunately, things have been
steadily improving. Unfortunately, bugs need to be _found_ before they can be
fixed, and using D for real projects helps us find bugs and make it so that you
_won't_ have problems with D in real projects.
I suppose that it's a bit like KDE 4.0's situation. They felt that they had to
release it or the developers wouldn't port their applications to it, and it
wouldn't be ready in any kind of reasonable time frame, but releasing it in the
state that it was meant that they were releasing a version which really wasn't
ready for general use yet. However, as applications were ported to it and
brave/foolish people used it, it improved. And now, the current KDE 4 is quite
solid.
So, I feel for you, but at the same time, we _need_ people to be developing in D
and running into the bugs in dmd, druntime, and Phobos if it's going to become
fully fit for general development.
- Jonathn M Davis
Well, I did what you suggested with success (thanks).
Minimal test case:
import std.stdio;
import std.conv;
int main(string[] args) {
int[string] t;
writeln(text(t));
return 0;
}
Tried:
dmd -O -release -inline -noboundscheck -c -Isrc src\main.d -> ERROR
dmd-release -inline -noboundscheck -c -Isrc src\main.d -> ERROR
dmd -O -inline -noboundscheck -c -Isrc src\main.d -> OK
dmd -O -release -noboundscheck -c -Isrc src\main.d -> OK
dmd -O -release -inline-c -Isrc src\main.d -> OK
Where ERROR is:
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): expression
expected, not 'EOF'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ']'
E:\d\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(364): found 'EOF'
when expecting ')' following template argument list
E:\d\dmd2\win
Re: Release build headache: -inline
On Saturday 05 March 2011 16:40:02 Tom wrote: > Well, I did what you suggested with success (thanks). Okay. I created a bug report for it: http://d.puremagic.com/issues/show_bug.cgi?id=5708 In the meantime, I would suggest that you simply not compile with - noboundscheck. It's likely that it rarely does anything for you anyway. It disables array bounds checking in @safe code, and precious little in Phobos is marked as @safe at this point, so unless you're marking _your_ code with @safe, most of it is likely @system (since that's the default), and so the - noboundscheck doesn't actually do anything for you. Array bounds checking is already removed for @system and @trusted functions with -release. - Jonathan M Davis
Re: Release build headache: -inline
El 05/03/2011 22:05, Jonathan M Davis escribió: On Saturday 05 March 2011 16:40:02 Tom wrote: Well, I did what you suggested with success (thanks). Okay. I created a bug report for it: http://d.puremagic.com/issues/show_bug.cgi?id=5708 In the meantime, I would suggest that you simply not compile with - noboundscheck. It's likely that it rarely does anything for you anyway. It disables array bounds checking in @safe code, and precious little in Phobos is marked as @safe at this point, so unless you're marking _your_ code with @safe, most of it is likely @system (since that's the default), and so the - noboundscheck doesn't actually do anything for you. Array bounds checking is already removed for @system and @trusted functions with -release. - Jonathan M Davis Very well. Thanks. Tom;
Why is it necessary to use synchronized functions when passing shared variables?
Greetings
Why is it necessary to use synchronized functions when passing shared
variables? I get error even when I am not modifying the shared variable in
the function.
Kindly look at the following code. I get a compile error unless I declare
the functions parent and root synchronized.
The compile error says:
test.d(13): Error: function test.HierObject.root () const is not callable
using argument types () shared const
Thanks and Regards
- Puneet
// Reduced Code
import std.exception;
// synchronized // Compiles without error when uncommented
class HierObject {
private shared HierObject _root;
private shared HierObject _parent;
shared(const(HierObject)) root() const {
if(_root) return _root;
else {
enforce(_parent,
"HierObject Instance does not have a parent!");
return this.parent().root();
}
}
shared(const(HierObject)) parent() const {
enforce(_parent);
return _parent;
}
}
Re: Template type parameters with their own type parameters
== Quote from spir (denis.s...@gmail.com)'s article
> On 03/05/2011 04:02 AM, Peter Lundgren wrote:
> > I have a function that I think should look something like this:
> >
> > MyStruct!T myFunc(T)(MyStruct!T x, ...) {
> > ...
> > return MyStruct!T(...);
> > }
> >
> > and the closest I can get to is:
> >
> > T myFunc(T)(T x, ...) {
> > ...
> > return T(...);
> > }
> >
> > which works, but doesn't make clear the intended use and gets in the way of
> > overloading. How can I express the intent of the first version.
> Maybe I do not exactly understand your problem; anyway, the following runs
> fine
> by me:
> struct S (T) {
> T v;
> }
> S!T inc (T) (S!T s) {
> return S!T(s.v + 1);
> }
> unittest {
> auto s1 = S!int(1);
> auto s2 = inc(s1);
> assert ( s2.v == 2 );
> }
> Could you provide (1) context (2) example (3) errors?
> Denis
Thanks for the help. I'd convinced myself that it didn't work and missed the
actual problem. I was mixing template type and template value parameters. What I
really wanted was this:
MyStruct!v myFunc(string v)(MyStruct!v x, ...) {
...
return MyStruct!v(...);
}
Re: Why is it necessary to use synchronized functions when passing shared variables?
On Saturday 05 March 2011 20:00:07 d coder wrote:
> Greetings
>
> Why is it necessary to use synchronized functions when passing shared
> variables? I get error even when I am not modifying the shared variable in
> the function.
> Kindly look at the following code. I get a compile error unless I declare
> the functions parent and root synchronized.
>
> The compile error says:
> test.d(13): Error: function test.HierObject.root () const is not callable
> using argument types () shared const
>
> Thanks and Regards
> - Puneet
>
> // Reduced Code
> import std.exception;
>
> // synchronized // Compiles without error when uncommented
> class HierObject {
> private shared HierObject _root;
> private shared HierObject _parent;
>
> shared(const(HierObject)) root() const {
> if(_root) return _root;
> else {
> enforce(_parent,
> "HierObject Instance does not have a parent!");
> return this.parent().root();
> }
> }
>
> shared(const(HierObject)) parent() const {
> enforce(_parent);
> return _parent;
> }
> }
It's probably complaining because using shared without synchronizing is
generally very foolish. Now, I would have _thought_ that it would still work
without, but I apparently not. Regardless, I'm not sure why you'd want to use
shared anything without synchronizing your access of it. Not synchronizing your
access of shared variables is pretty much guaranteeing a race condition unless
you're only accessing them from a single thread, in which case, there's no
reason for them to be shared in the first place.
- Jonathan M Davis
Re: Why is it necessary to use synchronized functions when passing shared variables?
> > > It's probably complaining because using shared without synchronizing is > generally very foolish. Now, I would have _thought_ that it would still > work > without, but I apparently not. Regardless, I'm not sure why you'd want to > use > shared anything without synchronizing your access of it. Thanks Jonathan Actually in my actual use case, I am using synchronized at code block level -- to limit the scope of locking. I am doing this to mitigate possible inefficiency due to indiscriminate use of mutex locked code. But D is forcing me to synchronize at function level, thus making most of my code go under mutex locks. Regards - Puneet
