subject:"'do'"

Hi Andras,

> Perfect, it works as expected on macOS.

Great! :)


> Finally I’ve got demoApp working: the culprit was the Safari browser.
> With Firefox it works!

I see. But then the Pil GUI must somehow be faulty too.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Alex,

Perfect, it works as expected on macOS.

Finally I’ve got demoApp working: the culprit was the Safari browser.
With Firefox it works!

Regards,
Andras Pahi

> On 2021. Apr 17., at 16:54, Alexander Burger  wrote:
> 
> On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote:
>> OK, as ppoll() works fine on Linux (tests passed), I will keep it. This 
>> covers
>> most use cases, including Servers (Debian), PilBox (Android) and smaller 
>> stuff
>> (Raspi).
>> 
>> I put an #ifdef for other systems, using poll() and setting infinite timeout
>> above 24 days.
> 
> Done!! Released a new pil21.tgz :)
> 
> @Andras: Can you test on Mac again?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote:
> OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers
> most use cases, including Servers (Debian), PilBox (Android) and smaller stuff
> (Raspi).
> 
> I put an #ifdef for other systems, using poll() and setting infinite timeout
> above 24 days.

Done!! Released a new pil21.tgz :)

@Andras: Can you test on Mac again?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Sat, Apr 17, 2021 at 04:21:53PM +0200, Alexander Burger wrote:
> Hmm, I'm just testing the ppoll() version ... What to do?

OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers
most use cases, including Servers (Debian), PilBox (Android) and smaller stuff
(Raspi).

I put an #ifdef for other systems, using poll() and setting infinite timeout
above 24 days.


BTW, the problems on MacOS are not explained with this. Even more as we now know
that on Linux too the 64 bit timeout was truncated to 32 bits. And I think
nowhere (e.g. demo app) such a big timeout was passed so that the value wrapped
to negative. Something else must be seriously wrong.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Andras,

> Just one remark, ppoll(2) is Linux-specific.

Oh, you are right! Too bad, it would have been a perfect replacement!

Good that you mention this, I did not pay attention.


> I know there is a perfectly portable API - Linux.

Yes :)

Hmm, I'm just testing the ppoll() version ... What to do?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Alex,

Just one remark, ppoll(2) is Linux-specific.
I know there is a perfectly portable API - Linux.

Regards,
Andras Pahi

> On 2021. Apr 17., at 15:53, Alexander Burger  wrote:
> 
> On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote:
>> But as you saw in my last mail, the whole question is obsolete. I have to 
>> adjust
>> pil21 anyway.
> 
> I will use ppoll(2).
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote:
> But as you saw in my last mail, the whole question is obsolete. I have to 
> adjust
> pil21 anyway.

I will use ppoll(2).

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Andras,

> Maybe the definition of
> 
> #define __INT_MAX__ 2147483647
> 
> could be used ? It is predefined by the clang/gcc preprocessor.

Yeah, should be portable enough.

But as you saw in my last mail, the whole question is obsolete. I have to adjust
pil21 anyway.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi all,

On Sat, Apr 17, 2021 at 01:02:20PM +0200, Alexander Burger wrote:
> Hmm, too bad! I tested here with 64-bit integers with
> 
>#if (int)-1 == 0x
> 
> and it worked.

Uuhh! Sorry! I was completely off the track!

'int' is *always* 32 bit in size, on every system I've seen so far!
How could I forget and confuse this?

So the whole concept of 292MY in pil21 is nonsense. It never worked, because
poll() would never wake up for timeouts greater than 24.86 days.

It seems I never ran a test with such a timeout ;)

Anyway, I will fix pil21.

.. but this does not explain the MacOS problems ...

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Alex,

Maybe the definition of

#define __INT_MAX__ 2147483647

could be used ? It is predefined by the clang/gcc preprocessor.

Regards,
Andras Pahi


> On 2021. Apr 17., at 13:02, Alexander Burger  wrote:
> Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used 
> the
> above construct.
> 
> Does anybody have a better idea?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Andras,

> According to the man page on macOS, poll returns:
> 
>  [EINVAL]   The nfds argument is greater than OPEN_MAX or the
> timeout argument is less than -1.

That explains it! So the specification of poll() is indeed different from the
Linux one.


> The check at compile time is not triggered on macOS, the following program
> prints “false”:
> 
> #include 
> #include 
> 
> int main(int argc, char*argv[])
> {
> #if (int)-1 == 0x
> printf("true");
> #else
> printf("false");
> #endif
>   return 0;

Hmm, too bad! I tested here with 64-bit integers with

   #if (int)-1 == 0x

and it worked.


Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used the
above construct.

Does anybody have a better idea?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Alex,

Thank you for looking after this.

According to the man page on macOS, poll returns:

 [EINVAL]   The nfds argument is greater than OPEN_MAX or the
timeout argument is less than -1.

The check at compile time is not triggered on macOS, the following program
prints “false”:

#include 
#include 

int main(int argc, char*argv[])
{
#if (int)-1 == 0x
printf("true");
#else
printf("false");
#endif
  return 0;
}

Regards,
Andras Pahi

> On 2021. Apr 17., at 11:42, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
>> values which when casted to (int) results in values less than -1 (eg. -3).
>> This results in EINVAL errors in poll().
> 
> The EINVAL is indeed strange. According to the man page any negative timout
> should result in an infinite wait.
> 
> 
>> I have inserted a code snippet which truncates the timeout to -1 then I can 
>> get
>> to the login page in the demo app.
> 
> This should not be necessary since PicoLip 21.4.15. It checks at compile time
> whether it is a system with 32-bit int's, and then passes -1 for larger 
> numbers:
> 
>   #if (int)-1 == 0x
>  else if (timeout > 2147483647)  // Fit into 32 bits (max 24 days)
> timeout = -1;
>   #endif
> 
> I cannot test it here. Can you verify that it works?
> 
> 
>> Entering eg. “ben”, “ben” results in dropping the connection. The task 
>> handling the connection
>> is forked, as I see in the process list.
> 
> Hmm, so the above is not enough. There must be some other problem, perhaps 
> also
> related to 32-bit integers.
> 
> ☺/ A!ex
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Andras,

> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
> values which when casted to (int) results in values less than -1 (eg. -3).
> This results in EINVAL errors in poll().

The EINVAL is indeed strange. According to the man page any negative timout
should result in an infinite wait.


> I have inserted a code snippet which truncates the timeout to -1 then I can 
> get
> to the login page in the demo app.

This should not be necessary since PicoLip 21.4.15. It checks at compile time
whether it is a system with 32-bit int's, and then passes -1 for larger numbers:

   #if (int)-1 == 0x
  else if (timeout > 2147483647)  // Fit into 32 bits (max 24 days)
 timeout = -1;
   #endif

I cannot test it here. Can you verify that it works?


> Entering eg. “ben”, “ben” results in dropping the connection. The task 
> handling the connection
> is forked, as I see in the process list.

Hmm, so the above is not enough. There must be some other problem, perhaps also
related to 32-bit integers.

☺/ A!ex


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi,

It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
values which when casted to (int) results in values less than -1 (eg. -3).
This results in EINVAL errors in poll().

I have inserted a code snippet which truncates the timeout to -1 then I can get
to the login page in the demo app.

Entering eg. “ben”, “ben” results in dropping the connection. The task handling 
the connection
is forked, as I see in the process list.

Any ideas how to get further ?

Thanks,
Andras Pahi

> On 2021. Apr 16., at 7:43, Andras Pahi  wrote:
> 
> Hi Alex,
> 
> Thank you for your suggestions, I have traced listen and wait and both have
> The parameters are as expected (Ms is NIL, Sd is 17).
> 
> As Mike tested on macOS Big Sur and it worked, the problem is in my setup.
> 
> Regards,
> Andras
> 
>> On 2021. Apr 15., at 19:11, Alexander Burger  wrote:
>> 
>> Hi Andras,
>> 
>>> 
>>> /pil app/main.l -ap~main -'go 4040' +
>>> 6538 = 58885 48782252818959702~
>>> ap: !? (wait Ms T "Sd")
>>> Select error: Invalid argument
>>> ...
>>> It has the same behavior as the previous version of pil21.
>> 
>> Yeah, I thought about it, and came to the conclusion that today's change in
>> gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout 
>> is
>> seldom used, I think.
>> 
>> So what causes the above error?
>> 
>> It happens in 'listen' (line 94 in @lib/net.l):
>> 
>>  (de listen (Sd Ms)
>> (loop
>>(NIL (wait Ms T Sd))
>>(T (accept Sd) @) ) )
>> 
>> "Select error" is issued by poll(). But which argument is ivalid?
>> 
>> Can you try to trace or debug?
>> 
>> Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen 
>> is
>> called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd().
>> 
>> Any idea?
>> 
>> ☺/ A!ex
>> 
>> -- 
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

2021-04-16 Thread picolisp

$ picolisp -wait
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775806]
!? (wait)
Select error: Invalid argument
?
: (wait)
!? (wait)
Select error: Invalid argument
?
: (wait)
!? (wait)
Select error: Invalid argument
?

fds was NULL, but then became non-NULL.


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Alex,

Thank you for your suggestions, I have traced listen and wait and both have
The parameters are as expected (Ms is NIL, Sd is 17).

As Mike tested on macOS Big Sur and it worked, the problem is in my setup.

Regards,
Andras

> On 2021. Apr 15., at 19:11, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> 
>> /pil app/main.l -ap~main -'go 4040' +
>> 6538 = 58885 48782252818959702~
>> ap: !? (wait Ms T "Sd")
>> Select error: Invalid argument
>> ...
>> It has the same behavior as the previous version of pil21.
> 
> Yeah, I thought about it, and came to the conclusion that today's change in
> gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout 
> is
> seldom used, I think.
> 
> So what causes the above error?
> 
> It happens in 'listen' (line 94 in @lib/net.l):
> 
>   (de listen (Sd Ms)
>  (loop
> (NIL (wait Ms T Sd))
> (T (accept Sd) @) ) )
> 
> "Select error" is issued by poll(). But which argument is ivalid?
> 
> Can you try to trace or debug?
> 
> Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen 
> is
> called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd().
> 
> Any idea?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Mike,

Thank you for the test, I am still on Mojave.
I will check my setup where it went wrong.

Regards,
Andras

> On 2021. Apr 15., at 21:13, Mike  wrote:
> 
> Andras,
> 
> https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg
> this is my try on latest big sur
> 
> 
> 
> April 15, 2021 7:53 PM, "Andras Pahi"  wrote:
> 
>> Hi,
>> 
>> I grabbed the latest pil21.tgz and demoApp.tgz.
>> 
>> "pil @lib/test.l +" runs without errors.
>> 
>> On macOS I've got
>> 
>> ./pil app/main.l -ap~main -'go 4040' +
>> 
>> 6538 = 58885 48782252818959702~
>> 
>> ap: !? (wait Ms T "Sd")
>> 
>> Select error: Invalid argument
>> 
>> ap? Select error: Invalid argument
>> 
>> ap? Select error: Invalid argument
>> 
>> …
>> ap? Select error: Invalid argument
>> ap? Segmentation fault: 11
>> 
>> It has the same behavior as the previous version of pil21.
>> 
>> Regards,
>> Andras Pahi
>> 
>>> On 2021. Apr 15., at 12:51, Alexander Burger  wrote:
>>> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
>>>> Looks like I should do that.
>>> 
>>> Done!
>>> 
>>> Can somebody test on a Macintosh or other BSDs?
>>> 
>>> ☺/ A!ex
>>> 
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

2021-04-15 Thread Mike

Andras,

https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg
this is my try on latest big sur



April 15, 2021 7:53 PM, "Andras Pahi"  wrote:

> Hi,
> 
> I grabbed the latest pil21.tgz and demoApp.tgz.
> 
> "pil @lib/test.l +" runs without errors.
> 
> On macOS I've got
> 
> ./pil app/main.l -ap~main -'go 4040' +
> 
> 6538 = 58885 48782252818959702~
> 
> ap: !? (wait Ms T "Sd")
> 
> Select error: Invalid argument
> 
> ap? Select error: Invalid argument
> 
> ap? Select error: Invalid argument
> 
> …
> ap? Select error: Invalid argument
> ap? Segmentation fault: 11
> 
> It has the same behavior as the previous version of pil21.
> 
> Regards,
> Andras Pahi
> 
>> On 2021. Apr 15., at 12:51, Alexander Burger  wrote:
>> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
>>> Looks like I should do that.
>> 
>> Done!
>> 
>> Can somebody test on a Macintosh or other BSDs?
>> 
>> ☺/ A!ex
>> 
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi Andras,

> 
> /pil app/main.l -ap~main -'go 4040' +
> 6538 = 58885 48782252818959702~
> ap: !? (wait Ms T "Sd")
> Select error: Invalid argument
> ...
> It has the same behavior as the previous version of pil21.

Yeah, I thought about it, and came to the conclusion that today's change in
gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout is
seldom used, I think.

So what causes the above error?

It happens in 'listen' (line 94 in @lib/net.l):

   (de listen (Sd Ms)
  (loop
 (NIL (wait Ms T Sd))
 (T (accept Sd) @) ) )

"Select error" is issued by poll(). But which argument is ivalid?

Can you try to trace or debug?

Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen is
called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd().

Any idea?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi,

I grabbed the latest pil21.tgz and demoApp.tgz.
"pil @lib/test.l +" runs without errors.

On macOS I've got

/pil app/main.l -ap~main -'go 4040' +
6538 = 58885 48782252818959702~
ap: !? (wait Ms T "Sd")
Select error: Invalid argument
ap? Select error: Invalid argument
ap? Select error: Invalid argument
…
ap? Select error: Invalid argument
ap? Segmentation fault: 11

It has the same behavior as the previous version of pil21.

Regards,
Andras Pahi

> On 2021. Apr 15., at 12:51, Alexander Burger  wrote:
> 
> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
>> Looks like I should do that.
> 
> Done!
> 
> Can somebody test on a Macintosh or other BSDs?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

2021-04-15 Thread picolisp

> On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote:
>> That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is 
>> 49
>> days (as opposed to the 292 million years (292MY) in 64 bits).
>
> Not even that! For signed 32 bits it is only 24 days :(
>
> Should I change the design of waitFd() to use only 32 bits?
>
> âº/ A!ex

A workaround is to poll ceil(N/(2^32)) times. By the way what happens when
(timeout > 292MY)?

> The man page of poll() says "Specifying a negative value in timeout means an
> infinite timeout". -2 or any other negative number does no harm.

The OSX man page is different. Yes, only -1 means infinite timeout.

I'm also trying to fix the parser/repl but that would be on another thread.



-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
> Looks like I should do that.

Done!

Can somebody test on a Macintosh or other BSDs?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Thu, Apr 15, 2021 at 08:42:04AM +0200, Alexander Burger wrote:
> Should I change the design of waitFd() to use only 32 bits?

Looks like I should do that.

poll(2) is badly specified, using only int for the timeout. But we have to live
with that, there may be other ABIs (other BSDs?) which define 'int' as 32 bits.

So I could change waitFd() to use -1 internally if a maximal value of 24 days is
passed. This would mean that all relevant Lisp-level functions ('wait', 'sync',
'key' and readline input) may wait forever.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote:
> That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is 
> 49
> days (as opposed to the 292 million years (292MY) in 64 bits).

Not even that! For signed 32 bits it is only 24 days :(

Should I change the design of waitFd() to use only 32 bits?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

On Thu, Apr 15, 2021 at 08:07:21AM +0200, Andras Pahi wrote:
> Hi,
> 
> Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit.
> The pil21 demoApp does not work on macOS.

Thanks Andras!

That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is 49
days (as opposed to the 292 million years (292MY) in 64 bits).

— Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

Hi,

Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit.
The pil21 demoApp does not work on macOS.

pahihu

sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16
sizeof(void*) = 8


> On 2021. Apr 15., at 7:46, Alexander Burger  wrote:
> 
> In summary, the problem seems to be that 'int's on the Mac are only 32 bit. 
> But
> that would break many other things, no? Any other Mac users here? I thought
> pil21 runs on the Mac (?).
> 
> ☺/ A!ex

Re: Why do waitFd and gPoll use 292MY for timeout?

On Thu, Apr 15, 2021 at 07:46:35AM +0200, Alexander Burger wrote:
> Hi all,
> 
> I just stumbled across this mail in the archive. I have not received it, and 
> the
> sending e-mail address seems just "picolisp".
> 
> > picolisp Sun, 11 Apr 2021 15:05:25 -0700

Ah, that's all right! There is indeed a registered list member with that name :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

2021-04-14 Thread Alexander Burger

Hi all,

I just stumbled across this mail in the archive. I have not received it, and the
sending e-mail address seems just "picolisp".

> picolisp Sun, 11 Apr 2021 15:05:25 -0700
>
> I am trying to fix infinite select errors about 292MY.
>
> On my mac (int)9223372036854775807 == -1 which means no timeout.

This is strange! The number 292MY is the biggest *positive* 64-bit number. A
call to waitFd() is compiled to e.g.:

   call i64 @waitFd(i64 %0, i32 -1, i64 9223372036854775807)

Does this mean the Mac uses only the lowest 32 bits?


Also, -1 does *not* mean "no timeout". It means infinite timeout.


> Why not simply use -1?

This would not work, because waitFd() compares the value to all other timeouts
in the task list. So it needs a big positive number.


> When Ms decrement to 9223372036854775806, (int)timeout becomes -2 which is 
> less
> than -1, then poll() returns EINVAL.

This is equally strange! The man page of poll() says "Specifying a negative
value in timeout means an infinite timeout". -2 or any other negative number
does no harm.


> src/lib.c: warning: '&' within '|' [-Wbitwise-op-parentheses]

I hate compilers treating me like a child! ;)


In summary, the problem seems to be that 'int's on the Mac are only 32 bit. But
that would break many other things, no? Any other Mac users here? I thought
pil21 runs on the Mac (?).

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

pil21: Why do waitFd and gPoll use 292MY for timeout?

2021-04-11 Thread picolisp

I am trying to fix infinite select errors about 292MY.

src/lib.c:
int32_t gPoll(struct pollfd *fds, int32_t nfds, int64_t timeout) {
   if (timeout == 9223372036854775807) {  // 292MY
  int i = nfds;
  do
 if (--i < 0)
return 0;
  while (fds[i].fd < 0);
   }
   return (int32_t)poll(fds, (nfds_t)nfds, (int)timeout);
}

On my mac (int)9223372036854775807 == -1 which means no timeout. Why not
simply use -1?

src/io.l:
(de i64 waitFd (Exe (i32 . Fd) (i64 . Ms))
   ...
(and
   (gt0 Ms)
   (lt0 (dec 'Ms Dif))
   (setq Ms 0) )
(setq Tim Now) )
   ... )

When Ms decrement to 9223372036854775806, (int)timeout becomes -2 which is
less than -1, then poll() returns EINVAL.

In the meantime I found two compile warnings:

src/lib.c: warning: use of GNU ?: conditional expression extension
ffi *ffiPrep(char *lib, char *fun, int64_t lst) {
   if (ffi_prep_cif(>cif, FFI_DEFAULT_ABI, nargs, rtype, p->args)
== FFI_OK  &&
 (p->fun = dlsym(lib ?: RTLD_DEFAULT, fun)) )

src/lib.c: warning: '&' within '|' [-Wbitwise-op-parentheses]
int readyOut(struct pollfd *p) {
   if (p->fd < 0)
  return 0;
   p->fd = -1;
   return (p->revents & POLLOUT | POLLERR | POLLNVAL) != 0;
}

Please have a look. Thanks!



-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free

2020-05-18 Thread O.Hamann

On 16.05.20 12:42, Alexander Burger wrote:
> I can't help him ...

No, of course you can't, neither the community.

There were many posts here of the community which argued in a fair
manner to him,

but I think, one can't stop a sender like him. He was not able to
receive any more.

So don't worry, help for him is not in hand of software designers.

And we all here now enjoy the 'pure signal'*, I think.

---

*) (c) by pd   :-)




--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-16 Thread Alexander Burger

On Sat, May 16, 2020 at 05:06:31PM +0200, Alexander Shendi (Web.DE) wrote:
> Can't you simply bounce his mails? I'm afraid handing matters over to the 
> police isn't going to be effective. 

It is all not effective I believe. I just ignore it ...

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-16 Thread Alexander Shendi (Web.DE)

Can't you simply bounce his mails? I'm afraid handing matters over to the 
police isn't going to be effective. 

Am 16. Mai 2020 12:42:17 MESZ schrieb Alexander Burger :
>On Sun, May 10, 2020 at 04:06:47PM +0200, pd wrote:
>> Thanks Alex for your absolute amazing and beautiful work and
>dedication.
>
>Thank you all too! For me it is a lot of fun :)
>
>
>> Fortunately noise is over and list returns to pure signal.
>
>Yes indeed!
>
>Unfortunately for me it is not over. Guido keeps on attacking me by PM.
>He calls
>me "very very stupid to use LLVM", and the members of this thread
>"complete
>idiots" ("Volldeppen").
>
>I can't help him ...
>
>☺/ A!ex
>
>-- 
>UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
You have zero privacy anyway. Get over it.

Scott McNealy 1999

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-16 Thread pd

Nice to hear is fun for you, for me is fun to use picolisp and also this
list where you are do accesible and kind, it's a real privilege!

Sad to know of that bulling, usually the better is simply ignore him but
sometimes it's not enough. Hope this stop quickly

Regards

El sáb., 16 may. 2020 12:47, Alexander Burger 
escribió:

> On Sun, May 10, 2020 at 04:06:47PM +0200, pd wrote:
> > Thanks Alex for your absolute amazing and beautiful work and dedication

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-16 Thread George-Phillip Orais

Wow that guy is really pain in the ass.. sorry about that Alex, is it
possible to report him to the authorities for cyber-bullying? not sure of
the right term..

On Sat, May 16, 2020 at 7:47 PM Alexander Burger 
wrote:

> On Sun, May 10, 2020 at 04:06:47PM +0200, pd wrote:
> > Thanks Alex for your absolute amazing and beautiful work and dedication

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-16 Thread Alexander Burger

On Sun, May 10, 2020 at 04:06:47PM +0200, pd wrote:
> Thanks Alex for your absolute amazing and beautiful work and dedication.

Thank you all too! For me it is a lot of fun :)

> Fortunately noise is over and list returns to pure signal.

Yes indeed!

Unfortunately for me it is not over. Guido keeps on attacking me by PM. He calls
me "very very stupid to use LLVM", and the members of this thread "complete
idiots" ("Volldeppen").

I can't help him ...

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-10 Thread pd

Thanks Alex for your absolute amazing and beautiful work and dedication.

Fortunately noise is over and list returns to pure signal.

El vie., 8 may. 2020 0:15, David Bloom  escribió:

> FWIW I have been enjoying a fantastic feature of e-mail, FILTERS!
>
> Thanks Alex and community for your work, your examples, your help when
> someone posts to the list, and most of all for being sane voices in a less
> than sane world.
>
> On Thu, May 7, 2020 at 3:52 PM  wrote:
>
>> On Wed, 06 May 2020 17:02 -04:00, Brian Cleary wrote:
>> > It's the end of an error.
>>
>> This was my favorite.  hehe.
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-07 Thread David Bloom

FWIW I have been enjoying a fantastic feature of e-mail, FILTERS!

Thanks Alex and community for your work, your examples, your help when
someone posts to the list, and most of all for being sane voices in a less
than sane world.

On Thu, May 7, 2020 at 3:52 PM  wrote:

> On Wed, 06 May 2020 17:02 -04:00, Brian Cleary wrote:
> > It's the end of an error.
>
> This was my favorite.  hehe.
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-07 Thread rick

On Wed, 06 May 2020 17:02 -04:00, Brian Cleary wrote:
> It's the end of an error.

This was my favorite.  hehe.

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread r cs

Alex (and friends):

Thank you for the truly beautiful work that you share with us!

8-)
rcs

On Wed, May 6, 2020 at 3:41 PM Alexander Burger  wrote:

> Hi Guido,
>
> On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote:
> > Perhaps you *all* learn, what a JIT compiler really is, in difference
> > to a AOT Ahead of Time Compiler.
> >
> > https://en.wikipedia.org/wiki/Just-in-time_compilation
> >
> > Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
> > LLVM IR translator) does.
> >
> > If this is really the case, it promise, i say 'goodbye' from PicoLisp
> > mailing list!!! I promise!
> >
> > Alex?
>
> Sorry, I'd love to, but I have no idea what you are talking about. PicoLisp
> should not generate its code?
>
> — Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Brian Cleary

It's the end of an error.

On Wed, May 6, 2020 at 1:13 PM Karol Drożak  wrote:

> Thank God!...
>
> śr., 6 maj 2020, 21:53 użytkownik Wojciech Gac  > napisał:
>
>> That's all folks. ;)
>>
>> On Wed, May 6, 2020 at 9:41 PM Alexander Burger 
>> wrote:
>>
>>> Hi Guido,
>>>
>>> On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote:
>>> > Perhaps you *all* learn, what a JIT compiler really is, in difference
>>> > to a AOT Ahead of Time Compiler.
>>> >
>>> > https://en.wikipedia.org/wiki/Just-in-time_compilation
>>> >
>>> > Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
>>> > LLVM IR translator) does.
>>> >
>>> > If this is really the case, it promise, i say 'goodbye' from PicoLisp
>>> > mailing list!!! I promise!
>>> >
>>> > Alex?
>>>
>>> Sorry, I'd love to, but I have no idea what you are talking about.
>>> PicoLisp
>>> should not generate its code?
>>>
>>> — Alex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Karol Drożak

Thank God!...

śr., 6 maj 2020, 21:53 użytkownik Wojciech Gac 
napisał:

> That's all folks. ;)
>
> On Wed, May 6, 2020 at 9:41 PM Alexander Burger 
> wrote:
>
>> Hi Guido,
>>
>> On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote:
>> > Perhaps you *all* learn, what a JIT compiler really is, in difference
>> > to a AOT Ahead of Time Compiler.
>> >
>> > https://en.wikipedia.org/wiki/Just-in-time_compilation
>> >
>> > Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
>> > LLVM IR translator) does.
>> >
>> > If this is really the case, it promise, i say 'goodbye' from PicoLisp
>> > mailing list!!! I promise!
>> >
>> > Alex?
>>
>> Sorry, I'd love to, but I have no idea what you are talking about.
>> PicoLisp
>> should not generate its code?
>>
>> — Alex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Wojciech Gac

That's all folks. ;)

On Wed, May 6, 2020 at 9:41 PM Alexander Burger  wrote:

> Hi Guido,
>
> On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote:
> > Perhaps you *all* learn, what a JIT compiler really is, in difference
> > to a AOT Ahead of Time Compiler.
> >
> > https://en.wikipedia.org/wiki/Just-in-time_compilation
> >
> > Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
> > LLVM IR translator) does.
> >
> > If this is really the case, it promise, i say 'goodbye' from PicoLisp
> > mailing list!!! I promise!
> >
> > Alex?
>
> Sorry, I'd love to, but I have no idea what you are talking about. PicoLisp
> should not generate its code?
>
> — Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Hi Guido,

On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote:
> Perhaps you *all* learn, what a JIT compiler really is, in difference
> to a AOT Ahead of Time Compiler.
> 
> https://en.wikipedia.org/wiki/Just-in-time_compilation
> 
> Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
> LLVM IR translator) does.
> 
> If this is really the case, it promise, i say 'goodbye' from PicoLisp
> mailing list!!! I promise!
> 
> Alex?

Sorry, I'd love to, but I have no idea what you are talking about. PicoLisp
should not generate its code?

— Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Wilhelm Fitzpatrick


On 5/6/20 11:35 AM, Guido Stepken wrote:


If this is really the case, it promise, i say 'goodbye' from PicoLisp
mailing list!!! I promise!

Oh, Guido, please don't make promises you can't keep 藍

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Christophe Gragnic

On Wed, May 6, 2020 at 3:11 PM John Duncan  wrote:
>
> Just wanted to tell you how much I appreciate your work. I hope you find a 
> blowhard like Guido amusing and not too irritating. I get the impression he’s 
> hardly written a line of code in his life, and that was probably in Java.

Just wanted to tell you how much I appreciate your three sentences above.
A few days ago I wanted to answer Guido and tell him what I thought,
but your protocol is much more interesting.
At least I got that from this story.

chri

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Perhaps you *all* learn, what a JIT compiler really is, in difference
to a AOT Ahead of Time Compiler.

https://en.wikipedia.org/wiki/Just-in-time_compilation

Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to
LLVM IR translator) does.

If this is really the case, it promise, i say 'goodbye' from PicoLisp
mailing list!!! I promise!

Alex?

This then this would be the biggest waste of time of all times.

Am Mi., 6. Mai 2020 um 19:29 Uhr schrieb John Duncan :
>
> Another benefit of llvm is you get their dataflow analysis and optimization
> for free, on the myriad ARM and x64 microarchitectures as optimized as you
> like. That is harder to do in custom abstract assembly, as you’d have to
> maintain a little zoo of targets.
>
> On Wed, May 6, 2020 at 13:08  wrote:
>
> > > On 06.05.20 18:42, John Duncan wrote:
> > > Picolisp is interpreted. Even the llvm version is just creating an
> > > interpreter. There is no JIT.
> > Exactly!
> >
> > Guido, you should really stop talking about things you so obviously have
> > no understanding of.
> > There is NO COMPILING when executing program written in PicoLisp. Nowhere

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread John Duncan

Another benefit of llvm is you get their dataflow analysis and optimization
for free, on the myriad ARM and x64 microarchitectures as optimized as you
like. That is harder to do in custom abstract assembly, as you’d have to
maintain a little zoo of targets.

On Wed, May 6, 2020 at 13:08  wrote:

> > On 06.05.20 18:42, John Duncan wrote:
> > Picolisp is interpreted. Even the llvm version is just creating an
> > interpreter. There is no JIT.
> Exactly!
>
> Guido, you should really stop talking about things you so obviously have
> no understanding of.
> There is NO COMPILING when executing program written in PicoLisp. Nowhere

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread andreas

> On 06.05.20 18:42, John Duncan wrote:
> Picolisp is interpreted. Even the llvm version is just creating an
> interpreter. There is no JIT.
Exactly!

Guido, you should really stop talking about things you so obviously have
no understanding of.
There is NO COMPILING when executing program written in PicoLisp. Nowhere.

> Since the AST (Abstract Syntax Tree) in any Lisp is changing all the
> time, the JIT engine *has to* post-jit continuously to keep up the
> full execution speed.
> That's what will give pil21 a real performance boost over over any
> 'static compiled' implementation. 
Wrong. PicoLisp is having Fexpr's (in opposition to Macros), and Fexpr's
can be impossible to compile at all.
pil21 is not about performance, but compatibility. pil21 is expected to
even run a bit slower then the current amd64 ASM implementation.

The core principles of PicoLisp are simplicity and practicality - raw
speed is not the goal, optimizing developer time is.

- beneroth



--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Joh-Tob Schäg






Ursprüngliche Nachricht  
Von: gstep...@gmail.com
Gesendet: 6. Mai 2020 17:36
An: picolisp@software-lab.de
Antworten: picolisp@software-lab.de
Betreff: Re: Do free Open Source Foundation's Software Stacks fall under US 
Export Law?


Am Mittwoch, 6. Mai 2020 schrieb Joh-Tob Schäg :

>Each one perhaps 50 pages long, that need to be adapted for supporting new CPU 
>architecture.


Exactly. 


>> Alex wrote he is tired of having to write meta assembler code for each 
>> platform. I doubt that will be better if has to use someone else's Meta 
>> assembler. Also LuaJIT does not target RISC-V.

> That's true so far. Though there a a couple of billion RISC-V cpus out there 
> now.
And that's what matters to Alex.


> Target LLVM IR means porting it once and being able to target anything which 
> has a translator.

>> And since when doesn't your C version of Picolisp compile on iOS? 
>> Objective-C is a superset of C with parts of Smalltalk.
>
> You seem really ignorant. Are you unaware that pil32/emu/mini have less 
> features than pil64 and are slower too due to overhead/resrictions used by C?

Is slower speed really an issue with pilbox GUI? Certainly not!

> Also the size of LLVM doesn't matter since it is only necessary when 
> compiling the binary. You can likely download binaries Alex built just as you 
> can do.

> "Compiling the binary" is funny  pil21, sitting on top of LLVM JIT engine 
> is post JIT'ing all the time during runtime. That thing is profiling and self 
> optimizing code while running! See HotSpot JIT Engine concepts: 
> https://en.wikipedia.org/wiki/HotSpot


BULLSHIT. Atleast as far as i can read the source:
https://github.com/picolisp/pil21/blob/master/src/lib/llvm.l 
It is just dumping human readable LLVM-IR into a file which receives an ajead 
of time compilation pass where it compiles the Picolisp language primitives for 
the interpreter

> Starting interpreted, then stepwise compiling and replacing inner loops with 
> machine code, outer loops, ... ? Starting slow, modern JIT engines are 
> getting faster while running. Google V8 Javascript compiler is also working 
> this way. That's why 'warm up' phase is often mentioned with benchmarks: 
> https://www.google.com/search?q=llvm+warm+up+phase


You are plain wrong. LLVM can be used as AoT compiler too without anything 
being a JIT. In fact the most common use case for LLVM is as an ahead-of-time 
(AOT) compiler for a language.

> This is not different than Dynasm depending on LUA. Picolisp does not touch 
> most LLVM code. It just needs the assembler part of it. Translating LLVM-IR 
> to what ever you want is not that hard if you don't want to use LLVM and you 
> can audit the resulting ASM.


> I am not reviewing or auditing 3 million lines of LLVM in my life. Apart from 
> that, China market falls flat now because of US export sanctions.


Congrats than stay on the old pil64 or emu, audit the LLVM-IR assembler, write 
your own LLVM-IR assembler.


Also stop the "China LLVM" talking point. Export control can't apply to code. 
The PGP case showed that ages ago and even if it does, we Europeans don't have 
to care about American export sanctions. As long as the code makes it to Europe 
it can end in China. 

> Wrong business strategy for Germany to use US toolchains any longer.


If you believe so.PԔ � )mX�����zV�u�.n7�

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread John Duncan

Picolisp is interpreted. Even the llvm version is just creating an
interpreter. There is no JIT.

On Wed, May 6, 2020 at 12:36 Guido Stepken  wrote:

> Am Mittwoch, 6. Mai 2020 schrieb :
>
> > Read Wikipedia:
> >
> > LLVM allows code to be compiled statically, as it is under the
> traditional GCC system, or left for late-compiling from the IR to machine
> code via just-in-time compilation (JIT)
>
> Wikipedia might have missed the chapter: "Extreme Laziness - Using Compile
> Callbacks to JIT from ASTs".
>
> Since the AST (Abstract Syntax Tree) in any Lisp is changing all the time,
> the JIT engine *has to* post-jit continuously to keep up the full execution
> speed.
>
> That's what will give pil21 a real performance boost over over any 'static
> compiled' implementation.
>
> Means: PicoLisp will continuously check its own AST for changes (diff) and
> then ASAP recompile what's necessary in the background on a second CPU.
>
> But that also means: pil21 "binary" size will become much larger, since it
> will contain the processor specific ASTtoMachine Code parts.
>
> But, indeed, you can also use LLVM and Clang to compile the C version of
> Picolisp as usual, 'statically'. But that's almost pure nonsense, gives you
> no real advantage over e.g. GCC .
>
> You may also compile PicoLisp C version on ployglot (many programming
> languages in one source) GraalVM (Truffle) and observe, how PicoLisp gets
> faster and faster after a certain warm up time. GraalVM (Truffle) is same
> HotSpot post JIT optimization concept.
>
> Have fun!
>
-- 
John Duncan

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Am Mittwoch, 6. Mai 2020 schrieb :

> Read Wikipedia:
>
> LLVM allows code to be compiled statically, as it is under the
traditional GCC system, or left for late-compiling from the IR to machine
code via just-in-time compilation (JIT)

Wikipedia might have missed the chapter: "Extreme Laziness - Using Compile
Callbacks to JIT from ASTs".

Since the AST (Abstract Syntax Tree) in any Lisp is changing all the time,
the JIT engine *has to* post-jit continuously to keep up the full execution
speed.

That's what will give pil21 a real performance boost over over any 'static
compiled' implementation.

Means: PicoLisp will continuously check its own AST for changes (diff) and
then ASAP recompile what's necessary in the background on a second CPU.

But that also means: pil21 "binary" size will become much larger, since it
will contain the processor specific ASTtoMachine Code parts.

But, indeed, you can also use LLVM and Clang to compile the C version of
Picolisp as usual, 'statically'. But that's almost pure nonsense, gives you
no real advantage over e.g. GCC .

You may also compile PicoLisp C version on ployglot (many programming
languages in one source) GraalVM (Truffle) and observe, how PicoLisp gets
faster and faster after a certain warm up time. GraalVM (Truffle) is same
HotSpot post JIT optimization concept.

Have fun!

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread andreas


On 06.05.20 17:29, Guido Stepken wrote:
> > Also the size of LLVM doesn't matter since it is only necessary when
> compiling the binary. You can likely download binaries Alex built just
> as you can do.
>
> "Compiling the binary" is funny  pil21, sitting on top of LLVM JIT
> engine is post JIT'ing all the time during runtime. That thing is
> profiling and self optimizing code while running! See HotSpot JIT
> Engine concepts: https://en.wikipedia.org/wiki/HotSpot
>
Read Wikipedia:

> LLVM allows code to be compiled statically, as it is under the
> traditional GCC system, or left for late-compiling from the IR to
> machine code via just-in-time compilation
> <https://en.wikipedia.org/wiki/Just-in-time_compilation> (JIT)
pil21 is of course statically compiled, one time, resulting in a binary
you can dissect and analyze.
There is no reason for pil21 to make use of JIT.

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Am Mittwoch, 6. Mai 2020 schrieb Joh-Tob Schäg :
>
>> Sigh! How often have I told here that the main purpose of pil21 is
portability?
> Do you see any portablity problems:
> https://luajit.org/luajit.html
> iOS obviously *is* supported. Tons of games are using LuaJIT on all kinds
of platforms. Of course, always with DYNASM as JIT IR below.
>
> LUAJIT still requires cpu specific headers as you can see here:
https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_asm_x86.h

Certainly! But there are many of them for plenty of different CPUs:

https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_asm_mips.h
https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_asm_ppc.h
https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_asm_arm64.h

Each one perhaps 50 pages long, that need to be adapted for supporting new
CPU architecture.

>
> Alex wrote he is tired of having to write meta assembler code for each
platform. I doubt that will be better if has to use someone else's Meta
assembler. Also LuaJIT does not target RISC-V.

That's true so far. Though there a a couple of billion RISC-V cpus out
there now.


> Target LLVM IR means porting it once and being able to target anything
which has a translator.

>> And since when doesn't your C version of Picolisp compile on iOS?
Objective-C is a superset of C with parts of Smalltalk.
>
> You seem really ignorant. Are you unaware that pil32/emu/mini have less
features than pil64 and are slower too due to overhead/resrictions used by
C?

Is slower speed really an issue with pilbox GUI? Certainly not!

> Also the size of LLVM doesn't matter since it is only necessary when
compiling the binary. You can likely download binaries Alex built just as
you can do.

"Compiling the binary" is funny  pil21, sitting on top of LLVM JIT
engine is post JIT'ing all the time during runtime. That thing is profiling
and self optimizing code while running! See HotSpot JIT Engine concepts:
https://en.wikipedia.org/wiki/HotSpot

Starting interpreted, then stepwise compiling and replacing inner loops
with machine code, outer loops, ... ? Starting slow, modern JIT engines are
getting faster while running. Google V8 Javascript compiler is also working
this way. That's why 'warm up' phase is often mentioned with benchmarks:
https://www.google.com/search?q=llvm+warm+up+phase

> This is not different than Dynasm depending on LUA. Picolisp does not
touch most LLVM code. It just needs the assembler part of it. Translating
LLVM-IR to what ever you want is not that hard if you don't want to use
LLVM and you can audit the resulting ASM.

I am not reviewing or auditing 3 million lines of LLVM in my life. Apart
from that, China market falls flat now because of US export sanctions.

Reminder: China is double the size of Europe+USA together. Of course, our
Chinese friends are is looking for alternatives from outside the US.

Wrong business strategy for Germany to use US toolchains any longer.

Best regards, Guido Stepken

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Certainly Fennel only a proof of concept. But it's easy to understand, you
can add lists and other things within just a few lines by using Lua
primitives, which are Lisp like.

Same with Common Lisp and Scheme. When you read through Common Lisp
language definition, it's a huge book, language definition of Scheme,
consequently based on S-expressions, is just a few pages long.

What brings me to topic of COMPLEXITY. PicoLisp IMHO is feature complete,
is no more complex, than a human can understand and absorb within a couple
of weeks to become a highly efficient and fast problem solver.

And from security point of view, PicoLisp is small enough to get completely
security reviewed by a team with just a few weeks. Today, we have automated
tools doing that in a couple of hours or minutes: See e.g. gcc -fanalyzer
function. A godsend! ;-)

Have fun!



Am Mittwoch, 6. Mai 2020 schrieb Edgaras Šeputis :
> I'll note that fennel seems like severely sub par lisp, not even really
supporting lists... Though there are others, lumen and urn for luaJIT. Not
sure why you keep mentioning fennel, while it seems most popular somehow,
but it is also most clojure like and with seemingly boneheaded list
handling.
>
> On Wed, May 6, 2020 at 3:51 PM Guido Stepken  wrote:
>>
>> Am Mittwoch, 6. Mai 2020 schrieb Alexander Burger :
>> > On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>> >> Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
comparison
>> >> to LLVM), more portable. He's from Munich.
>> >
>> > Useless.
>>
>> Ah, really?
>>
>> > Sigh! How often have I told here that the main purpose of pil21 is
portability?
>>
>> Do you see any portablity problems:
>>
>> https://luajit.org/luajit.html
>>
>> iOS obviously *is* supported. Tons of games are using LuaJIT on all
kinds of platforms. Of course, always with DYNASM as JIT IR below.
>>
>> > I need it to build PilBox on iOS, and to support RISC-V architectures.
In fact
>> > *all* 64-bit architectures, as I got tired of porting pil64.
>> >
>> > And I need it NOW!! Not *perhaps* in ten years.
>>
>> You could have had yesterday. There already is a Lisp on DYNASM, but -
written in Lua: https://fennel-lang.org/
>>
>> Easy to follow that example to get the DYNASM IR right.
>>
>> > Also, please shut up with WebAssembly. I need something running on
POSIX for
>> > server side applications. Something in the browser is as useful for me
as
>> > chewing gum for my cat.
>>
>> You simply do never listen. Webassembly programs *do* run server side:
>>
>>
https://wwwinfoworld.com/article/3411496/wasmer-takes-webassembly-server-side.html
>>
>> Sorry Alex, but sometimes you are your own labyrith not seeing the exit.
>>
>> And since when doesn't your C version of Picolisp compile on iOS?
Objective-C is a superset of C with parts of Smalltalk.
>>
>> Have fun!
>>
>> > — Alex
>> >
>> > --
>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>> >

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

My friend! The political wind has massively changed from US side. We cannot
go on doing business like 5 months and 6 days ago.

You brains simply haven't noticed yet ...

Am Mittwoch, 6. Mai 2020 schrieb Alfonso Villén :
> Hello Guido,
>
>> Alex, go on using LLVM. See you in Guantanamo. (Remember: Meng Wanzhou >
was caught in Canada with US warrant).
>>
>> Unbelievable ignorance
>
> I don't understand what makes you think that Alex is an ignorant.
>
> First of all, I want to thank Alex as John already did. I don't know Alex
and I'm only a hobby programmer (with limited experience in several
languages), but from his work and from the experience and savoir-faire that
that work emits, I can see that he made (and is still making) wise
decisions.
>
> Picolisp is useful for me, but for Alex, it's a way of life. So if he has
choosen LLVM, he must have good reasons for this. Not a random or ignorant
choice.
>
> If you think another way to develop pil21 will be better and Picolisp
really means that much to you, then please, be constructive and help. You
have experience with DynASM, Web Assembly or whatever? You know Picolisp so
deeply that you can build it from scratch using other toolchains? Then show
how *you* would do it, give directions, show some code and offer your
collaboration. Unless you go that way, all you say is blah blah and you're
saying it in a quite unrespectful and selfish manner, by the way. For now,
I'll trust Alex more than I trust you.
>
> Regards,
>
> Alfonso
>
> On 6/5/20 15:35, Guido Stepken wrote:
>
> I don't discourage him. I present facts. LLVM contains plenty of AI code,
especially for generating code for NVIDIA chips.
>
> Since January 1st there are export restrictions for AI code to China now.
>
>
https://www.reuters.com/article/us-usa-artificial-intelligence/u-s-government-limits-exports-of-artificial-intelligence-software-idUSKBN1Z21PT
>
> Means: No use of LLVM within China any longer. No use of pil21 with LLVM
JIT in China. Same for many other countries.
>
> Whole world now is rethinking use of US software stacks in general.
>
> Again: "Keep away from US Software Stacks!!!"
>
> Alex, go on using LLVM. See you in Guantanamo. (Remember: Meng Wanzhou
was caught in Canada with US warrant).
>
> Unbelievable ignorance
>
> Am Mittwoch, 6. Mai 2020 schrieb George-Phillip Orais <
oraisgeorgephil...@gmail.com>:
>> Hi Guido,
>> Thank you for sharing your insights here, I have fun reading them.
>> But please respect Alex decision in using LLVM for pil21, its his choice
and its his programming language, so please stop discouraging him.
>>
>> BR,
>> Geo
>>
>>
>>
>> On Wed, May 6, 2020 at 10:12 PM John Duncan 
wrote:
>>>
>>> Hey Alex,
>>> Just wanted to tell you how much I appreciate your work. I hope you
find a blowhard like Guido amusing and not too irritating. I get the
impression he’s hardly written a line of code in his life, and that was
probably in Java.
>>> Take care!
>>> John
>>> On Wed, May 6, 2020 at 07:59 Alexander Burger 
wrote:
>>>>
>>>> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>>>> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
comparison
>>>> > to LLVM), more portable. He's from Munich.
>>>>
>>>> Useless.
>>>>
>>>> Sigh! How often have I told here that the main purpose of pil21 is
portability?
>>>> I need it to build PilBox on iOS, and to support RISC-V architectures.
In fact
>>>> *all* 64-bit architectures, as I got tired of porting pil64.
>>>>
>>>> And I need it NOW!! Not *perhaps* in ten years.
>>>>
>>>> Also, please shut up with WebAssembly. I need something running on
POSIX for
>>>> server side applications. Something in the browser is as useful for me
as
>>>> chewing gum for my cat.
>>>>
>>>> — Alex
>>>>
>>>> --
>>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>> --
>>> John Duncan

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Joh-Tob Schäg

> Sigh! How often have I told here that the main purpose of pil21 is 
> portability?
Do you see any portablity problems:
https://luajit.org/luajit.html
iOS obviously *is* supported. Tons of games are using LuaJIT on all kinds of 
platforms. Of course, always with DYNASM as JIT IR below.

LUAJIT still requires cpu specific headers as you can see here: 
https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_asm_x86.h

Alex wrote he is tired of having to write meta assembler code for each 
platform. I doubt that will be better if has to use someone else's Meta 
assembler. Also LuaJIT does not target RISC-V.

Target LLVM IR means porting it once and being able to target anything which 
has a translator.

> And since when doesn't your C version of Picolisp compile on iOS? Objective-C 
> is a superset of C with parts of Smalltalk.

You seem really ignorant. Are you unaware that pil32/emu/mini have less 
features than pil64 and are slower too due to overhead/resrictions used by C?

Also the size of LLVM doesn't matter since it is only necessary when compiling 
the binary. You can likely download binaries Alex built just as you can do.
This is not different than Dynasm depending on LUA. Picolisp does not touch 
most LLVM code. It just needs the assembler part of it. Translating LLVM-IR to 
what ever you want is not that hard if you don't want to use LLVM and you can 
audit the resulting ASM.

TL;DR: Shut up until you can show the code. This also applies to your "I did 
some cool distributed pilog thing" if you write some cool software but can't 
share it, don't talk about it on the mailing list.

Ursprüngliche Nachricht  
Von: gstep...@gmail.com
Gesendet: 6. Mai 2020 14:51
An: picolisp@software-lab.de
Antworten: picolisp@software-lab.de
Betreff: Re: Do free Open Source Foundation's Software Stacks fall under US 
Export Law?

Am Mittwoch, 6. Mai 2020 schrieb Alexander Burger :
> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>> Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in comparison
>> to LLVM), more portable. He's from Munich.
>
> Useless.

Ah, really?

> Sigh! How often have I told here that the main purpose of pil21 is 
> portability?

Do you see any portablity problems:

https://luajit.org/luajit.html

iOS obviously *is* supported. Tons of games are using LuaJIT on all kinds of 
platforms. Of course, always with DYNASM as JIT IR below.

> I need it to build PilBox on iOS, and to support RISC-V architectures. In fact
> *all* 64-bit architectures, as I got tired of porting pil64.
>
> And I need it NOW!! Not *perhaps* in ten years.

You could have had yesterday. There already is a Lisp on DYNASM, but - written 
in Lua: https://fennel-lang.org/

Easy to follow that example to get the DYNASM IR right.

> Also, please shut up with WebAssembly. I need something running on POSIX for
> server side applications. Something in the browser is as useful for me as
> chewing gum for my cat.

You simply do never listen. Webassembly programs *do* run server side:

https://www.infoworld.com/article/3411496/wasmer-takes-webassembly-server-side.html

Sorry Alex, but sometimes you are your own labyrith not seeing the exit.

And since when doesn't your C version of Picolisp compile on iOS? Objective-C 
is a superset of C with parts of Smalltalk.

Have fun!

> — Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Edgaras Šeputis

I'll note that fennel seems like severely sub par lisp, not even really
supporting lists... Though there are others, lumen and urn for luaJIT. Not
sure why you keep mentioning fennel, while it seems most popular somehow,
but it is also most clojure like and with seemingly boneheaded list
handling.

On Wed, May 6, 2020 at 3:51 PM Guido Stepken  wrote:

> Am Mittwoch, 6. Mai 2020 schrieb Alexander Burger :
> > On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
> >> Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
> comparison
> >> to LLVM), more portable. He's from Munich.
> >
> > Useless.
>
> Ah, really?
>
> > Sigh! How often have I told here that the main purpose of pil21 is
> portability?
>
> Do you see any portablity problems:
>
> https://luajit.org/luajit.html
>
> iOS obviously *is* supported. Tons of games are using LuaJIT on all kinds
> of platforms. Of course, always with DYNASM as JIT IR below.
>
> > I need it to build PilBox on iOS, and to support RISC-V architectures.
> In fact
> > *all* 64-bit architectures, as I got tired of porting pil64.
> >
> > And I need it NOW!! Not *perhaps* in ten years.
>
> You could have had yesterday. There already is a Lisp on DYNASM, but -
> written in Lua: https://fennel-lang.org/
>
> Easy to follow that example to get the DYNASM IR right.
>
> > Also, please shut up with WebAssembly. I need something running on POSIX
> for
> > server side applications. Something in the browser is as useful for me as
> > chewing gum for my cat.
>
> You simply do never listen. Webassembly programs *do* run server side:
>
>
> https://www.infoworld.com/article/3411496/wasmer-takes-webassembly-server-side.html
>
> Sorry Alex, but sometimes you are your own labyrith not seeing the exit.
>
> And since when doesn't your C version of Picolisp compile on iOS?
> Objective-C is a superset of C with parts of Smalltalk.
>
> Have fun!
>
> > — Alex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Alfonso Villén

Hello Guido,

> Alex, go on using LLVM. See you in Guantanamo. (Remember: Meng 
Wanzhou > was caught in Canada with US warrant).

>
> Unbelievable ignorance

I don't understand what makes you think that Alex is an ignorant.

First of all, I want to thank Alex as John already did. I don't know 
Alex and I'm only a hobby programmer (with limited experience in several 
languages), but from his work and from the experience and savoir-faire 
that that work emits, I can see that he made (and is still making) wise 
decisions.

Picolisp is useful for me, but for Alex, it's a way of life. So if he 
has choosen LLVM, he must have good reasons for this. Not a random or 
ignorant choice.

If you think another way to develop pil21 will be better and Picolisp 
really means that much to you, then please, be constructive and help. 
You have experience with DynASM, Web Assembly or whatever? You know 
Picolisp so deeply that you can build it from scratch using other 
toolchains? Then show how *you* would do it, give directions, show some 
code and offer your collaboration. Unless you go that way, all you say 
is blah blah and you're saying it in a quite unrespectful and selfish 
manner, by the way. For now, I'll trust Alex more than I trust you.

Regards,

Alfonso

On 6/5/20 15:35, Guido Stepken wrote:
I don't discourage him. I present facts. LLVM contains plenty of AI 
code, especially for generating code for NVIDIA chips.

Since January 1st there are export restrictions for AI code to China now.

https://www.reuters.com/article/us-usa-artificial-intelligence/u-s-government-limits-exports-of-artificial-intelligence-software-idUSKBN1Z21PT

Means: No use of LLVM within China any longer. No use of pil21 with 
LLVM JIT in China. Same for many other countries.

Whole world now is rethinking use of US software stacks in general.

Again: "Keep away from US Software Stacks!!!"

Alex, go on using LLVM. See you in Guantanamo. (Remember: Meng Wanzhou 
was caught in Canada with US warrant).

Unbelievable ignorance

Am Mittwoch, 6. Mai 2020 schrieb George-Phillip Orais 
mailto:orais.georgephil...@gmail.com>>:

> Hi Guido,
> Thank you for sharing your insights here, I have fun reading them.
> But please respect Alex decision in using LLVM for pil21, its his 
choice and its his programming language, so please stop discouraging him.

>
> BR,
> Geo
>
>
>
> On Wed, May 6, 2020 at 10:12 PM John Duncan <mailto:duncan.j...@gmail.com>> wrote:

>>
>> Hey Alex,
>> Just wanted to tell you how much I appreciate your work. I hope you 
find a blowhard like Guido amusing and not too irritating. I get the 
impression he’s hardly written a line of code in his life, and that 
was probably in Java.

>> Take care!
>> John
>> On Wed, May 6, 2020 at 07:59 Alexander Burger <mailto:a...@software-lab.de>> wrote:

>>>
>>> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>>> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in 
comparison

>>> > to LLVM), more portable. He's from Munich.
>>>
>>> Useless.
>>>
>>> Sigh! How often have I told here that the main purpose of pil21 is 
portability?
>>> I need it to build PilBox on iOS, and to support RISC-V 
architectures. In fact

>>> *all* 64-bit architectures, as I got tired of porting pil64.
>>>
>>> And I need it NOW!! Not *perhaps* in ten years.
>>>
>>> Also, please shut up with WebAssembly. I need something running on 
POSIX for
>>> server side applications. Something in the browser is as useful 
for me as

>>> chewing gum for my cat.
>>>
>>> — Alex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de 
<mailto:picolisp@software-lab.de>?subject=Unsubscribe

>>
>> --
>> John Duncan

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

PilBox, yes. Also one of your brilliant ideas ...

Something similar already exists since a couple of years ...
https://jasonette.com/, renamed to https://jasonelle.com/

Some Google guys picked up the idea and made FLUTTER: One code, two
binaries for Android and iOS. Dart Programming Language. Btw.: Works on
Linux Desktop too. Windows haven't tried, not available at the moment.

Also interesting: Draftbit built a highly sophisticated Cloud App Builder
around Flutter. http://draftbit.com

So, your brilliant ideas have become pretty widespread.

Have fun!

Best, Guido

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread Yiorgos [George] Adamopoulos

Also, I see no problem in, for example, Guido trying to prove the
point by making a PicoLisp clone in the runtime of his choice :) IIRC,
we already have the Ersatz (Java) port of picolisp.

On Wed, May 6, 2020 at 4:23 PM George-Phillip Orais
 wrote:
>
> Hi Guido,
>
> Thank you for sharing your insights here, I have fun reading them.
>
> But please respect Alex decision in using LLVM for pil21, its his choice and 
> its his programming language, so please stop discouraging him.
>
>
> BR,
> Geo
>
>
>
>
> On Wed, May 6, 2020 at 10:12 PM John Duncan  wrote:
>>
>> Hey Alex,
>>
>> Just wanted to tell you how much I appreciate your work. I hope you find a 
>> blowhard like Guido amusing and not too irritating. I get the impression 
>> he’s hardly written a line of code in his life, and that was probably in 
>> Java.
>>
>> Take care!
>>
>> John
>>
>> On Wed, May 6, 2020 at 07:59 Alexander Burger  wrote:
>>>
>>> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>>> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in comparison
>>> > to LLVM), more portable. He's from Munich.
>>>
>>> Useless.
>>>
>>> Sigh! How often have I told here that the main purpose of pil21 is 
>>> portability?
>>> I need it to build PilBox on iOS, and to support RISC-V architectures. In 
>>> fact
>>> *all* 64-bit architectures, as I got tired of porting pil64.
>>>
>>> And I need it NOW!! Not *perhaps* in ten years.
>>>
>>> Also, please shut up with WebAssembly. I need something running on POSIX for
>>> server side applications. Something in the browser is as useful for me as
>>> chewing gum for my cat.
>>>
>>> — Alex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>> --
>> John Duncan



-- 
keep raising the bar

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

I don't discourage him. I present facts. LLVM contains plenty of AI code,
especially for generating code for NVIDIA chips.

Since January 1st there are export restrictions for AI code to China now.

https://www.reuters.com/article/us-usa-artificial-intelligence/u-s-government-limits-exports-of-artificial-intelligence-software-idUSKBN1Z21PT

Means: No use of LLVM within China any longer. No use of pil21 with LLVM
JIT in China. Same for many other countries.

Whole world now is rethinking use of US software stacks in general.

Again: "Keep away from US Software Stacks!!!"

Alex, go on using LLVM. See you in Guantanamo. (Remember: Meng Wanzhou was
caught in Canada with US warrant).

Unbelievable ignorance

Am Mittwoch, 6. Mai 2020 schrieb George-Phillip Orais <
orais.georgephil...@gmail.com>:
> Hi Guido,
> Thank you for sharing your insights here, I have fun reading them.
> But please respect Alex decision in using LLVM for pil21, its his choice
and its his programming language, so please stop discouraging him.
>
> BR,
> Geo
>
>
>
> On Wed, May 6, 2020 at 10:12 PM John Duncan  wrote:
>>
>> Hey Alex,
>> Just wanted to tell you how much I appreciate your work. I hope you find
a blowhard like Guido amusing and not too irritating. I get the impression
he’s hardly written a line of code in his life, and that was probably in
Java.
>> Take care!
>> John
>> On Wed, May 6, 2020 at 07:59 Alexander Burger 
wrote:
>>>
>>> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>>> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
comparison
>>> > to LLVM), more portable. He's from Munich.
>>>
>>> Useless.
>>>
>>> Sigh! How often have I told here that the main purpose of pil21 is
portability?
>>> I need it to build PilBox on iOS, and to support RISC-V architectures.
In fact
>>> *all* 64-bit architectures, as I got tired of porting pil64.
>>>
>>> And I need it NOW!! Not *perhaps* in ten years.
>>>
>>> Also, please shut up with WebAssembly. I need something running on
POSIX for
>>> server side applications. Something in the browser is as useful for me
as
>>> chewing gum for my cat.
>>>
>>> — Alex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>> --
>> John Duncan

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread George-Phillip Orais

Hi Guido,

Thank you for sharing your insights here, I have fun reading them.

But please respect Alex decision in using LLVM for pil21, its his choice
and its his programming language, so please stop discouraging him.


BR,
Geo




On Wed, May 6, 2020 at 10:12 PM John Duncan  wrote:

> Hey Alex,
>
> Just wanted to tell you how much I appreciate your work. I hope you find a
> blowhard like Guido amusing and not too irritating. I get the impression
> he’s hardly written a line of code in his life, and that was probably in
> Java.
>
> Take care!
>
> John
>
> On Wed, May 6, 2020 at 07:59 Alexander Burger  wrote:
>
>> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
>> comparison
>> > to LLVM), more portable. He's from Munich.
>>
>> Useless.
>>
>> Sigh! How often have I told here that the main purpose of pil21 is
>> portability?
>> I need it to build PilBox on iOS, and to support RISC-V architectures. In
>> fact
>> *all* 64-bit architectures, as I got tired of porting pil64.
>>
>> And I need it NOW!! Not *perhaps* in ten years.
>>
>> Also, please shut up with WebAssembly. I need something running on POSIX
>> for
>> server side applications. Something in the browser is as useful for me as
>> chewing gum for my cat.
>>
>> — Alex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
> --
> John Duncan
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Hi John,

> Just wanted to tell you how much I appreciate your work. I hope you find a
> blowhard like Guido amusing and not too irritating. I get the impression
> he’s hardly written a line of code in his life, and that was probably in
> Java.

Thanks a lot John! :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread John Duncan

Hey Alex,

Just wanted to tell you how much I appreciate your work. I hope you find a
blowhard like Guido amusing and not too irritating. I get the impression
he’s hardly written a line of code in his life, and that was probably in
Java.

Take care!

John

On Wed, May 6, 2020 at 07:59 Alexander Burger  wrote:

> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
> > Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
> comparison
> > to LLVM), more portable. He's from Munich.
>
> Useless.
>
> Sigh! How often have I told here that the main purpose of pil21 is
> portability?
> I need it to build PilBox on iOS, and to support RISC-V architectures. In
> fact
> *all* 64-bit architectures, as I got tired of porting pil64.
>
> And I need it NOW!! Not *perhaps* in ten years.
>
> Also, please shut up with WebAssembly. I need something running on POSIX
> for
> server side applications. Something in the browser is as useful for me as
> chewing gum for my cat.
>
> — Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
-- 
John Duncan

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Am Mittwoch, 6. Mai 2020 schrieb Alexander Burger :
> On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
>> Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in
comparison
>> to LLVM), more portable. He's from Munich.
>
> Useless.

Ah, really?

> Sigh! How often have I told here that the main purpose of pil21 is
portability?

Do you see any portablity problems:

https://luajit.org/luajit.html

iOS obviously *is* supported. Tons of games are using LuaJIT on all kinds
of platforms. Of course, always with DYNASM as JIT IR below.

> I need it to build PilBox on iOS, and to support RISC-V architectures. In
fact
> *all* 64-bit architectures, as I got tired of porting pil64.
>
> And I need it NOW!! Not *perhaps* in ten years.

You could have had yesterday. There already is a Lisp on DYNASM, but -
written in Lua: https://fennel-lang.org/

Easy to follow that example to get the DYNASM IR right.

> Also, please shut up with WebAssembly. I need something running on POSIX
for
> server side applications. Something in the browser is as useful for me as
> chewing gum for my cat.

You simply do never listen. Webassembly programs *do* run server side:

https://www.infoworld.com/article/3411496/wasmer-takes-webassembly-server-side.html

Sorry Alex, but sometimes you are your own labyrith not seeing the exit.

And since when doesn't your C version of Picolisp compile on iOS?
Objective-C is a superset of C with parts of Smalltalk.

Have fun!

> — Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

On Wed, May 06, 2020 at 12:51:33PM +0200, Guido Stepken wrote:
> Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in comparison
> to LLVM), more portable. He's from Munich.

Useless.

Sigh! How often have I told here that the main purpose of pil21 is portability?
I need it to build PilBox on iOS, and to support RISC-V architectures. In fact
*all* 64-bit architectures, as I got tired of porting pil64.

And I need it NOW!! Not *perhaps* in ten years.

Also, please shut up with WebAssembly. I need something running on POSIX for
server side applications. Something in the browser is as useful for me as
chewing gum for my cat.

— Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Hi Alex!

Yes! -10 for using LLVM, that falls under US export restrictions (ECRA). AI
software is no longer allowed to export to e.g. China, since January 1st.

So if you have compiled-in a single line of LLVM code into pil21, you're in
real trouble now, because of pilog, which is certainly a kind of AI.

Use Mike's DYNASM JIT Engine. Better, faster, smaller (tiny, in comparison
to LLVM), more portable. He's from Munich.

Have fun!

Best regards, Guido

Am Mittwoch, 6. Mai 2020 schrieb Alexander Burger :
> On Wed, May 06, 2020 at 09:55:08AM +0200, Guido Stepken wrote:
>> Lisp, as functional language, should
>> better be implemented in a functional language
>
> Point for pil21 :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

On Wed, May 06, 2020 at 09:55:08AM +0200, Guido Stepken wrote:
> Lisp, as functional language, should
> better be implemented in a functional language

Point for pil21 :)

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

There are plenty of free implementations of Lisp language in Pascal, Modula
2/3, Oberon out there.

E.g. https://github.com/bobappleyard/pascal-lisp/blob/master/README

But all that makes no real sense. Lisp, as functional language, should
better be implemented in a functional language, such as Haskell or OCaml:

https://bernsteinbear.com/blog/lisp/00_fundamentals/

At the moment, we are working on a Linux (POSIX) Clone in OCaml
(European!!!). That has started with MirageOS, http://mirage.io
(European!!!)

All i can say is, that by moving everything to OCaml (as Operating System
and Cloud Application Server), (overall) memory footprint now is reduced by
a factor of 25 and speed went up factor 10. Network latencey went
tremendously down, thanks to a TCP/IP Stack implementation in OCaml.

Worth mentioning: Microsoft's F# is a 98% OCaml Clone. Ridiculous!

Picolisp runs on MirageOS ... Funny thing that is: Linux (UNIX) now is just
a (OCaml written) library. When compiling PicoLisp from C sources, you have
to #include that library. So, PicoLisp now directly is sitting on top of a
Hypervisor, an "EXO Kernel". Much faster than on Linux.

Hardware requirements, 800 servers with conventional "US Software Stacks"
(mostly Linux) have come down to 17. That was an eye-opener for me.

Have fun!

Best regards, Guido Stepken

Am Mittwoch, 6. Mai 2020 schrieb George-Phillip Orais <
orais.georgephil...@gmail.com>:
> Hi Guido,
> Want to hear your thoughts about, what if PicoLisp is implemented in
Pascal or Modula or Oberon? Will it be cool or not?
>
> BR,
> Geo
> On Wed, May 6, 2020 at 2:46 PM Guido Stepken  wrote:
>>
>> In international law, signing such a contract, as Anaconda Eula is
called "self binding". Those ideas in law go back to John Locke, Francis
Bacon, Thomas Hobbes.
>>
>> British and American law differ between binding contracts and common
law. But in those countries, signing such a contract binds you to their
legal system. Something, what over a long period was disputed about in the
European Union and that finally led to Brexit.
>>
>> http://www.contractsandagreements.co.uk/legally-binding-contracts.html
>>
>> Means: Sign that and you're going to Guantanamo, if you sent a copy of
Anaconda Python Packages to Iran. You get an international warrant. See
Assange, Australian. See Meng Wanzhou, Chinese.
>>
>> But all US export control laws can be overridden by the US president, by
US trade department, US Department of Justice, any time they want.
>>
>> https://www.eff.org/cases/bernstein-v-us-dept-justice
>>
>> Means, you can never know, if something is legal under US (and British)
law when using US "legally owned" (e.g. by Apache Foundation, Linux
Foundation, LLVM foundation) Open Source software ... or not, even if it's
under a "free license". And even if you haven't signed the Anaconda EULA.
Just by using free packages (e.g. with Python pip installer) that are
listed in Anaconda, gets you into conflict with US DoJ.
>>
>> But too many programmers proudly handed over their software to famous US
foundations without knowing, that - from now on - their code falls under US
law, US export restictions.
>>
>> Again i only can repeat: "Keep away from US Software Stacks!"
>>
>> Best regards, Guido Stepken
>>
>> Am Mittwoch, 6. Mai 2020 schrieb :
>> > Hi Guido
>> >
>> > Anaconda is a well known, free Software Installer for Python and R
packages, mostly used under Windows, right?
>> >
>> > And you think, that "free software" packages cannot be restricted by
US ministry of trade or U.S. president, such as happened in Huawei Google
case, right? Plain wrong:
>> >
>> > Quote from:
https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
>> >
>> > Are you sure you are not just mixing up "Enterprise Edition" and the
FOSS variant ("Individual Edition") ?
>> > To me it looks like the FOSS Anaconda is BSD-licensed, which comes
without any additional EULA or other strings attached.
>> > The EULA you link to belongs obviously to the proprietary product (the
classic "open-core" software business model).
>> >
>> > Additionally I like to add that throwing picolisp database together
with "distributed databases like datomic" into the same category is
misleading, this is hardly the same bucket. PicoLisp database can certainly
be used to build distributed systems, including a datomic-like DBMS, but
picolisp database is certainly not a "plug & play" distributed database
system in the current mainstream sense. There distributed DBMS essentially
means individual servers are abstracted away for the programmer, be it 3 or
3000 servers doesn't make a difference for the programmer using the DBMS -
of course this abstracting on top of networking (which is unreliable) comes
with constraints (e.g. usually no ACID) and a ton of potential issues (some
better, some often not so much mitigated by common distributed DBMS
software). This doesn't apply to PicoLisp database, which offers strict
ACID transactions and gives strong consistency guarantees

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

Well, can PicoLisp replace expensive "fully ACID" Datomic and Closure?

You mentioned that PicoLisp would be missing ACID feature. That's why we've
invented the "Event Sourcing Layer":

https://de.wikipedia.org/wiki/Event_Sourcing

Sorry, not available in other languages!

What's that? This is kind of apppend-only structure, similar to PostgreSQL
WAL Log, where all storage events (SQL inserts, updates) get registed,
before being applied (means finally written into) the database.

In a distributed database, you have to insert such a layer to get fully
ACID compliance. Like in a distributed, decentralized (this is not the
same!) blockchain, see Bitcoin database.

Means you will have to implement the following:

All database servers, now listen up!
Yeah! (server 1)
Yeah! (server 2)
Yeah!   ...
Yeah!   ...
I would like to insert 42 at symbol "Noclue"! Can i do that?
Yeah! Ready!
Yeah! Ready!
..
..
Ok, sending "Upsert 42 into Noclue" + Checksum + Cluster Increment Nummber
Received!
Received!
Received!
Received!
Ok, now all insert into database and write to disk!
Finished!
Finished!
Finished!
Finished!
Thank you all! (Close!)

Means: Being fully ACID compliant, for PicoLisp distributed cluster, you
need to implement that mechanism on your own. Certainly plenty of things
can go wrong. And like in all good languages, those errors can be caught
with 'catch':

: (catch 'OK (println 1) (throw 'OK 999) (println 2))
1
-> 999
: (catch '("No such file") (in "doesntExist" (foo)))
-> "No such file"

Adding such an "Event Sourcing Layer" costs you perhaps 50 lines of
Picolisp code. Peanuts!! Dead simple to implement.

And typically those append only structures get garbaged after some time ...

Have fun!

Am Mittwoch, 6. Mai 2020 schrieb :
> Hi Guido
..
> Additionally I like to add that throwing picolisp database together with
"distributed databases like datomic" into the same category is misleading,
this is hardly the same bucket. PicoLisp database can certainly be used to
build distributed systems, including a datomic-like DBMS, but picolisp
database is certainly not a "plug & play" distributed database system in
the current mainstream sense. There distributed DBMS essentially means
individual servers are abstracted away for the programmer, be it 3 or 3000
servers doesn't make a difference for the programmer using the DBMS - of
course this abstracting on top of networking (which is unreliable) comes
with constraints (e.g. usually no ACID) and a ton of potential issues (some
better, some often not so much mitigated by common distributed DBMS
software). This doesn't apply to PicoLisp database, which offers strict
ACID transactions and gives strong consistency guarantees even when
"distributed" (following C+P of CAP, while "datomic" follows A+P). PicoLisp
database allows to easily deploy read-replicas and remote databases can be
easily integrated into an single instance (including into the indexing
system), but it doesn't give you multi master mechanics out of the box
without basically re-implementing datomic or a similar architecture on top
of it.
>
> Your understanding of both distributed databases and PicoLisp (including
the non-DB areas) seem rather superficial to me.
>
> And it does not fall under US restrictions, since PicoLisp is  and does not contain any US libraries, that might fall under those
US export laws.
>
> What makes you think that Germany will not introduce similar laws sooner
or later?
>
> Germany already has the "Hacker-paragraph" which arguably criminalizes
distribution of the 'ping' network tool. Germany's "hate-speech" law was
copied by a number of repressive states, a perfect template. And currently
politicians debate about forcing websites to hand over password hashes to
the government. Granted these laws are probably not widely applied in
practice - but worse - this way they degenerate into tools of
arbitrariness, which stands in direct opposition to democratic rule of law.
>
> It's not so easy,
> - beneroth
>
> On 05.05.20 21:40, Guido Stepken wrote:
>
> Interesting question, isn't it? Let's have a look into my findings!
>
> Anaconda is a well known, free Software Installer for Python and R
packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by US
ministry of trade or U.S. president, such as happened in Huawei Google
case, right? Plain wrong:
>
> Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
>
> [quote]
> Export regulations
>
> Any use or distribution of the Software Product is made under conditions
that the user and/or distributor is in full compliance with all export and
other governing laws of the United States of America, including full and
ongoing compliance w

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-06 Thread George-Phillip Orais

Hi Guido,

Want to hear your thoughts about, what if PicoLisp is implemented in Pascal
or Modula or Oberon? Will it be cool or not?


BR,
Geo

On Wed, May 6, 2020 at 2:46 PM Guido Stepken  wrote:

> In international law, signing such a contract, as Anaconda Eula is called
> "self binding". Those ideas in law go back to John Locke, Francis Bacon,
> Thomas Hobbes.
>
> British and American law differ between binding contracts and common law.
> But in those countries, signing such a contract binds you to their legal
> system. Something, what over a long period was disputed about in the
> European Union and that finally led to Brexit.
>
> http://www.contractsandagreements.co.uk/legally-binding-contracts.html
> 
>
> Means: Sign that and you're going to Guantanamo, if you sent a copy of
> Anaconda Python Packages to Iran. You get an international warrant. See
> Assange, Australian. See Meng Wanzhou, Chinese.
>
> But all US export control laws can be overridden by the US president, by
> US trade department, US Department of Justice, any time they want.
>
> https://www.eff.org/cases/bernstein-v-us-dept-justice
>
> Means, you can never know, if something is legal under US (and British)
> law when using US "legally owned" (e.g. by Apache Foundation, Linux
> Foundation, LLVM foundation) Open Source software ... or not, even if it's
> under a "free license". And even if you haven't signed the Anaconda EULA.
> Just by using free packages (e.g. with Python pip installer) that are
> listed in Anaconda, gets you into conflict with US DoJ.
>
> But too many programmers proudly handed over their software to famous US
> foundations without knowing, that - from now on - their code falls under US
> law, US export restictions.
>
> Again i only can repeat: "Keep away from US Software Stacks!"
>
> Best regards, Guido Stepken
>
> Am Mittwoch, 6. Mai 2020 schrieb :
> > Hi Guido
> >
> > Anaconda is a well known, free Software Installer for Python and R
> packages, mostly used under Windows, right?
> >
> > And you think, that "free software" packages cannot be restricted by US
> ministry of trade or U.S. president, such as happened in Huawei Google
> case, right? Plain wrong:
> >
> > Quote from:
> https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
> >
> > Are you sure you are not just mixing up "Enterprise Edition" and the
> FOSS variant ("Individual Edition") ?
> > To me it looks like the FOSS Anaconda is BSD-licensed, which comes
> without any additional EULA or other strings attached.
> > The EULA you link to belongs obviously to the proprietary product (the
> classic "open-core" software business model).
> >
> > Additionally I like to add that throwing picolisp database together with
> "distributed databases like datomic" into the same category is misleading,
> this is hardly the same bucket. PicoLisp database can certainly be used to
> build distributed systems, including a datomic-like DBMS, but picolisp
> database is certainly not a "plug & play" distributed database system in
> the current mainstream sense. There distributed DBMS essentially means
> individual servers are abstracted away for the programmer, be it 3 or 3000
> servers doesn't make a difference for the programmer using the DBMS - of
> course this abstracting on top of networking (which is unreliable) comes
> with constraints (e.g. usually no ACID) and a ton of potential issues (some
> better, some often not so much mitigated by common distributed DBMS
> software). This doesn't apply to PicoLisp database, which offers strict
> ACID transactions and gives strong consistency guarantees even when
> "distributed" (following C+P of CAP, while "datomic" follows A+P). PicoLisp
> database allows to easily deploy read-replicas and remote databases can be
> easily integrated into an single instance (including into the indexing
> system), but it doesn't give you multi master mechanics out of the box
> without basically re-implementing datomic or a similar architecture on top
> of it.
> >
> > Your understanding of both distributed databases and PicoLisp (including
> the non-DB areas) seem rather superficial to me.
> >
> > And it does not fall under US restrictions, since PicoLisp is  GERMANY> and does not contain any US libraries, that might fall under those
> US export laws.
> >
> > What makes you think that Germany will not introduce similar laws sooner
> or later?
> >
> > Germany already has the "Hacker-paragraph" which arguably criminalizes
> distribution of the 'ping' network tool. Germany's "hate-speech" law was
> copied by a number of repressive states, a perfect template. And currently
> politicians debate about forcing websites to hand over password hashes to
> the government. Granted these laws are probably not widely applied in
> practice - but worse - this way they degenerate into tools of
> arbitrariness, which stands in direct opposition to democratic rule of law.
> >
> > It's not

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-05 Thread Guido Stepken

In international law, signing such a contract, as Anaconda Eula is called
"self binding". Those ideas in law go back to John Locke, Francis Bacon,
Thomas Hobbes.

British and American law differ between binding contracts and common law.
But in those countries, signing such a contract binds you to their legal
system. Something, what over a long period was disputed about in the
European Union and that finally led to Brexit.

http://www.contractsandagreements.co.uk/legally-binding-contracts.html

Means: Sign that and you're going to Guantanamo, if you sent a copy of
Anaconda Python Packages to Iran. You get an international warrant. See
Assange, Australian. See Meng Wanzhou, Chinese.

But all US export control laws can be overridden by the US president, by US
trade department, US Department of Justice, any time they want.

https://www.eff.org/cases/bernstein-v-us-dept-justice

Means, you can never know, if something is legal under US (and British) law
when using US "legally owned" (e.g. by Apache Foundation, Linux Foundation,
LLVM foundation) Open Source software ... or not, even if it's under a
"free license". And even if you haven't signed the Anaconda EULA. Just by
using free packages (e.g. with Python pip installer) that are listed in
Anaconda, gets you into conflict with US DoJ.

But too many programmers proudly handed over their software to famous US
foundations without knowing, that - from now on - their code falls under US
law, US export restictions.

Again i only can repeat: "Keep away from US Software Stacks!"

Best regards, Guido Stepken

Am Mittwoch, 6. Mai 2020 schrieb :
> Hi Guido
>
> Anaconda is a well known, free Software Installer for Python and R
packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by US
ministry of trade or U.S. president, such as happened in Huawei Google
case, right? Plain wrong:
>
> Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
>
> Are you sure you are not just mixing up "Enterprise Edition" and the FOSS
variant ("Individual Edition") ?
> To me it looks like the FOSS Anaconda is BSD-licensed, which comes
without any additional EULA or other strings attached.
> The EULA you link to belongs obviously to the proprietary product (the
classic "open-core" software business model).
>
> Additionally I like to add that throwing picolisp database together with
"distributed databases like datomic" into the same category is misleading,
this is hardly the same bucket. PicoLisp database can certainly be used to
build distributed systems, including a datomic-like DBMS, but picolisp
database is certainly not a "plug & play" distributed database system in
the current mainstream sense. There distributed DBMS essentially means
individual servers are abstracted away for the programmer, be it 3 or 3000
servers doesn't make a difference for the programmer using the DBMS - of
course this abstracting on top of networking (which is unreliable) comes
with constraints (e.g. usually no ACID) and a ton of potential issues (some
better, some often not so much mitigated by common distributed DBMS
software). This doesn't apply to PicoLisp database, which offers strict
ACID transactions and gives strong consistency guarantees even when
"distributed" (following C+P of CAP, while "datomic" follows A+P). PicoLisp
database allows to easily deploy read-replicas and remote databases can be
easily integrated into an single instance (including into the indexing
system), but it doesn't give you multi master mechanics out of the box
without basically re-implementing datomic or a similar architecture on top
of it.
>
> Your understanding of both distributed databases and PicoLisp (including
the non-DB areas) seem rather superficial to me.
>
> And it does not fall under US restrictions, since PicoLisp is  and does not contain any US libraries, that might fall under those
US export laws.
>
> What makes you think that Germany will not introduce similar laws sooner
or later?
>
> Germany already has the "Hacker-paragraph" which arguably criminalizes
distribution of the 'ping' network tool. Germany's "hate-speech" law was
copied by a number of repressive states, a perfect template. And currently
politicians debate about forcing websites to hand over password hashes to
the government. Granted these laws are probably not widely applied in
practice - but worse - this way they degenerate into tools of
arbitrariness, which stands in direct opposition to democratic rule of law.
>
> It's not so easy,
> - beneroth
>
> On 05.05.20 21:40, Guido Stepken wrote:
>
> Interesting question, isn't it? Let's have a look into my findings!
>
> Anaconda is a well known, free Software Installer for Python and R
packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by US
ministry of trade or U.S. president, such as happened in Huawei Google
case, right? Plain wrong:
>
> Quote from:

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-05 Thread Guido Stepken

>From the philosphical point of view, 64 bit integer is the same as 64 bit
float, except for, that you give certain bits a different meaning.

Picolisp gives you total freedom, to decide, what to do with those 64 (or
even more!!!) bits. Either you can store 4x 16 bit as so called
"minifloat", even 8 bit floats do exist, e.g. within neural nets.

Alex documented that: https://software-lab.de/doc/ref.html#data

Picolisp thus also can handle very long numbers, e.g. used in enterprises,
such as Siemens to handle huge sums, that go into the billions.

Picolisp is used in Logistics as well as ERP system. Picolisp easily can
substitute SAP for small enterprises (<1 employees):

Alex wrote about that here: https://software-lab.de/doc/app.html

[quote]
A Minimal Complete Application

The PicoLisp release includes in the "app/" directory a minimal, yet
complete reference application. This application is typical, in the sense
that it implements many of the techniques described in this document, and
it can be easily modified and extended. In fact, we use it as templates for
our own production application development.

It is a kind of simplified ERP system, containing customers/suppliers,
products (items), orders, and other data. The order input form performs
live updates of customer and product selections, price, inventory and
totals calculations, and generates on-the-fly PDF documents. Fine-grained
access permissions are controlled via users, roles and permissions. It
comes localized in seven languages (English, Spanish, German, Norwegian,
Swedish, Russian and Japanese), with some initial data and two sample
reports.

Since this reference application employs so many of the typical techniques
used in writing PicoLisp applications, taking the time to study it is time
very well invested. Another good way to get acquainted with the language
and framework is to start experimenting by writing small applications of
your own. Copying and making changes to the reference application is a very
good way to get started with this, and I highly recommend doing so.
[/quote]

You get an (Cloud) ERP system for free! Before you have introduced and
customized SAP for you needs, you're bankrupt. Picolisp is the much better
solution, takes much less resources. Price: ZERO!

And if so much freedom is too much for you, nothing prevents you do bind
GNU Scientific Library into Lisp via FFI, with IEEE floats and all known US
standards. But i can tell you, that Picolisp "standards" are very well
thought through.

https://picolisp.com/wiki/?interfacing
https://www.gnu.org/software/gsl/

Have fun!

Best regards, Guido

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-05 Thread andreas

Hi Guido

> Anaconda is a well known, free Software Installer for Python and R
> packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by
> US ministry of trade or U.S. president, such as happened in Huawei
> Google case, right? Plain wrong:
>
> Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
Are you sure you are not just mixing up "Enterprise Edition" and the
FOSS variant ("Individual Edition") ?
To me it looks like the FOSS Anaconda is BSD-licensed, which comes
without any additional EULA or other strings attached.
The EULA you link to belongs obviously to the proprietary product (the
classic "open-core" software business model).

Additionally I like to add that throwing picolisp database together with
"distributed databases like datomic" into the same category is
misleading, this is hardly the same bucket. PicoLisp database can
certainly be used to build distributed systems, including a datomic-like
DBMS, but picolisp database is certainly not a "plug & play" distributed
database system in the current mainstream sense. There distributed DBMS
essentially means individual servers are abstracted away for the
programmer, be it 3 or 3000 servers doesn't make a difference for the
programmer using the DBMS - of course this abstracting on top of
networking (which is unreliable) comes with constraints (e.g. usually no
ACID) and a ton of potential issues (some better, some often not so much
mitigated by common distributed DBMS software). This doesn't apply to
PicoLisp database, which offers strict ACID transactions and gives
strong consistency guarantees even when "distributed" (following C+P of
CAP, while "datomic" follows A+P). PicoLisp database allows to easily
deploy read-replicas and remote databases can be easily integrated into
an single instance (including into the indexing system), but it doesn't
give you multi master mechanics out of the box without basically
re-implementing datomic or a similar architecture on top of it.

Your understanding of both distributed databases and PicoLisp (including
the non-DB areas) seem rather superficial to me.

> And it does not fall under US restrictions, since PicoLisp is  GERMANY> and does not contain any US libraries, that might fall under
> those US export laws.
What makes you think that Germany will not introduce similar laws sooner
or later?

Germany already has the "Hacker-paragraph" which arguably criminalizes
distribution of the 'ping' network tool. Germany's "hate-speech" law was
copied by a number of repressive states, a perfect template. And
currently politicians debate about forcing websites to hand over
password hashes to the government. Granted these laws are probably not
widely applied in practice - but worse - this way they degenerate into
tools of arbitrariness, which stands in direct opposition to democratic
rule of law.

It's not so easy,
- beneroth

On 05.05.20 21:40, Guido Stepken wrote:
> Interesting question, isn't it? Let's have a look into my findings!
>
> Anaconda is a well known, free Software Installer for Python and R
> packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by
> US ministry of trade or U.S. president, such as happened in Huawei
> Google case, right? Plain wrong:
>
> Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
>
> [quote]
> Export regulations
>
> Any use or distribution of the Software Product is made under
> conditions that the user and/or distributor is in full compliance with
> all export and other governing laws of the United States of America,
> including full and ongoing compliance with the Export Administration
> Regulations (EAR) of the United States Department of Commerce. See
> www.commerce.gov/  and
> http://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear.
> Use or distribution of Continuum software products to any persons,
> entities or countries currently under US sanctions is strictly
> prohibited. Continuum has self-assessed that Anaconda Repository
> requires no license to for export to non-embargoed countries
>
> The United States currently has embargoes against several countries.
> The exportation, re-exportation, sale or supply, directly or
> indirectly, from the United States, or by a U.S. person wherever
> located, of any Continuum software to any of these countries is
> strictly prohibited without prior authorization by the United States
> Government. By accepting this Agreement, you represent to Continuum
> that you will comply with all applicable export regulations for Anaconda.
> [/quote]
>
> Means: Export Anaconda or packages from Anaconda to Iran and you're
> going to Guantanamo!
>
> And i repeat: *Stop using US Software Stacks!*
>
> Picoslip has everything, yor IT could ever need! Integrated
> Distributed Database, Prolog like reasoning about stored data and

Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-05 Thread Edgaras Šeputis

You being an interesting personality, I have just mildly related question.
What is your opinion on picolisp's floating point situation? (this is one
reason why I did not even attempt to delve too much into it apart from some
small experiments in REPL, though obviously I still find it and community
fascinating). Similarly consideration about other "regular"(one could say
efficient) structures like arrays. I have this view that programming
language should allow writing something as video games to be of interest to
me. And no native floats and arrays seems like it would make such
potentially quite cumbersome.

On Tue, May 5, 2020 at 10:45 PM Guido Stepken  wrote:

> Interesting question, isn't it? Let's have a look into my findings!
>
> Anaconda is a well known, free Software Installer for Python and R
> packages, mostly used under Windows, right?
>
> And you think, that "free software" packages cannot be restricted by US
> ministry of trade or U.S. president, such as happened in Huawei Google
> case, right? Plain wrong:
>
> Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/
>
> [quote]
> Export regulations
>
> Any use or distribution of the Software Product is made under conditions
> that the user and/or distributor is in full compliance with all export and
> other governing laws of the United States of America, including full and
> ongoing compliance with the Export Administration Regulations (EAR) of the
> United States Department of Commerce. See www.commerce.gov/ and
> http://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear.
> Use or distribution of Continuum software products to any persons, entities
> or countries currently under US sanctions is strictly prohibited. Continuum
> has self-assessed that Anaconda Repository requires no license to for
> export to non-embargoed countries
>
> The United States currently has embargoes against several countries. The
> exportation, re-exportation, sale or supply, directly or indirectly, from
> the United States, or by a U.S. person wherever located, of any Continuum
> software to any of these countries is strictly prohibited without prior
> authorization by the United States Government. By accepting this Agreement,
> you represent to Continuum that you will comply with all applicable export
> regulations for Anaconda.
> [/quote]
>
> Means: Export Anaconda or packages from Anaconda to Iran and you're going
> to Guantanamo!
>
> And i repeat: *Stop using US Software Stacks!*
>
> Picoslip has everything, yor IT could ever need! Integrated Distributed
> Database, Prolog like reasoning about stored data and even contains a Graph
> Database, though it's mentioned nowhere.
>
> But there is no real need to mention that, since Lisp in itself ("Code is
> data, data is code") not only has a "syntax tree" (kind of graph), but, in
> fact, you can model any graph you like with Lisp's (cons) constructs.
>
> And it does not fall under US restrictions, since PicoLisp is  GERMANY> and does not contain any US libraries, that might fall under those
> US export laws.
>
> Have fun!
>

Do free Open Source Foundation's Software Stacks fall under US Export Law?

2020-05-05 Thread Guido Stepken

Interesting question, isn't it? Let's have a look into my findings!

Anaconda is a well known, free Software Installer for Python and R
packages, mostly used under Windows, right?

And you think, that "free software" packages cannot be restricted by US
ministry of trade or U.S. president, such as happened in Huawei Google
case, right? Plain wrong:

Quote from: https://docs.anaconda.com/anaconda-repository/2.23/admin/eula/

[quote]
Export regulations

Any use or distribution of the Software Product is made under conditions
that the user and/or distributor is in full compliance with all export and
other governing laws of the United States of America, including full and
ongoing compliance with the Export Administration Regulations (EAR) of the
United States Department of Commerce. See www.commerce.gov/ and
http://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear.
Use or distribution of Continuum software products to any persons, entities
or countries currently under US sanctions is strictly prohibited. Continuum
has self-assessed that Anaconda Repository requires no license to for
export to non-embargoed countries.

The United States currently has embargoes against several countries. The
exportation, re-exportation, sale or supply, directly or indirectly, from
the United States, or by a U.S. person wherever located, of any Continuum
software to any of these countries is strictly prohibited without prior
authorization by the United States Government. By accepting this Agreement,
you represent to Continuum that you will comply with all applicable export
regulations for Anaconda.
[/quote]

Means: Export Anaconda or packages from Anaconda to Iran and you're going
to Guantanamo!

And i repeat: *Stop using US Software Stacks!*

Picoslip has everything, yor IT could ever need! Integrated Distributed
Database, Prolog like reasoning about stored data and even contains a Graph
Database, though it's mentioned nowhere.

But there is no real need to mention that, since Lisp in itself ("Code is
data, data is code") not only has a "syntax tree" (kind of graph), but, in
fact, you can model any graph you like with Lisp's (cons) constructs.

And it does not fall under US restrictions, since PicoLisp is and does not contain any US libraries, that might fall under those
US export laws.

Have fun!

Re: How do I read HTTP body while using web.l

Hi Kashyap,

> While my question was about the server side - it is super cool to learn
> about "ssl" - although I am curious - was there a reason why "POST" was
> left out of it?

Good question! To be true, 'ssl' serves mainly other purposes (running as a
daemon synchronizing databases), and the single-shot mode used in that case is
more an add-on ;)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How do I read HTTP body while using web.l

2019-05-15 Thread C K Kashyap

Hey Alex,
While my question was about the server side - it is super cool to learn
about "ssl" - although I am curious - was there a reason why "POST" was
left out of it?
Also I agree about the point of parsing a program generated JSON looks like
an overkill is many cases.

Hey Andreas - I dont think web.l reads up the body beforehand. Even if I
have a (out "+out.txt" (prinl (till NIL T))) inside the handler and I
Ctrl-C the process after sending in a request, I can see out.txt with the
request body.

Regards,
Kashyap

On Wed, May 15, 2019 at 12:55 AM Alexander Burger 
wrote:

> Hi Andreas,
>
> > Web.l is a server-side framework.
> > ...
>
> Thanks! I've seen it, but never found the time to study it :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: How do I read HTTP body while using web.l

Hi Andreas,

> Web.l is a server-side framework.
> ...

Thanks! I've seen it, but never found the time to study it :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How do I read HTTP body while using web.l

On Wed, May 15, 2019 at 09:18:47AM +0200, Alexander Burger wrote:
>   (from "\"EUR\"")
>   (from "\"last\" : ")
>   (read) )

Just for completeness:

In the real case, I do not use 'read' as above. I handle our long-discussed
fixpoint issue this way:

   (from "\"EUR\"")
   (from "\"last\" : ")
   (format
  (pack (till ".,\n") (or (till ",\n") "."))
  *Scl )

☺/ A!ex


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How do I read HTTP body while using web.l

2019-05-15 Thread andreas


Hi Alex,

Web.l is a server-side framework.

This thread is about how to handle a uploaded JSON file I believe,
not about consuming a JSON/REST API as a client.

Web.l is an alternative to the picolisp standard GUI framework form.l.

I can recommend web.l for people learning how to implement a HTTP 
server, and for small (toy) applications.
It's a  simple/simplified HTTP server, and the code is pretty 
transparent.
I do not recommend to use web.l for larger or critical production 
applications - I think it just makes it too easy to program severe 
stability issues and security holes with it.


In practice you like to program your own webserver and stack (as I 
did/do), then web.l might be a good basis to start from, but you will 
end up with your own implementations anyway.
Or you don't want to be bothered with webserver internals and just need 
a framework for writing an application - then stay with picolisp 
standard form.l.

That would be my sincere recommendation.

Kind regards,
beneroth


Am 2019-05-15 09:08, schrieb Alexander Burger:

Hi Andreas,

On Wed, May 15, 2019 at 08:27:19AM +0200, andr...@itship.ch wrote:

In web.l framework, you you define a request handler using (dh).


I do not know the web.l framework, but like to add that using either 
'client'

(from "@lib/http.l") or @bin/ssl is a bit simpler.

'client' can handle POSTs, but no HTTPS. @bin/ssl handles HTTPS, but no 
POSTs.

In case you need both, I recommend a pipe to curl again.

'client' and @bin/ssl are used roughly the same way. An example for 
parsing

bitcoin rates would be:

   (load "@lib/json.l")

   (scl 2)

   (in '("@bin/ssl" "blockchain.info" 443 "de/ticker")
  (while (line))  # Skip header
  (readJson) )

☺/ A!ex


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How do I read HTTP body while using web.l

On Wed, May 15, 2019 at 09:08:44AM +0200, Alexander Burger wrote:
>(in '("@bin/ssl" "blockchain.info" 443 "de/ticker")
>   (while (line))  # Skip header
>   (readJson) )

Having discussed about Json all the time, let me say that in fact I never used
'readJson' etc. I feel it is overkill in most practical cases.

Instead, I parse the stream directly. This is much simpler and faster. In the
above case, I would extract e.g. the EUR rate as: the

   (scl 8)

   (in '("@bin/ssl" "blockchain.info" 443 "de/ticker")
  (from "\"EUR\"")
  (from "\"last\" : ")
  (read) )

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How do I read HTTP body while using web.l