Alexander Burger wrote:
 Hi Cle,

Hello Alexander,

> Alexander Burger wrote:
>> Hi Cli,

 Oops, sorry ;-)

Macht nischt! :-D

(...)

 Now I'm wondering why you extended the setting of the 'Home' global
 in init(), to fall back to the current working directory if the first
 file argument doesn't contain a usable path pattern.

Because in test/src/mail.l there is a unit test (test (path '@) (pack (pwd) '/)) that consistently failed before! I found, that if I start the unit tests via

  ./p lib/test.l -bye

would result into a call like this using the script p:

  exec ./bin/picolisp ./lib.l @ext.l lib/test.l -bye

Exactly the combination, that let 'Home' unset so the unit test failed. Now I assumed the following:

  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?

 Is this needed on the Mac? IMHO, it does not make sense for the
 purpose of 'Home' (i.e. being inserted in path names starting with
 '@'), because it is to make programs independent from the current
 working directory and find the installation directory when started
 from arbitrary locations.

Is it needed on the Mac? I do not know! But as the 'p' script make all my calls to './' the old solution did not work. So I changed it. But perhaps my solution is also not correct!

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

Some of these cases still do not work correctly neither with the old solution nor with my work-around. So perhaps we should first specify a bit, how it should work correctly and then I can try to implement the solution?

But anyhow, sorry, if I got it wrong this time!

 The other issue, the port conflict, is quite strange:

> 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.

 Then we have another bug on the Mac perhaps. On my system, a port can
 be reused after it was closed:

(... test sequence snipped ...)

 What happens if you try these things in the REPL?

It works correctly! No problem at all!

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 ...

 Cheers, - Alex

Ciao,
Cle.


--------------080103040309050501040702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
 <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Alexander Burger wrote:<br>
<span style="white-space: pre;">&gt; Hi Cle,<br>
</span><br>
Hello Alexander,<br>
<span style="white-space: pre;"><br>
&gt;&gt; Alexander Burger wrote:<br>
&gt;&gt;&gt; Hi Cli,<br>
&gt; <br>
&gt; Oops, sorry ;-)<br>
</span><br>
Macht nischt! :-D<br>
<br>
<span style="white-space: pre;">(...)</span><br>
<br>
<span style="white-space: pre;">&gt; Now I'm wondering why you extended
the setting of the 'Home' global<br>
&gt; in init(), to fall back to the current working directory if the
first<br>
&gt; file argument doesn't contain a usable path pattern.</span><br>
<br>
Because in test/src/mail.l there is a unit test (test (path '@) (pack
(pwd) '/)) that consistently failed before! I found, that if I start
the unit tests via<br>
<br>
  ./p lib/test.l -bye<br>
<br>
would result into a call like this using the script p:<br>
<br>
  exec ./bin/picolisp ./lib.l @ext.l lib/test.l -bye<br>
<br>
Exactly the combination, that let 'Home' unset so the unit test failed.
Now I assumed the following:<br>
<br>
  if (the first file contains a '/' and does not begin with './')<br>
     old handling that also considering absolute pathes and<br>
     relative pathes not beginning with './'<br>
 else<br>
     assume the path is relative to the current working directory<br>
<br>
But perhaps my assumptions were wrong?<br>
<br>
<span style="white-space: pre;"></span><span style="white-space: pre;">&gt;
Is this needed on the Mac? IMHO, it does not make sense for the<br>
&gt; purpose of 'Home' (i.e. being inserted in path names starting with<br>
&gt; '@'), because it is to make programs independent from the current<br>
&gt; working directory and find the installation directory when started<br>
&gt; from arbitrary locations.</span><br>
<br>
Is it needed on the Mac? I do not know! But as the 'p' script make all
my calls to './' the old solution did not work. So I changed it. But
perhaps my solution is also not correct!<br>
<br>
So could you perhaps elaborate a bit, what should be the correct
behavior? If for instance started via<br>
<br>
   ./p lib/test.l -bye<br>
   ./p $(pwd)/lib/test.l -bye<br>
   ./p ../picolisp/lib/test.l -bye<br>
   (cd lib; ../p test.l -bye)<br>
   PATH=$(pwd):$PATH p lib/test.l -bye<br>
<br>
Some of these cases still do not work correctly neither with the old
solution nor with my work-around. So perhaps we should first specify a
bit, how it should work correctly and then I can try to implement the
solution?<br>
<br>
But anyhow, sorry, if I got it wrong this time!<br>
<br>
<span style="white-space: pre;">&gt; The other issue, the port
conflict, is quite strange:<br>
&gt; <br>
&gt;&gt; test/src/net.l also use port 4444, it seems that the port was
not <br>
&gt;&gt; released back to the OS yet, when test/lib.l was running.
Therfore<br>
&gt;&gt; it was still be used and couldn't be bound again.<br>
&gt; <br>
&gt; Then we have another bug on the Mac perhaps. On my system, a port
can<br>
&gt; be reused after it was closed:<br>
</span><br>
(... test sequence snipped ...)<br>
<br>
<span style="white-space: pre;">&gt; What happens if you try these
things in the REPL?<br>
</span><br>
It works correctly! No problem at all!<br>
<br>
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 ...<br>
<span style="white-space: pre;"><br>
&gt; Cheers, - Alex</span><br>
<br>
Ciao,<br>
Cle.<br>
<br>
</body>
</html>

--------------080103040309050501040702--
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to