I've just create it: StackInterpreterMacOSConfig subclass: #StackInterpreterDebugMacOSConfig instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMaker' And implemented: StackInterpreterDebugMacOSConfig >> compilerFlags ^ self commonCompilerFlags, ' ' ,self compilerFlagsDebug Is this correct ? I would like to complelty debug with XCode out of the box. Thanks Mariano |
On 16 March 2011 16:58, Mariano Martinez Peck <[hidden email]> wrote: > > I've just create it: > > StackInterpreterMacOSConfig subclass: #StackInterpreterDebugMacOSConfig > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'CMakeVMMaker' > > And implemented: > > StackInterpreterDebugMacOSConfig >> compilerFlags > > ^ self commonCompilerFlags, ' ' ,self compilerFlagsDebug > > > > Is this correct ? I would like to complelty debug with XCode out of the box. > It you can build VM using this config, and it satisfies your needs (debug flags etc), then it is correct. :) Once you verify, just send me .cs and i will include it. > Thanks > > Mariano > > -- Best regards, Igor Stasenko AKA sig. |
On Wed, Mar 16, 2011 at 5:11 PM, Igor Stasenko <[hidden email]> wrote:
The problem is that I am not sure if it is really correct. I put a breakpoint in lookupMethodInClass(sqInt class). When I enter the XCode debugger, and see the srtacktrace, I go down to the caller: interpret() and instead of seeing the place inside interpret() where the call to lookupMethodInClass() is done, the XCode goes to this place: /* This doesn't belong here, but neither do 'self flag: ...'s belong in the image. */ #ifdef _MSC_VER static void flag(char *ignored) {} #else <---------------- HERE static inline void flag(char *ignored) {} #endif This seems to be from sqMemoryAccess.h Any help? thanks mariano Once you verify, just send me .cs and i will include it. |
On 16 March 2011 17:16, Mariano Martinez Peck <[hidden email]> wrote: > > > On Wed, Mar 16, 2011 at 5:11 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 16 March 2011 16:58, Mariano Martinez Peck <[hidden email]> >> wrote: >> > >> > I've just create it: >> > >> > StackInterpreterMacOSConfig subclass: #StackInterpreterDebugMacOSConfig >> > instanceVariableNames: '' >> > classVariableNames: '' >> > poolDictionaries: '' >> > category: 'CMakeVMMaker' >> > >> > And implemented: >> > >> > StackInterpreterDebugMacOSConfig >> compilerFlags >> > >> > ^ self commonCompilerFlags, ' ' ,self compilerFlagsDebug >> > >> > >> > >> > Is this correct ? I would like to complelty debug with XCode out of the >> > box. >> > >> >> It you can build VM using this config, and it satisfies your needs >> (debug flags etc), then it is correct. :) >> > > The problem is that I am not sure if it is really correct. I put a > breakpoint in lookupMethodInClass(sqInt class). > When I enter the XCode debugger, and see the srtacktrace, I go down to the > caller: interpret() > and instead of seeing the place inside interpret() where the call to > lookupMethodInClass() is done, the XCode goes to this place: > > > /* This doesn't belong here, but neither do 'self flag: ...'s belong in the > image. */ > > #ifdef _MSC_VER > static void flag(char *ignored) {} > #else <---------------- HERE > static inline void flag(char *ignored) {} > #endif > > > This seems to be from sqMemoryAccess.h > > Any help? > Wipe everything in /src /build dirs and use <YourConfig> generateWithSources see if it can help > thanks > > mariano > >> Once you verify, just send me .cs and i will include it. >> >> >> > Thanks >> > >> > Mariano >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > -- Best regards, Igor Stasenko AKA sig. |
I don't have commit access to VMMaker, so I attach de mcz Name: CMakeVMMaker-MarianoMartinezPeck.57 Author: MarianoMartinezPeck Time: 1 April 2011, 2:53:25 pm UUID: 4fc51c2f-d626-439d-869d-b1bd60c23a89 Ancestors: CMakeVMMaker-MarianoMartinezPeck.56 New classes CogDebugMacOSConfig and StackInterpreterDebugMacOSConfig that implements #compilerFlags so that to answer the debug ones. Anyway...I don't like a new class just for implementing #compilerFlags ^ self compilerFlagsDebug. I would prefer use the same class and do: CogMacOSConfig generateForDebugWithSources Cheers Mariano On Wed, Mar 16, 2011 at 5:35 PM, Igor Stasenko <[hidden email]> wrote:
CMakeVMMaker-MarianoMartinezPeck.57.mcz (92K) Download Attachment |
On 1 April 2011 14:55, Mariano Martinez Peck <[hidden email]> wrote: > I don't have commit access to VMMaker, so I attach de mcz > > Name: CMakeVMMaker-MarianoMartinezPeck.57 > Author: MarianoMartinezPeck > Time: 1 April 2011, 2:53:25 pm > UUID: 4fc51c2f-d626-439d-869d-b1bd60c23a89 > Ancestors: CMakeVMMaker-MarianoMartinezPeck.56 > > New classes CogDebugMacOSConfig and StackInterpreterDebugMacOSConfig > that implements #compilerFlags > so that to answer the debug ones. > > > > Anyway...I don't like a new class just for implementing #compilerFlags ^ > self compilerFlagsDebug. > > I would prefer use the same class and do: CogMacOSConfig > generateForDebugWithSources > There is a zillions of various options which you can play with and get VM built with it. The problem is, that then you will have all those generateWithFooButWithoutBar and it will get messy quite fast. I wanted to do like that originally, but were driven in right direction by Esteban, who proposed to use separate class(es) for each concrete configuration we well be using. Because in this way it defines a configuration which works out of the box, and you don't need additional knowledge (what options you can set, or what special selectors to run it etc etc). Classes are cheap. And this package is service package anyways, so who cares if there will be hundreds of configs :) After all, people are free to create own modifications of configuration(s) through subclassing. And it proves to be quite simple, because when you starting from already working configuration, and just modify some bits here and there, and quite easily you got another working configuration. But if you explode config with various options, then subclasses have to support them too.. but the problem is that they could come into conflict with each other, and moreover, people will be obliged to discover & test building them all. > Cheers > > Mariano > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |