Monday, September 28, 2009

Nemerle in Visual Studio 2008 Shell

A couple of years ago I was quite impressed with the ease of adding Haskell to one of the Visual Studio IDE's.  Then I learned that the free 2008 Shell could be used for F#.  Today I have learned that Nemerle will pop itself into that shell by just running its MSI.

Only two things went wrong: the Shell defaults to creating projects up in "Documents and Settings" but kept failing when initiating a Windows desktop project.  So I stopped using the default and created a VS_Projects directory over on a dev drive under a Nemerle folder.  That popped up a simpler error where that folder was a bad path, in my case

    'r:\Nemerle\'\VS_Projects

So I hopped into ENV vars and sure enough there it was: the value for Nemerle was set to a quoted

  'r:\Nemerle\'

I stripped-off the quotes and the backslash and away things ran hummingly.

This quirk may only be for an install of Nemerle on XP.

Regardless, I am looking forward to some experiments with .Net libraries and a break from Eclipse.

Monday, September 21, 2009

Python + Tkinter and Python + Gtk

Remembering that Python was intended as a scripting language, compare these two HelloWorld from Python.

First, Tkinter for Tk as in Tcl/Tk

from Tkinter import *
root = Tk()

class HelloWorld:

def __init__(self):
  widget = Button(root, text = 'Hello World', command = self.quit)
  widget.pack()

def quit(self):
  print "Hello World"
  import sys
  sys.exit()

HelloWorld()
root.mainloop()

Now to compare the same minimal HelloWorld with Gtk.  First, install Gtk+  ( and on Windows XP  that means get all of the dependencies - the DLL's - on the path.)

import pygtk
pygtk.require('2.0')
import gtk

class HelloWorld:
def hello(self, widget, data=None):
print "Hello World"

def delete_event(self, widget, event, data=None):
print "delete event occurred"
return False

def destroy(self, widget, data=None):
   gtk.main_quit()

def __init__(self):
   self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
   self.window.connect("delete_event", self.delete_event)
   self.window.connect("destroy", self.destroy)
   self.window.set_border_width(10)
   self.button = gtk.Button("Hello World")
   self.button.connect("clicked", self.hello, None)
   self.button.connect_object("clicked", gtk.Widget.destroy, self.window)
   self.window.add(self.button)
   self.button.show()
   self.window.show()

def main(self):
   gtk.main()

if __name__ == "__main__":
    hello = HelloWorld()
    hello.main()

Whatever the merits of Gtk+ as a cross-platform C GUI framework for general purpose languages, something looks to have gone wrong with the Python library PyGtk.

Even with Tk itself, something comparable occurs when using Tk from Haskell versus using Tk from OCaml.  Probably  expect was the Tcl "killer app" but Tk is what most developers know of Tcl today.  Tk was also an early mainstay of Ruby.  Here is the HelloWorld demo using Gtk+ from the Ruby-Gnome team:

# Copyright (c) 2002,2003 Ruby-GNOME2 Project Team
require 'gtk2'

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") {
    puts "Hello World"
}

window = Gtk::Window.new
window.signal_connect("delete_event") {
    puts "delete event occurred"
#true
   false
}

window.signal_connect("destroy") {
   puts "destroy event occurred"
   Gtk.main_quit
}

window.border_width = 10
window.add(button)
window.show_all

Gtk.main

Now this is a little better, but compared to Ruby + Tk we are at almost double the lines of code.

To see a really elegant use of Tk, see the QTk framework for Oz, the language.  I'm fiddling with a QCurl variant for Oz just now.  I added some notes on OCaml and labltk over at wikia.com

Monday, September 14, 2009

From Oz QTk to QHTML to QCurl

The QTk framework for the Oz programming language provides a mixed declarative and procedural approach to generating a GUI using Tk. Since the appearance of QTk, the QHTML framework appeared first as a research report and then in the SCM for Oz.

In going through the QHTML Oz code it became apparent almost immediately that transitioning QHTML to QCurl would be even less problematic than my current efforts with Smalltalk Seaside for Curl.

A QCurl framework should address one or two challenges that faced QHTML and move closer to a framework involving the fewest number of disjoint languages: in this case, only Oz and Curl. With Oz on the server-side and Curl on the client-side we have a mixed declarative-functional-procedural language on each end, plus the advantage of Curl macros. With the Curl JIT compiler producing native code and consuming declarative Curl as a data format, Oz can expect excellent performance with an alternative to HTML+JavaScript+CSS while also not being restricted to the web browser as the GUI container.

Thursday, September 10, 2009

Converge programming language 1.1 "alpha" binaries available

Laurie Tratt's Converge, an ICON for pythonistas has gone to 1.1 over at convergepl.org

This comes just as Robert Parlett's ObjectIcon has popped up to 1.4 at code.google.com

I am still waiting for news to clarify the status of ICON 9.5 ... which Carl Sturtivant of UMN, for one, has been working on over the past year or more.

I have started a sketch for a Converge docs site-specific browser at converge.aule-browser.com

At the moment it's only note-taking link is to cl1p.net/convergepl

A converge DSL on the server-side would be excellent for scripting a dynamic GUI in Curl code.

Wednesday, September 9, 2009

Tcl browser plugin v3 (from ActiveState)

There are some discrepancies in info about embedding Tcl/Tk since the change to plugin v3.

I tested against up-to-date Chrome, Opera, Safari, IE8, FireFox 3.5 and Amaya

My result is that given some script XYZ.tcl ONLY the following worked across all:

<OBJECT
ID="PluginHostCtrl"
CLASSID="CLSID:14E78123-A693-4F27-B6EE-DDDE18F93D3A"
WIDTH="400"
HEIGHT="220"
>
<PARAM name="type" value="application/x-tcl"/>
<PARAM name="pluginspage" value="http://www.tcl.tk/software/plugin/"/>
<PARAM name="src" value="XYZ.tcl"/>
</OBJECT>

Getting the plugin recognized by each browser was slightly problematic: IE 8 appeared to just ignore the XPI.

Generating Curl 7.0 web content from Seaside 3.0 on Pharo 1.0 beta

Yesterday I used a 3.0 install on the Pharo 1.0 beta to generate non-HTML (in my case that is Curl markup )

I would not say that is any easier that before 2009 Camp Smalltalk ( I started from scratch - it still took me hours to track down everything )

Anyone trying this must remember both gotchas:

WASystemConfiguration clearAllDescriptions.

WARenderer resetDefault.

But since WARenderer is an HTML subclass which always resets the default renderer class to itself, that >>default method had to change.

The main nuisance is that methods >>textHtml or >>textPlain are in many critical places instead of a default rendering type ... and of course many key methods for error and redirect still output raw HTML.

Now to see what headaches appear as Pharo and Seaside evolve - given the wide-spread changes still required to accommodate a default rendering MIME type other than plain text or html.

Curl and GemStone are such a natural match that the game still looks to be worth the candles.

Friday, September 4, 2009

Ruby 1.9.1 on Windows after 1.8.6

I came back to Ruby on Windows the other day after working on a linux box and did not want not be in Cygwin. So I hopped out to ruby-lang.org and pulled in the Windows 1.9.1 binaries. Then I flipped my ruby env variable to point to the new directory so that my path - which uses %ruby%\bin - would update. Then I called gem to install Treetop for PEG and ... Segmentation fault. Oh joy.

I saw that 1.8.6 has a one-click installer for Windows, so I used that, flipped the ruby var and presto all was well.

So why not with the 1.9.1 zip install? Well, ruby for windows XP is not really Ruby for windows so much as it is Ruby for Gnu on Windows. What was missing in the path were Win32 versions of linux DLL's - specifically:
gdbm.dll
libeay32.dll
pdcurses.dll
readline.dll
zlib.dll

The quickest fix was to copy them from the 1.8.6 \bin into the 1.9.1 \bin

So if you start ruby or irb or gem on Windows and hit a Segmentation fault error, this may be the only issue.

You may avoid this issue if you build ruby from source .. but the point of running Ruby on a Windows box outside of Cygwin or Msys is usually to either try something out or get something done - not to do development work. And after all, Ruby is supposed to be at least one notch above its file-based and cmd-line cousin, Gnu Smalltalk, right? Or why else is Ruby seeing so much use on the server-side? Of course if Ruby were to displace that other Smalltalk-descendant, Objective-C, on the iPhone we would be running RIGS for GnuStep anyway ...

Btw, there is Cocotron for that other pseudo-Smalltalk on Windows ...

PS
The DLL's can also be found here.