Custom Search
|
Date: May 30, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<9305D8AB-9145-11D7-BA65-000393B2AA24@xxxxxxxxxxxx>
> I have a 10.2.6 system and I got that kind of message. What should I do?
> This is long time ago that I did not make that....I start to get old or
> spoiled by other Smalltalks :)
:-)
> checking for C compiler default output... configure: error: C compiler
> cannot create executables
> check `config.log' for details.
>
> Quite fun for a c compiler not to be able to create executables.
Yes, try compiling something as simple as
int main() { }
with
cc -o test test.c
./test
Actually the problem is in the linker:
> /usr/bin/ld: /usr/lib/libSystem.dylib load command 9 unknown cmd field
Probably something is screwed with your compiler/linker setup. You might ask
Lukas to
try on his machine (BTW tell him that it works under Cygwin too).
Paolo
Date: May 30, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<1054024308.2759.33.camel@xxxxxxxxxxxxxxxxxxxx><003001c32482$36dbd1b0$63dc1d97@bonz
><1054067453.22633.16.camel@xxxxxxxxxxxxxxxxxxxx> <001901c3253a$eda1ca40$49df1d97@bonz> <1054196993.2497.28.camel@xxxxxxxxxxxxxxxxxxxx>
> It only went down to 4MB and stayed there. Pity. But I can't guarantee
> that there were no nasty references that should have been cleared up.
> That image was fairly well messed up.
You can use the code in examples/MemUsage.st (you'll have to uncomment a couple
of
lines) to obtain a list of classes with the number of instances, and spot
something
unusual.
> Files in on top of 'Browser' and 'Regex' (the latter is only used
> briefly).
Sorry, this is not something that will go in. It is too hackish, and too little
customizable. But I can provide the machinery to do it nicely in the first
alpha for
2.2: the trick is to generalize the <primitive: NNN> syntax so that one can say
<saveProperty: #xGeom>
or even provide a custom block like
<saveProperty: #xGeom as: [ :widget :value | value / widget weight ]>
(just an example, it probably does not make sense :-)
All these will be compiled to a Message object and accessible with
CompiledMethod>>#pragmasDo: or CompiledMethod>>#allPragmas:
You will then have to patch Blox in a thousand places but it is quite a
mechanical work
(like I did when I added the documentation to all of the Blox options).
It is good work, you'll get many insights by going down your current way (maybe
wait
for BCanvasObject -- this is something for which your automatic approach will
have to
be changed.
> BLOX.BWindow savePositions "Haven't managed to make this automatic yet"
Take a look at ObjectMemory's dependents.
Paolo
Date: May 29, 2003
From: Mike Anderson <bigbadwolf@xxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<001901c3253a$eda1ca40$49df1d97@bonz>
References:
<1054024308.2759.33.camel@xxxxxxxxxxxxxxxxxxxx> <003001c32482$36dbd1b0$63dc1d97@bonz
> <1054067453.22633.16.camel@xxxxxxxxxxxxxxxxxxxx> <001901c3253a$eda1ca40$49df1d97@bonz>
On Wed, 2003-05-28 at 18:02, Bonzini wrote: > > It certainly does that... and it gets rid of the excess windows in the > > Blox Browser test as well. I'm expecting a 10MB garbage collection on my > > test image - I'll let you know! > > Ouch! That should be quite a stress test. :-) It only went down to 4MB and stayed there. Pity. But I can't guarantee that there were no nasty references that should have been cleared up. That image was fairly well messed up. > Can you please post your test code or send it to me privately? Attached. Files in on top of 'Browser' and 'Regex' (the latter is only used briefly). Execute BLOX.BWindow rebuildWindowsOnStartup: true and BLOX.BWindow savePositions "Haven't managed to make this automatic yet" Save image and restart. So far, the windows rebuild themselves, including their menus. The two major omissions are: BCanvasObjects - haven't even looked at them. Reconnecting the BLOXBrowser objects. In principle the BLOXBrowser objects should already be connected, and menu items like 'Save Image' and 'Exit without saving' do function, so I think it is simply a question of prompting them to do an updates Be gentle. It's an exploratory work so far. Regards, Mike
RebuildWindowsOnStartup.st.bz2
Description: application/bzip
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk
Date: May 28, 2003
From: Stephane Ducasse <ducasse@xxxxxxxxxxxx>
In-reply-to:
<000f01c3253a$624d7480$49df1d97@bonz
>
References:
<000f01c3253a$624d7480$49df1d97@bonz
>
Hi paolo I have a 10.2.6 system and I got that kind of message. What should I do?This is long time ago that I did not make that....I start to get old or spoiled by other Smalltalks :)
Stef[Stephane-G4:~/Workspace/SecondCircle/smalltalk-2.1.2] ducasse% ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets ${MAKE}... yes
Build Tools:
checking for style of include used by make... GNU
checking for gcc... no
checking for cc... cc
checking for C compiler default output... configure: error: C compiler
cannot create executables
check `config.log' for details. [Stephane-G4:~/Workspace/SecondCircle/smalltalk-2.1.2] ducasse% Quite fun for a c compiler not to be able to create executables. Stef more config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Smalltalk configure 2.1.2, which was generated by GNU Autoconf 2.54. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = Stephane-G4.local. uname -m = Power Macintosh uname -r = 6.6 uname -s = Darwinuname -v = Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.ob
j~1/RELEASE_PPC
/usr/bin/uname -p = powerpc
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = Mach kernel version:
Darwin Kernel Version 6.6:
Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC
Kernel configured for up to 2 processors.
1 processor is physically available.
Processor type: ppc7450 (PowerPC 7450)
Processor active: 0
Primary memory available: 512.00 megabytes.
Default processor set: 63 tasks, 164 threads, 1 processors
Load average: 1.25, Mach factor: 0.41
unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /Users/ducasse/bin
PATH: /usr/local/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1529: checking for a BSD-compatible install
configure:1583: result: /usr/bin/install -c
configure:1594: checking whether build environment is sane
configure:1637: result: yes
configure:1670: checking for gawk
configure:1699: result: no
configure:1670: checking for mawk
configure:1699: result: no
configure:1670: checking for nawk
configure:1699: result: no
configure:1670: checking for awk
configure:1686: found /usr/bin/awk
configure:1696: result: awk
configure:1706: checking whether make sets ${MAKE}
configure:1726: result: yes
configure:1952: checking for style of include used by make
configure:1980: result: GNU
configure:2051: checking for gcc
configure:2080: result: no
configure:2131: checking for cc
configure:2147: found /usr/bin/cc
configure:2157: result: cc
configure:2319: checking for C compiler version
configure:2322: cc --version </dev/null >&5
2.95.2
configure:2325: $? = 0
configure:2327: cc -v </dev/null >&5
Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs
Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2
19991024 (release)
configure:2330: $? = 0
configure:2332: cc -V </dev/null >&5
cc: argument to `-V' is missing
configure:2335: $? = 1
configure:2355: checking for C compiler default output
configure:2358: cc conftest.c >&5
/usr/bin/ld: /usr/lib/libSystem.dylib load command 9 unknown cmd field
configure:2361: $? = 1
configure: failed program was:
#line 2338 "configure"
#include "confdefs.h"
int
main ()
{
;
return 0;
}
configure:2388: error: C compiler cannot create executables
check `config.log' for details.
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=awk
ac_cv_prog_ac_ct_CC=cc
ac_cv_prog_make_make_set=yes
## ----------------- ##
## Output variables. ##
## ----------------- ##
ACLOCAL='${SHELL}
/Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing --r
un aclocal-1.7' ALLOCA='' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE=''AMTAR='${SHELL} /Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing --run
tar' AS='' ATK_CFLAGS='' ATK_LIBS=''AUTOCONF='${SHELL} /Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing --
run autoconf'AUTOHEADER='${SHELL} /Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing
--run autoheader'AUTOMAKE='${SHELL} /Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing --
run automake-1.7'
AWK='awk'
BLOX_IMPLEMENTATION=''
CC='cc'
CCDEPMODE=''
CFLAGS=''
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR='.deps'
DLLTOOL=''
ECHO='echo'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EMACS=''
EXEEXT=''
GLIB_CFLAGS=''
GLIB_GENMARSHAL=''
GLIB_LIBS=''
GLIB_MKENUMS=''
GOBJECT_QUERY=''
GTK_CFLAGS=''
GTK_LIBS=''
HAVE_GTK_FALSE=''
HAVE_GTK_TRUE=''
HAVE_SIGSEGV_FALSE=''
HAVE_SIGSEGV_TRUE=''
I18N_DISABLED=''
ICON=''
INCLTDL=''
INCSNPRINTFV=''
INCTCLTK=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_INFO=''
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
LDFLAGS=''
LDPATH=''
LEX=''
LIBGMP=''
LIBICONV=''
LIBLTDL=''
LIBOBJS=''
LIBREADLINE=''
LIBS=''
LIBSNPRINTFV=''
LIBTCLTK=''
LIBTOOL=''
LIGHTNING_MAIN_FALSE=''
LIGHTNING_MAIN_TRUE=''
LN_S=''
LTALLOCA=''
LTLIBOBJS=''
MAINTAINER=''
MAKEINFO='${SHELL}
/Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/config/missing --
run makeinfo'
MODULES=''
MODULES_EXAMPLE=''
MODULES_GTK=''
MODULES_I18N=''
MODULES_TCP=''
MODULES_TK=''
OBJDUMP=''
OBJEXT=''
PACKAGE='smalltalk'
PACKAGE_BUGREPORT='help-smalltalk@xxxxxxx'
PACKAGE_NAME='GNU Smalltalk'
PACKAGE_STRING='GNU Smalltalk 2.1.2'
PACKAGE_TARNAME='smalltalk'
PACKAGE_VERSION='2.1.2'
PANGO_CFLAGS=''
PANGO_LIBS=''
PATH_SEPARATOR=':'
PKG_CONFIG=''
RANLIB=''
RM=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
TCLSH=''
USE_JIT_TRANSLATION_FALSE=''
USE_JIT_TRANSLATION_TRUE=''
VERSION='2.1.2'
VERSION_INFO='4:10:0'
YACC=''
ac_ct_AS=''
ac_ct_CC='cc'
ac_ct_DLLTOOL=''
ac_ct_OBJDUMP=''
ac_ct_RANLIB=''
ac_ct_STRIP=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include='include'
am__quote=''
bindir='${exec_prefix}/bin'
build=''
build_alias=''
build_cpu=''
build_os=''
build_vendor=''
datadir='${prefix}/share'
exec_prefix='NONE'
host=''
host_alias=''
host_cpu=''
host_os=''
host_vendor=''
includedir='${prefix}/include'
infodir='${prefix}/info'
install_sh='/Users/ducasse/Workspace/SecondCircle/smalltalk-2.1.2/
config/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
lispdir=''
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
subdirs=''
sysconfdir='${prefix}/etc'
target_alias=''
## ----------- ##
## confdefs.h. ##
## ----------- ##
#define MAINTAINER ""
#define PACKAGE "smalltalk"
#define PACKAGE_BUGREPORT "help-smalltalk@xxxxxxx"
#define PACKAGE_NAME "GNU Smalltalk"
#define PACKAGE_STRING "GNU Smalltalk 2.1.2"
#define PACKAGE_TARNAME "smalltalk"
#define PACKAGE_VERSION "2.1.2"
#define ST_EDIT_VERSION 2
#define ST_MAJOR_VERSION 2
#define ST_MINOR_VERSION 1
#define VERSION "2.1.2"
configure: exit 77
Date: May 28, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<346CCD74-90EF-11D7-BA65-000393B2AA24@xxxxxxxxxxxx>
> does anybody run GNU Smalltalk on Mac OS X? Yes, it does run. Some older kernels need to configure it with --disable-generational-gc but it is pretty evident from the fact that it locks up some lines after it says "If the script locks up, reconfigure with --disable-generational-gc" On some other machines, instead, it configures and makes correctly. Paolo
Date: May 28, 2003
From: Stephane Ducasse <ducasse@xxxxxxxxxxxx>
In-reply-to:
<20030528075318.88442.qmail@xxxxxxxxxxxxxxxxxxxxxx>
References:
<20030528075318.88442.qmail@xxxxxxxxxxxxxxxxxxxxxx>
Hi everybody does anybody run GNU Smalltalk on Mac OS X?I presented smalltalk to a group of mac fans that like scripting and mentioned to them GST
but I would like to push them to really have a look at GST. Stef
Date: May 28, 2003
From: Vimal Reddy <vimalreddy@xxxxxxxxx>
In-reply-to:
<20030520080213.GA23907@biancaneve
>
References:
<20030520080213.GA23907@biancaneve
>
> > I get similar results on the other programs. Also, I was wondering if there > > were any real benchmarking programs available for GST. The ones I'm using > now > > don't run long enough to capture true cache behavior. > > What about generating the manual (see docs/Makefile.am and > examples/Publish.st)? > > Paolo I tried running Publish.st, but could'nt get it to create the manual. I just ran, gst examples/Publish.st How should I go about using Publish.st? Thanks, Vimal __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Date: May 27, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<20030527174419.93941.qmail@xxxxxxxxxxxxxxxxxxxxxxx>
> It would be very useful, I think. I did try writing > code to do this in Smalltalk, but it was misguided - I > got references from the MethodContext back to the > object, and it became very messy. Nope, you cannot do that. And you cannot even do half primitive-half Smalltalk like #allInstances because the fields that you're going to examine are the entire object space -- which is extremely more dynamic than the object class field. Contexts also have to be special-cased in the primitive (see is_owner in the code that I posted). > Well, I did have a good look at BWindow TopLevel and > BrowserMain Windows, but emptying them does not help. I was thinking about the latter actually. > Yes, understood. I was trying to say that, on each > startup / snapshot / quit iteration, I would expect > the objects created by the previous iteration to get > garbage collected, and the same number of new ones > created, so it should balance out to zero. As I say, I > only ran two iterations, so it might not have quite > got there. Yes, that's the correct behavior. With the patch I ran thirty of them and the image size stayed there. > Oh, I forgot - I'm still on 2.1pre - my internet > connection's been down for a while, so I've not yet > upgraded. I hope you'll be able to apply my patch (it is against 2.1.2). There should not be severe mismatches. Paolo
Date: May 27, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<1054024308.2759.33.camel@xxxxxxxxxxxxxxxxxxxx>
This patch does two things: - fix the memory leak on vanilla images - provide an #allOwners method that you should like. The memory leak on vanilla images is actually something worse: at one time I had the image quit if I did "Processor yield!" or also " [ 'surprise ' printNl ] fork " after saving the image several times, but now I cannot reproduce it anymore. The problem is that CallinProcesses should not survive an image save, because they were asked for their duty in the original image (while they were quitting in the reloaded image too). The second image will still be a bit larger, but then the extra CallinProcess will become garbage on the third image load and will not be saved in the third image, and so on. |_ _ _ __ |_)(_)| ),' ------- '---
gst-fix-memory-leak.patch
Description: Binary data
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk
Date: May 27, 2003
From: MSA or SJF <msasjf@xxxxxxxxxxx>
In-reply-to:
<002101c32465$b0f6b180$6a17623e@bonz
>
References:
<002101c32465$b0f6b180$6a17623e@bonz
>
--- Bonzini <bonzini@xxxxxxx> wrote: > > Hmm, so I'm having a look at recreating blox > windows on image restart, > > rather than simply abandoning them. > > Very kewl :-) When I've tidied it up, I'll post it, if you're interested. > There is no primitive yet in GNU Smalltalk to find > the owners of a particular object. > This might be the right input to add it. It would be very useful, I think. I did try writing code to do this in Smalltalk, but it was misguided - I got references from the MethodContext back to the object, and it became very messy. > But in > this case the culprit is probably some > class variable of BWindow or of the equivalent > browser object (IIRC, BrowserShell). Well, I did have a good look at BWindow TopLevel and BrowserMain Windows, but emptying them does not help. TopLevel is set to nil on startup already. I didn't notice any class variable in BrowserShell, but I'll take another look. > Note that an evaluation does create CompiledMethods > and MethodInfos to compile, an > Array to hold the literals in the method, and > CallinProcesses and MethodContexts to > evaluate. The notification of the system doing a > snapshot is also causing more code to > be executed. The BlockClosures, Strings and > VFS.CStatStructs are probably created by > #allSubinstancesDo:. Yes, understood. I was trying to say that, on each startup / snapshot / quit iteration, I would expect the objects created by the previous iteration to get garbage collected, and the same number of new ones created, so it should balance out to zero. As I say, I only ran two iterations, so it might not have quite got there. Oh, I forgot - I'm still on 2.1pre - my internet connection's been down for a while, so I've not yet upgraded. Regards, Mike __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Date: May 27, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<1054024308.2759.33.camel@xxxxxxxxxxxxxxxxxxxx>
> Hmm, so I'm having a look at recreating blox windows on image restart, > rather than simply abandoning them. Very kewl :-) > It's actually working quite nicely, but my test > image is getting slowly bigger and bigger (up to 12MB now!). Not very kewl indeed. > Looking into the problem, I find that: > > BLOX.BWindow allInstances size > > reports over one hundred. There is no primitive yet in GNU Smalltalk to find the owners of a particular object. This might be the right input to add it. But in this case the culprit is probably some class variable of BWindow or of the equivalent browser object (IIRC, BrowserShell). > and checked the size of the image afterwards. It goes up by 416 bytes > each time. I'll look into this. It is probably not the same problem, but it is interesting... But, it is also interesting to see whether the change goes into the objects or rather into the OOP table. In the latter case it is more innocuous. > objects): some Arrays, CallinProcesses, CompiledMethods, MethodContexts, > MethodInfos, WriteStreams and VFS.CStatStructs created, some > BlockClosures and Strings destroyed. All in all, there's a lot more > change than I would expect Note that an evaluation does create CompiledMethods and MethodInfos to compile, an Array to hold the literals in the method, and CallinProcesses and MethodContexts to evaluate. The notification of the system doing a snapshot is also causing more code to be executed. The BlockClosures, Strings and VFS.CStatStructs are probably created by #allSubinstancesDo:. Paolo
Date: May 27, 2003
From: Mike Anderson <bigbadwolf@xxxxxxxxxxxxxxxxxxxx>
Hmm, so I'm having a look at recreating blox windows on image restart,
rather than simply abandoning them. It's actually working quite nicely,
but my test image is getting slowly bigger and bigger (up to 12MB now!).
Looking into the problem, I find that:
BLOX.BWindow allInstances size
reports over one hundred. Needless to say, there are only a few windows
in my test setup.
Now, if you create an image with:
PackageLoader fileInPackage: 'Browser'.
ObjectMemory snapshot; quit!
and then repeatedly run it with:
Transcript print: BLOX.BWindow allInstances size.
BLOX.BLOXBrowser.BrowserMain new initialize!
and choose Smalltalk > Save Image and Smalltalk > Exit without saving,
you see the number of windows go up by one every time.
Just to complicate matters, I then tried repeatedly running the
following on a pristine image:
ObjectMemory snapshot; quit!
and checked the size of the image afterwards. It goes up by 416 bytes
each time.
I don't know whether this is all the same problem, anyway, I'm off to
rebuild my image from scratch to bring it back down to 2.5MB.
Regards,
Mike
BTW,
To try to find out what is going on, I ran the following against an
image from one iteration and against the image from the next iteration,
then diff'ed the output:
Object allSubinstancesDo: [ :each |
[ Transcript print: each class ] on: Error do: [ :sig |
Transcript print: '(error)'.
].
Transcript nl.
].
!
I don't know if that's valid (I appreciate that some objects will be
created before it starts running, and more will be created while it is
running). Anyway, the difference appears to be (give or take a few
objects): some Arrays, CallinProcesses, CompiledMethods, MethodContexts,
MethodInfos, WriteStreams and VFS.CStatStructs created, some
BlockClosures and Strings destroyed. All in all, there's a lot more
change than I would expect, though maybe I should have used #snapshot:
and #quit: instead of #snapshot and #quit.
Date: May 27, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<20030526191637.75739.qmail@xxxxxxxxxxxxxxxxxxxxxx>
> I understand 'source line' refers to the line in the source file. No, in the source method. It is used by the debugger. The number before the colon is the IP, as Daniel pointed out. Paolo
Date: May 26, 2003
From: "Daniel A. Koepke" <dkoepke@xxxxxxxxxxxxx>
In-reply-to:
<20030526191637.75739.qmail@xxxxxxxxxxxxxxxxxxxxxx>
References:
<20030526191637.75739.qmail@xxxxxxxxxxxxxxxxxxxxxx>
On Mon, 26 May 2003, Vimal Reddy wrote: > In execution tracing, what is the significance of the number at the > beginning of each line. > > 0: source line 1 > 3: push Global Variable[0] = Smalltalk > 4: push Literal[2] = #BLOX It looks like the instruction pointer. That is, the byte offset into the bytecode-compiled source. -dak
Date: May 26, 2003
From: Vimal Reddy <vimalreddy@xxxxxxxxx>
Hi,
In execution tracing, what is the significance of the number at the beginning
of each line. Here is a small snippet from a run:
0: source line 1
3: push Global Variable[0] = Smalltalk
4: push Literal[2] = #BLOX
5: send selector 1, 2 args = #includesKey:
0: source line 4
3: push self
4: push Temporary[0]
I understand 'source line' refers to the line in the source file. Is there a
way to know which source file it's referring to?
Thanks,
Vimal
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Date: May 20, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<Law10-F9fAscbgJlHr30000f0b8@xxxxxxxxxxx>
You forgot the attachment... also, are you using the JIT? It is known to freeze the debugger. |_ _ _ __ |_)(_)| ),' ------- '---
Date: May 20, 2003
From: "charles ogilvie" <chuckogilvie@xxxxxxxxxxx>
OrderedCollection new testWhen I try to inspect any of the callback lines smalltalk freezes with no load and I have to terminate it. I am running Slackware 7.1 linux on a pentium 166 with X11R6.4 and the latest clean automake and autoconf. I have 64meg of ram and 200meg of swap. Any help you can give me to resolving this problem would be much appreciated. Also if you need more information don't hesitate to reply.
Sincerely,
Charles Ogilvie
P.S. In the
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Date: May 20, 2003
From: Paolo Bonzini <bonzini@xxxxxxx>
In-reply-to:
<20030519222634.52447.qmail@xxxxxxxxxxxxxxxxxxxxxx>
References:
<20030519222634.52447.qmail@xxxxxxxxxxxxxxxxxxxxxx>
> Number of references to eden space = 48,943 > Number of references to surv space 0 = 2 > Number of references to surv space 1 = 2 > Number of references to tenq space = 2 > Total references to new space (eden, surv's, tenq) = 48,949 > Number of references to other spaces(old+fixed) = 29,827,066 <-- > > The num references to old+fixed are really large compared to new space. > Considering that most objects are used up fast ie die young in smalltalk, > should'nt the new space be getting the most references? Is there something I'm > missing? Not necessarily. The test you're running does SmallInteger stuff which does not result in any reference to any space except for methods (which lie into old space). Also, contexts (and hence the stack, nothing less!) get their own pool and are moved to survivor space only if they survive a GC: you are probably considering them as part of oldspace, but their arena is more of a separate eden. You can get the allocated addresses from the chunks array in libgst/interp.c, IIRC. Finally, the tenuring queue is actually only a data structure that is only used at GC time. You can safely drop it. > I get similar results on the other programs. Also, I was wondering if there > were any real benchmarking programs available for GST. The ones I'm using now > don't run long enough to capture true cache behavior. What about generating the manual (see docs/Makefile.am and examples/Publish.st)? Paolo
Date: May 20, 2003
From: Vimal Reddy <vimalreddy@xxxxxxxxx>
Hello Paolo, I'm including the previous email conversation I had with you about garbage collection. My cache simulations are giving results different from expectation (I'm using Shade simulator on Sun Solaris). Basically, I'm counting the number of references made to new space, survivor space and the other spaces (old+fixed). Here's a run for intmath.st: Number of references to eden space = 48,943 Number of references to surv space 0 = 2 Number of references to surv space 1 = 2 Number of references to tenq space = 2 Total references to new space (eden, surv's, tenq) = 48,949 Number of references to other spaces(old+fixed) = 29,827,066 <-- The num references to old+fixed are really large compared to new space. Considering that most objects are used up fast ie die young in smalltalk, should'nt the new space be getting the most references? Is there something I'm missing? My method of collecting this data is I make a note of the allocated addresses for new space and surv spaces (from the respective C structures after memory initialization _gst_init_mem). In my simulator, I count references to addresses lying within these regions. I get similar results on the other programs. Also, I was wondering if there were any real benchmarking programs available for GST. The ones I'm using now don't run long enough to capture true cache behavior. Thanks in advance, -Vimal Date: Tue, 29 Apr 2003 17:20:47 -0400 (EDT) From: Vimal Reddy <vkreddy@xxxxxxxxxxxxxx> To: Bonzini <bonzini@xxxxxxx> Cc: Vimal K Reddy <vkreddy@xxxxxxxx> Subject: Re: GNU smalltalk - Garbage collection P> One thing comes to mind. Generational garbage collection is only supported if your P> architecture is supported by libsigsegv. The porting is not very complex, take a look P> at the parts that implements the check for Alpha/OSF in libsigsegv/configure.in, for P> example, which is one of the simplest. Otherwise you are not using true generational P> GC as the old generation will all be scanned for roots to the new one. Thanks. I looked at the configure.in file. I use Sun Ultrasparc with solaris and x86 with Linux. It looks like both architectures are supported. P> Why not use oprofile or cachegrind on a standard x86 to do cache simulations? This was my opinion as well. But when I discussed it on use groups, I got the feeling that there are 2 levels we are dealing with here. One, the virtual machine which manages its heap, and second the underlying machine which it is being run on. Which level's addresses should I be interested in? Depends on what I want, right? What I want to do is "pin down" all memory between the lo and hi addresses of the youngest generation in the cache (L1 or L2). Then I want to see how the GC performance is effected and so also the VM performance. IMHO, tracing at the machine level should be ok. But some others felt I must trace data references in the interpreter. Are'nt they the same? I tried profiling with Cachegrind (with the Valgrind core and on Linux x86). When a garbage collection is invoked in GST, valgrind comes out with an Abort signal. If you've tried valgrind, it intercepts signals, does its stuff and then hands it back to the client's (here GST) signal handler. Something is going wrong there. I have'nt looked into it much. But I plan on doing it. Without any GC, it works fine. If you are interested, please give it a try. -Vimal Date: Tue, 29 Apr 2003 16:28:03 +0200 From: Bonzini <bonzini@xxxxxxx> To: Vimal Reddy <vkreddy@xxxxxxxxxxxxxx> Cc: Vimal K Reddy <vkreddy@xxxxxxxx> Subject: Re: GNU smalltalk - Garbage collection p>One thing comes to mind. Generational garbage collection is only supported p>if your architecture is supported by libsigsegv. The porting is not very p>complex, take a look at the parts that implements the check for Alpha/OSF in p>libsigsegv/configure.in, for example, which is one of the simplest. p>Otherwise you are not using true generational GC as the old generation will p>all be scanned for roots to the new one. p>Why not use oprofile or cachegrind on a standard x86 to do cache simulations? Date: Wed, 23 Apr 2003 00:25:03 -0400 (EDT) From: Vimal Reddy <vkreddy@xxxxxxxxxxxxxx> To: Paolo Bonzini <bonzini@xxxxxxx> Cc: Vimal K Reddy <vkreddy@xxxxxxxx> Subject: Re: GNU smalltalk - Garbage collection v>Hello again, v>I'm trying to pursure my efforts of studying garbage collection using GNU v>smalltalk. Let me update you of what I'm trying. Basically, I trying to v>see if new cache strategies (like pinning the youngest generation in v>cache) would work good for garbage collection. So I'm trying to collect v>data references for Smalltalk programs, which I would then use on cache v>simulators for studies. v>Now stuff for which I need your help. I've been reading the GST code v>to figure out a way to augment the VM code to get data reference traces. v>Do you think the VM can be augmented to print out every data v>reference that is made while running a smalltalk program. By data v>reference, I mean the address of the location referenced in the heap, not v>the object table. Please let me know which file and function is the best v>place to insert such code. I was thinking the interpreter is suitable for v>it. Thanks, Vimal ===== Vimal Reddy Graduate Student, ECE North Carolina State University Raleigh, NC Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Date: May 15, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<b9o2r3$83j$1@xxxxxxxxxxxxxx>
Thanks. The solution I applied is to add an unset ac_cv_header_tcl_h statement before the AC_CHECK_HEADER for tcl.h |_ _ _ __ |_)(_)| ),' ------- '---
Date: May 12, 2003
From: Carey Evans <careye@xxxxxxxxxxx>
Running configure within script, as sh -x ./configure, I seem to have found the problem: configure is caching the results of the first test for tcl.h (trial 1) for the three other trials, so only the first locations tested will work. I tested this by editing configure and changing "for trial in 1 2 3 4" to "for trial in 4 1 2 3", and the Tcl and Tk libraries are now discovered correctly.
I haven't tried building Smalltalk yet; I'll report back if I have any problems there.
--"Hanging is too good for a man who makes puns; he should be drawn and quoted."
-- Fred Allen
Date: May 12, 2003
From: Paolo Bonzini <bonzini@xxxxxxx>
In-reply-to:
<20030511145603.19b1955e.raquel@xxxxxxxxxxxxxxxx>
References:
<20030509230054.6ddb3f53.raquel@xxxxxxxxxxxxxxxx> <000f01c316c5$b103f1e0$51df1d97@bonz
> <20030510015920.55b9aedf.raquel@xxxxxxxxxxxxxxxx> <002501c31804$1d7ad1b0$5016623e@philo> <20030511145603.19b1955e.raquel@xxxxxxxxxxxxxxxx>
> All I did was to send a message to the address just as the software > message told me when the install failed. There was no mention of an > email list or how to join that list So keep answering to help-smalltalk@xxxxxxx; you answered to me privately. Also, reporting a bug means saying "which tests failed". So far I don't have any clue of which 81 passed and which 3 did not. Please include the full output of make check, or I cannot consider your problem any further. Paolo
Date: May 11, 2003
From: "Paolo Bonzini" <bonzini@xxxxxxx>
References:
<200305101342.19896.jan.hidders@xxxxxxxxxx>
Okay, it looks more or less fine. > Is there a list of bugs somewhere? The closest thing is http://savannah.gnu.org/support/?group=smalltalk -- currently empty, but can be nice to fiddle with it. Paolo
Date: May 10, 2003
From: Jan Hidders <jan.hidders@xxxxxxxxxx>
Here is the diff for PCode.st. I'm rather new at submitting patches, so please be gentle with me. :-) Another bug I noticed: If I select 'Search' in the class hierarchy of the the namespace browser while I already selected a class, all windows freeze. Is there a list of bugs somewhere? Kind regards, -- Jan Hidders
SyntaxHighlightNonKeywordMethods.diff
Description: Text Data
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk
Date: May 10, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<20030509230054.6ddb3f53.raquel@xxxxxxxxxxxxxxxx>
> ======================================= > 3 of 84 tests failed > Please report to help-smalltalk@xxxxxxx > ======================================= Which? On what system (I see from the headers that's a i586-pc-linux-gnu), but...? |_ _ _ __ |_)(_)| ),' ------- '--- > make[2]: *** [check-TESTS] Error 1 > make[2]: Leaving directory > `/home/raquel/downloads/programs/LinuxTools/smalltalk-2.1.2/tests' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory > `/home/raquel/downloads/programs/LinuxTools/smalltalk-2.1.2/tests' > make: *** [check-recursive] Error 1 > > > -- > Raquel > ============================================================ > A person reveals his character by nothing so clearly as the joke he > resents. > --G. C. Lichtenberg > > > > _______________________________________________ > help-smalltalk mailing list > help-smalltalk@xxxxxxx > http://mail.gnu.org/mailman/listinfo/help-smalltalk > >
Date: May 09, 2003
From: "Bonzini" <bonzini@xxxxxxx>
I'm currently uploading GNU Smalltalk 2.1.2 to
ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.1.2.tar.gz
Diffs relative to the previous release are
ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.1.1-2.1.2.diff.gz
The interesting changes include:
* builds under Linux/PPC and with gcc 2.x (I'm very sorry for the latter)
* better error checking in ObjectMemory>>#snapshot:
* fixing the class mutation that Mike reported
* Mike's patch for copying stack traces
* Nicolas' bugfix for File>>#extensionFor:
The biggest reason to upgrade would be that if you are using GCC 2.x or running
under
Linux/PPC, 2.1.1 would not build for you. Otherwise, there are still a few
interesting
changes but you can save yourself a 3 megabyte download. :-)
Most of the changes indeed are small changes in the configury:
* a supposedly more thorough detection of Tcl/Tk
* a --disable-generational-gc switch for those releases of MacOS X which lock
up in the
configuration of libsigsegv
This release has been tested on
i686-pc-linux-gnu
i686-pc-cygwin
Pre-releases (but not exactly the latest tarballs) were run on
sparc-sun-solaris2.8
powerpc-unknown-linux-gnu
alpha-unknown-linux-gnu
ia64-unknown-linux-gnu
alpha-unknown-freebsd
alpha-unknown-netbsd
Other Linux and Solaris platforms should give no problems. HP/UX should not as
well,
but I'm not so sure as for Linux and Solaris.
I've put quite a lot of care in this release; of course I might have missed
something,
so don't hesitate to tell me about any problem that you might encounter.
However I
hope that it remains stable for quite a long time (say until September).
Have fun,
Paolo
Date: May 09, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<200305090853.33144.jan.hidders@xxxxxxxxxx>
> Is it known that sometimes the syntax highlighting doesn't work? For an > example see the arithmetic methods for class Set. Yes, but it's good enough that I did not track it down. :-) > I also noticed that if you select the first message category for the first > time, the method list first very briefly shows a list of the messages in the > last (?) message category and after that shows the proper list. Interesting. > Sounds like a > nice small exercise to get more acquainted with the Blox classes, so would it > be interesting if I tried to come up with a patch for that? Yes, of course. Also take a look at the TODO list for the browser, there are a few more small things there. After I take a look at the patch I'll decide if it needs paperwork (FSF copyright assignment). Paolo
Date: May 09, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<200305081931.38789.jan.hidders@xxxxxxxxxx><000701c315e3$4f1f0ba0$3b4693c8@robertoa
> <200305090826.07412.jan.hidders@xxxxxxxxxx>
> This probably should be fixed ASAP. Yes, it's going to. :-( Paolo
Date: May 09, 2003
From: Jan Hidders <jan.hidders@xxxxxxxxxx>
Just two small questions. Is it known that sometimes the syntax highlighting doesn't work? For an example see the arithmetic methods for class Set. I also noticed that if you select the first message category for the first time, the method list first very briefly shows a list of the messages in the last (?) message category and after that shows the proper list. Sounds like a nice small exercise to get more acquainted with the Blox classes, so would it be interesting if I tried to come up with a patch for that? Kind regards, -- Jan Hidders
Date: May 09, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<200305081931.38789.jan.hidders@xxxxxxxxxx>
gcc 2.1.1 fails to compile (by mistake) under gcc 3.x only. Use 2.1 (it is about the same as 2.1.1 under Linux), or wait for 2.1.2 which I am holding notwithstanding this bug because I want to have high quality and would like to open the 2.2 branch just after it that release is out. |_ _ _ __ |_)(_)| ),' ------- '---
Date: May 09, 2003
From: Jan Hidders <jan.hidders@xxxxxxxxxx>
In-reply-to:
<000701c315e3$4f1f0ba0$3b4693c8@robertoa
>
References:
<200305081931.38789.jan.hidders@xxxxxxxxxx> <000701c315e3$4f1f0ba0$3b4693c8@robertoa
>
Hello Roberto, Thanks for the quick help. There actually seem to be two bugs in lib-src/ansidecl.h in version 2.1.1. The current text contains: ----- #ifndef __attribute__ # if !defined __GNUC__ || !defined __GNUC_MINOR__ # define __attribute__ (x) # elif (__GNUC__ * 1000 + _GNUC_MINOR) < 2007 # define __attribute__ (x) # endif #endif ----- The first error is that in the third line is says "_GNUC_MINOR" and not "__GNUC_MINOR__". That is why this definition is used by mistake on my and your gcc version 2.95.3. it shouldn't have. The second error (which you already indicated) is that on the third and fifth line there is a space between "__attribute__" and "(x)". However, that defines "__attribute__" as "(x)" but what you really want is that "__attribute__(x)" is defined as "" (empty). So that is not a gcc error, the spaces simply shouldn't be there. Perhaps you thought this was a gcc2 error because for gcc3 this code simply isn't executed. This probably should be fixed ASAP. Kind regards, -- Jan Hidders
Date: May 09, 2003
From: "Roberto Amorim" <roberto@xxxxxxxxxxxxxxxx>
References:
<200305081931.38789.jan.hidders@xxxxxxxxxx>
> Hello All,
Hi Jan...
> I tried to compile version 2.1.1 but couldn't. This was a bit surprising
> because 2.1 compiled flawlessly. This is on Suse Linux 7.3 with gcc
version
> 2.95.3 20010315 (SuSE). I tried adding flags like -ansi but that didn't
seem
> to matter.
>
> The errors that Make gave started with:
>
> In file included from gstpriv.h:462,
> from interp.c:36:
> input.h:104: parse error before `('
> input.h:110: parse error before `('
> input.h:115: parse error before `('
> input.h:121: parse error before `('
(...)
I found the same error when compiling on FreeBSD 4.8 on i386, gcc 2.95.3.
After some research and some talking with pb, I've found it's some sort of
bug with gcc 2.X. To compile successfully, look for a macro definition on
the ansidecl.h file (under the libgst dir, IIRC - I don't have the source
code ready here) with the code "__attribute__ (x)" and remove the space,
turning it into "__attribute__(x)".
That should enable you to compile it. If for some reason you don't find it,
I'll be happy to post a patch here later, as soon as I have access to my
FreeBSD box again.
Please post here if that solves your problem (or if it doesn't).
Date: May 08, 2003
From: Jan Hidders <jan.hidders@xxxxxxxxxx>
Hello All,
I tried to compile version 2.1.1 but couldn't. This was a bit surprising
because 2.1 compiled flawlessly. This is on Suse Linux 7.3 with gcc version
2.95.3 20010315 (SuSE). I tried adding flags like -ansi but that didn't seem
to matter.
The errors that Make gave started with:
--- 8< --- 8< --- 8< ---
In file included from gstpriv.h:462,
from interp.c:36:
input.h:104: parse error before `('
input.h:110: parse error before `('
input.h:115: parse error before `('
input.h:121: parse error before `('
In file included from gstpriv.h:477,
from interp.c:36:
sysdep.h:195: parse error before `('
In file included from /usr/include/errno.h:36,
from ../snprintfv/snprintfv/compat.h:22,
from ./printf.in:33,
from gstpriv.h:486,
from interp.c:36:
/usr/include/bits/errno.h:39: parse error before `('
In file included from ../snprintfv/snprintfv/compat.h:27,
from ./printf.in:33,
from gstpriv.h:486,
from interp.c:36:
/usr/include/inttypes.h:296: parse error before `('
/usr/include/inttypes.h:300: parse error before `('
In file included from gstpriv.h:486,
from interp.c:36:
./printf.in:390: parse error before `('
./printf.in:421: parse error before `('
....
--- 8< --- 8< --- 8< ---
If I look in input.h then the differences between the old and the new at the
places where the errors appeared are like the following:
old input.h:
> /* Emits a warning, with the current file and line in front of it, on
> the standard error descriptor. */
> extern void _gst_warningf (const char *str,
> ...) FN_PRINTF(1);
new input.h:
> /* Emits a warning, with the current file and line in front of it, on
> the standard error descriptor. */
> extern void _gst_warningf (const char *str,
> ...) ATTRIBUTE_PRINTF_1;
So does anybody know what is going wrong here?
And while I have your attention let me also ask some small questions:
* Is the page at http://www.smalltalk.org/versions/GNUSmalltalk.html really
the official GNU smalltalk site? I thought that was
http://www.gnu.org/software/smalltalk/smalltalk.html .
* And how come that the links to "Stable" and "Alpha" on the two pages seem to
lead to two different directories? It is correct that there is no alpha
version at the moment?
* Is it correct that version 2.0.3 is the latest stable release as is
mentioned on the first page?
* Why is there not a sourceforge project? Wouldn't that make bug-reporting a
bit more stream-lined?
Ok. I'll stop now. :-) Well, just one more. Is there somewhere an easy
introduction to using the BLOX paradigm (as opposed to MVC) or can this only
done by looking around in the implementation of the browser?
Ok. Now I will really stop, but not before I have said thanks to the people
who have helped creating a really free implementation of my favourite
programming language. Thanks. :-)
Kind regards,
-- Jan hidders
Date: May 06, 2003
From: "Bonzini" <bonzini@xxxxxxx>
References:
<20030504042534.GA15465@xxxxxxxxxx>
> I've noticed that when running the Blox browser if you try to save the > image to the default root-owned unwriteable location, stuff breaks. I suspect something related to ObjectMemory events (#aboutToSnapshot, #returnedFromSnapshot, etc.) but I am not sure. > If you select the unwriteable file it doesn't tell you that it failed. This was "a by-design bug" (i.e. it always worked like this -- the primitive never failed except if the parameter was not a String). The fix is not easy because it exposes a latent bug in the handling of failed primitives (it supposed that before failing the primitive did not call back to Smalltalk, which was true before this change), it will be in 2.1.2 (expect it in one or two weeks, it will be ready for Debian packaging). > As a side note, I also noticed that if you have a gst.im in the > current directory, gst ignores it in favour of the system default > location... Is that correct behavior now? Yes, if you want a local gst.im set SMALLTALK_IMAGE to its path. Paolo
Date: May 04, 2003
From: David MENTRE <david.mentre@xxxxxxxxxx>
In-reply-to:
<001b01c30dab$4373b110$3bdc1d97@bonz>
References:
<001b01c30dab$4373b110$3bdc1d97@bonz>
"Bonzini" <bonzini@xxxxxxx> writes: > This patch makes GNU Smalltalk compile and pass "make check" under linux/ppc. > It is a It also compiles and pass "make check" on my iBook. Many thanks paolo. Best regards, d. -- david.mentre@xxxxxxxxxx
Date: May 04, 2003
From: Brett Cundal <bcundal@xxxxxxxxxx>
Hiya, I've noticed that when running the Blox browser if you try to save the image to the default root-owned unwriteable location, stuff breaks. I'm starting blox using the gst-blox script in the Debian package: "gst -qK browser/Run.st", and I'm running gst 2.1.1. If you start up with the default image and select save image, it doesn't notify you that it can't write the image. After that the Namespace and Class browsers load but are empty, and lots of other things break. Likewise if you select "save image as..." and select the unwriteable file it doesn't tell you that it failed. Anyone able to reproduce that? As a side note, I also noticed that if you have a gst.im in the current directory, gst ignores it in favour of the system default location... Is that correct behavior now? -- Brett
pgpFmkJ1cB730.pgp
Description: PGP signature
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk