I want to step into extension development for Gnome Shell, but I can't seem to understand how I do a few tasks in Looking Glass lg to actually debug my stuff.
When I type global.log("hi"); into LG, it throws me back r(...) = undefined. Why?
When I want to debug an extensions that doesn't load, how do I do that?
It would be nice to see why an extension can't be loaded.
I tried Main.ExtensionSystem.loadExtension() but it returns undefined no matter if I give it the extension's name string or the extension's object.
Where do I find documentation for classes, objects and member methods?
(The LG inspector does not seem to be able to inspect functions.)
If I had these resources I could at least start to work on updating some extensions for newer Gnome versions. I would not ask these simple questions if they would be nicely explained somewhere but getting all the info seems really tough (I've googled for hours).
1: LookingGlass is basically a GJS console. It allows you to execute and test lines of GJS, grab and manipulate objects and use r(...) to use results in following commands.
The reason you get r(...) = undefined is because log(String); does not return anything, thus the result is undefined.
2: Either log throughout init() and enable(), then check where it breaks and try to pinpoint the breaking line using log or commenting out lines of code (although the culprit is probably defined in the general logging, described in the section at the bottom).
3: There is no official documentation. They have some outdated tutorials for GNOME Shell 3.4 with a small difference explanation to 3.6, a few pages on the C(++) ends of the libraries you use (most of the functions, variables and constants use the same names though), but for any real info you'd need experience, digging through other GNOME and shell extension code or some unofficial sources. Unofficial sources aren't always up to date, however.
Up to date generated docs at RooJS, although at least events are off as they are separated with - (minus) rather than _ (underscore).
Old, but mostly useful documentation, MathematicalCoffee has more useful things, like in depth explained code that is quite a solid learning source.
Generated docs, almost everything is there, very extensive, but sometimes the site drops offline for a few days. You could try to clone the git repo to run it locally, but the readme.md is a verbatim copy of what they forked...
More recent reference made by a user, although this is quite extensive, it's not of much use if you're on an older version of GNOME Shell, as deprecated and old is more likely to work than next gen stuff.
I recommend checking the official extensions website and go through whatever interesting extensions' source code you can get, as that is your best bet to learn anything.
Generally Debugging gnome can be done in several ways.
- use the log() function and follow journalctl in a commandline, check either GNOME or JS, use journalctl -f | grep -i js (or use grep -i gnome). You will see some warnings no matter what, but most mention what extension they're from. This is nice and works on all distros implementing systemd
- Or log a specific process that is a part of GNOME like journalctl /usr/bin/gnome-session -f -o cat, just beware that some distros and versions log to different files and old GNOME versions often log to whatever your display manager logs to.
- use the official (albeit tricky) manner of logging: GNOME on debugging.
I personally couldn't get this to work.
Related
Perl 6 comes with a REPL; and that REPL picks up plugins such as Linenoise as soon as it's installed, getting all the goodies.
However, it's not clear to me how Linenoise plugs into the REPL to provide that functionality. I haven't seen it documented anywhere, either. If I want to create my own plugin for providing, let's say, other type of tab completion (which Linenoise already has, but far as I can tell, only for keywords), or anything else for that matter, how could I proceed? Is there any particular part of Linenoise I could fork for doing that?
This would help, for instance, towards providing a better REPL, as the community has requested for some time already.
You currently cannot, at least not without patching Raku. It's hard-coded in Raku's source code.
I am creating a PythonAnalyzer using the following code:
var interpreterFactory = InterpreterFactoryCreator.CreateAnalysisInterpreterFactory(
PythonLanguageVersion.V36.ToVersion());
var analyzer = PythonAnalyzer.Create(interpreterFactory);
Later on I also create and analyze a simple python module, that looks like this:
name = input('What is your name?\n')
print('Hi, %s.' % name)
Then I do module.Analysis.GetValuesByIndex("name", 4).
At this moment I expected the "value" to be 'str', because that's what Visual Studio shows when I open the same file in it. However, I get 'object' instead. So it seems that the PythonAnalyzer when constructed as mentioned above lacks some important information about where to look for standard library and/or its types.
Unfortunately, the documentation on PythonAnalyzer is lacking, so I was hoping the community could help understand how to configure it properly.
Congratulations on getting so far :)
What you're hitting here is the fact that CreateAnalysisInterpreterFactory is really intended for "pure" cases, where you have access to all the code that you're trying to analyze and nothing needs to be looked up. It is mostly used for the unit tests, or as a fallback when no copies of Python are installed. Depending on precisely which version of PTVS you are using, the bare information you're getting is either coming from DefaultDB\v3\python.pyi or CompletionDB\__builtin__.idb, both of which are somewhat lacking (by design).
Assuming you have a copy of Python installed, I would suggest creating an instance of InterpreterConfiguration with all of its details, and passing that to CreateInterpreterFactory (without "Analysis").
If you're on the latest sources (strongly recommended), this may run the interpreter in the background to collect information from it (you can control caching of this info with the DatabasePath and UseExistingCache members of InterpreterFactoryCreationOptions). If you are using the older version still, you'll need to trigger a completion DB regeneration or have one that you've created through VS.
And a final caveat: this part of PTVS is currently under some pretty heavy development at time of writing, so you'll either want to keep updating the version you're working against or stick with a slightly older one. Also feel free to post questions like this on the GitHub site, as while this is technically public API, it's barely documented at all and so the best help will come from the dev team.
I'm trying to set up a working ruby project with guard-rspec.
I've mixed together the general method of a tutsplus tutorial with some new syntax as described in the RSpec videos and another post. The project can be found in the stack-overflow-question branch on github.
I'm also trying to practice namespacing as described in Programming Ruby 1.9. So eventually I'd like to have example.rb in my lib/example/ directory.
There's 4 questions I have about my project:
What do I need to put in my Guardfile to watch specific directories in my project for changes? I've several different ways which can be seen in my Guardfile as comments labelled like:
# Watch Specific Directory Attempt X
What is the difference between uncommenting lines 8 and 9 in my Guardfile (bellow Uncomment and set this to only include directories you want to watch) and adding "named group captures" like watch(%r{^lib/(?<path>.+)\.rb$}) { |m| "spec/lib/#{m[:path]}_spec.rb" } as described here
Where do I need to put the --clear option to make it persistent? I know I can run it with my binstub like bin/guard --clear and I've tried putting that in my Guardfile however it didn't work.
Are there any glaring convention, syntax, or clarity mistakes that you see in my project? I feel like I'm duck taping this whole thing together and I'd appreciate some guidance in piecing this thing together in a sensible way.
I'll answer the question in the title and cover the "sub-questions" as I go.
The best way to set up a project (as of now) is to use bundle exec guard --init rspec. This should give reasonable defaults to start work immediately. It's not perfect, but there is a lot of work planed to improve things, so do ask questions on GitHub instead (makes more sense).
Guard has to maintain backward compatibility, so there are some "non-intuitive" things for now and skimming through all the docs first (and wiki) is a good investment to quickly know what's available and where. Asking when confused or in doubt is also a good idea (one issue per question is best).
Guard uses a DSL to simplify setting up listeners. This is a bit non-intuitive and clunky at times, but it does help organize actions into groups, which can help maintain complex workflows. The DSL's command for e.g. clearing the terminal automatically is: (clearing: on). (This answers question 3).
There are all kinds of uses and scenarios, so Guard tries hard to make everyone happy and on every platform too. Guard uses Listen, which watches directories recursively (due to restrictions on OSX mostly). This usually isn't a problem, but for huge directions on OSX this can be very, very slow. That's why Guard lets you select which top directories to watch (like 'lib', 'app', etc.). Watching the whole project directory is very convenient, so that is still the default. More info on this is at the Listen project. So by default all directories (:directories statement) are "physically watched" (take up operating resources), though in Guard you only configure which changes you want to respond to (which is what watch statements do).
The words chosen are a bit misleading at times. E.g. watch in the DSL actually means: "out of all the changes happening, select changes matching ...". The block passed to watch is given the results of the match. That block should return a list of files for the current guard plugin to run. So "watch" probably is more misleading than helpful. "match" would probably be a better choice and it might replace "watch" in the future.
The guard-rspec project runs RSpec on changed files. You can see the exact RSpec commands if you run guard with the debugging option on, e.g. bundle exec guard -d. To simplify setup, Guard::RSpec uses a DSL that should work out-of-the-box if your project follows a given setup. E.g. dsl.watch_spec_files_for(ruby.lib_files) is defined here: so it pretty much already should do what you want if you put all your tested source files in lib. For other folders, you can add your own. E.g. Rails projects typically have sources also in an app directory, so in the default Guard::RSpec template there's an statement: dsl.watch_spec_files_for(rails.app_files) with the pattern defined as: rails.app_files = %r{^app/(.+)\.rb$} If you have a typical case that isn't covered, open an issue in that project. (covers question 2).
Everything looks fine in the example project and suggestions are mostly based on taste or preference. E.g.
Instead of let (:greeter) { Example::RSpecGreeter.new }, I'd use RSpec's implicit subject (but some may argue that it's less explicit and less readable)
if you're testing Example::RSpecGreeter, I'd recommend putting that class in a separate file and including it instead (require 'example/rspec_greeter')
you might add RubCop/Guard::RuboCop for detecting convention issues (covers 4th question)
you might want to check out Guard's own Guardfile used to test itself for a more "real-life" setup without the documentation clutter.
for best results I think it's best to copy a whole existing project and rename the parts you want to change. Usually there are many hours spent still fine-tuning things like alternate RSpec configs for Travis, special gem release tasks, certain workarounds and conveniences, etc.
All,
I have been working with vim for some time now, and love everything about it - there is only one thing I really miss from IDEs like RubyMine, and that is advanced autocompletion.
For reference, here is my standard VIM setup: https://github.com/wrwright/.vim
I have tried ctags with omnicomplete + supertab, and the one major element I miss is the ability to bring up a context sensitive list of attributes/constants/methods. For example, as I learn RubyMotion, I'd love to have some help remembering iOS SDK constants/attributes/methods, but my VIM autocomplete stops with suggesting class names..or if it does suggest methods/attributes, it lists a ton of methods/attributes that don't even apply to the class I'm working with.
I'd like to (simple example) be able to type UIColor.bl and have it autocomplete with UIColor.blueColor (or suggest if there are multiple options that start with "bl" that are properties of UIColor.
RubyMine does this very well, and if I can get VIM to be similarly smart with autocomplete it would be heavenly (and a great boon while learning RubyMotion/iOS Development.
I have also tried SnipMate (and even a RubyMotion tailored variation at https://github.com/rcyrus/snipmate-snippets-rubymotion), but that doesn't seem to offer the features I'm looking for either.
Relatively satisfied with stock Vim's omnicomplete + vim-ruby and vim-rails having completion abilities on par with NetBeans but with all the bells&whistles of Vim and much lower resource requirements, of course.
From my .vimrc concerning completion options :
autocmd FileType ruby,eruby let g:rubycomplete_buffer_loading = 1
autocmd FileType ruby,eruby let g:rubycomplete_classes_in_global = 1
autocmd FileType ruby,eruby let g:rubycomplete_rails = 1
One thing that I have had a bit of luck with Rubymotion is YouCompleteMe and enabling tag Support. you will need a lot of ram(YCM uses ~2GB when indexing a large tag file) because the tags that rubymotion uses are about 40k tags.
The downside is that the rubymotion people don't seem to want to review pull requests and provide any feedback so I am not sure if they will add the needed things to the rake task that creates the tag files for ycm to work correctly out of the box.
To get it to work you need to set the tags files correct
set tags=./tags;,tags;
and then you need to setup ycm to complete off tags.
let g:ycm_collect_identifiers_from_tags_files = 1
you need to make the ctags file compatible with ycm as well. This pull request does that. You need to add a language field to the ctags creation and then change bridgesupport to ruby.
pull request for that
after that you need to run rake ctags in the root of your project.
If you don't want to modify the project.rb file you could probably create your own rake task that does pretty much the same thing.
Yes, Vim is an awesome... text editor.
As such, it can't be expected to match any IDE's "code awareness". Furthermore, it completely relies on the community for providing more than default support for a given language. If google or the rubymotion site didn't help you to find a serious "autocompletion" solution I doubt you'll find it here.
The process explained in the blog post below sounds ok, if not very precise on the vim configuration front.
http://rayhightower.com/blog/2013/02/12/automatic-ctags-with-rubymotion-and-vim/
How to generate tags file for Go source
In mac, I installed exuberant ctags , and tried the below command in source directory
ctags -f gosource.tags -R `pwd`
But, it doesn't consider *.go files. Do I have to use -h option? But, isn't it only for header files, as per the manual?
Please give me the correct command so that I can use the tags file with vim. I also prefer absolute path so that I can keep the file anywhere
Thanks.
Edit:
I assumed current ctags support Go, seeing http://groups.google.com/group/golang-nuts/browse_thread/thread/3a4848db231b02c9.
but, http://ctags.sourceforge.net/languages.html desn't have go listed.
Add the following to ~/.ctags
--langdef=Go
--langmap=Go:.go
--regex-Go=/func([ \t]+\([^)]+\))?[ \t]+([a-zA-Z0-9_]+)/\2/d,func/
--regex-Go=/var[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/d,var/
--regex-Go=/type[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/d,type/
(From http://go-wise.blogspot.com/2011/09/using-ctags-with-go.html)
--langdef=Go
--langmap=Go:.go
--regex-Go=/func([ \t]+\([^)]+\))?[ \t]+([a-zA-Z0-9_]+)/\2/f,func/
--regex-Go=/var[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/v,var/
--regex-Go=/type[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/t,type/
Does indeed work with ctags 5.8. One slight change from the previous poster, ctags requires unique 1-char types at the ends of the regex lines. Thus /d,func/ should read /f,func/ intuitively. This allows the ctags to distinguish between and identify types, allowing ctags --go-types=fvt i.e.
I saw your post, bumbled around a bit trying to find a good tool for the job, tried ctags, and ultimately was unsatisfied. I wrote a program 'gotags' in Go that generates a ctags file for Go code. Its better than the current ctags support because, for example, it tags struct field names as well as the struct name itself. You can get it here: https://github.com/necro351/gotags.
Its a nice short simple Go program because it uses the standard library parser and has no extra features other than good Go parsing and tagging. Just check it out (or go get it) and do a go install. Also, if you have any suggestions or ideas about improving it, let me know.
Edit: I am an active Gopher and so will be updating this tool over time and as I use it.
Edit: I am not actively developing Go anymore. But my tool is very short and pretty much works as is so it should "just work" :)
universal-ctags supports Go. It's the successor of exuberant-ctags and works perfectly fine. See here for the man pages.
Check Go Dashborad/Projects, section "Tag Generators". Status of those tools is not known to me.
Edit 2011-11-22: Latest egotags fork announced today (cyclic reference possible ;-)