|
Prev: paypal whoelsale AF,jacket wholesale (paypal accept)(www.top-saler.com) paypal whoelsale g star,jeans,jacket(paypal accept)(www. top-saler.com) good quality soccer suit wholesale (paypal accept)(www.top-saler.com)
Next: A few more Package/Symbol Questions
From: Sashank Varma on 14 Apr 2008 18:48 On Apr 14, 3:44 pm, dstein64 <DStei...(a)gmail.com> wrote: > I am new to Common Lisp, but maybe the symbols are being interned to a > different package than the package you are in when calling them. If > this is the case, there would probably something that looks like: (in- > package packagename) in the code. From the REPL, you can access these > functions and other symbols by switching to the relevant package by > typing (in-package packagename) where packagename is the same as in > the code, or by typing 'packagename:x' instead of just 'x' when trying > to access x. I hope this helps. Again, I am still new to the language. I should have mentioned: Everything's happening in CL-USER.
From: Sashank Varma on 14 Apr 2008 19:08 On Apr 14, 3:48 pm, Sashank Varma <varm...(a)gmail.com> wrote: > On Apr 14, 3:44 pm, dstein64 <DStei...(a)gmail.com> wrote: > > > I am new to Common Lisp, but maybe the symbols are being interned to a > > different package than the package you are in when calling them. If > > this is the case, there would probably something that looks like: (in- > > package packagename) in the code. From the REPL, you can access these > > functions and other symbols by switching to the relevant package by > > typing (in-package packagename) where packagename is the same as in > > the code, or by typing 'packagename:x' instead of just 'x' when trying > > to access x. I hope this helps. Again, I am still new to the language. > > I should have mentioned: Everything's happening in CL-USER. Just to make sure, I compiled/loaded the file again and then searched each package for occurrences of the "center", which occurs in several special variables, method names, and macro names. None were found. ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ... ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl ;;; Fasl write complete CL-USER> (mapc #'(lambda (package) (format t "~%~A:" (package-name package)) (apropos "center" package) (format t "~%")) (list-all-packages)) ACL-SOCKET: ACLMOP: ASDF: COM.GIGAMONKEYS.ASDF-EXTENSIONS: COMMON-LISP: COMMON-LISP-USER: COMPILER: CROSS-REFERENCE: DEBUGGER: DEFSYSTEM: EXCL: EXCL.SCM: FOREIGN-FUNCTIONS: GARBAGE: INSPECT: KEYWORD: LEP: LEP-IO: MULTIPROCESSING: NET.URI: NULL-PACKAGE-REPLY-SESSION: PROFILER: SLIME-NREGEX: SWANK: SWANK-BACKEND: SWANK-COMPLETION-TEST: SWANK-IO-PACKAGE: SWANK-LOADER: SWANK-MOP: SYSTEM: TOP-LEVEL: (#<The ACL-SOCKET package> #<The ACLMOP package> #<The ASDF package> #<The COM.GIGAMONKEYS.ASDF-EXTENSIONS package> #<The COMMON-LISP package> #<The COMMON-LISP-USER package> #<The COMPILER package> #<The CROSS-REFERENCE package> #<The DEBUGGER package> #<The DEFSYSTEM package> ...) CL-USER>
From: Sashank Varma on 14 Apr 2008 19:40 One more tidbit. On Apr 14, 2:50 pm, Sashank Varma <varm...(a)gmail.com> wrote: > > ; SLIME 2005-11-22 > ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ... > ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp > ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl > ;;; Fasl write complete I just checked. The resulting fasl file is only 4k. > However, I have had success with the following workaround: If I split > the file into 6 smaller files, and compile and load each separately > (with C-c C-k), everything works fine. By contrast, these files range in size from 28K to 124K. So it looks like C-c C-k is not compiling the original source file, but it is compiling the smaller ones. Now I'm wondering whether I'm running up against the limits of the ACL 8.1 Express version. It is a trial version after all.
From: Sashank Varma on 14 Apr 2008 21:55 On Apr 14, 4:07 pm, vanekl <va...(a)acd.net> wrote: > > I don't have anything like your setup, so I'm just riffing here. > What happens if you rename 4caps-2.1.lisp to just 4caps.lisp and > do a C-c C-k? The multiple "dots" in the filename may be a problem. Nice idea. I was hopeful for a moment...but it didn't work.
From: Madhu on 15 Apr 2008 00:56
[CC attempted to slime-devel list to report a different bug, (*) at the bottom of my reply] * Sashank Varma wrote in article <95319b1d-190d-493c-b0c8-14d1a5491249(a)k10g2000prm.googlegroups.com> : on Mon, 14 Apr 2008 16:40:44 -0700 (PDT): | |> ; SLIME 2005-11-22 |> ;;;; Compile file /Users/sv0f/Desktop/4caps-2.1.lisp ... |> ;;; Compiling file /Users/sv0f/Desktop/4caps-2.1.lisp |> ;;; Writing fasl file /Users/sv0f/Desktop/4caps-2.1.fasl |> ;;; Fasl write complete | | I just checked. The resulting fasl file is only 4k. q| |> However, I have had success with the following workaround: If I split |> the file into 6 smaller files, and compile and load each separately |> (with C-c C-k), everything works fine. | | By contrast, these files range in size from 28K to 124K. | | So it looks like C-c C-k is not compiling the original source file, | but it is compiling the smaller ones. | | Now I'm wondering whether I'm running up against the limits of the ACL | 8.1 Express version. It is a trial version after all. Did you try starting up alisp (without SLIME in the picture) and calling (compile-file 4caps-2.1.lisp"). Is the fasl still 4k ? It is likely that the problem you face is an external-format issue. The original source file may not be of the correct CRLF/LF type which ACL is expecting, and ACL may be reading it as a single comment and generating an empty fasl. However your smaller files may have been saved in a different coding system, which ACL groks correctly. Other lisps (CMUCL, LW) have had similar issues reported. -- Madhu PS: Your slime version is very old. I've been using acl81_express (alisp) on linux with a more recent Slime (CVS 2008-04-06) for a few days now and have been compiling > 1Mb source files. (*) I've noticed a different intermittent problem where forms were being truncated before being sent to ACL (via a file in /tmp) when *print-lines* is non-NIL. This is a bug in swank-allegro.lisp which should be rebinding printer variables when printing stuff to send to lisp. Setting *print-lines* to NIL solves this |