(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);
but gcc insists that there are another one???
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
On 30 December 2010 10:53, John McIntosh johnmci@smalltalkconsulting.com wrote:
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
Well but at least once it was built by Eliot? No? Because otherwise, why is it there, if not for building against it? :)
I doubt that there is something wrong with Mac OS tree, okay.. the headers could be a little bit different, but i compiling the gcc3x-interp.c which have little to do with Mac OS tree, since its a generated StrackInterpreter code.
As to me, it looks like bug in GCC (because error is FATAL).
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);
but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Igor, I could compile StackVM without fatal errors in Mac. JUst in case, I am using GCC 4.2 and compiling from XCode.
cheers
mariano
On Thu, Dec 30, 2010 at 11:22 AM, Igor Stasenko siguctua@gmail.com wrote:
On 30 December 2010 10:53, John McIntosh johnmci@smalltalkconsulting.com wrote:
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
Well but at least once it was built by Eliot? No? Because otherwise, why is it there, if not for building against it? :)
I doubt that there is something wrong with Mac OS tree, okay.. the headers could be a little bit different, but i compiling the gcc3x-interp.c which have little to do with Mac OS tree, since its a generated StrackInterpreter code.
As to me, it looks like bug in GCC (because error is FATAL).
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here
/var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol
L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
===========================================================================
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
-- Best regards, Igor Stasenko AKA sig.
Hi John,
Why so grumpy? :-)
On Dec 30, John McIntosh johnmci@smalltalkconsulting.com wrote:
The mac OS tree is not certified to work or even compile with the cog vm.
But if it doesn't work, that's a bug, right? And if it's a bug, this list would be the place to bring it up, so we can figure out how to fix it.
In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
So? The Mac app store doesn't exist yet, and Cog isn't production ready anyway. For now, folks are just trying to get a working Cog VM for their own use. We'll worry about Apple's policies when the time comes.
Colin
On 2010-12-30, at 5:02 AM, Colin Putney wrote:
In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
So? The Mac app store doesn't exist yet, and Cog isn't production ready anyway. For now, folks are just trying to get a working Cog VM for their own use. We'll worry about Apple's policies when the time comes.
Colin
Jan 6th 2011, 7 days from now and Apple's going to run right over anyone in the way... Warranty on the squeak 4.x series VM is null and void that morning...
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Dec 30, 2010, at 5:16 PM, John M McIntosh wrote:
On 2010-12-30, at 5:02 AM, Colin Putney wrote:
In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
So? The Mac app store doesn't exist yet, and Cog isn't production ready anyway. For now, folks are just trying to get a working Cog VM for their own use. We'll worry about Apple's policies when the time comes.
Colin
Jan 6th 2011, 7 days from now and Apple's going to run right over anyone in the way... Warranty on the squeak 4.x series VM is null and void that morning...
Ok Now what should be done to have signed/certified.... May be ESUG can pay a license to esteban so that the vm gets signed?
Stef
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Well let me suggest that ESUG could actually apply for and get a mac developer license as an organization, then setup Esteban's company as a team lead etc. That way the APP ends up being offered under the ESUG name.
On 2010-12-30, at 10:46 AM, Esteban Lorenzano wrote:
Ok Now what should be done to have signed/certified.... May be ESUG can pay a license to esteban so that the vm gets signed?
yep, that would be cool... :)
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ok I will pass this info to the esug board
Stef
On Dec 30, 2010, at 8:35 PM, John M McIntosh wrote:
Well let me suggest that ESUG could actually apply for and get a mac developer license as an organization, then setup Esteban's company as a team lead etc. That way the APP ends up being offered under the ESUG name.
On 2010-12-30, at 10:46 AM, Esteban Lorenzano wrote:
Ok Now what should be done to have signed/certified.... May be ESUG can pay a license to esteban so that the vm gets signed?
yep, that would be cool... :)
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 30.12.2010, at 17:16, John M McIntosh wrote:
On 2010-12-30, at 5:02 AM, Colin Putney wrote:
In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
So? The Mac app store doesn't exist yet, and Cog isn't production ready anyway. For now, folks are just trying to get a working Cog VM for their own use. We'll worry about Apple's policies when the time comes.
Colin
Jan 6th 2011, 7 days from now and Apple's going to run right over anyone in the way... Warranty on the squeak 4.x series VM is null and void that morning...
Huh? That sounds unwarrantedly bitter.
Nothing is going to stop working on Jan 6th. People will just have an additional way to install software. I don't see a problem. (Yet, anyway)
- Bert -
hi john
I think that there are two issues: - is it reasonable (did it work in the past) to build a Stack vm using an automatic build and should igor spend his time on that? - what are the actions to be done to the the vm on apple store? I see them as two different things. Right now we would like to have a server that builds all the vm for all the platforms automatically so that we can move on to spend energy on something else than fighting with makefiles.
Stef
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
El 30/12/2010, a las 10:16a.m., stephane ducasse escribió:
hi john
I think that there are two issues:
- is it reasonable (did it work in the past) to build a Stack vm using an automatic build and should igor
spend his time on that?
- what are the actions to be done to the the vm on apple store?
I see them as two different things. Right now we would like to have a server that builds all the vm for all the platforms automatically so that we can move on to spend energy on something else than fighting with makefiles.
Stef
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Dec 30, 2010, at 3:03 PM, Esteban Lorenzano wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Tx for the info. esteban do you know if the iOS version contains all the cleans that ESUG payed for (I imagine). Stef
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
El 30/12/2010, a las 10:16a.m., stephane ducasse escribió:
hi john
I think that there are two issues:
- is it reasonable (did it work in the past) to build a Stack vm using an automatic build and should igor
spend his time on that?
- what are the actions to be done to the the vm on apple store?
I see them as two different things. Right now we would like to have a server that builds all the vm for all the platforms automatically so that we can move on to spend energy on something else than fighting with makefiles.
Stef
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
El 30/12/2010, a las 11:41a.m., stephane ducasse escribió:
On Dec 30, 2010, at 3:03 PM, Esteban Lorenzano wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Tx for the info. esteban do you know if the iOS version contains all the cleans that ESUG payed for (I imagine). Stef
I don't know what cleanings ESUG payed, but I'm pretty sure the work is done, John can answer that better than me :) If you provide me with a list of cleanings, I can take a look.
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
El 30/12/2010, a las 10:16a.m., stephane ducasse escribió:
hi john
I think that there are two issues:
- is it reasonable (did it work in the past) to build a Stack vm using an automatic build and should igor
spend his time on that?
- what are the actions to be done to the the vm on apple store?
I see them as two different things. Right now we would like to have a server that builds all the vm for all the platforms automatically so that we can move on to spend energy on something else than fighting with makefiles.
Stef
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Dec 30, 2010, at 4:12 PM, Esteban Lorenzano wrote:
El 30/12/2010, a las 11:41a.m., stephane ducasse escribió:
On Dec 30, 2010, at 3:03 PM, Esteban Lorenzano wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Tx for the info. esteban do you know if the iOS version contains all the cleans that ESUG payed for (I imagine). Stef
I don't know what cleanings ESUG payed, but I'm pretty sure the work is done,
I'm sure about that :) this is just that with ios cog stackvm.... I would like that his hardwork is not lost :)
John can answer that better than me :) If you provide me with a list of cleanings, I can take a look.
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
El 30/12/2010, a las 10:16a.m., stephane ducasse escribió:
hi john
I think that there are two issues:
- is it reasonable (did it work in the past) to build a Stack vm using an automatic build and should igor
spend his time on that?
- what are the actions to be done to the the vm on apple store?
I see them as two different things. Right now we would like to have a server that builds all the vm for all the platforms automatically so that we can move on to spend energy on something else than fighting with makefiles.
Stef
The mac OS tree is not certified to work or even compile with the cog vm. In fact you should know that any vm built with the Mac OS tree and submitted to the osx app store will be rejected by apple
On 12/30/10, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);
but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Dec 30, 2010, at 3:03 PM, Esteban Lorenzano wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Tx for the info. esteban do you know if the iOS version contains all the cleans that ESUG payed for (I imagine). Stef
iOS tree "Some of this code was funded via a grant from the European Smalltalk User Group (ESUG)"
106 files
Mac OS tree
ZERO files...
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Thanks john. Happy new year :)
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Tx for the info. esteban do you know if the iOS version contains all the cleans that ESUG payed for (I imagine). Stef
iOS tree "Some of this code was funded via a grant from the European Smalltalk User Group (ESUG)"
106 files
Mac OS tree
ZERO files...
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 30 December 2010 15:03, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
yeah, except that unfortunately i started messing with Cog+Mac OS stuff, instead of doing either unix or windows :)
Okay, then maybe i should really remove the Mac OS subdir from Cog's source repository, because we don't need that anymore. One thing what is important , that we want to make sure that we can build StackInterpreter even on platform which can run Cog. Because then we could completely migrate onto Stack+Cog.
@Esteban, please tell me if you took a look at CMakeVMMaker stuff, and if you can do it. If you don't have enough time, then i will do it myself, otherwise i will start making configuration for unix.
What we want is to have a working Hudson build server for VMs in the mid of January, so keep that in mind :)
El 30/12/2010, a las 12:01p.m., Igor Stasenko escribió:
On 30 December 2010 15:03, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi, I answer instead John... and I answer something I already said: I see no point on compile the cog vm based on the Mac OS branch, because that code is based on legacy apple code (carbon), and for that reason, it will not be present in future releases of OSX. The correct branch to work is iOS :)
Cheers, Esteban
pd: yes, automated generation is a great goal, and I'm cheering Igor's work :)
yeah, except that unfortunately i started messing with Cog+Mac OS stuff, instead of doing either unix or windows :)
Okay, then maybe i should really remove the Mac OS subdir from Cog's source repository, because we don't need that anymore. One thing what is important , that we want to make sure that we can build StackInterpreter even on platform which can run Cog. Because then we could completely migrate onto Stack+Cog.
@Esteban, please tell me if you took a look at CMakeVMMaker stuff, and if you can do it. If you don't have enough time, then i will do it myself, otherwise i will start making configuration for unix.
I'm working on that just right now... give me until wednesday of next week and I will have it :)
What we want is to have a working Hudson build server for VMs in the mid of January, so keep that in mind :)
hurray!!!!
-- Best regards, Igor Stasenko AKA sig.
Hi Igor,
On Thu, Dec 30, 2010 at 1:37 AM, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here
/var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
So two things here. One is what these labels are. The labels that are added by the code generator simply for performance measurement. See the define of VM_LABEL in the various sqPlatformSpecific.h files. So this is not necessary but essential if using the VMProfiler to profile the stack interpreter. If a method is marked with an <asmLabel: true> pragma the code generator outputs a label for it and one can ten identify the particular code sequence (e.g. a bytecode) in the VMProfiler.
The other is what causes the error. The C compiler can choose to inline code, but both gcc and icc appear not to examine the code they're inlining for inserted labels and end up duplicating the labels inserted by VM_LABEL. Since this duplication depends on the exact source and compiler optimization level in force there's no easy way to predict when a label will be duplicated. The fix is to add <asmLabel: false> to the relevant method. A better fix might be to add a <C: #noinline> pragma that would result in turning off inlining for the relevant function (for example I don't think it appropriate at all that the C compiler is inlining bereaveAllMarriedContexts; it doesn't happen all that often - basically at snapshot or voiding machien code - and inlining it is a silly decision on the C compiler's part). A hack fix is of course to simply define VM_LABEL as 0, but that criples the VMProfiler.
HTH Eliot
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
On 30 December 2010 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Igor,
On Thu, Dec 30, 2010 at 1:37 AM, Igor Stasenko siguctua@gmail.com wrote:
(warnings are supressed)
In file included from /Users/sig/projects/cog/sig-cog/build/../platforms/Mac OS/vm/Developer/sqGnu.h:46, from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level: /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note: ‘theIP’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note: ‘hdrTypeBits’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note: ‘freeChunkSize’ was declared here /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note: ‘freeChunkSize’ was declared here /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol L0bereaveAllMarriedContexts already defined.
So two things here. One is what these labels are. The labels that are added by the code generator simply for performance measurement. See the define of VM_LABEL in the various sqPlatformSpecific.h files. So this is not necessary but essential if using the VMProfiler to profile the stack interpreter. If a method is marked with an <asmLabel: true> pragma the code generator outputs a label for it and one can ten identify the particular code sequence (e.g. a bytecode) in the VMProfiler. The other is what causes the error. The C compiler can choose to inline code, but both gcc and icc appear not to examine the code they're inlining for inserted labels and end up duplicating the labels inserted by VM_LABEL. Since this duplication depends on the exact source and compiler optimization level in force there's no easy way to predict when a label will be duplicated. The fix is to add <asmLabel: false> to the relevant method. A better fix might be to add a <C: #noinline> pragma that would result in turning off inlining for the relevant function (for example I don't think it appropriate at all that the C compiler is inlining bereaveAllMarriedContexts; it doesn't happen all that often - basically at snapshot or voiding machien code - and inlining it is a silly decision on the C compiler's part). A hack fix is of course to simply define VM_LABEL as 0, but that criples the VMProfiler.
Thanks for explanation and a hint. But as you can see this is a code generator, which inlining this function, and then for duplicating label, C compiler inlining voidVMStateForSnapshot() at least twice. Yes, since this code is not critical for VM performance, we could either disable inlining or remove label.
Because my first reaction was disable labels ...
I guess this happens because it compiles it with whole module optimization flag: -O3 , which i took from xcode project 'Release' config.
HTH Eliot
i found the only use of it in generated code:
voidVMStateForSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt activeContext; sqInt header; sqInt oop; sqInt sz;
activeContext = divorceAllFrames(); /* begin bereaveAllMarriedContexts */ VM_LABEL(0bereaveAllMarriedContexts);
but gcc insists that there are another one???
-- Best regards, Igor Stasenko AKA sig.
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Colin Putney -
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko -
John M McIntosh -
John McIntosh
-
Mariano Martinez Peck -
stephane ducasse