Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
Sorry here I attach.
On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
error was recently moved out of VMMaker (interp.c) and into the support code. You need to update the svn side of things.
On Thu, Apr 29, 2010 at 6:18 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Sorry here I attach.
On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
error was recently moved out of VMMaker (interp.c) and into the support code. You need to update the svn side of things.
I see a definition of error in platforms/win32/vm/sqWin32Intel.c but none in platforms/Mac OS/vm/sqMacMain.c or platforms/unix/vm/sqUnixMain.c. Something like this should serve:
/* Print an error message, possibly a stack trace, and exit. */ /* Disable Intel compiler inlining of error which is used for breakpoints */ #pragma auto_inline off void error(char *msg) { /* flag prevents recursive error when trying to print a broken stack */ static sqInt printingStack = false;
printf("\n%s\n\n", msg); abort(); } #pragma auto_inline on
HTH
On Thu, Apr 29, 2010 at 6:18 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Sorry here I attach.
On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
On Thu, Apr 29, 2010 at 7:13 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
error was recently moved out of VMMaker (interp.c) and into the support code. You need to update the svn side of things.
I see a definition of error in platforms/win32/vm/sqWin32Intel.c but none in platforms/Mac OS/vm/sqMacMain.c or platforms/unix/vm/sqUnixMain.c. Something like this should serve:
Thanks Eliot. Indeed, that worked. Or at least, I could compile, link and run an image. Now I wonder how this kind of changes (those changes to VMMaker that require changes in all platform code support) are managed and synchronized so that to avoid this kind of problems.
Is there a procedure for this ?
Cheers
Mariano
/* Print an error message, possibly a stack trace, and exit. */ /* Disable Intel compiler inlining of error which is used for breakpoints */ #pragma auto_inline off void error(char *msg) { /* flag prevents recursive error when trying to print a broken stack */ static sqInt printingStack = false;
printf("\n%s\n\n", msg); abort();} #pragma auto_inline on
HTH
On Thu, Apr 29, 2010 at 6:18 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Sorry here I attach.
On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
On 29 April 2010 21:59, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Thu, Apr 29, 2010 at 7:13 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
error was recently moved out of VMMaker (interp.c) and into the support code. You need to update the svn side of things.
I see a definition of error in platforms/win32/vm/sqWin32Intel.c but none in platforms/Mac OS/vm/sqMacMain.c or platforms/unix/vm/sqUnixMain.c. Something like this should serve:
Thanks Eliot. Indeed, that worked. Or at least, I could compile, link and run an image. Now I wonder how this kind of changes (those changes to VMMaker that require changes in all platform code support) are managed and synchronized so that to avoid this kind of problems.
Is there a procedure for this ?
I think, if we could have a build farm, which will build VMs for all major platforms and checks that build are successfull, then at least compile-time errors fixes can be managed much more quickly.
Cheers
Mariano
/* Print an error message, possibly a stack trace, and exit. */ /* Disable Intel compiler inlining of error which is used for breakpoints */ #pragma auto_inline off void error(char *msg) { /* flag prevents recursive error when trying to print a broken stack */ static sqInt printingStack = false; printf("\n%s\n\n", msg); abort(); } #pragma auto_inline on
HTH
On Thu, Apr 29, 2010 at 6:18 AM, Mariano Martinez Peck marianopeck@gmail.com wrote:
Sorry here I attach.
On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi folks. I am trying to compile a Mac VM with the latest versions of VMMaker and SVN. However, when linking in XCode, I have an error.
Sorry I cannot tell you more. I have no idea. I attach an screenshot with the error.
Thanks for any help.
Mariano
On Thu, Apr 29, 2010 at 08:59:45PM +0200, Mariano Martinez Peck wrote:
On Thu, Apr 29, 2010 at 7:13 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
error was recently moved out of VMMaker (interp.c) and into the support code. You need to update the svn side of things.
I see a definition of error in platforms/win32/vm/sqWin32Intel.c but none in platforms/Mac OS/vm/sqMacMain.c or platforms/unix/vm/sqUnixMain.c. Something like this should serve:
Thanks Eliot. Indeed, that worked. Or at least, I could compile, link and run an image. Now I wonder how this kind of changes (those changes to VMMaker that require changes in all platform code support) are managed and synchronized so that to avoid this kind of problems.
Is there a procedure for this ?
Mariano,
I don't know that there is any simple answer to this, but to take the error() function as a specific example, here is how it was handled:
- The error() function was originally implemented in code that was genererated by VMMaker. Someone pointed out (on the vm-dev list) that this was a bad idea.
- We renamed the original error() implementation as defaultErrorProc(), which is now generated by CCodeGenerator>>emitCHeaderOn:
- We used a CPP macro for error (see CCodeGenerator>>emitDefaultMacrosOn:). If the macro is not defined then error is defined as defaultErrorProc, which is the original implementation.
- If the platform code provides its own implementation of error(), it defines the error macro to point to it. Typically this may be done in the config.h header.
The end result is that the new version of VMMaker generated code will use the implementation of error() that is provided by the platforms sources if possible, but if this is not available it uses the original implementation in defaultErrorProc. If the platform code does not provide an error() function, then everything works it did before the change.
I suspect that you have discovered some combination of platform sources, configuration files, etc that breaks this, but the intent was to make the change in such a way as to provide backward compatibility even if all of the various platform sources were not updated immediately.
Dave
On 4/29/2010 8:51 PM, David T. Lewis wrote:
I suspect that you have discovered some combination of platform sources, configuration files, etc that breaks this, but the intent was to make the change in such a way as to provide backward compatibility even if all of the various platform sources were not updated immediately.
And to be honest, I think that's a mistake. It leads people to implementing protocols only partially. For example, I hadn't even noticed that John added ioMicroseconds(). If the compile had generated an error, I would have fixed it and moved on. The way it's now we shipped 4.0.1 with a broken microseconds clock. I don't like that.
It is the nature of people working asynchronously and at different schedules that there may not be consistency about what the status for head is in each platform. Compile errors point out what you're still missing, that's their purpose. If you run head, you run the risk that something's still missing. If you need something stable, we have tags, we have file releases, use those. The latest head may or may not be functioning. If it doesn't you can help fix and improve it.
Head is the bleeding edge of development, why would anyone expect that to work flawlessly and why should we try to pretend that?
Cheers, - Andreas
On Thu, Apr 29, 2010 at 09:11:55PM -0700, Andreas Raab wrote:
On 4/29/2010 8:51 PM, David T. Lewis wrote:
I suspect that you have discovered some combination of platform sources, configuration files, etc that breaks this, but the intent was to make the change in such a way as to provide backward compatibility even if all of the various platform sources were not updated immediately.
And to be honest, I think that's a mistake. It leads people to implementing protocols only partially. For example, I hadn't even noticed that John added ioMicroseconds(). If the compile had generated an error, I would have fixed it and moved on. The way it's now we shipped 4.0.1 with a broken microseconds clock. I don't like that.
I see your point. From my point of view, it's nice to be able to add support for something that one person needs (e.g. microsecond timers) without requiring agreement from everyone else. And to some extent I'm trying to avoid the inevitable "I just loaded the latest VMMaker and now I can't compile a VM" questions. But perhaps this causes more problems than it solves.
This thread ("Problem compiling Mac VM") seems to be a good example of the point you are making. I wonder what John and Ian think?
Dave
On Fri, Apr 30, 2010 at 2:12 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Apr 29, 2010 at 09:11:55PM -0700, Andreas Raab wrote:
On 4/29/2010 8:51 PM, David T. Lewis wrote:
I suspect that you have discovered some combination of platform sources, configuration files, etc that breaks this, but the intent was to make the change in such a way as to provide backward
compatibility
even if all of the various platform sources were not updated
immediately.
And to be honest, I think that's a mistake. It leads people to implementing protocols only partially. For example, I hadn't even noticed that John added ioMicroseconds(). If the compile had generated an error, I would have fixed it and moved on. The way it's now we shipped 4.0.1 with a broken microseconds clock. I don't like that.
I see your point. From my point of view, it's nice to be able to add support for something that one person needs (e.g. microsecond timers) without requiring agreement from everyone else. And to some extent I'm trying to avoid the inevitable "I just loaded the latest VMMaker and now I can't compile a VM" questions.
Actually I don't want to download and compile the latest VMMaker code. I just needed to migrate my code to a new image, and try to load VMMaker again (not even the last) but the same metacello version than before. There I had a problem because B3DAcceleratorPlugin was removed from Ballon and put in some other place (I think VMMaker). Then, I didn't know how to change my C code that I had download from SVN to adapt it (it was failing as I didn't have the c code of such plugin). Thus, I had to download the latest code.
Thanks
Mariano
But perhaps this causes more problems than it solves.
This thread ("Problem compiling Mac VM") seems to be a good example of the point you are making. I wonder what John and Ian think?
Dave
On 2010-04-30, at 5:12 AM, David T. Lewis wrote:
This thread ("Problem compiling Mac VM") seems to be a good example of the point you are making. I wonder what John and Ian think?
Dave
Well the microsecond timer was announced to the dev list in early january, discussed by some people altered, then pushed as a commit (again email) April 1st. etc etc. Some parties claim they missed the activity.
However this goes all the way back to Ken Beck's discussion of having a publicly visible SUnit test machine that flags when a person sticks something into the production queue as being faulty.
In this case I'd agree having a server farm to run the platform compiles to ensure everything compiles after changes to SVN or to VMMaker would make sense. Sometimes It's difficult to determine if a change will impact other platforms.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
John M McIntosh -
Mariano Martinez Peck