Squeak and Pharo saw a great config change in 2010.
The issue is how to incrementally construct a bytecode "image" for a Smalltak VM, but it is the Smalltalk equivalent of make and configure for a build.
Building up Smalltalk images has been a nasty secret in the the otherwise sunny world of design, test and develop in Smalltalk. The darkest secret - which managers learn about eventually, is then stripping that image back down for deployment. Add to that the possibility that all was not well in the relations between the Smalltalk event loop and the application design/test/develope cycle for GUI applications. Give Cincom VisualWorks a spin and you'll see that I can rest my case. Smalltalk evangelists, just count to ten. Relax. Take a few deep breaths.
Metacello is finally a way for code users to be able to use modular code without resorting to chicken giblets in order to choose among package versions.
But why did this require some 3 generations of Smalltalk developers? My view: that Smalltalk was not multi-paradigm (for no good reason) and so failed to embrace logic programming.
Logtalk for Prolog is interesting in this regard: it also required generations of developers to appear - it came with categories before Self traits were retrofitted to Smalltalk and it comes with messaging.
What I now must take seriously is the configuration management of Smalltalk-Self-Actor hybrid Io.
Note: packaging is finally coming to Rebol as Rebol3 (in alpha.) Modularity of Falcon was re-thought prior to version 1.0 (still in the works.)
Languages lacking sufficient contributors and library versions to put to the test: ICON, Unicon, ObjectIcon.
And no, bragging abut hot-fixes does not serve to avoid a hard-look at Erlang in this regard.
Arguably the reason that open-source Smalltalk got to configuration objects before VisualWorks is the strength of their user/developer community.
In fairness to legacy Smalltalk, I found PVCS for Visual Smaltalk Enterprise to be quite adequate.
My view: that source versioning and build configuration were confounded for years in Smalltalk. Separation of concerns.
Think of it this way: the developer wanting to try new language features and the manager trying to audit application feature testing of putative release X. Then throw in the ability of Smalltalk to genially load code at startup ... for years a matter of trust trumping governance, compliance and risk.
Is there a dissertation on how all this was managed at J.P Morgan?
Smalltalk essentials maxim: code gurus must not do builds; builders must rotate among junior developers under rotating senior mentors.
Smalltalk essentials maxim: never strip when you can assemble instead.
Smalltalk essentials maxim: builds are not self-documenting.
The only audit to trust is the outside audit. Facts: often performance-tuning would be out-sourced; audit was most often not even performed, let alone out-sourced. Fallacy: unit-testing removes need for audit. Fallacy: code escrow is suitable resource for software audit of runtime applications.
First step: remove developers from the deployment task.
Clean linen may dry on trees, but it don't grow on trees.
Wednesday, January 19, 2011
Friday, October 15, 2010
Mercury configure and make: Cygwin tips
I have recently been trying to imagine why a language as smart as Mercury which is itself used to generte the smart Mercury compiler is built using a configure script and then make and a Makefile.
One of the most non-declarative aspects of building Mercury is the lack of examples in configure.help as an aid to building, say, a minimal Mercury library with both a Java and Erlang backend but no profilers etc. There is a flag for --disable-most-grades and a flag for --enable-Java-grade but if one were to use both in that order?
So my first Mercury tool should be a translator for the Makefile and a wrapper for make to display what we will build given a run of the configure script.
Cygwin must know: that there is no INSTALL env var in your Windows env and that your Cygwin bash has run zsh at least once so as to create a .zshrc file. These two little points could save you hours in Win32 world.
Do first run
You may find a Win binary at winmercury over at code.google.com
With Cygwin 1.7 you will still need symbolic links to suitable java, javac and jar executables as well as a path to Erlang erl and erlc if you wish to compile to either.
The install depends on the executable install.exe in Cygwin /bin so if your Windows env holds an INSTALL var, edit and rename it. Do not rely on exporting it as an empty string in your Cygwin bat or in your .profile - but do create a java.sh in /profile.d as to use your preferred JAVA_HOME.
And good luck. But why would you need that - luck - when compiling C towards a self-compiling compiler for a logic programming language in 2010? Oh - and about 2 Gb filespace for cp and a few hours on a spare CPU core. Better rsults may be had on Windows 7 and with parallel make for multicore CPU.
Neat things in Mercury - the .m pages at Ralph Becket's site at cs.mu.oz.au
At this date (10/2010) the make clean fails to delete essential transient Makefile instances beneath ./boehm_gc making it essential (?) to do so if you are intending to re-run ./configure to prep a re-make. It is also essential (?) to delete the transient config.h file which a previous configure pass will have placed in the ./src subdirectory of the gc hierarchy:
.\mercury-compiler-10.04.2\boehm_gc\libatomic_ops\src
and down to the deepest Makefile left behind in
.\mercury-10.04.2\mercury-compiler-10.04.2\boehm_gc\libatomic_ops\src\atomic_ops\sysdeps
I understand per the maillist that this is already a fix committed for future release (or in a daily snapshot.)
One of the most non-declarative aspects of building Mercury is the lack of examples in configure.help as an aid to building, say, a minimal Mercury library with both a Java and Erlang backend but no profilers etc. There is a flag for --disable-most-grades and a flag for --enable-Java-grade but if one were to use both in that order?
So my first Mercury tool should be a translator for the Makefile and a wrapper for make to display what we will build given a run of the configure script.
Cygwin must know: that there is no INSTALL env var in your Windows env and that your Cygwin bash has run zsh at least once so as to create a .zshrc file. These two little points could save you hours in Win32 world.
Do first run
sh configure --helpas I have been advised that "everyone" knows to do this first.
You may find a Win binary at winmercury over at code.google.com
With Cygwin 1.7 you will still need symbolic links to suitable java, javac and jar executables as well as a path to Erlang erl and erlc if you wish to compile to either.
The install depends on the executable install.exe in Cygwin /bin so if your Windows env holds an INSTALL var, edit and rename it. Do not rely on exporting it as an empty string in your Cygwin bat or in your .profile - but do create a java.sh in /profile.d as to use your preferred JAVA_HOME.
And good luck. But why would you need that - luck - when compiling C towards a self-compiling compiler for a logic programming language in 2010? Oh - and about 2 Gb filespace for cp and a few hours on a spare CPU core. Better rsults may be had on Windows 7 and with parallel make for multicore CPU.
Neat things in Mercury - the .m pages at Ralph Becket's site at cs.mu.oz.au
At this date (10/2010) the make clean fails to delete essential transient Makefile instances beneath ./boehm_gc making it essential (?) to do so if you are intending to re-run ./configure to prep a re-make. It is also essential (?) to delete the transient config.h file which a previous configure pass will have placed in the ./src subdirectory of the gc hierarchy:
.\mercury-compiler-10.04.2\boehm_gc\libatomic_ops\src
and down to the deepest Makefile left behind in
.\mercury-10.04.2\mercury-compiler-10.04.2\boehm_gc\libatomic_ops\src\atomic_ops\sysdeps
I understand per the maillist that this is already a fix committed for future release (or in a daily snapshot.)
Tuesday, September 29, 2009
Perl Devel::REPL take-2
It occurred to me that there was an alternative to the big make: just fake the install by taking whatever had made from ./cpan/build and placing the contents of each of those ./lib in their respective places in ./perl/lib
Then just run legitimate calls to Devel::REPL in a Perl script and address the make of the missing pieces one at a time.
It seems to work. The cpan shell is able to install MOP, for example. Many of the missing pieces blocked by the circular dependencies and recursing make loops are just odds-and-ends.
I came back to Devel::REPL because each alternative that I looked at could not cope with the simple fact that Perl print returns 1 (in some scripting languages, such as REBOL, print returns no value - it just has a side-effect - it prints!) And they each had other quirks (PerlConsole has the virtue of no docs, so you read the code until ah-hah (tip: you must use my for variable assignments to pass through).)
Then just run legitimate calls to Devel::REPL in a Perl script and address the make of the missing pieces one at a time.
It seems to work. The cpan shell is able to install MOP, for example. Many of the missing pieces blocked by the circular dependencies and recursing make loops are just odds-and-ends.
I came back to Devel::REPL because each alternative that I looked at could not cope with the simple fact that Perl print returns 1 (in some scripting languages, such as REBOL, print returns no value - it just has a side-effect - it prints!) And they each had other quirks (PerlConsole has the virtue of no docs, so you read the code until ah-hah (tip: you must use my for variable assignments to pass through).)
use PerlConsole::Console;
my $cons = PerlConsole::Console->new;
while(true) {
$cons->interpret($cons->getInput);
}
# exit with :quit
CPAN, Perl and the elusive Devel::REPL
Over at make-config.net I am hoping to get a new version of ClassPath Canuck available soon.
In the meantime I have had to go back to Perl for some aule-browser tasks and I thought I would try to use something lighter-weight than an IDE or Emacs since my Perl is a little rusty.
I chose to build Devel::REPL from CPAN because of the 4 articles that accompany its design.
And then a fateful decision: I decided to build it in Cygwin. Over an hour later I hit a circular dependency in CPAN.
So then I went to a Win XP cmd prompt. Now CPAN refused to run because it could not be satisfied with my Mingw gcc. After a trip to refresh Win32 Perl at ActiveState.com I gave up on launching the CPAN shell from with perl and opted for the cpan.bat file. That little gem decided to install a Mingw and a dmake. Oh vey. The ENV var CC and GCC are pointing into a mingw bin and it is up front on the path. But ActiveState offers to install a gcc and a dmake, so I let it have a whirl. What the heck. These are the Perl experts.
My first test when the cpan shell exited was to launch it again with cpan.bat and request
make Moose
This finally failed on missing prereq's - dependencied which the Cygwin cpan make had pulled in just fine. Go figger. You can only enter 'y' for 'yes' so many times ...
Next attempt:
make Devel::REPL
That when into a loop on a circular dependency for cpan\build\ExtUtils-Depends-0.302-eJL_dD
Time to rant.
Once we had ICON, the Perl language could have gone away. We have REBOL parse, but Perl does not go away. We have Parser Expression Grammars for Ruby and Python. For Tk we have elegant Python Tkinter. And we still have Tcl's gift, Expect. But still, Perl does not go away.
A basic REPL in Perl can be a one-liner and that can be wrapped in rlwrap to provide a command line history so this Devel::REPL is not needed.
I might try this later on a Linux box or try perlconsole or another shell - or just use Perl Express. I could even use emacs even here on Windows.
But how byzantine has a language become when to build a well-publicized REPL is such a task? Perl, after all - perl - that is - is just an interpreter. It is not an environment. It requires no VM.
If this is what the "souk" or the "public market" achieves then perhaps we should remember that we are not always trying to to build a "cathedral". Sometimes it's just a boathouse. Ok, Witold, it can drift into being a vision of a beautiful home. But what I needed today was to erect a shed and I thought I would first build some saw-horses. There were no plans for scaffolding at all. None needed. The man needed a wheel-barrow. What's with the camel?
In the meantime I have had to go back to Perl for some aule-browser tasks and I thought I would try to use something lighter-weight than an IDE or Emacs since my Perl is a little rusty.
I chose to build Devel::REPL from CPAN because of the 4 articles that accompany its design.
And then a fateful decision: I decided to build it in Cygwin. Over an hour later I hit a circular dependency in CPAN.
So then I went to a Win XP cmd prompt. Now CPAN refused to run because it could not be satisfied with my Mingw gcc. After a trip to refresh Win32 Perl at ActiveState.com I gave up on launching the CPAN shell from with perl and opted for the cpan.bat file. That little gem decided to install a Mingw and a dmake. Oh vey. The ENV var CC and GCC are pointing into a mingw bin and it is up front on the path. But ActiveState offers to install a gcc and a dmake, so I let it have a whirl. What the heck. These are the Perl experts.
My first test when the cpan shell exited was to launch it again with cpan.bat and request
make Moose
This finally failed on missing prereq's - dependencied which the Cygwin cpan make had pulled in just fine. Go figger. You can only enter 'y' for 'yes' so many times ...
Next attempt:
make Devel::REPL
That when into a loop on a circular dependency for cpan\build\ExtUtils-Depends-0.302-eJL_dD
Time to rant.
Once we had ICON, the Perl language could have gone away. We have REBOL parse, but Perl does not go away. We have Parser Expression Grammars for Ruby and Python. For Tk we have elegant Python Tkinter. And we still have Tcl's gift, Expect. But still, Perl does not go away.
A basic REPL in Perl can be a one-liner and that can be wrapped in rlwrap to provide a command line history so this Devel::REPL is not needed.
I might try this later on a Linux box or try perlconsole or another shell - or just use Perl Express. I could even use emacs even here on Windows.
But how byzantine has a language become when to build a well-publicized REPL is such a task? Perl, after all - perl - that is - is just an interpreter. It is not an environment. It requires no VM.
If this is what the "souk" or the "public market" achieves then perhaps we should remember that we are not always trying to to build a "cathedral". Sometimes it's just a boathouse. Ok, Witold, it can drift into being a vision of a beautiful home. But what I needed today was to erect a shed and I thought I would first build some saw-horses. There were no plans for scaffolding at all. None needed. The man needed a wheel-barrow. What's with the camel?
Subscribe to:
Comments (Atom)