Curl and Perl regexp

One of the nice thinga about Curl, the web content langauge, is that when you use {regexp-match ... you will be using the regexp flags that you know from Perl.

I will put a page on Curl regexp over at eclectic-pencil under the Curl/Surge RTE pages and {import * from CURL.LANGUAGE.REGEXP }

My document links for Curl are also kept there.

Scala and the interpreter

I have been looking at Prolog-like facilities implemented in languages which could benefit from something like the partially determined clauses found in Mercury for which there is no backtracking: a matching clause is found among a set of clauses or we fail.
There are interesting implementations of prolog available as add-ons to many languages including Scala.

I began my foray into Scala with a PDF by Martin Odersky which presented the following code:

def sort(xs: Array[int]): Array[int] =
if (xs.length <= 1) xs else { val pivot = xs(xs.length / 2) Array.concat( sort(xs filter (pivot >)),
xs filter (pivot ==),
sort(xs filter (pivot <))) }

This implementation of a quicksort chokes Scala when it is fed line-by-line to the interpreter by my own shell tool.
Here is one variant that keeps the interpreter waiting for more:

def sort(xs: Array[int]):
Array[int] = if (xs.length <= 1) xs else { val pivot = xs(xs.length / 2) Array.concat( sort(xs filter (pivot >)),
xs filter (pivot ==),
sort(xs filter (pivot <))) }

It is the sort of thing that those who script Perl are used to but might seem odd to someone from the functional-side whose interpreters would be waiting for the closing embrace.

If you would like to contribute to a portal on declarative+imperative, there is a new SmalltalkProlog portal that I have opened at aboutus.org

Win32 NamedPipes and "All pipe instances are busy"

When I began using named piped with the excellent Win32 implementation of Smalltalk from http://www.object-arts.com/ called Dolphin Smalltalk. I was convinced that Windows XP named pipes had been abandoned for sockets.
I would open a pipe, receive

All pipe instances are busy

so I would try with Perl. No problem. Then the real evil: open a named pipe with Perl and Perl could write and read. Open a named pipe with Perl and then try to write or read with Tcl and

resource temporarily unavailable

yet again.

What was infuriating was that even with the disconnect issues noted in my last blog, Perl would reconnect clients to my pipe in a single shot. Tcl could not even read that pipe.

Had I been using the screen utility under Cygwin, the answer might have come earlier. It required 4 CMD sessions to be open on my left monitor. The top 2 opened the same pipe with Perl. Perl began writing to an instance of the pipe in screen 3 and screen 1 dutifully echo'd the output. Now amazement: in screen 4 I simply redirected my bothersome buffered interpreter to dump pages of docs to that same pipe and PRESTO screen 2 was dumping that output from an instance of the named pipe.

Now more evil. I close everything. Open one instance of that same named pipe. Now anyone can read and write to the pipe. Including Tcl.

No, I do not have any anti-virus software running: I suspect that this is a gift from Microsoft security upgrades.
Now when I want a pipe for the console of my choosing, I create it, close it, create it again. No problem. The 'one instance' accepts the first client.
There is a commercial ACL utility which could no doubt pin down the access issue.
Now just wait until I upgrade to Vista ...

Now to get a utility pkg written for Dolphin Smalltalk to allow read and write streams to interact correctly with a Win32 named pipe as if it were a file.

Perl Win32 NamedPipes

Inaccurate documentation of an API is always vexing - more so if it propagates across the web.
Take the win32::Pipe module for Perl, available from at least 3 sources: ActiveState, CPAN and its author.
I can vouch that the module does permit creating a Win32 named pipe at a server end and writing to the pipe from the client end. Then the time comes to disconnect.
The docs claim that $Pipe001->Disconnect() will return 1 or 0 depending on if it succeeds or fails.
But a tell-tale sign: in the docs 'working' example, no value is assigned and tested upon Disconnect(). Nor is this done in the 'test' app available from the module's author. And in the docs, the result of a data read (!) is used to close the pipe, i.e.,

$Data = $Pipe->Read();
$Data->Close()

which is a long-standing error in the 'working' example.

This is what a current ActiveState Perl in fact reports as the result of $Pipe->Disconnect() with a pipe created, connected, written and read using the Win32::Pipe module

Disconnection result: usage: Disconnect($PipeHandle [, $iPurge]);

Having tried several variants with no success, this remains: you close the pipe ( it will report 0 for that op ) and then you recreate the pipe de novo and wait for another client with Pipe->Connect()
The worry might be what security holes may be opened by the use of this faulty module.
Caveat emptor, err, there is no such thing as free money - except in spam.
Oh, the docs are ambiguous on the key op: destroy. Is it only the 'instance' of the pipe that Disconnect() was to destroy and the pipe 'itself' which Close() was to destroy? And just what is the issue when the client drops off either with or without closing? ( the docs warn that if the client drops before the server, then the server will have a long wait. I found this issue trivial to address with a friendly client of my own devising ... unfriendlies are, well, unfriendly.)
The fact that ActiveState reproduces the author's docs with no clear caveat of their own is somewhat vexing.