I am wondering how people typically go about debugging applications that are written in multiple languages.
For example, you could have some javascript that calls some back end python code. Is there a way to set up debugging so that you can start debugging in one language i.e. javascript, and then switch to the python debugger once that bit of code gets called?
My use case is with PowerShell and some .NET class libraries but it seems like there might be a broader set of use cases.
Related
I was asked by a friend to write a simple GUI containing some charts and selections of common commands for an application he wrote in Forth. However, I have basically zero knowledge about Forth, only that you can't write a GUI in this language (at least that's what he told me).
Now I've been wondering what other programming languages you would suggest which do interact well with Forth and provide libraries (e.g. Java Swing) for interface programming?
Note: I'm still a beginner in programming, and my experiences so far are limited to Java, HTML, CSS, JavaScript, and some C#.
Win32Forth comes with complete Windows GUI and words to use all user32.dll and gdi32.dll functions. It also has a great development environment and windows form creator and editor. Very easy to create user interfaces with it.
SP-Forth allow developing applications with GUI and library WinLib: http://spf.sourceforge.net/ UI libs: http://spf.sourceforge.net/docs/devel.en.html#ui
I would suggest XHTML and Co. (i.e. CSS, JavaScript, XSLT, HTTP) to create user interface (GUI) and interact with Forth. In most general case you include an http-server into Forth system. In some special cases a Web browser object can be embedded into Forth application (for example, using COM on Windows).
Also on Windows you can use HTA (HTML Application) — quite simple solution. HTA can be started from Forth as well as Forth from HTA.
Another way is to use Qt framework (some Forth systems can have bindings).
Yet another way — just use API to underlying system (like user32.dll and gdi32.dll on Windows). Some Forth systems contain GUI-libraries that are based on underlying system API.
Also as edge case, user interface can be implemented in any language as shared library or as separate process with IPC (inter process communication) to Forth system.
In any case, usually GUI is created using special languages, libraries or APIs. GUI is not a subject of Forth as general-purpose programming language.
Bernd Paysan's MINOS may be a way to write GUI code in Forth:
https://bernd-paysan.de/theseus/minos-1.html
Adding a GUI to a program written in Forth is no different from the same problem in any language. You either have to write graphic code yourself or be able to call graphic libraries. In both cases on e.g. MS-windows you have to call functions present in DLL's and you need the documentation of those functions. Most serious Forth's allow to call DLL's. Of course libraries that are internal to a different language are less easily used, but why would you want to? You then commit to that language and are better off using that language from the get-go.
Forth being an interpreter you can couple a plot program easily via a pipe, but that is a one way street. It may be viable if the plot program has the interaction ( such as enlarge, change scale, crop, print etc.) you need.
I am writing a big project using c++. In this project, some lua scripts will be called to implement functions. Now I want to set breakpoints in lua scripts but I don't know how to do that. I would prefer something like "pdb.set_trace()" as for python.
Any idea would be appreciated. Thanks in advance.
Unfortunately, Lua has no built-in debugger, and many of the debugging options available to you in the Lua standalone are not available in an embedded Lua scenario.
One way to deal with this would be to "script in" debugging - simply use print(whatever) and print(debug.traceback()) liberally throughout the code, possibly switched on or off by a DEBUG global (perhaps set by a DEBUG #define in the C++ code) so that the messages wouldn't be emitted in production executables.
Also, when using lua_pcall(), if a function has an error, it calls debug.traceback() and puts the resulting string on the stack. You can get it with:
lua_pushcfunction(L, c_function_name);
lua_pushnumber(L, 5.3);
if (lua_pcall(L, 1, 0, 0) != 0) lua_error(L);
A note: none of this works unless you open the debug library first, using luaopen_debug(L); where L is your lua_State*.
If you really do need interactive debugging, as #Colonel Thirty Two said, you should find an interactive debugging library; I'm sure one is available, but that is outside the scope of a StackOverflow question.
Can GO be used as a scripting language within an application ? I can't find any informations about this: is there a dynamic link library version which could be interfaced from a Windows application with some standard methods such as Compile(), Execute and features such as callbacks, variables sharing etc ?
This might sound strange at first but go with me on this: I think it would be a perfect candidate for a scripting language because it's compile time is so fast....hear me out...
Most scripting languages are interpreted, and so they do not require (or even provide in some cases) compilation. However compiled languages are safer in general because they can catch certain errors at compile time, which is better than, for example, catching a syntax error at runtime.
With Go, the compile time is so speedy that whatever program is running your Go code (e.g. a web server) could hypothetically compile the code on-demand if the code has changed, and otherwise use the compiled version.
Actually if you check out Google App Engine and download their dev web server for Go (https://developers.google.com/appengine/) you'll notice that their web server does exactly this. If you run through their Hello World tutorial for Go you'll notice that if you make changes to your code you won't need to recompile the Go code in order for the changes to take affect.
Go is not a scripting language. Because Go is designed for fast compilation, there have been some attempts to use it as a scripting language. For example,
gorun
GoNow
In theory (and perhaps somewhere out there w/o me knowing), Go can be used as a script language. Just note that it makes as much sense as using e.g. C as a scripting language.
No. Go code cannot be used within a non-Go application unless Go is responsible for starting up the whole app.
During web searching, I found the following comment : Traditional Lisp debugging practices can still be used.
What are the traditional debugging practices?
Normally, what tools are used for debugging lisp (with/without emacs)?
I don't know what Bill meant specifically, but IME:
Typically your editor will have a running instance connected to it. You can compile functions immediately to insert them into the running image -- since Lisp has its own compiler, you're just telling the running image to read and compile a small section of text. Or you can run functions directly, to see what they do.
When an exception is thrown (or a condition is signaled, if you're lucky enough to be in a dialect with conditions), the debugger will show you the stack trace and let you decide how to continue.
The major difference between Lisp and other high-level compiled languages is that in Lisp you're basically always writing code with the debugger attached.
As clojure was tagged in the question, I'll give our perspective.
Class files generated by the clojure compiler include line- and method-based debugging info, so any java debugger will interoperate directly with clojure code, including breakpoints and object inspection.
If you use emacs/slime as your development environment, integration with slime's debugger has recently been included. As documentation is a little sparse, it's probably best to check out the scope of the support on github directly.
Run edebug-defun in emacs and you will see that lisp is magic.
In something that I would call approaches a "traditional set of Lisp debugging techniques" are:
Debug printouts
Function tracing (each invocation of a traced function
is printed with an indentation that corresponds to call depth, on return the return
value is printed).
Explicit invocation of the in-image debugger
Ending up in the in-image debugger due to a bug (trying to add an integer and a symbol, for example)
Basically just things like adding code to print out values as it runs so you can see what's happening.
I need to write an app that reads a config file with info on the menu bars it needs to create.
Normally, I'd just use java, but I need the application to have the least run-time dependencies possible, this includes not forcing the user to download anything, even JRE, let alone something like NET Framework.
So I need something that can compile to an EXE (windows only for now), and that will allow me to CODE the GUI, so I can dynamically create it from my config.
BTW: something like C++ is a bit too low level, all I need is to create menus, and display HTMLs in a panel.
How about wxPython together with py2exe?
There is a nice tutorial on how to do it here.
If Java's too high-level and C++ too low-level, there ins't much in-between. Maybe Delphi?
I wouldn't totally write off using Java and/or Python for a few reasons.
1) py2exe can compile your Python code to an exe.
2) GCJ can compile your Java code to an exe.
Delphi is best chose for you. Because Delphi compile source code into native x86.
Unless you have serious reasons to avoid interpreted languages, I would suggest you better look into ways of packaging or compiling interpreted scripts because doing this will likely reduce your learning and development time.
I would write a simple GUI in Tcl/Tk, and then package it as a Starpack.
ActiveState provides a distribution (ActiveTCL) and a decent editor (Komodo Edit), and it is fairly easy to get simple GUIs going with Tk. Check out TkDocs for some hand holding.
Once you're done, you can package your code, a Tcl runtime, a database, and a virtual filesystem, all into a single executable that you can easily distribute.
Earwicker is right. You can use HTA:
http://www.interclasse.com/scripts/htanotepad.php
But if you know C++, then creating this type of an application is actually very easy with Visual C++. Use MFC, and statically link everything. You can draw the menu in the resource editor, and attach events to the menu items. I wouldn't use HTML if I were you. Just use regular Windows controls. But if you're really set on using HTML, you can embed a Browser control in the formview.
Have you considered D ? It has a syntax that is like a mixture of Java, C++ and Python with the ability to make native windows apps. The tutorials on dprogramming.com are great to get up and going with the language. For quick GUIs you'd be interested in The D Forms Library and the Entice Designer.
Here are some short video tutorials to get up and running with Entice.
Alternatively, have you tried Qt & Qt Creator? It takes a lot of the hair pulling out of C++ Programming and it's also cross-platform.
You say:
all I need is to create menus, and
display HTMLs in a panel.
A lot like a Web browser, then. If it's going to run on Windows, then the user has IE. Why not use IE to do all the work for you?
You can make something a lot like an .exe with IE, called an .hta:
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx