If I have an audio file, how can I play it using Prolog? I cannot find any code in the documentation that relates to audio playing.
You will have to use some interface to the system for that (i.e. get out of the Prolog world and tell the surrounding system to do something).
If you are comfortable coding in C and have an audio-playing API somewhere, the Foreign Language Interface.
More reasonably, you can use the shell/1 (or the Win32 equivalent) predicate to issue a shell command to a command interpreter: Operating System Interaction
Related
I'm writing a coding language of my own and I want to be able to create console applications, this means I need to be able to catch the standard streams of me process.
Can anyone give me any insight into how this is done in other languages?
For example, how does the Console class in C# work behind the covers? Or what does cout in C++ compile to?
Any insight would help, I don't have a solid lead.
There is no portable solution without a library. Indeed, the point of the standard C I/O library is to provide a portable solution.
Each platform will also have its own libraries (for the various supported languages), which you could use if your compiler can produce anappropriate calling sequence.
The existence of the three standard streams (input, output and error output) is, in part, an artifact of the standard C library but there is usually an obvious translation from the platform's native interface.
For example, the Posix interface, in which every I/O stream is referenced with a small integer, called the "file descriptor" (fd), reserves fds 0, 1 and 2 for the three standard streams. Posix shells arrange for these fds to be correctly associated when they initiate a console application.
Windows has a different mechanism, which you can probably read about in the Windows documentation. (The shell interface is very different.)
And so on.
Edit. I am working in a Windows environment.
I want to write a simple game in console output with OCaml. I need to be able to use a 'read_key' function. But :
The graphics module throws an error : Exception: Graphics.Graphic_failure "graphic screen not opened". But I do not want to open the graphic window.
The function read_line forces the user to press "return" after every key press...
It is not possible to implement such function using pure OCaml. You will need to call to platform specific libraries. It is not an OCaml problem, this is the same for other languages, including python, java, c, etc. Actually, interacting with a terminal in a portable way is kind of rocket science. Mostly for historical reasons.
I suspect, that you don't want to get into such troubles, so I can suggest few easy solutions:
Use OCamlSDL library, - you're developing a game, and SDL is for games
Use Graphics module, yes you will need to open the graphic window, and your game will not be a pure console... but maybe this is not a big issue. Also, you can make a black background and emulate a terminal :)
Install Cygwin version of OCaml. You will get a unix-like environment, and Unix.tc_* will start to work.
Switch to a normal operating system. Where by normal I mean Unix-like. You can use virtual machine, or containers, like Docker, for a first time.
I need to find a sound library for haskell. I have followed instructions of some that are presented in haskell wiki http://www.haskell.org/haskellwiki/Sound_data_structures but couldnt get any to work. All i need is to play audio files, regardless its format.
I am developing a game with FunGen, and its time for music. I may have somo problems making them work togather, but I cant even play a simple sound example.
Most of my problems are due to cabal installation, or dependancies I cant find anywhare. I am using Windows.
Being on Windows is a major limitation in Haskell audio. Most packages are bindings to C code, and they tend to be either Linux-centric (JACK, Alsa) or at best nominally cross-platform but in practice difficult to build and use on Windows. You'll need to build or install the C library first before installing the Haskell binding.
Have you tried OpenAL? It's probably the most well-suited for what you want to do. If you install the C OpenAL libraries, the Haskell binding should be a fairly simple next step. There are a few add-on packages that are meant to simplify some common tasks, like ALUT and Alure.
Otherwise, most other solutions would actually involve several packages that may not work well together. hsndfile and hsndfile-vector are good for reading audio files (you'll need to have libsndfile installed), but they don't play sound. portaudio will play audio (again, you'll need the C portaudio library), but it hasn't been updated in a while (and some updates are badly needed). You'll also need to be moderately familiar with a C compiler chain (e.g. MinGW or Cygwin) to install the necessary C libraries first.
Another way might be to bind to a dedicated audio language such as Supercollider or Csound. This would be a rather heavyweight solution, but the bindings tend to be better-maintained and at least Csound should be easily installable on Windows (disclosure: I wrote the hCsound package). Sox (C library/executable) might also work for you (I've never tried it on Windows, but it claims to work).
All i need is to play audio files, regardless its format.
Your best bet for this will be hsndfile, mentioned in John L.'s excellent answer above. But you may want to make your life easier initially. The WAV file format is a very simple format -- essentially consisting of raw PCM data with minimal headers prepended. Try to get a WAV file to play, and then broaden your horizons from there.
You will be fighting uphill against a lack of sample code -- and you may find yourself needing foreign memory pointers and other not-so-straightforward techniques -- but there's a decent sample for opening and reading a WAV file here.
Also, when developing on Windows, learn to love the -fno-ghci-sandbox flag. It tells ghci that you're connecting to a library that uses its own thread local storage. It's often the only way to get certain external libraries to work in GHCi.
I need to develop a large set of tools to be run from the server command line (i.e. not client-server architecture). The systems does not have to be high-performance; I just want something that is easy to develop with.
Which technologies are out there I can use to build simple GUI to be run from the command line? I need only menus where I can select a line/check-box/enter free text in a dialog.
Edit: forgot to add, access to Mysql (i.e. drivers available) is essential.
Shell, with dialog, the old stand-by - http://www.linuxjournal.com/article/2807
EDIT- If it's MySQL-related, take a look at PERL-Tk and DBI.
python + ncurses would be a good combo here.
i like using perl's re.pl from the Devel::REPL library for quickie cli interfaces. read on a bit for my rationale before downvoting!
in this type of app it sounds like you will be doing query-type operations. these naturally lend themselves to a "repl" style interraction. re.pl gives you all of the goodies, namely command editing and history. all you need to write are the functions that users will call. the nice thing is that users who know perl will realize they can use any installed module to extend the functionality of your system on their own. i my case, i used re.pl to create a mysqlclient-like tool to access and display data that was being compressed in a way that the standard mysqlclient couldn't deal with.
i cite perl because it's DBI is the best database abstraction and it is what i have used....but the rationale can be extended to other tools. python's repl or any other would provide the same benefit.
You could use Mono for Linux and write your program in C# .NET, then make it work for Linux, since Mono allows so.
As far as graphic command line interfaces go, one of the best frameworks is ncurses. It abstracts away most of the ugliness associated with graphic command line applications.
I have to say, use Python, because I like it.
But text-based interfaces are pretty much not worth it, because they seem like a good idea until you look at the details:
There isn't really a standard keyboard navigation model for text-UIs; they all use their own scheme
How is unicode supported? (Hint: this is nontrivial)
What about different keyboard layouts? What key does someone press if their keyboard doesn't have, say, a "home", "end", or "Escape" ?
ncurses does not provide a widget set, only low-level operations. The answers to the above questions aren't easy.
It really shows that nobody has put much thought into keyboard-and-text-driven terminal-based UIs recently, or these would all have been solved.
Web interfaces have them solved, in fact, you can use a text-mode web browser if you like.
Modern devices like i(phone|pad)s and even cheap mobile phones have a web browser which is good enough.
It is easy to write a web application which uses a very simple style (few images, little Javascrfipt) and have it work without much effort on a variety of devices.
So I would say go with dmckee's comment "go with what you know".
By building your own terminal-based interface, you are going to box yourself into a corner in the long term.
Is there a programming language which can be programmed entirely in interactive mode, without needing to write files which are interpreted or compiled. Think maybe something like IRB for Ruby, but a system which is designed to let you write the whole program from the command line.
I assume you are looking for something similar to how BASIC used to work (boot up to a BASIC prompt and start coding).
IPython allows you to do this quite intuitively. Unix shells such as Bash use the same concept, but you cannot re-use and save your work nearly as intuitively as with IPython. Python is also a far better general-purpose language.
Edit: I was going to type up some examples and provide some links, but the IPython interactive tutorial seems to do this a lot better than I could. Good starting points for what you are looking for are the sections on source code handling tips and lightweight version control. Note this tutorial doesn't spell out how to do everything you are looking for precisely, but it does provide a jumping off point to understand the interactive features on the IPython shell.
Also take a look at the IPython "magic" reference, as it provides a lot of utilities that do things specific to what you want to do, and allows you to easily define your own. This is very "meta", but the example that shows how to create an IPython magic function is probably the most concise example of a "complete application" built in IPython.
Smalltalk can be programmed entirely interactively, but I wouldn't call the smalltalk prompt a "command line". Most lisp environments are like this as well. Also postscript (as in printers) if memory serves.
Are you saying that you want to write a program while never seeing more code than what fits in the scrollback buffer of your command window?
There's always lisp, the original alternative to Smalltalk with this characteristic.
The only way to avoid writing any files is to move completely to a running interactive environment. When you program this way (that is, interactively such as in IRB or F# interactive), how do you distribute your programs? When you exit IRB or F# interactive console, you lose all code you interactively wrote.
Smalltalk (see modern implementation such as Squeak) solves this and I'm not aware of any other environment where you could fully avoid files. The solution is that you distribute an image of running environment (which includes your interactively created program). In Smalltalk, these are called images.
Any unix shell conforms to your question. This goes from bash, sh, csh, ksh to tclsh for TCL or wish for TK GUI writing.
As already mentioned, Python has a few good interactive shells, I would recommend bpython for starters instead of ipython, the advantage of bpython here is the support for autocompletion and help dialogs to help you know what arguments the function accepts or what it does (if it has docstrings).
Screenshots: http://bpython-interpreter.org/screenshots/
This is really a question about implementations, not languages, but
Smalltalk (try out the Squeak version) keeps all your work in an "interactive workspace", but it is graphical and not oriented toward the command line.
APL, which was first deployed on IBM 360 and 370 systems, was entirely interactive, using a command line on a modified IBM Selectric typewriter! Your APL functions were kept in a "workspace" which did not at all resemble an ordinary file.
Many, many language implementations come with pure command-line interactive interpreters, like say Standard ML of New Jersey, but because they don't offer any sort of persistent namespace (i.e., when you exit the program, all your work is lost), I don't think they should really count.
Interestingly, the prime movers behind Smalltalk and APL (Kay and Iverson respectively) both won Turing Awards. (Iverson got his Turing award after being denied tenure at Harvard.)
TCL can be programmed entirely interactivly, and you can cetainly define new tcl procs (or redefine existing ones) without saving to a file.
Of course if you are developing and entire application at some point you do want to save to a file, else you lose everything. Using TCLs introspective abilities its relatively easy to dump some or all of the current interpreter state into a tcl file (I've written a proc to make this easier before, however mostly I would just develop in the file in the first place, and have a function in the application to resources itself if its source changes).
Not sure about that, but this system is impressively interactive: http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html
Most variations of Lisp make it easy to save your interactive work product as program files, since code is just data.
Charles Simonyi's Intentional Programming concept might be part way there, too, but it's not like you can go and buy that yet. The Intentional Workbench project may be worth exploring.
Many Forths can be used like this.
Someone already mentioned Forth but I would like to elaborate a bit on the history of Forth. Traditionally, Forth is a programming language which is it's own operating system. The traditional Forth saves the program directly onto disk sectors without using a "real" filesystem. It could afford to do that because it didn't ran directly on the CPU without an operating system so it didn't need to play nice.
Indeed, some implementations have Forth as not only the operating system but also the CPU (a lot of more modern stack based CPUs are in fact designed as Forth machines).
In the original implementation of Forth, code is always compiled each time a line is entered and saved on disk. This is feasible because Forth is very easy to compile. You just start the interpreter, play around with Forth defining functions as necessary then simply quit the interpreter. The next time you start the interpreter again all your previous functions are still there. Of course, not all modern implementations of Forth works this way.
Clojure
It's a functional Lisp on the JVM. You can connect to a REPL server called nREPL, and from there you can start writing code in a text file and loading it up interactively as you go.
Clojure gives you something akin to interactive unit testing.
I think Clojure is more interactive then other Lisps because of it's strong emphasis of the functional paradigm. It's easier to hot-swap functions when they are pure.
The best way to try it out is here: http://web.clojurerepl.com/
ELM
ELM is probably the most interactive you can get that I know of. It's a very pure functional language with syntax close to Haskell. What makes it special is that it's designed around a reactive model that allows hot-swapping(modifying running code(functions or values)) of code. The reactive bit makes it that whenever you change one thing, everything is re-evaluated.
Now ELM is compiled to HTML-CSS-JavaScript. So you won't be able to use it for everything.
ELM gives you something akin to interactive integration testing.
The best way to try it out is here: http://elm-lang.org/try