Thread: [Sbcl-devel] (no subject) | Steel Bank Common Lisp (2024)

[telent.net is having hardware problems, hence alternate address while new MX records spread around the net]So I'm still having Fun With GC (the first 10% is 90% of the work, andthe second 90% is another 90% of the work...) but I happened to noticethe FIXME comment in interrupt_handle_pending (runtime/interrupt.c) /* FIXME: How come we unconditionally copy from pending_mask into * the context, and then test whether pending_signal is set? If * pending_signal wasn't set, how could pending_mask be valid? */And the answer is - or appears to be - because interrupt_maybe_gc setit that way (look in the #ifndef __i386__ bit). We can't GC during apseudo-atomic, so we set maybe_gc_pending=1 andarch_set_pseudo_atomic_interrupted(..) When we come out ofpseudo_atomic we're marked as interrupted, so we callinterrupt_handle_pending, which does the GC using the pending context(it needs a context so that it has registers to use as GC roots) thennotices there's no actual interrupt handler to call, so doesn't.That's the second question answered, anyway. Why we still need tocopy the pending_mask into the context given that we're now done withthe context anyway, I couldn't say.Or maybe I'm just completely off the wall (it is, after all, late).Who's to say?-dan-- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 

 (let ((*print-length* nil)=0D (*print-pretty* nil))=0D (print #S(...)))=0Dproduces=0D debugger invoked on condition of type TYPE-ERROR:=0D The value NIL is not of type (OR SINGLE-FLOAT DOUBLE-FLOAT RA=TIONAL).=0D=0DError is in `src/code/target-defstruct.lisp', in function=0D`default-structure-print':=0D (and (not *print-readably*)=0D (>=3D index *print-length*)))=0DIt should be=0D (and (not *print-readably*)=0D *print-length*=0D (>=3D index *print-length*)))=0D=0DAlexey Dejneka=0D=0D--=0D=F3=C5=C7=CF=C4=CE=D1 =D5=C4=C1=DE=CE=D9=CA =C4=C5=CE=D8 =C4=CC=D1 =D4=CF==C7=CF, =DE=D4=CF=C2=D9 =DA=C1=D7=C5=D3=D4=C9 =D0=CF=DE=D4=D5 =CE=C1 =F1==CE=C4=C5=CB=D3=C5!=0D=E2=C5=D3=D0=CC=C1=D4=CE=C1=D1, =D5=C4=CF=C2=CE=C1=D1 =C9 =C2=C5=DA=CF=D0==C1=D3=CE=C1=D1 =D0=CF=DE=D4=C1 =CE=C1 http://www.yandex.ru=0D=0D

On Thu, Jun 14, 2001 at 07:06:50AM +0400, Alexey Dejneka wrote:> (let ((*print-length* nil)> (*print-pretty* nil))> (print #S(...)))> produces> debugger invoked on condition of type TYPE-ERROR:> The value NIL is not of type (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL).> > Error is in `src/code/target-defstruct.lisp', in function> `default-structure-print':> (and (not *print-readably*)> (>= index *print-length*)))> It should be> (and (not *print-readably*)> *print-length*> (>= index *print-length*)))Thank you. I've merged your fix into sbcl-0.6.12.35, just checked in.-- William Harold Newman <wil...@ai...>pending patches from sbcl-devel: nonePGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

- (**current-segment**- ;; FIXME: I can't see why we have to use- ;; (MACROLET ((LOSE () (ERROR ..))) (LOSE))- ;; instead of just (ERROR "..") here.- (macrolet ((lose ()-(error "You can't use INST without an ~-ASSEMBLE inside emitters.")))- (lose))))Hmmn, SYMBOL-MACROLET on a special is a little twisted, and I guess otherLisps don't like it? And the macrolet/macroexpand of ..inherited-labels..is a bit precious too, since we're defining a macro that we never have anyintention of evaluating just to squirrel some info away in the lexicalenvironment. In the old days the manly macro hackers had COMPILER-LET todo this sort of thing, but then ANSI took it away...Anyway, the reason for the rather peculiar LOSE local macro is to cause acompile-time ERROR if any reference to **current-segment** appears in thecode without being shadowed by the correct definition. If you simply said(error ...) then the error would only happen at runtime. I think that whathappened is that someone got burned by forgetting to use an ASSEMBLE form,and then some code quietly went into *the wrong segment*.This is not good, but the if the symbol macrolet had a different name thanthe special, then you would at least have gotten undefined variable erroron the symbol macro reference.It appears that there is in fact no reason for the special binding of**current-segment**, and this is what should be flushed, not the symbolmacrolet. If I am correct that INST, EMIT-LABEL, etc. are always called inthe lexical scope of an ASSEMBLE, then the special can be dispensed withentirely. However, it is possible that somewhere someone is calling afunction from a vop generator that calls INST, making use of the specialbinding. This is easily enough found by removing the special and lookingfor undefined var warnings, and easily enough fixed by passing the segmentin and adding an ASSEMBLE.Referencing a special is, needless to say, more costly than a local, andthe assembler is one of the more performance critical parts of thecompiler. Does it make a big difference? You won't know without testing,and just timing an entire compile probably isn't going to give you enoughsignal-to-noise to see this effect. You have to time something likeGENERATE-CODE. The difference may be not so big on an x86 as long as thecode is compiled unsafe, since with 8 registers, it's probably on the stackalready, so you've got one memory reference. Adding another to get thesymbol only doubles it. Doing a boundp check also hurts. Rob

On Fri, Mar 08, 2002 at 05:46:25PM -0500, Rob MacLachlan wrote:> Hmmn, SYMBOL-MACROLET on a special is a little twisted, and I guess other> Lisps don't like it? It's actually specifically forbidden by ANSI... "an error of typePROGRAM-ERROR is signalled."> Anyway, the reason for the rather peculiar LOSE local macro is to cause a> compile-time ERROR if any reference to **current-segment** appears in the> code without being shadowed by the correct definition. If you simply said> (error ...) then the error would only happen at runtime. I think that what> happened is that someone got burned by forgetting to use an ASSEMBLE form,> and then some code quietly went into *the wrong segment*.Ah, yes, of course! Thanks, that makes more sense now. > It appears that there is in fact no reason for the special binding of> **current-segment**, and this is what should be flushed, not the symbol> macrolet. If I am correct that INST, EMIT-LABEL, etc. are always called in> the lexical scope of an ASSEMBLE, then the special can be dispensed with> entirely. However, it is possible that somewhere someone is calling a> function from a vop generator that calls INST, making use of the special> binding. This is easily enough found by removing the special and looking> for undefined var warnings, and easily enough fixed by passing the segment> in and adding an ASSEMBLE.Yes, I thought of this possibility during the night (who says we can'tbe productive 24 hours a day...), but thanks for giving me a littlemore impetus into following it up. I'll report back as and when I'vegiven it a spin.Cheers,Christophe-- Jesus College, Cambridge, CB5 8BL +44 1223 510 299http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)(set-dispatch-macro-character #\! #\$ #'pling-dollar)

Hi,The attached file is a reduced test case for a compile warning in portable allegroserve that started happening some time this month. Removing either of call-next-method or symbol-macrolet makes the symptoms go away, as does simplifying the class slot to hold a number instead of the structure (with accompanying changes to the index symbol-macro). Is anyone familiar with this area of sbcl and could point me to relevant files?Thanks,Rudi; compiling DEFMETHOD FROB (BUFFERED-STREAM-MIXIN):; file: /Users/rudi/Source/bug.lisp; in: DEFMETHOD FROB (BUFFERED-STREAM-MIXIN); (DEFMETHOD FROB; ((STREAM BUFFERED-STREAM-MIXIN)); (SYMBOL-MACROLET ((INDEX #)); (SETF INDEX 0)); (CALL-NEXT-METHOD)); --> PROGN SB-PCL::LOAD-DEFMETHOD SB-PCL::LOAD-DEFMETHOD LIST*; --> SB-INT:NAMED-LAMBDA FUNCTION MACROLET; --> SB-PCL::FAST-LEXICAL-METHOD-FUNCTIONS; --> SB-PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET; --> SB-PCL::BIND-LEXICAL-METHOD-FUNCTIONS SB-PCL::CALL-NEXT-METHOD-BIND LET; --> FLET SB-PCL::WITH-REBOUND-ORIGINAL-ARGS LET SB-PCL::BIND-ARGS LET*; --> SB-PCL::PV-BINDING SB-PCL::PV-BINDING1 SB-PCL::PV-ENV LET LET; --> SB-PCL::GET-SLOTS-OR-NIL BLOCK WHEN COND IF; ==>; (COND);; caught WARNING:; The binding of ARRAY is not a SIMPLE-VECTOR:; NIL

Rudi Schlatte <ru...@co...> writes:> The attached file is a reduced test case for a compile warning in> portable allegroserve that started happening some time this month.> Removing either of call-next-method or symbol-macrolet makes the> symptoms go away, as does simplifying the class slot to hold a number> instead of the structure (with accompanying changes to the index> symbol-macro). Is anyone familiar with this area of sbcl and could> point me to relevant files?Here's a patch (X marks the spot; similar is wanted ininstance-write-internal and instance-boundp-internal).The warning appears to be genuine, but warning about PCL-internalcode, not user code. The attached patch probably doesn't do wondersto performance, though it might be relatively neutral; better might beto write a GET-SLOTS-OR-LOSE function and use that in the appropriateplace.(defmacro instance-read-internal (pv slots pv-offset default &optional type) (unless (member type '(nil :instance :class :default)) (error "illegal type argument to ~S: ~S" 'instance-read-internal type)) (if (eq type :default) default (let* ((index (gensym)) (value index)) `(locally (declare #.*optimize-speed*) (when (null ,slots) (bug "Argh, SLOTS is NULL!")) ; X (let ((,index (pvref ,pv ,pv-offset))) (setq ,value (typecase ,index ,@(when (or (null type) (eq type :instance)) `((fixnum (clos-slots-ref ,slots ,index)))) ,@(when (or (null type) (eq type :class)) `((cons (cdr ,index)))) (t +slot-unbound+))) (if (eq ,value +slot-unbound+) ,default ,value))))))Cheers,Christophe-- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

Rudi Schlatte <ru...@co...> writes:> The attached file is a reduced test case for a compile warning in> portable allegroserve that started happening some time this month.> Removing either of call-next-method or symbol-macrolet makes the> symptoms go away, as does simplifying the class slot to hold a number> instead of the structure (with accompanying changes to the index> symbol-macro). Is anyone familiar with this area of sbcl and could> point me to relevant files?Sorry for the delay. I've merged what I think is a fix for this (withwhat I think is minimal collateral damage) into sbcl-0.8.6.17. Beaware that I'm not at all sure that my fix is right, so please shoutif you observe any weird clos-related behaviour.Cheers,Christophe-- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

Howdy all,In followup to earlier discussion of SBCL / Darwin building, the attachedpatch should make everything OK by backing the optimization off to O2 (notO3). It also cleans up the linker flags, many of which were extraneous.--Brian Mastenbrookhttp://www.cs.indiana.edu/~bmastenb/bma...@cs...

On Fri, 28 May 2004, Brian Mastenbrook wrote:> In followup to earlier discussion of SBCL / Darwin building, the attached> patch should make everything OK by backing the optimization off to O2 (not> O3). It also cleans up the linker flags, many of which were extraneous.Thank you, this has been merged in 0.8.10.65.Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time."

Hi all.Thanks for porting SBCL to Windows.I have successfully built SBCL from the 0.9.9 source tarball using the0.9.9 binary provided under MSYS with MinGW32 gcc 3.4.5.While trying to add Win32 support for run-program to the released 0.9.9source I had some bizarre trouble with my newly modified"src/runtime/run-program.c".During the build with the _modified_ file, it is overwritten _before_gcc is called with an error message as follows:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMicrosoft (R) File Expansion Utility Version 5.1.2600.0 Copyright (C)Microsoft Corp 1990-1999. All rights reserved.No destination specified for: ./src/runtime/run-program.c.=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dwhich in turn causes gcc to barf as follows:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....gcc -g -Wall -O3 -mno-cygwin -I. -c -o purify.o purify.cpurify.c: In function `ptrans_boxed': purify.c:522: warning: implicitdeclaration of function `bcopy' gcc -g -Wall -O3 -mno-cygwin -I. -c -oregnames.o regnames.c gcc -g -Wall -O3 -mno-cygwin -I. -c -orun-program.o run-program.crun-program.c:1: error: syntax error before "File" run-program.c:1:47:too many decimal points in number make: *** [run-program.o] Error 1make: Leaving directory `/c/lang/source/sbcl/sbcl-0.9.9/src/runtime'=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D==3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DI'm finding the SBCL build system a little obscure at this early stagein my exposure to it so I thought I'd ask the experts.Any ideas?CheersMike Thomas.

On 15. Feb 2006, at 00:09, Mike Thomas wrote:> While trying to add Win32 support for run-program to the released > 0.9.9> source I had some bizarre trouble with my newly modified> "src/runtime/run-program.c".>> During the build with the _modified_ file, it is overwritten _before_> gcc is called with an error message as follows:>> ======================================================================> Microsoft (R) File Expansion Utility Version 5.1.2600.0 Copyright (C)> Microsoft Corp 1990-1999. All rights reserved.>> No destination specified for: ./src/runtime/run-program.c.> ======================================================================My guess is that cygwin/msys binaries are after Windows' expand.exe in your path. Does it work if you comment out the linetools-for-build/canonicalize-whitespacein make.sh?Cheers,Rudi

<mi...@pa...> wrote:> During the build with the _modified_ file, it is overwritten _before_> gcc is called with an error message as follows:make.sh calls tools-for-build/canonicalize-whitespace to remove tabsand trailing whitespace from .lisp and .c files. This is done bycalling "expand". Unfortunately on Windows "expand" names some sort ofobsolete backup utility, which destroys the file.You can either: * Not write tabs into the file in the first place * Comment out the call to canonicalize-whitespace in make.sh-- Juho Snellman

Looks like sbcl doesn't compile on sparc: From http://sbcl.static.net/buildbot/sbcl-linux-sparc/builds/5/step- compile/1:> /usr/lib/gcc/sparc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m > elf32_sparc -Y P,/usr/lib -export-dynamic -dynamic-linker /lib/ld- > linux.so.2 -relax -o sbcl /usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib/crt1.o /usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib/crti.o /usr/lib/gcc/sparc-linux-gnu/4.1.2/ > crtbeginS.o -L/usr/lib/gcc/sparc-linux-gnu/4.1.2 -L/usr/lib/gcc/ > sparc-linux-gnu/4.1.2 -L/usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib alloc.o > backtrace.o breakpoint.o coreparse.o dynbind.o funcall.o gc- > common.o globals.o interr.o interrupt.o largefile.o monitor.o os- > common.o parse.o print.o purify.o pthread-futex.o pthread-lutex.o > regnames.o run-program.o runtime.o save.o search.o thread.o time.o > util.o validate.o vars.o wrap.o sparc-arch.o linux-os.o sparc-linux- > os.o cheneygc.o sparc-assem.o ldso-stubs.o -ldl -lm -lgcc --as- > needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as- > needed /usr/lib/gcc/sparc-linux-gnu/4.1.2/crtend.o /usr/lib/gcc/ > sparc-linux-gnu/4.1.2/../../../../lib/crtn.o>> interrupt.o: In function `handle_trap':> /home/sbclbot/sparc/sbcl-linux-sparc/build/src/runtime/interrupt.c: > 1344: undefined reference to `arch_handle_single_step_trap'> collect2: ld returned 1 exit status> make[1]: *** [sbcl] Error 1This code in params.lisp:> ;; Stepper actually not implemented on Sparc, but these constants> ;; are still needed to avoid undefined variable warnings during sbcl> ;; build.> single-step-around> single-step-before)And this in interrupt.c (which was changed in "1.0.4.13: refactor trap handling"):> #ifdef trap_SingleStepAround> case trap_SingleStepAround:> case trap_SingleStepBefore:> arch_handle_single_step_trap(context, trap);> break;> #endifappear to be in conflict.James

James Y Knight <fo...@fu...> writes:> Looks like sbcl doesn't compile on sparc:I think in fact it might not compile on anything that's not a PPC oran x86oid, as the lack of arch_handle_single_step_trap (even thoughthe traps are defined) seems to be common. (It's possible thatsomething in genesis could save the other platforms, but I can't seeit; I've only verified this on sparc/linux, though).There are several possible fixes:* don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on platforms that don't use them, then genesis won't #define them;* write null arch_handle_single_step_trap() definitions on currently failing platforms;* conditionalize the lisp code which uses single-step-around or single-step-before, so that the symbols don't need to be defined on platforms where single-stepping doesn't work;* (my preferred solution) implement single-stepping on all platforms.So, firstly, am I right that the build is hosed on minority platforms?And secondly, what needs to be done?(Aside: the powerpc code in call.lisp which seems to be dealing withthis looks like it could benefit from using the LOAD-SYMBOL-VALUEmacro)Cheers,Christophe

Christophe Rhodes wrote:> James Y Knight <fo...@fu...> writes:> > > Looks like sbcl doesn't compile on sparc:> > I think in fact it might not compile on anything that's not a PPC or> an x86oid, as the lack of arch_handle_single_step_trap (even though> the traps are defined) seems to be common. (It's possible that> something in genesis could save the other platforms, but I can't see> it; I've only verified this on sparc/linux, though).It does not build on mips for that reason.> There are several possible fixes:> > * don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on> platforms that don't use them, then genesis won't #define them;> > * write null arch_handle_single_step_trap() definitions on currently> failing platforms;> > * conditionalize the lisp code which uses single-step-around or> single-step-before, so that the symbols don't need to be defined on> platforms where single-stepping doesn't work;> > * (my preferred solution) implement single-stepping on all platforms.The last one is what I had a stab at, but I probably won't have thetime to get it finished soon.Thiemo

Christophe Rhodes <cs...@ca...> writes:> There are several possible fixes:> > * don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on> platforms that don't use them, then genesis won't #define them;> > * write null arch_handle_single_step_trap() definitions on currently> failing platforms;This seems like the best one of the kludgy "let's not implement singlestepping everywhere" fixes.> * conditionalize the lisp code which uses single-step-around or> single-step-before, so that the symbols don't need to be defined on> platforms where single-stepping doesn't work;> > * (my preferred solution) implement single-stepping on all platforms.> > So, firstly, am I right that the build is hosed on minority platforms?Right, this was due to the trap handling refactoring that Nikodemusdid.> And secondly, what needs to be done?Just the following for Alpha, Mips and Sparc.* Flesh out the stub step-instrument-before-vop. Just load a symbol value, and trigger a trap if it's not NIL.* Implement the "around" instrumentation in the call vop. Basically with code similar to the step-instrument-before-vop, but also needs to encode the TN offset for the register that contains the fdefn or function that's being called. * Implement arch_handle_single_step_trap. This should dig out the TN from the trap code and call handle_single_step_trap.* On Sparc, sb-di::handle-single-step-around-trap probably also needs to handle the different format of the fdefn objects (which store the raw address of the function, not the function object itself).In theory, that should be it, and those vops should be easy towrite. (Especially now that you mentioned LOAD-SYMBOL-VALUE). Justneed someone with access to these platforms. In practice, there willalmost certainly be further complications for other platformidiosyncracies which I didn't manage to hit with the x86oids or ppc.-- Juho Snellman

Juho Snellman <js...@ik...> writes:>> And secondly, what needs to be done?>> Just the following for Alpha, Mips and Sparc.>> * Flesh out the stub step-instrument-before-vop. Just load a symbol value,> and trigger a trap if it's not NIL.> * Implement the "around" instrumentation in the call vop. Basically > with code similar to the step-instrument-before-vop, but also needs> to encode the TN offset for the register that contains the fdefn or > function that's being called. > * Implement arch_handle_single_step_trap. This should dig out the TN> from the trap code and call handle_single_step_trap.> * On Sparc, sb-di::handle-single-step-around-trap probably also needs> to handle the different format of the fdefn objects (which store the> raw address of the function, not the function object itself).>> In theory, that should be it, and those vops should be easy to> write. (Especially now that you mentioned LOAD-SYMBOL-VALUE). Just> need someone with access to these platforms. In practice, there will> almost certainly be further complications for other platform> idiosyncracies which I didn't manage to hit with the x86oids or ppc.There was one wrinkle, which I eventually realised after a fair amountof single-stepping and looking (manually, sigh) at register contents:the allocation of the sap in handle_single_step_trap() doesn't updatethe dynamic_space_free_pointer/reg_ALLOC correctly on non-gencgcplatforms, because the fake_foreign_function_call() hasn't occurredyet: causing the corruption visible in<http://paste.lisp.org/display/40560>.(Side note: I'm not sure how it could have been quite so systematic asI saw yesterday, with the failure mode being exactly the same eachtime, but my gut tells me that I'm right anyway).So, the patch for sparc is at<http://www-jcsu.jesus.cam.ac.uk/~csr21/ss-sparc.diff>. However,before it gets merged, we probably need to think about how to restorethe goodness implied by the comment in handle_single_step_trap() thatI've deleted, without bringing back the badness of heap corruption incheneygc that goes with it.Cheers,Christophe

<html><body><p>Greetings.<br>Would you be interested in a home job that allows you to earn up to $10000 per month? No start up fees, no “envelope stuffing” nonsense.<br><br>We proudly present Amato Logistics Co. Ltd.<br><br>The job we offer will not affect your present career, it will only take a small part of your time. <br>The only things you need to have to start running your business with our company are reliable Internet/E-mail access and checking/savings bank account. <br>And of course your decency and willingness to earn.<br><br>The first vacancy is Transfer manager:<br>The nature of the job is payment processing. <br>It is related to online banking operating the funds from either our company or our partners to designated bank account approved by our <br>manager keeping specified money transaction fee as a commission for your services (usually between $150 to $500, no less than $150 per transfer).<br><br>You will receive the funds which our customers/resellers send directly to you and forward it to us or our agents (less your commission)via one of chosen money transfer agencies.<br>The job is rather simple and you won't need any special knowledge to become our partner, though we do require that you are able to act on a very short notice.<br>We can afford to pay such a decent commission only because we keep our customers happy with our promptness.<br><br>And the second is Shipment manager.<br>The job we offer is related to mail. It is an easy part time job that doesn’t require leaving your main occupation. <br>You will be receiving mail and packages for our clients, either repack them or ship them further out following our manager’s instructions. <br><br><br>For those who look for career opportunities it’s a chance of becoming a part of our team in the future (based on your performance), <br>team in which you will be highly respected and decently rewarded - just think about this! We will be hoping to hear from you soon. <a href="mailto:yl...@bu...">yl...@bu...</a><br><br><br>If you would like to get our application form please email us with your request. No fees are asked, just leave your contact details: &quot;random e-mail&quot;<br><br>Write us to: <a href="mailto:yl...@bu...">yl...@bu...</a><br><br>We would appreciate your continued patronage and get in touch with you soon. Thank you!</p></body></html>

Thanks for your work on SBCL William

On Tue, Mar 13, 2001 at 01:45:40AM +0000, da...@ft... wrote:> [telent.net is having hardware problems, hence alternate address while > new MX records spread around the net]> > So I'm still having Fun With GC (the first 10% is 90% of the work, and> the second 90% is another 90% of the work...) but I happened to notice> the FIXME comment in interrupt_handle_pending (runtime/interrupt.c)> > /* FIXME: How come we unconditionally copy from pending_mask into> * the context, and then test whether pending_signal is set? If> * pending_signal wasn't set, how could pending_mask be valid? */> > And the answer is - or appears to be - because interrupt_maybe_gc set> it that way (look in the #ifndef __i386__ bit). We can't GC during a> pseudo-atomic, so we set maybe_gc_pending=1 and> arch_set_pseudo_atomic_interrupted(..) When we come out of> pseudo_atomic we're marked as interrupted, so we call> interrupt_handle_pending, which does the GC using the pending context> (it needs a context so that it has registers to use as GC roots) then> notices there's no actual interrupt handler to call, so doesn't.> > That's the second question answered, anyway. Why we still need to> copy the pending_mask into the context given that we're now done with> the context anyway, I couldn't say.OK, thank you, I've merged your explanation into the comment in 0.6.11.14 (just checked in).-- William Harold Newman <wil...@ai...>software consultantPGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C