Showing posts with label shell. Show all posts
Showing posts with label shell. Show all posts

Monday, August 30, 2010

ObjectIcon 2.4 and Cygwin make

ObjectIcon 2.4 is available at code.google.com/p/objecticon

This is the Icon language of the late Ralph Griswold and others as extended by Robert Parlett with class-based objects and Unicode.

If you are a Windows user with Cygwin as your gcc build environment, you will have to recall how to apply env var changes to the current shell: ObjectIcon comes with a handy paths.sh file which will only be of use if run as
.  ./paths.sh
where the initial dot ensures that a script not using exit will have its variables export into the scope of the current shell in which it will run.  Just running the script will not set the var's for ObjectIcon to use.

This way you are able to pick up the ObjectIcon env vars such as OIHOME without adding them into a bash rc file or the like.

On my system that paths.sh file is
# Object Icon path settings

export OIHOME="/cygdrive/i/objecticon-2.4"
export OIBIN="$OIHOME/bin"
export OILIB="$OIHOME/lib"
export OIPATH="$OILIB/main:$OILIB/gui:$OILIB/xml:$OILIB/parser:$OILIB/ipl"
export OIINCL="$OILIB/incl"
PATH="$PATH:$OIBIN"
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$OILIB/native"
export TRACE OIMAXLEVEL

Tuesday, July 31, 2007

Windows and the Tea Shell

The Tea shell for the JVM has been available as version 3.2.2 for some months now.

There is no problem running the shell under Windows if you had Tea 3.1.0 up and running.

The first problem is that 3.2.2 includes no TEA.BAT in the tgz file. Just get the old 3.1.0, extract the bat file and update it to suit your install.

Tea must find a GNU jar for regexp and a Xerces jar for XML parsing. I reference them explicitly in a temp CLASSPATH in that BAT, e.g.,
set CLASSPATH=%TEA_BASE_DIR%;%TEA_BASE_DIR%\xerces-1.4.4.jar;%TEA_BASE_DIR%\gnu-regexp-1.0.8.jar;%CLASSPATH%

Tea is intended to bring multi-paradigm programming to the JVM. It is a java-based functional langauge with extensions for procedures and classes. This is another language intended to be component 'glue'. The selling point is that it is in java.

Other multi-paradigm languages either have their own compiler written in C or are using libraries implemented in C. Tea is java so one positive is that you get javadocs. The tea reference javadoc lists about 20 functions as the language core.

As a functional language Tea is intended to make the use of closures easy: functions are first-class objects as in JavaScript. In many respects the object system is like Smalltalk: members are private; methods are public. Code blocks in {} come with their contexts as closures. Every statement is at least a word which invokes a function. Lists are like Smalltalk collections: they can contain objects of mixed types. Unlike JavaScript, there is no literal notation for functions, but they can be loaded at will from jars or from raw source files using the source word.

Variables are not pre-typed, but they must first be declared with a define. The define word is over-loaded 3-fold: define a variable; declare a variable to have a value; define a variable to be a function as declared. The define word returns what it defines (it, too, is a function.) The set! function is used to re-assign a variable and anonymous functions can be had using the lambda function. Much like Smalltalk's collect: there is a map function to iteratively apply a function to a list. For lists of lists there is the function map-apply. Unassigned vars are returned with the value null. But note this sigil use:
define nativeParser $null

The syntax is very simple. Statements end at end-of-line. Comments start with octothorpe. You get variable values with a prefixed $ sigil. Other scripters will feel comfortable. The type tests use function? string? symbol? int? pair? which is extended to boolean tests as same? not-same? null? and not-null?. Lists use parentheses and, thankfully, no commas.

Lists are very much Scheme, as in
define testPair [cons "first" "last"]
where [car $testPair] gives "first and [cdr $testPair] give "last".
List are built from such pairs; the last pair in the list references a pair where both slots are null. With syntactic sugar our test list can be declared as
define testPair ( "first" "last" )

The Smalltalk procedural style is made possible by using the $ sigil.
For example, if you have a database connection in variable conn then
define sqlStmt [$conn statement]
returns a statement. The difference from Smalltalk can be seen when the query is created: there is no need for a colon, as in
define dataSet [$sqlStmt query "SELECT client_id FROM new_customers"]
but what is different is the use of [...] and not as a code-block { expression }. What is happening, of course, is a command substitution as in Tcl. The {} are used to defer evaluation as in a while loop.

The load function is rather like Jython: it gives access to java classes including Tea functions in those java jars.

But why would you use Tea? One possiblity is that you already know Scheme and Tcl or need a rapid way to work with closures in the JVM. But why not simply use JavaScript? One curiousity is that Tea is promoted as a language for rapid-prototyping, but in Lisbon it has been used for major banking and telco systems. But was it used only as glue code? Not at over a million lines according to Tea's own 'whitepaper'.

One observation: Tea is almost the opposite of Curl and Rebol. It is only now adding GUI and networking. But why add them if this is a scripting language for the JVM? It must be irresistable. Some people spoil their kids; some people spoil something else. And most of us seem to bloat if we are not kept on track ... and reminded that what we leave out can be as important as what we put in.

In Tea you get a hint of what the future holds if we shift away from 'C' and the OS to life with a VM.

Likely Tea will never have the momentum to break into North American markets unless it is embraced by a major player. It does have an advantage over Jython: there is no shifting Python beneath it. Then again, functional may becoming fashionable... even at Microsoft.

If you are a secret Schemer masquerading in Java or someone who can't thrive without a little Tcl, you may want to have some Tea... and lemon? Ah, right. They already added the syntactic sugar ...

PS There is another TEA which is the Tiny Encryption Algorithm and yet another Tea that is a strongly-typed templating language for managing servlets from the Disney TeaServlet project at what was once GO.COM Green tea. Black tea. Chá, anyone?

Friday, June 1, 2007

redirecting Rebol stdin/stdout under Windows

Rebol has a console interpreter which I wished to wrap in a smarter Win32 console shell that would screen my typical typo's, maintain a history across sessions and a few other useful features to exploit the Rebol parser.

My console wrappers at the moment are both Smalltalk console applications written in Dolphin Smalltalk: ConsoleShell and ConsolePipe. ConsoleShell understands commands for several language configurations and writes to a named pipe opened and echoed by ConsolePipe1; ConsolePipe2 takes STDOUT and pipes it to a chosen NamedPipe to feedback to an IDE running the ConsoleShell.

The problem that I faced was to pipe out from rebol.exe as it is not enough just to use the -w option to prevent a window from opening.

The answer lay in a Rebol script not unlike what you might use to loop a Perl interpreter. In my test case, the following pipeline works under Windows XP:
ConsoleShell | ConsolePipe1 | rebol.exe -w -c --do "forever [attempt [print do ask %~]]" 2>&1 | ConsolePipe2

The input is to my shell and the output appears in a destination window fed by a named pipe.
Unless you ran taskmgr you would not know that rebol.exe was running.

The two key bits are the -c flag and the print block. You also have to ignore the obvious and set the prompt ( in my case '->' ) with the '%' as indicated and you must wrap the script in dbl-quotes.

Now my ConsoleShell pipes into Rebol and Rebol outputs into my chosen Windows NamedPipe. This should work with any 2 wrappers - you might want to try with Tcl and expect. The Rebolution continues ...

Sunday, May 20, 2007

Tcl, fork, CommandShell and Squeak Smalltalk

Something rather Tcl-ish is available to Squeak Smalltalk based on the OSProcess classes: CommandShell. And of course it is only fully implemented on a Linux installation of Squeak.

But in Win32 where you cannot fork, you can likely get by using a socket on the child process, and there Squeak shines. And sockets are a definite alternative to messing with NamedPipes on Windows.

CommandShell detects whether it is being passed code to interpret or commands to execute, rather like a Tcl shell or any other scriptable shell. But scripting with Smalltalk is almost always a pleasure.

tbc at http://www.eclectic-pencil.com/