I am mostly playing with F# on Linux and would like to get all the necessary GUI libraries (Gtk, Gdk, Atk, Glib, Pango, Cairo) to be referenced by default so that I can simply use:
open Gtk;;
without any additional typing.
My best guess would modifying the fsi launching script, which at the moment looks like that:
#!/bin/sh
exec /usr/bin/mono /usr/local/src/fsharp/bin/fsi.exe $#
Update: working version of the script as in Stephen's suggestion:
#!/bin/sh
exec /usr/bin/mono /usr/local/src/fsharp/bin/fsi.exe -r "/usr/lib/cli/atk-sharp-2.0/atk-sharp.dll" -r "/usr/lib/cli/glib-sharp-2.0/glib-sharp.dll" -r "/usr/lib/cli/gdk-sharp-2.0/gdk-sharp.dll" -r "/usr/lib/cli/gtk-sharp-2.0/gtk-sharp.dll" -r "/usr/lib/cli/pango-sharp-2.0/pango-sharp.dll" -r "/usr/lib/mono/2.0/Mono.Cairo.dll" $#
I wrote a little script that allows you to use Gtk# from F# Interactive (see below). It references the necessary Gtk# assemblies (you may need to modify the paths) and it also configures F# Interactive event loop, so that you can create and display widgets (such as Window) interactively.
If you want to get the support automatically, you'll need to run fsi.exe with a parameter to load the script on start mono /.../fsi.exe --load:load-gtk.fsx (assuming that you save the script as load-gtk.fsx)
[<AutoOpen>]
module GtkSharp
// Load some common Gtk# assemblies (from /usr/lib/mono/2.0/../gtk-sharp-2.0)
#r "../gtk-sharp-2.0/gtk-sharp.dll"
#r "../gtk-sharp-2.0/gdk-sharp.dll"
#r "../gtk-sharp-2.0/glib-sharp.dll"
#r "../gtk-sharp-2.0/atk-sharp.dll"
open Gtk
Application.Init()
fsi.EventLoop <-
{ new Microsoft.FSharp.Compiler.Interactive.IEventLoop with
member x.Run() = Application.Run() |> ignore; false
member x.Invoke f =
let res = ref None
let evt = new System.Threading.AutoResetEvent(false)
Application.Invoke(new System.EventHandler(fun _ _ ->
res := Some(f())
evt.Set() |> ignore ))
evt.WaitOne() |> ignore
res.Value.Value
member x.ScheduleRestart() = () }
It may be a little different in Linux, but in Windows you can reference assemblies on fsi startup by using -r. e.g.
#!/bin/sh
exec /usr/bin/mono /usr/local/src/fsharp/bin/fsi.exe -r /usr/somedll.dll $#
I am guessing add
-r:/path/to/gtk
or
--load:someStartupScript.fs
which maybe includes some #rs or whatnot. fsi /? and you'll figure it out.
Related
I have the following C# program (test.cs) which I want to debug:
using System;
using System.Collections.Generic;
class Program
{
static void Main(string[] args)
{
Console.WriteLine( "Hello, World!" );
List<int> list = new List<int>();
list.Add(123);
list.Add(234);
list.Add(345);
list.Add(456);
int number = 4;
++number;
Console.WriteLine(" number " + number); // <--- L:16 I want to set a breakpoint here :)
Console.WriteLine("Number of elements" + list.Count);
foreach (Object obj in list)
{
Console.WriteLine(" " + obj);
}
Console.WriteLine("Bye");
}
}
And below is the debug session using lldb and mono (I am in OSX). I can start the session and run the program however I am not able to setup any breakpoint. I guess that when using mono as the executable file things are different. How can I achieve this?
$ mcs -debug test.cs
$ lldb
(lldb) target create mono
Current executable set to 'mono' (i386).
(lldb) b test.cs:16
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) run --debug test.exe
Process 15191 launched: '/usr/bin/mono' (i386)
Hello, World!
number 5
Number of elements4
123
234
345
456
Bye
Process 15191 exited with status = 0 (0x00000000)
(lldb)
I've tried with GBD as this old guide suggests but it is worse, apparently there is something broken in mono in OSX that makes it impossible to debug unless the soft debugger is used (which is exactly what I want to avoid. MonoDevelop debugger is really really unstable/unreliable/slow). This is what I have tried with GBD. No luck at all.
And help is appreciated.
Isn't mono the interpreter for your language and test.exe the binary? lldb only knows about mono -- any breakpoints you try to set would be in the mono interpreter. e.g. if you were debugging an issue with mono itself.
This is a unique enough environment that you'll need to do a little analysis to understand what lldb sees. What do you get for
(lldb) image list test.exe
? Of course if you do
(lldb) im li mono
You'll see mono listed -- because that's a binary that lldb knows about. (you can use plain image list aka im li to see all the binaries that lldb knows)
You can ask lldb to list all of the line table entries based on a source filename with a command line
(lldb) target modules dump line-table test.cs
if lldb has any debug information for a test.cs, you'll see a line table. Without a line table, file and line breakpoints (b test.cs:16) won't work.
For what it's worth, I don't think trying to use lldb (or gdb) to debug your C# program will work. You'll probably need to use some facility of the mono runtime itself to set breakpoints and examine program state.
This is a bit long, so bear with me!
I'm having a bit of trouble working with a Haskell program, that I have to use as part of a uni project. For reference, it's Casper.
So, you're supposed to execute a script, which is actually a Bash script to invoke Hugs interpreter like this:
exec $HUGSBIN/hugs $HUGSARGS +p"Casper> " $FILES
Where $FILES points to a Main.lhs file.
After this, I need to invoke a function "compile" with a path to a file, in the interpreter.
I need to perform the above in a scripted manner. I need this automated because I'm writing a program that will call on Casper in the background.
So I compiled the .lhs file. Now I want to execute the "compile" function but I have no idea how this is done. I try:
./Main compile <a path>
from the command line but it returns me an error about a file "test" not found. Upon investigation, I see these lines in the Main.lhs file:
>main :: String -> IO()
>main = compile "test"
>compile :: String -> IO()
>compile s = catch (compile0 False s) handler
[...snipped]
The 2nd line solves this question. Now my question is, how do I invoke the "compile" function and pass a path to it after I have compiled main.lhs? From the interpreter, I just type "compile " and it works, but I can't get the same to work after compiling the main.lhs and executing from the command line? Any ideas why? Is there any way I can script Hugs if all else fails?
Thank you for any assistance!
You may access the command-line arguments passed to a Haskell program via getArgs. For example, it sounds like you want a main function that does something like this:
>main = do
> args <- getArgs
> case args of
> [] -> putStrLn "What file did you want me to compile?"
> [filename] -> compile filename
> _ -> putStrLn "I only compile one file at a time."
Modify to taste.
Replace main with
main = getArgs >>= \(arg1:_) -> compile arg1
This will pass the first command line argument (arg1) to compile instead of "test", and ignore the rest (_). You may need to add
import System
or
import System.Environment
I can't remember what is needed in hugs for this.
Tim Pope's rails.vim provides a command :A (and a set of related commands) which opens the "alternate" file. For most classes, that's the test, and for the test, the class.
It would sure be nice to have that functionality in non-Rails Ruby projects. Is there a plugin which provides that? Bonus points if it helps me create the test file when I create the implementation file. :)
Our hero tpope wrote rake.vim too. It does the very same things rails.vim does but in Ruby projects.
I created the following command that makes it possible to do
:E /pattern/replace
to jump to the file that is the current filename and substituting pattern by replace
For example, if your tests files are in /test/code.js and your src files in /src/code.js you could write the following command:
command! -nargs=* Es :call EditSubstitute("/test/src")
command! -nargs=* Et :call EditSubstitute("/src/test")
to have the command :Es to jump from testfile to source file and the command :Et to jump from source file to testfile.
Here's the function that does that :
function! EditSubstitute(args)
if (len(a:args))<2
return
endif
let s:delimiter = (a:args[0])
let s:split = split(a:args,s:delimiter,1)[1:]
let s:fullpath = expand('%:p')
let s:bar = substitute(s:fullpath, s:split[0], s:split[1], "")
echo (s:bar)
silent execute('edit '.s:bar)
endfunction
command! -nargs=* E :call EditSubstitute(<q-args>)
I know this doesn't really answer your question at all... but I use VIM buffers to provide easy accessibility to a file and its tests.
I keep my test on top, and the file on the bottom. Then I can view both at the same time.
I use NERDTree to make browsing easier too, but that is not a per-requisite.
You can get a full reference of what I use here:
https://github.com/coderjoe/dotfiles
If you like it I'd recommend NOT using my dotfiles from the above repo, but start with something like RyanB's dotfiles and build your own sets based on your own preferences. :)
Have a look at the vimrc of the guy from 'Destroy all software' https://github.com/garybernhardt/dotfiles/blob/master/.vimrc#L280
pressing <leader>. will switch you between your code and the spec code.
-frbl
This example routine generates two Throw::nocatch warning messages in the kernel window. Can they be handled somehow?
The example consists of this code in a file "test.m" created in C:\Temp:
Needs["JLink`"];
$FrontEndLaunchCommand = "Mathematica.exe";
UseFrontEnd[NotebookWrite[CreateDocument[], "Testing"]];
Then these commands pasted and run at the Windows Command Prompt:
PATH = C:\Program Files\Wolfram Research\Mathematica\8.0\;%PATH%
start MathKernel -noprompt -initfile "C:\Temp\test.m"
Addendum
The reason for using UseFrontEnd as opposed to UsingFrontEnd is that an interactive front end may be required to preserve output and messages from notebooks that are usually run interactively. For example, with C:\Temp\test.m modified like so:
Needs["JLink`"];
$FrontEndLaunchCommand="Mathematica.exe";
UseFrontEnd[
nb = NotebookOpen["C:\\Temp\\run.nb"];
SelectionMove[nb, Next, Cell];
SelectionEvaluate[nb];
];
Pause[10];
CloseFrontEnd[];
and a notebook C:\Temp\run.nb created with a single cell containing:
x1 = 0; While[x1 < 1000000,
If[Mod[x1, 100000] == 0,
Print["x1=" <> ToString[x1]]]; x1++];
NotebookSave[EvaluationNotebook[]];
NotebookClose[EvaluationNotebook[]];
this code, launched from a Windows Command Prompt, will run interactively and save its output. This is not possible to achieve using UsingFrontEnd or MathKernel -script "C:\Temp\test.m".
During the initialization, the kernel code is in a mode which prevents aborts.
Throw/Catch are implemented with Abort, therefore they do not work during initialization.
A simple example that shows the problem is to put this in your test.m file:
Catch[Throw[test]];
Similarly, functions like TimeConstrained, MemoryConstrained, Break, the Trace family, Abort and those that depend upon it (like certain data paclets) will have problems like this during initialization.
A possible solution to your problem might be to consider the -script option:
math.exe -script test.m
Also, note that in version 8 there is a documented function called UsingFrontEnd, which does what UseFrontEnd did, but is auto-configured, so this:
Needs["JLink`"];
UsingFrontEnd[NotebookWrite[CreateDocument[], "Testing"]];
should be all you need in your test.m file.
See also: Mathematica Scripts
Addendum
One possible solution to use the -script and UsingFrontEnd is to use the 'run.m script
included below. This does require setting up a 'Test' kernel in the kernel configuration options (basically a clone of the 'Local' kernel settings).
The script includes two utility functions, NotebookEvaluatingQ and NotebookPauseForEvaluation, which help the script to wait for the client notebook to finish evaluating before saving it. The upside of this approach is that all the evaluation control code is in the 'run.m' script, so the client notebook does not need to have a NotebookSave[EvaluationNotebook[]] statement at the end.
NotebookPauseForEvaluation[nb_] := Module[{},While[NotebookEvaluatingQ[nb],Pause[.25]]]
NotebookEvaluatingQ[nb_]:=Module[{},
SelectionMove[nb,All,Notebook];
Or##Map["Evaluating"/.#&,Developer`CellInformation[nb]]
]
UsingFrontEnd[
nb = NotebookOpen["c:\\users\\arnoudb\\run.nb"];
SetOptions[nb,Evaluator->"Test"];
SelectionMove[nb,All,Notebook];
SelectionEvaluate[nb];
NotebookPauseForEvaluation[nb];
NotebookSave[nb];
]
I hope this is useful in some way to you. It could use a few more improvements like resetting the notebook's kernel to its original and closing the notebook after saving it,
but this code should work for this particular purpose.
On a side note, I tried one other approach, using this:
UsingFrontEnd[ NotebookEvaluate[ "c:\\users\\arnoudb\\run.nb", InsertResults->True ] ]
But this is kicking the kernel terminal session into a dialog mode, which seems like a bug
to me (I'll check into this and get this reported if this is a valid issue).
How do I debug Rscripts that are run from the command line?
I am currently using the getopt package to pass command line options, nut when there's a bug, it is hard for me to:
see what exactly went wrong;
debug interactively in R (since the script expects command line options.)
Does anyone have example code and willing to share?
You could pass your command line arguments into an interactive shell with --args and then source('') the script.
$ R --args -v
R version 2.8.1 (2008-12-22)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> require(getopt)
Loading required package: getopt
> opt = getopt(c(
+ 'verbose', 'v', 2, "integer"
+ ));
> opt
$verbose
[1] 1
> source('my_script.R')
You could now use the old browser() function to debug.
I either use old-school print statements, or interactive analysis. For that, I first save state using save(), and then load that into an interactive session (for which I use Emacs/ESS). That allows for interactive work using the script code on a line-by-line basis.
But I often write/test/debug the code in interactive mode first before I deploy in a littler script.
Another option is to work with the options(error) functionality. Here's a simple example:
options(error = quote({dump.frames(to.file=TRUE); q()}))
You can create as elaborate a script as you want on an error condition, so you should just decide what information you need for debugging.
Otherwise, if there are specific areas you're concerned about (e.g. connecting to a database), then wrap them in a tryCatch() function.