Hi Cle,

> >  Now I'm wondering why you extended the setting of the 'Home' global
> >  ...
> (pwd) '/)) that consistently failed before! I found, that if I start the 
> unit tests via
> 
>    ./p lib/test.l -bye

I see. The unit tests are a little special. As they need a well-defined
environment to operate correctly, they have to be started in a certain
way. It is written as a comment in the 5th line of "lib/test.l":

   # $(/bin/pwd)/p lib/test.l -bye

This makes sure that 'Home' has a value that suits later tests which
compare with the result of (pwd).


>    if (the first file contains a '/' and does not begin with './')
>       old handling that also considering absolute pathes and
>       relative pathes not beginning with './'
>   else
>       assume the path is relative to the current working directory
> 
> But perhaps my assumptions were wrong?

Not wrong, but they would be useful only in the context of these unit
tests. In that sense, the unit tests are the problem, not the system
itself.


> So could you perhaps elaborate a bit, what should be the correct 
> behavior? If for instance started via
> 
>     ./p lib/test.l -bye
>     ./p $(pwd)/lib/test.l -bye
>     ./p ../picolisp/lib/test.l -bye
>     (cd lib; ../p test.l -bye)
>     PATH=$(pwd):$PATH p lib/test.l -bye

For the unit tests, the 'p' script itself must be started with an
absolute path that is identical to what the (pwd) function returns. Only
then will the tests that check the return value of (path '@) work
correctly. This is the only reason.

As you noticed, the initialization of 'Home' works in such a way that
the first file name on the command line is analyzed to determine the
installation directory. This is usually "lib.l". Thus, the invokation

   $(/bin/pwd)/p lib/test.l -bye

will expand to

   /<dir>/bin/picolisp /<dir>/lib.l @ext.l lib/test.l -bye
                       ^
and 'Home' will point to "/<dir>/".

In the above five examples, it either points to "./", to "../" or is
empty. In all those cases the (path '@) tests will fail.


> > > test/src/net.l also use port 4444, it seems that the port was not
> > > released back to the OS yet, when test/lib.l was running. Therfore
> > > it was still be used and couldn't be bound again.
> > ...
> But in test/src/net.l you fork a child process while dealing with that 
> port. And as my MacBoot is a dual core, those processes get executed in 
> parallel probably. So it may be, that the test in test/src/net.l was 
> alread passes, but the port was still hold by the child, when test/lib.l 
> tried to open it. So it failed. This is only a hypothesis, though ...

Ah, right! This might be the problem. The child process in
"test/src/net.l" sleeps for 400 milliseconds before it terminates. If
the other tests proceeded meanwhile, we might get a conflict.

So I will follow your suggestion and change these ports.

I uploaded a new "picoLisp.tgz". If you have time, please check if the
situation is improved.

Many thanks!

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to