Unsubscribe

[Guido Stepken]

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

[Guido Stepken]

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: Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

It's not me being on the warpath, it US government by sanctioning and
blackmailing every fucking country in the world. See North Stream 2
threats against Germany and Swiss companies, the warrant against Meng
Wanzhou, former Huawei CFO (no proof, nothing), sanctions even against
Venezuela (maybe they have Weapons of Mass Destruction ...who knows?).

They're weaponizing US Dollar for over a decade now, globally
blackmailing foreign banks with fines (hundreds of billion dollars in
total) and now, since January 1st 2020, they have started to weaponize
their US software industry.

Seems, most people yet don't take that very seriously, but everybody
is affected. Each single Open Source programmer, supporter.

But like Kurt Tucholski said: "Incidentally, the person who points out
the dirt is much more dangerous than the person who makes the dirt!"

So far!





Am Mi., 6. Mai 2020 um 19:09 Uhr schrieb Yiorgos [George] Adamopoulos
:
>
> Enough is enough. By bringing a very controversial person in the
> discussion (who does not have the chance to participate in it) you are
> making me lose any interest in your arguments.
>
> You are on a mission. I get it. I might even admire it. I am not on
> that mission and have no interest in it until I see implementations of
> your claims. So far you have shown nothing besides theoretical
> knowledge, not a single line of code, have only called people ignorant
> (and they have allowed this out of courtesy), FUD them (I am not
> planning on sending code on Iran, if they manage to download any, good
> for them) and you keep insisting on your path. Which is OK for you to
> follow; just not necessarily for us.
>
> A cheap Hetzner server can be based in two sites in Germany where you
> are protected from US Law. Show us your code there. Not now, sometime.
> Make your picolisp port use whatever runtime you like. Because frankly
> so far, you seem to want others to do the job for you.  This may not
> be your intent, but this is how get understood over here.
>
> Now show us your parentheses.
>
> On Wed, May 6, 2020 at 7:44 PM Guido Stepken  wrote:
> >
> > Υπάρχουν πάντοτε άνθρωποι που δεν έχουν πρόσβαση. Και δεν ξέρουν καν γιατί 
> > κάνουν αυτό. Ειδικά σε περιόδους μαζικών πολιτικών αλλαγών. Αυτός είναι 
> > επίσης ο λόγος για τον οποίο ο Βαρουφάκης παραιτήθηκε. Αλλά είχε δίκιο με 
> > πολλούς τρόπους.
> >
> > Am Mittwoch, 6. Mai 2020 schrieb Yiorgos [George] Adamopoulos 
> > :
> > > Βρίσκω τον τρόπο που γίνεται η συζήτηση αγενή.
> > >
> > > On Wed, May 6, 2020 at 6:48 PM Guido Stepken  wrote:
> > >>
> > >> Je ne veux pas faire sursauter trop tôt nos collègues lecteurs des 
> > >> États-Unis. Peut-être tu veux attendre quelques semaines de plus jusqu'à 
> > >> ce que des choses importantes soient décidées au niveau de l'UE.
> > >>
> > >> Mais je peux toi assurer que des parties importantes viennent de France.
> > >>
> > >> Ce sera une grande surprise pour eux.
> > >>
> > >> Amuse-toi bien!
> > >>
> > >> > I'm curious, what are those two similar other tools?
> > >> >
> > >> > Best,
> > >> >
> > >> > Eric
> > >> >
> > >> >>> --
> > >> >>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> > >> >>>
> > >
> > >
> > >
> > > --
> > > keep raising the bar
> > >
> > > --
> > > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
> > >
>
>
>
> --
> keep raising the bar
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe

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

Re: Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

Υπάρχουν πάντοτε άνθρωποι που δεν έχουν πρόσβαση. Και δεν ξέρουν καν γιατί
κάνουν αυτό. Ειδικά σε περιόδους μαζικών πολιτικών αλλαγών. Αυτός είναι
επίσης ο λόγος για τον οποίο ο Βαρουφάκης παραιτήθηκε. Αλλά είχε δίκιο με
πολλούς τρόπους.

Am Mittwoch, 6. Mai 2020 schrieb Yiorgos [George] Adamopoulos <
yiorgos.adamopou...@gmail.com>:
> Βρίσκω τον τρόπο που γίνεται η συζήτηση αγενή.
>
> On Wed, May 6, 2020 at 6:48 PM Guido Stepken  wrote:
>>
>> Je ne veux pas faire sursauter trop tôt nos collègues lecteurs des
États-Unis. Peut-être tu veux attendre quelques semaines de plus jusqu'à ce
que des choses importantes soient décidées au niveau de l'UE.
>>
>> Mais je peux toi assurer que des parties importantes viennent de France.
>>
>> Ce sera une grande surprise pour eux.
>>
>> Amuse-toi bien!
>>
>> > I'm curious, what are those two similar other tools?
>> >
>> > Best,
>> >
>> > Eric
>> >
>> >>> --
>> >>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>> >>>
>
>
>
> --
> keep raising the bar
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

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

[Guido Stepken]

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: Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

Je ne veux pas faire sursauter trop tôt nos collègues lecteurs des
États-Unis. Peut-être tu veux attendre quelques semaines de plus jusqu'à ce
que des choses importantes soient décidées au niveau de l'UE.

Mais je peux toi assurer que des parties importantes viennent de France.

Ce sera une grande surprise pour eux.

Amuse-toi bien!

> I'm curious, what are those two similar other tools?
>
> Best,
>
> Eric
>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>

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

[Guido Stepken]

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?

[Guido Stepken]

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?

[Guido Stepken]

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: Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

Am Mittwoch, 6. Mai 2020 schrieb cilz :
>
> Le 06/05/2020 à 15:19, Guido Stepken a écrit :
>
> Sorry, no tutorial handy ... i only have the full code, which i don't
want to publish ...
>
> Too bad!
>
> May be you can devise a tiny example to help us (at least the very noob
like me) figure out what you're meaning with this awesome statement
"Picolisp is the only language in the world, that can reason about database
contents!"

It's all perfectly written down in Alex' documention on pilog:

https://software-lab.de/doc/select.html

Perhaps you should read the *whole documentation* about PicoLisp first.

And then do, what the famous German Philospher Arthur Schopenhauer once
said in "The World as Will and Representation":

"Read my books and then, at the end, start again reading from the
beginning".

He was right. After having read through his book, only getting parts of it
into my mind, i discovered plenty of things, i simply couldn't see or had
overseen, when reading it the first time.

Getting the *whole mindset* of PicoLisp is not easy, because Alex weaved
into each other, what normaly is sold and mentally recognized as separate
products: A Programming Language, a Prolog AI, a BTree Database Server, a
Graph Database, a modern Web Framework ...

That's, what makes it so highly efficient to program with. I've seen only
two (complete, covering everything) simlilar other tools in my life, that
is such efficient to program with.

Have fun!

> Hence, am I right if I consider PicoLisp as the root for building a
"deductive database system"?
>
> But Prolog, same as *pilog* is a declarative language, very easy to
learn. What makes pilog unique is, that you can mix it with Lisp.
>
> It's a relatively simple combinatorial problem, that can be divided into
two (well, four) separate problems:
>
> 1st: Find the right, matching boxes to fulfill your 'special' customer's
demands.
>
> 2nd: With the rest of fruits you let pilog reason about, what 'standard
packages' can be rebuilt from that.
>
> 3rd. Delete boxes from problem #1 from your inventory (PicoLisp)
>
> 4th. Add rebuilt boxes to inventory. There might be some fruits left
over. (PicoLisp)
>
> Now your homework! ;-)
>
> yes!
>
> Of course, you can implement it with pure Lisp, too! ;-)
>
> Have fun!
>
>
> Best,
>
> Eric
>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>

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

[Guido Stepken]

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?

[Guido Stepken]

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: Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

Sorry, no tutorial handy ... i only have the full code, which i don't want
to publish ...

But Prolog, same as *pilog* is a declarative language, very easy to learn.
What makes pilog unique is, that you can mix it with Lisp.

It's a relatively simple combinatorial problem, that can be divided into
two (well, four) separate problems:

1st: Find the right, matching boxes to fulfill your 'special' customer's
demands.

2nd: With the rest of fruits you let pilog reason about, what 'standard
packages' can be rebuilt from that.

3rd. Delete boxes from problem #1 from your inventory (PicoLisp)

4th. Add rebuilt boxes to inventory. There might be some fruits left over.
(PicoLisp)

Now your homework! ;-)

Of course, you can implement it with pure Lisp, too! ;-)

Have fun!

Am Mittwoch, 6. Mai 2020 schrieb cilz :
> Hi Guido,
>
> I would love to see some (toy?) code example about this if you have
some...
>
> Thanks in advance, best,
>
> Eric
>
> Le 06/05/2020 à 09:27, Guido Stepken a écrit :
>>
>> You all might have heard about 'pilog' a Prolog like AI system within
Picolisp, where you can define rules, describe a situation and ask for
solutions. What can you do with that?
>>
>> Typically, items come bundled in all kinds of packages, repair packages,
addons, ...
>>
>> E.g. We have 30 (all slighly different) meal packages in stock with each
(banana, apple, pear), (cherry, strayberry, apple), (strawberry, banana,
orange) ...
>>
>> All packages having a serial number, only available as complete package,
'all or nothing' - rule.
>>
>> Business, so far, went well. But now we have good customer, ordering 3
packages: (2x banana, 1 apple), (3 x strawberry), (1 orange,2 apples).
>>
>> Now comes the question: What is the minimum number of precustomized
packages i do have to destroy and unlist from the database and how can i
repackage the rest to fit the scheme of custom packages, (re-)adding some
'new' packages (while reusing using old boxes)?
>>
>> No problem for PicoLisp Pilog. You don't even have to program that.
Simply give PicoLisp the rules, and let Pilog reason about it
>>
>> And you even don't have to download all inventory into a Picolisp to
find the perfect solution: ***Picolip Prolog is sitting in the
database!!!***
>>
>> I did implement that for a couple of hundred 'service points' for a huge
manufacturer. Using Picolisp's built-in distributed database cluster. Now
Pilog even can reason across several locations and their local inventory,
saving them *incredible amounts* of money.
>>
>> Of course, they had to learn howto rewrite their rules that change from
day to day. Sometimes there is 'norule' day, e.g. when there is no personel
available to repackage boxes. Pilog then recognizes that and does not
reason across whole cluster database any longer.
>>
>> Picolisp is unbeatable in logistics, far ahead of *any* competitor, for
*any* money. At ZERO cost!!! This little thing is a *genius strike*!
>>
>> Have fun!
>>
>> Best regards, Guido Stepken
>>
>>
>>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

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

[Guido Stepken]

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?

[Guido Stepken]

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?

[Guido Stepken]

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

Picolisp is the only language in the world, that can reason about database contents!

[Guido Stepken]

You all might have heard about 'pilog' a Prolog like AI system within
Picolisp, where you can define rules, describe a situation and ask for
solutions. What can you do with that?

Typically, items come bundled in all kinds of packages, repair packages,
addons, ...

E.g. We have 30 (all slighly different) meal packages in stock with each
(banana, apple, pear), (cherry, strayberry, apple), (strawberry, banana,
orange) ...

All packages having a serial number, only available as complete package,
'all or nothing' - rule.

Business, so far, went well. But now we have good customer, ordering 3
packages: (2x banana, 1 apple), (3 x strawberry), (1 orange,2 apples).

Now comes the question: What is the minimum number of precustomized
packages i do have to destroy and unlist from the database and how can i
repackage the rest to fit the scheme of custom packages, (re-)adding some
'new' packages (while reusing using old boxes)?

No problem for PicoLisp Pilog. You don't even have to program that. Simply
give PicoLisp the rules, and let Pilog reason about it.

And you even don't have to download all inventory into a Picolisp to find
the perfect solution: ***Picolip Prolog is sitting in the database!!!***

I did implement that for a couple of hundred 'service points' for a huge
manufacturer. Using Picolisp's built-in distributed database cluster. Now
Pilog even can reason across several locations and their local inventory,
saving them *incredible amounts* of money.

Of course, they had to learn howto rewrite their rules that change from day
to day. Sometimes there is 'norule' day, e.g. when there is no personel
available to repackage boxes. Pilog then recognizes that and does not
reason across whole cluster database any longer.

Picolisp is unbeatable in logistics, far ahead of *any* competitor, for
*any* money. At ZERO cost!!! This little thing is a *genius strike*!

Have fun!

Best regards, Guido Stepken

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

[Guido Stepken]

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?

[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
pack

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

[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

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

[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: PilCon 2020

[Guido Stepken]

Lisp, interpreted languages in general, are single core only. Thus, a
Hetzner CX11 offer for 2.98€/month https://www.hetzner.de/cloud always is
sufficient, even for 60 clients.

The is a huge discussion out there about Python GIL, many people claiming,
that Python applications (Django, Flask) couldn't scale.

But there is a solution for that, a very cheap one: You only have to use
multiple A-record entries in DNS for automatic load balancing between
several PicoLisp Hetzner Server instances:

https://stackoverflow.com/questions/5319649/using-dns-for-failover-using-multiple-a-records

This way, your application will scale _endlessly_ even without a costy load
balancer. That's because the behaviour to pick randomly one of these DNS A
record IP Adresses is built-in into any browser.

Only problem left, is to asynchronously sync the database content across
several physical machines.

I personally tend to use http://dqlite.io , the little, distributed brother
of famous SQLite, which is built in into all browsers under the name
IndexdDB.

But, in fact, "distributed database", in Picolisp, comes for free:

**Integrated Distributed Database Engine**

*Build large, distributed databases with fewer headaches and fewer
dependencies*

Database functionality is built into the core of the VM, making PicoLisp a
language for querying and manipulating databases.

For that, PicoLisp includes a built-in application framework and Prolog
engine so you can create, organize, inspect and change (and even build a
fancy UI for) your data - all with a uniform and concise syntax.

And when it's time to scale, PicoLisp has you covered - creating networks
of distributed databases is built into the core as well. It's simple and
powerful, and makes few assumptions about your application architecture.

From: https://picolisp.com/wiki/?home

With this, Picolisp even beats _extremely expensive_ commercial solutions
..

Especially Closure and Datomic -> dustbin! US bloat!

Have fun!


Am Dienstag, 5. Mai 2020 schrieb O.Hamann :
> On 28.04.20 07:38, Alexander Burger wrote:
>> We used Jitsi a lot during the last weeks. I have tried up to only 5
members so
>> far, but performance was good. Beneroth has set up his own server. I
don't know
>> how well it scales for more members, and what can be done to optimize it

Re: Talking about algorithms and their BIG(O) behaviour, efficiency, other JIT IR compilers ...

[Guido Stepken]

"Pico operates on lists. Its fundamental data structure tends toward linear
algorithms."

This is what you've been told? Plain wrong!

(cons(cons(A B) C) already is a minimal (directed) graph.

What does that (200 lines of C) Lisp implementation tell you?

typedef struct List {
   struct List * next;
   void * data;
 } List;

https://carld.github.io/2017/06/20/lisp-in-less-than-200-lines-of-c.html

Lisp is a (recursive) graph (syntax "tree") engine by default, scaling -
endlessly!

That's, what PicoLisp also is.

Have fun!

> On Sun, May 3, 2020 at 16:57 Guido Stepken  wrote:
>>
>> Certainly you've heard of Fusion² Trees, Exponential² Trees, Ryabko³
Trees, Bit Twiddling Hacks⁴ in C ... this is, what i consider the high
class of programming excellence, every programmer not only should have
heard of, but also should have implemented on his/her own.
>>
>> This class of algorithms shows much better BIG(O) behaviour, often
O(log(log(n)) or O(log₃₂(n)) on 32 bit, O(log₆₄(n)) on 64 bit in searching
through vasts amounts of data in almost ZERO time.
>>
>> They're quite rare in e.g. Apache Foundation or Linux Foundation
software ("pile of shit") packages, since they allow even better search
times on a $25 Raspberry Pi Zero than on a $100.000 28 Core Intel Dual CPU
Xeon machine. Of course, this is not in the interest of US industry.
>>
>> Most interesting for Lisp implementors is the Ryabko aka Fenwick Tree,
since it easily allows implementing a highly efficient multi generational
(ageing memory pools) garbage collectors as being found in our German
version of LLVM, the brilliant LuaJIT DYNASM enginge, which has almost
everything, that is publically considered as 'state of the art' JIT
compiler technology.
>>
>> Of course DYNASM is faster, smaller, better than LLVM and generates
machine code for even smallest embedded devices (even runs on those!!!),
has the much superiour "Four Color Multi Color, Multi Generational Mark
Sweep GC".
>>
>> That little thing with the long name is far superior to every other
Garbage Collector, i've seen in my life:
>>
>> http://wiki.luajit.org/SSA-IR-2.0
>> http://wiki.luajit.org/New-Garbage-Collector
>>
>> Lua is a very Lisp like language, since its smallest data structure is a
two (cons) cell unit, one data and one pointer to next cell. But comes with
INFIX notation.
>>
>> And since Lua Programming Language data structures are so similar to
those of Lisp, there also is a Lisp port onto that tiny LuaJIT DYNASM
engine, kind of transpiler, written in - Lua! Piece of cake in terms of LoC
(compare to pil21):
>>
>> https://github.com/bakpakin/Fennel/blob/master/README.md
>>
>> And, of course, you get C speed with that stuff, with far lesss lines of
code Maintainable, security reviews can easily be done ... much smaller
memory footprint, much faster JIT compile times, thanks to DYNASM:
>>
>> http://luajit.org/dynasm.html
>>
>> Needless to say, that this stuff is far superior to anything you can
find made by US Foundations with their billions of lines of unmaintainable
bloat ...
>>
>> I am using that stuff now since a while - both the superior algorithms
as well as some of our own German/EU software stacks and i only can tell
you, what i've already mentioned:
>>
>> "Don't use US Software Stacks!!! - Billions of lines of code, millions
of bugs, thousands of NSA backdoors, hundreds of slow algorithms!!!"
>>
>> I hope, you regard my "findings" for you quite interesting and
convincing, see you using next generation of high quality software, that
does not fall under US software export restrictions, since it's - "Made in
Germany"!!! ;-)
>>
>> Finally you also should have a look into the last link, "Bit Twiddling
Hacks in C". You will be _very surprised_ what you will find there.
Needless to say, that this collection of tips and tricks also applies to
other programming languages, making your code much faster (and much
less readable and understandable, if you don't put a link into the
comments)! ;-)
>>
>> Have fun!
>>
>> Best regards, Guido Stepken
>>
>> ¹) https://en.wikipedia.org/wiki/Fusion_tree
>> ²) https://en.wikipedia.org/wiki/Exponential_tree
>> ³) https://en.wikipedia.org/wiki/Fenwick_tree
>> ⁴) https://graphics.stanford.edu/~seander/bithacks.html
>
> --
> John Duncan

Re: Talking about algorithms and their BIG(O) behaviour, efficiency, other JIT IR compilers ...

[Guido Stepken]

Certainly, Fusion Tree, as well as the successor, Exponetial Tree and
especially Van Emde Boas Tree have certain "overhead". But it pays off
quickly at search through huge data on terabyte+ SSDs, you even can find in
any home today.

Remember: "You'll never become a car even if you put your body in a garage!"

Regards, Guido Stepken

Am Sonntag, 3. Mai 2020 schrieb John Duncan :
> I took my algorithms class from one of the inventors of fusion trees.
It’s more of a stunt than anything else. He invented it just to prove the
point. The constant factor of each operation dwarfs the comparison it
avoids. But the big-O is relatively small. They are still impractical.
> Pico operates on lists. Its fundamental data structure tends toward
linear algorithms. Trees are also possible where needed. In general, this
is not the fastest, but it’s usually good enough.
> On Sun, May 3, 2020 at 16:57 Guido Stepken  wrote:
>>
>> Certainly you've heard of Fusion² Trees, Exponential² Trees, Ryabko³
Trees, Bit Twiddling Hacks⁴ in C ... this is, what i consider the high
class of programming excellence, every programmer not only should have
heard of, but also should have implemented on his/her own.
>>
>> This class of algorithms shows much better BIG(O) behaviour, often
O(log(log(n)) or O(log₃₂(n)) on 32 bit, O(log₆₄(n)) on 64 bit in searching
through vasts amounts of data in almost ZERO time.
>>
>> They're quite rare in e.g. Apache Foundation or Linux Foundation
software ("pile of shit") packages, since they allow even better search
times on a $25 Raspberry Pi Zero than on a $100.000 28 Core Intel Dual CPU
Xeon machine. Of course, this is not in the interest of US industry.
>>
>> Most interesting for Lisp implementors is the Ryabko aka Fenwick Tree,
since it easily allows implementing a highly efficient multi generational
(ageing memory pools) garbage collectors as being found in our German
version of LLVM, the brilliant LuaJIT DYNASM enginge, which has almost
everything, that is publically considered as 'state of the art' JIT
compiler technology.
>>
>> Of course DYNASM is faster, smaller, better than LLVM and generates
machine code for even smallest embedded devices (even runs on those!!!),
has the much superiour "Four Color Multi Color, Multi Generational Mark
Sweep GC".
>>
>> That little thing with the long name is far superior to every other
Garbage Collector, i've seen in my life:
>>
>> http://wiki.luajit.org/SSA-IR-2.0
>> http://wiki.luajit.org/New-Garbage-Collector
>>
>> Lua is a very Lisp like language, since its smallest data structure is a
two (cons) cell unit, one data and one pointer to next cell. But comes with
INFIX notation.
>>
>> And since Lua Programming Language data structures are so similar to
those of Lisp, there also is a Lisp port onto that tiny LuaJIT DYNASM
engine, kind of transpiler, written in - Lua! Piece of cake in terms of LoC
(compare to pil21):
>>
>> https://github.com/bakpakin/Fennel/blob/master/README.md
>>
>> And, of course, you get C speed with that stuff, with far lesss lines of
code Maintainable, security reviews can easily be done ... much smaller
memory footprint, much faster JIT compile times, thanks to DYNASM:
>>
>> http://luajit.org/dynasm.html
>>
>> Needless to say, that this stuff is far superior to anything you can
find made by US Foundations with their billions of lines of unmaintainable
bloat ...
>>
>> I am using that stuff now since a while - both the superior algorithms
as well as some of our own German/EU software stacks and i only can tell
you, what i've already mentioned:
>>
>> "Don't use US Software Stacks!!! - Billions of lines of code, millions
of bugs, thousands of NSA backdoors, hundreds of slow algorithms!!!"
>>
>> I hope, you regard my "findings" for you quite interesting and
convincing, see you using next generation of high quality software, that
does not fall under US software export restrictions, since it's - "Made in
Germany"!!! ;-)
>>
>> Finally you also should have a look into the last link, "Bit Twiddling
Hacks in C". You will be _very surprised_ what you will find there.
Needless to say, that this collection of tips and tricks also applies to
other programming languages, making your code much faster (and much
less readable and understandable, if you don't put a link into the
comments)! ;-)
>>
>> Have fun!
>>
>> Best regards, Guido Stepken
>>
>> ¹) https://en.wikipedia.org/wiki/Fusion_tree
>> ²) https://en.wikipedia.org/wiki/Exponential_tree
>> ³) https://en.wikipedia.org/wiki/Fenwick_tree
>> ⁴) https://graphics.stanford.edu/~seander/bithacks.html
>
> --
> John Duncan

Re: divmod?

[Guido Stepken]

Plain wrong. Christian Schafmeister will teach you the use of Lisp in
high(est) end number crunching:

https://youtube.com/watch?v=8X69_42Mj-g

He's the Super Brain behind all the compute stuff of that famous Genomic
Reasearch Institute in NY (proteine folding ... Corona) ... ;-)

In fact, he's using the AI Lisp language to compose all those mighty C/C++
libraries to new libraries. Means: His Lisp AI is (re-)writing software.

I fear, you're a decade behind of what's 'state of the art' in programming!
Lisp, until today, is a highly important language. It also optimizes
machine code within GCC, generating highest efficient machine code for any
CPU in the world  - see MELT, a Lisp dialect:

http://www.starynkevitch.net/Basile/gcc-melt/

Binding GSL (GNU Scientific Library) and magic OpenBLAS (searching through
huge graph structures in zero time) to PicoLisp is piece of cake.

https://picolisp.com/wiki/?interfacing

Automated marshalling and unmarshalling C interfaces in Lisp is a
nobrainer, simply extract .c header files. Finished!

Have fun!

Best regards, Guido Stepken

Am Sonntag, 3. Mai 2020 schrieb John Duncan :
> For heavy number crunching, picolisp might not be appropriate. In modern
systems you would probably want something that used the vector
instructions. But if it’s a few divisions here and there, you’d be
surprised how little the efficiency in clock cycles  matters anymore.
> On Sun, May 3, 2020 at 14:28 Wilhelm Fitzpatrick  wrote:
>>
>> >> I'm not finding such a thing in the function reference, but asking on
the off chance I'm
>> >> overlooking it. Is there a way in Picolisp to get a division result
and remainder as a single
>> >> operation?
>> > Sure
>> > http://ix.io/2kBM
>>
>> Thanks! But as Alex intuited, I was looking to leverage the underlying
>> processor operation that returns both parts of the integer divide in a
>> single operation. But if I follow his response correctly, the cost of
>> building the memory representation of the answer swamps the actual cost
>> of the divide, and that's going to be similar regardless of if the
>> divide and remainder wind up being one machine instruction or two.
>>
>> -wilhelm
>>
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
> --
> John Duncan

Talking about algorithms and their BIG(O) behaviour, efficiency, other JIT IR compilers ...

[Guido Stepken]

Certainly you've heard of Fusion² Trees, Exponential² Trees, Ryabko³ Trees,
Bit Twiddling Hacks⁴ in C ... this is, what i consider the high class of
programming excellence, every programmer not only should have heard of, but
also should have implemented on his/her own.

This class of algorithms shows much better BIG(O) behaviour, often
O(log(log(n)) or O(log₃₂(n)) on 32 bit, O(log₆₄(n)) on 64 bit in searching
through vasts amounts of data in almost ZERO time.

They're quite rare in e.g. Apache Foundation or Linux Foundation software
("pile of shit") packages, since they allow even better search times on a
$25 Raspberry Pi Zero than on a $100.000 28 Core Intel Dual CPU Xeon
machine. Of course, this is not in the interest of US industry.

Most interesting for Lisp implementors is the Ryabko aka Fenwick Tree,
since it easily allows implementing a highly efficient multi generational
(ageing memory pools) garbage collectors as being found in our German
version of LLVM, the brilliant LuaJIT DYNASM enginge, which has almost
everything, that is publically considered as 'state of the art' JIT
compiler technology.

Of course DYNASM is faster, smaller, better than LLVM and generates machine
code for even smallest embedded devices (even runs on those!!!), has the
much superiour "Four Color Multi Color, Multi Generational Mark Sweep GC".

That little thing with the long name is far superior to every other Garbage
Collector, i've seen in my life:

http://wiki.luajit.org/SSA-IR-2.0
http://wiki.luajit.org/New-Garbage-Collector

Lua is a very Lisp like language, since its smallest data structure is a
two (cons) cell unit, one data and one pointer to next cell. But comes with
INFIX notation.

And since Lua Programming Language data structures are so similar to those
of Lisp, there also is a Lisp port onto that tiny LuaJIT DYNASM engine,
kind of transpiler, written in - Lua! Piece of cake in terms of LoC
(compare to pil21):

https://github.com/bakpakin/Fennel/blob/master/README.md

And, of course, you get C speed with that stuff, with far lesss lines of
code. Maintainable, security reviews can easily be done ... much smaller
memory footprint, much faster JIT compile times, thanks to DYNASM:

http://luajit.org/dynasm.html

Needless to say, that this stuff is far superior to anything you can find
made by US Foundations with their billions of lines of unmaintainable bloat
..

I am using that stuff now since a while - both the superior algorithms as
well as some of our own German/EU software stacks and i only can tell you,
what i've already mentioned:

"Don't use US Software Stacks!!! - Billions of lines of code, millions of
bugs, thousands of NSA backdoors, hundreds of slow algorithms!!!"

I hope, you regard my "findings" for you quite interesting and convincing,
see you using next generation of high quality software, that does not fall
under US software export restrictions, since it's - "Made in Germany"!!! ;-)

Finally you also should have a look into the last link, "Bit Twiddling
Hacks in C". You will be _very surprised_ what you will find there.
Needless to say, that this collection of tips and tricks also applies to
other programming languages, making your code much faster (and much
less readable and understandable, if you don't put a link into the
comments)! ;-)

Have fun!

Best regards, Guido Stepken

¹) https://en.wikipedia.org/wiki/Fusion_tree
²) https://en.wikipedia.org/wiki/Exponential_tree
³) https://en.wikipedia.org/wiki/Fenwick_tree
⁴) https://graphics.stanford.edu/~seander/bithacks.html

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

You guys haven't read or understood carefully. I said, that i have not
found any evidence to distrust IBM or to think, that IBM would be sitting
in the NSA boat. IBM, much earlier than other companies, did open source
everything, Power firmware included:

https://github.com/open-power

On the other hand, UEFI.sources never were published, could be compiled
through. Same as Intel IME (Minix) Firmware.

Doesn't mean, that i, in fact, do use IBM stacks for my own mission
critical businesses.

Have fun!

Am Mittwoch, 29. April 2020 schrieb :
> On Tue, 28 Apr 2020 17:57 -04:00, andr...@itship.ch wrote:
>> On 28.04.20 22:53, Guido Stepken wrote:
>> >
>> > (Blathering removed.)
>>
>> You generalize too broadly in one sentence and then contradict
>> yourself the next.
>
> ^^ This. ^^
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

"gcc -fanalyzer" will fundamentally change safety of C programs, such as
Linux, GNOME, DQlite (distributed SQLite), Cython, Python, Crystal, Ruby,
NIM, ZIG, Vala/Genie ... but also the C compiled version of PicoLisp ...

https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/

Plenty of proactive security patches are coming out now minutely, which
vastly improve complete Linux environment.

Sadly, Microsoft does _not profit_ from the magic abilities of that new
flow analyzer in GCC. Windows, Office ... all written in C++! :-D

Have fun!

Am Dienstag, 28. April 2020 schrieb Edgaras Šeputis :
> Here is the thing, in consumer space, but not even there in a way "nobody
> cares about security". Not in that nobody cares, but there are more
> important things than security, like some particular ability, and for now
> it USA stuff or severe hits in performance, or even nothing at all. Which
> in such cases people will rightfully so take some security concerns over
> not being able to do anything, or things that competitors are doing. For
> now penetration of those technologies are super low, and it remains to be
> seen where they will go. I also have hopes that someone will unseat if not
> crush at least one company - Intel, but more for all the underhanded shit
> they done to win "top dog" position in market. Also Linus makes some very
> pragmatical valid points about security too:
>
https://www.cio.com/article/2434264/torvalds-calls-openbsd-group--masturbating-monkeys-.html
,
> which applies here full well. You can pipe all you want a bout this
> insecure or that with backdoor no one will care until you deliver
> competitive features, not with attitude like you shown sometimes. You go
> this is shit that will be most amazing and thus don't use this. Well seems
> people can not use 'that', so in a mean time they will keep using 'this'.
> And 'that' will have to compete, and dropping potential allies cause today
> they use 'this' is just stupid. Unless you think stuff can not be ported
> later on.
>
> On Tue, Apr 28, 2020 at 1:44 PM Guido Stepken  wrote:
>
>> I think, it's decided now, that China is going to remove US hardware, US
>> software and US protocols.
>>
>> In fact, US software stacks, especially those Open Source by Apache,
Linux,
>> .. "Foundations" have become a *huge pile of shit*:
>>
>> *Billions lines of code, millions of bugs, thousands of NSA backdoors,
>> hundreds of intentionally slowed down algorithms, sponsored mainly by
>> Intel*
>>
>> Security Reviews? Impossible! Removing NSA contributed code, e.g.
SELinux,
>> backdoors even deeply sticking in Linux TCP/IP stack? Impossible!
>>
>> Removing Intel IME Spy Firmware Processor (MINIX) from all 2008 later
>> motherboards (even in notebooks) - Impossible!
>>
>> To give you an idea, what's all running in parallel to your "Booted OS"
of
>> choice:
>>
>>
>>
https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf
>>
>> In fact, UEFI is an Operating System, that is running parallel to your
own
>> OS. You're booting Windows, Linux on a kind of Hypervisor, the
underlying,
>> hidden Minix OS (a tiny UNIX Clone living in North Bridge), has *full
>> access* to. Means: Disk, memory, keyboard, network ...
>>
>> NSA can access all of your passwords, certificates, ... any time. Even
when
>> main processor is switched off, the Cortex-A15 core can activate power
for
>> e.g. SSD, network on its own, even when Intel main CPU is deactivated.
>>
>> And i fear, the little "US problem" with surveillance, spying on other
>> countries industries to gain strategic advantage and control over forein
>> industries, politicians, CEOs ... is much bigger than anybody can
imagine

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

I think, it's decided now, that China is going to remove US hardware, US
software and US protocols.

In fact, US software stacks, especially those Open Source by Apache, Linux,
.. "Foundations" have become a *huge pile of shit*:

*Billions lines of code, millions of bugs, thousands of NSA backdoors,
hundreds of intentionally slowed down algorithms, sponsored mainly by Intel*

Security Reviews? Impossible! Removing NSA contributed code, e.g. SELinux,
backdoors even deeply sticking in Linux TCP/IP stack? Impossible!

Removing Intel IME Spy Firmware Processor (MINIX) from all 2008 later
motherboards (even in notebooks) - Impossible!

To give you an idea, what's all running in parallel to your "Booted OS" of
choice:

https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf

In fact, UEFI is an Operating System, that is running parallel to your own
OS. You're booting Windows, Linux on a kind of Hypervisor, the underlying,
hidden Minix OS (a tiny UNIX Clone living in North Bridge), has *full
access* to. Means: Disk, memory, keyboard, network ...

NSA can access all of your passwords, certificates, ... any time. Even when
main processor is switched off, the Cortex-A15 core can activate power for
e.g. SSD, network on its own, even when Intel main CPU is deactivated.

And i fear, the little "US problem" with surveillance, spying on other
countries industries to gain strategic advantage and control over forein
industries, politicians, CEOs ... is much bigger than anybody can imagine.

In Europe, we now have Exokernels (similar to Hypervisors, Microkernels)
running on safe hardware (e.g. ARM Cortex-A53/55 (no Spectre/Melissa
vulnerability, like Odroid N4, RPi 3, ...) with *"UNIX as library"* running
on top, programmed in an old, rock solid funtional, compiled language named
*OCaml*. Also see ReasonML. 10x faster, 100x lesser memory footprint for
same (web, database, GUI) functionality.

New upcoming European "Gaia-X" Cloud will be built with that stuff
exclusively (security reviews ongoing), leaving US companies and their
technologies in the dust. China, India, South America are going similar
ways.

Also see "Shakti RISC-V" Project: https://shakti.org.in/

RISC-V foundation recently has been moved to Switzerland. Finished with US
influence. We're taking them out of business now. With "we" i mean whole
world with 7 billion people outside the US.

Have fun!

P.S.: I neither smoke nor am i taking drugs!

Am Dienstag, 28. April 2020 schrieb Edgaras Šeputis :
> Now you seriously smoking something. China's bullshit new IP was not
accepted by anyone, no one wants their authoritarian extensions, and say
whatever you want about US (and one can say a lot of shit about them and be
quite correct), US is still millions of miles better than China and if you
are running from US, you should run even faster from China
> I'll just point that for some time now you are acting like some kind of
weird troll, making some seemingly interesting pionts, even while
displaying crappy attitude, then spouting complete bullshit about China
being better than US.
>
> On Tue, Apr 28, 2020 at 12:27 AM Guido Stepken  wrote:
>>
>> Seems, you haven't the slightest idea, what's going on in world:
>>
>> China is changing gears, decoupling from TCP/IP protocol. Means: USA
becoming isolated. It's a 320 million people state, making just 5% of
global population.
>>
>>
https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/
>>
>> China, in fact, is double as big as Europe and the US together. Apart
from that, not only half of USA is bankrupt, with Corona now it's ⅔

Re: Digging into Symbols

[Guido Stepken]

Certainly. But how is it *implemented* internally? Mostly you suffer
massive performance loss when prepending, because complete linked list gets
moved to a new place in memory. If internal representaion ist a double
cell, one value, pointer to next, then you quickly suffer CPU cache misses.
Wild jumps across memory with upto 18 CPU waitstates for random access.
Means: Your proud 4 GHz machine gets slower than a 250 MHz embedded ESP32
ARM CPU. E.g. Python dqueue doesn't show any performance loss here.

Have fun!

Am Dienstag, 28. April 2020 schrieb Wilhelm Fitzpatrick :
> On 4/27/20 2:42 PM, Guido Stepken wrote:
>
>> In most Lisp languages, you only can "append" to a list, never
"prepend".:
>
> "Prepend", aka "add to the beginning" seems the natural (and
non-destructive) operation of Lisp, e.g.
>
> (cons 9 (1 2 3)) -> (9 1 2 3)
>
> ..perhaps that is what you meant?
>
> -wilhelm
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Digging into Symbols

[Guido Stepken]

In most Lisp languages, you only can "append" to a list, never "prepend".

Python, e.g., has such structures:
https://www.geeksforgeeks.org/deque-in-python/

The "*d*ouble *e*nded *queue*". Appending, prepending, Python simply lets
you do, what you want! ;-)

Mighty, mighty stuff, highly efficient!

Have fun!

Am Montag, 27. April 2020 schrieb Wilhelm Fitzpatrick :
> I've been digging down to really understand the symbol implementation in
Picolisp, since symbols are used for so many purposes within the language.
>
> One surprising thing I learned last night is that (get ...) has a side
effect! It moves the key that was accessed to the head of the symbol
"tail". I assume this is a performance optimization to cause recently
accessed properties to "bubble up" to the front of the list in case they
are re-accessed soon.
>
> A few questions:
>
> 1. I understand why (cdr) doesn't function on a symbol (semantically it's
not a pair) but I'm curious why (car) is allowed to work (returning the
VAL)?
>
> 2. Is there anyway within the REPL to inspect the tail structure of the
symbol directly? This is mostly from curiosity.
>
> 3. Again from curiosity, I'm wondering why the bytes of the name are
seemingly stored "backwards"? I'm assuming this also provides some
performance optimization.
>
> -wilhelm
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Seems, you haven't the slightest idea, what's going on in world:

China is changing gears, decoupling from TCP/IP protocol. Means: USA
becoming isolated. It's a 320 million people state, making just 5% of
global population.

https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/

China, in fact, is double as big as Europe and the US together. Apart from
that, not only half of USA is bankrupt, with Corona now it's ⅔.

Means: Germany also is saying 'goodbye' to USA, US technology, US
protocols, US standards ...

'Show me the code' ... what code? I don't publish on M$ owned Github or M$
owned NPM and i will never do. Not a single US owned server will be allowed
to carry a singe bit of my code ...

Do i want to get into jail for nothing like Meng Wanzhou? No evidence, no
proof. Or Assange, Guantanamo prisoners? See 'Military Commissions Act'.

Means: Everything now gets isolated from US software/hardware
implementations. There are even NSA Backdoors implemented in hardware, e.g.
Broadcom Wifi silicon. All Open Source repositories (Github, NPM, Anaconda,
NuGet) now are poisined by NSA backdoors!!!

Seems, most of you guys haven't yet understood, what USA is aiming at:
Total control of all software, hardware, communication on the world.

Sorry, but simply don't care your little provocation. Either you agree with
US strategies or you do down under!

I've already warned Alex not to use US software stacks (LLVM) for Picolisp
.. but he simply doesn't listen.

Picolisp, for me, now is dead, burnt. I have to reimplement it now, because
plenty of my code uses Picolisp. As i've already mentioned: Picolisp is a
genius strike, carries plenty of pretty usable ideas in it.

Well, using Picolisp, with mighty LLVM (420 Mbytes compressed bloat,
backdoor injections by NSA everywhere, no security review possible) will be
the last Picolisp for me. Pil21 is a NO-GO! Finished, for all times.

You must know, how your friends are, Alex doesn't.

Have fun!

Am Montag, 27. April 2020 schrieb Danilo Kordic :
> Guido Stepken:
>> [...]
>
>   ""Talk is cheap, show me the code."" -- Linus Torvalds
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: MiniPicolisp Questions

[Guido Stepken]

Nope. Polymorphic Inline Caching. And why shouldn't JIT compilers use MMU
"memory address violation exception" to check for end of range? Same for
TLB.

I could flood you with hundreds of papers about that. I am using that all
time.

Of you were right and such knowledgeable, PicoLisp would run fast. But it
doesn't. So take my pointers and - learn something new! ;-)

Best regards, Guido

Am Mittwoch, 22. April 2020 schrieb Alexander Burger :
> On Wed, Apr 22, 2020 at 03:49:41PM +0200, Guido Stepken wrote:
>> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a
MMU
>> and you get "Memory Access Violation", so no pointer rage checks needed
to
>> be handled by CPU any longer.
>
> Sigh, you don't understand at all how a Lisp interpreter works.
> It is *all* type checks. We have dynamic data. Please stop
> talking about things you have no clue of!
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: MiniPicolisp Questions

[Guido Stepken]

Well, we have year 2020, not Dijksra 1978. Even embedded systems have a MMU
and you get "Memory Access Violation", so no pointer rage checks needed to
be handled by CPU any longer. Those formerly needed range checks, eating up
clock cycles, now are deeply sticking in MMU and IOMMU ... Bang! -
Exception!

Also reading about modern "multi generational garbage collectors" will
explain, why garbage collected (functional, pure OO) languages have kept up
with C/C++ statically machine code. Julia language, sitting on FemtoLisp
JIT engine, in some times even ist faster than C.

Have fun!

Am Mittwoch, 22. April 2020 schrieb Alexander Burger :
> Hi Geo,
>
>> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
>> it limit the memory for each data type?
>
> Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
terrible
> solution. Doesn't scale, and is extremely inefficient due to the necessary
> pointer range checks.
>
> PicoLisp's way is far superior, because the tag bits come "free", they are
> implicit by the natural pointer alignments.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: MiniPicolisp Questions

[Guido Stepken]

I meat: "0xE000 for everything, that must be persisted to disk". There, of
course, you can also reserve three slots for float, integer, string ...

Best regards, Guido

Am Mittwoch, 22. April 2020 schrieb George-Phillip Orais <
orais.georgephil...@gmail.com>:
> Hi Guido,
> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
it limit the memory for each data type? Like what if the application uses
only integers so does it mean it cannot use the memory location for float
and strings?
>
> BR,
> Geo
> On Wed, Apr 22, 2020 at 8:44 PM Guido Stepken  wrote:
>>
>> Hi Kashyap!
>>
>> Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
indicating type or as persistence flag (ORM-wrapper) is the old fashioned
way. It unnecessarily costs cycles, reduces precision ...
>>
>> The modern, "fully functional" (no state bits anywhere!) - and correct -
way would be to indicate type by its position in memory:
>>
>> 0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000
everything, that have to be persisted do disk. Let another CPU do the
persistence! ;-)
>>
>> Have fun!
>>
>> Best, Guido Stepken
>>
>> Am Mittwoch, 22. April 2020 schrieb C K Kashyap :
>> > Thanks Alex,
>> > I was thinking of increased memory space - not exactly doubling -  I
was thinking it would just be one additional byte per CELL. Ofcourse this
additional byte would not have the same lifetime of the CELL so it should
not need any extra management.
>> > I feel encouraged - I'll give it a try :)
>> > Regards,
>> > Kashyap
>> > On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger 
wrote:
>> >>
>> >> Hi Kashyap,
>> >>
>> >> > About the the CELL having an additional byte, I meant that the CELL
size
>> >> > would be 2*WORD + 1... that should work too right? I would not need
any
>> >> > masking in that case.
>> >>
>> >> I see. Yes, that would work. But it would either double the memory
usage, or
>> >> require some management of this additional byte (e.g. in a separate,
parallel
>> >> byte heap), which complicates things a lot more than it benefits.
>> >>
>> >> ☺/ A!ex
>> >>
>> >>
>> >> --
>> >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>> >

Re: MiniPicolisp Questions

[Guido Stepken]

Hi Kashyap!

Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
indicating type or as persistence flag (ORM-wrapper) is the old fashioned
way. It unnecessarily costs cycles, reduces precision ...

The modern, "fully functional" (no state bits anywhere!) - and correct -
way would be to indicate type by its position in memory:

0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000
everything, that have to be persisted do disk. Let another CPU do the
persistence! ;-)

Have fun!

Best, Guido Stepken

Am Mittwoch, 22. April 2020 schrieb C K Kashyap :
> Thanks Alex,
> I was thinking of increased memory space - not exactly doubling -  I was
thinking it would just be one additional byte per CELL. Ofcourse this
additional byte would not have the same lifetime of the CELL so it should
not need any extra management.
> I feel encouraged - I'll give it a try :)
> Regards,
> Kashyap
> On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger 
wrote:
>>
>> Hi Kashyap,
>>
>> > About the the CELL having an additional byte, I meant that the CELL
size
>> > would be 2*WORD + 1... that should work too right? I would not need any
>> > masking in that case.
>>
>> I see. Yes, that would work. But it would either double the memory
usage, or
>> require some management of this additional byte (e.g. in a separate,
parallel
>> byte heap), which complicates things a lot more than it benefits.
>>
>> ☺/ A!ex
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: picoLisp 19.12: variable length array in structure fixes

[Guido Stepken]

Interesting. You might have also run into no "excution bits" on Intel
hardware:

https://releases.llvm.org/8.0.1/docs/SpeculativeLoadHardening.html

https://en.wikipedia.org/wiki/NX_bit

In Lisp, "code is data, data is code". There simply is no separation the
like - "code here, data there". Typical Lisp JIT emits machine code, where
needed.

This is a common and well known problem. Unsure, if you can disable that
behavior in Apple BIOS. And even then you must recompile with options.

US hardware and software stacks increasingly become nebulous.

Have fun, Guido Stepken

Am Dienstag, 21. April 2020 schrieb Andras Pahi :
> Hi,
>
> Maybe not related to this one, but on Mac OS X the heap size is limited
> to 65532KB. On startup picolisp fails to set the unlimited stack size,
> And use the actual ulimit so on the first run I’ve got a SIGSEGV running
> code2015.l
>
> Andras
>
>
>> On 2020. Apr 21., at 10:38, Mike  wrote:
>>
>> hi all,
>>
>>> If you are interested I have patched the 19.12 32bit sources to compile
without GCC.
>>> I have attached the changed files: pico.h, main.c, apply.c and flow.c
>>>
>>> Since clang does not support variable length array in structures I
allocate the bindFrame
>>> with alloca() and provided a macro in pico.h to ease this: allocFrame()

Re: Replace LLVW - Was: Stop using US controlled software stacks!!!

[Guido Stepken]

Hi Alex!

Webassembly already is ported to almost all architectures, where browsers
are available. All those Webassembly containers in those browsers takes
Binary Lisp code and do translate it to native machine code.

If you would please have a look at that giant list of programming
languages, that transpile to that "Binary Lisp" for being executed in
Webassembly browser containers.

https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md

There are couple of server side Webassembly containers out there, that do
either interpret Webassembly Binary Lisp code or can JIT that.

Means: Your PicoLisp .l code could *directly* run in any browser and on any
hardware in such a Webassembly container. All you need to do is to tokenize
your PicoLisp code. That's one day of work.

I still haven't the slightest idea, what you are doing there with pil21 and
LLVM. Don't use buggy, backdoored US software stacks, such as LLVM, GCC,
VC++ or JVM any longer!

We simply *don't need* them!!!

Webassemby, by JITing Binary Lisp code to machine code already has
everything in it! It's kind of universal AST to machine code compiler,
where the AST only is represented in Binary Lisp form.

I've recently completed my ASIC Lisp machine, just waiting for the board
designers to get finished. No CPU of any kind neccessary any longer.
PicoLisp .l code then also could directly run on that ASIC. And much
faster, than you can imagine! ;-)

Best regards, Guido Stepken




Am Dienstag, 21. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
> On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote:
>> But this is not the point. The point is, that MetaCola was a code
>> generator, where you can implement whole programming languages within
just
>> a few lines of code.
>> ...
>> OMeta Parser/Interpreter has been translated into many programming
>> languages and is used almost everywhere now to implement DSL (Domain
>> Specific Languages).
>> ...
>> 153 Lines of OMeta code:
>> ...
>> I almost completely stopped writing code in any programming language by
>> hand, since there is not a single problem that cannot be solved with
OMeta
>
> Wonderful! That saves all our problems. No reason to stop pil21 :)
>
> LLVM is only needed to translate the IR code, generated from PicoLisp
pil21
> sources, to the target machine language.
>
> You can surely write for us such a translator in 160 lines. For now,
targets
> x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would
be
> enough.
>
> Issue closed! :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: MiniPicolisp Questions

[Guido Stepken]

Hi Kashyap!

Dividing up Lisp Cells (Atoms) in RAM/ROM - i think, you're referring to
this: https://picolisp.com/wiki/-A265.html has recently got another aspect:
https://en.wikipedia.org/wiki/Remote_direct_memory_access

RDMA, Remote Direct Memory Access.

With Picolisp and especially miniPicoLisp you can build one (logically)
giant Lisp machine across hundreds of servers. I'm using that since a
couple of weeks now using some Nokia 400 GbE cards and i must say: It works
pretty well! ;-)

Distributed in memory database, partly with persistance, Graph, PILOG on
top ...

It's the simlicity in PicoLisp that allows to do unbelievable things.

As i've already said: PicoLisp is a *genius strike*. You can easily do
things, that only would be available if you would use those multi million
line US software stacks, with all their bugs, NSA backdoors, whatever.

Have fun!

Best, Guido Stepken

Am Dienstag, 21. April 2020 schrieb C K Kashyap :
> Hi Alex et al,
> I've been working on miniPicoLisp source with the idea of making it more
easy to understand - granted, it's really simple but it's simplicity may
not be apparent from looking at the source to some (such as myself). For
instance, it took me some time to get what's going on with the optimized
string storage. So, one of the changes I did was to switch to 7 bits for
all. So I am trying to alter the code to make it easy for guys like me :)
> I have a couple of questions
> 1. About RAM vs ROM Call me lazy but I would really appreciate a
description of how the RAM vs ROM decision is taken here (and in general
too..I mean, it is not clear to me how gen3m.c determines how something is
never written to or not)
> if (x > 0)
>Rom[x] = strdup(buf);
> else
>Ram[-x] = strdup(buf);
>
> 2. Can I try and make the CELL have an additional byte to store the TYPE
and get rid using tagged pointers? Clearly, it would be less efficient at
runtime but perhaps it would be more easy to understand. Is there any
reason that this would not work?
> Regards,
> Kashyap

Why i chose PicoLisp as main language for my projects ...

[Guido Stepken]

Hi all!

Main argument was, that only with Lisp i can mathematically, formally
proof, that my programs *are safe*. Demand for safe programs, libraries of
all kinds is going through the roof.

Base was this paper here:
http://www.cse.chalmers.se/research/group/logic/TypesSS05/Extra/lectnotes_vol1.pdf

It has a good reason, why Lisp is also deeply sticking behind Webassembly,
the standardized browser container format - and - hopefully - the new
upcoming server container format, with S-Expressions at its base:

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md

Unbelievable, all that language support, that now is translating to Lisp,
isn't it? Pure fun!

Formal verifiers - behind the scenes - then will ensure, that everything
uploaded (by customers) will precisely follow its predefined specifications
isand not doing - by evil code injection - anything other than that!
Execution will instantly terminate then. That prototype is finished now, in
the testing.

And those containers will run on ultra cheap, ultra fast - Lisp executing
ASICs with their own TCP/IP stack - in the very short future. Stay tuned.

That's why most my software now is implemented in Lisp, most parts in
PicoLisp. It's a nice, handy, easy to learn Lisp dialect and libraries are
sufficiently complete, nothing important missing.

Best of Picolisp is PILOG, the Prolog interpreter that can run on top of a
distributed, self replicating, ultra fast persisting database, that comes
for free with Picolisp, very much like (or even better) than
Closure(Script) with its ultra expensive commercial DATOMIC database.

This makes PicoLisp a total killer ... and is coming for free! That's just
unbelievable! Nothing else in the world does even come close to that
expressiveness and capabilities

Even if i am repeating myself: "PicoLisp, in its design, is a genius
strike!"

And you? What where your motives to switch to PicoLisp?

Best regards, Guido Stepken

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty :
> Hi Guido,
>
> Guido Stepken  writes:
>> Using US software stacks, even if open source and under a free license
are
>> not tolerable. For any nation, for any kind of project.
>>
>> US Cloud Act, Patriot Act, by law, force US companies as well US
>> organisations in general, such as Linux Foundation as well as Apache
>> Foundation and LLVM Foundation to comply with US law.
>
> is using google mail tolerable?

I am using US driven services and software libraries/stacks, US computer
hardware for unimportant work only. All other neither is internet connected
nor does it use any of the known US standards for communication or
encryption. I've learned my lessons! ;-)

Have fun!

Re: picoLisp 19.12: variable length array in structure fixes

[Guido Stepken]

Linux, here Debian GNU/Linux, allows parallel installation of 32/64 bit
libraries ...

https://wiki.debian.org/Multiarch/HOWTO

Sometimes "apt-get install ia32-libs" helps.

Have fun!

Am Montag, 20. April 2020 schrieb Mike :
> April 20, 2020 11:01 AM, "Andras Pahi"  wrote:
>
>> Hi Mike,
>>
>> pil32, x64 means you’ve built the contents of the src/ dir in x64 mode ?
>>
>
> pil32, x64 - means gcc and voidlinux-x64 compiled-supports multilib.
> I use pil32 and pil64 on the same machine, I always in pil64, but can
switch fast.
>
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty :
> Guido Stepken  writes:
>> Picolisp, thanks to Alex' brilliant ideas, behind the scenes, serves as
>> prototype of a new kind of "minimalistic, highly efficiency" software
>> strategy within the EU. Goal is: Back to the roots, small modules,
security
>> review everywhere, minimal hardware requirements, driving down energy
>> consumption massively.
>
> does EU fund Picolisp as part of the software strategy?

No. I said, that Picolisp ideas serve as prototype for new developments.

> If not, why and how could that be achieved?

Why should EU fund sponsor something, what's already there? Apart from the
fact, that Picolisp not really is unique. But it has plenty of nice ideas
in it.

> Where can I read about the EU software strategy?

We have a EU commission of experts and, of course, the official EU database
of sponsored EU projects. E.g. PyPy project has received continuous
funding(s). PostgreSQL Columnar Store Extension too. Pharo Smalltalk
Environment ...

Best regards, Guido Stepken

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

What about US sanctions against China about Huawei using free, open sourced
Android? What about USA advising Germany, Switzerland to stop buying gas
from Russia - see Grenell's letters to industry:

http://www.xinhuanet.com/english/2019-12/24/c_138655403.htm

(B.t.w.: Grenell's now commander in chief of all US secret services. A pure
nightmare, that guy!)

That affront even was noticed in China. And what about Apple buying and
removing Open Sourced FoundationDB from Internet?

"In March 2015 the FoundationDB Community site was updated to state that
the company had changed directions and would no longer be offering
downloads of its product. The company was acquired by Apple Inc., which was
confirmed March 25, 2015."

Never, ever trust US government, US companies, US Foundations.

Even RISC V Foundation had to move away from the US to Switzerland due to
geopolitical concerns:

https://www.theregister.co.uk/2019/11/26/riscv_foundation_switzerland/

Most people here seem to think, i would be paranoid or being a "US hater".

I fear, it's much worse than that! :-(

Again: Stop using US software stacks! Under all circumstances!!!

Best regards, Guido Stepken


Am Sonntag, 19. April 2020 schrieb Jeronimo Pellegrini <
j.pellegr...@randomnode.info>:
> [ sorry for duplacates; I've realized I have sent this from a wrong
>   From: address, so I'm sending  it again ]
>
> Hello.
>
> I don't usually write here, but I believe this is important.
>
> I agree that the tone used initialy by Guido was really bad. But
> there are strong arguments that lead to what he said.
>
> I would like to at least present the argument, even if only
> pointing to external references. Because there is one, and for
> the same reason I don't like when people go saying that "earth is
> flat", or that "there is no coronavirus" [0], because that is strongly
> disrespectful of science, I also believe that for agreeing or
> disagreeing on the subject being discussed on this thread, one would
> also need to show where the agreement or disagrement comes from.
> Scientifically -- and I'm including human sciences.
>
> The argument would not be strictly in exact sciences, and that may
> be why it is uncomfortable for programmers to actually pay attention
> to it [1]. The argument would likely go through Mumford, Foucault,
> Deleuze, Zuboff. I wont reproduce it here.
>
> However, cryptographer Phil Rogaway did write an essay that is closely
> related to that, and explains much of the core of it. It is called
> "The Moral Character of Cryptographic Work" [2], and is really
> brilliant. This as a distingueshed IACR lecture in 2015 [3]. IACR
> is the International Association for Cryptologic Research [4].
>
> So. One important thing: Lewis Mumford noticed [5] that technology
> is not always of the same kind. Sometimes it is more useful than
> damaging, and sometimes it is the other way around (the terminology he
> used is different, but it is the same). And people have been working
> on developing technology without any attention to that (nuclear energy is
> the usual first example of this. Rogaway metions the Russel-Einstein
> manifesto, for example. It was written by two exact science researchers!
> Rogaway also mentions in his text that "Academic  cryptography  used  to
> be  more  political" -- check that.
>
> A few examples may be interesting.
> With nuclear energy, there came a requirement for more authoritarianism,
> stronger vertical power structures. Why?  Because the potential for damage
> is huge. See, for example, the radioactive boy scout, David Hahn [6].
> I do recall that there was some similar incident in Europe, but couldn't
> easily find the reference.
> Besides requiring more authoritative power, nuclear energy is also
> related to several disasters, and there is thenuclear waste problem.
>
> Am example closer to programmers: deep fake. "We have neural networks, and
> we now can train deep networks" - everybody is happy. "We can use
> deep learning in videos and audios" - happier. Then comes deep fake.
> It is hard -- and will possibly become harder and harder -- to detect
> wether a video is fake or not. This could potentially lead
> both criminology and investigative journalism to the pre-photography
> era. There will be a solution, and I am afraid that it will, again,
> require an even more authoritative society (your video, photo or
> audio must have been recorded by a tivoized device with a unbreakable
> crypto module, otherwise it is useless). AND you will need to
> trust the manufacturer (they COULD use the private keys to create whatever
> fake videos they want).
>
> See... Technology is not "neutral". (Interestingly, this is also why
> darktable --

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Well, perhaps you could find a few papers about "Frank" at Viewpoint
Research homepage. Bert Freudenberg, Ian Piumarta, Alan Kay certainly have
the full "Frank" code.

But this is not the point. The point is, that MetaCola was a code
generator, where you can implement whole programming languages within just
a few lines of code. What you're seeing here is an OMeta (a MetaCola
descendant) Lisp interpreter.

http://www.tinlizzie.org/ometa-js/#Lisp

What you're seeing here is the complete Lisp machine!!!

OMeta Parser/Interpreter has been translated into many programming
languages and is used almost everywhere now to implement DSL (Domain
Specific Languages). Here a Common Lisp Implementation with OMeta:

153 Lines of OMeta code:

https://github.com/thiago-silva/cl-ometa/blob/master/src/ometa-parser.g

Means: What you're seeing there, that's the *complete* Common Lisp parser
and Interpreter ...

I use it all the time, not only to implement new languages, compilers, but
also to design my own FPGA and ASIC CPUs, my compilers then are generating
code for. I directly parse any programming language with OMeta and
transpile to VHDL. Only a couple of minutes later i can upload my "CPU of
choice" onto my FPGA board.

The complete toolchain (parser, lexer, compiler) is automatically
generated. And after running a couple of tests i can handover everything to
my customer(s).

I almost completely stopped writing code in any programming language by
hand, since there is not a single problem that cannot be solved with OMeta
.. New is, that you also can generate your own CPU (implemented in FPGA or
much faster ASIC) and compiler, tools in one go. ASICs go up to 10 GHz
clock frequency, ultra fast!

You can easily find your OMeta Parser/Interpreter of your language of
choice in Google.

Best regards, Guido Stepken

Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty :
> Guido Stepken  writes:
>> That group implemented a whole operating system in MetaCola language
within
>> 20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver
..
>> everything included, called "Frank" for Frank - enstein.
>
> interesting, where can I learn more?
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Tiny C Compiler

[Guido Stepken]

Well, perhaps i may recommend you an excellent course into "C system
programming". IMHO it's basic knowledge, nobody can succeed without. This
guy is a highly talented teacher, IMHO.

Example lesson, worth watching at first:
http://cs-education.github.io/sys/#/chapter/5/section/0/activity/0

Here the overview: http://cs-education.github.io/sys/#lessons

The book: https://github.com/angrave/SystemProgramming/wiki

The online IDE and compiler: http://cs-education.github.io/sys/#VM

I am absolutely sure, that after you will have completed these short
lessons each, your little "problem" with replacing a C macro by C code also
will disappear magically. ;-)

Best regards, Guido Stepken

Am Dienstag, 14. April 2020 schrieb C K Kashyap :
> Thanks Guido,
> I was not able TCC to align the functions though :(
> Regards,
> Kashyap
> On Mon, Apr 13, 2020 at 2:05 PM Guido Stepken  wrote:
>>
>> That's kind of tabulator for structs of data in memory .. only of real
use for handing over to vector instructions (SSE, AVX2, AVX512 ... ARM
NEON). It's a GCC thing, not a C standard! ;-)
>>
>> https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro
>>
>> Hope, that helps.
>>
>> Am Montag, 13. April 2020 schrieb C K Kashyap :
>> > Hi all,
>> > I just noticed that TCC was mentioned in another thread so I wanted to
share my experience with it. I had tried to build miniPicoLisp with it but
unfortunately, TCC does not seem to generate aligned functions :( it did
not seem to honor  __attribute__((aligned))
>> > Does anyone else have any experience with using TCC to build
miniPicoLIsp or PicoLisp for that matter?
>> > Regards,
>> > Kashyap

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Ok. Fine. Then let's look, how many lines it needs to write your own
compiler. Means: Source language -> Windows .exe binary.

What do you think, how many lines are needed to generate 64-bit Machine
code COFF executable format for Intel, AMD Ryzen, Thread Ripper, EPYC on
Windows?

I can tell you: 100 lines!!!

https://github.com/d3dave/brainfuck-x64/blob/master/compile.py

You are not "teaching" the right things, IMHO. Lisp -> x64 compiler is just
a few lines longer, since you have to handle multiple stack machines.
That's all!

Compare to 2,5 million lines of LLVM code. Do you understand me now?

Best regards, Guido Stepken


Am Sonntag, 19. April 2020 schrieb Jo-To Schäg :
> Dear Guido,
> all our time on earth is limited. We all got our own priorities.
> I think the PicoLisp community gladly spends time teaching people. Even
multiple times.
> However the PicoLisp community does not like to solve problems for other
people.
> Especially if it is motivated for political reasons.
> Do not expect Alex to spend his time on satisfying your paranoia or
political motivations.
> You are weary of the giants of muscle and steel, I come from Cyberspace,
the new home of Mind. On behalf of the future, I ask you of the past to
leave us alone. You are not welcome among us. You political motivations
have no sovereignty where we gather. - inspired by the Declaration of
Cyberspace
> Also you do not need to leave the community but at least stop bothering
Alex about your political opinions.
> We have heard you concern thrice. As far as i see we only use LLVM to
translate LLVM-IR to some CPU architecture, so we only depend on the code
for that.
> You could write your own LLVM-IR to x86 translator if you are bothered by
LLVM itself.
>
>
>
> On Sun, 19 Apr 2020 at 15:54, Guido Stepken  wrote:
>>
>> Alex, this is not the point. One day LLVM will inject trojan code,
because US government, by law, tells them to do so!
>>
>> With Cloud Act and Patriot Act US government can advise any US company
or organisation to implement evil code.
>>
>> Can you do a full code review at every update coming for LLVM? I can't!
Nobody can! 2.5 million lines is out of anybody's reach!
>>
>> 100 bytes more in a binary can make a *huge difference* from security
oint of view. Do you always know, why LLVM suddenly is generating bigger
code? Can be everything. E.g. this:
>>
>> https://gistgithub.com/DGivney/5917914
>>
>> TCC, i can review any time  code is so tiny. Well ok, TCC binary
code is not as highly optimized in terms of speed, but AMD processor
microcode does compensate that. Differences to GCC -O3 or LLVM - in
practice - have become negligible.
>>
>> TCC always is fast enough. And i repeat: Stop using US software stacks!
>>
>> Best regards, Guido Stepken
>>
>> Am Sonntag, 19. April 2020 schrieb Alexander Burger :
>> > Hi Guido,
>> >
>> >> Look at LLVM generated bloat and compare with Nokolisp. Less is
more!!! In
>> >> terms of size as well as of security.
>> >
>> > True, LLVM is huge (as is gcc, and other equivalent systems), but this
is
>> > irrelevant because I *use* it only to translate *my* code.
>> >
>> > The generated pil21 'picolisp' binary is only a few percent larger
than the
>> > assembly version of pil64.
>> >
>> > ☺/ A!ex
>> >
>> > --
>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>> >

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Alex, this is not the point. One day LLVM will inject trojan code, because
US government, by law, tells them to do so!

With Cloud Act and Patriot Act US government can advise any US company or
organisation to implement evil code.

Can you do a full code review at every update coming for LLVM? I can't!
Nobody can! 2.5 million lines is out of anybody's reach!

100 bytes more in a binary can make a *huge difference* from security oint
of view. Do you always know, why LLVM suddenly is generating bigger code?
Can be everything. E.g. this:

https://gist.github.com/DGivney/5917914

TCC, i can review any time  code is so tiny. Well ok, TCC binary code
is not as highly optimized in terms of speed, but AMD processor microcode
does compensate that. Differences to GCC -O3 or LLVM - in practice - have
become negligible.

TCC always is fast enough. And i repeat: Stop using US software stacks!

Best regards, Guido Stepken

Am Sonntag, 19. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
>> Look at LLVM generated bloat and compare with Nokolisp. Less is more!!!
In
>> terms of size as well as of security.
>
> True, LLVM is huge (as is gcc, and other equivalent systems), but this is
> irrelevant because I *use* it only to translate *my* code.
>
> The generated pil21 'picolisp' binary is only a few percent larger than
the
> assembly version of pil64.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

8k ... well, looks like totally bloated ... somebody implemented Ian
Piumarta's Lysp in Free Pascal, using 192 lines of code only. I haven't
tested, but should come out at under 4k, one memory page for the binary.

https://github.com/tangentstorm/lysp

Finally, to execute Lisp like code, you only need to implement a lambda
calculus, perhaps some alpha, beta reductions, caching on top to gain some
speed ...

That group implemented a whole operating system in MetaCola language within
20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver ...
everything included, called "Frank" for Frank - enstein.

I've seen that "Frankenstein OS" booting on bare Intel metal and working
quite well.

Have fun!

Am Sonntag, 19. April 2020 schrieb Alexander Burger :
> On Sun, Apr 19, 2020 at 06:10:25PM +0900, George-Phillip Orais wrote:
>> You mentioned nokolisp, I also tried that and from what I remember the
>> source code was only runnable on an old DOS?
>
> Then 8kLisp is even better:
>
>https://software-lab.de/8kLisp.tgz
>
> It run on CP/M, and the whole interpreter binary 8kl.com has 8192 *bytes*

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Am Sonntag, 19. April 2020 schrieb :

Picolisp, thanks to Alex' brilliant ideas, behind the scenes, serves as
prototype of a new kind of "minimalistic, highly efficiency" software
strategy within the EU. Goal is: Back to the roots, small modules, security
review everywhere, minimal hardware requirements, driving down energy
consumption massively.

That's why i am so upset. LLVM definitely is the wrong way: It's pure bloat!

Regards, Guido

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Hi Alex!

I have enough proof, that USA is weaponizing its whole developer community
to spy upon us. Facebook SDK for Android, in fact, not only is a highly
sophisticated library for programming Android Apps, but also a spy tool,
that copies all contents, your business contacts, ... onto facebook
servers, even if you don't have any Facebook account.

https://media.ccc.de/v/35c3-9941-how_facebook_tracks_you_on_android

Also see Brian Lunduke findings: https://youtube.com/watch?v=8n6ubzCzZ5I

And Microsoft they're continuously collecting 1.9 Petabytes of data
from 800 million Windows 10 workstations ... all "telemetry" data, of
course ;-)

https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/

Back to LLVM. LLVM is Open Source. Assumed, people might find any trojan
code in it sooner or later.

But the finally compiled LLVM binary, that comes with most
Linux/FreeBSD/NetBSD/Darwin/MacOS X Distributions, has nothing to do with
its official sources!!! It's completely different code, as i've found out.

Doing a security review of the official (assumed trojan free) LLVM code -
even is impossible. 420 Megabytes compressed - no chance to review this
beast in lifetime ...

TCC - no problem. One week and i was through.

Perhaps i should remind you, that even your "tiny" (relatively to US
frameworks) Picolisp - is hard at the limit, what can be reviewed.

Compared to Nokolisp, Picolisp is pure bloat: Nokolisp only has 5600 lines
of code, its binary .exe is 50 KILOBYTES in size only:

https://github.com/timonoko/nokolisp

Just to give you an idea, what to aim for. I've implemented a couple of
Lisp interpreters now, they all do fit into 1st level caches (32 KBytes) of
all kinds of CPUs. Memory access - with zero waitstates - finally makes
them *ultra fast*, much faster than LLVM. Fast, security reviewed software
is a good sell today ... i can't complain: Minimal effort, secures me
highest income.

Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In
terms of size as well as of security.

And there is another aspect to consider ... Clouds ... the smaller the
interpreter is, that is executing some e.g. fastcgi code, the more clients
can be served, the faster startup - and cleaning up - times, lesser
latency. With interpreters, that only occupy one 4 KByte Memory Page ... i
can have millions of instances (forks, whatever) running, without even
coming close to one Gigabyte of memory footprint, thanks to KSM (Kernel
Samepage Merging) mechanism in Linux. Identical binaries here are only
stored once in memory.

With LLVM? No chance. It would need terabytes of memory and dozens of cpus
and servers, load balancers ... to serve a million clients. That's, of
course, in US interest:

"Hardware sales optimization" over bloated Open Source libraries and
compilers and - intentionally - ultra slow, old fashioned algorithms,
especially to be found in Open Source database code, hosted and maintained
by Apache Group. I have reviewed some of them. Pure mess, a huge, no giant
pile of shitty, slow, highly insecure code, full of US government injected
trojans. Nobody can even security review billions of lines of code ...

Less is more! Back to the roots! Also very important: "Reproducible
builds". Also for security reasons. No chance with LLVM!

Best regards, Guido


Am Sonntag, 19. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
>> Using US software stacks, even if open source and under a free license
are
>> not tolerable. For any nation, for any kind of project.
>
> Then no software stack, from anywhere, is tolerable.
>
> In case of pil21, where is the problem? I use Lisp to generate LLVM-IR,
then the
> llvm assembler to convert to machine code, then link it with libc.
>
> Do you seriously believe the libraries contain backdoors? They would be
detected
> very quickly. The generated machine code and runtime behavior I debug and
> observe permanently.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Stop using US controlled software stacks!!!

[Guido Stepken]

Hi Alex!

"completely replace it with pil21" ... (LLVM based)

Using US software stacks, even if open source and under a free license are
not tolerable. For any nation, for any kind of project.

US Cloud Act, Patriot Act, by law, force US companies as well US
organisations in general, such as Linux Foundation as well as Apache
Foundation and LLVM Foundation to comply with US law.

Here's a possible outcome:
https://www.infoq.com/news/2016/06/visual-cpp-telemetry/

The compiler itself becomes a NSA/CIA spy tool. With (compressed) over 420
megabytes of source code size for LLVM, world does not have the slightest
chance to do any security review on that software stack.

And that's what stupid cowboys are hoping for: Not only creating Lock-In -
as well as legal problems - on APIs of all kinds (see Oracle-Google
lawsuit) with Apache/Linux/LLVM/... Foundations, stupid cowboys are also
injecting spy code into in all kinds of US controlled libraries (NPM now is
Microsoft/Github owned) and especially compilers, development tools.

My urgent advice: Stay with your own x64 compiler, forget about everything
that is coming from or is directed by US companies, US foundations of any
kind.

Switch to LLVM with pil21 and i cannot recommend you and your (until today:
trustworthy) software stack any longer for any kinds of projects.

And i can assure you: My influence is **much bigger** than you might think!
Stop that, immediately!

Use C99 compilers, that are small enough to be security reviewed, such as
TCC.

Best regards, Guido Stepken

Am Samstag, 18. April 2020 schrieb Alexander Burger :
> Hi Andras,
>
>> If you are interested I have patched the 19.12 32bit sources to compile
without GCC.
>> I have attached the changed files: pico.h, main.c, apply.c and flow.c
>
> Thanks a lot!
>
>
>> Since clang does not support variable length array in structures I
allocate the bindFrame
>> with alloca() and provided a macro in pico.h to ease this: allocFrame().
>>
>> I know that the 32bit version is not the mainstream version, but feel
free to
>> abuse the patches.
>
> Cool!
>
> As I'm concentrating on pil21, I'm glad if development and maintenance of
pil32,
> mini and/or ersatz is taken care of by others. Until it is replaced by
pil21
> next year, I will do necessary fixes to pil64 and then - if all goes well
-
> completely replace it with pil21.
>
> Let's hope that no major problems pop up ... ;)
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Tiny C Compiler

[Guido Stepken]

That's kind of tabulator for structs of data in memory ... only of real use
for handing over to vector instructions (SSE, AVX2, AVX512 ... ARM NEON).
It's a GCC thing, not a C standard! ;-)

https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro

Hope, that helps.

Am Montag, 13. April 2020 schrieb C K Kashyap :
> Hi all,
> I just noticed that TCC was mentioned in another thread so I wanted to
share my experience with it. I had tried to build miniPicoLisp with it but
unfortunately, TCC does not seem to generate aligned functions :( it did
not seem to honor  __attribute__((aligned))
> Does anyone else have any experience with using TCC to build miniPicoLIsp
or PicoLisp for that matter?
> Regards,
> Kashyap

Re: pil21 language reference?

[Guido Stepken]

Where are the tests?

Am Montag, 13. April 2020 schrieb Alexander Burger :
> Hi Alexander,
>
>> I have now compiled pil21 on OpenBSD-6.7-beta/arm64 (aka -current),
mainly by
>> copying the files over from amd64.
>
> Perfect.
>
>
>> I have an additional question. Is the a pil21 language reference? Can I
use
>> the pil64 docs? Which functions are missing?
>
> There is no reference yet. Note also that pil21 is now only about half way
> implemented. When done, it should be completely compatible with pil64,
except
> for a few differences.
>
> I maintain a file for these differences. As of today (will probably be
extended
> with time), it is:
>
>
>   Differences to Pil64
>   
>
>+ Lisp insted of PilAsm
>+ No PicoLisp required for bootstrapping
>+ '*Run' not limited to 1024 FDs / 500 children
>+ Shared libraries have ".so" extension
>+ 'journal' format: Default size '0' instead of '64'
>+ 'with' accepts 'var' instead of 'sym'
>
>- '' is removed
>- '(arg)' call is removed
>- Second argument to 'name' (i.e. renaming) is removed
>- Lambda-binding environment offset for 'eval' and 'run' only for '@'
>- 'native'
>   — only functions with fixed number of arguments
>   — no 'T' result spec (skipped call)
>- Coroutines
>   Main routine has a tag 'T'
>
>
> So, as I said, pil21 is not usable now. If you want to know which
user-level
> functions are implemented so far, look at 'symTab' in "src/glob.l" (as
opposed
> to 'SymTab' in "src64/glob.l".
>
> And even of those functions some are not complete yet. I'm going through
> "src/main.l", and traverse the 'load'ed files. This month I'm in
"src/io.l".
>
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!

[Guido Stepken]

Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
>> All you need to do, is to let PicoLisp Interpreter convert PicoLisp
Source
>> into that Lisp dialect, Webassembly VM does understand, and you're done!
>
> OK, if it is so easy, why don't you do it?

I've hoped, you would have an insight, that going that way could bring you
lots of revenue. :-/


> Still it doesn't solve the portability issue. I want PicoLisp to run also
in iOS
> (also MacOS, and other server setups). pil64 is fine (and probably the
absolute
> optimum in terms of performance), but it can't be ported to e.g. RISC-V.

Just a question of time, until Webassembly will be the standard
(containered = secure) way of starting processes, microservices on mobiles,
Linux Servers in general.

That's going quick now, we're already replacing Docker containers by
Webassembλy containers for all kinds of microservices:

Webassembλy rules

RISC-V ... i am playing around with that, recently adapted TCC to the
Kendryte 210 Board. Holy fuck, that thing ist fast!!! And cheap!

https://www.heise.de/newsticker/meldung/RISC-V-50-Dollar-Entwicklerboard-aus-China-4198639.html

uLisp is dominating here:

http://www.ulisp.com/show?30X8

Inline RISC-V Assembler brings speedup of upto 1000x ...

http://www.ulisp.com/show?30ZU

Here the original and assembler accelerated Mandelbrot example:

http://forum.ulisp.com/t/mandelbrot-set-using-risc-v-assembler/522

First i've thought, German Industry would hop on microPython, but no ...

uLisp on RISC-V is making it. Lisp is much smaller and faster to implement.
The fastest growing market of all times ... Embedded Lisp ...

Have fun!

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

Re: Towards a more readable Pico(Lisp) ... nobody needs parenthesis!

[Guido Stepken]

Like that WISP example. Indendation here replaces "("

https://wiki.gnome.org/Projects/Genie#Block_Indentation

Same for Python.

Means: Lisp code generally can be stripped off most brackets without losing
"meaning". And it should. For readabilty reasons, public acceptance - and
typing speed: With German Keyboard typing {([ ])}; is no fun!

Happy Easter!

Am Sonntag, 12. April 2020 schrieb :

> Looks a lot like Sweet[0] or WISP[1] to me!
> They are defined for Scheme, but can be used for any sexprs.
>
>
> Sweet example:
>
> define factorial(n)
>   if {n <= 1}
>  1
>  {n * factorial{n - 1}}
>
>
> WISP example:
>
> define : factorial n
> __  if : zero? n
>    . 1
>    * n : factorial {n - 1}
>
>
> [0] https://srfi.schemers.org/srfi-110/srfi-110.html
> [1] https://srfi.schemers.org/srfi-119/srfi-119.html
>
> --
>/c
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!

[Guido Stepken]

Hi Alex!

Maybe, i am repeating myself. But Webassembly containers use LLVM already.

https://github.com/WAVM/WAVM/blob/master/README.md

All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source
into that Lisp dialect, Webassembly VM does understand, and you're done!

Greetings from another universe ...

Have fun!

Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> On Sun, Apr 12, 2020 at 10:36:58AM +0200, Guido Stepken wrote:
>> Why porting Picolisp onto LLVM, when there already is a JIT compiler in
>> every Webassembly container, that accepts Lisp code?
>
> The answer is "portability"
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp Sources

[Guido Stepken]

Hi Alex!

You might perhaps have noticed, that modern CPUs execute "unoptimized"
compiler code almost as fast as code produced by highly optimizing
compilers (-Os vs. -O3). Difference is almost zero!

You also might have noticed, that AMD with EPYC Rome and Threadripper are
far ahead of Intel in terms of IPC - Instructions Per Clockcycle.

That has to do with long instruction prefetch queues, a new neural "branch
prediction" and new, highly sophisticated translators from ISA instructions
into internal microcode.

I can tell you, that "SSA" tricks, such as PHI() optimizations, "register
renaming", ... all that stuff alredy has moved into the processor itself. 2
megabytes (that's the size of a full processor microcode update!) of
processor - internal "post machine code optimization" - code makes that
possible.

On AMD EPYC, even speed of completely unoptimized TCC machine code comes
quite close to - hundreds of years of intelligent man/womenpower optimized
- GCC/LLVM compiler code. Difference is negligible.

https://en.wikipedia.org/wiki/Static_single_assignment_form

These "SSA idea" is going back to 1988. Today is 2020, that's 32 years
later.

Have fun!

Guido Stepken

Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
>> Rowan Thorpe  writes:
>> > parentheses are not used because as is stated at
>> > https://picolisp.com/wiki/?src64 "Assembly language is not a
>> > functional language, i.e. the individual instructions do not "return"
>> > a value. So a fully parenthesized syntax is useless and just tedious."
>>
>> because picolisp doesn't have a compiler (program)
>>
>> it is "compiled" to the picolisp assembly manually ahead of time by Alex
>> (human)
>
> Actually, all this will change with the new PicoLisp "pil21". It is no
longer
> oriented to machine *instructions* like pil64, but to SSA (Static Single
> Assignment) *values*.
>
> It is a radically different approach. If there is interest, work in
progress can
> be seen at
>
>https://git.envs.net/mpech/pil21
>
> or directly in
>
>https://software-lab.de/pil21.tgz
>
> Here the sources have real PicoLisp syntax (though partially different
> semantics). The compiler (in "src/lib/llvm.l") does not only use the
reader, but
> generates the LLVM-IR by *executing* the code (Forth is chuckling from
behind).
>
> This works by simply redefining some (not many) functions in llvm' and
'priv'
> namespaces.
>
>
> For example, the source of the 'car' function:
>
> In pil64 it is (in "src64/subr.l")
>
># (car 'var) -> any
>(code 'doCar 2)
>   push X
>   ld X E
>   ld E ((E CDR))  # Get arg
>   eval
>   num E  # Need variable
>   jnz varErrEX
>   ld E (E)  # Take CAR
>   pop X
>   ret
>
> This results in e.g. AMD/Intel asssembly (in "src64/x86-64.linux.base.s")
>
>   .globl  doCar
>doCar:
>   push %r13
>   mov  %rbx, %r13
>   mov  8(%rbx), %r10
>   mov  (%r10), %rbx
>   test $0x06, %bl
>   jnz  1f
>   test $0x08, %bl
>   cmovnzq  (%rbx), %rbx
>   jnz  1f
>   call evListE_E
>1:
>   testb$0x06, %bl
>   jnz  varErrEX
>   mov  (%rbx), %rbx
>   pop  %r13
>   ret
>
>
> Now in pil21 the source is (in "src/subr.l"):
>
># (car 'var) -> any
>(de _car (Exe)
>   (car (needVar Exe (eval (cadr Exe )
>
> and the result in LLVM-IR is (in "src/base.ll"):
>
>define i64 @_car(i64) {
>$1:
>; # (cadr Exe)
>  %1 = inttoptr i64 %0 to i64*
>  %2 = getelementptr i64, i64* %1, i32 1
>  %3 = load i64, i64* %2
>  %4 = inttoptr i64 %3 to i64*
>  %5 = load i64, i64* %4
>; # (eval (cadr Exe))
>  %6 = and i64 %5, 6
>  %7 = icmp ne i64 %6, 0
>  br i1 %7, label %$4, label %$3
>$4:
>  br label %$2
>$3:
>  %8 = and i64 %5, 8
>  %9 = icmp ne i64 %8, 0
>  br i1 %9, label %$6, label %$5
>$6:
>  %10 = inttoptr i64 %5 to i64*
>  %11 = load i64, i64* %10
>  br label %$2
>$5:
>  %12 = call i64 @evList(i64 %5)
>  br label %$2
>$2:
>  %13 = phi i64 [%5, %$4], [%11, %$6], [%12, %$5] ; # ->
>; # (needVar Exe (eval (cadr Exe)))
>  %14 = and i64 %13, 6
>  %15 = icmp ne i64 %14, 0
>  br i1 %15, label %$7, label %$8
>$7:
>  call void @varErr(i64 %0, i64 %13)
>  unreachable
>$8:
>; # (car (needVar Exe (eval (cadr Exe
>  %16 = inttoptr i64 %13 to i64*
>  %17 = load i64, i64* %16
>  ret i64 %17
>}
>
> Looks unbelievably horrible, but works ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp Sources

[Guido Stepken]

Happy Easter, Alex!

Nothing brings me to waste just a second on LLVM compiler suite. And i
directly will tell you why:

https://bellard.org/otcc/

OTCC is a C compiler implemented in 2048 bytes of code. It can compile
itself and translates to 386 machine code. Fully 'Turing complete'! Its
successor, TCC, can compile even Linux onto ARM, Intel, is slighly longer.

420 Megabytes .tgz LLVM can neither be understood nor *security reviewed*
-> dustbin!

No security review, no run on my machines. It's as simply as that!

I am too old for Russian Roulette. I am an engineer, not a priest, praying,
hoping for, that Microsoft, Apple haven't injected some evil code into the
compiler, as seen here:

https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/

*Not for a second* i do consider wasting my time on (by US law!) NSA
poisoned, backdoored US software stacks any longer! We have plenty of
alternatives in Europe.

Keep away from Windows and other viruses!

Have fun!

Guido Stepken





Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
>> Rowan Thorpe  writes:
>> > parentheses are not used because as is stated at
>> > https://picolisp.com/wiki/?src64 "Assembly language is not a
>> > functional language, i.e. the individual instructions do not "return"
>> > a value. So a fully parenthesized syntax is useless and just tedious."
>>
>> because picolisp doesn't have a compiler (program)
>>
>> it is "compiled" to the picolisp assembly manually ahead of time by Alex
>> (human)
>
> Actually, all this will change with the new PicoLisp "pil21". It is no
longer
> oriented to machine *instructions* like pil64, but to SSA (Static Single
> Assignment) *values*.
>
> It is a radically different approach. If there is interest, work in
progress can
> be seen at
>
>https://git.envs.net/mpech/pil21
>
> or directly in
>
>https://software-lab.de/pil21.tgz
>
> Here the sources have real PicoLisp syntax (though partially different
> semantics). The compiler (in "src/lib/llvm.l") does not only use the
reader, but
> generates the LLVM-IR by *executing* the code (Forth is chuckling from
behind).
>
> This works by simply redefining some (not many) functions in llvm' and
'priv'
> namespaces.
>
>
> For example, the source of the 'car' function:
>
> In pil64 it is (in "src64/subr.l")
>
># (car 'var) -> any
>(code 'doCar 2)
>   push X
>   ld X E
>   ld E ((E CDR))  # Get arg
>   eval
>   num E  # Need variable
>   jnz varErrEX
>   ld E (E)  # Take CAR
>   pop X
>   ret
>
> This results in e.g. AMD/Intel asssembly (in "src64/x86-64.linux.base.s")
>
>   .globl  doCar
>doCar:
>   push %r13
>   mov  %rbx, %r13
>   mov  8(%rbx), %r10
>   mov  (%r10), %rbx
>   test $0x06, %bl
>   jnz  1f
>   test $0x08, %bl
>   cmovnzq  (%rbx), %rbx
>   jnz  1f
>   call evListE_E
>1:
>   testb$0x06, %bl
>   jnz  varErrEX
>   mov  (%rbx), %rbx
>   pop  %r13
>   ret
>
>
> Now in pil21 the source is (in "src/subr.l"):
>
># (car 'var) -> any
>(de _car (Exe)
>   (car (needVar Exe (eval (cadr Exe )
>
> and the result in LLVM-IR is (in "src/base.ll"):
>
>define i64 @_car(i64) {
>$1:
>; # (cadr Exe)
>  %1 = inttoptr i64 %0 to i64*
>  %2 = getelementptr i64, i64* %1, i32 1
>  %3 = load i64, i64* %2
>  %4 = inttoptr i64 %3 to i64*
>  %5 = load i64, i64* %4
>; # (eval (cadr Exe))
>  %6 = and i64 %5, 6
>  %7 = icmp ne i64 %6, 0
>  br i1 %7, label %$4, label %$3
>$4:
>  br label %$2
>$3:
>  %8 = and i64 %5, 8
>  %9 = icmp ne i64 %8, 0
>  br i1 %9, label %$6, label %$5
>$6:
>  %10 = inttoptr i64 %5 to i64*
>  %11 = load i64, i64* %10
>  br label %$2
>$5:
>  %12 = call i64 @evList(i64 %5)
>  br label %$2
>$2:
>  %13 = phi i64 [%5, %$4], [%11, %$6], [%12, %$5] ; # ->
>; # (needVar Exe (eval (cadr Exe)))
>  %14 = and i64 %13, 6
>  %15 = icmp ne i64 %14, 0
>  br i1 %15, label %$7, label %$8
>$7:
>  call void @varErr(i64 %0, i64 %13)
>  unreachable
>$8:
>; # (car (needVar Exe (eval (cadr Exe
>  %16 = inttoptr i64 %13 to i64*
>  %17 = load i64, i64* %16
>  ret i64 %17
>}
>
> Looks unbelievably horrible, but works ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!

[Guido Stepken]

Happy Easter, Rowan!

Unlike (Pico-)Lisp, where operator comes first "> (+ 2 3)" Forth is
*Reverse Polish notation*, so (2) values are pushed onto a stack and
operator (+) comes last "> 3 2 +". That's von Neumann friendly in so far,
as CPU also has to load values first and then calls the add() function:
"Prefix" and "Postfix" notation.

Next evolutionary step in interpreter/compiler technology were (split)
multistacks and "named stack" engines, as with one stack only, as now
happens in my SISC Computer, things are quickly piling up, plenty of
unproductive in-between operations needed, like in Towers of Hanoi problem,
which goes with 2^N-1, but with far less, when you can use far more than
just 3 piles (stacks).

That brought the GCC developers to the "endless registers" machine. GCC, in
fact, is translating the code into some abstract Intermediate Code, where
the CPU initially has endless number of registers and the Lisp like "MELT"
language then reduces that problem to a multi-stack problem with number of
registers, the individual target CPU has. That's the secret behind the
portability of GCC. And this is, how i made my compiler for my experimental
SISC machine.

Building that "MOV Fuscator" is a piece of cake. Just set - deeply inside
GCC - the number of available registers to 1 in MELT optimization layer and
there u are:

https://github.com/xoreaxeaxeax/movfuscator/blob/master/README.md

Means: The transition from "stack engine" to "register engine" is fluent.
Does your CPU have more (orthogonal) registers, the less "stack work"
(compare to Towers of Hanoi problem with increasing number of piles) is
needed. Code becomes more compact, CPU gets faster. See Motorola 68000
design, a genius strike. Is super easy to write highly optimizing compilers
for.

Back to Webassembly: You just have to transpile PicoLisp code into WASM
S-Expressions:

https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API

let the Webassembly Container translate that into machine code, do the
work. Finished is your PicoLisp JIT engine.

Why porting Picolisp onto LLVM, when there already is a JIT compiler in
every Webassembly container, that accepts Lisp code?

The only thing, Alex would have to do, is to translate (Pico-)Lisp into
(Webassembly-) Lisp or S-Expressions. Piece of cake!

Have fun!

> Aside from the surface syntactic similarities due to the use of
> s-expressions in the text format, I think the better
> content-comparison of WebAssembly is to a register machine (hence
> "assembly" in the name, but something closer to the LLVM IR - which
> can be JITted or statically compiled - feels like a good comparison),
> as opposed to lisp which is functional. I used to think of it as being
> like other stack-machine languages like Forth (or even the JVM), and
> the design rationale at https://webassembly.org/docs/rationale/ even
> describes it as "a structured stack machine", but
> http://troubles.md/posts/wasm-is-not-a-stack-machine/ explains why
> this is not quite accurate. Also several Forths (like gforth) are
> considered "stack-machine implementations" due to being a forth, but
> they can use registers in addition to the typical 2-stack forth core,
> so the stack/register boundary gets a little fuzzy there too. When I
> first read about WebAssembly the thought that hit me was not that it
> was like Picolisp but that it is very similar to the 64-bit assembly
> written for and used at the core of the 64-bit Picolisp
> implementation, except that - unlike WebAssembly's text format - there
> parentheses are not used because as is stated at
> https://picolisp.com/wiki/?src64 "Assembly language is not a
> functional language, i.e. the individual instructions do not "return"
> a value. So a fully parenthesized syntax is useless and just tedious."
>
> By the way what I love most about Picolisp is that it feels like as
> good a hybrid as you can get between the "typical functional
> lisp/scheme" mental model and something that feels "forth-like" in
> terms of minimalism/precision/close-to-the-metal von-neumann
> architecture-friendliness. I describe it to friends as "as close as
> you can get a lisp to forth while still being able to call it a lisp"
> (I hope Alex doesn't hate that oversimplification too much, if he has
> a better soundbite-way to capture the core of that sentiment I'd be
> keen to hear it and would be happy to modify my soundbite). My two
> favourite programming idioms are lisp and forth (rust comes third, and
> part of its coolness is its comprehensive support for compiling to
> webasm, which is why I started learning rust).
>
> --
> Rowan Thorpe
> http://twitter.com/rowanthorpe
> PGP fingerprint: 92FA 6C6F ABF2 C1B2 7E1C  7CCD 131F D7A9 542F 12F0
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Did you know? Webassembly Containers are (Pico-)Lisp machines!

[Guido Stepken]

Hello, all!

It might sound a little bit weird, when i tell you, that recently
standardized Webassembly Containers in your browser are - Lisp machines.

Emscripten C/C++ "emcc" compiler does not translate into machine code
directly, but rather some kind of meta machine code (Intermediate
Bytecode), that the processor (Intel, ARM, ...) then can easily JIT -
transform into its final, executable machine code. That Intermediate
Bytecode, in fact, is a pure Lisp, just like PicoLisp is:

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

PicoLisp and Webassembly containers have a lot in common. They even have
same capabilities, features. Nothing speaks against letting PicoLisp run
directly in a browser container or - serverside as Webassembly container.
PicoLisp thus - was far ahead of its time!

Here a famous quote by the Docker inventor on twitter:

https://twitter.com/solomonstre/status/004913222324225

Solomon Hykes
@solomonstre


If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
That's how important it is. Webassembly on the server is the future of
computing. A standardized system interface was the missing link. Let's hope
WASI is up to the task!


PicoLisp *is* a genius strike, but some get it at least a decade later ...
:-(

Even Microsoft now is on the train to port its ASP DOTNET CORE 3.0 Blazor
Library onto Webassembly Lisp:

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
https://github.com/AdrienTorris/awesome-blazor/blob/master/README.md

It's just ridiculous!

Have fun!

Happy easter and keep away from Windows and other viruses!

Guido Stepken

Lisp, a language for "Stratified Design" Podcast and paper.pdf

[Guido Stepken]

A highly inspiring, philosophical Podcast about Abstractions in Lisp, that
- until today - you simply can't do in other programming languages:

https://podcasts.google.com/?q=Lisp+stratified

https://www.researchgate.net/profile/Gerald_Sussman/publication/37596906_Lisp_A_Language_for_Stratified_Design/links/53d142ce0cf220632f392c19/Lisp-A-Language-for-Stratified-Design.pdf

Also see that strage discussion about PicoLisp and 'Graph Database':

https://www.mail-archive.com/picolisp@software-lab.de/msg09451.html

Even with a Bachelor in Computer Science, people simply don't get the power
of Picolisp. They don't see the forest for the trees.

Have fun listening!

Guido Stepken

Towards a more readable Pico(Lisp) ... nobody needs parenthesis!

[Guido Stepken]

Hi all!

Parenthesis sometimes unneccessarily seem to keep people away from Lisp as
"all day programming language". It's confusing their brain.

How about this "innovative" new Lisp syntax?

https://github.com/birchb1024/genyris/blob/master/examples/queens.g

It's the more readable version, compare to this original version here:

http://obereed.net/queens/algorithm.html

Reminds me a bit of Python or Julia ... or rather - Swift?

Seems, all programming languages, including new C++20, Java, Kotlin, Scala
do slowly converge to Lisp. "AWS Lambda", just saying.

German Heise Mag recently introduced into "new" C++20 lambda, iterators,
generators, "yield", lazy streams, coroutines, block closures, promises,
futures, await ... surprising, always surprising ...

https://heise.de/developer/artikel/C-20-Coroutinen-ein-erster-Ueberblick-4687457.html

"New features", even PicoLisp is having since decades now. It's getting
more and more ridiculous with "US Software Innovation Industry". But most
people simply don't get it, where that all comes from.

Have fun!



With C++28 we probably finally then have a full implementation of a Lisp
.. 70 years after Lisp was invented in the year 1958. Ridiculous!

Have fun!

Porting Picolisp onto the simplest possible processor - The new SISC!

[Guido Stepken]

Hi Andreas!

My implementation not really is a pure Lambda calculus, but rather a so
called "Krivine Machine" that, in fact, consists of 4 instructions, als
'subset' of the more universal MOV instruction.

https://en.wikipedia.org/wiki/Krivine_machine

Also see the famous "Landin Machine" with 10 instructions.

https://en.wikipedia.org/wiki/SECD_machine

There are a couple of "Weird Instruction Set Machines" out in the wild, all
built, suited for special purposes ...

I was surprised, how small miniPicoLisp is and - als fully featured
programming language - it fits onto such kind of hardware (low transistor
count === very low energy consumption **while running**) architectures.

Have fun!

Guido Stepken

Am Freitag, 10. April 2020 schrieb :
>>
>> Only 1 - in words "ONE" - single instruction left: MOV.
> congratulations, you discovered lambda expressions, the fundamental idea
> on which the concept of LISP is based.
>
> Thanks for your post, very interesting!
> Keep on! Our group of radical IT purists is growing ;-)
>
> This crisis will only increase the demand for quickly to create,
> flexible & maintainable software - so let's picolisping :-)
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Porting Picolisp onto the simplest possible processor - The new SISC!

[Guido Stepken]

Hi Alex!

Yes, indeed! Code typically gets quite large quickly when compiling the
miniPicoLisp into "SISC Code". But luckily your miniPicoLisp was tiny
enough.

But adding a few more Lisp - Instructions to SISC will significantly reduce
the code length. Y-combinator, the "pure Lisper's while loop" and Beta
reduction(s) just to mention here.

Probably adding parts of the "Forth Instruction Set" - seen from the lambda
point of view - might be the optimum, keeping a good balance between number
of necessary instructions and execution code length of a pure MOV "SISC"
machine to keep number of transistors as low as possible.

I will find out ... ;-)

Am Freitag, 10. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
>> I've succeeded now to design my own CPU. I was curious, how many
>> instructions - e.g. from Intel Instruction Set Architecture- i could
>> ...
>> Only 1 - in words "ONE" - single instruction left: MOV.
>
> Yeah, this single instruction set fascinated me too, since the early 90s
when we
> talked about it in the Munich Forth group meetings.
>
> It has ZERO opcodes - because it would be always the same :)
>
> But there *is* a cheat. All real work is done by hardware at given
addresses
> where values are moved to and fetched from.
>
> Also, code gets very large, because each instruction takes up 128 bits
> (two addresses, thus two words on a 64-bit machine).
>
>
>> Happy Easter and keep away from Windows and other viruses!
>
> Same to you, and everybody else!
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Porting Picolisp onto the simplest possible processor - The new SISC!

[Guido Stepken]

Hi all!

miniPicoLisp is a masterpiece of simplicity:
https://github.com/8l/miniPicoLisp/tree/master/src

Now i wanted to know, what the simplest processor could be, that would be
able to run miniPicoLisp.

Inspired by the famous book "From NAND to miniPicoLisp":

https://www.nand2tetris.org/

"Building a Lisp Machine from First Principles"

I've succeeded now to design my own CPU. I was curious, how many
instructions - e.g. from Intel Instruction Set Architecture- i could
remove, still having a fully functional 'Turing complete' computer.

Well, you might be surprised:

https://github.com/xoreaxeaxeax/movfuscator/blob/master/README.md

Only 1 - in words "ONE" - single instruction left: MOV.

That brought me to the idea to design the "Minimum Required Processor
Hardware" for this magic "Single Instruction Set Computer". Found some time
last days to work on that. FPGA miniPicoLisp computer architecture is
finished, fully working, success!

miniPicoLisp now runs on the simplest self built computer ever: The "Single
Instruction Set Computer". Not RISC-V or RISC, but SISC. REPL is quite
responsive, no noticeable delay or whatever.

I still couldn't figure out, how many transistors - measured in pure
silicon - that would correspond, but certainly under 1k, far below the old
4004 CPU. Add a couple of hundred Logic Units for full SDRAM support.

That brings be back to some thoughts about all that bloat - in form of
hardware and software - that US companies are flooding the world with:

"Billion lines of code, billions of transistors, billons of watts needed to
run stuff, that is neither neccessary nor can be understood or security
reviewed - ever!".

Happy Easter and keep away from Windows and other viruses!

Have fun, Guido Stepken

Re: Small Docker container builds the latest pil in Alpine image

[Guido Stepken]

Yes, you're right. Docker, from security point of view, is like a Swiss
Cheese. I always succeeded to find a way to break out, getting *full
access* to the underlying machine. Always!

Webassembly is a bit different. We now have around 200 people working
fulltime at building the "absolutely safe" webassembly interpreter. Not a
compiler, but an interpreter catching any undefined bytecode behaviour.
It's designed from scratch with security in mind - right from the
beginning.
Why? ***You can't test security into software!***

But this is, what stupid cowboys use to do. Unqualified (from security
point of view) people writing world class software?  ... A nightmare!

Whole Linux/Apache Foundation software packages - from security point of
view - finally are ready for the dustbin. Not ready for mission critical
purposes to keep the world going. See e.g. Emotet virus/trojan. Since one
year now it's spreading and Microsoft still has no antidote. This is not a
professional company, IMHO. Bunch of idiots, for sure. Same for Intel.

Use L4 kernel on ARM Cortex-A53 CPUs. Spectre, Meltdown? - ARM Cortex-A53
is - not affected. Makes a $25 Raspberry Pi 3 safest solution ever!

Have fun!

Guido Stepken

Am Donnerstag, 26. März 2020 schrieb David Bloom :

Too bad that WebASM is bunk from a security perspective and I share your
> love for hardware isolation.  Wherever it is running I am grateful for the
> language and the community.
>
> Cheers,
> David B.
>
> On Thu, Mar 26, 2020 at 9:43 AM  wrote:
>
>> Thanks for your informative email.
>>
>> I mostly agree with your points, except for WebAssembly on the client.
>> Though you differentiate between WebASM on client and on server - didn't
>> know about WebASM on server, might be a very good thing!
>>
>> But WebASM on the client is a epic conceptual mistake - it is the new
>> Adobe Flash.
>> Already now it is mostly used for malware obfuscation:
>> https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf
>>
>> Web scripting languages should not be turing complete, same holds true
>> for everything with untrusted scripting input.
>> Impossible to validate, unless you execute it. Yes, containment using
>> sandboxing turns out to be a better strategy than we thought years ago, but
>> still it gives a strong incentive to not work properly.
>>
>> Of course, that battle is already lost :(
>>
>> Security-wise, the whole cloud business should be dead, only full
>> hardware isolation gives full security.
>> Servers could be many small devices (e.g. rock64's, raspis, ..) instead
>> of shared resources with many layers and much (energy) overhead.
>>
>> No, I don't fully practice this, not viable currently.
>> Yes, I enjoy living in my radical purity niche.
>>
>> Have fun ;-)
>> - beneroth
>> On 26.03.20 13:35, Guido Stepken wrote:
>>
>> Though - for some folks - it might make things simpler, i am no friend of
>> Docker.
>>
>> What the Docker founder is saying about Docker now:
>>
>> Solomon Hykes
>> @solomonstre
>> <https://mobile.twitter.com/solomonstre>
>> ·
>> 27 März 2019
>> <https://mobile.twitter.com/solomonstre/status/004913222324225>
>> If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
>> That's how important it is. Webassembly on the server is the future of
>> computing. A standardized system interface was the missing link. Let's hope
>> WASI is up to the task!
>>
>> Source: https://twitter.com/solomonstre/status/004913222324225
>>
>> Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler and
>> runs perfectly in (server side) Webassembly containers. It's completely
>> replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.
>>
>> https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
>>
>> And when you look deeper into Webassembly, you will notice, that - in
>> itself - it's a Lisp, very much like Picolisp.
>>
>> https://developer.mozilla.org/en-US/docs/WebAssembly/
>> Understanding_the_text_format
>>
>> Lisp now rules the world. And Linux has won! ;-)
>>
>> Have fun!
>>
>> Guido Stepken
>>
>> Am Mittwoch, 25. März 2020 schrieb David Bloom :
>>
>>> For work reasons I have strayed from the beloved PicoLisp into Erlang
>>> for some time.  While I have much love for using Erlang/OTP to build
>>> robust, distributed systems, it handles a different job than PicoLisp in my
>>> opinion.  Even though work kept me in the Erlang world for a while I still
>>> followed the mailing list and one day saw instructions on how to build pil
>>> with musl.  After a single attempt in a fresh Alpine container it worked so
>>> I felt compelled to share with the group.  BEHOLD!
>>>
>>> https://hub.docker.com/r/progit/pil-alpine-minimal
>>>
>>> Big, big thanks again to Alex and this entire community.  Happy hacking!
>>>
>>

Re: Small Docker container builds the latest pil in Alpine image

[Guido Stepken]

Though - for some folks - it might make things simpler, i am no friend of
Docker.

What the Docker founder is saying about Docker now:

Solomon Hykes
@solomonstre
<https://mobile.twitter.com/solomonstre>
·
27. März 2019
<https://mobile.twitter.com/solomonstre/status/004913222324225>
If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
That's how important it is. Webassembly on the server is the future of
computing. A standardized system interface was the missing link. Let's hope
WASI is up to the task!

Source: https://twitter.com/solomonstre/status/004913222324225

Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler and
runs perfectly in (server side) Webassembly containers. It's completely
replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.

https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm

And when you look deeper into Webassembly, you will notice, that - in
itself - it's a Lisp, very much like Picolisp.

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

Lisp now rules the world. And Linux has won! ;-)

Have fun!

Guido Stepken

Am Mittwoch, 25. März 2020 schrieb David Bloom :

> For work reasons I have strayed from the beloved PicoLisp into Erlang for
> some time.  While I have much love for using Erlang/OTP to build robust,
> distributed systems, it handles a different job than PicoLisp in my
> opinion.  Even though work kept me in the Erlang world for a while I still
> followed the mailing list and one day saw instructions on how to build pil
> with musl.  After a single attempt in a fresh Alpine container it worked so
> I felt compelled to share with the group.  BEHOLD!
>
> https://hub.docker.com/r/progit/pil-alpine-minimal
>
> Big, big thanks again to Alex and this entire community.  Happy hacking!
>

Re: PicoLisp on windows

[Guido Stepken]

Sure. But tell me: What is faster? A tiny Picolisp interpreter binary, that
entirely fits into 1st/2nd/3rd level cache, accesses memory without
waitstaites - or a huge, multi gigabyte JIT engine, that, in itself, is a
pure memory monster?

My measurements show, that small, tiny interpreters - especially for lambda
microservices - are much faster than any Microsoft/Oracle/Apple (LLVM is
heavily sponsored by Apple!) technology.

And then you will also notice, that your "cloud memory footprint" (tens of
thousands of micoservices running at the same time with different customer
data, each) will tremendously go down, when you simply don't use any
"Wintel Alliance" technology: "We make slower software for you make faster
hardware!" (where Apple and Oracle certainly belong to!)

It saves you plenty of money, when you simply don't use U.S. technology
(neither Closed Source nor Open Source), using a sledgehammer to crack a
nut.

Tiny interpreters, like Picolisp, here have tremendous advantages. Also
don't forget to activate KSM (Kernel Same-page Merging) in Linux. Same
binaries (4K memory pages) get consolidated, only use one, single binary
instance in DRAM.

Remember: *Picolisp is a genius-strike!*

Most people simply don't understand why, because they simply got victim of
long-term U.S. advertising strategies selling more and more hardware to
host bigger and bigger software packages. That nonsense has kept up going
Silicon Valley for two decades now, pulling billions from our pockets.

Have fun!

Guido Stepken


Am Donnerstag, 26. März 2020 schrieb :

> Does anyone realize that there's an LLVM-based port of picolisp being
> worked on by Alex? :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Graph database

[Guido Stepken]

Lawrence, you haven't yet understood, that any Lisp, by default, is it's
own Graph Database. Especially Picolisp, where Alex has made any Picolisp
Atom persistent and even distributed across other Picolisp instances. 'Data
is code, code is data'.

Any named bag of items automatically represents a (directed, undirected)
graph. The name then is the node, the items in the bag then there represent
the edges. Even Picolisp sources you can consider a (directed) graph, often
also called 'syntax tree'.

If you like, you can put, group all "edges" with same properties into a
new, searchable bag of edges for fast lookup. Since it's all lazy evaluated
(even the persistent nodes), as Alex already pointed out, it's still ultra
fast. And since in Picolisp everything can be persisted distributed,
Picolisp automatically represents a distributed graph database (with
sharding and everything) which you can build, implement on your own with
just a few lines of code. It's a no-brainer!

Picolisp is a genius strike, but most people can't see the forest for all
the trees.

Have fun!

Regards, Guido Stepken

P.S. Keep away from Windows and other viruses!

Am Donnerstag, 12. März 2020 schrieb Lawrence Bottorff :

> I take it the picolisp graph database follows more the Neo4j property
> graph idea than any RDF/OWL triples, correct? That seems obvious, but I
> thought I'd check. I haven't dived in deep, buy you seem to use Lisp
> objects to create a vertex. But then what are the edges? Again, I'm just
> getting started.
>
> LB
> Grand Marais, MN, Oberer See
>

Re: PicoLisp on windows

[Guido Stepken]

Hi to all!

Before s.b. is reinventing wheels, like porting Picolisp onto .net, please
consider Femtolisp, which is the base underlying Julia programming language
JIT compiler. It's LLVM based and ultra fast, tiny and quite useful as PoC
for implementing Picolisp on your own.

https://github.com/JeffBezanson/femtolisp/blob/master/README.md

Picolisp on Windows and .NET ... i could never have imagined that s.b.
could want that ... is Windows still in use anywhere? I mean: After Emotet,
newest Zero Day Exploits, ? Still no antidote against, after one year
now!

Sorry, that i must say that, but whole Microsoft infrastructure has
collapsed under its own weight, cross site complexity!

"End of lifetime" for Microsoft, i would say!

Have fun!

Am Dienstag, 24. März 2020 schrieb C K Kashyap :

> Hi All,
> I've been using PicoLisp under docker on my windows machine but a
> challenge that I face is in my ability to share the scripts with my
> colleagues. It would be awesome to run picolisp on Windows.
>
> minipicolisp is easy to build on Windows (with mingw). However, it does
> not really have networking and bignum among other things.
>
> I was wondering if it would be easier/better -
>
> 1. Try to figure out how to use networking in minipicolisp - perhaps using
> libuv (the io library that's used by nodejs)
> 2. Figure out how to patch the Posix calls needed by Picolisp
> 3. Use PicoLisp LLVM as the base
> 4. Any other idea :)
>
> Regards,
> Kashyap
>

Re: cloud host for picolisp

[Guido Stepken]

You can either choose e.g. a Hetzner VSERVER, see CX11 offer or you simply
ask your provider of your choice for a NginX virtual domain server with
PicoLisp interpreter as fast_cgi module setup:
https://www.nginx.com/resources/wiki/start/topics/examples/fastcgiexample/

Any UNIX sysadmin can configure that in a few minutes.

Have fun!

https://www.nginx.com/resources/wiki/start/topics/examples/fastcgiexample/

Derenik Mikaelyan  schrieb am Mo., 10. Juni 2019,
20:39:

> Hi,
>
> I'd like to use picolisp for making a web-app. I'm not good at server-side
> setups and maintenance. Is there any cloud hosting-service that provides
> well managed picolisp installation (for reasonable monthly fee)?
>
> Thanks,
>
> Derenik
>

Re: Database file format

[Guido Stepken]

Alex Burgers PicoLisp DB tutorial describes indirecty the underlying format:
http://software-lab.de/doc/tut.html#db

"block size of 256 Bytes", talking of a CAR and a CDR which indicates, that
it is kind of "functional database", comparable to ultra expensive DATOMIC.

Alex also writes about kind of btree allowing 'soundex' search which
indicates, that there must be specialized index files for faster and
tolerant search. PicoLisp has transactions built-in, rollback is possible.

PIL or Prolog in PicoLisp allows you to build up highly sophisticated (also
remote, distributed) queries from these tree primitives, but it can happen,
that suddenly you have accidentally created millions of queries ... NVMe
SSD's (>100,000 IOPS) highly recommended ...

You finally must know, what you are doing. You can't compare PicoLisp's
functional, (btree, soundex) indexed database with highly specialized and
optimized engines like PostgreSQL or Neo4J, engines using modern GraphBLAS
algorithms like Redis.

But finally you will be able to build all kinds of (distributed) databases,
even (distributed) graph databases, (distributed) fault tolerant databases
with PicoLisp just with a few lines of code.

Nothing here speaks against building own, specialized indexing daemons
written in either PicoLisp or in C as module, which i have done (Fusion
Tree).

That's mighty, mighty stuff ... finally far superior to commercial
solutions (e.g. MongoDB).

PicoLisp is very tiny, very well thought through. One person can fully
understand and master (even modify) the whole PicoLisp ecosystem within
just a few weeks, C/Lisp knowledge required, of course!

That makes PicoLisp unique.

C K Kashyap  schrieb am Di., 28. Mai 2019, 22:46:

> Hi,
> Is there documentation about the file format of the database file in
> PicoLisp?
> I am looking at the possibility of using it for the tripple store
> .
> Regards,
> Kashyap
>

Is PicoLisp's future really dark?

[Guido Stepken]

No, it's not! When you ignore "us standards", you not only can build your
complete IT infrastructure with PicoLisp, but you also get access to the
complete, compact, well written, maintainable source code with it.

And if you really need security, you have a good chance to get a complete
security review through within just a few days invested.

Compare to the giant codebase of e.g. node.js ... code hell! Not the
slightest chance to do code reviews. Simply impossible.

At the moment, we (all countries globally) are at a point to say 'goodbye'
to U.S. software, hardware in general. U.S.A. and U.S. companies are no
longer reliable partners to setup an industry / finance / production
business upon. See Huawei case.

Here, Alex with PicoLisp, Mike Pall with LuaJIT and Frank Lesser with
Lesser Smalltalk JIT (all german guys) suddenly start to play a strategic
role in German IT Industry. And perhaps we must step back a bit, move to
much smaller frameworks, which deliver sufficient performance on slower,
smaller hardware with much smaller memory footprint running on much less
energy consuming hardware.

We must think faster now, new directions are to be decided ...

Re: lens.l - generalized data accessors

[Guido Stepken]

Wonderful! But i fear, most of the audience here hasn't the slightest idea,
what it's all about. Let me explain!

Maybe, you have already clicked into some graphics in your browser or just
used the "onmouseover" functionality. In HTML, everything is repesented in
a DOM, that's a tree structure, like JSON. But what do you mean, when you
move your mouse over a structure, say a table? Do you mean the cell element
or do you rather mean the whole table which then gets highlighted by
clicking on it?

Lenses here give you kind of functional tool to select or glue elements or
parts of the DOM together to make it a functional unit. Internally, it's
done with a set of chained getters and setters to compose DOM elements to
bigger units that then can be moved together, clicked on, activated or
deactivated, turned, (CSS3) animated, ... whatever.

A map function here is the simplest kind of "lens". With "onmouseover" you
mean whole DOM. Whereever you need kind of selector, you can do it with
lenses.

A more complicated example is a 5 - axis robot. Each arm can be moved
independently, so i have a chain of affine transformations, that finally
move the tool at the end to its position. But here 5 arms sometimes give us
more freedom, than we really need and maybe that there are many ways of
combining movements of arms to reach the same position.

Note: Moving forward then turning is not the same as first turning and then
moving forwards!

And now imagine, that one arm of the 5-axis robot breaks and i have to
compensate that. Mathematically, i now have to introduce co- and
contravariant matrixes to compensate the broken arm.

Contravariance you may also need e.g. to compensate a robot arm on a
rolling ship, e.g. to keep things horizontally.

Lenses here give you the universal tool for new aggregation of functions
that then treat data in a different way, with a different focus on the
underlying structures, be it tree, graph, linear list, whatever the
chain of getter/setter functions get rearranged automatically.

In Lisp or Picolisp it is done by reworking the code. Learn: "Data is code,
code is data", which makes Lisp unique in the whole world of programming.

Summary: Lenses are a general tool for functional composition or
rearrangement of getter/setter functions.

In non-functional programming languages lenses make no sense. They simply
don't exist there.

Have fun!


Abel Normand  schrieb am So., 19. Mai 2019,
23:08:

> Hello everyone.
>
> I'm happy to present you my last project:
> https://gitlab.com/Abel-ze-Normand/lens.l. It is a very nice abstraction
> from Haskell functional programming community and I wanted to share with
> you this PicoLisp implementation of Lens pattern and utilities to work with
> them. I plan to use them not only as a proof of concept but also as
> powerful tool to work with different formats of data in declarative way. I
> hope you will find it useful or at least interesting.
> --
> Best regards, Nail
>

Re: lens.l - generalized data accessors

[Guido Stepken]

lens.l isn't there, but i found your trie.l quite interesting!

https://gitlab.com/Abel-ze-Normand/trie.l/blob/master/trie.l

Abel Normand  schrieb am So., 19. Mai 2019,
23:08:

> Hello everyone.
>
> I'm happy to present you my last project:
> https://gitlab.com/Abel-ze-Normand/lens.l. It is a very nice abstraction
> from Haskell functional programming community and I wanted to share with
> you this PicoLisp implementation of Lens pattern and utilities to work with
> them. I plan to use them not only as a proof of concept but also as
> powerful tool to work with different formats of data in declarative way. I
> hope you will find it useful or at least interesting.
> --
> Best regards, Nail
>

Re: Review request for my JSON parsing implementation

[Guido Stepken]

Some also call it "REST" and have written mighty libraries in other
languages.

In PicoLisp it's a 5 - liner! ;-)

Alexander Burger  schrieb am Di., 7. Mai 2019, 07:04:

> On Mon, May 06, 2019 at 02:06:56PM -0700, C K Kashyap wrote:
> > My mind is blown - yet again. I love it just looking at it. I'll have to
> > look a little more to see what's going on.
> >
> > How do I capture the output though - I mean this does not capture the
> > output in J
>
> I used 'pretty' in the example to view the result.
>
> You can directly 'setq' it or use it in whatever way of course.
>
>(let J
>   (pipe
>  (in '("curl" "-s" "
> https://api.iextrading.com/1.0/stock/aapl/chart/3m;)
> (while
>(prin
>   (echo "volume" "unadjustedVolume") )
>(echo ",")
>(prin ".0,") ) )
>  (readJson) )
>   
>   (doSomething J)
>   ... )
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Philosophical implications of teaching PicoLisp

[Guido Stepken]

Lisp is IMHO the only programming language (i speak 23) that puts
"transformation" into foreground. Like - with us humans - it's unimportant
who you "are" (in contrary to Object Oriented Languages), but only how we
can transform each other, we do interfere with each other. The "inbetween"
here plays a much more important role.

"Learning" here means to change the way, neurons are connected. But it's
still the same neuron, that enables us to solve new problems.

Lisp is a good model to train that kind of thinking. Especially because in
Lisp all "data is code code is data", which makes it extreamly easy not
only to transform streams of data, but also transform steams of PicoLisp
code as well.

Have fun!


Nehal  schrieb am So., 28. Apr. 2019, 15:20:

> Dear Mr Alexander,
>
> Thanks for appreciating our efforts. This was all unplanned and
> spontaneous. Infact we started to approach Lisp syntax with addition of
> numbers from 1 to 100. So all kids were focused on numbers. Syntax was just
> natural. The best thing was they enjoyed. And there was no fear of
> programming. At the end of the session they were told that it was Lisp and
> they can use Emacs Scratch Buffer for complex problems (they're already
> using Org mode for drafting journals to send us mails).
>
> Your response was forwarded to parents of these children. It was highly
> encouraging for them, seeing it coming from the creator of PicoLisp
> himself.
>
> We'll keep the PicoLisp mailing list updated about further activities.
>
> Thanks
> Nehal
>
> -
>
>
> On Sat, Apr 27, 2019, 13:19 Alexander Burger 
>> Dear Nehal,
>>
>> wow, thats impressing!
>>
>> > We have begun Lisp sessions here with kids. Many other kids joined.
>> Without
>> > explicitly telling about symbolic expressions they learned to traverse,
>> > understand, solve lisp as mathematical puzzles.
>> >
>> > The session was taken by my mentor and co-worker, Alabhya Singh, Alumnus
>> > IIT Kharagpur. Session is in Hindi but explanation on board can be
>> easily
>> > understood.
>>
>> These kids are amazing. I don't understand the words, but at one point I
>> believe
>> I even heard one kid speculating about infinity (well, not completely
>> correct as
>> (/ 10 10) would rather be 1 ;) ... at that age!
>>
>> Thanks for sharing this!!
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Subscribe

[Guido Stepken]

Re: Programming can be futuristic

[Guido Stepken]

Fuck! Excellent! Wow. I like PicoLisp very much. This is a giant step
forward in cloud computing.

But is has to be communicated better and in more channels even.

Have fun!

Have fun!
Am 24.10.2013 12:12 schrieb Jakob Eriksson ja...@aurorasystems.eu:

 Well, if PicoLisp was ported to

 http://zerovm.org/wiki/The_Cloud_Hypervisor

 then we'd definitely be there.

 Thing is, I think it might be a good fit!

 On 2013-10-24 06:23, Henrik Sarvell wrote:
  This guy has obviously not discovered PicoLisp yet :-)
 
 
 http://www.ianbicking.org/blog/2013/10/why-isnt-programming-futuristic.html
 

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

Re: Direct JavaScript calls from/to Lisp

[Guido Stepken]

Pretty interesting, how far you can get with PicoLisp...maybe, overhead is
even smaller, than with this technology:

http://demo.kaazing.com/livefeed/

Have fun!
Am 09.09.2013 16:41 schrieb Alexander Burger a...@software-lab.de:

 Hi all,

 one more article:

http://picolisp.com/5000/!wiki?OnClickButton

 It can be seen as a kind of addendum to the Drawing Canvas stuff.

 Explains how to use the '+OnClick' button prefix class to directly embed
 JavaScript calls into GUI pages, and to return useful data to the
 application on the server.

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

Subscribe

[Guido Stepken]

Hello Guido Stepken <gstep...@googlemail.com> :-)
You are now subscribed



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