I'm not sure what's going wrong here and I'm failry new to emacs in general... I started with trying to install JDEE (downloaded it, extracted into directory below) into emacs with this code
(add-to-list 'load-path "~/.emacs.d/internet/jdee-2.4.1/lisp")
(load "jde")
in my.emacs file and I was getting the error "Cannot find wget. You might want to use the beanshell resolver instead." upon M-x eval-buffer
I'm not sure what's going on there since I have wget with xcode on my mac. But I looked up about jdee and i found that i might want cedet. So I download that, put it into .emacs.d and even add
(add-to-list 'load-path "~/Users/paulmyers/.emacs.d/internet/cedet-1.1/cedet-build.el")
to my .emacs but whenever I run
emacs -Q -l cedet-build.el -f cedet-build
from my terminal like it tells me to, I get the message
"Cannot open load file: no such directory, cedet-build.el"
I don't know what to do at this point...
Be sure CEDET works well before trying jdee.
Get the last CEDET http://sourceforge.net/p/cedet/git/ci/master/tree/ and the last jdee http://sourceforge.net/p/cedet/git/ci/master/tree/ .
Here my cedet conf (at the beginning of your .emacs):
(ignore-errors ;; for cedet reload
(load-file "~/.emacs.d/cedet-git-master/cedet-devel-load.elc")
(load-file "~/.emacs.d/cedet-git-master/cedet-contrib-load.elc"))
(global-ede-mode 1)
(add-to-list 'semantic-default-submodes 'global-semanticdb-minor-mode 1)
(add-to-list 'semantic-default-submodes 'global-semantic-idle-scheduler-mode 1)
(add-to-list 'semantic-default-submodes 'global-semantic-stickyfunc-mode 1)
(add-to-list 'semantic-default-submodes 'global-semantic-highlight-func-mode 1)
(add-to-list 'semantic-default-submodes 'global-semantic-idle-summary-mode t)
(add-to-list 'semantic-default-submodes 'global-semantic-idle-completions-mode t)
(add-to-list 'semantic-default-submodes 'global-srecode-minor-mode t)
(semantic-mode)
And my jdee conf
(add-to-list 'load-path "~/.emacs.d/jdee/jdee-master")
(autoload 'jdee-mode "jdee" "" t)
(setq auto-mode-alist (append '(("\\.java\\'" . jdee-mode)) auto-mode-alist))
(setq jde-complete-add-space-after-method t)
(setq jdee-server-dir "~/.emacs.d/jdee/jdee-server-master/target/")
(add-hook 'jdee-mode-hook
(lambda()
;; abbrev
;;(jdee-abbrev-mode)
;; autocomplete
(add-to-list 'ac-modes 'jdee-mode)))
Then use M-x custumize-group jdee for JAVA variables (JAVA_HOME, CLASSPATH...)
Regarding JDEE, in your place I would install in from MELPA using emacs package manager. This is the recommended way to install it.
Related
I made a small repro for this issue using only lisp.
file1.lisp :-
(defpackage :my_package
(:use :cl))
(in-package :my_package)
(defun subscribe (x) (print x)(terpri))
(export '(subscribe))
(in-package :cl-user)
file2.lisp :-
(defun loader ()
(load "file1.lisp")
(my_package:subscribe "hello"))
(loader)
Now, running this gives the same error :-
sbcl --load file2.lisp
This is SBCL 2.1.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
debugger invoked on a SB-C::INPUT-ERROR-IN-LOAD in thread
#<THREAD "main thread" RUNNING {1001834103}>:
READ error during LOAD:
Package MY_PACKAGE does not exist.
Line: 3, Column: 22, File-Position: 59
Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/omkarwagh/swarajya/scratch/file2.lisp" {10009BF613}>
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT ] Abort loading file "/home/omkarwagh/swarajya/scratch/file2.lisp".
1: [CONTINUE] Ignore runtime option --load "file2.lisp".
2: Skip rest of --eval and --load options.
3: Skip to toplevel READ/EVAL/PRINT loop.
4: [EXIT ] Exit SBCL (calling #'EXIT, killing the process).
(SB-C:COMPILER-ERROR SB-C::INPUT-ERROR-IN-LOAD :CONDITION #<SB-INT:SIMPLE-READER-PACKAGE-ERROR "Package ~A does not exist." {10018375A3}> :STREAM #<SB-INT:FORM-TRACKING-STREAM for "file /home/omkarwagh/swarajya/scratch/file2.lisp" {10009BF613}>)
4
I guess that the problem is that we don't know the package at read time because the relevant file has not been loaded yet.
So the question is, what is the recommended practice in this case?
Original question
I have a roswell script that I've attached below. I have an asdf system called "my_system" which has only one module with one file that contains only one package called "my_package".
Somehow, the asdf system is being loaded but when I try to actually use any of the functions in it, then it fails with an error saying that "my_package" is not found
#!/bin/sh
#|-*- mode:lisp -*-|#
#|
exec ros -Q -- $0 $(readlink -f $(dirname $(readlink -f $0)))/asdf.conf "$#"
|#
(progn ;;init forms
(ros:ensure-asdf)
#+quicklisp(ql:quickload '() :silent t)
)
(defpackage :ros.script.test.3880638094
(:use :cl))
(in-package :ros.script.test.3880638094)
(require "asdf")
;(asdf:load-system "my_system")
;(print #'my_package:subscribe)
(defun main (mydir &rest argv)
(declare (ignorable argv))
(asdf:initialize-source-registry `(:source-registry :inherit-configuration (:include ,mydir)))
(asdf:load-system "my_system")
(sleep 0.2)
(print "here3")(terpri)
(print (list-all-packages))
(do-external-symbols (s (find-package :my_package)) (print s))
(print #'my_package::subscribe)(terpri)
)
;;; vim: set ft=lisp lisp:
The error is :-
Unhandled SB-C::INPUT-ERROR-IN-LOAD in thread #<SB-THREAD:THREAD "main thread" RUNNING
{1004460113}>:
READ error during LOAD:
Package MY_PACKAGE does not exist.
However, if I comment out this line :-
(print #'my_package::subscribe)(terpri)
I do in fact, see the package in the list of packages as well as the symbol in question :-
#<PACKAGE "MY_PACKAGE">
MY_PACKAGE:SUBSCRIBE
As you said, the error is signalled because the package does not exist at the read time (when the form is read as text and translated to symbols).
The most straightforward option to change the code above this is to create the symbol when function is executed, e.g., (funcall (intern "SUBSCRIBE" 'my-package)). Variant of this (using read-from-string instead of intern) can be seen in the Swank or Slynk loader.
If you use asdf (which is implied in your question), you should probably use uiop to do this for you - see uiop:symbol-call. For example, documented way to define test-op is with
:perform (test-op (o c) (symbol-call :fiveam '#:run! :foobar)))
However, most libraries structure files in such a way that this issue does not arise - the file1.lisp would be loaded before file2.lisp (e.g., using asdf system definition).
With the following (simplified) code:
(setv agnostic-manager-installers {})
(defmacro alias-assign [am &rest aliases]
(for [alias aliases] (assoc
agnostic-manager-installers
(str alias)
(-> (globals) (get (str am)) (get "install")))))
(setv brew {
"prefix" "/home/linuxbrew/.linuxbrew/"
"install" (defn brew [] (run
"curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh | sudo bash"
:shell True))
})
(alias-assign brew brew homebrew home-brew linuxbrew linux-brew)
I'm getting the following error:
Traceback (most recent call last):
File "/home/shadowrylander/.local/syvl/python/hy/bin/hy", line 8, in <module>
sys.exit(hy_main())
File "/usr/lib/python3.9/contextlib.py", line 137, in __exit__
self.gen.throw(typ, value, traceback)
File "<stdin>", line 9, in alias_assign
hy.errors.HyMacroExpansionError:
File "<stdin>", line 20
(alias-assign brew brew homebrew home-brew linuxbrew linux-brew)
^--------------------------------------------------------------^
expanding macro alias-assign
KeyError: 'brew'
I thought the macro was not supposed to evaluate the arguments until compile-time, if I'm reading the error correctly (which I don't think I am)? Basically, I would like to not write the double quotes around every single alias provided to alias-assign, which is why I went with a macro.
Here's some much simpler code that produces the same error:
(setv brew 1)
(defmacro m []
(get (globals) "brew"))
(m)
Perhaps the problem is more obvious now: trying to access the global variable brew during macro-expansion doesn't work because brew doesn't exist during compile-time, when macro-expansion happens. The same problem occurs, with NameError instead of KeyError, if you just say brew instead of (get (globals) "brew"). In any case, the form (setv brew 1) won't be evaluated until run-time. One way around this is to say (eval-when-compile (setv brew 1)) instead. This makes the evaluation happen earlier.
A broader problem is that you seem to be executing code that you actually want to return, as the result of the macro expansion. After all, the body of your macro is a for, so it will always return None. Contrast with the following code, which uses quoting and unquoting to generate forms and return them (and uses updated syntax):
(setv agnostic-manager-installers {})
(defmacro alias-assign [am #* aliases]
`(do ~#(gfor
alias aliases
`(setv (get agnostic-manager-installers ~(str alias))
(get ~am "install")))))
(setv brew (dict
:prefix "/home/linuxbrew/.linuxbrew/"
:install "placeholder"))
(alias-assign brew brew homebrew home-brew linuxbrew linux-brew)
(print (hy.repr agnostic-manager-installers))
The result is:
{"brew" "placeholder" "homebrew" "placeholder" "home-brew" "placeholder" "linuxbrew" "placeholder" "linux-brew" "placeholder"}
I've seen many questions in this forum which are questions of how to fix a problems of compiling IronPython WPF to exe.
But the problem is that I haven't seen any guide Step-by-step of how to compile my project.
I understood it includes using the clr module.
I've 6 files:
Window.py, Window.xaml.
Window1.py, Window1.xaml.
Window2.py, Window2.xaml.
That's all the files
Thanks
((irrelevant: Update- 3 hours later:
I've started using SharpDevelop and when I run it through the software itself it can be run. However , when I try to run this through the .exe file in the project's folder it doesn't work... ))
Update 2 - SharpDevelop created an exe file which works but the problem is it didn't encrypt my xaml to dll ..
Have you tried the script from this thread: Ironpython 2.6 .py -> .exe
Supposedly it includes wpf support:
#!/usr/bin/env python
# CompileToStandalone, a Python to .NET ILR compiler which produces standalone binaries
# (C) 2012 Niall Douglas http://www.nedproductions.biz/
# Created: March 2012
import modulefinder, sys, os, subprocess, _winreg
if len(sys.argv)<2:
print("Usage: CompileEverythingToILR.py <source py> [-outdir=<dest dir>]")
sys.exit(0)
if sys.platform=="cli":
print("ERROR: IronPython's ModuleFinder currently doesn't work, so run me under CPython please")
sys.exit(1)
sourcepath=sys.argv[1]
destpath=sys.argv[2][8:] if len(sys.argv)==3 else os.path.dirname(sys.argv[0])
ironpythonpath=None
try:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, None)
except Exception as e:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\Wow6432Node\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, "")
except Exception as e:
pass
finally:
if ironpythonpath is not None:
_winreg.CloseKey(keyh)
print("IronPython found at "+ironpythonpath)
else:
raise Exception("Cannot find IronPython in the registry")
# What we do now is to load the python source but against the customised IronPython runtime
# library which has been hacked to work with IronPython. This spits out the right set of
# modules mostly, but we include the main python's site-packages in order to resolve any
# third party packages
print("Scanning '"+sourcepath+"' for dependencies and outputting into '"+destpath+"' ...")
searchpaths=[".", ironpythonpath+os.sep+"Lib"]
searchpaths+=[x for x in sys.path if 'site-packages' in x]
finder=modulefinder.ModuleFinder(searchpaths)
finder.run_script(sourcepath)
print(finder.report())
modules=[]
badmodules=finder.badmodules.keys()
for name, mod in finder.modules.iteritems():
path=mod.__file__
# Ignore internal modules
if path is None: continue
# Ignore DLL internal modules
#if '\\DLLs\\' in path: continue
# Watch out for C modules
if os.path.splitext(path)[1]=='.pyd':
print("WARNING: I don't support handling C modules at '"+path+"'")
badmodules.append(name)
continue
modules.append((name, os.path.abspath(path)))
modules.sort()
print("Modules not imported due to not found, error or being a C module:")
print("\n".join(badmodules))
raw_input("\nPress Return if you are happy with these missing modules ...")
with open(destpath+os.sep+"files.txt", "w") as oh:
oh.writelines([x[1]+'\n' for x in modules])
cmd='ipy64 '+destpath+os.sep+'pyc.py /main:"'+os.path.abspath(sourcepath)+'" /out:'+os.path.splitext(os.path.basename(sourcepath))[0]+' /target:exe /standalone /platform:x86 /files:'+destpath+os.sep+'files.txt'
print(cmd)
cwd=os.getcwd()
try:
os.chdir(destpath)
retcode=subprocess.call(cmd, shell=True)
finally:
os.chdir(cwd)
sys.exit(retcode)
The project I'm working in uses fabric for many build steps and requires a offline build as fallback.
I'm currently stuck at installing python packages provided in tarballs.
The thing is I have trouble getting into the newly extracted directory and running setup.py install in there.
#task
def deploy_artifacts():
"""Installs dependencies from local path, useful for offline builds"""
#TODO: Handle downloading files and do something like this bellow
tmpdir = tempfile.mkdtemp()
artifacts_path = ''
if not 'http' in env.artifacts_path:
artifacts_path = env.artifacts_path
with lcd(artifacts_path):
for f in os.listdir(artifacts_path):
if 'gz' in f:
put(f, tmpdir)
tar = os.path.join(tmpdir, f)
target_dir = os.path.join(tempfile.gettempdir(), normalize(f))
if not files.exists(target_dir):
run('mkdir %s' % target_dir)
else:
run('rm -rf %s' %target_dir)
run('mkdir %s' % target_dir)
run('tar xf %s -C %s' % (tar, target_dir))
run('rm %s' % tar)
with cd(target_dir):
sudo('python setup.py install')
I come from reading the tar man page for the bazillion time and I got nowhere near to getting what I want.
Did some of you face a situation like this? is there some other (read: better) approach to this scenario?
There's nothing wrong (in principle) with what you're trying do. Maybe just take smaller steps getting there. Rather than using temporary directories, it might make debugging easier if everything was put in a systematic location that has known permissions that nothing else writes to by convention. At least that would let you use some combination of fabric and manual intervention to check what is going wrong.
In the longer term, there are a few alternatives that I see. For simplicity you want the online and offline versions to work the same way, and that means fetching packages using easy_install / pip for both cases.
One way to do this is to build a mirror of PyPi. The right way to do this if you've got plenty of storage space (30Gb) is to use software that implements PEP381 (Mirroring Infrastructure for PyPI), there is already a client that does this (pep381client). A number of other projects are available that do similar things (basketweaver, djangopypi2, chishop).
An alternative is to consider a lighter weight proxying scheme. I've been looking a pip2pi and pipli. I'm unsure if they will work directly with easy_install, but it would be worth a try.
It's also worth noting that if you were using pip, you could have installed directly from the tarballs.
On Win7 with Emacs24 I encounter problems when Emacs programs want to open (pdf) files. The problems remain when I activate or deactivate openwith-mode. I either get a 'wrong-type-argument arrayp nil' message inside Emacs or Acrobat Reader is started but gives an error message 'can't open/find that file'.
I tried to debug it and always ended up in files.el.
It seems that the name of the pdf-file to be opened is constructed by concatenating the absolute filename and the file extension .pdf. However, the filename-string given to AcroRd32 appears to look like this:
AcroRd32 "c:\\absolute\file\name".pdf
This doesn't work on the command line either. I have to change it (manually) to
AcroRd32 "c:\\absolute\file\name.pdf"
or to
AcroRd32 c:\\absolute\file\name.pdf
to make it work.
I don't know if this is considered a bug, or if it is a problem only for me. I tried to change the elisp code to something like
(format "%s" (concat absolute-filename file-extension))
to get rid of those double-quotes, but to no avail. And anyway, I don't feel comfortable to mess around in a basic library like files.el, and its really hard to edebug that library since its invoked permanently.
Maybe somebody encountered the same problem and found a solution?
[I use GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601) of 2011-11-22 on MARVIN.]
PS 1 Test Case 1
I get the following error message when I do M-x toggle-debug-on-error and then try to open a pdf file in dired:
Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
file-truename(nil)
find-file-noselect-1(#<buffer test.pdf<4>> "~/.emacs.d/org/projects/sandbox/test.pdf" nil nil "~/.emacs.d/org/projects/sandbox/test.pdf" ((2816 7 . 27468) (16087 . 35227)))
find-file-noselect("c:/Users/tj2/.emacs.d/org/projects/sandbox/test.pdf" nil nil nil)
find-file("c:/Users/tj2/.emacs.d/org/projects/sandbox/test.pdf")
dired-find-file()
call-interactively(dired-find-file nil nil)
and the following message:
Openwith mode enabled
find-file-noselect-1: Wrong type argument: arrayp, nil
Does it matter that my .emacs.d is really a windows symlink (mklink) to a Dropboxfolder?
PS 2 Test Case 2
here is the message I get in the maven-compile buffer, when doing C-c C-s (LilyPond-command-view) in a ,ly buffer:
-*- mode: compilation; default-directory: "~/.emacs.d/org/projects/sandbox/" -*-
Compilation started at Tue Dec 20 09:16:28
AcroRd32 "c:/Users/tj2/.emacs.d/org/projects/sandbox/2test".pdf
Compilation exited abnormally with code 1 at Tue Dec 20 09:16:35
In the message buffer I find
Compilation exited abnormally with code 1
Error during redisplay: (invalid-regexp "Unmatched ( or \\(")
This error doesn't trigger the debugger, although I did M-x toggle-debug-on-error.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug.
Dunno why Michael H. sent you to a Sunrise Commander page with a tip about OpenWith. Perhaps I'm missing something in your question where you indicate that you use one of those packages?
I would suggest reporting an Emacs bug. And if you want to see more about opening Windows apps associated with file types etc. then I'd suggest consulting this page.
This seems to be a problem with openwith.el, so I don't think you'll get much help with an Emacs bug report since openwith.el is not part of Emacs.
I've found a similar error (I'm on Linux) and decided that it would be better to use a "cleaner" alternative that doesn't tweak find-file-noselect (see that page on emacs.sxe for why). The OpenWith wiki page pointed me to a less-popular little bit of glue code,
https://www.emacswiki.org/emacs/download/run-assoc.el (code)
https://www.emacswiki.org/emacs/RunAssoc (docs)
By default this package's run-associated-program is not well-integrated with the usual Emacs workflow, but here is how you can integrate it with helm-find-files (also documented at the above link).
(require 'run-assoc)
(setq associated-program-alist
'(("evince" "\\.pdf$")
("play" "\\.mp3$")))
(defun helm-find-files-maybe-run-assoc (orig-fun &rest args)
(let ((sel (helm-get-selection)))
(if (string-match (mapconcat
(lambda (x) (second x))
associated-program-alist "\\|")
(helm-get-selection))
(run-associated-program sel)
(apply orig-fun args))))
(advice-add 'helm-execute-selection-action
:around #'helm-find-files-maybe-run-assoc)