PilMCU status

[George-Phillip Orais]

Hi List!

I hope everyone is safe and in good health.

Even though I don't login to freenode these days, but I made it a habit to
check the channel everyday :) And what I read yesterday is the reason for
this email.

I saw some message about PilMCU so let me provide some answers here:

"... if Geo has or will ever post his FPGA picolisp code for the hardware
Pil machine he posted to youtube some years ago"
-> As of the moment, I don't recommend to post it yet because of the
following reasons:
* The code is still messy (both PilASM assembler and Verilog), contains
temporary codes for debugging
* The implementation is still unoptimized
* The Verilog code is not yet designed for portability to other FPGA vendor
and other FPGA boards

But don't worry, I will post it as soon as I get all these sorted out. BUT,
if you really want to see the code for reference, I can email it to you or
anyone interested and discuss how the development process was done as well
the whole approach.


"... Seems he stopped it"
-> I know it feels like that way because I did not provide any update for a
long time, but I would like to say that it is not yet stopped, but its
still on-hold. It's still difficult for me to find extra time for this but
I believe sometime soon I can get back on this. My motivation to have this
done is still the same as the beginning because I still believe this will
address most of my frustration on current firmware development work flow.


"... I would expect better performance, since you can in theory implement
lisp functions and run many of them in parallel"
-> This is true and this is actually one of the main motivator for me. An
analogy that can back this theory is bitcoin mining, from CPU -> GPU ->
FPGA -> ASIC, arranged as slowest to fastest. It's still difficult to
implement lisp with parallel computing in mind but I have some other ideas
that I would like to try and show that this approach is indeed interesting
to venture.

The reason why current implementation is slow is because of the following:
* The approach of implementation did not fully utilize the advantage of
FPGA over off the shelf CPU or MCU
* The implementation is not optimized due to no proper experience before
* 50Mhz clock made it feel slower :)

But as of the moment, I keep taking notes on how to resolve all these as
well as plan how to implement it.

For now, these are my goal for next PilMCU version which I want to call
uPil (u for micro):
* Cell processing directly in hardware
* Reduce primitives to a few core primitive to fit Cell processing on any
FPGA with decent logic size
* Use FRAM as storage of Pil codes in Cell format and run code from FRAM
* Use NOR Flash or external SD card as storage of Pil codes in ASCII format
with DB as filesystem
* Use internal memory of FPGA as RAM which will achieve register like speed
* Only Verilog code needed, no need PilASM assembler
* Must run on three major FPGA vendors with no code modification

Im not sure if all these are feasible but I think it will be, will see how
it goes.

I was also keeping an eye on other implementors of lisp on of the shelf
MCU, here are the latest ones:

1. http://www.ulisp.com/

2.
https://www.youtube.com/watch?v=GWr4iQfc0uw=PLQu9CQjHyYejctK-zxYbAC8kWUTkgcjsA=30=116s

https://icfp20.sigplan.org/details/scheme-2020-papers/3/Running-Scheme-On-Bare-Metal-Experience-Report-

3. https://lambdachip.com/index/


I was also planning to have PilMCU be remotely access during PilCon, let me
try get it back to working state and see how I can setup remote access, I
got TeamViewer on my PC so will see.

I remember there was someone trying to port PilOS on RPi?

Ok sorry for this long email, before I'll end let me comment of some recent
issue that I read also, about unstable email as well as the freenode issue?
Hmm what about developing email server and/or irc server using PicoLisp?
Would this be a nice group project? It's like hitting two birds in one
stone because: first it will address the issues, second it will serve as
another demo that can help promote PicoLisp to the outside? or instead of
centralized, how about something like those of fediverse or matrix? Anyway
just some ideas before going to bed :)

Have a good weekend everyone, stay safe always and keep in touch, cheers!


BR,
Geo

Re: Pil21 is now in Debian Unstable

[George-Phillip Orais]

Happy pil21 Alex and everyone!!

On Thu, Dec 31, 2020 at 12:51 PM  wrote:

> Congratulations!  \o/
>
> On Tue, 29 Dec 2020 08:23 -05:00, Alexander Burger wrote:
> > Hi all,
> >
> > On Tue, Dec 29, 2020 at 11:29:22AM +, Mike wrote:
> > > Happy coding and New Year,
> >
> > Thanks a lot to Mike Pechkin for all the testing, feedback, input and
> support,
> > and to Kan-Ru Chen for maintaining the Debian releases! And to all other
> members
> > in this list and the #picolisp IRC channel!
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Tomorrow is PilCon

[George-Phillip Orais]

Hi Olaf,

Thanks for this recap, this is very nice indeed!

I would like to add the hand-made block diagram by Alex for his
documentation, very cool! Maybe we can call it pilDiagram and make it as
official diagram for PicoLisp? Lets see :)


Hi Alex,

Thank you once again for sharing your time and patiently answering our
questions, PicoLisp always surprises me with so many nice features, how I
wish I have a very good Pil knowledge enough to introduce these hidden gems
to the outside world... but I still believe someone here or you with pil21,
it will happen someday soon :)


Hi Nehal,

I'm not so sure but you mentioned about org-babel, does this help your
inquiry: https://github.com/tj64/ob-picolisp


Thanks again everyone and stay safe always, have a great weekend! Bis blad!


BR,
Geo




On Fri, Sep 4, 2020 at 8:51 PM Alexander Burger  wrote:

> Hi Olaf,
>
> > I like to recap some topics/items, perhaps others can also enjoy
> > (disclaimer: there may be misunderstandings or faults in the notes!)
>
> Thanks a lot! This is a very good idea!
>
> And all correct I think.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Requests for PilCon

[George-Phillip Orais]

Hi Alex,

You are indeed right, sorry for this stupid suggestion :)
I look forward to the coming FfF!


BR,
Geo

On Wed, Sep 2, 2020 at 2:03 PM Alexander Burger  wrote:

> Hi Geo,
>
> > If I remember or heard and understand correctly, someone suggested a
> > theme-based PilCon? And what I have in mind for this coming Fridays theme
> > would be: "How to do it in PicoLisp way" :)
> >
> > And anyone gives some problems found from actual work or project
> > implemented in different programming language, then you or other Pil
> gurus
> > can provide answers on how to solve it using Pil, what do you think?
>
> This would be fine for me. However, isn't that just the same as what
> RosettaCode
> is all about?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Requests for PilCon

[George-Phillip Orais]

Hi Alex,

If I remember or heard and understand correctly, someone suggested a
theme-based PilCon? And what I have in mind for this coming Fridays theme
would be: "How to do it in PicoLisp way" :)

And anyone gives some problems found from actual work or project
implemented in different programming language, then you or other Pil gurus
can provide answers on how to solve it using Pil, what do you think?


BR,
Geo


On Tue, Sep 1, 2020 at 8:44 PM Alexander Burger  wrote:

> Hi all,
>
> any requests for PilCon next Friday? Should we prepare something?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: cells in picolisp [tutorial, slides]

[George-Phillip Orais]

Hi Mike, I like this too, thank you for sharing! Btw do you have another
format for this something like Powerpoint? If yes can I ask for a copy too?
Thanks again and hope to meet you on one of FFF (Fridays for Functions)

On Sat, Jun 6, 2020 at 7:52 AM C K Kashyap  wrote:

> I liked it :)
> Thanks,
> Kashyap
>
> On Fri, Jun 5, 2020 at 5:37 AM Mike  wrote:
>
>> hi all,
>>
>> https://envs.net/~mpech/cells-tutorial.pdf
>>
>> I've created tutorial about cell as root of data type hierarchy.
>> Goal of PDF is understanding of destructive functions.
>> I hope you will learn something new.
>>
>> Happy coding,
>> (mike)
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>
>

Re: Fridays for Functions (Was: PilCon 2020)

[George-Phillip Orais]

Super! I will indeed join and listen to learn more, thanks Alex and
everyone!

On Wed, Jun 3, 2020 at 3:30 PM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Jun 3, 2020, at 14:54, Alexander Burger  wrote:
> >
> > I would propose informal Jitsi meetings every second Friday or so. The
> time
> > could be alternating 8:00 and 16:00 UTC, to allow attendance from most
> time
> > zones. No big planning and schedule. Let's start with questions,
> tutorials and
> > demonstrations.
> >
> > Any thoughts?
>
> Nice idea ! :)
>
>
> --
> Jean-Christophe Helary @brandelune
> http://mac4translators.blogspot.com
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>
>

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

[George-Phillip Orais]

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

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

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

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

[George-Phillip Orais]

Hi Guido,

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

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


BR,
Geo




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

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

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

[George-Phillip Orais]

Hi Guido,

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


BR,
Geo

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

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

Re: Pil21 Status

[George-Phillip Orais]

wow! congrats! getting near :)


On Fri, May 1, 2020 at 11:21 PM Alexander Shendi (Web.DE) <
alexander.she...@web.de> wrote:

> \0/. 濾
>
> Am 1. Mai 2020 15:41:21 MESZ schrieb Alexander Burger  >:
>>
>> Hi all,
>>
>> pil21 reached the first milestone:
>> It passes the bignum tests in @misc/bigtest :)
>>
>> Next goal is self-bootstrap
>>
>> ☺/ A!ex
>>
>>
> --
> You have zero privacy anyway. Get over it.
>
> Scott McNealy 1999
>

Re: Pil transformed

[George-Phillip Orais]

No problem ;)



On Fri, Apr 24, 2020 at 11:15 AM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

> Thank you George,
>
> > On Apr 24, 2020, at 10:39, George Orais  wrote:
>
> > Hi Jean-Christophe,
> > maybe the README file inside doc64 can help answer your question ;) one
> thing that reminds me is the namespace? The reason why is pil32 uses hash
> table for the symbol table while pil64 uses binary tree? Not so sure but
> something like that :)
>
> Ok then, way over my head then :) But thank you for the pointer :)
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Pil transformed

[George-Phillip Orais]

Hi Andras,
this is super cool! Thanks for sharing!


Hi Jean-Christophe,
maybe the README file inside doc64 can help answer your question ;) one
thing that reminds me is the namespace? The reason why is pil32 uses hash
table for the symbol table while pil64 uses binary tree? Not so sure but
something like that :)


BR,
Geo

Re: MiniPicolisp Questions

[George-Phillip Orais]

Hi Alex,

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

I see, that make sense, thank you for the explanation.


Hi Guido,

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

If so, will it conflict with strings? Anyway thanks for sharing your
thoughts, its nice to know other approach existed, we look forward to see
your ASIC LispM someday soon..


BR,
Geo

Re: MiniPicolisp Questions

[George-Phillip Orais]

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

[George-Phillip Orais]

Same here, as lurker and amateur PicoLisper, I love to join and the attend
this online PilCon 2020, thank you Alex!


BR,
Geo

On Wed, Apr 22, 2020 at 2:47 PM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Apr 22, 2020, at 14:00, Alexander Burger  wrote:
> >
> > Hi all,
> >
> > yesterday the Oktoberfest, the largest annual event in Bavaria, was
> canceled.
> >
> > I think we will also have to cancel the other large event, PilCon. It is
> not
> > sure whether such events will be allowed legally by end of July, and how
> the
> > international travel situation will be.
> >
> > I hope this is OK for everybody.
> >
> > Would it make sense to plan an online conference instead? We are playing
> around
> > with Jitsi Meet currently. Any thoughts?
>
> There is a thread on hacknews about jisti vs mumble where they mention
> issues with a large number of people.
>
> https://news.ycombinator.com/item?id=22477785
>
> Maybe it would be nive to do tests with a dozen participants or so before
> going live ?
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

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

[George-Phillip Orais]

Hi Guido,

I am very interested to hear about your ASIC Lispm, how can we avail once
its out? Can you please share more details? Actually I am also trying to
get back from what we have started using FPGA but time is always not on my
side these days, but will see..

I really hope to hear from you back, thanks.


BR,
Geo


On Tue, Apr 21, 2020 at 5:37 PM Guido Stepken  wrote:

> 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: picoLisp 19.12: variable length array in structure fixes

[George-Phillip Orais]

Hi tankf33der,

Thanks for sharing your huge.l test, I tried it on my pil64 on WSL and all
passed!

20:27 $ pil huge.l +
OK-UTF8
OK-Montgomery
OK-Leibniz
OK-math
OK-forth
OK-parse2list
OK-mapreduce
OK-pow
OK-inc-db
# worker redefined
# +Inc c redefined
OK-inc-db-v2
OK-destr
OK-test-car
OK-bitwise
# reduce redefined
OK-Cartesian
# reduce redefined
# pow redefined
# seq redefined
OK-4clojure
# pow redefined
OK-AoC15
OK-AoC16
# f3-2 redefined
# f4-2 redefined
OK-AoC17
# a10 redefined
OK-AoC18
# c5 redefined
# c9 redefined
# c11 redefined
# c13 redefined
OK-AoC19
OK-SimplyScheme
# lcm redefined
# evenp redefined
# second redefined
# mystery redefined
# add1 redefined
# numbers redefined
# half redefined
OK-Touretzky
# prime? redefined
OK-Menshikov
# pow redefined
# exp redefined
# log redefined
# sin redefined
# cos redefined
# tan redefined
# asin redefined
# acos redefined
# atan redefined
# atan2 redefined
# f1-1 redefined
# f1-2 redefined
# create redefined
# inrow redefined
# f2-1 redefined
# move redefined
# f3-1 redefined
# f3-2 redefined
# f3-3 redefined
# f4-1 redefined
# f4-2 redefined
# f4-3 redefined
# product redefined
# f5-1 redefined
# f5-2 redefined
# f6-1 redefined
# f6-2 redefined
# f7-1 redefined
# f7-2 redefined
# f8-22 redefined
# f10-1 redefined
# f10-2 redefined
# f14-1 redefined
# f14-2 redefined
# f15-1 redefined
# f16-2 redefined
# f17-1 redefined
# f17-2 redefined
# f18-1 redefined
# f18-2 redefined
OK-Gorlansky
OK-Stepanoff
SIPHASH-OK
# mod32+ redefined
# endian redefined
Hash-ALL-OK
OK-RNG
OK-HKDF
OK-test-pbkdf2
# pow redefined
# exp redefined
# log redefined
# sin redefined
# cos redefined
# tan redefined
# asin redefined
# acos redefined
# atan redefined
# atan2 redefined
# T1 redefined
OK-HMAC
OK-test-MD5
OK-test-MD2
OK-test-aes
# totwo redefined
# fromtwo redefined
# tilde redefined
OK-test-KECCAK
OK-test-SHA512
OK-test-SHA256
OK-test-RIPEMD160
# mod32+ redefined
# hex2L redefined
OK-test-Blowfish
OK-test-bcrypt
# mod32+ redefined
# mod32* redefined
# hex2L redefined
OK-test-twofish
# endian redefined
OK-test-threefish
# hex2L redefined
OK-test-RC2
# mod32* redefined
# hex2L redefined
OK-test-rc5
OK-test-rc6
# f redefined
# num64 redefined
# create redefined
OK-test-camellia
# expand redefined
OK-test-idea
OK-test-MD4
OK-test-SHA1
# num64 redefined
# sbox redefined
OK-test-Tiger
# wsbox redefined
OK-test-Whirlpool
OK-test-JH256
# num32 redefined
OK-test-anubis
# rol redefined
OK-test-scrypt
# endian redefined
OK-test-blake2s
# endian redefined
OK-test-blake2b
# i redefined
OK-test-Kangaroo12
crypto-ALL-OK
OK-All

Cool! Thanks!


BR,
Geo

On Sun, Apr 19, 2020 at 8:17 PM 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
>
> My testing status for https://github.com/picolisp/picolisp
>
> 1. pil @lib/test.l +
> clang  - ok
> clang+asan - ok
> tcc-git- ok
>
>
> 2. huge.l - failed (you must take care)
> $ git clone https://git.envs.net/mpech/tankf33der.git
> $ cd tankf33der
> $ pil huge.l +
> OK-UTF8
> OK-Montgomery
> OK-Leibniz
> OK-math
> OK-forth
> OK-parse2list
> OK-mapreduce
> OK-pow
> OK-destr
> OK-test-car
> OK-bitwise
> # reduce redefined
> # pow redefined
> OK-4clojure
> # pow redefined
> // hangs in advent2015/code2015.l
> // is it hangs or very-very slow?
> // the same in crypto/test.l
>
> !!!
> Super goal - huge.l should pass all code with your patch set.
>
>
> p.s. I dont have enough energy right now to debug all this.
>
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Stop using US controlled software stacks!!!

[George-Phillip Orais]

Hi Alex,

Indeed! How can I missed that hehe if I remember correctly, the character
for commenting was not yet ‘#’ right?

So cool!! thanks for reminding me ;)



BR,
Geo


On Sun, Apr 19, 2020 at 6:37 PM Alexander Burger 
wrote:

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

[George-Phillip Orais]

Hi Guido,

You mentioned nokolisp, I also tried that and from what I remember the
source code was only runnable on an old DOS?

One thing that was cool about nokolisp was it was intended for Nokie phones
right?

How about Lisp dialects made in Japan? Im interested to hear your thoughts
about them as well :)



BR,
Geo

Re: Stop using US controlled software stacks!!!

[George-Phillip Orais]

Just for fun: I cannot imagine Guido's email what if Alex will announce
that he will stop pil21 and decide to port PicoLisp to WINDOWS and use .NET
as official VM ^^



On Sun, Apr 19, 2020 at 7:24 AM  wrote:

> Hey Guido!
>
> While I don't disagree with you in spirit (and I'm sure it's the same for
> most  of our community, we're a bunch of purist radicals), I have to
> disagree with your tone.
>
> And i can assure you: My influence is **much bigger** than you might
> think! Stop that, immediately!
>
> This is childish. You think we would part of this niche community (even
> pico-tiny within the lisp culture) if such words would work on us? Think
> again.
>
> We're not so much interested to convert anyone to our path by doing
> missionary work - nice if it happens, we welcome it, but not for the price
> of our principles. We foster the old programming hacker culture, only
> practical results (be it elegant code, elegant designs or well-thought
> arguments) count in this group. We don't give a damn about who you know or
> what influence you have. Certainly we like interesting stories, and we're
> open and welcoming to everyone - but for getting respected here you must
> deliver us something we value according to our standards.
>
> You are invited to develop the pil stack further, hands on, what holds you
> back?
> The PicoLisp stack is simple enough that we surely could coordinate
> multiple variants if people like to do the work. Less talking and more
> doing, Guido!
> Theorizing is nice and sometimes worthwile, but we're allergic to mental
> masturbation, let's not mix up the map with the real territory.
>
> Kind regards and no offense,
> beneroth
> On 18.04.20 22:46, Guido Stepken wrote:
>
> 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: PicoLisp Sources

[George-Phillip Orais]

Hi Alex,

> No, it is a different symbol, defined in the 'llvm' namespace (see my
previous
> mail).

Ok got it, thanks!


BR,
Geo


On Mon, Apr 13, 2020 at 4:55 PM Alexander Burger 
wrote:

> Hi Geo,
>
> > Would that be the 'car' from the running pil64?
>
> No, it is a different symbol, defined in the 'llvm' namespace (see my
> previous
> mail).
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp Sources

[George-Phillip Orais]

Would that be the 'car' from the running pil64?


BR,
Geo

On Mon, Apr 13, 2020 at 3:55 PM Tomas Hlavaty  wrote:

> Hi Alex,
>
> interesting.
>
> Alexander Burger  writes:
> > Now in pil21 the source is (in "src/subr.l"):
> >
> ># (car 'var) -> any
> >(de _car (Exe)
> >   (car (needVar Exe (eval (cadr Exe )
>
>  ^
> what is this car?
>
> Tomas
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Graph database

[George-Phillip Orais]

Thank you beneroth and Joh-Tob for this impressive and insightful
explanation, very informative for me as well, thank you, I will put this on
my PicoLisp notes.

On Thu, Mar 26, 2020 at 8:29 AM Joh-Tob Schäg  wrote:

> Have you already looked at the family example?
>
> Here is my brief overview of ascending order of abstractedness:
> PicoLisp had no graph database. What is has is this:
>  - The ability to serialize/de-serialize all structures in the heap
> (Lists, numbers, functions, symbols etc)
>  - It has the ability to fetch and deserialize structures when they
> are accessed by their reference (also called external symbol) and also
> GC the loaded content when it is no longer accessable
>  - the ability to make atomic changes to such structures (by write
> locking the database).
>  - it has relations which allow the database to place pointers in one
> or multiple directions, make space for indexes etc... (I have not
> fully grasped that myself)
>  - The are indexes which automatically maintained and those are
> accessible to the database allowing you to discover objects placed in
> the database.
>  - It has an mechanism which allows you to maintain database
> consistent of different machines (replication)
>
> In PicoLisp you can solve many graph database problems with those
> structures, however PicoLisp does not care or know what a vertex is.
> It does not come support for weighted vertexes, you could build your
> own class but is usually more efficient to just implement what you
> actually need, not implement some paradigm because you heard of
> it/like it.
>
> Tailor PicoLisp to your problem, not your paradigm. This is a thing i
> had to learn over a long time.
>
> On Wed, 25 Mar 2020 at 21:46, Lawrence Bottorff  wrote:
> >
> > I'm afraid at my level of CS theory I don't really know what is meant by
> a picolisp atom being persistent, much less across distributed picolisp
> instances. Could someone give me a concrete example of what you describe
> as: "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." I do understand the tree structure of a lisp
> program. But that doesn't make it a graph database. When I tried to fathom
> the Picolisp "graph database" example, I was quickly confused. The GUI
> actually added confusion, AFAIC. I'm guessing from what I could ausknobeln
> from example that the Picolisp version of a CLOS object is a vertex, and
> the inheritance of that object from other (higher, more general?) objects
> is a sort of edge. Correct me if I'm wrong. But then there was talk of
> "records." Is creating a record the same as creating an object instance --
> and this record/object is a vertex? Where, what are the edges?
> >
> > Don't get me wrong, I have long felt that Lisp -- with its parsing
> actually visible in the code you write -- is or could be very
> graphDB-friendly; however, Lisp is functional, i.e., you write functions.
> And even though they are set up as a graph-like tree in nested lists form,
> they are not in themselves data in the traditional sense, rather, code
> meant to take you from a domain/input to a range/result. This is not a
> "record" (or graph vertex?) creation/query/deletion paradigm.
> >
> > But this relates to a long-standing question I've had about software
> libraries. As it stands, they may be auto-indexed for our viewing pleasure,
> but they aren't in any real database form so that you might simply have
> your program "query-and-plug-in" a library. (Although I've heard Haskell's
> hlint almost writes your code for you!) No, you have to find the module,
> plug it in yourself. The whole "code is data", therefore, doesn't seem to
> get past the higher-order function trick of passing in a function as an
> argument. What more is there to "code is data?" In Fortran the data was in
> fact parked just below the code.
> >
> > At some point I'm just scared and rambling on
> >
> > On Wed, Mar 25, 2020 at 7:12 AM Guido Stepken 
> wrote:
> >>
> >> 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 

Re: PicoLisp on windows

[George-Phillip Orais]

Ah ok got it, thanks for the clarification.

Hmm maybe you can also try the Emu of Pil64, its in C also.


BR,
Geo

On Wed, Mar 25, 2020 at 2:23 PM C K Kashyap  wrote:

> By runtime I meant something beyond just the OS - in the case of .net ,
> you need the CLR (like the jvm in case of java). It's just that windows
> machines come with CLR so it is not apparent.
> Regards,
> Kashyap
>
> On Tue, Mar 24, 2020 at 10:08 PM George-Phillip Orais <
> orais.georgephil...@gmail.com> wrote:
>
>> Hi Kashyap,
>>
>> That's also one of my plan so it will work on Linux and Mac, but will see
>> coz it will be redundant especially for Linux.
>>
>> miniPicoLisp is indeed pure PicoLisp and ideally for embedded systems,
>> but I'm not sure what you mean "not needing any runtime".
>>
>>
>> BR,
>> Geo
>>
>> On Wed, Mar 25, 2020 at 1:43 PM C K Kashyap  wrote:
>>
>>> Thanks all,
>>>
>>> Hey Geo - perhaps you should use .Net core :) - I look forward to your
>>> implementation.
>>>
>>> I'd still like to figure the possibility of adding to miniPicoLisp - I
>>> like the idea not needing any runtime :)
>>>
>>> Regards,
>>> Kashyap
>>>
>>>
>>> On Tue, Mar 24, 2020 at 8:43 PM r cs >> > wrote:
>>>
>>>> Ersatz is much more functional than minipicolisp and includes basic TCP
>>>> networking.
>>>>
>>>> Regards,
>>>> rcs
>>>>
>>>> On Tue, Mar 24, 2020 at 10:51 PM C K Kashyap >>> > wrote:
>>>>
>>>>> Thanks rcs,
>>>>> I just checked - at the very least Ersataz has "call" implemented!!!
>>>>> ...makes it more useful that miniPicoLIsp.
>>>>> Regards,
>>>>> Kashyap
>>>>>
>>>>> On Tue, Mar 24, 2020 at 7:27 PM C K Kashyap 
>>>>> wrote:
>>>>>
>>>>>> Hi rcs,
>>>>>> I had not considered Erstaz since I assumed that it is equivalent in
>>>>>> capability to miniPicoLisp and has the added requirement of JVM. While I 
>>>>>> am
>>>>>> sure about the JVM part, I am not so sure about the capabilityis that
>>>>>> not so?
>>>>>> Regards,
>>>>>> Kashyap
>>>>>>
>>>>>> On Tue, Mar 24, 2020 at 7:03 PM r cs  wrote:
>>>>>>
>>>>>>> Kashyap:
>>>>>>>
>>>>>>> Have you considered Ersatz on Windows?
>>>>>>>
>>>>>>> Regards,
>>>>>>> rcs
>>>>>>>
>>>>>>> On Tue, Mar 24, 2020 at 6:55 PM C K Kashyap 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
>>>>>>> (There is no fireside like your own fireside.)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
>>>> (There is no fireside like your own fireside.)
>>>>
>>>>
>>>>

Re: PicoLisp on windows

[George-Phillip Orais]

Hi Kashyap,

That's also one of my plan so it will work on Linux and Mac, but will see
coz it will be redundant especially for Linux.

miniPicoLisp is indeed pure PicoLisp and ideally for embedded systems, but
I'm not sure what you mean "not needing any runtime".


BR,
Geo

On Wed, Mar 25, 2020 at 1:43 PM C K Kashyap  wrote:

> Thanks all,
>
> Hey Geo - perhaps you should use .Net core :) - I look forward to your
> implementation.
>
> I'd still like to figure the possibility of adding to miniPicoLisp - I
> like the idea not needing any runtime :)
>
> Regards,
> Kashyap
>
>
> On Tue, Mar 24, 2020 at 8:43 PM r cs  > wrote:
>
>> Ersatz is much more functional than minipicolisp and includes basic TCP
>> networking.
>>
>> Regards,
>> rcs
>>
>> On Tue, Mar 24, 2020 at 10:51 PM C K Kashyap > > wrote:
>>
>>> Thanks rcs,
>>> I just checked - at the very least Ersataz has "call" implemented!!!
>>> ...makes it more useful that miniPicoLIsp.
>>> Regards,
>>> Kashyap
>>>
>>> On Tue, Mar 24, 2020 at 7:27 PM C K Kashyap  wrote:
>>>
 Hi rcs,
 I had not considered Erstaz since I assumed that it is equivalent in
 capability to miniPicoLisp and has the added requirement of JVM. While I am
 sure about the JVM part, I am not so sure about the capabilityis that
 not so?
 Regards,
 Kashyap

 On Tue, Mar 24, 2020 at 7:03 PM r cs  wrote:

> Kashyap:
>
> Have you considered Ersatz on Windows?
>
> Regards,
> rcs
>
> On Tue, Mar 24, 2020 at 6:55 PM C K Kashyap 
> wrote:
>
>> 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
>>
>
>
> --
> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
> (There is no fireside like your own fireside.)
>
>
>
>>
>> --
>> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
>> (There is no fireside like your own fireside.)
>>
>>
>>

Re: PicoLisp on windows

[George-Phillip Orais]

Hi Kahsyap et al,

First of all, I hope everyone here and everyone's family are doing well,
safe and far from the COVID19 danger.
Today I started to work from home because yesterday the report came that
one worker from different company but in the same building of our office is
COVID19 positive, so our company shifts to code red which means full work
from home.
I hope and pray this pandemic will end soon so that we can all go back to
our normal and safe life.

Back to original subject, I am also interested of this subject. Actually I
am working on something for this and plan to announce it once I have
something to show. But because you are asking, maybe I could share some
info here.

I am currently planning to implement PicoLisp on .Net framework with these
two approach:
1. Using DLR which is used for IronPython and IronRuby
2. Implement from scratch and use DLR as reference

Progress is a bit slow because of work, but aiming to make something happen
before or on PicoLisp Conference :)


BR,
Geo

On Wed, Mar 25, 2020 at 11:51 AM C K Kashyap  wrote:

> Thanks rcs,
> I just checked - at the very least Ersataz has "call" implemented!!!
> ...makes it more useful that miniPicoLIsp.
> Regards,
> Kashyap
>
> On Tue, Mar 24, 2020 at 7:27 PM C K Kashyap  wrote:
>
>> Hi rcs,
>> I had not considered Erstaz since I assumed that it is equivalent in
>> capability to miniPicoLisp and has the added requirement of JVM. While I am
>> sure about the JVM part, I am not so sure about the capabilityis that
>> not so?
>> Regards,
>> Kashyap
>>
>> On Tue, Mar 24, 2020 at 7:03 PM r cs  wrote:
>>
>>> Kashyap:
>>>
>>> Have you considered Ersatz on Windows?
>>>
>>> Regards,
>>> rcs
>>>
>>> On Tue, Mar 24, 2020 at 6:55 PM C K Kashyap  wrote:
>>>
 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

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

Merry Christmas!!

[George-Phillip Orais]

Hi Everyone!

Just want to greet you all a Merry Christmas and Happy New Year in advance!

More power to Pico Lisp community and once again, thank you Alex for
sharing your talents to us.


Cheers from Philippines,
Geo

Re: freemint in Tokyo

[George-Phillip Orais]

Hi rick and pd!

Thanks! hehe its made here coz I am not able to order the one in online :)



On Fri, Dec 13, 2019 at 11:39 PM  wrote:

> Very cool!  Nice shirt BTW, geo. :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Subscribe

[George-Phillip Orais]

hello