I would like to use the helm-semantic-or-imenu command to navigate components of type annotated Python code, but whatever code analyzer is used to dentify the components doesn't seem to recognize the type annotated python code. Functions with the return type annotation doesn't get recognized at all and functions with annotated arguments show the type instead of the arguments names in the signatures
The main problem I have is that I do not properly understand the components that is involved in making this work (when it does work). Obviously it might help to somehow update the code analyzer, but in which project do I find that? helm? semantic? imenu? or as someone mentioned somewhere else with regards to code analysis python.el? I could really use some help getting started to solve this. If the code analyzer is found in python.el, can I then try to modify and make emacs use a local version preferentially over the installed one?
EDIT:
After making the initial post I finally made a break through in trying to figure out where the components come from. I searched for python*.el in all of the file systemsystem and discovered these:
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python.elc
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python-wy.elc
I found the source for emacs 26.2 and discovered that indeed it seems python-el is responsible for parsing python files for semantic. It also internally uses the python-wy for recognizing a large portion of the language components. But unfortunately that is where I hit a brick wall. I was hoping to be able to monkey patch the function that recognizes a function definition via an re or something, but semantic actually solves the problem the right way. So python-wy seems to be auto-generated from a formal grammar definition file (in emacs git admin/grammars/python.wy) and figuring out how to modify that it is unfortunately much beyond my abilities.
The semantic python backend doesn't appear to parse type annotations correctly (and there hasn't been much recent development on those libraries as far as I can tell). Since helm-semantic-or-imenu favors semantic when it is active, you can disable semantic altogether for python buffers unless you use its other features (personally I only use it for C/C++).
When the semantic mode-specific libraries are loaded they set imenu-create-default-create-index and imenu-default-goto-function, causing imenu to use semantic instead of python.el's imenu function.
To disable semantic support for your python files you can customize the semantic-new-buffer-setup-functions, only adding entries for modes you want semantic support for, eg. in your semantic hook (or alternatively with the customize UI),
(setq semantic-new-buffer-setup-functions
'((c-mode . semantic-default-c-setup)
(c++-mode . semantic-default-c-setup)
(srecode-template-mode . srecode-template-setup-parser)
(texinfo-mode . semantic-default-texi-setup)
;; etc.
;; (makefile-automake-mode . semantic-default-make-setup)
;; (makefile-mode . semantic-default-make-setup)
;; (makefile-gmake-mode . semantic-default-make-setup)
))
Related
The two functions mkYesodData and mkYesodDispatch in the Yesod framework are supposed to separate the handler definition and the dispatch process. Though by some miracle (to me), templates use this interesting function "resourcesApp":
mkYesodDispatch "App" resourcesApp
The only mention of this function I have found in hoogle is in the Hledger package. And it is not a yesod dependency.
In the school of Haskell by this link they give an explanation that resourcesApp is "generated" by mkYesodData, although it still does not work for my side.
https://www.schoolofhaskell.com/school/advanced-haskell/building-a-file-hosting-service-in-yesod/part%202
What is the reason for this?
There's some Template Haskell (TH) going on under the hood in Yesod, and I think this is what's confusing you. Template Haskell can be confusing when searching in documentation because it produces values at compile-time for use at runtime that aren't there before the code is compiled. resourcesApp is just one of these values.
In the code you reference, the author describes that you must have another module (which he calls Foundation) in which you have invoked mkYesodData. Indeed, without this other module, the code in the Dispatch module won't work. Strangely, it's not until (Part 4)[https://www.schoolofhaskell.com/school/advanced-haskell/building-a-file-hosting-service-in-yesod/part%204] that he seems to define the Foundation module, but you can see that there is a line:
mkYesodData "App" $(parseRoutesFile "config/routes")
That may not look like it defines a value called resourcesApp, but sure enough, it does.
In short, you should be able to get your code working by just finishing the entire tutorial and running the code altogether.
In case you're wondeering, a call to mkYesodData takes a String and then literally generates code that defines a value names resources**** where the **** is the string you passed. In this case, that would be a value resourcesApp, but in someone else's Yesod project, it could be resourcesFoo. Furthermore, since this resourcesFoo value isn't concretely in the code, projects that use Yesod typically wouldn't have it show up in their export lists or haddock documentation. It's actually very strange that you found even one hit for resourcesApp on hoogle at all, but upon closer examination, it kind of makes sense: Hledger seems to be some sort of extended interface around yesod, so they pre-generated the TH values so that they would be easily accessible to users.
As another note, TH has some restrictions in its use. For one, you typically need to perform the TH invocations ("splices" as they're typically called) in a separate module than the one you use the generated values. This is probably why the author has you create a separate Foundation module rather than just putting the line mkYesodData ... in the Dispatch module.
For a program i have to reformat a dot file in Haskell to adjust the layout of its tree/content. I decided to use https://hackage.haskell.org/package/graphviz-2999.20.1.0/docs/Data-GraphViz.html , but i cant find simple tutorials and the documentation confuses me, namely:
1 . It contains a function: dotToGraph, which reads: "A pseudo-inverse to graphToDot; "pseudo" in the sense that the original node and edge labels aren't able to be reconstructed."
I do need to retain the names of the nodes and edges, which i suppose are the labels mentioned here? but it seems weird that it cannot do this. It also does not take in a file name or string for the dot text, so i assume this is the wrong function.
2 . There also seems to be a parseDot function/class that comes with the package, but i cant find clear documentation for its use. (see: https://hackage.haskell.org/package/graphviz-2999.20.1.0/docs/Data-GraphViz-Parsing.html#t:ParseDot)
Can you recommend me a simple overview/summary/online example for doing this? Should i be using a different function? I have only recently started using Haskell, so the package documentation is sometimes difficult to decipher for me.
It would help a great deal, thanks!
I've been tasked with creating conformance tests of user input, the task if fairly tricky and we need very high levels of reliability. The server runs on PHP, the client runs on JS, and I thought Haxe might reduce duplicative work.
However, I'm having trouble with deadcode removal. Since I am just creating helper functions (utilObject.isMeaningOfLife(42)) I don't have a main program that calls each one. I tried adding #:keep: to a utility class, but it was cut out anyway.
I tried to specify that utility class through the -main switch, but I had to add a dummy main() method and this doesn't scale beyond that single class.
You can force the inclusion of all the files defined in a given package and its sub packages to be included in the build using a compiler argument.
haxe --macro include('my.package') ..etc
This is a shortcut to the macro.Compiler.include function.
As you can see the signature of this function allows you to do it recursive and also exclude packages.
static include (pack:String, rec:Bool = true, ?ignore:Array<String>, ?classPaths:Array<String>):Void
I think you don't have to use #:keep in that case for each library class.
I'm not sure if this is what you are looking for, I hope it helps.
Otherwise this could be helpful checks:
Is it bad that the code is cut away if you don't use it?
It could also be the case some code is inlined in the final output?
Compile your code using the compiler flag -dce std as mentioned in comments.
If you use the static analyzer, don't use it.
Add #:keep and reference the class+function somewhere.
Otherwise provide minimal setup if you can reproduce.
When converting a thrift object for nodejs:
thrift -r --gen js:node state_service.thrift
The following error is thrown:
[ERROR: /state_service.thrift:33] (last token was 'not') Cannot use
reserved language keyword: "not"
The lines in the code around 33 are:
typedef bool Not
struct Exp {
1: string left
2: Not not
3: BinaryOp op
4: AnyValue right
}
I am using the most recent Thrift version 0.9.2
Try to change the not to something else, i think the problem is that 'not' may have another meaning in the language that you choose to generate.
2: Not not
The solution is to not use the reserved language keyword, as advised by the Thrift compiler. These keywords are reserved for a reason. Thrift is a cross-language tool, and not is indeed a keyword in some of them.
I don't want to change the processing code only because of a faulty js converter.
I beg to differ. Faulty is something that does not work, altough it should. Thrift clearly tells you that what you are about to try is illegal (as of today) and what the problem is.
To put it another way: With Linux, you can put uppercase and lowercase letters in a file name (actually you can put a whole bunch of strange things in, but I'll make it easy). So creating a FILE and a file in the same folder will work perfectly. If you now take your program and run it on Windows, relying on that behaviour, you will sooner or later run into trouble and may start to complain you "dont want to change your processing code only because of that faulty OS".
Note that complaining will not help you out of the pothole, altough the endorphines emitted during that process will make sure you have a fun time. The solution is of course to wait until Microsoft fixed their faulty OS, because you make the rules. Correct?
Of course not. So if you feel the implementation is wrong - fine! This is Open Source, and nobody claimed perfection. You are free to provide a patch, and we will happily review it. But please make sure you tested it with all 20+ languages currently supported by Thrift.
In Common Lisp, quicklisp is a popular library management tool. I'm going to use that tool and I'm going to try and use CL-WHO. I use the SBCL 1.0.57 implementation. I'm going to answer my own question below.
As a beginner, it's not clear how ASDF and quicklisp actually work together. And so it's not clear how to actually use packages or libraries that you've downloaded through quicklisp in an external source file. The quicklisp FAQ, at least at this moment, does not help. In python, it's incredibly simple: you can just put 'import somemodule' and life is great. Is there an equivalent for CL+quicklisp?
If you search, you find many results. Here are some of the most relevant ones I've found:
Lisp importing/loading file
How to use packages installed by quicklisp?
When I was reading through these originally, at least one question came to mind: do I actually have to care about ASDF if I'm using quicklisp? Quicklisp seems to be a higher level management tool. Other people suggest using quickproject. But is that really necessary?
The analogy to Python's imports is the system definition... well, this is a very loose analogy, but, it's the way to go. You declare dependencies in the system definition and then in source code you expect it to be there, so that if you later refer to the bits of the foreign code, you just do it.
Eg. in the system definition you might have: (usually it would be in my-program.asd file)
(defsystem :my-program
:version "0.0.1"
:serial t
:description "My program"
:components ((:file "some-source-file"))
;; `some-external-package' here is the "import", i.e. here you
;; declared that you will be using code from this package.
;; ASDF will generally "know" how to get the code of that package
;; from here on. But if it doesn't, then there are ways to "help it"
;; similar to how in Python there's a procedure to prepare your local
;; files to be used by easy_install
:depends-on (:some-external-package))
Later on in your code you just assume that the some-external-package is available to your program, e.g.:
(some-external-package:exported-symbol)
should just work. ("Your code" is the some-source-file.lisp, you've specified in the components).
This is the ASDF documentation on how to define systems
After you have this file in the place where ASDF might find it*, assuming you have ASDF installed (available to your Lisp, SBCL comes bundled with it), you'd load this system using (asdf:load-system :my-program) Explained here.
* - A quick way to test it would be to do
(push "/path/to/your/system/definition/" asdf:*central-registry*)
Download cl-who through the instructions on the quicklisp page and run this:
#!/usr/bin/sbcl --script
(load "~/quicklisp/setup.lisp")
(ql:quickload "asdf")
(asdf:load-system 'cl-who)
(with-open-file (*standard-output* "out.html" :direction :output)
(cl-who:with-html-output (*standard-output* nil :indent t)
(:html
(:head
(:title "Test page"))
(:body
(:p "CL-WHO is really easy to use")))))
To the beginner, or someone who's really lazy, there's no reason why you should have to write 3 lines at the top instead of just one (like in python).