* (make-pathname :name "cgi-bin/")
#P"cgi-bin/"
* (merge-pathnames "nav.py" #P"cgi-bin/")
#P"cgi-bin/nav.py" ; **it is ok**
* (merge-pathnames "nav.py" (make-pathname :name "cgi-bin/"))
#P"nav.py" ; why ?
*(defvar bp #P"/media/E/myapp/cgi-bin/")
* bp
#P"/media/E/myapp/cgi-bin/")
* (merge-pathnames "nav.py" bp)
#P"nav.py" ; why ?
* (merge-pathnames "nav.py" #P"/media/E/myapp/cgi-bin/")
#P"/media/E/myapp/cgi-bin/nav.py" ; **it is ok**
I am using sbcl-1.0.54.
Any suggestion is appreciated !
A pathname is a structure that represents a pathname using components, like drive, host, directory, name, etc. See here for more details.
You construct a pathname using make-pathname function with :directory, :name and other keywords, and the function returns an object of type pathname:
CL-USER> (defvar p (make-pathname :directory '(:absolute "home" "test" "docs")))
CL-USER> #P"/home/test/docs/"
The function merge-pathnames as documented here, completes the missing components of the pathname specified with the ones from default-pathname:
CL-USER> (merge-pathnames p "tada.txt")
CL-USER> #P"/home/test/docs/tada.txt"
Edit: it doesn't work for you because you are constructing a pathname with :name and that specifies the name of the file (without extension or :type). So when you call merge-pathnames it doesn't find a missing component in its pathname, because "cgi-bin/" is specified as :name (the filename), and you already got a filename in "nav.py".
Related
Emacs version: 26.3
Slime version: 2.26.1
I start up Emacs.
I open up a simple .lisp file.
(defun testfn (x y)
(+ x y))
(defmacro testmc (form)
form
`(list 1 2 3))
I place my cursor over the symbol defun and issue the keyboard-command M-. (slime-edit-definition).
This should bring me to the definition of defun.
But it doesn't.
It brings me here:
I place my cursor over the symbol defmacro and issue the keyboard-command M-. (slime-edit-definition).
This should bring me to the definition of defmacro.
But it doesn't.
It brings me here:
Why does it do this & how do I fix this
Notice there is a warning in the REPL when trying to find the source of DEFUN:
WARNING: inconsistent 2 form-number-translations
You can replicate it yourself in the REPL:
CL-USER> (let ((slynk::*buffer-package* (find-package :cl))
(slynk::*buffer-readtable* *readtable*))
(slynk:find-definitions-for-emacs "DEFUN"))
WARNING: inconsistent 2 form-number-translations
(("(DEFMACRO DEFUN)"
(:LOCATION (:FILE "/home/chris/data/src/sbcl/src/code/macros.lisp")
(:POSITION 4140)
(:SNIPPET "(setq doc nil)
(let* (;; stuff shared between LAMBDA and INLINE-LAMBDA and NAMED-LAMBDA
(lambda-guts `(,#decls (block ,(fun-name-block-name name) ,#forms)))
(lambda `(lambda ,lambda-list ,#lambda-guts))
(named-lambda `("))))
To find where the warning comes from, you could do as I did first and do a textual search on the repository, or you could use the following alternate method that works better, namely invoke the debugger on warnings:
(handler-bind ((warning (lambda (c) (invoke-debugger c))))
(let ((slynk::*buffer-package* (find-package :cl))
(slynk::*buffer-readtable* *readtable*))
(slynk:find-definitions-for-emacs "DEFUN")))
This comes from SLYNK-SBCL::FORM-NUMBER-POSITION, and the interesting value in the debugger is the source location obtained from SBCL:
#<SB-INTROSPECT:DEFINITION-SOURCE {10369C50F3}>
--------------------
The object is a STRUCTURE-OBJECT of type SB-INTROSPECT:DEFINITION-SOURCE.
PATHNAME: #P"SYS:SRC;CODE;MACROS.LISP"
FORM-PATH: (5)
FORM-NUMBER: 89
CHARACTER-OFFSET: 3917
FILE-WRITE-DATE: 3825178034
PLIST: NIL
DESCRIPTION: NIL
It says the source is the fifth toplevel form in the file (which corresponds to the character offset), and from here, the FORM-NUMBER is the 89th form in a depth-first search walk of the form (this comes from the structure's docstring).
But, if I recompile the function FORM-NUMBER-POSITION with DEBUG set to 3, the toplevel form read at this position, TLF is NIL:
1: (SLYNK-SBCL::FORM-NUMBER-POSITION #S(SB-INTROSPECT:DEFINITION-SOURCE :PATHNAME #P"SYS:SRC;CODE;MACROS.LISP" :FORM-PATH (5) :FORM-NUMBER 89 :CHARACTER-OFFSET 3917 :FILE-WRITE-DATE 3825178034 :PLIST NIL..
Locals:
DEFINITION-SOURCE = #S(SB-INTROSPECT:DEFINITION-SOURCE :PATHNAME #P"SYS:SRC;CODE;MACROS.LISP" :FORM-PATH (5) :FORM-NUMBER 89 :CHARACTER-OFFSET 3917 :FILE-WRITE-DATE 3825178034 :PLIST NIL :DESCRIPTION NIL)
FORM-NUMBER = 89
PATH-TABLE = #((0 0))
POS-MAP = #<HASH-TABLE :TEST EQ :COUNT 126 {103B227EA3}>
POS-MAP#1 = #<HASH-TABLE :TEST EQ :COUNT 126 {103B227EA3}>
STREAM = #<SB-IMPL::STRING-INPUT-STREAM {7F3E0350D953}>
TLF = NIL
TLF#1 = NIL
TLF-NUMBER = 5
In read-source-form, you can see that the form is being read inside a (ignore-errors (read ...)) form, which returns NIL in case of error. I tried calling (read ...) only but this somehow did not invoke the debugger, so I did the same thing as above and explicitly invoked it on any condition.
There is an error, namely that the package "SB-XC" does not exist, which is expected since, if I am not mistaken, this is a package that only exists during the compilation of SBCL itself.
I think you should contact the SBCL SLY developers and file a bug for this directly, they would certainly have a better idea of how to fix the behaviour (feel free to link to your question in addition to giving the usual details of the bug report).
I'm seeing pretty much what you're seeing.
Defun (line 280 of defboot.lisp) is a macro, which is defined in terms of defun-expander (line 230 of defboot.lisp) which is what you're seeing.
Whereas, defmacro takes you directly to its definition (line 15 of defmacro.lisp) which is what you're seeing.
It seems to be doing useful things.
I defined a new function 'addmore'
(defun addmore (x y z)
(testfn x (testfn y z)))
I compiled it all, and M-. on 'addmore' takes me to the definition of testfn.
So I think it's all working.
Suppose I have a these properties defined:
:PROPERTIES:
:a: 1
:b: 2
:END:
How do I define a property c such that the value is the sum of the value of property a and the value of property b? I have tried :c: (+ a b) but the value of c is just the string "(+ a b)".
Is it possible to define a property in this way or do I have to have a code-block that is then evaluated? (Using the Properties API for instance)
You could define a code block which executes on export, using the Property API:
* Code
#+NAME: PropertyCalculator
#+BEGIN_SRC emacs-lisp
(let* ( (rootval (string-to-number (org-entry-get nil "root")))
(squareval (number-to-string (* rootval rootval))) )
(org-entry-put nil "square" squareval)
)
#+END_SRC
* Content
** Property Data
:PROPERTIES:
:root: 2
:square: 5
:END:
#+CALL: PropertyCalculator()
This would leave any existing entry in place in the buffer, but overwrite in the export.
You could also correct in-buffer with (org-babel-load-file).
For a structure and its instance defined as follows:
(struct dog (name breed age))
(define mydog (dog "lassie" "collie" 5))
(example from https://learnxinyminutes.com/docs/racket/)
The usual way to get a structure field is as follows:
(dog-name mydog) ; => "lassie"
Can there be a macro so that we can perform above using following dot notation:
(mydog.name) ; => "lassie"
Or, parentheses may not be needed:
mydog.name ; => "lassie"
Macro for dot notation is used on this page: http://www.greghendershott.com/fear-of-macros/pattern-matching.html#%28part._hash..refs%29 but I am not able to use it for above purpose. I also saw some details of structure macro on this page: Is struct a macro in Racket?
Edit: as suggested in comments and as mentioned on https://docs.racket-lang.org/reference/reader.html?q=read-cdot#%28part._parse-cdot%29, I tried read-cdot, but it does not work:
#lang racket
(read-cdot #t)
(struct dog (name breed age))
(define mydog (dog "lassie" "collie" 5))
(dog-name mydog) ; works
mydog.dog-name ; does not work;
The error is:
mydog.dog-name: unbound identifier in module in: mydog.dog-name
I have created a macro which creates a named dispatcher with 3 associates functions get-dispatcher, set-dispatcher and call-dispatcher to work with the dispatcher (they get a dispatching function, add one or call one). It all works just fine! However, now I want to automate the related functions names creation, thus I am putting all these internals of the macro into a let which defines that simple construction function. Note that in the code below only the get- function's name is constructed with that automation. The set- and call- ones name creation still has that manual smell.
(defmacro create-dispatcher [name]
;creates a set of dispatching functions tagged
`(do
;define dispatcher
(def ~(symbol name) ~(atom {}))
(let
[name-w-prefix (fn [x] (~(symbol (str x "-" name))))]
; -- define getter
(defn (name-w-prefix "get")
"get-dispatcher [tag]: get a dispatcher fn by tag"
(~'[] (println "no tag is provided for '" ~(str name) "' dispatcher"))
(~'[tag]
(do
(println "dispatcher '" ~(str name) "' called with '" ~'tag "' tag")
; return the tagged dispatcher
( (keyword ~'tag) #~(symbol name) )))
)
; -- define caller
(defn ~(symbol (str "call-" name))
"get-dispatcher [tag & args]: call a dispatcher fn by tag and apply to the args"
~'[tag & args]
(apply (~(symbol (str "get-" name)) ~'tag) ~'args)
)
; -- define setter
(defn ~(symbol (str "set-" name))
~'[tag fn]
"add-dispatcher [tag fn]: add a dispatcher fn associated with the tag"
(swap! ~(symbol name) assoc (keyword ~'tag) ~'fn)
)
)
; -- report
(println "created dispatcher set for '" ~(str name) "' ok!")
))
However, there is a problem. The name-w-prefix in the let statement binding causes errors. How can I fix that?
(also any advices on improvement are welcome since I am a newb and that is almost the first thing that I wrote in Clojure)
All symbols in a macro are resolved in the current namespace and expected to evaluate to a var. You could quote the name-w-prefix symbol, but that would risk colliding with symbols passed in to the macro during macro expansion. So, Clojure provides a special syntax for use in syntax-quoted forms for generating symbols - just append a # to the end of the symbol and Clojure will treat that as a quoted, auto-generated symbol. So in this case, replace occurrences of name-w-prefix with name-w-prefix# and you should be good to go.
Taking a step back and looking at what your overall goal is, I think you should move the name-w-prefix definition outside the syntax quotes and then use syntax-escape to call it. Otherwise, you'll get still more errors because defn requires a symbol, so once expanded the macro must produce a defn form that has a symbol as its second item. Something along the lines of:
(defmacro create-dispatcher [name]
(let [name-w-prefix #(symbol (str % "-" name))]
`(do
(def ~(symbol name) (atom {}))
(defn ~(name-w-prefix "get")
([] (println "no tag provided"))
([tag#] (println "called with tag" tag#))))))
Note that I've changed ~'[tag] to [tag#] in the defn body in accordance with what I was talking about above.
I was messing around in SLIME (connected a Clozure REPL) when I discovered this:
It looks like the variables +, *, and / are all bound to some variation on recent input, + is the input itself, * is the result of evaluating that input, and / is the result contained in a list.
Is this right? Who is responsible for this, SLIME or Clozure? I couldn't find anything in the SLIME manual.
Thanks!
; SLIME 2010-05-13
CL-USER> +
NIL
CL-USER> *
NIL
CL-USER> /
(NIL)
CL-USER> -
-
CL-USER> +
-
CL-USER> (list 1 2)
(1 2)
CL-USER> +
(LIST 1 2)
CL-USER> /
((LIST 1 2))
CL-USER> (+ 1 2)
3
CL-USER> /
(3)
CL-USER> *
(3)
CL-USER> (* 1 2)
2
CL-USER> *
2
CL-USER>
Those are all, and more, specified by the Common Lisp standard. Search the environment dictionary for 'Variable'.
+
++
+++
While a form is being evaluated by the top-level loop, the variable + is bound to the previous form read by the loop. The variable ++ holds the previous value of + (that is, the form evaluated two interactions ago), and +++ holds the previous value of ++.
-
While a form is being evaluated by the top-level loop, the variable - is bound to the form itself; that is, it is the value about to be given to + once this interaction is done.
*
**
***
While a form is being evaluated by the top-level loop, the variable * is bound to the result printed at the end of the last time through the loop; that is, it is the value produced by evaluating the form in +. If several values were produced, * contains the first value only; * contains nil if zero values were produced. The variable ** holds the previous value of * (that is, the result printed two interactions ago), and * holds the previous value of **.
/
//
///
While a form is being evaluated by the top-level loop, the variable / is bound to a list of the results printed at the end of the last time through the loop; that is, it is a list of all values produced by evaluating the form in +. The value of * should always be the same as the car of the value of /. The variable // holds the previous value of / (that is, the results printed two interactions ago), and /// holds the previous value of //. Therefore the value of ** should always be the same as the car of //, and similarly for * and ///.
From Common Lisp the Language, 2nd Edition 20.2