implementing command change from sbt documentation - scala

I am reading the sbt documentation on commands. It talks about how one can write commands by creating a commandExample and placing it in the project directory and creating command word sequences in the build.sbt.
My implementation follows that instructions and the commands for hello and helloAll both work , however the changeColor command throws an error. What imput parameter am I to enter in to the sbt terminal to activate the newly made command ?

Related

VSCode CLI : Disable electron logging

Is there a way to not display this electron loggings on executing code <path> command ?
I prefer the CLI to not livetail this logging so that I can proceed with other command lines.
I cannot find article for this inside the CLI doc https://code.visualstudio.com/docs/editor/command-line.
Somehow it will do a livetail for the first time we use the code <path> command. The subsequent usage will not show the livetail.
As suggested in this github issue, try running code.cmd in ~/AppData/Local/Programs/Microsoft\ VS\ Code/bin, not Code.exe in the parent folder.

Opening a Scala Play console and executing commands programmatically

I have a Scala script that accesses models from my Play project and rather than open up a console and run it manually, I would like it to be run automatically after a Git hook. This could be achieved via a small bash script but there doesn't seem to be a way to execute the ":load nameOfMyScript.scala" command after the Play console has opened. Is this possible or am I going about this the wrong way?
I also considered running this command via a plain Scala console but I cannot figure out how to load my Play project definition inside of the Scala console.
Any help would be greatly appreciated.
From the sbt console of your Play app, run the console command. This will start the Scala REPL and give you access to everything on your app's classpath.

How do I debug puppet beaker tests using netbeans?

I am trying to understand why some of the puppet code do not work as expected. I run the puppet beaker test using "rake beaker" command. I am failing to understand how can I tell netbeans to run this command after I set the break points in the sources. I tried to set the project configuration with the appropriate parameters from following command line which "rake beaker" invokes.
/usr/local/rvm/rubies/ruby-1.9.3-p545/bin/ruby -I
/usr/local/rvm/gems/ruby-1.9.3-p545/gems/rspec-support-3.1.0/lib:
/usr/local/rvm/gems/ruby-1.9.3-p545/gems/rspec-core-3.1.4/lib
/usr/local/rvm/gems/ruby-1.9.3-p545/gems/rspec-core-3.1.4/exe/rspec spec/acceptance --color
But the debugger simply starts and ends?
Any idea, how can I debug a rake task?
Update:
As per this I can start the rake beaker task using the ruby-debug-ide, however it does not break at the break points I have set. As per the blog I believe I have break points set in the files, which will run using ruby-debug-ide.
By the way I am running Netbeans 8.0.1 on CentOS 6.4
One way I found out is to
Create a Netbeans ruby project
Set the breakpoints wherever needed.
Open the rspec binary file in Netbeans editor window.
Debug rspec file, by pressing Ctrl-Shift-F5
Provide the parameters in the debug dialog as shown in picture below
And you are done

PyCharm behavior inconsistent with command line ironpython

I have an ironpython script which I am launching in pycharm. The script imports custom c# assemblies and employs classes found within. Everything is fine when this script is launched at command line. The problem comes when I try to launch the script in pycharm. I get an error like this:
SystemError: Could not load file or assembly 'great_assembly.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
This comes from the line I pasted below. This line is just retrieving a path (string) from a settings object.
clr.AddReferenceToFileAndPath(self.settings.__getitem__('greatAssembly'))
The run configuration is perfectly standard. It has all default settings. It is using the proper interpreter (IPY 2.7). Anyone have any idea why this might show up in pycharm but not at command line?

i really would like sbt and its console to work under cygwin any way you think it can be done?

i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.