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.
Related
Is anyone aware of how to retrieve the exact version (major, minor, patch) that a specific feature was added/removed/altered to the Ruby language?
Obviously one could comb through the history to find out, which is not ideal, and can be cumbersome to navigate. Was curious if anyone might know a better way to do it, as the documentation doesn't state when a method, class, etc. was added.
When documenting my own gems with YARD, it is easy to just add a #since tag to clearly show when something was added, but the Ruby API doesn't seem to have any such mechanism in its own documentation.
When writing gems, it is obviously handy to know such details when managing dependencies, and I was hoping there was a simpler solution, such as simply typing a method name into a website, and seeing the exact version it was added.
To clarify, basically a "changelog" for any item. For example, type in method name, see log of when it was added, changed, deprecated, removed, etc.
A prime example would be something akin to .NET Core's Reverse Package Search.
I was just doing this, unfortunately my answer is what you were hoping to avoid.
I was looking through history, but able to use GitHub's handy Blame feature to help track down when a specific line was edited. With this I could open the file in question click "Blame" and see when it was last edited/created.
Was a great way to track down when Exception2MessageMapper was added to the standard library. It was 17 years ago, as part of v1.4.0:
https://github.com/ruby/ruby/blame/trunk/lib/e2mmap.rb#L55
I am new to Sublime and to Ruby. I have been developing Java for 10+ years, and what I miss, is: autocomplete, in the meaning of:
using: Sublime3 (ok if had to switch to 2 to get this option) + Rails.
issue: I want: I type: "MyClass. [DOT]" say: I type the dot
and then: a list of methods of this class are displayed. These methods that are defined by default (as of heritage), and those that I have defined, in the class definition.
I am aware of the 'duck-typing' style, such: also these methods, that this object itself is able to use, would be a plus.
While, I would be happy with the first two (heritage and self.methods).
Yes I am aware that the Ruby-community is sort of pure coding; I like it also, and I also appreciate an editor that helps.
I have read through answers in GITHUB, and I could not figure out if that is existing or not .. it seems, the Ruby-people do not understand this Java-coding idea.
Thank you for any link or answer.
Sublime is a text editor, is not an IDE. In the Java world you are likely used to write your code with IDE (such as Netbeans, Eclipse, Intellij IDEA), I have never seen Java developers using a pure text editor.
There are some IDE for Ruby. However, the highly dynamic and loosely typed nature of Ruby makes it really hard to provide an accurate IntelliSense code completion. Both the assumption that the Ruby community pretends to be pure, or Ruby-people do not understand Java-coding idea are simply wrong. Several Ruby developers approached the language from Java, therefore they are perfectly aware of how the Java world works.
If you feel more comfortable with an IDE, try to search for a Ruby one. RubyMine is a great product, and if you come from Java world you may already be familiar with Intellij IDEA. There are also plugins for Netbeans and Eclipse, but the runtime evaluation capabilities of RubyMine are far superior and it's also the most up-to-date.
Most of text editors, such as TextMate, Sublime Text, Atom, etc understands Ruby and provide Ruby syntax highlighting and additional features, some of them even autocompletion, but IDE-level features as you would expect from the Java world.
Autocomplete is possible in Sublime - there are several packages for Python, including the excellent Anaconda plugin. Coverage for Ruby isn't quite as deep, but I did find SublimeRsense which may fit your needs. The README implies that it's for Atom, but I think that's just left over from another repo. I'm not a Rubyist, so I didn't install it, but the directions looked pretty straightforward.
That being said, depending on your personal preferences and knowledge, an IDE may work better for you. Of course, it'll take up a lot more room on your HD and in memory, and may get in your way at times, but with that comes many more features that you won't find in a text editor, even one as advanced as Sublime. Try them both out, and use what works for you. Personally, I prefer Sublime over IDEs, as I find many of their "features" annoying, but you'll have to see what best matches your style and needs.
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.
I have been programming almost exclusively in Vim since 1/1/2001, and I feel that Vim fulfulls all my needs as an editor/IDE, but I can't help but wonder if perhaps there have been some new killer features developed for other IDEs in the last decade that would allow me to be more productive than I can be using Vim. So I ask: What are the most important IDE features missing in Vim??
Integrated debugging with all the fanciness that Visual Studio/Eclipse provide (thread debugging, etc etc)
Autocomplete with inline documentation support for methods/properties
Build and run from 'within' the editor application
I miss the excellent refactoring support and code tips from tools such as Resharper. Regexs are powerful for code modification, but understanding the code as Resharper does is just a tad better IMO.
Fortunately I can get both Resharper and Vim in Visual Studio so I am happy.
The real question is: what do VIM have that IDEs are missing.
I find that refactoring would be a real nice thing to have. Changing a java package name in vim with lots of source files can be pretty cumbersome.
Originally the refactoring was the killer feature that made us switch from Emacs. I have now used Eclipse extensively for Java for the last 6 years, and I expect any replacement to have:
Refactoring: Rename variables, functions, change method signatures (including all calls to it).
Debugging: "You are here" "Your current variables are" plus stuff like "go to the defined class for this object" or "go to the actual type for this object". I belive the latter requires quite a bit of integration between debugger and editor.
Code replacement while debugging. Change code, press Ctrl-S and the code in your debugging session is updated with what you just changed. A killer feature for big programs.
Navigation: Simple navigation of class hierarchy (please show me all implementations of this method in this interface and similar).
Javadoc integration - Eclipse can show javadoc just by hovering the mouse over an identifier.
Plus some more :)
Edit: I occasionally miss the Emacs functionality inside Eclipse, but the Eclipse editor has become stronger so it is not so bad anymore. In this regard the Save Action allowing a Format at every save was a killer. This ensures that changes show up properly in the source repository.
Search in files: In most editors, there is a separate window doing the search in files, and simultaneously editing can continue on the main window. The search results are updated as and when they are found. Also the current results can be viewed by clicking on it, even when the searching is ongoing, without waiting for the entire search to be completed.(whereas in cim one has to wait till vimgrep/ctags has finished to view the results)
This is particularly useful for search in large number of files.
So basically something like a search in background and simultaneously show results which can be clicked on to view them simultaneously.
(something like Microsoft Visual Studio 6.0 does)
The things I missed were code completion and debugging. That's why I started using eclim http://eclim.sourceforge.net/index.html so I could use vim for what it does best and eclipse when I actually need it. Try it out - it's a fantastic combination.
It's like the old question "What's worn under a kilt?"
Answer: "Nothing. Everything's in perfect working order!".
But seriously, I'd like to see a more intuitive (easy to use) help system added to Vim.
There is nothing missing in Vim that an IDE has. The only thing we could argue about is; Vim needs to be customized and IDE comes out of the box.
Let me comment the other answeres and how to solve such "needs".
build
As mentioned, use :make and learn how to customize it.
refactoring
Use the very well known ropevim (for Python), it makes a great reafactoring tool. You won't need more than that. There are many others, search for your language.
Autocompletion
I use this snippet together with mapping to TAB (I think supertab plugin does that)
" python stuff
python << EOF
import os
import sys
import vim
for p in sys.path:
if os.path.isdir(p):
vim.command(r"set path+=%s" % (p.replace(" ", r"\ ")))
EOF
" tags for python libs
set tags+=~/.vim/tags/python.ctags
autocmd FileType python,mako set omnifunc=pythoncomplete#Complete
autocmd FileType html,mako set omnifunc=htmlcomplete#Complete
autocmd FileType html,mako set omnifunc=htmlcomplete#CompleteTags
autocmd FileType mako set filetype=mako.html.js
Help system
in Vim is perfect, you just have to learn it's system. It has it's own conventions how are things organized.
Debugging
I don't know for other languages than Python, but running pdb and !python % does it's job.
At work I'm using Perl 5.8.0 on Windows.
When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.
So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.
What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?
As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.
To do that, you'll have to configure and compile the sources yourself. When you run configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programming that shows you how to do it.
Now, go back to your original distribution and run cpan -a to create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.
To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.
Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.
As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrew tool might help you manage that.
Good luck, :)
I would seriously consider looking at using Strawberry Perl.
You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.
If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.
All you need to do is ensure that the new build lists the previous include directories in its #INC array (which is used to look for modules).
By the sounds of it, I think you're on Windows, in which case the current #INC paths can be viewed with
perl -le "print for #INC"
Make sure you target your new Perl version in another directory. It will happily coexist
with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.
Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.
I think the answer to this involves virtualisation of some kind:
Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
Go through your scripts testing them on the new image.
Once you're happy, flip the switch.
The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.
You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running perl -c on each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.
When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.
It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.
I am not sure about building it yourself—I always just used prepackaged binaries for Windows.
I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?
Why don't you use ActivePerl and its "ppm" tool to (re)install modules?