Emacs: Free pascal interaction

Hum... I googled, but have not found. Evidently, nobody was concerned with the problem of interaction emacs and fpc.

Well, I've readjusted what I can - highlight uses, support of compile errors messaging and the default compile-command.

;;Pascal mode
(require 'compile)
(pushnew '("^\\([a-zA-Z0-9\\.]+\\)(\\([0-9]+\\),\\([0-9]+\\))\s\\(.*$\\)" 1 2 3)
         compilation-error-regexp-alist)
(defun pascal-mode-additional-init ()
  (local-set-key "\C-c\C-c" 'compile)
  (unless (or (file-exists-p "makefile")
              (file-exists-p "Makefile"))
    (set (make-local-variable 'compile-command)
         (concat "fpc -g " buffer-file-name)))
  (font-lock-add-keywords 'pascal-mode
  '(("^[ \t]*\\(uses\\)\\>[ \t]*\\([a-z]\\)" 1 font-lock-keyword-face prepend))))

What should else I do so good?

Odd thoughts about testing

Approaches promoted in TDD and something that many people consider to be unit tests are like apples and oranges. In Test Driven Development tests are the way of thinking, one cannot create a program without writing tests to it. To write tests before the code is easy, to write unit tests after it is boring, useless and very often impossible.

All kind of tests are important.

In the traditional TDD there is no loss of time for tests writing by definition.

I'm not used to think by tests. I can assume that it is hard for many people too.

Possibility of automate testing <= Low coherence <= Good architecture.
There is also the reverse chain.

To estimate the coherence from the tests point of view is more easy.

It is not necessary to test everything for early finding problems out. A complex problem that was not found in the low level as the snowball will grow to snow slide and bring dawn the most banal tests of the high level. But before the fixing you'll have to write the test, all the same :)

Tests are documenting errors. Write a test, fix a bug, run the test — it's a guarantee that neither you, nor your mates will trigger this backflash again (that is especially important during the refactoring).

Refactoring without tests <=> you have only yourself to blame

If after the refactoring test is not compiled it's a reason to let your team mates know about changes and ways of moving the old code.

Pre- and post conditions it is not automatic tests (emphasis is placed on any word to your taste). They still need a set of automated scripts.

Unlike homemade solutions unit tests are an industry standard of automated scripts design. There is support from IDE for them.

Tests automate the developer labor, supplement IDE with its specific functionality. Tests highlight the place of errors. Tests simplify debugging. One click and you are in the place of a problem.

There is no good code, there is a code which is easy to rewrite. Tests are one of ways of achievement of ease.

There is a separate chapter in Lingvo - "Easy-to-test"

The main thing is brain, still tests do not guarantee success.

The four large letters IMHO before each peremptory statement about the software development can be dropped only in a personal LJ.

Bigloo Scheme - simple type conversion

For a long time I looked for a function real->integer, it turned out that everything is much more easy.

1:=> (integer? 6.0)
#t
1:=> (real? 6.0)
#t
1:=> (exact? 6.0)
#f
1:=> (inexact? 6.0)
#t
1:=> (vector-ref (make-vector 10 0) 6.0)
*** ERROR:_vector-ref:
Type `int' expected, `real' provided -- 6.0
    0.interp
    1.engine
    2.main
1:=> (vector-ref (make-vector 10 0) 6)
0
1:=> (vector-ref (make-vector 10 0) (inexact->exact 6.0))
0

Links: Numerical Computation Guide

An interesting book - Numerical Computation Guide, especially the appendix What Every Computer Scientist Should Know About Floating-Point Arithmetic

For the first time I've met a description of the support of IEEE standards for the calculations with mantissa in C language.

P.S. But why this is not told in universities in study courses dedicated to the programming in C language and the computational modeling?

Ubuntu update again... boring

I've updated my all three Ubuntus — at home on the laptop, at work under coLinux and on a usual computer of my little sister. Everything took place almost without adventures.

It's good that it is almost impossible to drive Linux to the completely idle state. Without looking into what is what I tried to cross upstart and the old 2.6.11 coLinux kernel. Naturally, nothing has worked. Not a problem, I booted with init=/bin/bash parameter ant apt-geted sysvinit back.

Linuxant still has not shared builds of modem drivers for the new Ubuntu. I've downloaded a package with srcs. Something there is incompatible with the new kernel. hcfpciconfig --rcstart initializes nothing. I had to do everything at full scale of hcfpciconfig.

What is taught in schools...

Who said that Pascal is suitable language for the programming studying?

Well, about stack, heap, the difference between on-line storage, hard disk and above all why this separation is necessary I explained to my sister without a flub.

Took a time-out... I'm fussing about the syntax.

Such a doltish samples are given in books:

Type
   vector   = array[1..1000] of real;
   p_vector =  ^vector;

Var
   a p_vector;
   
getmem(a,sizeof(vector));

Just an amazing possibility of declaring in the heap an array of fixed size.
Common sense waved me goodbye.

I had to dig in my old university programs.

Aha! To have a possibility of creation arrays of really beforehand unknown size a little trick is required:

row =  array[1..1] of real;

Little sister, have not you understood yet?

Look further:

Type
   row   = array[1..1] of real;
   p_row = ^row;
Var
   a p_row; 
   i integer;
Begin   
   getmem(a,10*sizeof(real));
   for i := 1 to 10 do
      a^[i] := i;
   for i := 1 to 10 do
      writeln(a^[i]);
End.

By declaring array of one element we deceive the compiler and later it allows us to refer to the array element by dereferencing the pointer.

Before this moment the inner organization of arrays was not very important for us but now the agreement that array elements are located close to each other has become critical.
Using it, we allocate memory for array with getmem function and calculate the size of the required piece just by multiplying the size of one element to their number. And we sure that the reference to an element number i is done by a^[i] expression.

Aha, and how many pupils spoiled by Pascal will guess how to create 2-D array, after all mentioned above?
Taking into account that the answer

row = array[1..1,1..1] of real;

is wrong?

I'm going to check my sister shrewdness.