My Google search at first only lead me to a massive discussion thread on github (https://github.com/JuliaLang/julia/issues/69). While certainly insightful and interesting, I think it is convenient for many to have this question answered immediately on stackoverflow.
Multiline comments can be written by putting #= before the comment and =# after the comment. Like so
#=
enter comment here
=#
Note that these are nestable as well.
Related
I have an assigment where I have to describe what this bit of code does but when I type it does not do anything. Any ideas? Here the code.
def unknown(word):
for i in range(1,len(word)+1):
if i==len(word):
return word
if word[i]<word[i-1]:
word=word[:i-1]+word[i]+word[i-1]+word[i+1]
return unknown(word)
unknown('qwerty')
It's doing something. You just aren't seeing what it's doing because you aren't doing anything with the output of unknown. Try replacing
unknown('qwerty')
with
print(unknown('qwerty'))
and see what you get.
Edit:
It looks like there's a typo in your question:
word=word[:i-1]+word[i]+word[i-1]+word[i+1]
should very likely be:
word=word[:i-1]+word[i]+word[i-1]+word[i+1:]
That change should make it do a recursive bubble sort.
In the man page for the GNU version of find, at the end of the
EXPRESSIONS: ACTIONS: -printf section, is the following perplexing line:
A '%' at the end of the format
argument causes undefined behaviour since there is no following
character. In some locales, it may hide your door keys, while in
others it may remove the final page from the novel you are
reading.
I like the imagery, but what the does this actually mean? The find utility does not actually allow such a printf argument to be processed:
> find -printf "%"
find: error: % at end of format string
Inspection of the source code for reasonably recent versions of GNU find shows that it checks for this condition (a trailing %) and aborts with the error you indicate, so the excerpt from the man page appears to be nonsense.
I honestly can't imagine it ever behaved otherwise, so I doubt this excerpt was ever true.
My best guess is that the person writing the documentation somehow got it into their head that find's printf formats were somehow passed directly to the C library's printf function (which is ridiculous) and that the C library code might take some bizarre, locale-dependent action (which also seems ridiculous).
Does Julia have an equivalent of Python's with? Maybe as a macro? This is very useful, for example, to automatically close opened files.
Use a do block. Docs on do blocks are here.
And here is an example of how to do the usual with open(filename) as my_file of Python in Julia:
open("sherlock-holmes.txt") do filehandle
for line in eachline(filehandle)
println(line)
end
end
The above example is from the Julia wikibooks too.
Although the do block syntax does have certain similarities to Python's with statement, there is no exact equivalent. This is discussed in further detail in the GitHub issue "with for deterministic destruction". The issue concludes that this structure should be added to Julia, although no syntax or plan for such is established.
I've been banging my head against ASDF2 and just want a sanity check. When I eval (asdf:initialize-source-registry) with no arguments or with any argument, I get no value. When I check source-registry, I get an empty hash table. Is this a bug?
I'm on AllegroCL Enterprise 64-bit on Windows 7.
This sounds mostly correct to me. In my SBCL init file, I have:
(pushnew #p"/home/paulnath/.asdf/" asdf:*central-registry* :test #'equal)
(push #p"/home/paulnath/.asdf/" asdf:*central-registry*)
Check section 7.9 in the ASDF manual.
Checking the source of asdf.lisp, the source path ends with a (values), which of course returns no values. So I expect to not return anything.
Old question, but yes, that behavior is correct.
If you provide an argument to asdf::initialize-source-registry, then asdf::source-registry will (probably, you may have no .asd files...) not be empty. Also note that lisp distributions may put their own stuff into asdf::source-registry. For example, SBCL puts its internals into it.
The answer given doesn't really answer the question, as asdf::central-registry is a different (and supposedly deprecated even though it takes precedence over asdf::source-registry) mechanism.
I'm looking for a way to mimic Textmate's CSS editing behavior in Emacs.
In Textmate, when adding a CSS property:
#element {} <-- Braces auto close.
#element {background: ;} <-- after typing the colon, the semi-colon is automatically inserted and the cursor is placed between them.
I have taken a look at several css-modes (and textmate.el) but cannot see that anyone has implemented this.
I have absolutely zero knowledge of emacs-lisp would be be willing to give it a shot and write something myself, but does anyone know if this has been done already?
You want to look at some examples of electric functions (the naming convention used when additional input or formatting is performed when particular visible characters are typed).
There's nothing special about the implementation. The key in question is bound within the mode's keymap to a function which does the work. Aside from the fact that you must handle the insertion of the character typed, it's just like any other keybinding.
cc-mode has several examples. The basic approach looks like this:
(define-key c-mode-base-map "{" 'c-electric-brace)
(defun c-electric-brace (arg)
(interactive "*P")
;; [...]
(self-insert-command (prefix-numeric-value arg))
;; [...]
)
Admittedly c-electric-brace is a far more complicated function than you might be expecting, but it would be trivial to have a function which simply inserted the same number of }s after inserting the {s.
(defun my-electric-brace (arg)
"Automatically add a closing '}' for every '{' inserted."
(interactive "*P")
(let ((count (prefix-numeric-value arg)))
(self-insert-command count)
(save-excursion
(insert-char ?} count))))
(defun my-css-mode-hook ()
(local-set-key (kbd "{") 'my-electric-brace))
(add-hook 'css-mode-hook 'my-css-mode-hook)
You might find that is a little simplistic, and there are circumstances in which you don't want the matching brace to be inserted, however. You would probably also want to deal with automatically removing matching braces when you delete one of them, by defining electric delete functions.
Your electric colon requirement is also less trivial than the brace, as it should only occur in the right context (although in practice you might get away with a naive implementation, as I don't think you would be typing colons in a CSS file that were not in the correct context.)
Hopefully this points you in the right direction, if you decide to write your own solutions.
Obviously you would want to read some tutorials on elisp, but for understanding the code above, just note that you can use C-h f (describe-function) to read the documentation for any elisp function (or M-x find-function to view the code).
For general purpose autopairing of all sorts of braces, etc you might want to take a look at autopair-mode.