Hello Squeak folks. I am trying to install Squeak to my user space in a box running Red Hat 7.2, that I'm connecting to via VNC.
I downloaded the Squeak 3.0 source, image, changes and image file from the links found at http://www-sor.inria.fr/~piumarta/squeak .
I followed Ian's instructions -- except that I don't have root privileges, so I copied the executables to ~/bin. When I change to the working directory that contains the image, source, changes files, and run "squeak Squeak3.0.image", I get the message "Visual class TrueColor is not supported at depth 8." at the command-line. No Squeak :(.
On Tuesday 18 December 2001 04:03 pm, Brent Vukmer wrote:
Hello Squeak folks. I am trying to install Squeak to my user space in a box running Red Hat 7.2, that I'm connecting to via VNC.
I downloaded the Squeak 3.0 source, image, changes and image file from the links found at http://www-sor.inria.fr/~piumarta/squeak .
I followed Ian's instructions -- except that I don't have root privileges, so I copied the executables to ~/bin. When I change to the working directory that contains the image, source, changes files, and run "squeak Squeak3.0.image", I get the message "Visual class TrueColor is not supported at depth 8." at the command-line. No Squeak :(.
You need to tell VNC not to use that visual class using the -cc option:
$ vncserver -cc 3 $ ./squeak -display ned:1 ../../3.0/Squeak3.1a-4325.image
I have alter the squeak source at source forge
http://sourceforge.net/projects/squeak/
to support large files.
I have also updated the macintosh source to reflect changes pending in 3.2.1 which cover
a) long file names b) large files c) Buildable via Apple Project Builder under OS-X 10.1.1 which means now you can build the official Carbon VM without having to purchase a development environment (aka Codewarrior) d) A slew of other changes.
What I need now is a Apple Project Builder HOWTO for Squeak under OS-X, lurkers are welcome to create such a document. Checking to see if I've actually posted enough information and files for you to build your own mach-o carbon OS-X Squeak VM would be a GOOD thing...
I also confirmed the mpeg plugin was at v1.2
Pending are changes to the JPEG plugin and possible integration as an internal Mac plugin.
On Tue, Dec 18, 2001 at 05:27:35PM -0800, John M McIntosh wrote:
What I need now is a Apple Project Builder HOWTO for Squeak under OS-X, lurkers are welcome to create such a document. Checking to see if I've actually posted enough information and files for you to build your own mach-o carbon OS-X Squeak VM would be a GOOD thing...
Ok. It worked for me. Not perfectly, but I have build a new VM.
Problems: -> recources.sit seems to be corrupted? -> some changesets are missing (InternetConfig, UUID, ...) -> compiler error LargeIntegers (assert)
detailed log: (MacOS X 10.1.2, Projectbuilder 1.1v73.3) ------------- -> install MacOSX Developer Tools -> get the latest image. -> install cvs -> get vmmaker. -> in the Terminal.app: cvs -d:pserver:anonymous@cvs.squeak.sourceforge.net:/cvsroot/squeak login cvs -z3 -d:pserver:anonymous@cvs.squeak.sourceforge.net:/cvsroot/squeak co squeak -> mv squeak/platforms/ . -> File in VMmaker: VMMaker-3-1-version3.cs -> File in MacLongFileName-JMM.5.cs, LargeFiles-JMM.3.cs -> do VMMakerTool openInWorld
Plugins not build: FFIPlugin FileCopyPlugin GeniePlugin IntegerPokerPlugin TestOSAPlugin
External Plugins: JPEGReadWriter2Plugin Mpeg3Plugin
-> generate all. -> go to src/vm, unstuff SqueakVMForCarbon.pbproj.sit -> click on SqueakVMForCarbon.pbproj, Projectbuilder starts. -> select the build-target (OPTtimized Vm, not Debug) -> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).
You'l get two errors in LargeIntergers, simply delete the "assert" funtion and prototype. (it's not used)
That's it.
-> generate all. -> go to src/vm, unstuff SqueakVMForCarbon.pbproj.sit -> click on SqueakVMForCarbon.pbproj, Projectbuilder starts. -> select the build-target (OPTtimized Vm, not Debug) -> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).
So which ones are missing?
You'l get two errors in LargeIntergers, simply delete the "assert" funtion and prototype. (it's not used)
Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.
On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:
-> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).
So which ones are missing?
The resources are not there (resources.sit is corrupted). Then I did not file in the changesets for UUID-Plugin and InternetConfig. But I found those and now the only source file missing is "sqGnu.h".
Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.
Ok.
On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:
-> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).
So which ones are missing?
The resources are not there (resources.sit is corrupted). Then I did not file in the changesets for UUID-Plugin and InternetConfig. But I found those and now the only source file missing is "sqGnu.h".
Ah if you startup stuffit expander and select the resource.sit. Does it complain it's corrupt? Maybe I need to make it as binhex to make cvs happy.
At 12:06 AM +0100 12/23/01, Marcus Denker wrote:
The real problem is that you need to customize the project (add some files, remove some files) if you don't build the exact same modules as John. This is annoying. I'd like to just type "make" or push some button. But there seems to be no possiblility to use a script to build the "Makefile" used by the Projectbuilder. That's bad.
Mmm if you look inside the SqueakVMForCarbon.pbproj folder/bundle you'll see a project.pbxproj file. That is an text file. Now it has fun stuff like
08773EF700C6A1C4C0A80109 = { isa = PBXFileReference; path = sqMacWindow.c; refType = 4; };
Then of course the key for the file is used in a few other places.
Bet once could autogenerate the file with a little Squeak Code. Mmm I was hoping that key was a UUID but a quick check shows a current UUID is squeak -> an UUID('f7d9637b-f76e-11d5-bd5b-00306540a296') or
[otter:~] johnmci% uuidgen 58674EBA-F76F-11D5-AC9E-00306540A296
Ya, my airport card has 003065110e6b as the address so neither match the ending. But I'm wondering how magical that number needs to be. Maybe there is a doc somewhere...
On Sat, Dec 22, 2001 at 10:43:47PM -0800, John M McIntosh wrote:
Ah if you startup stuffit expander and select the resource.sit. Does it complain it's corrupt? Maybe I need to make it as binhex to make cvs happy.
Same thing: "The file resources.sit does not appear ti be compressed or encoded....". (Stuffit Lite 6.5). I have no Probems with SqueakVMForCarbon.pbproj.sit
Bet once could autogenerate the file with a little Squeak Code.
Or we could use OSProcess to call gcc from within Squeak...
Hi!
--- John M McIntosh johnmci@smalltalkconsulting.com wrote: [SNIP]
Ah if you startup stuffit expander and select the resource.sit. Does it complain it's corrupt? Maybe I need to make it as binhex to make cvs happy.
Eh? If it is a binary file - why don't you check it in binary? That tells CVS to "stay out of it" and not expand keywords or convert lineendings.
regards, G�ran
===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
__________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
Marcus Denker wrote:
On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:
...
Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.
Ok.
The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.
I just want to have an assert function, which does exactly what you expect from such a function. The semantics should be the same for as ST #assert: as C 'assert()'. And now there comes one compile problem and we have to change code on the ST side. Furthermore I have to follow the rule: 'Don't use #assert: in plugin code!'. (And when comes the next function name, which I cannot use?)
So far there wasn't any problem with assert, so what is it exactly (I don't have a Mac)? Then I've seen other plugin code with asserts (B3DRasterizerPlugin): why isn't there the same problem?
Possible solutions: - If it is a macro defined elsewhere, you are probably able to #undef it in your special platform specific code. - On the other side: what about '#include <assert.h>' as standard for all plugins? Then we don't have to define such a function for plugins in ST. And the #assert: in ST matches the C 'assert()' well in semantics.
I like #assert: and 'assert()' to have simple debug checking and some documentation about the conditions which have to hold: please don't change its name on either side.
Greetings,
Stephan
At 7:10 AM +0100 12/24/01, Stephan Rudlof wrote:
Marcus Denker wrote:
On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:
...
Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.
Ok.
The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.
I just want to have an assert function, which does exactly what you expect from such a function.
Well in the bsd <assert.h> we have #define assert(expression) \ ((void) ((expression) ? 0 : __assert (#expression, __FILE__, __LINE__)))
then you do static int assert(int aBool) { /* missing DebugCode */; }
Then the GNU compiler gets grumpy.
Note that assert is also used in b3dAlloc.c which is one of the places the #include <assert.h> is invoked to pickup the BSD definition.
I'm assuming you could revert to use #include <assert.h> then use assert as defined for BSD assert versus your own version. Mmm right now it appears your assert doesn't do anything? Should it?
John M McIntosh wrote:
At 7:10 AM +0100 12/24/01, Stephan Rudlof wrote:
Marcus Denker wrote:
On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:
...
Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.
Ok.
The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.
I just want to have an assert function, which does exactly what you expect from such a function.
Well in the bsd <assert.h> we have #define assert(expression) \ ((void) ((expression) ? 0 : __assert (#expression, __FILE__, __LINE__)))
then you do static int assert(int aBool) { /* missing DebugCode */; }
Then the GNU compiler gets grumpy.
Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here. Here is just --- #include <math.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h>
#include "sqVirtualMachine.h" #include "sqConfig.h" #include "sqPlatformSpecific.h" --- for LargeIntegers.c and none of them seem to include <assert.h>. Possibly this behaves different for you?
Note that assert is also used in b3dAlloc.c which is one of the places the #include <assert.h> is invoked to pickup the BSD definition.
But this shouldn't affect the compiling of LargeIntergers.c, I think.
I'm assuming you could revert to use #include <assert.h> then use assert as defined for BSD assert versus your own version.
I just wanted (I'm not really sure, see below) to have the most common ANSI-C assert. If your BSD assert (what means BSD here?) is such a thing, OK.
Mmm right now it appears your assert doesn't do anything? Should it?
In debug plugin generation mode it does something. One reason to introduce it has been (now it seems to be the only one for this plugin), that per default there is *no* '#include <assert.h>' for plugins. So write your own or change the generation of plugin file preambles.
One problem with using the standard 'assert()' in C is its radical behaviour: my K&R book says, that it 'abort()'s. Defining our own could modify this behaviour and differentiate between different plugins (assumed the current name clash is solved).
Greetings,
Stephan
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.
Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which
includes "/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes "/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"
which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"
I just wanted (I'm not really sure, see below) to have the most common ANSI-C assert. If your BSD assert (what means BSD here?) is such a thing, OK.
Below is the man page for the BSD (aka FreeBSD being the reference edition for OS-X) assert, but it seems the GNU assert is used here which overrides the platform definition for consistency according to notes on newsgroups from the 1990. The GNU assert.h is defined below (at least the interesting parts).
Thus either the assert used by LargeInteger.c uses the GNU assert, or platform assert, or it needs another name because it's not really assert.
GNU assert.h <partial>
extern void __eprintf () __attribute__ ((noreturn)); /* Defined in libgcc.a */
#define assert(expression) \ ((void) ((expression) ? 0 : __assert (expression, __FILE__, __LINE__)))
#define __assert(expression, file, lineno) \ (__eprintf ("%s:%u: failed assertion `%s'\n", \ file, lineno, "expression"), 0)
libgcc2.c has <partial>
/* This is used by the `assert' macro. */ extern void __eprintf (const char *, const char *, unsigned int, const char *) __attribute__ ((__noreturn__));
void __eprintf (const char *string, const char *expression, unsigned int line, const char *filename) { fprintf (stderr, string, expression, line, filename); fflush (stderr); abort (); }
BSD assert man page
ASSERT(3) System Programmer's Manual ASSERT(3)
NAME assert - expression verification macro
SYNOPSIS #include <assert.h>
assert(expression)
DESCRIPTION The assert() macro tests the given expression and if it is false, the calling process is terminated. A diagnostic message is written to stderr and the abort(3) function is called, effectively terminating the program.
If expression is true, the assert() macro does nothing.
The assert() macro may be removed at compile time with the cc(1) option -DNDEBUG.
DIAGNOSTICS The following diagnostic message is written to stderr if expression is false:
"assertion "%s" failed: file "%s", line %d\n", \ "expression", __FILE__, __LINE__);
SEE ALSO cc(1), abort(3)
STANDARDS The assert() macro conforms to ANSI C3.159-1989 (``ANSI C'').
HISTORY A assert macro appeared in Version 6 AT&T UNIX.
John M McIntosh wrote:
Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.
Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which
includes "/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes "/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"
which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"
What about just #undef assert (I think without braces) just after the #include "/Developer/Headers/FlatCarbon/MacTypes.h" in sqConfig.h? This should allow the inclusion of headers potentially using 'assert()'s, but removes its definition for the Squeak sources. Have you tried this approach?
I just wanted (I'm not really sure, see below) to have the most common ANSI-C assert.
See also my last mail in response to Tim in this thread.
If your BSD assert (what means BSD here?) is such a thing,
OK.
Below is the man page for the BSD (aka FreeBSD being the reference edition for OS-X) assert,
OK.
Greetings,
Stephan
...
Added support to compile under os-x as a bundle. This requires a change to how files names are resolved when open the file
'From Squeak3.2alpha of 1 November 2001 [latest update: #4599] on 27 December 2001 at 3:41:11 pm'!
!Mpeg3Plugin methodsFor: 'primitives' stamp: 'JMM 12/27/2001 15:39'! primitiveMPEG3CheckSig: path | result sz |
"int mpeg3_check_sig(char *path)" self var: #storage declareC: 'char storage[1024] '. self primitive: 'primitiveMPEG3CheckSig' parameters: #(String). sz _ interpreterProxy byteSizeOf: path cPtrAsOop. self cCode: 'sqFilenameFromStringOpen(storage, path, sz)'. self cCode: 'result = mpeg3_check_sig(storage)'. ^result asOop: Boolean ! !
!Mpeg3Plugin methodsFor: 'primitives' stamp: 'JMM 12/27/2001 15:40'! primitiveMPEG3Open: path | mpeg3Oop index sz storage |
"mpeg3_t* mpeg3_open(char *path)" self var: #index declareC: 'mpeg3_t ** index'. self var: #storage declareC: 'char storage[1024]'. self primitive: 'primitiveMPEG3Open' parameters: #(String). sz _ interpreterProxy byteSizeOf: path cPtrAsOop. self cCode: 'sqFilenameFromStringOpen(storage, path, sz)'. mpeg3Oop _ interpreterProxy instantiateClass: interpreterProxy classByteArray indexableSize: 4. index _ self cCoerce: (interpreterProxy firstIndexableField: mpeg3Oop) to: 'mpeg3_t **'. self cCode: '*index = mpeg3_open(storage); makeFileEntry(*index)'. ^mpeg3Oop. ! !
John M McIntosh wrote:
Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.
Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which
includes
"/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes
"/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"
which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"
What about just #undef assert (I think without braces) just after the #include "/Developer/Headers/FlatCarbon/MacTypes.h" in sqConfig.h? This should allow the inclusion of headers potentially using 'assert()'s, but removes its definition for the Squeak sources. Have you tried this approach?
Well we could but I think the question then is are we using assert as we know a unix assert, or are we using some other specialized sqAssert. I think overriding the unix assert could be confusing to some people. Also you then get into interesting games here to ensure our assert is used versus the unix assert. Right now you have an assert in LargeIntegers.c but that's different than the one found in other locations in the source code.
John M McIntosh wrote:
John M McIntosh wrote:
Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.
Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which
includes
"/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes
"/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"
which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"
What about just #undef assert (I think without braces) just after the #include "/Developer/Headers/FlatCarbon/MacTypes.h" in sqConfig.h? This should allow the inclusion of headers potentially using 'assert()'s, but removes its definition for the Squeak sources. Have you tried this approach?
Well we could but I think the question then is are we using assert as we know a unix assert, or are we using some other specialized sqAssert. I think overriding the unix assert could be confusing to some people.
That's a point.
Also you then get into interesting games here to ensure our assert is used versus the unix assert.
This shouldn't be a problem: just #undef it if necessary (#undef'ing at the begin of each - automatically generated - plugin should be sufficient; remark: so far - until your problem for *one* specific platform - there wasn't any assert problem).
Right now you have an assert in LargeIntegers.c but that's different than the one found in other locations in the source code.
Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).
I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).
Is this a compromise?
Greetings,
Stephan
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
At 4:01 AM +0100 12/28/01, Stephan Rudlof wrote:
Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).
I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).
Is this a compromise?
Yes, it's quite workable. Now if someone wants to resubmit a change set to clean this up, that would be great.
Note the usages below.
It would seem that BalloonEngineSimulation>>assert: should really use the Object>>assert: which means some changes because one expects a block, the other a boolean. Which is correct is a question? SUnit expects a boolean, perhaps our usage on Object as a block should change to avoid confusion.
Perhaps a better name for the plugin assert is sqPluginAssert? I'm also assuming this could be folded into InterpreterPlugin? Printing a message, is ok, but I wonder if we want to also print a stack trace too before doing the exit(1), or is that a primitiveFail and return we want (I suspect so?) This implies doing a return will be ok, or do we need sqPluginAssertExit & sqPluginAssertReturn?
TestCase>>assert: aBoolean aBoolean ifFalse: [self signalFailure: 'Assertion failed']
Object>>assert: aBlock "Throw an assertion error if aBlock does not evaluates to true."
aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']
BalloonEngineSimulation>>assert: bool bool ifFalse:[^self error:'Assertion failed'].
LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]
On Wednesday, January 2, 2002, at 02:11 AM, John M McIntosh wrote:
LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]
Well, even as a compromise, this ignores that the code, as written, is broken! I suggest eliminating it altogether as used here. Because of the
#self cCode:inSmalltalk
message, this method will not be inlined to the caller, even though the #debugCode inlines the generated code of #assert: to blank! This is what appears to be happening in the generated code for LargeIntegerPlugin.
Thus, the generated code for the production version contains calls like:
assert(limit < lenFrom);
which are evaluated for an empty procedure, I don't know how many optimizing compilers are smart enough to pick this one up, but with less than careful optimiztion, this means that all your assertion expressions are evaluated.
This is particularly egregious for LargeIntegersPlugin, since that code tends to live inside many inner loops for computation-intensive work. The microseconds wasted for such computations -- which are unnecessary if this were done differently -- add up.
Thus, in addition to the decidedly annoying problems with some important platform development systems and the like, this structure is also highly inefficient, because
Andrew,
you are correct (as far as I've gotten your mail, see below), but...
Besides that I've posted a changeset TIPlugin-cleanup-sr.1.cs.gz in mail subjected [ENH] TestInterpreterPlugin-cleanup-sr recently (triggered by this discussion), which simplifies the >>sqAssert: and therefore...
"Andrew C. Greenberg" wrote:
On Wednesday, January 2, 2002, at 02:11 AM, John M McIntosh wrote:
LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]
Well, even as a compromise, this ignores that the code, as written, is broken! I suggest eliminating it altogether as used here. Because of the
#self cCode:inSmalltalk
message, this method will not be inlined to the caller, even though the #debugCode inlines the generated code of #assert: to blank! This is what appears to be happening in the generated code for LargeIntegerPlugin.
Thus, the generated code for the production version contains calls like:
assert(limit < lenFrom);
which are evaluated for an empty procedure, I don't know how many optimizing compilers are smart enough to pick this one up, but with less than careful optimiztion, this means that all your assertion expressions are evaluated.
... avoids this problem:
- the current production LargeIntegersPlugin>>assert: is used very rarely; - I've thought that compilers are able to optimize this call away (in production code generated by default), since then - C assert() is an empty function, - there is no function call in the arguments of the generated C assert() calls, - there is no side effect while evaluating the arguments of the generated C assert() calls; - in the worst case (stupid compiler) these very few to be evaluated boolean expressions should have negligable impact on performance.
Resumee: There is a better solution, but there is no reason to make panic: the LargeIntegersPlugin is fast with or without these assert()'s!
Greetings,
Stephan
This is particularly egregious for LargeIntegersPlugin, since that code tends to live inside many inner loops for computation-intensive work. The microseconds wasted for such computations -- which are unnecessary if this were done differently -- add up.
Thus, in addition to the decidedly annoying problems with some important platform development systems and the like, this structure is also highly inefficient, because
PS: Here your mail has been truncated for me...
John M McIntosh wrote:
At 4:01 AM +0100 12/28/01, Stephan Rudlof wrote:
Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).
I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).
Is this a compromise?
Yes, it's quite workable. Now if someone wants to resubmit a change set to clean this up, that would be great.
Note the usages below.
It would seem that BalloonEngineSimulation>>assert: should really use the Object>>assert: which means some changes because one expects a block, the other a boolean. Which is correct is a question? SUnit expects a boolean, perhaps our usage on Object as a block should change to avoid confusion.
Perhaps a better name for the plugin assert is sqPluginAssert? I'm also assuming this could be folded into InterpreterPlugin? Printing a message, is ok, but I wonder if we want to also print a stack trace too before doing the exit(1), or is that a primitiveFail and return we want (I suspect so?) This implies doing a return will be ok, or do we need sqPluginAssertExit & sqPluginAssertReturn?
TestCase>>assert: aBoolean aBoolean ifFalse: [self signalFailure: 'Assertion failed']
Object>>assert: aBlock "Throw an assertion error if aBlock does not evaluates to true."
aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']
BalloonEngineSimulation>>assert: bool bool ifFalse:[^self error:'Assertion failed'].
LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]
My last [ENH] suggestion was to kick this >>assert: and to use a modified one: TestInterpreterPlugin>> sqAssert: aBool self debugCode: [aBool ifFalse: [self error: 'Assertion failed!']. ^ aBool]
This eliminates any assert() calls in production code and results in an exit() call (see error() in interp.c) with call stack printing for debug code.
See TIPlugin-cleanup-sr.1.cs.gz in mail subjected [ENH] TestInterpreterPlugin-cleanup-sr .
For me this is a simple variant for developer code and *documentation* purposes (>>sqAssert:'s say something about the semantics of the code!). The question remains if it makes sense to provide a more complicated variant with >>primitiveFail semantics. For me the simple one is at least a good start.
Greetings,
Stephan
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
I made some changes when compiling the macintosh VM 3.2.1Beta5 under OS-X mach-o
So update your VMMaker platform source trees.
In short
a) I fixed the open image dialog so that you can open an image even if the image is lacking the file type. This allows you to attempt to open any file that ends with say .image (be sure you know what you are doing eh)
b) Added support to work with bundles, versus CFM under OS-X. I also have some broken code in the source tree to enable mach-o applications to interface to CFM libraries if someone wants to be a hero they can fix it eh?
c) Changed the mpeg3lib plugin to enable you to compile it under os-x project builder as a bundle. This requires a Smalltalk code change too, and it would be nice if some other hero could mangle the source tree so that one can build that plugin under linux etc without much hassle. Also understanding why it core dumps on the mac when I compile with PTHREADS would be interesting too, but I don't have a dual CPU mac box to test with, maybe someone else does?
Now I'll go back to fixing an OpenBSD 68K box that I busted while doing yearly maintenance last night...
It sounds to me that there are several varieties of 'assert()' that exist in C-land and a variety of ways of getting them into an executable. This suggests to me that we should sidstep the problem by using our own name (is there anything wrong with #sqAssert: ?) and defining it to sensibly suit the needs of the vm. I see from a cursory search on the web that there is at least a dichotomy between assert()s that simply write the line & function name out to a log and those that then abort you program. I'm not sure either is adequate for real uses; wouldn't it be more useful to have a flag for a fatal problem so you can choose whether you need to log or die?
tim
Tim Rowledge wrote:
It sounds to me that there are several varieties of 'assert()' that exist in C-land and a variety of ways of getting them into an executable. This suggests to me that we should sidstep the problem by using our own name (is there anything wrong with #sqAssert: ?)
#sqAssert: is a workaround: We already have this nice ST #assert:, and I'd be happy to be allowed to use the same name for a C assert() with a related semantics. And it annoys me to be forced to avoid this name just since there is some platform specific include problem.
and defining it to sensibly suit the needs of the vm. I see from a cursory search on the web that there is at least a dichotomy between assert()s that simply write the line & function name out to a log and those that then abort you program. I'm not sure either is adequate for real uses; wouldn't it be more useful to have a flag for a fatal problem so you can choose whether you need to log or die?
This gives me an idea: we already have #primitiveFailed and could possibly define #assert: to use it instead of a hardcore abort() (together with some logging stating than an assert has failed). What do you think about this?
Greetings,
Stephan
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Useful as a hip pocket on a T-shirt.
Stephan Rudlof wrote:
#sqAssert: is a workaround: We already have this nice ST #assert:, and I'd be happy to be allowed to use the same name for a C assert() with a related semantics. And it annoys me to be forced to avoid this name just since there is some platform specific include problem.
Well I have some sympathy with the attitude but I rather suspect it would be lot simpler to roll over and just put up with having a different name. Think of it as jujitsu programming, skilfully avoiding a problem by moving slickly to one side of the monster.
This gives me an idea: we already have #primitiveFailed and could possibly define #assert: to use it instead of a hardcore abort() (together with some logging stating than an assert has failed). What do you think about this?
Yes we could certainly do something like that. I'd suggest a form of assert that can cleanly return a defined failure notification as well as one that can do the "argh! I'm dead!" sort of failure.
I think a simple primitiveFail is a bit lacking in information content. It is a simple matter to extend it to set a defined temp variable in the calling context to some object that provides more info. We used a form of this for the Interval project and it allows one to quickly owrk out why the prim failed. BitBLT could use it to specify _which_ coordinate was innapropriate, or which Form was invalid. A file prim could return a sensible reason for why your attempt to open a file failed (file not there? permissions? bad breath?).
It has been argued that one could do this by having a get-last-error prim and copy the errno() idea form unix. This is a poor idea for two reasons:- copying a dumb idea from a daft OS is not sensible and unless you propose to put some form of critical block around every prim call you could not trust that the result of a separate prim has anything to do with the one that failed.
The code changes to enable this are very simple but (unless one wants to put tedious guard code around the place) it does have something of a Heaviside function about it - an image expecting it can run on an older vm, but an updated vm would crash an older image. It might be a good thing to include in the list of image-format-breaking changes alongside new compiled method format, blocks etc etc.
tim
On Mon, Dec 24, 2001 at 07:10:37AM +0100, Stephan Rudlof wrote:
The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.
I just want to have an assert function, which does exactly what you expect from such a function. The semantics should be the same for as ST #assert: as C 'assert()'. And now there comes one compile problem and we have to change code on the ST side. Furthermore I have to follow the rule: 'Don't use #assert: in plugin code!'. (And when comes the next function name, which I cannot use?)
....
Possible solutions:
- If it is a macro defined elsewhere, you are probably able to #undef it in
your special platform specific code.
- On the other side: what about '#include <assert.h>' as standard for all
plugins? Then we don't have to define such a function for plugins in ST. And the #assert: in ST matches the C 'assert()' well in semantics.
Or: We could chane the SLANG Codegenerator to use a prefix (like "sq_") for every function it generates... (instead of generationg a function "assert()" it would generate "sq_assert()" for the "assert:" method) this would solve this kind of problem once and for all.
Marcus
Marcus Denker wrote:
On Mon, Dec 24, 2001 at 07:10:37AM +0100, Stephan Rudlof wrote:
The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.
I just want to have an assert function, which does exactly what you expect from such a function. The semantics should be the same for as ST #assert: as C 'assert()'. And now there comes one compile problem and we have to change code on the ST side. Furthermore I have to follow the rule: 'Don't use #assert: in plugin code!'. (And when comes the next function name, which I cannot use?)
....
Possible solutions:
- If it is a macro defined elsewhere, you are probably able to #undef it in
your special platform specific code.
- On the other side: what about '#include <assert.h>' as standard for all
plugins? Then we don't have to define such a function for plugins in ST. And the #assert: in ST matches the C 'assert()' well in semantics.
Or: We could chane the SLANG Codegenerator to use a prefix (like "sq_") for every function it generates... (instead of generationg a function "assert()" it would generate "sq_assert()" for the "assert:" method) this would solve this kind of problem once and for all.
Good idea: *all* 'private' C functions of InterpreterPlugin subclasses could have this prefix. We shouldn't use it for exported functions though, they already have the module prefix, which should be sufficient.
We are continuing to emulate C++ namespaces here...
Wait: why not using a C++ compiler with namespace Squeak instead? ;-)
Greetings,
Stephan
Marcus
-- Marcus Denker marcus@ira.uka.de
Marcus Denker marcus@ira.uka.de is widely believed to have written:
Plugins not build: FileCopyPlugin IntegerPokerPlugin
Was this because of a problem, or your choice? It built ok on linux this afternoon.
You'l get two errors in LargeIntergers, simply delete the "assert" funtion and prototype. (it's not used)
Didn't seem to be aproblem on linux. Aren't platform differences wonderful....
One problem did arise on linux; platforms/Cross/vm/sq.h needs #define sqFilenameFromStringOpen(d,s,n) sqFilenameFromString(d,s,n) after #define sqFilenameFromString(dst, src, num) \ (line 133 in my copy) in order to build. I'll try to commit the change some time tomorrow if I can recall the incantation. Oh, and you _have_ to have the LargeFile-jmm.cs installed. This is potentially a problem in our vm maintenance process I suppose; how can we make sure that things are kept in step? Maybe this would be helped by SqCVS in some manner since we could make sure to fetch vm related changesets along with the C code?
I wonder if Harry Potter has problems remembering his sourcery code?
tim
On Fri, Dec 21, 2001 at 09:58:34PM -0800, Tim Rowledge wrote:
Plugins not build: FileCopyPlugin IntegerPokerPlugin
Was this because of a problem, or your choice? It built ok on linux this afternoon.
They weren't included in the Projectbuilders Makefile... I just tried, IntegerPokerPlugin is no problem, but FileCopyPlugin needs an additional library (and I havn't yet looked a t building that on OS X).
Oh, and you _have_ to have the LargeFile-jmm.cs installed. This is potentially a problem in our vm maintenance process I suppose; how can we make sure that things are kept in step? Maybe this would be helped by SqCVS in some manner since we could make sure to fetch vm related changesets along with the C code?
Don't know if you really need them... I think they will be in the update stream soon.
The real problem is that you need to customize the project (add some files, remove some files) if you don't build the exact same modules as John. This is annoying. I'd like to just type "make" or push some button. But there seems to be no possiblility to use a script to build the "Makefile" used by the Projectbuilder. That's bad.
Marcus
Marcus Denker marcus@ira.uka.de is widely believed to have written:
FileCopyPlugin needs an additional library (and I havn't yet looked a t building that on OS X).
yup, it needs a platform specific file to do the actual copy-with-all-status-intact stuff. Of course, we ought to be able to do this in squeak anyway.
Oh, and you _have_ to have the LargeFile-jmm.cs installed. This is potentially a problem in our vm maintenance process I suppose; how can we make sure that things are kept in step? Maybe this would be helped by SqCVS in some manner since we could make sure to fetch vm related changesets along with the C code?
Don't know if you really need them... I think they will be in the update stream soon.
It's required by the sqVirtualMAchine.c file in the tree, so I hope it gets in the image soon.
The real problem is that you need to customize the project (add some files, remove some files) if you don't build the exact same modules as John. This is annoying. I'd like to just type "make" or push some button. But there seems to be no possiblility to use a script to build the "Makefile" used by the Projectbuilder. That's bad.
It's certainly annoying. However, as long as there is some way to get the tools to accept some file that is plain(ish) text, there is hope. Acorn & unix can use fairly plain makefile texts, codeworrier can accpet xml, I think vileC++ can accept something similar... must be doable somehow. May OSProcess is a better bet thouh, drive the compiler directly?
tim
I just tried to make a Mac VM from the tree from SF and a latest 3.1 +VMMaker image. It does have the 64bit access doohickeys and the image was used to make a working linux VM yesterday.
I used the vm/SqueakPro5.xml as a project to import into codeworrier. I had to edit the access path/user paths/project to make it {Project}:src in order to get the compiler to llok at the files in src/vm/... instead of platforms/vm/... etc. Breathtakingly dumb thing for codeworrier to do, but it seems to be really good at that sort of thing.
I got 307 red-hand errors. Couldn't find project file "InternetConfigPlugin.c" Identifier 'mkdir(const char*,...) redeclared was declared as : int (const char*, int) now declared as: int (const char*,...) sqMacDirectory.c line 23 Couldn't find project file "sqMacInternetConfiguration.c" and 300 plus complaints about the sqMAcOpenGLInfo.c file not being able to open GL/gl.h
Suggestions for how to get past this list of problems welcomed. I probably did something wrong by changing the {Project} thingy, but it appeared to be the only way forward!
tim
I just tried to make a Mac VM from the tree from SF and a latest 3.1 +VMMaker image. It does have the 64bit access doohickeys and the image was used to make a working linux VM yesterday.
I used the vm/SqueakPro5.xml as a project to import into codeworrier. I had to edit the access path/user paths/project to make it {Project}:src in order to get the compiler to llok at the files in src/vm/... instead of platforms/vm/... etc. Breathtakingly dumb thing for codeworrier to do, but it seems to be really good at that sort of thing.
I got 307 red-hand errors. Couldn't find project file "InternetConfigPlugin.c" Identifier 'mkdir(const char*,...) redeclared was declared as : int (const char*, int) now declared as: int (const char*,...) sqMacDirectory.c line 23 Couldn't find project file "sqMacInternetConfiguration.c" and 300 plus complaints about the sqMAcOpenGLInfo.c file not being able to open GL/gl.h
Suggestions for how to get past this list of problems welcomed. I probably did something wrong by changing the {Project} thingy, but it appeared to be the only way forward!
a) You want to run OS-X right not that OS-9 and Code Warrior? Don't you have to pay for that tool eh?
b) You need the Open/GL SDK See ftp://ftp.apple.com/developer/opengl/SDK/ and get the OpenGL_SDK_1.2_Core.img.bin file first. That's only 2.8MB and I think that is all you need, since the full SDK is 40+MB. But if you use the Core SDK then you'll need to update your path information because the silly volume name is different.
c) Be a nice fellow and update the readme in the mac vm folder to talk about the Open/GL image you need
d) mkdir(const char*,...) mmm seems this is one of those CW versus BSD issues, so change it to int (const char*, int), I'll consider and #ifdef
e) you need to build it with the internetconfigplugin, there is a change set on the list for that plugin if it's not in your image. Also a change set exists for the UUID plugin that you might need. If of course you don't build with those internal plugins then you need to chop them out of the CW project.
PS Squeak 3.2.1Beta5 Mach-o Carbon is pending on my desktop. I've made changes to support plugins, er bundles, under OS-X. So maybe tomorrow I'll distribute to those that have expressed interest. We are also cleaning up the JPEG stuff and I hope to make a new version of that available soon.
I'm trying to get a VM build environment going on a Linux machine from the CVS platforms tree and VMMaker. It looks like the configure and make scripts are not quite happy with this new directory structure. I try to run platforms/unix/misc/configure, but it's not happy. Am I missing something, or are things not quite there yet?
Thanks, Stephen
On Thu, Dec 27, 2001 at 08:21:17AM -0500, Stephen Pair wrote:
I'm trying to get a VM build environment going on a Linux machine from the CVS platforms tree and VMMaker. It looks like the configure and make scripts are not quite happy with this new directory structure. I try to run platforms/unix/misc/configure, but it's not happy. Am I missing something, or are things not quite there yet?
You're not missing anything. The good news it that it will build fine, except for the MPEG plugin; just ignore the warnings. You should consider the CVS repository to be an unauthorised hacker's copy of the master source, which belongs to Ian. Personally, I prefer to use the unauthorized hack, but don't be surprised if there are some problems with it.
A volunteer to discombobulate the Makefile.in for the CVS tree would no doubt be gratefully accepted.
Tim, did I get that about right?
Dave
"David T. Lewis" lewis@mail.msen.com is widely believed to have written:
On Thu, Dec 27, 2001 at 08:21:17AM -0500, Stephen Pair wrote:
I'm trying to get a VM build environment going on a Linux machine from the CVS platforms tree and VMMaker. It looks like the configure and make scripts are not quite happy with this new directory structure. I try to run platforms/unix/misc/configure, but it's not happy. Am I missing something, or are things not quite there yet?
You're not missing anything. The good news it that it will build fine, except for the MPEG plugin; just ignore the warnings. You should consider the CVS repository to be an unauthorised hacker's copy of the master source, which belongs to Ian. Personally, I prefer to use the unauthorized hack, but don't be surprised if there are some problems with it.
Unauthorised ? In an open source wordd? Hmm, not sure that concept really applies. Anyway, the code in a few files needed altering to allow it to work with any/all plugins external; a diff between version would show what they are and how minor. Mostly small bugs that would require plugins to be internal in order for the vm to link successfully (I seem to remember an explicit init of the serial port for example, which the serial plugin handles if it is ever loaded)
The MPEG plugin needs some work in the makefile stuff - Lex originally provided an altered 'mkfrags' file that apparently makes it work, but I haven't had the time or reason to try to integrate it with the slightly hacked makefiles needd for the VMMaker system. I think the new JPEG plugin needs a tiny amount of rework as well, and I hope to get to it sometime. Aside from that, it really should be a case of
get image (up to 4478 currently tested by me) load VMMAker VMMakerTool openInWorld choose your poisons (which plugins are internal/external/ignored) pres the go button wait . . . chmod a+x src/con* src/ac* src/in* src/lt* src/util/* (to make stuff executable - see other emails about the problems of copying files and losing vital info in the process) mkdir build cd build ../src/configure make cp squeak .libs {my destination}
done!
Once you have done this you should find you have a 'FileCopyPlugin' which _ought_ to do the file copying properly next time and obviate the need for the permissions changing. We really need to improve the file system code.
A volunteer to discombobulate the Makefile.in for the CVS tree would no doubt be gratefully accepted.
I'm certain the makefiles stuff needs tidying up. I commented every change I made with 'tpr' - or at least tried to. An expert can probably make it much neater. Please do so....
Tim, did I get that about right?
Pretty much.
Building on a Mac ought to be similar, but Apple seem to delight in making programming difficult. I know it _can_ be done because John has been building the relese MAc VMs with it since goodness knows when. Windows is not something I can test personally since I haven't used a 'doze machine in five years or maybe more. Craig was able to get VMMAker running in about an hour a few months ago and the results of that are in the SF platform tree.
tim
On Thu, Dec 27, 2001 at 08:22:38AM -0800, Tim Rowledge wrote:
<snip>
"building a linux VM...
should be a case of
get image (up to 4478 currently tested by me) load VMMAker VMMakerTool openInWorld choose your poisons (which plugins are internal/external/ignored) pres the go button wait . . . chmod a+x src/con* src/ac* src/in* src/lt* src/util/* (to make stuff executable - see other emails about the problems of copying files and losing vital info in the process) mkdir build cd build ../src/configure
Nothing seems unusual up to this point.
make
Now it gets wierd. I should mention that I'm using an image updated to 4478, and building just the core VM (I'll mess with plugins once I get this to work). One of two things happens; the first happens when I use the src/ directory generated by VMMaker, and the second when I use a copied version ("cp -r") of that directory.
The first thing that might happen is that typing "make" results in the output:
cd ../src && aclocal cd ../src && autoconf configure.in:142: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:143: warning: AC_TRY_RUN called without default to allow cross compiling Bconfigure.in:144: warning: AC_TRY_RUN called without default to allow cross compiling ../src/configure --prefix=/usr/local --exec_prefix=/usr/local --bindir=/usr/local/bin --libdir=/usr/local/lib --mandir=/usr/local/man ... <repeat of configure> ... updating cache ./config.cache creating ./config.status creating Makefile creating inisqueak creating sqUnixConfig.h sqUnixConfig.h is unchanged CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.
This behavior is unlike any other unix program I have tried to compile. Subsequent invocations of "make" just elicit a repeat of the line:
make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.
The other thing that might happen is that typing "make" appears to run normally up until the following output:
copying last section of file mv gnuify.out gnu-interp.c gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -DHAVE_CONFIG_H -DUNIX -DSQ_LIBDIR="/usr/local/lib/squeak/3.1a-4164" -I. -I../src/vm -c gnu-interp.c gnu-interp.c:1234: conflicting types for `readImageFromFileHeapSizeStartingAt' ../src/vm/sq.h:309: previous declaration of `readImageFromFileHeapSizeStartingAt' make: *** [gnu-interp.o] Error 1
This is a more reasonable error, but an error nonetheless. I have a hunch that the first behavior might be avoided by using VMMaker with a properly compiled FilePlugin. However, to do that, I have to avoid the second error.
Help?
Thanks, Joshua
cp squeak .libs {my destination}
done!
On Fri, Dec 28, 2001 at 10:48:47AM -0500, Joshua 'Schwa' Gargus wrote:
The other thing that might happen is that typing "make" appears to run normally up until the following output:
copying last section of file mv gnuify.out gnu-interp.c gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -DHAVE_CONFIG_H -DUNIX -DSQ_LIBDIR="/usr/local/lib/squeak/3.1a-4164" -I. -I../src/vm -c gnu-interp.c gnu-interp.c:1234: conflicting types for `readImageFromFileHeapSizeStartingAt' ../src/vm/sq.h:309: previous declaration of `readImageFromFileHeapSizeStartingAt' make: *** [gnu-interp.o] Error 1
I hacked around this by changing the type in sq.h from offset_t to int. This let me get as far as:
ar -rc squeak.a.tmp sqNamedPrims.o sqUnixExternalPrims.o sqUnixMozilla.o sqVirtualMachine.o sqXWindow.o zipio.o zlib.o gnu-interp.o sqUnixVersion.o mv squeak.a.tmp squeak.a /bin/sh ./libtool --mode=link gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -avoid-version -export-dynamic -R/usr/local/lib/squeak/3.1a-4164 -o squeak squeak.a -lXext -lX11 -lm -ldl -lnsl -L/usr/X11R6/lib mkdir .libs gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -o squeak squeak.a -lXext -lX11 -lm -ldl -lnsl -L/usr/X11R6/lib -Wl,--export-dynamic -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 squeak.a(sqVirtualMachine.o): In function `sqGetInterpreterProxy': /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:306: undefined reference to `positive64BitIntegerFor' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:307: undefined reference to `positive64BitValueOf' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:308: undefined reference to `signed64BitIntegerFor' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:309: undefined reference to `signed64BitValueOf' collect2: ld returned 1 exit status make: *** [squeak] Error 1
There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?
Thanks, Joshua
This is a more reasonable error, but an error nonetheless. I have a hunch that the first behavior might be avoided by using VMMaker with a properly compiled FilePlugin. However, to do that, I have to avoid the second error.
Help?
Thanks, Joshua
cp squeak .libs {my destination}
done!
Joshua 'Schwa' Gargus wrote:
There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?
Yup, you need the largefiles changes that define the 64bit routines and would fix the off_t error for you. I forgot to call out that particular problem, sorry!
I'd like to hope that we can avoid this kind of problem when the module system is in use by keeping the VM related modules alongside the vm C code; wherever we eventually decide to keep that.
make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.
This is very strange - there is no way it should be looking for anything in ../src/src, so clearly there is some wrinkle in the makefile stuff that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!
tim
On Fri, Dec 28, 2001 at 10:45:23AM -0800, Tim Rowledge wrote:
Joshua 'Schwa' Gargus wrote:
There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?
Yup, you need the largefiles changes that define the 64bit routines and would fix the off_t error for you. I forgot to call out that particular problem, sorry!
No problem. I'm ecstatic at having successfully used VMMaker, and am looking forward to playing with my own plugins, now that it's so convenient. Thank you!
One more hack was necessary to successfully compile: I added #define sqFilenameFromStringOpen(dst, src, num) sqFilenameFromString(dst, src, num) to sqPlatformSpecific.h in order to get the FilePlugin to build.
I'd like to hope that we can avoid this kind of problem when the module system is in use by keeping the VM related modules alongside the vm C code; wherever we eventually decide to keep that.
make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.
This is very strange - there is no way it should be looking for anything in ../src/src, so clearly there is some wrinkle in the makefile stuff that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!
Like I said, building with a copy of the source ("diff -r oldsrc copiedsrc" verifies that they are the same) doesn't have the same problem. I also manually compared all of the file permissions in the two directories. I have no idea what the difference could possibly be.
Bye, Joshua
tim
make: *** No rule to make target
`../src/src/Makefile.in', needed by `Makefile'. Stop.
This is very strange - there is no way it should be looking
for anything
in ../src/src, so clearly there is some wrinkle in the
makefile stuff
that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!
Like I said, building with a copy of the source ("diff -r oldsrc copiedsrc" verifies that they are the same) doesn't have the same problem. I also manually compared all of the file permissions in the two directories. I have no idea what the difference could possibly be.
Translating make's error message into a more plain "I am missing the file `../src/src/Makefile.in' and don't know how to create it myself" I would guess that "../src/src/" should probably be "../src/" - so it all looks like a problem with your base directory.
Cheers, - Andreas
On Fri, Dec 28, 2001 at 09:22:31PM +0100, Andreas Raab wrote:
make: *** No rule to make target
`../src/src/Makefile.in', needed by `Makefile'. Stop.
This is very strange - there is no way it should be looking
for anything
in ../src/src, so clearly there is some wrinkle in the
makefile stuff
that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!
Like I said, building with a copy of the source ("diff -r oldsrc copiedsrc" verifies that they are the same) doesn't have the same problem. I also manually compared all of the file permissions in the two directories. I have no idea what the difference could possibly be.
Translating make's error message into a more plain "I am missing the file `../src/src/Makefile.in' and don't know how to create it myself" I would guess that "../src/src/" should probably be "../src/" - so it all looks like a problem with your base directory.
I can see how what I wrote above might be misinterpreted. Here is exactly what I did:
-generate src/ with VMMaker (do chmod a+x, etc.) -tried to build; got error described above
-rm -fr src -generate src with VMMaker (do chmod a+x, etc.) -mv src origsrc -cp -r origsrc src -tried to build; did not get error described above
I verified that the directories src/ and origsrc/ are the same with "diff -r". When I try: -rm -fr src -mv origsrc src -try to build
the error pops up again. Wierd.
Bye, Joshua
Cheers,
- Andreas
Josh,
I can see how what I wrote above might be misinterpreted. Here is exactly what I did:
-generate src/ with VMMaker (do chmod a+x, etc.) -tried to build; got error described above
-rm -fr src -generate src with VMMaker (do chmod a+x, etc.) -mv src origsrc -cp -r origsrc src -tried to build; did not get error described above
I verified that the directories src/ and origsrc/ are the same with "diff -r". When I try: -rm -fr src -mv origsrc src -try to build
the error pops up again. Wierd.
Not weird at all. First of all, does "../src/src/Makefile.in" exist? I bet it doesn't. If not, then there's a simple way to get the error through using cp: - cp -r origsrc src - 'touch' the make file causing the problem like in: find . -name Makefile -exec touch {}; - try to build I bet it's the modification stamp of some Makefile wrt to some other file that (by chance) gets a different stamp with cp (mv is moving files and keeping the dates but cp is creating new ones and thus modifying the date).
(NB: If I'm not totally wrong here, why would it be a misinterpretation to point out that Make is just complaining about a non-existing file?! ;-)
Cheers, - Andreas
On Fri, Dec 28, 2001 at 11:12:59PM +0100, Andreas Raab wrote:
Josh,
I can see how what I wrote above might be misinterpreted. Here is exactly what I did:
-generate src/ with VMMaker (do chmod a+x, etc.) -tried to build; got error described above
-rm -fr src -generate src with VMMaker (do chmod a+x, etc.) -mv src origsrc -cp -r origsrc src -tried to build; did not get error described above
I verified that the directories src/ and origsrc/ are the same with "diff -r". When I try: -rm -fr src -mv origsrc src -try to build
the error pops up again. Wierd.
Not weird at all. First of all, does "../src/src/Makefile.in" exist? I bet it doesn't.
Lucky guess. Oh wait, that's what the error message told us ;-)
If not, then there's a simple way to get the error through using cp:
- cp -r origsrc src
- 'touch' the make file causing the problem like in: find . -name Makefile -exec touch {};
- try to build
I bet it's the modification stamp of some Makefile wrt to some other file that (by chance) gets a different stamp with cp (mv is moving files and keeping the dates but cp is creating new ones and thus modifying the date).
Hmm. That make some sense. I still insist that it's weird, tho'; I've never seen a Makefile created by configure that re-invokes configure. Since Makefile is generated, it may be an interaction between timestamps of some other files. I tried touching a few, but was unable to replicate the behavior. Then boredom set in, and I quit.
(NB: If I'm not totally wrong here, why would it be a misinterpretation to point out that Make is just complaining about a non-existing file?! ;-)
I thought that I didn't make it clear that I was doing the exact same thing with two copies of the same source tree; the reason I though that was your hypothesis that "something was wrong with my base directory".
Thanks for the help, Joshua
Cheers,
- Andreas
Joshua 'Schwa' Gargus wrote:
Hmm. That make some sense. I still insist that it's weird, tho'; I've never seen a Makefile created by configure that re-invokes configure. Since Makefile is generated, it may be an interaction between timestamps of some other files.
I think it must have something to do with that; the 'normal' makefile doesn't do it, but something I touched in making it survive with VMMaker has affected it. As I've said before, expert help is needed.
tim
On Friday 28 December 2001 18:45, Tim Rowledge wrote:
Joshua 'Schwa' Gargus wrote:
There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?
Yup, you need the largefiles changes that define the 64bit routines and would fix the off_t error for you. I forgot to call out that particular problem, sorry!
I'd like to hope that we can avoid this kind of problem when the module system is in use by keeping the VM related modules alongside the vm C code; wherever we eventually decide to keep that.
make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.
This is very strange - there is no way it should be looking for anything in ../src/src, so clearly there is some wrinkle in the makefile stuff that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!
IIRC, the Makefile will run autoconf depending on the timestamps of the various files and autoconf will then screw up the Makefile. Using touch(1) on configure to update the timestamp will hopefully fix it.
Fixing the autoconf stuff would be better but I've no idea how to do that.
John M McIntosh johnmci@smalltalkconsulting.com is widely believed to have written:
a) You want to run OS-X right not that OS-9 and Code Warrior? Don't you have to pay for that tool eh?
It was paid for long ago and by somebody else anyway, so my issue would be paying $120 or thereabouts for an OS upgrade. OS9.whatever is it until somebody starts paying me.
b) You need the Open/GL SDK See ftp://ftp.apple.com/developer/opengl/SDK/ and get the OpenGL_SDK_1.2_Core.img.bin file first. That's only 2.8MB and I think that is all you need, since the full SDK is 40+MB. But if you use the Core SDK then you'll need to update your path information because the silly volume name is different.
I think I'll skip that pleasure and forget the plugin...
c) Be a nice fellow and update the readme in the mac vm folder to talk about the Open/GL image you need
d) mkdir(const char*,...) mmm seems this is one of those CW versus BSD issues, so change it to int (const char*, int), I'll consider and #ifdef
Sigh. Apple seem to contantly do this sort of thing. Move files, change names, alter apis. I know they don't exactly have a huge installed base of developers to worry about, but dosen't it screw up their own lives as well? Bizarre.
e) you need to build it with the internetconfigplugin, there is a change set on the list for that plugin if it's not in your image. Also a change set exists for the UUID plugin that you might need. If of course you don't build with those internal plugins then you need to chop them out of the CW project.
I guess I can ust drop this one too.
Is there any possible answer to my problem with the inititial {Projet} path stuff? Or that something that one is supposed to intuitively understand?
tim
squeak-dev@lists.squeakfoundation.org