OperatorTable addAssignOperator(":", "myAssignMethod")
"foo" : "bar"
That gives an error that a Sequence does not respond to ":" (":" is still being treated as a message, not an operator).
I think it should get evaluated to myAssignMethod("foo", "bar") (since "foo" = "bar" becomes updateSlot("foo", "bar")), but it's not. However:
OperatorTable addAssignOperator(":", "myAssignMethod")
doString("\"foo\" : \"bar\"")
that does work properly, and myAssignMethod gets called. So how do I get whatever processing happens on the code during doString() to work in the main code of the file?
: is a valid identifier, and has special meaning. It's used to indicate number of arguments in the objective-c binding. It's highly recommended you choose another operator.
Also note, that all operator table modifications must be done prior to your file you're using them in being loaded and parsed, since operator shuffling occurs at compile time (when the file is loaded) and not at evaluation time. The REPL hides this problem as it has a new compile with each time you hit enter.
Additionally, if you want to see what something will be compiled to (useful for operators) wrap it inside a message() call. i.e., message(1 + 2) will yield 1 +(2) in the REPL.
Turns out this appears to be a bug in the Mac environment that was fixed recently; I was working off the MacPorts build of Io, and the '20090105' version of the environment has this bug. Running the same code on the Windows/Linux binaries resulted in the expected behavior.
Related
I upgraded to rpy2.ipython from rmagic but it seems that every statement now prints to the console. Previously, an explicit print had to be called.
Is there an option to get back the former behaviour ?
This is fixed now in version_2.4.x on bitbucket:
https://bitbucket.org/lgautier/rpy2/commits/e22cdab51c94a504c4ea9808c6fad2772a34ef5e?at=default#Lrpy/ipython/rmagic.pyT216
Basically, I had a conceptual glitch while trying to fix up that logic - R is a Lisp, and withVisible operates on the code it gets in a way that doesn't translate via rpy2's python wrapper (which will operate in pythons function execution semantics, where the innermost is evaluated, return values passed out, etc.).
You can set a breakpoint on the closing } of a Scala method, but it's pointless to do so because it won't be hit, apparently.
I would still like to set it there. So I thought, "how about I put in a no-op before that line, and set a breakpoint on that?"
But since evidently Eclipse is not warning me when I try to set a breakpoint that will never be hit (because there is no code there), I therefore can't rely on Eclipse telling me if a no-op has been optimised out (particularly as I'm not even using the same version of Scala to run the code as the Eclipse Scala plugin is using).
So is there a short no-operation statement or expression that I can use here which is guaranteed not to be optimised away by the Scala compiler, in all circumstances - and guaranteed not to be optimised away by a JIT in a way that prevents a breakpoint on it being hit? I guess it has to be an expression rather than a statement in my case, because this method returns a useful value, not Unit.
It's not exactly a no-op, but a logging statement (or trace expression - i.e. a logging statement which additionally returns the value it has just logged) is guaranteed not to be optimised away!
The only trouble with that is, you have to manually step over the debug statement or trace expression each time you hit the breakpoint, if you want to see what it actually outputs. Unless it's just outputting the value of a variable, in which case you can find that variable in the Variables tab in Eclipse.
And stepping over a trace expression, at least in my code, with the Eclipse Scala plugin 2.1 milestone 2, in "old-style debugging mode", is no small matter - because it's completely broken, due to this issue!
Before I realised what was going on, it took me about 20 tries of pounding the F6 and F7 keys before I finally managed to step over it! And that was just for stepping over it once!
And remember, the next line is the } - so the obvious workaround, setting another breakpoint on the next line - won't work!
Theoretically you should just be able to Inspect the value being traced, rather than trying to step over the trace. Unfortunately, that doesn't work for me either - it says class not found.
I'm working on a program mode, which has various different calls to assemblers, programmers and other external programs. My cunning plan was to handle all of these with the compile function, passing an explicit compile-command that depends on which program is being run.
This sort of seems to work and now I want to add specific error regexps for the different external programs. One option would be to alter compilation-error-regexp-alist-alist, keyed on my major mode and then add my major mode to compilation-error-regexp-alist.
What I'd prefer to do, though, is something like the following:
(let ((compilation-error-regexp-alist
(cons <my-regexp-and-numbers> compilation-error-regexp-alist))
(compile <my-compile-command>))
What's weird is that this binding doesn't seem to affect the way the compilation buffer gets parsed / marked up. If I manually push <my-regexp-and-numbers> onto the front of compilation-error-regexp-alist and then call (compilation-mode t) on the buffer, everything gets fontified as expected (so I haven't got the regexp wrong). However, sticking the call to (compilation-mode t) inside a let form as above doesn't affect anything.
I realise this fails miserably as an easy-to-reproduce test case. If no-one has any ideas, I'll try to hack out an example, but I'm hoping that someone will go "Ah, yes! That's because doesn't get evaluated then, but rather at " or the like...
My guess is that the variable is set for the command but somehow is not passed to compile buffer.
Try your method and view the value of the variable (C-h v) inside the compile buffer for confirmation.
why doesn't eclipse match the argument while doing code completion. In the following example it should have automatically matched the throwable. In stead it shows arg1 as the first option.
The autocomplete options in Eclipse for auto-completed method arguments, start with the parameter names found in the source distribution (that contains the class with the method). If no source distribution is available, then it will use the parameter names as indicated in the binary distributions i.e. in the compiled byte code. This is the default behavior
If you want to change this behavior of inserting parameter names from source code or binaries to inserting the best guessed arguments (including local variables), then you can configure the auto-complete options of Eclipse to do so, as shown in the following screenshot:
This will produce the desired result of automatically displaying the options containing the list of best-guessed arguments. This also seems to avoid suggesting parameter names:
I guess arg1 is thing you already typed. So the proposal eclipse can provide is trying to find something which start from arg1.
So it puts it as the first choice.
You can type t , and try Alt+/ , to see if this is the reason.
I've built a number of work-specific helper functions that could be useful for other members of my team&mdash. But I've written them all in Emacs' Elisp, and getting them to convert from Notepad++ is NOT going to happen.
So, I'm thinking convert the functions to Perl. No problem.
Except I use ido-completion all the time to limit responses:
(setq client (ido-completing-read "Select a Client: " '("IniTrade" "HedgeCorp" "GlobalTech" "OCP") nil t))
EDIT: ido-completing-read is similar to completing-read, except that all the options are visible, and can be selected via cycling [arrow-keys, usually] or typing-completion. In the example above, the prompt would look like
Select a Client: {IniTrade | HedgeCorp | GlobalTech | OCP}
selections can be made on the left-most item by hitting RET, or by partial typing (in this case, the first letters are all unique, so that's all that would be needed, and the matching item would become the left-most).
nil in the example is an unused param, but "t" requires an exact match -- eg, the user must make one of the selections. The function returns a string, such as "IniTrade".
My "helper functions" are for internal needs -- opening a particular error log, restoring a batch to the server, etc. For these operations, the user needs to specify test or production environment, client, stage, etc. In almost all cases, these are string selections that are used for building another shell command. If a numeric item is returned, that could in turn be re-translated to a string -- but since the selections are usually the required string, it would be nice if that step could be skipped. [end EDIT]
Is there a Perl equivalent? I've looked at Term::Prompt which offers up a numbered-menu... closest I've found. That's not as pretty as ido-completion, and I'd still have to convert a numeric-result backwards to a string (not a major issue; just annoying).
While composing this, I noticed I used the term 'menu', so did some more searching and came up with Term::Menus. I haven't tried this one yet.
Term::ReadLine may do what you're looking for, though it's probably more like 'completing-read' than 'ido-completing-read'.