tack-devel — Discussion for developers of the ACK.

[Tack-devel] CVS migrated to Mercurial

[David G. <dg...@co...>]

I have just migrated the ACK CVS repository to a new Mercurial
repository on Sourceforge (for general reliability, performance,
robustness, etc reasons).

The old CVS repository won't be going away, but will no longer be
modified; any new development, if any, will happen in the Mercurial
repository.

I had to fix some CVS corruption in old files that no longer exist so
it's possible that checking out certain very old revisions won't produce
entirely correct results, but anything recent should be fine.

Information on how to access the Mercurial repository is here:

https://sourceforge.net/scm/?type=hg&group_id=130811

Trust me, Mercurial is *so* much better and easier to use than CVS it
isn't funny...

Incidentally, people may be interested to know that the very first ACK
checkin happened at 13:42 UTC on Thursday, May 17 1984, which makes the
ACK older than CVS itself...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "I have a mind like a steel trap. It's rusty and full of dead mice."
│ --- Anonymous, on rasfc

Re: [Tack-devel] Beginner - problem linking pascal program

[David G. <dg...@co...>]

On 02/10/10 18:38, er...@ba... wrote:
[...]
> OK, I have written replacement new.c and dis.c that implement the standard 
> procedures new() and dispose().
[...]
> While testing my new new() and dispose() functions I noticed that the
> ANSI standard macro assert from <assert.h> does not work in the C
> compiler.

Awesome. I've fixed the assert() issue and checked in your new new() and
dispose() --- thanks very much for that!

Incidentally, with regard to the copyright notices: the notices in the
source files are now obsolete, and are superseded by the BSD license in
the root directory. They should probably all be removed at some point.
As your implementation is clearly a derivative of the original, and the
original had the commercial license text, I've left it in.

[...]
> I have uncovered a few more problems in the Pascal compiler, I will post
> on this list if and when I have some proposed solutions.

All fixes gratefully appreciated! As you can tell, none of this seems to
have been exercised much. I suspect you're probably the first ack Pascal
user for about twenty years...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "To be is to do" -- Nietzche
│ "To do is to be" -- Sartre
│ "Do be do be do" -- Sinatra

[Tack-devel] Beginner - problem linking pascal program

[<er...@ba...>]

2010-09-30 David Given  wrote:
>This is all stuff related to dynamic memory allocation.
>
>Back in the old days, the EM virtual machine defined its own mechanism
>for allocating memory. These days we use the host OS to do this instead.
>Obviously the Pascal runtime library hasn't been updated to use malloc
>and free.
>
>If you want to have a look, the Pascal compiler calls _new() and _dis()
>in libpc (lang/pc/libpc/...) to do the work; I'll have a go myself when
>I get the chance, but it may not be soon.

OK, I have written replacement new.c and dis.c that implement the standard 
procedures new() and dispose(). Instead of including them in this message
I have made the files available on my webserver, adress:
    http://pascal.dyndns-free.com/ackmod/

I have uncovered a few more problems in the Pascal compiler, I will post
on this list if and when I have some proposed solutions.

While testing my new new() and dispose() functions I noticed that the ANSI 
standard macro assert from <assert.h> does not work in the C compiler.
(Fails with a linker message about unresolved symbols.)
This can be fixed by renaming the calls to _kill() and _getpid() to just
kill() and getpid() (no underscores) in the file lang/cem/libcc.ansi/signal/raise.c
but I don't know if this is the correct way to fix this bug.

regards
Erik Backerud

Re: [Tack-devel] Beginner - problem linking pascal program

[David G. <dg...@co...>]

On 30/09/10 11:17, er...@ba... wrote:
> 2010-09-28 er...@ba... wrote:
>> I tried it and it works. Thanks alot!
>> Now that I've gotten a bit further I have discovered more linking problems in the Pascal compiler.
>> It seems that any program that contains a call to the built in procedure new() or dispose() fails during linking with the message:
>> Undefined:
>>         .reghp
>>         .limhp
>>         BRK
> The above symbols are defined in a file called mach/i386/libsys/head_em.s, but the objectfile corresponding to this file does not seem to get included in any library( lib/linux386/libsys.a ? ). I haven't figured out how that happens. Regards

This is all stuff related to dynamic memory allocation.

Back in the old days, the EM virtual machine defined its own mechanism
for allocating memory. These days we use the host OS to do this instead.
Obviously the Pascal runtime library hasn't been updated to use malloc
and free.

If you want to have a look, the Pascal compiler calls _new() and _dis()
in libpc (lang/pc/libpc/...) to do the work; I'll have a go myself when
I get the chance, but it may not be soon.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL

Re: [Tack-devel] Beginner - problem linking pascal program

[Jan V. <ja...@ve...>]

On Thursday 30 September 2010 12:17:28 er...@ba... wrote:
> 2010-09-28 er...@ba... wrote:
> > I tried it and it works. Thanks alot!
> > Now that I've gotten a bit further I have discovered more linking
> > problems in the Pascal compiler. It seems that any program that
> > contains a call to the built in procedure new() or dispose() fails
> > during linking with the message: Undefined:
> >         .reghp
> >         .limhp
> >         BRK
>
> The above symbols are defined in a file called
> mach/i386/libsys/head_em.s, but the objectfile corresponding to this
> file does not seem to get included in any library(
> lib/linux386/libsys.a ? ). I haven't figured out how that happens.
> Regards Erik Backerud

EM is the intermediate code that is generated by the compiler front end.

If you compile with the -t flag, all intermediate files are preserved 
(i.e. none is deleted). Is this a clue?

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

[Tack-devel] Beginner - problem linking pascal program

[<er...@ba...>]

2010-09-28 er...@ba... wrote:
> I tried it and it works. Thanks alot!
> Now that I've gotten a bit further I have discovered more linking problems in the Pascal compiler.
> It seems that any program that contains a call to the built in procedure new() or dispose() fails during linking with the message:
> Undefined:
>         .reghp
>         .limhp
>         BRK
The above symbols are defined in a file called mach/i386/libsys/head_em.s, but the objectfile corresponding to this file does not seem to get included in any library( lib/linux386/libsys.a ? ). I haven't figured out how that happens. Regards
Erik Backerud

Re: [Tack-devel] GUI front end

[Jan V. <ja...@ve...>]

On Tuesday 28 September 2010 22:37:22 Jan Verhoeven wrote:
> I'm working (off and on) on a GUI front end for the ACK:
>
> http://fruttenboel.verhoeven272.nl/ack/gui.html
>
> Not sure when it will be ready....

It's almost ready... You can compile, run and execute Unix commands from 
within the GUI. All output is logged in the GUI.

The webpage contains screenshots. In the download section you can get 
yourself a copy of the tcl script:

	http://fruttenboel.verhoeven272.nl/ack/data/gack.tcl

The gack is only tested with the Modula-2 front end. Volunteers for the 
C and Pascal front ends? :o)

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

[Tack-devel] GUI front end

[Jan V. <ja...@ve...>]

I'm working (off and on) on a GUI front end for the ACK:

http://fruttenboel.verhoeven272.nl/ack/gui.html

Not sure when it will be ready....

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] Beginner - problem linking pascal program

[<er...@ba...>]

2010-09-27 David Given  wrote:
>Nothing. I've just had a look at the libpascal source code and the
>relevant files are calling _open() and _creat() instead of open() and
>creat() for some reason; it is perfectly legitimately broken. remove()
>was simply not supported in the extremely minimal syscall library for
>linux386.
>
>I've changed libpascal to call the correct functions, and I've added
>remove() and unlink() to the syscall library; however as these changes
>are scattered across the system I'm not going to try and produce a
>patch, so I'm afraid I'll have to ask you to check out head of CVS to
>get the fixed version. None of this is at all tested. There may be a
>*reason* why libpascal is calling _open() and _creat().
>
>To check out CVS, install a CVS client, then run this commands:
>
>cvs -z3 -d:pserver:ano...@ta...:/cvsroot/tack co
>-P Ack

I tried it and it works. Thanks alot!
Now that I've gotten a bit further I have discovered more linking problems in the Pascal compiler.
It seems that any program that contains a call to the built in procedure new() or dispose() fails during linking with the message:
Undefined:
        .reghp
        .limhp
        BRK

I have looked in the source and seen mention of .reghp and .limhp but I haven't found any fix for the problem. I am not so familiar with the internals of the Ack compilers (yet).

Regards
Erik Backerud

Re: [Tack-devel] Beginner - problem linking pascal program

[David G. <dg...@co...>]

On 27/09/10 15:27, er...@ba... wrote:

(Do I owe you a reply to a message from weeks ago?)

[...]
> Now I can compile Pascal programs with a command like: "ack -o f2 f2.p". This seems to work except when the program contains calls to the standard procedures reset() and rewrite(), then I get an error from the linker:
> Undefined:
>         __open
>         __creat
>         _remove
> There are modules with names like: 1317-pcreat.o in libpascal.a. and that files seems to contain the symbol '__creat' for example. What am I doing wrong?
[...]

Nothing. I've just had a look at the libpascal source code and the
relevant files are calling _open() and _creat() instead of open() and
creat() for some reason; it is perfectly legitimately broken. remove()
was simply not supported in the extremely minimal syscall library for
linux386.

I've changed libpascal to call the correct functions, and I've added
remove() and unlink() to the syscall library; however as these changes
are scattered across the system I'm not going to try and produce a
patch, so I'm afraid I'll have to ask you to check out head of CVS to
get the fixed version. None of this is at all tested. There may be a
*reason* why libpascal is calling _open() and _creat().

To check out CVS, install a CVS client, then run this commands:

cvs -z3 -d:pserver:ano...@ta...:/cvsroot/tack co
-P Ack

This will download the ACK source into a directory called Ack.

Sorry for the inconvenience...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "To be is to do" -- Nietzche
│ "To do is to be" -- Sartre
│ "Do be do be do" -- Sinatra

Re: [Tack-devel] Beginner - problem linking pascal program

[Jan V. <ja...@ve...>]

On Monday 27 September 2010 16:27:17 er...@ba... wrote:
> Hello.
> I got ack mainly in order to try out the Pascal compiler under Linux,
> and it seems to work for programs that do not do file I/O. I
> installed ack-6.0pre4 on a debian system. The only modifications I
> made was to change the line: DEFAULT_PLATFORM = "pc86"
> to:
> DEFAULT_PLATFORM = "linux386"
> in config.pm . I then ran the three commands
> ./pm configure;    ./pm;    ./pm install

OK

> Now I can compile Pascal programs with a command like: "ack -o f2
> f2.p". This seems to work except when the program contains calls to
> the standard procedures reset() and rewrite(), then I get an error
> from the linker: Undefined:
>         __open
>         __creat
>         _remove

I can create, open, read and append files using the Modula-2 front end. 
So that part seems to work. I guess the Pascal units (or whatever they 
are called) need some touching up. Lately I fixed a 30 year old error 
in a low level library... In the Modula-2 section.

> There are modules with names like: 1317-pcreat.o in libpascal.a. and
> that files seems to contain the symbol '__creat' for example. What am
> I doing wrong?

You're not using the Modula-2 front end... :o)

See also http://fruttenboel.verhoeven272.nl/ack/index.html

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

[Tack-devel] Beginner - problem linking pascal program

[<er...@ba...>]

Hello.
I got ack mainly in order to try out the Pascal compiler under Linux, and it seems to work for programs that do not do file I/O. I installed ack-6.0pre4 on a debian system. The only modifications I made was to change the line:
DEFAULT_PLATFORM = "pc86"
to:
DEFAULT_PLATFORM = "linux386"
in config.pm . I then ran the three commands
./pm configure;    ./pm;    ./pm install
Now I can compile Pascal programs with a command like: "ack -o f2 f2.p". This seems to work except when the program contains calls to the standard procedures reset() and rewrite(), then I get an error from the linker:
Undefined:
        __open
        __creat
        _remove
There are modules with names like: 1317-pcreat.o in libpascal.a. and that files seems to contain the symbol '__creat' for example. What am I doing wrong?

Re: [Tack-devel] Allocated memory

[David G. <dg...@co...>]

On 08/09/10 21:38, Jan Verhoeven wrote:
> Suppose I have a program that allocates 10 MB of memory.
> 
> The program stops.
> 
> Is memory automatically de-allocated? Or shgould I do this manually?

On any Unix, all resources the program was using get freed up when the
process gets destroyed [*]. This includes memory, open file handles,
etc. So you don't have to worry about it.



[*] With certain exotic exceptions like shared memory segments.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL

[Tack-devel] Allocated memory

[Jan V. <ja...@ve...>]

Suppose I have a program that allocates 10 MB of memory.

The program stops.

Is memory automatically de-allocated? Or shgould I do this manually?

Mocka has the concept of MemoryPools. At the end of the program you 
simply kill the pool and that's it.

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] ACK GetPosition

[Jan V. <ja...@ve...>]

On Wednesday 01 September 2010 21:57:04 David Given wrote:

> Fixed and checked in --- thanks very much for that.

I'd like tyo help a bit more for this fine compiler. As long as it is in 
my competences...

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] ACK GetPosition

[David G. <dg...@co...>]

On 31/08/10 19:13, Jan Verhoeven wrote:
[...]
>> 	position := position - LONG(s^.maxcnt - s^.cnt + 1)
[...]
> Which was the correct assumption. I changed the Streams implementation 
> module /home/jan/modula/ACK/lang/m2/libm2/Streams.mod recompiled 
> with 'pm -p' and 'pm install' and now all is well.

Fixed and checked in --- thanks very much for that.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Home is where, when you have to go there, they have to take you in."
│ --- Cordelia Naismith

Re: [Tack-devel] ACK GetPosition

[Jan V. <ja...@ve...>]

On Tuesday 31 August 2010 03:09:53 Jan Verhoeven wrote:

> >    position := position + LONG(s^.maxcnt - s^.cnt + 1);
>
> I think the plus sign ought to be a minus sign so that the line
> reads:
>
> 	position := position - LONG(s^.maxcnt - s^.cnt + 1)
>
> assuming:

Which was the correct assumption. I changed the Streams implementation 
module /home/jan/modula/ACK/lang/m2/libm2/Streams.mod recompiled 
with 'pm -p' and 'pm install' and now all is well.


-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

[Tack-devel] ACK GetPosition

[Jan V. <ja...@ve...>]

Gents,

When going through Streams.mod I see something strange in the definition 
of GetPosition:

PROCEDURE GetPosition(s: Stream; VAR position: LONGINT;
                      VAR result: StreamResult);
BEGIN
  IF (s = NIL) OR (s^.kind = none) THEN
    result := illegaloperation;
    RETURN;
  END;
  IF (s^.mode # reading) THEN FlushStream(s, result); END;
  position := StripUnix.lseek(s^.fildes, 0D, 1);
  IF position < 0D THEN
    result := illegaloperation;
    RETURN;
  END;
  IF s^.mode = reading THEN
>    position := position + LONG(s^.maxcnt - s^.cnt + 1);
  END;
END GetPosition;

I think the plus sign ought to be a minus sign so that the line reads:

	position := position - LONG(s^.maxcnt - s^.cnt + 1)	

assuming:

	position = bytes transfered from file
	maxcnt = buffersize
	cnt = position in buffer

maxcnt - cnt = unused part of the buffer 
If you subtract this from the total bytes tranfered from disk, you must 
end up with the amount of bytes processed.

Since this is ACK Modula-2 source.... am I the first to find this bug in 
30 years?

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] File pointer in the ACK

[Jan V. <ja...@ve...>]

On Monday 30 August 2010 12:49:24 David Given wrote:

> Could you try running your program with strace again?
> Streams.GetPosition seems to be calling lseek to do the work, and I'd
> like to see what the kernel's actually seeing. (The kernel APIs are
> hairy and very badly documented.)

-------------------
open("testdata", O_RDONLY)              = 3
read(3, "123456789ABCDEF 123456789ABCDEF "..., 1024) = 64
lseek(3, 0, SEEK_CUR)                   = 64
------------------

64 is the length of the file. Not the current position...


-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] File pointer in the ACK

[Jan V. <ja...@ve...>]

On Monday 30 August 2010 12:49:24 David Given wrote:
> On 29/08/10 20:36, Jan Verhoeven wrote:
> [...]
>
> > I read the first 7 tokens out of it. Then I ask for the file
> > pointer with Streams.GetPosition. Although I just read character nr
> > '7', the file pointer returns the value 25
>
> Could you try running your program with strace again?
> Streams.GetPosition seems to be calling lseek to do the work, and I'd
> like to see what the kernel's actually seeing. (The kernel APIs are
> hairy and very badly documented.)

Of course...

jan@Beryllium:~/develop/ack$ strace -o log.txt bakk
123456789ABCDEF 123456789ABCDEF 12345
 ++++  ++++ .n
jan@Beryllium:~/develop/ack$ less log.txt
jan@Beryllium:~/develop/ack$

The plus signs are printed after each call to [GS]etPosition. The dot is 
printed when th REPEAT is entered and the 'n' is printed to signal a 
nil.

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] File pointer in the ACK

[David G. <dg...@co...>]

On 29/08/10 20:36, Jan Verhoeven wrote:
[...]
> I read the first 7 tokens out of it. Then I ask for the file pointer 
> with Streams.GetPosition. Although I just read character nr '7', the 
> file pointer returns the value 25

Could you try running your program with strace again?
Streams.GetPosition seems to be calling lseek to do the work, and I'd
like to see what the kernel's actually seeing. (The kernel APIs are
hairy and very badly documented.)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Home is where, when you have to go there, they have to take you in."
│ --- Cordelia Naismith

[Tack-devel] File pointer in the ACK

[Jan V. <ja...@ve...>]

Hello fellow ACKers

I've got a small problem with a file pointer.

I have a file with the content

        123456789ABCDEF

I read the first 7 tokens out of it. Then I ask for the file pointer 
with Streams.GetPosition. Although I just read character nr '7', the 
file pointer returns the value 25

I documented the problem here:

	http://fruttenboel.verhoeven272.nl/ack/sio.html

In the very bottom of the page.

Can someone confirm this for either C or Pascal?

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] New Module

[Jan V. <ja...@ve...>]

On Saturday 21 August 2010 12:16:13 David Given wrote:

> > I get the impression that I need to compile a module manually. The
> > man page does not clear things. Anyone an idea?
>
> The ACK is a traditional compiler and, yes, does need separate
> compilation.
>
> ack -c module1.mod
> ack -c module2.mod
> ack -o outputfile -r.mod module1.o module2.o
>
> ...or:
>
> ack -o outputfile module1.mod module2.mod

Let's say it is peculiar (for a Modula-2 compiler) but it is also 
cute...

And it works...

	http://fruttenboel.verhoeven272.nl/ack/sio.html

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl

Re: [Tack-devel] New Module

[David G. <dg...@co...>]

On 21/08/10 01:25, Jan Verhoeven wrote:
[...]
> Normally, when a Modula-2 compiler detects a module that is not yet 
> compiled (or of which the source files are newer than the compiled 
> file) it does an automatic compile.
[...]
> I get the impression that I need to compile a module manually. The man 
> page does not clear things. Anyone an idea?

The ACK is a traditional compiler and, yes, does need separate compilation.

ack -c module1.mod
ack -c module2.mod
ack -o outputfile -r.mod module1.o module2.o

...or:

ack -o outputfile module1.mod module2.mod

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Home is where, when you have to go there, they have to take you in."
│ --- Cordelia Naismith

[Tack-devel] New Module

[Jan V. <ja...@ve...>]

Friends,

I created a new module called Sio with a Def and a Mod part as usual. 
Then I made a test source to comfirm the first version was right.. :o)

Normally, when a Modula-2 compiler detects a module that is not yet 
compiled (or of which the source files are newer than the compiled 
file) it does an automatic compile.

Not with the ACK.

I get the impression that I need to compile a module manually. The man 
page does not clear things. Anyone an idea?

jan@Beryllium:~/develop/ack$ ack filt.mod -o filt1
"filt.mod", line 19: (warning) variable "outS" never used/assigned
Undefined:
        __Sio_
        __Sio__ReadString
        __Sio__EOF

zSio IS defined, just as well as both functions.

-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl