To delete a file in Common Lisp I can do:
(delete-file "c:\\path\\to\\file")
But for some reason I'm unable to find out how to delete a directory. There is no delete-directory, and when I pass a directory path to delete-file I get:
couldn't delete c:\path\to\folder: Unknown error
[Condition of type SB-INT:SIMPLE-FILE-ERROR]
Googling didn't help either.
I'm using Steel Banks Common Lisp on Windows, installed using Lispstick.
Uiop comes with ASDF 3 and has delete-empty-directory and delete-directory-tree.
Please do use this kind of wrapper library for portability.
Google with common lisp delete directory suggested me immediately cl-fad. I guess it could be useful (but I never tried it)
I found the solution myself. I looked at the source code of cl-fad (mentioned in other answers), and saw that it basically used different extensions for the different Common Lisp implementations. Since I was using Steel Banks Common Lisp my solution was:
(sb-ext:delete-directory "c:\\path\\to\\folder\\")
For most other implementations you basically have to swap out sb-ext with the name of the extension package for the implementation in question.
Related
I use an IDE called DrRacket to help to learn scheme.
I read a book named Simply Scheme and I downloaded the package simply-scheme so that I could run examples and do exercises in this book.
This book provides a package named functions.scm, the book instructed me to load it(functions.scm) into the interpreter so I could explore those functions and procedures inside it.
But it seems that I can't use procedures inside the file(functions.scm) after I loaded it.
This is OK when I found I could just open it(functions.scm) in IDE and click run button top right-hand corner.
However, when I kept reading this book, I wrote more and more procedures. And there are more and more times when I want to reuse my procedures defined before.
It becomes a severe problem that I can't use my procedures after loading files into scheme interpreter.
I really don't understand why would this happen. When I add extra parentheses into those files and then I loaded them into Scheme, the interpreter would show error message about unmatched parentheses. This means the interpreter does read the loading files. But why can't I just use the procedures I defined inside it?
I would appreciate it if there is anyone who could explain it and give me a solution to this issue.
Over the past few weeks I have been getting into Ada, for various different reasons. But there is no doubt that information regarding my personal reasons as to why I'm using Ada is out of scope for this question.
As of the other day I started using the gprbuild command that comes with the Windows version of GNAT, in order to get the benefits of a system for managing my applications in a project-related manner. That is, being able to define certain attributes on a per-project basis, rather than manually setting up the compile-phase myself.
Currently when naming my files, their names are based off of what seems to be a standard for the grpbuild, although I could very much be wrong. For periods (in the package structure), a - is put in the name of the file, for underscores, an _ is put accordingly. As such, a package by the name App.Test.File_Utils would have a file name of app-test-file_utils: .ads and .adb accordingly.
In the .gpr project file I have specified:
for Source_Dirs use ("app/src/**");
so that I am allowed to use multiple directories for storing my files, rather than needing to have them all in the same directory.
The Problem
The problem that arises, however, is that file names tend to get very long. As I am already putting the files in a directory based on the package name contained by the file, I was wondering if there is a way to somehow make the compiler understand that the package name can be retrieved from the file's directory name.
That is, rather than having to name the App.Test.File_Utils' file name app-test-file_utils, I would like it to reside under the app/test directory by the name file_utils.
Is this doable, or will I be stuck with the horrors of eventually having to name my files along the lines of: app-test-some-then-one-has-more_files-another_package-knew-test-more-important_package.ads? Granted, I have not missed something about how an Ada application should actually be structured.
What I have tried
I tried looking for answers in the package Naming configuration of the gpr files in the documentation, but to no avail. Furthermore I have been browsing the web for information, but decided it might be better to get help through Stackoverflow, so that other people who might struggle with this problem in the future (granted it is a problem in the first place) might also get help.
Any pointers in the right direction would be very helpful!
In the top-secret GNAT documentation there is a description of how to use non-default file names. It's a great deal of effort. You will probably give up, use the default names, and put them all in a single directory.
You can also simplify much of the effort by using GPS and letting it build your project file as you add files to your source directories.
I'm stuck using the 4.0 version of lua which does not seem to support the os library. Is there a way to include this library into my project?
Or get another way to use the functionality contained within pertaining to date time calculations?
Preferably by using a *.lua file and not a *.c file since I don't have complete access to the code.
When I run the following line,
print(os.time{year=1970, month=1, day=1, hour=0})
I get an error stating:
attempt to index global 'os'(a nil value)
As #Colonel Thirty Two said it's not possible to use the os library. So the time() funciton is not available for me.
Adding to the (totally correct) currently accepted answer (that if "os" access was not allowed to you, you're generally done), there's some very slight chance the Original Programmer may have provided you with some alternative facilities to do your thing (fingers crossed). In a perfect world, those would be described in some kind of a User's Manual for your scripting environment. But if the manual was lost to time (or never existed in the first place), you might possibly try your luck at exploring any preloaded libraries by digging through the result of the globals() Basic Function. (At least I hope that's how it was done in 4.0 too.) That is, if the Original Programmer didn't block globals() for you too...
I'm using Emacs as my Lisp environment, and would like to have offline access to the Common Lisp HyperSpec. I downloaded it, and put the folders into my emacs.d directory. I then put the following code into my .emacs:
(global-set-key [(f2)] 'slime-hyperspec-lookup)
(setq common-lisp-hyperspec-root "/.emacs.d/HyperSpec/")
However, every time I try to search for something in it, my query ends up being malformed. Specifically, suppose I search for dotimes; what gets dumped into my browser is file:///.emacs.d/HyperSpec/Body/m_dolist.htm, which doesn't match the directory structure in the HyperSpec folder, causing the query to fail. The HyperSpec lookup instead formats to suit the web version (in that case, it works absolutely fine).
Is there any way I can fix this, and if so, how? I basically just want to be able to look up the HyperSpec even when I'm not online.
You might like to try my CLHS ASDF wrapper, which is specifically designed to download the CLHS into a standard location (basically the quicklisp directory) and then help you setup emacs to point to it.
Simply invoke (ql:quickload "clhs") and follow the instructions.
Hope this helps!
edit: #JigarParekh I think you may have skimmed my answer a little too fast.
The question's title is "Viewing the Common Lisp HyperSpec offline via Emacs". The question's body basically gets bogged down in the details of manually installing the CLHS and pointing emacs to it, and asks how to solve an immediate subproblem related to that. The selected answer solves the user's immediate subproblem, but is less than optimal given what's available today.
My answer does include the essential part of the answer, which is:
Simply invoke (ql:quickload "clhs") and follow the instructions.
This downloads the CLHS from Quicklisp in a way that should remain available for the foreseeable future, regardless of the helpful but optional additional information I included for reference in the first paragraph. My answer would remain useful even if the reference links' content changed or even if, god forbid, they became 404 Not Found or otherwise unavailable. (I note in passing that since the referenced page is part of a public domain website and available on github, anyone could easily mirror it and provide a replacement link to it here should that ever come to pass. But as I said, it's optional additional reference information anyway.)
Please replace
(setq common-lisp-hyperspec-root "/.emacs.d/HyperSpec/")
with
(setq common-lisp-hyperspec-root "~/.emacs.d/HyperSpec/")
or even
(setq common-lisp-hyperspec-root (expand-file-name "~/.emacs.d/HyperSpec/"))
I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.