?

Log in

Kreely's Journal [entries|archive|friends|userinfo]
kreelman

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

CMD scripts are crippled ? [Sep. 26th, 2007|12:11 pm]
kreelman
[Tags|]
[Current Location |Work]
[music |ABC podcast]

I've been doing a fair bit of automation here of our build process.

The company I work for builds applications that run on the Windows platform.

To automate the build process, I put lots of the previously manual build tasks into a cmd script.

Most of the time this is fine. However if you need to something like :-
    set BUILD_RESULT=build.bat

You can't !

It just seems to be impossible in Windows CMD scripts to assign anything other than a constant to a variable.

Am I missing something here?

This is absolutely simple to do in bash :-
BUILD_RESULT=`build.sh`

This is quite crippled if you ask me. You'd think Windows scripting could at least do what shell scripting could do since about the 1970s.

.. Of course if someone is happy to correct me, that would be great !!
linkpost comment

Stack Trace: What a cool argument! [Sep. 25th, 2007|03:12 pm]
kreelman
Found a very cool podcast.

http://thestacktrace.libsyn.com/

One of the guys is really pro-Java and the other guy is pro dynamic languages and seems to have a nice lisp understanding and bent.

Of course I find myself siding with the lisp guy, but it's a great argument every time. The lisp guy seems to have a fair breadth and depth of experience and I often find myself thinking 'Preach brother!!' (so to speak).

The one I'm listening to now is about XML. Of course the Java guy loves XML, but the lisp guy thinks 'Meh, well I can parse it into lisp easily'. I love it.
linkpost comment

A nice day on comp.lang.lisp [Sep. 3rd, 2007|03:51 pm]
kreelman
Ah! So nice to see. Sensible conversation on comp.lang.lisp.
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e6c6a2926f08baa7?hl=en
linkpost comment

Surprised by relative ease of recursion [Jul. 30th, 2007|10:46 am]
kreelman
Was sitting on the train the other day writing the same little game that I always write when learning a new language, howitzer.
This game is a simple ballistics game where you shoot a cannon with a given amount of gunpowder and a given angle to hit a target on a landscape made of connected lines (really simple).

I've used this toy project to get better at lisp and better at CLX, hopefully more on that later. CLX has been a lot of fun.

I had to write a routine to work out whether the shell had hit the ground or not and it was suprisingly easy and natural for me to use recursion. This was interesting, since I thought that perhaps I would not get used to using recursion in lisp. I'll post the code later.
linkpost comment

System upgrade (or hardware upgrades without cost) [Jan. 16th, 2007|02:25 pm]
kreelman
I have a server at home that provides me with file storage space and I have plans to also setup MythTv on it at some stage.

The other day, after fiddling around with a UPS, I managed to burn out the power supply on this venerable box (Celeron ~400 MHz).

Luckily, in my area last weekend we had a council cleanup. This gives you the opportunity to throw out 3 square metres of rubbish from your house/backyard without having to pay for taking it to the tip.

Laura and I love this event as it's an opportunity to go 'trawling' and pick up useful things that people don't want.

So, my home server gets a nice upgrade to a P3 with 500 Mb (!!) RAM and a couple of 15-20 Gb hard drives. There was also a scanner with a feeder (don't know if it works yet) and a PC that had a PCI video capture card in it. Now to install Debian and Samba.
link15 comments|post comment

Learning [Jan. 16th, 2007|02:15 pm]
kreelman
Was fiddling around with some LISP the other morning which involved parsing text.

Once I sorted it out, it wasn't much more difficult than doing it in Delphi/Perl (though there were more ways of doing it I think), but it was the relative unfamiliarity of the language compared to the 10+ years of Delphi that I have that makes it interesting.

What was interesting was noticing how quickly I thought about how I'd do it in Delphi.

I think I'll get this happening to me for a few years yet. I don't think this is a bad thing since at least knowing how to do something in another language at least gives you a feel for how to solve the problem.

In theory I could also adapt LISP to feel more like Delphi if I needed to as well.

Will be interesting to see how quickly I can gain some level of LISP mastery . I feel like I'm at least getting better.
linkpost comment

A strange fractal in LISP [Dec. 20th, 2006|09:37 am]
kreelman
[Tags|]
[mood |accomplished]

As an exercise in confidence building and to firm up what I'd read of Paul Graham's ANSI Common LISP, I decided to translate the first piece of X11 code that I ever wrote way back in 1991.

I should note that the C version started out just doing some simple graphics and some time last year, for fun I got it to spit out pbm files on standard output. That way it could be much more useful. I was toying with the idea of using the image as a kind of watermark on documents, since the image varies a fair bit when the cx and cy parameters are changed.

There are a few support files missing from the C version presented here. These are mostly to do with X11/XLib stuff that the simple LISP version doesn't do (I may just leave it this way, but it would be fun to learn CLX or mcCLIM and get the fractal up on the screen.

So, what did this exercise show me?

It's quite possible to write some interesting code on the train on the way to work!
The LISP code is a little bit shorter than the C code.
It was more fun to write the LISP code as I could test it out in the interpreter before compiling it. For me testing involved more checking my understanding of do loops and writing small loops over 10x10 arrays to check that I was getting the right kind of pbm output.
The LISP code is a little shorter than the C code, but to be fair, a second look at the C code shows several places where the code could have been shortened, several of the local variables in drawfractal could have been pulled inside the loop block.
You can translate C code into LISP code relatively easily.
let is pretty cool.
developing iteratively is good fun and lets you connect with the problem well. Having to change mode and jump out and compile isn't as much fun as having it all there running.
This is a pretty straightforward piece of (toy) code. Nothing terribly complicated is going on here.

Some interesting things that could be done
compile the code into an exe and do some speed tests.
incorporate colour into the image (perhaps write out a ppm)
pull more of the variables into a let inside the for loop (should be possible?)
incorporate a testing framework. I use testing frameworks all day long in Delphi and they make life much easier. Having one in LISP would make the iterative approach even more fun I think.
It would be fun to jigger around with passing in a calculation function, since this is something that CL is very good at.

Other less interesting things
Perhaps incorporate Skippy to write out a gif image?
try a few other LISP environments (everything here was done in ECL (ecls.sf.net)). Perhaps run it in SBCL, CLISP (should work, pretty standard code)


#include
[Error: Irreparable invalid markup ('<math.h>') in entry. Owner must fix manually. Raw contents below.]

As an exercise in confidence building and to firm up what I'd read of Paul Graham's ANSI Common LISP, I decided to translate the first piece of X11 code that I ever wrote way back in 1991.

I should note that the C version started out just doing some simple graphics and some time last year, for fun I got it to spit out pbm files on standard output. That way it could be much more useful. I was toying with the idea of using the image as a kind of watermark on documents, since the image varies a fair bit when the cx and cy parameters are changed.

There are a few support files missing from the C version presented here. These are mostly to do with X11/XLib stuff that the simple LISP version doesn't do (I may just leave it this way, but it would be fun to learn CLX or mcCLIM and get the fractal up on the screen.

So, what did this exercise show me?

It's quite possible to write some interesting code on the train on the way to work!
The LISP code is a little bit shorter than the C code.
It was more fun to write the LISP code as I could test it out in the interpreter before compiling it. For me testing involved more checking my understanding of do loops and writing small loops over 10x10 arrays to check that I was getting the right kind of pbm output.
The LISP code is a little shorter than the C code, but to be fair, a second look at the C code shows several places where the code could have been shortened, several of the local variables in drawfractal could have been pulled inside the loop block.
You can translate C code into LISP code relatively easily.
let is pretty cool.
developing iteratively is good fun and lets you connect with the problem well. Having to change mode and jump out and compile isn't as much fun as having it all there running.
This is a pretty straightforward piece of (toy) code. Nothing terribly complicated is going on here.

Some interesting things that could be done
compile the code into an exe and do some speed tests.
incorporate colour into the image (perhaps write out a ppm)
pull more of the variables into a let inside the for loop (should be possible?)
incorporate a testing framework. I use testing frameworks all day long in Delphi and they make life much easier. Having one in LISP would make the iterative approach even more fun I think.
It would be fun to jigger around with passing in a calculation function, since this is something that CL is very good at.

Other less interesting things
Perhaps incorporate Skippy to write out a gif image?
try a few other LISP environments (everything here was done in ECL (ecls.sf.net)). Perhaps run it in SBCL, CLISP (should work, pretty standard code)

<code>
#include <math.h>
#include <stdio.h>

extern int use_xwin;

void Draw_to_Xwin(int x, int y);

drawpoint(long x, long y)
{
if (use_xwin)
Draw_to_Xwin(x, y);
else
DrawToPBM(x, y);
// printf("%d, %d\n", x, y);
}

int drawfractal(int width, int height, double cx, double cy, int npoints)
{
int i, x_rat, y_rat;
double pi;
double r,x,y;
double wx, wy, theta;
long v0, v1;
long z;

pi = M_PI;
wx = 0;
wy = 0;
x = 0;
y = 0;
theta = 0;
x_rat = 300;
y_rat = 300;

/* prefsize (x+rat*4, y_rat*4); */

for(i=1; i &lt; npoints; i++) {
wx = x - cx;
wy = y - cy;
if (wx &gt; 0)
theta - atan(wy/wx);
if (wx &lt; 0)
theta = pi + atan(wy/wx);
if (wx == 0)
theta - pi/2;

theta = theta / 2;

r = sqrt(fabs((wx * wx * wx) + (wy * wy * wy)));

z = random();

if (z &lt; 1073741824)
r = sqrt(r);
else
r = -sqrt(r);

x = r* cos(theta);
y = r* sin(theta);

v0 = 0.5 * (x * x_rat + width);
v1 = 0.5 * (y * y_rat + height);

drawpoint(v0, v1); /* was v2i */
}
/* ring bell to indicate completion. */
// putchar('\007');
fflush(stdout);
}
</stdio.h></math.h></code>

...and here is the LISP version.

<code>
(defun write-pbm (array pathname)
"Loop over array and write out a pbm file to pathname"
(with-open-file (p pathname :direction :output)
(format p "P1~%")
(format p "~A ~A~%" (array-dimension array 0) (array-dimension array 1))
(do ((x 0 (+ x 1)))
((&gt;= x (array-dimension array 0)) 'done)
(progn (format p "~%")
(do ((y 0 (+ y 1)))
((&gt;= y (array-dimension array 1)) 'done)
(if (aref array x y) (format p "1") (format p "0")))))))

(defun frac (size centre points)
"Create a fractal of bounded by size, at centre and iterate points times."
(let ((xrat 300 ) (yrat 300) (wx 0) (wy 0) (theta 0) (x 0) (y 0) (r 0)
(output (make-array size)) (cx (car centre)) (cy (cadr centre)))

(dotimes (i points nil)
(setf wx (- x cx))
(setf wy (- y cy))
(if (&gt; wx 0) (setf theta (- theta (atan (/ wy wx)))))
(if (&lt; wx 0) (setf theta (+ pi (atan (/ wy wx)))))
(if (= 0 wx) (setf theta (- theta (/ pi 2))))
(setf theta (/ theta 2))

(setf r (sqrt (abs (+ (* wx wx wx) (* wy wy wy)))))
(setf z (random 10))
(if (&lt; z 5) (setf r (sqrt r)) (setf r (* -1 (sqrt r))))

(setf x (* r (cos theta)))
(setf y (* r (sin theta)))
(setf v0 (* 0.5 (+ (car size) (* xrat x))))
(setf v1 (* 0.5 (+ (cadr size) (* yrat y))))

(if (and (&lt; v0 (car size)) (&lt; v1 (cadr size)) (&gt; v0 0) (&gt; v1 0))
(setf (aref output (truncate v0) (truncate v1)) 1))
)(array-dimension output 0)
output))

;; Some simple calls to check everything's working.

(setf fractal (frac '(500 500) '(0.318 0.28) 10000))

(setf test (make-array '(100 100)))

(write-pbm fractal "fract.pbm")

</code>
link5 comments|post comment

Thoughts on typed values vs typed variables and metaprogramming [Nov. 13th, 2006|02:00 pm]
kreelman
Have just started a new role (using Delphi) and it involves using a lot of interfaces and some COM/ActiveX/OLE for server communication.

COM is used heavily by Delphi for three tier communication. A client can optionally use COM to talk to a 'business' tier and each instance of a business tier connection is a COM instance.

It's interesting to have been using Common LISP for a while and seeing how COM uses variants. It's use similar in some ways to LISP values/variables. Here are the comparisons I've noticed :-

Values similarities....
COM                                                           Common LISP
All arrays variable size                               Everything is sizeable
Variables type is queried                            All values have types
Variable type is dynamic                            Value types dynamic, but can be fixed optionally for optimisation
Automatic cleanup when out of scope       Everything garbage collected

It makes sense in some ways that MS chose to go this way. It's trying to make life much easier for consumers of ActiveX/COM code. A codeer doesn't need to worry about memory management and type munging, like you normally need to in C/C++. However, it is a little hard to work out what COM was meant to do, it kind of got feature-itis.

Metaprogramming
It's also interesting to see how much code needs to get written that is just boilerplate connection/creation code. Much of this kind of code could be generated relatively easily with a macro system. In fact in a strange recognition of this, many object/Delphi/C++ dev houses create their own code generators that do this very task for them (Delphi has COM proxy code generator built in).

These kinds of issues show up again with webservices since they have inherently dynamic interfaces. Metaprogramming potentially makes this kind of task much easier for the developer.
linkpost comment

On blogging from the SMH [Dec. 8th, 2005|10:25 am]
kreelman
The following article http://blogs.smh.com.au/entertainment/archives//002970.html (with many comments talks about the new risks associated with blogging now that new sedition laws have been passed in Australia.

I suppose this was bound to happen. I don't think it will hurt blogspace that much. The only question is what happens if someone says bad things about a company ? Would this count as sedition (IANAL) ? I don't know much law.
linkpost comment

XAML and XWindows [Nov. 23rd, 2005|05:11 pm]
kreelman
My previouse boss at the company I last worked for rang me thisafternoon to ask about a role I'm applying for that he is being referee for.

We got talking about .Net and how it worked and I tried to explain the XAML thing to him. I explained it as "Java without the virtual machine" since in the next version of Windows, .NET will come with the system, so you don't need to download a VM. I explained that XAML was a rendering of the screen in XML that allowed an app to be run from anywhere without having to have a 'thick' client.

He then asked "Have you ever heard of XWindows ? It's been doing this since the eighties" (true, it doesn't do it in XML, but the infrastructure is all there). It's interesting to think how all of this comes about. We have become so used to thinking about how software works on Windows that when a new way is shown up by MS that cuts down on the local clutter on a machine, we say "Wow....!!!". In reality XWindows has been doing this kind of thing for decades by having the ability to run a program on a remote machine, but display it locally.

Users of MS Windows think it's kinda cool because it seems so revolutionary, but in reality, it's not all that new.

For those that say "Ah yes, but XAML does more than that", well yes it does, but the important part of remoting an application has been doable for generations in XWindows.

If you really want to use XAML on open systems, there is a project on the go to translate XAML into more general formats for use on non-MS systems. Have a look at http://www.mono-project.com/Summer2005#XAML_compiler.

...But this is just a bunch of students hired by Google !!

From the same pool that MS hires from.
linkpost comment

navigation
[ viewing | 10 entries back ]
[ go | earlier/later ]