Problem compiling Mac VM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem compiling Mac VM

Mariano Martinez Peck
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Mariano Martinez Peck
 
Sorry here I attach.

On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck <[hidden email]> 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


Picture 5.png (187K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Eliot Miranda-2
 
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 <[hidden email]> wrote:
 
Sorry here I attach.

On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Eliot Miranda-2
 


On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda <[hidden email]> 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:

/* 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 <[hidden email]> wrote:
 
Sorry here I attach.

On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Mariano Martinez Peck
 


On Thu, Apr 29, 2010 at 7:13 PM, Eliot Miranda <[hidden email]> wrote:
 


On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda <[hidden email]> 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 ?

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 <[hidden email]> wrote:
 
Sorry here I attach.

On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Igor Stasenko

On 29 April 2010 21:59, Mariano Martinez Peck <[hidden email]> wrote:

>
>
>
> On Thu, Apr 29, 2010 at 7:13 PM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>> On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>> Sorry here I attach.
>>>>
>>>> On Thu, Apr 29, 2010 at 3:16 PM, Mariano Martinez Peck <[hidden email]> 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
>>>>
>>>>
>>>
>>
>>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

David T. Lewis
In reply to this post by Mariano Martinez Peck
 
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 <[hidden email]>wrote:
> >
> > On Thu, Apr 29, 2010 at 10:07 AM, Eliot Miranda <[hidden email]>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 ?

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

Mariano Martinez Peck
 


On Fri, Apr 30, 2010 at 2:12 PM, David T. Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Problem compiling Mac VM

johnmci
In reply to this post by David T. Lewis
 

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 <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





smime.p7s (3K) Download Attachment