On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease doesn't make sense because they are aprox. 12 implementaions...I don't want to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things? I have no idea.
The same with class comments. There are so many classes that copy pasting or documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
debugVMFlagEnable: boolean
"THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
I modified the StackInterpreter to this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr.
.....
and only 'grrr' is printed. The TWO previous assert are ignored.
I may be doing something very stupid...
thanks in advance,
Mariano
On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko siguctua@gmail.com wrote:
On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease doesn't make sense because they are aprox. 12 implementaions...I don't
want
to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things? I have no idea.
The same with class comments. There are so many classes that copy pasting
or
documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
debugVMFlagEnable: boolean
"THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
-- Best regards, Igor Stasenko AKA sig.
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
If first stands for 'no-debug' and second stands for 'debug vm'..
I modified the StackInterpreter to this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr.
.....
and only 'grrr' is printed. The TWO previous assert are ignored.
I may be doing something very stupid...
thanks in advance,
Mariano
On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko siguctua@gmail.com wrote:
On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease doesn't make sense because they are aprox. 12 implementaions...I don't want to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things? I have no idea.
The same with class comments. There are so many classes that copy pasting or documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
debugVMFlagEnable: boolean
"THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not
working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3
-funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs.
I said all this last week. Please take note this time :)
best, Eliot
If first stands for 'no-debug' and second stands for 'debug vm'..
I modified the StackInterpreter to this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr.
.....
and only 'grrr' is printed. The TWO previous assert are ignored.
I may be doing something very stupid...
thanks in advance,
Mariano
On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko siguctua@gmail.com
wrote:
On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com
wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or
#compilerFlagsRelease
doesn't make sense because they are aprox. 12 implementaions...I don't
want
to copy paste to all of them. Only in one? it doesn't make sense
because
people won't see it. So..how we document this kind of things? I have
no
idea.
The same with class comments. There are so many classes that copy
pasting or
documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops'
'-fasm-blocks'
'-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16'
'-fno-gcse'
'-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
debugVMFlagEnable: boolean
"THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko AKA sig.
On 26 April 2011 04:03, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues. DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs. I said all this last week. Please take note this time :)
But hey, i insist that they are mutually exclusive. See, if i want to build a debug version of VM, i should use -DDEBUGVM=1 but should not use -DNDEBUG because otherwise all assertions will be suppressed, which is not what i would want in debug version of VM.
AFAIK, windows also using NDEBUG, but my main comment was about that it is used wrongly.
The check
if defined(NDEBUG)
will always pass whether you use -DNDEBUG=1 or -DNDEBUG=0
because it checks if given symbol are defined, it doesn't cares about its value!!!
So, a proper use would be to either omit -DNDEBUG at all, or include it. But not like currently, changing its value between 0 or 1.
Here the code from assert.h:
#ifdef NDEBUG #define assert(e) ((void)0) #else ....
And here the sample code for testing it:
cat a.c
#include <stdio.h>
int main() {
#ifdef NDEBUG printf ("NDEBUG defined\n"); #endif
return 0;
}
Now see what happens:
gcc a.c ./a.out <no output>
gcc -DNDEBUG=0 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=ZORK a.c ./a.out NDEBUG defined
best, Eliot
If first stands for 'no-debug' and second stands for 'debug vm'..
I modified the StackInterpreter to this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr.
.....
and only 'grrr' is printed. The TWO previous assert are ignored.
I may be doing something very stupid...
thanks in advance,
Mariano
On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko siguctua@gmail.com wrote:
On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease doesn't make sense because they are aprox. 12 implementaions...I don't want to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things? I have no idea.
The same with class comments. There are so many classes that copy pasting or documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>debugVMFlagEnable: boolean
"THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko AKA sig.
On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 04:03, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com
wrote:
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com
wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not
working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3
-funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for
enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
DEBUGVM includes some extra code that allows break-pointing jumping from
the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs.
I said all this last week. Please take note this time :)
But hey, i insist that they are mutually exclusive.
You can insist all you like but you're wrong. NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive.
See, if i want to build a debug version of VM, i should use -DDEBUGVM=1 but should not use -DNDEBUG because otherwise all assertions will be suppressed, which is not what i would want in debug version of VM.
AFAIK, windows also using NDEBUG, but my main comment was about that it is used wrongly.
The check
if defined(NDEBUG)
will always pass whether you use -DNDEBUG=1 or -DNDEBUG=0
because it checks if given symbol are defined, it doesn't cares about its value!!!
So, a proper use would be to either omit -DNDEBUG at all, or include it. But not like currently, changing its value between 0 or 1.
Here the code from assert.h:
#ifdef NDEBUG #define assert(e) ((void)0) #else ....
And here the sample code for testing it:
cat a.c
#include <stdio.h>
int main() {
#ifdef NDEBUG printf ("NDEBUG defined\n"); #endif
return 0;
}
Now see what happens:
gcc a.c ./a.out
<no output>
gcc -DNDEBUG=0 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined
gcc -DNDEBUG=ZORK a.c ./a.out NDEBUG defined
best, Eliot
If first stands for 'no-debug' and second stands for 'debug vm'..
I modified the StackInterpreter to this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr.
.....
and only 'grrr' is printed. The TWO previous assert are ignored.
I may be doing something very stupid...
thanks in advance,
Mariano
On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko siguctua@gmail.com
wrote:
On 13 April 2011 19:13, Mariano Martinez Peck marianopeck@gmail.com
wrote:
I've just commited the fix, but not the comment ;)
Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or
#compilerFlagsRelease
doesn't make sense because they are aprox. 12 implementaions...I
don't want
to copy paste to all of them. Only in one? it doesn't make sense
because
people won't see it. So..how we document this kind of things? I
have no
idea.
The same with class comments. There are so many classes that copy
pasting or
documenting only one doesn't make sense.
The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'.
The only thing I though is doing something like this:
compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops'
'-fasm-blocks'
'-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16'
'-fno-gcse'
'-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H'
'-DHAVE_NANOSLEEP'
'-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>>debugVMFlagEnable: boolean "THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString
or something like that...
This knowledge is important. It of course a question where to put
that,
but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off..
So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why.
cheers
Mariano
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 26 April 2011 19:01, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 04:03, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues. DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs. I said all this last week. Please take note this time :)
But hey, i insist that they are mutually exclusive.
You can insist all you like but you're wrong. NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive.
Eliot, i understand this stuff. Now you taking my words too literally. I meant to say that for existing cmake configurations they should be mutually exclusive.
But for current variants for release we should have: a) turn debugging off (-DDEBUGVM=0) b) suppress assertions (-DNDEBUG)
and when building VM for debugging we doing otherwise: - turn all debugging on (-DDEBUGVM=1) - enable assertions (omit defining -DNDEBUG)
so in the above two configurations its easy to see that these two options are mutually exclusive.
And of course, in case of need, one can create configuration where you can use different combination of these two flags, but the above two is most logical choice for release and debug versions of VM configs.
On Tue, Apr 26, 2011 at 10:29 AM, Igor Stasenko siguctua@gmail.com wrote:
On 26 April 2011 19:01, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko siguctua@gmail.com
wrote:
On 26 April 2011 04:03, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com
wrote:
On 26 April 2011 03:05, Mariano Martinez Peck marianopeck@gmail.com
wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not
working. I can see the flags are being set correct in CmakeList.txt:
add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3
-funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for
enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
DEBUGVM includes some extra code that allows break-pointing jumping
from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs.
I said all this last week. Please take note this time :)
But hey, i insist that they are mutually exclusive.
You can insist all you like but you're wrong. NDEBUG controls assertions
and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive.
Eliot, i understand this stuff. Now you taking my words too literally. I meant to say that for existing cmake configurations they should be mutually exclusive.
Ah, agreed :) Sorry :)
But for current variants for release we should have: a) turn debugging off (-DDEBUGVM=0) b) suppress assertions (-DNDEBUG)
and when building VM for debugging we doing otherwise:
- turn all debugging on (-DDEBUGVM=1)
- enable assertions (omit defining -DNDEBUG)
so in the above two configurations its easy to see that these two options are mutually exclusive.
And of course, in case of need, one can create configuration where you can use different combination of these two flags, but the above two is most logical choice for release and debug versions of VM configs.
-- Best regards, Igor Stasenko AKA sig.
On Tue, Apr 26, 2011 at 7:40 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Tue, Apr 26, 2011 at 10:29 AM, Igor Stasenko siguctua@gmail.comwrote:
On 26 April 2011 19:01, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko siguctua@gmail.com
wrote:
On 26 April 2011 04:03, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko siguctua@gmail.com
wrote:
On 26 April 2011 03:05, Mariano Martinez Peck <
marianopeck@gmail.com> wrote:
> > Hi guys. I don't know why but with CMakeVMMaker the asserts are
not working. I can see the flags are being set correct in CmakeList.txt:
> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0
-msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>
AFAIK, code checks
#ifdef NDEBUG
which means 'if defined NDEBUG'
and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value.
Also, NDEBUG and DEBUGVM should be mutually exclusive?
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for
enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
DEBUGVM includes some extra code that allows break-pointing jumping
from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs.
I said all this last week. Please take note this time :)
But hey, i insist that they are mutually exclusive.
You can insist all you like but you're wrong. NDEBUG controls
assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive.
Eliot, i understand this stuff. Now you taking my words too literally. I meant to say that for existing cmake configurations they should be mutually exclusive.
Ah, agreed :) Sorry :)
But for current variants for release we should have: a) turn debugging off (-DDEBUGVM=0) b) suppress assertions (-DNDEBUG)
and when building VM for debugging we doing otherwise:
- turn all debugging on (-DDEBUGVM=1)
- enable assertions (omit defining -DNDEBUG)
Yes, exactly. Finally I understood. So...I will commit the fix becuase now CMake confs are wrong.
Cheers
Mariano
so in the above two configurations its easy to see that these two
options are mutually exclusive.
And of course, in case of need, one can create configuration where you can use different combination of these two flags, but the above two is most logical choice for release and debug versions of VM configs.
-- Best regards, Igor Stasenko AKA sig.
Hi Mariano:
On 26 Apr 2011, at 02:05, Mariano Martinez Peck wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt:
-DNDEBUG=1
I think Igor and Eliot already answered the question, but since nobody pointed you at this document, I will do it. Might help for future questions:
http://linux.die.net/man/3/assert
Best regards Stefan
On Tue, Apr 26, 2011 at 7:56 AM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Mariano:
On 26 Apr 2011, at 02:05, Mariano Martinez Peck wrote:
Hi guys. I don't know why but with CMakeVMMaker the asserts are not
working. I can see the flags are being set correct in CmakeList.txt:
-DNDEBUG=1
I think Igor and Eliot already answered the question,
Hi Stefan. No, they didn't answer, or yes, they answer but I am so newbie that I don't see it. My question was why I didn't see in the gdb console those outputs of those asserts. If I am compiling with -DNDEBUG=1 I expect the asserts() to be evaluating. And even more, asserta() seems to evaluates always. So...why if I did this:
lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr. .....
and compile the vm and I fire up an iamge...why only 'grrr' is printed ?? The TWO previous assert are ignored, even the asserta()
If this was answered I thanks someone that could explain it again for me :)
thanks in advance
Mariano
but since nobody pointed you at this document, I will do it. Might help for future questions:
http://linux.die.net/man/3/assert
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Mariano:
On 26 Apr 2011, at 09:53, Mariano Martinez Peck wrote:
If I am compiling with -DNDEBUG=1 I expect the asserts() to be evaluating.
NDEBUG is a short form for NO debug, I suppose. Let me cite the manpage:
If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all. <<
Thus, -DNDEBUG=0 and -DNDEBUG=1, as well as -DNDEBUG=foo have all the same effect: NO DEBUG, no assertions.
And even more, asserta() seems to evaluates always.
I don't know asserta(), I suppose it is `assert always`? The only thing I can tell you here is, that you probably need to refer to its implementation.
Best regards Stefan
On Tue, Apr 26, 2011 at 10:18 AM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Mariano:
On 26 Apr 2011, at 09:53, Mariano Martinez Peck wrote:
If I am compiling with -DNDEBUG=1 I expect the asserts() to be
evaluating. NDEBUG is a short form for NO debug, I suppose. Let me cite the manpage:
If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all. <<
Thus, -DNDEBUG=0 and -DNDEBUG=1, as well as -DNDEBUG=foo have all the same effect: NO DEBUG, no assertions.
Thanks Stefan. In fact, you were right. If I DO NOT define DNDEBUG, assertions. If I define it (with whatever value), no assertions. Now, I think that I was to naive to understand Eliot's first answer:
" NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts. To get asserts working in Cog it was easiest to use this flag. So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning). See platforms/Cross/vm/sqAssert.h. Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs. "
So..I should have NOT understood them literal "Hence NDEBUG=0 for production and NDEBUG=1 for debug" but instead that for debug I DO NOT have to define NDEBUG but I do for production ?
And even more, when Igor said "and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value." he was correct.
And even more, asserta() seems to evaluates always.
I don't know asserta(), I suppose it is `assert always`? The only thing I can tell you here is, that you probably need to refer to its implementation.
yes
Thanks Stefan
Mariano
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
vm-dev@lists.squeakfoundation.org