Smalltalk › Squeak › Squeak VM

Problem compiling Mac VM

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Mariano Martinez Peck

Problem compiling Mac VM

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

Mariano Martinez Peck

Re: Problem compiling Mac VM

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

Eliot Miranda-2

Re: Problem compiling Mac VM

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

Eliot Miranda-2

Re: Problem compiling Mac VM

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

Mariano Martinez Peck

Re: Problem compiling Mac VM

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

Igor Stasenko

Re: Problem compiling Mac VM

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.

David T. Lewis

Re: Problem compiling Mac VM

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

Andreas.Raab

Re: Problem compiling Mac VM

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

David T. Lewis

Re: Problem compiling Mac VM

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

Mariano Martinez Peck

Re: Problem compiling Mac VM

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

johnmci

Re: Problem compiling Mac VM

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