Re: Future of PicoLisp?

[Henrik Sarvell]

I agree here, there's been a few instances over the years where people have
talked about putting the source on Git (I can't believe it's been almost 10
years now), but in the end the only actual contributions have not amounted
to much more than a few changes to the header files to make things easier
to compile on for instance OS X and BSD.

So let's face it, it's just talk without any practical value apart from
making the project perhaps a bit more visible.

In the beginning I had comments on in my bitbucket repo (
https://bitbucket.org/hsarvell/ ) which I quickly turned off due to
statements like "why doesn't it just work, please help me" and the like, no
collaboration whatsoever on the form of "hi I just downloaded and had some
issues that I solved, here's the pull request".




On Thu, Feb 23, 2017 at 10:46 PM, Lindsay John Lawrence <
lawrence.lindsayj...@gmail.com> wrote:

> I am relatively new to picolisp, with limited knowledge of its development
> history... but I'll politely disagree with some suggestions here regarding
> making the core more 'popular' and open to 'collaborative' development.
>
> Bandwagon collaboration may in all likelihood dull the scapel and result
> in  something far from pico.
>
> What would be great is to see more of an ecosystem built around the
> picolisp core. Build something awesome with picolisp, document it and share
> it with the world.
>
> I am.
>
> /Lindsay
>
>
> ~~~
> Notes: I made as a read through the email thread...penny thoughts, ...a
> bit opinionated and repetitive and therefore subject to change.
>
> Make what more open? From what I can see, the source going back to at
> least 2002 is freely available for anyone to copy and do with as they like.
> There is no lack of transparency or reluctance to share knowledge.
>
> Compared to almost every other development tool I have worked with,
> picolisp is a breath of fresh air.  The more I breathe in, study the
> succinct examples on the wiki, rosetta code, 99probs, tankfeeder, etc the
> more I appreciate that. Many of those examples, despite their brevity, are
> far from trivial.
>
> It is a scapel. A lot a fun to play with. But it is neither a toy lisp, an
> overspecialized lisp, or -- what it feels like to me now -- the 'all things
> to everyone' bloated cruft that is common lisp.
>
> In the short time I have worked with it, I have yet to write a 'hack' to
> get around some limitation or shortcoming of the picolisp environment. I
> have written a surprising amount of useful code and connected it to other
> tools to do useful things in concert.
>
> It is lisp. Therefore, initially, "Lots of Irritating, Silly, Parentheses"
>  that with practice, quickly become an appreciated, simple consistent
> syntax. Syntax sugar is overrated. Look at the mess of most other
> programming languages as they try to add 'advanced' features.
>
> Even as a newbie, I can see how easily the current picolisp core can
> integrate with, or integrate, other tools. How easy it is to leverage
>  functionality like distributed programming, async io, templated
> programming, underlying os pipes, etc that most other runtimes either don't
> provide at all, end up diluting or obfuscating.
>
> In what other language, even other lisps, is it as easy to say... (= code
> data) ?
>
> A high performance, general purpose, interpreted runtime engine, in a few
> hundred kilobytes?. I wish I had 'discovered' it a decade ago.
>
>
>

Re: Future of PicoLisp?

[Edgaras]

Just a lurker passing by:

Personally I'm much less excited about things like pip or node.js packages.
While I get their appeal often times you end up with quite a nonses like
node.js left-pad issue of year or so ago. In my eyes it promotes a kinda of
"shatered into milion pieces" situation. I'm much more keen on how things are
in C land - go get stuff yourself :). Which somewhat prevents "dependacny
creep".

On Fri, Feb 24, 2017 at 09:02:57AM +0100, Jakob Eriksson wrote:
> And I would be interested in working on a package or module system similar to 
> "pip" for Python.
> 
> I must confess that most discussions about namespaces etc on this list is way 
> over my head... however could I be on the right track if I were to assume 
> that using "local" in such modules would be a good start, so as to only 
> export deliberately exposed symbols from a package?
> 
> 
> 
> 
> > 24 feb. 2017 kl. 08:45 skrev Alexander Burger :
> > 
> > Hi Erik,
> > 
> > thanks for the long post!
> > 
> > Just in short:
> > 
> >> 'Learn PicoLisp the Hard Way'
> > 
> > I totally agree. This would be a great project, I'm ready to join.
> > Same for Stack Overflow support.
> > 
> > 
> >> And let's make sure said landing page is served over HTTPS. It's 2017.
> > 
> > Yes, yes, I know ;) In fact, it is on my todo list since half a year.
> > 
> > I want to use Let's Encrypt, as I already do on another server. However, the
> > picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
> > whatever I tried to get the certbot running resulted in a storm of Python
> > package mismatch error messages. No way .. I gave up, and decided to wait 
> > until
> > Debian Stretch is stable and thus available from my provider.
> > 
> > ♪♫ Alex
> > -- 
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Alexander Burger]

Thanks Lindsay, Mansur, good hints. I take a look at alternate ways,
hopefully without Python, to Let's Encrypt.

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

Re: Future of PicoLisp?

[Alexander Burger]

On Fri, Feb 24, 2017 at 08:25:21AM -0600, Erik Gustafson wrote:
> and also javascript (json, frameworks, ...)
> 
> Now we're talking! I think PicoLisp would pair nicely with some of the
> popular libraries and frameworks. Joe built
> https://github.com/joebo/pil-mithril-scaffold. A similar project for React

Interfacing with JavaScript is indeed quite simple.

In addition to the built-in stuff in @lib/form.js (including a JS lisp()
function which calls a Lisp function on the server!), or @lib/canvas.js for
canvas drawing, I interfaced to the TinyMCE editor (also in the distribution, in
@lib/tinymce.l) for some projects, e.g. https://BlitzMenu.7fach.de

Another example are the social privacy buttons (used in picolisp.com or
sushi.7fach.de), available in http://software-lab.de/socialshareprivacy.tgz.

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

Re: Future of PicoLisp?

[Alexander Burger]

On Fri, Feb 24, 2017 at 08:34:20AM -0600, Erik Gustafson wrote:
> > picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
> > whatever I tried to get the certbot running resulted in a storm of Python
> > package mismatch error messages. No way .. I gave up, and decided to wait
> > until
> > Debian Stretch is stable and thus available from my provider.
> >
> 
> Sounds like a headache, I don't blame you. I'll be cheering for the Debian
> folks this
> year!

Thanks!

BTW, if need be, picolisp.com can be reached with HTTPS also under

   https://7fach.de/wiki

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

Re: Future of PicoLisp?

[Mansur Mamkin]

Hi all!
About certbot:
See also other tools:
https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/
I've seen acmetool in action (written in Golang, so it requires no 
dependencies).
I see there is a tool, written even in Bash 

Best regards, 
Mansur

--skipped--
>> And let's make sure said landing page is served over HTTPS. It's 2017.
>
>Yes, yes, I know ;) In fact, it is on my todo list since half a year.
>
>I want to use Let's Encrypt, as I already do on another server. However, the
>picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
>whatever I tried to get the certbot running resulted in a storm of Python
>package mismatch error messages. No way .. I gave up, and decided to wait until
>Debian Stretch is stable and thus available from my provider.
>
>♪♫ Alex
>-- 
>UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Lindsay John Lawrence]

Hi Alex,

I've been using LetsEncrypt.

This page https://gethttpsforfree.com clearly documents the steps to get a
certificate manually.
I ended up writing an automated javascript (nodejs) version of the steps on
that page that works for my purposes but is essentially just 'get it done'
 code.

It should be straightforward to write a picolisp version of it...

/Lindsay



On Thu, Feb 23, 2017 at 11:45 PM, Alexander Burger 
wrote:

> Hi Erik,
>
> thanks for the long post!
>
> Just in short:
>
> > 'Learn PicoLisp the Hard Way'
>
> I totally agree. This would be a great project, I'm ready to join.
> Same for Stack Overflow support.
>
>
> > And let's make sure said landing page is served over HTTPS. It's 2017.
>
> Yes, yes, I know ;) In fact, it is on my todo list since half a year.
>
> I want to use Let's Encrypt, as I already do on another server. However,
> the
> picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
> whatever I tried to get the certbot running resulted in a storm of Python
> package mismatch error messages. No way .. I gave up, and decided to wait
> until
> Debian Stretch is stable and thus available from my provider.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Erik Gustafson]

Hi Alex,

> 'Learn PicoLisp the Hard Way'
>
> I totally agree. This would be a great project, I'm ready to join.
> Same for Stack Overflow support.
>

Great! I'll reach out to Zed and confirm that this is still kosher.


> Yes, yes, I know ;) In fact, it is on my todo list since half a year.
>
> I want to use Let's Encrypt, as I already do on another server. However,
> the
> picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
> whatever I tried to get the certbot running resulted in a storm of Python
> package mismatch error messages. No way .. I gave up, and decided to wait
> until
> Debian Stretch is stable and thus available from my provider.
>

Sounds like a headache, I don't blame you. I'll be cheering for the Debian
folks this
year!

- Erik

Re: Future of PicoLisp?

[Erik Gustafson]

Hi Andrés,


> I think it's a terrific idea and I'm volunteer to work on it
>

Great, thanks!


> I also think it's a great idea since I think picolisp has a strong
> strength in web developing but just because it's 2017 I feel the effort
> must be put in integrating picolisp with web (W3C) technologies (css, html
> 5, xml, websockets...)
>

I think we're doing fairly well here. css is very easy to integrate, see
http://picolisp.com/wiki/?css

For html 5, I usually just define the tags I need on a per project basis,
like the other tag functions in the 'lib/xhtml.l', e.g.

   (load "@lib/xhtml.l")

   (de  (Attr . Prg)
  (tag 'section Attr 2 Prg)
  (prinl) )

Henrik and Jose have done work with websockets. See:
https://bitbucket.org/hsarvell/pl-web

But don't let that stop you from running with your own ideas!

and also javascript (json, frameworks, ...)
>

Now we're talking! I think PicoLisp would pair nicely with some of the
popular libraries and frameworks. Joe built
https://github.com/joebo/pil-mithril-scaffold. A similar project for React
or Vue with a PicoLisp DB would be cool! I
made an attempt with React last year, but did not progress beyond a couple
'Hello World' programs and a clone
of the React Comment Box Tutorial backed by a PicoLisp DB.
https://github.com/erdg/picolisp-react

Anything that could help introduce PicoLisp and its built-in DB to a wider
web-dev audience would be time well
spent, in my mind. I'm happy to collaborate on that front!

It would be great also to deploy the web in apache or nginx (even lighttpd
> or cherokee) to documentate how to integrate picolisp in a corporative
> environmet. It would be useful too to use also picolisp as webserver
> (httpgate) and show how to scale it up.
>

I know others have used similar setups in the past (Henrik, was it?). Is
there an existing write-up regarding this?

- Erik

Re: Future of PicoLisp?

[Jakob Eriksson]

And I would be interested in working on a package or module system similar to 
"pip" for Python.

I must confess that most discussions about namespaces etc on this list is way 
over my head... however could I be on the right track if I were to assume that 
using "local" in such modules would be a good start, so as to only export 
deliberately exposed symbols from a package?




> 24 feb. 2017 kl. 08:45 skrev Alexander Burger :
> 
> Hi Erik,
> 
> thanks for the long post!
> 
> Just in short:
> 
>> 'Learn PicoLisp the Hard Way'
> 
> I totally agree. This would be a great project, I'm ready to join.
> Same for Stack Overflow support.
> 
> 
>> And let's make sure said landing page is served over HTTPS. It's 2017.
> 
> Yes, yes, I know ;) In fact, it is on my todo list since half a year.
> 
> I want to use Let's Encrypt, as I already do on another server. However, the
> picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
> whatever I tried to get the certbot running resulted in a storm of Python
> package mismatch error messages. No way .. I gave up, and decided to wait 
> until
> Debian Stretch is stable and thus available from my provider.
> 
> ♪♫ Alex
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

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

Re: Future of PicoLisp?

[Alexander Burger]

Hi Erik,

thanks for the long post!

Just in short:

> 'Learn PicoLisp the Hard Way'

I totally agree. This would be a great project, I'm ready to join.
Same for Stack Overflow support.


> And let's make sure said landing page is served over HTTPS. It's 2017.

Yes, yes, I know ;) In fact, it is on my todo list since half a year.

I want to use Let's Encrypt, as I already do on another server. However, the
picolisp.com server is currently a mix of Wheezy, Jessie and Stretch, and
whatever I tried to get the certbot running resulted in a storm of Python
package mismatch error messages. No way .. I gave up, and decided to wait until
Debian Stretch is stable and thus available from my provider.

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

Re: Future of PicoLisp?

[pd]

On Fri, Feb 24, 2017 at 1:14 AM, Erik Gustafson 
wrote:

>
>
> 'Learn PicoLisp the Hard Way'
>
> What do you think?
>

I think it's a terrific idea and I'm volunteer to work on it



>
>
> Let's build picolisp.com from scratch. Still in written in PicoLisp, duh!
> Make it a simple, beautiful, modern, responsive home page. And only a home
> page. Something like what I had in mind here, but better:
>
> https://github.com/erdg/picolisp-website
>
> (that is sooo late 2015, lol)
>
> So a simple landing page that introduces the language and loudly points to
> our new book, 'Learn PicoLisp the Hard Way'. Then we transition the
> documentation to GitHub and Stack Overflow, so the whole internet can be
> impressed by how active our community is.
>
> And let's make sure said landing page is served over HTTPS. It's 2017.
>
>
I also think it's a great idea since I think picolisp has a strong strength
in web developing but just because it's 2017 I feel the effort must be put
in integrating picolisp with web (W3C) technologies (css, html 5, xml,
websockets...) and also javascript (json, frameworks, ...)

So what if building picolisp.com from sacratch with presentation done by
CSS javascript framework like jquery and/or bootstrap and content made
compatible with html5 using websockets and json to make an api rest
available for example to communicate with picolisp repl ?

It would be great also to deploy the web in apache or nginx (even lighttpd
or cherokee) to documentate how to integrate picolisp in a corporative
environmet. It would be useful too to use also picolisp as webserver
(httpgate) and show how to scale it up.

I'm volunteer to this too ;-)

-- 
Andrés

*~ La mejor manera de librarse de la tentación es caer en ella**. ~ Oscar
Wilde* ~

Re: Future of PicoLisp?

[Erik Gustafson]

Hey all,

Another long post.


TLDR: leave the core language development strategy untouched, re-redo the
website, and migrate documentation to GitHub/Stack Overflow.


Re: Git(Hub) for the core language... I'm also on Alex's side here. His
time for core development is invaluable. We would be wise to keep the
process as frictionless as possible for him. No need to fix what isn't
broken.

This conversation seems to come up every year. We all spend a while
rehashing the same arguments, and nothing changes.

Now, I agree that there is a problem with the future of PicoLisp. But it
does NOT have to do with the core language and whether it's hosted here or
there or whatever.

Here's an idea that's been bouncing around my head. I think it could
address some of the problems we're facing (more on that below).

'Learn PicoLisp the Hard Way'

I'm currently working through Zed Shaw's 'Learn C the Hard Way'. It's a
wonderful book, meant for people who already know the basics of programming
(they've learned a language or several). Starting out with the C basics,
the book quickly ramps up. After 52 exercises the student is dropped off on
the far side of intermediate C programming. They have a solid command of
the language, can read and write proficiently, have built a handful of
non-trivial projects along the way, and thus become familiar with common
libraries and tooling in the ecosystem.

The book is also huge on what Zed calls the 'Defensive Programming
Mindset'. For each exercise, there is a section on how to break the code.
So the student learns how to mess up each program in different ways,
exposing all sorts of weird behavior. It shows that the C compiler is not
your friend and really couldn't care less if you trample all over memory.
Through this breaking process, the student learns so much about the
language, common pitfalls, and how to defend against them. This practice
would pair well with PicoLisp, an even more powerful and potentially abused
language.

So I'm proposing a community driven project of 'Learn PicoLisp the Hard
Way'. This would be great for several reasons:

As Lindsay mentioned, PicoLisp lacks a project that the whole community is
behind. We're a bunch of individuals hacking our own stuff, asking Alex
similar questions over and over again. So let's make it a community sourced
project, we'll use GitHub. Boom! Strong GitHub presence checked off the
list.

PicoLisp lacks a coherent front for documentation. So let's distill all
PicoLisp knowledge into a series of 52 exercises. Make it the new face of
PL documentation. Start here, work through this book, and when you're
finished you'll be a strong member of the PicoLisp community. This would
alleviate 'mailing list fatigue'.

Honestly it's mostly an editing challenge. There is so much code buried in
this list and scattered throughout the internet. We just need to assemble
it into a series of exercises that build on each other.

The progression might be something like this:

Set up environment -> Lisp fundamentals -> OOP/DB -> Web Apps w/GUI ->
distributed DB's -> 'native' C stuff -> put it all together for something
awesome (like, idk, a text editor written in PicoLisp?!)

We'll also whip up some short video lectures to accompany the exercises in
the book.

'Learn PicoLisp the Hard Way'

What do you think?

And for the record, I believe Mr. Shaw is onboard with this idea - or at
least he was at one point. Search for 'Learn X the Hard Way'.


Finally some other thoughts as to how we can continue to improve the future
of PicoLisp...

Let's be real, the wiki sucks. I say this as the guy who spent many many
hours last year redesigning it, editing content, trying to make it more
coherent, etc. It's still a mess. The UI is clunky. Its overwhelming for
newcomers. And no one wants to deal with yet another markup language
(though I'll admit I've grown rather fond of it).

Let's build picolisp.com from scratch. Still in written in PicoLisp, duh!
Make it a simple, beautiful, modern, responsive home page. And only a home
page. Something like what I had in mind here, but better:

https://github.com/erdg/picolisp-website

(that is sooo late 2015, lol)

So a simple landing page that introduces the language and loudly points to
our new book, 'Learn PicoLisp the Hard Way'. Then we transition the
documentation to GitHub and Stack Overflow, so the whole internet can be
impressed by how active our community is.

And let's make sure said landing page is served over HTTPS. It's 2017.

Whelp, that was a lot. Take sometime to digest, and then please rip these
ideas to pieces, folks!

"The night is darkest just before the dawn. And I promise you, the dawn is
coming."

-- Some dude in some Batman movie


Peace and PicoLisp y'all!

- Erik

Re: Future of PicoLisp?

[Joh-Tob Schäg]

T
Am 23.02.2017 22:52 schrieb "Lindsay John Lawrence" <
lawrence.lindsayj...@gmail.com>:

> I am relatively new to picolisp, with limited knowledge of its development
> history... but I'll politely disagree with some suggestions here regarding
> making the core more 'popular' and open to 'collaborative' development.
>
> Bandwagon collaboration may in all likelihood dull the scapel and result
> in  something far from pico.
>
> What would be great is to see more of an ecosystem built around the
> picolisp core. Build something awesome with picolisp, document it and share
> it with the world.
>
> I am.
>
> /Lindsay
>
>
> ~~~
> Notes: I made as a read through the email thread...penny thoughts, ...a
> bit opinionated and repetitive and therefore subject to change.
>
> Make what more open? From what I can see, the source going back to at
> least 2002 is freely available for anyone to copy and do with as they like.
> There is no lack of transparency or reluctance to share knowledge.
>
> Compared to almost every other development tool I have worked with,
> picolisp is a breath of fresh air.  The more I breathe in, study the
> succinct examples on the wiki, rosetta code, 99probs, tankfeeder, etc the
> more I appreciate that. Many of those examples, despite their brevity, are
> far from trivial.
>
> It is a scapel. A lot a fun to play with. But it is neither a toy lisp, an
> overspecialized lisp, or -- what it feels like to me now -- the 'all things
> to everyone' bloated cruft that is common lisp.
>
> In the short time I have worked with it, I have yet to write a 'hack' to
> get around some limitation or shortcoming of the picolisp environment. I
> have written a surprising amount of useful code and connected it to other
> tools to do useful things in concert.
>
> It is lisp. Therefore, initially, "Lots of Irritating, Silly, Parentheses"
>  that with practice, quickly become an appreciated, simple consistent
> syntax. Syntax sugar is overrated. Look at the mess of most other
> programming languages as they try to add 'advanced' features.
>
> Even as a newbie, I can see how easily the current picolisp core can
> integrate with, or integrate, other tools. How easy it is to leverage
>  functionality like distributed programming, async io, templated
> programming, underlying os pipes, etc that most other runtimes either don't
> provide at all, end up diluting or obfuscating.
>
> In what other language, even other lisps, is it as easy to say... (= code
> data) ?
>
> A high performance, general purpose, interpreted runtime engine, in a few
> hundred kilobytes?. I wish I had 'discovered' it a decade ago.
>
>
>

Re: Future of PicoLisp?

[Lindsay John Lawrence]

I am relatively new to picolisp, with limited knowledge of its development
history... but I'll politely disagree with some suggestions here regarding
making the core more 'popular' and open to 'collaborative' development.

Bandwagon collaboration may in all likelihood dull the scapel and result in
 something far from pico.

What would be great is to see more of an ecosystem built around the
picolisp core. Build something awesome with picolisp, document it and share
it with the world.

I am.

/Lindsay


~~~
Notes: I made as a read through the email thread...penny thoughts, a
bit opinionated and repetitive and therefore subject to change.

Make what more open? From what I can see, the source going back to at least
2002 is freely available for anyone to copy and do with as they like. There
is no lack of transparency or reluctance to share knowledge.

Compared to almost every other development tool I have worked with,
picolisp is a breath of fresh air.  The more I breathe in, study the
succinct examples on the wiki, rosetta code, 99probs, tankfeeder, etc the
more I appreciate that. Many of those examples, despite their brevity, are
far from trivial.

It is a scapel. A lot a fun to play with. But it is neither a toy lisp, an
overspecialized lisp, or -- what it feels like to me now -- the 'all things
to everyone' bloated cruft that is common lisp.

In the short time I have worked with it, I have yet to write a 'hack' to
get around some limitation or shortcoming of the picolisp environment. I
have written a surprising amount of useful code and connected it to other
tools to do useful things in concert.

It is lisp. Therefore, initially, "Lots of Irritating, Silly, Parentheses"
 that with practice, quickly become an appreciated, simple consistent
syntax. Syntax sugar is overrated. Look at the mess of most other
programming languages as they try to add 'advanced' features.

Even as a newbie, I can see how easily the current picolisp core can
integrate with, or integrate, other tools. How easy it is to leverage
 functionality like distributed programming, async io, templated
programming, underlying os pipes, etc that most other runtimes either don't
provide at all, end up diluting or obfuscating.

In what other language, even other lisps, is it as easy to say... (= code
data) ?

A high performance, general purpose, interpreted runtime engine, in a few
hundred kilobytes?. I wish I had 'discovered' it a decade ago.

Re: Future of PicoLisp?

[Rowan Thorpe]

On 23 February 2017 at 19:45, Alexander Burger  wrote:
> ..[snip]..
> > checkout hook to force a full build after checkout. It was years ago,
> > and I can't find them now that I search for them, but I remember it
> > was not too difficult to implement (and I'll keep an eye out for them
>
> Yes, did so too, around 2008 for SVN. But such tricks are a cludge.

Too true...

> ..[snip]..
> But, *of course*, nobody will be stopped to do with PicoLisp whatever he 
> likes.
> Anybody can build a repo (as some people here already did), and communicate on
> in whatever platform. I just don't see that *I* have to do it.

Of course it makes sense you don't have to do anything people ask you
on a mailing list :-D which is why I emphasise I was just
"campaigning" for the merits of a workflow in the broader context (and
I believe others were too) - it can't hurt to try to sway opinion
occasionally... Of course the debate about workflows helping
user-flexibility, community-building, integration, exposure, etc all
comes second-priority to you developing picolisp in the way that
doesn't obstruct/limit you. For that reason it is good you outlined
your workflow so clearly:

> I live on incremental snapshots [...] has the environment from that
> moment (not only source files explicitly checked in [...] Forcing my
> working style to the limitations of a repo would be a drawback.

..so anyone who wants to pursue the issue in the future can read that
in the mail-archives before doing so.

-- 
Rowan Thorpe
"A riot is the language of the unheard." - Dr. Martin Luther King
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
"Ignorance requires no apologies when it presents questions
rather than assertions." - Michael Sierchio (OpenSSL mailing list)
"What we need more than an end to wars is an end to the
beginning of all wars." - Franklin Roosevelt
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Michel Pelletier]

There is a tool called metastore meant specifically to use with vcs hooks
to save and restore file metadata.

https://github.com/przemoc/metastore

-Michel


On Feb 23, 2017 9:52 AM, "Alexander Burger"  wrote:

> Hi Jakob, Rowan,
>
> thanks for the good hints!
>
> > "alea iacta est". However - just in case you are not already aware -
> > since version 2.2.2 git now only updates modification times on
> > *changed* files during checkout (see
> > https://github.com/git/git/commit/c5326bd62b7e168ba1339dacb7ee81
> 2d0fe98c7c),
>
> I see. Good to know. I suppose, however, that if you clone a whole new
> repo you
> won't get the original timestamps of the whole tree (as you would from a
> TGZ).
>
>
> > checkout hook to force a full build after checkout. It was years ago,
> > and I can't find them now that I search for them, but I remember it
> > was not too difficult to implement (and I'll keep an eye out for them
>
> Yes, did so too, around 2008 for SVN. But such tricks are a cludge.
>
> I won't use such a repo based system here. Period. I live on incremental
> snapshots which I take from my whole home directory tree several times a
> day,
> with statistics and inspection tools, and other scripts. Each of thess
> snapshots
> is fully complete, and has the environment from that moment (not only
> source
> files explicitly checked in, but also temporary files, databases, backups
> and
> whatever). Forcing my working style to the limitations of a repo would be a
> drawback.
>
>
> But, *of course*, nobody will be stopped to do with PicoLisp whatever he
> likes.
> Anybody can build a repo (as some people here already did), and
> communicate on
> in whatever platform. I just don't see that *I* have to do it.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Jakob Eriksson]

On 2017-02-23 18:45, Alexander Burger wrote:

> I won't use such a repo based system here. Period.


Ok, then we have status quo, or if someone steps up and becomes what
Alan Cox for many years was to the Linus and the Linux kernel. Basically
a maintainer, merging between distributions (users) and "upstream" (LKML
and Linus). Maybe one of the PicoLisp repos on Github already has that
role, I don't know, I have not been in the loop about PicoLisp
development. (Only lurking on this list.)


best regards,
Jakob
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Alexander Burger]

Hi Jakob, Rowan,

thanks for the good hints!

> "alea iacta est". However - just in case you are not already aware -
> since version 2.2.2 git now only updates modification times on
> *changed* files during checkout (see
> https://github.com/git/git/commit/c5326bd62b7e168ba1339dacb7ee812d0fe98c7c),

I see. Good to know. I suppose, however, that if you clone a whole new repo you
won't get the original timestamps of the whole tree (as you would from a TGZ).


> checkout hook to force a full build after checkout. It was years ago,
> and I can't find them now that I search for them, but I remember it
> was not too difficult to implement (and I'll keep an eye out for them

Yes, did so too, around 2008 for SVN. But such tricks are a cludge.

I won't use such a repo based system here. Period. I live on incremental
snapshots which I take from my whole home directory tree several times a day,
with statistics and inspection tools, and other scripts. Each of thess snapshots
is fully complete, and has the environment from that moment (not only source
files explicitly checked in, but also temporary files, databases, backups and
whatever). Forcing my working style to the limitations of a repo would be a
drawback.


But, *of course*, nobody will be stopped to do with PicoLisp whatever he likes.
Anybody can build a repo (as some people here already did), and communicate on
in whatever platform. I just don't see that *I* have to do it.

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

Re: Future of PicoLisp?

[Rowan Thorpe]

[Sorry this is a bit long, I tried to make each point as concise as
possible without missing the point. Also, I know some of the git-usage
details below are well-known already but I include them for context,
and for whoever reads this and is less familiar with git]

On 23 February 2017 at 08:55, Alexander Burger  wrote:
> ..[snip]..
>
> 2. Using a code repository is fine. But I personally will not use any of the
>existing ones, because my working style deeply depends on file meta
>informations (most important the modification date), which are destroyed by
>those repositories. I explained the situation at various occasions. 
> Checking
>files *into* a repo is all right, but as soon as I check them out they 
> would
>be unusable for me.

I realise from your previous emails - e.g.
http://www.mail-archive.com/picolisp@software-lab.de/msg05272.html -
that you are not too keen on a git-or-similar-DVCS for actual
development due to the metadata issues (and believing it to be
overkill), and - as you said in
http://www.mail-archive.com/picolisp@software-lab.de/msg05250.html -
"alea iacta est". However - just in case you are not already aware -
since version 2.2.2 git now only updates modification times on
*changed* files during checkout (see
https://github.com/git/git/commit/c5326bd62b7e168ba1339dacb7ee812d0fe98c7c),
which may be adequate for not messing with the system you have in
place? If that isn't sufficient, for fitting git into an unusual
system I once added shellscript checkout/commit-hooks which
generated-by-find/stat and reinstated-by-touch the metadata from an
index-file in the repo root dir, and added "make clean" to the
checkout hook to force a full build after checkout. It was years ago,
and I can't find them now that I search for them, but I remember it
was not too difficult to implement (and I'll keep an eye out for them
if you think it is at all interesting/worth finding). If using git
would only be interesting without needing "make clean" after
checkouts, then I found this "long answer" quoted from Linus Torvalds
on SO which provides at least 3 other workarounds (his typically
acerbic "short answer" isn't so helpful though):
http://stackoverflow.com/a/1964508

> 3. Being present on StackOverflow would be a good thing.

Because trawling through historical emails and copy-pasting Q&As to
StackOverflow is something no-one would enjoy (but is an easy way to
build "reputation points" for whoever cares about such things), I
suggest that whenever someone asks a question on the mailing-list that
has already been asked-and-answered (I know I did it once on a bad
google-fu day, sorry), they should be urged to ask it on SO and post
it's link back to the mailing list, and then someone can find the
historical answer and copy-paste it as SO-answer (as a quotation, with
link to the original). This would mean:

 * The answer appears at least once independently of SO (in case SO
suddenly goes bankrupt, eggs are in more than one basket).

 * The most recent, google-friendliest iterations of a question in the
mailing list at least include links to SO, so that people who
google-find the mailing list answer first can go to SO and up-vote it
there to help the google-juice rise for those questions, and therefore
to reduce the number of repeat-questions on the list.

 * It is a way to reduce duplicate Q&As in the mailing list in a way
more diplomatic than having to just say "already answered, use
google".

 * SO users see lots of picolisp content pointing back to the
mailing-list, to the wildly impressive fount of knowledge called
regenaxer :-), and can marvel at how nice it is to have the language's
actual architect/author so present and willing to help.

> As for (2), I see no problem with the current situation. Is it so much worse 
> to
> do a "wget http://software-lab.de/picoLisp.tgz"; instead of "git clone .."? The
> change history is in "doc/ChangeLog", and is the same as was checked into
> mercury when we were still using google code.

It goes without saying that it is entirely your (regenaxer)
prerogative if you still don't want to onboard such a workflow, but I
am "campaiging" for it a bit (particularly for publicly accessible
DVCS collaboration-platform) because I have a hunch that it might open
more useful contribution-floodgates than expected, not to mention
boost the public-profile of picolisp more than expected. The reasons
for my hunch are:

Firstly, I think even the best ChangeLog in the world can never
compete with "git log -p" for speed/resolution when finding issues or
points of interest in the code (right next to their commit-message for
context, like a distant cousin of literate-programming), or "git
bisect" when troubleshooting specific nits - and this is equally true
for users as for the maintainer. Due to constant changes a distinct
ChangeLog file is the most likely to prevent a conflict-free merge, so
many deprecate it in favour of only having git-log, but if a ChangeLog
exter

Re: Future of PicoLisp?

[Jakob Eriksson]

https://medium.com/@sitapati/the-impact-github-is-having-on-your-software-career-right-now-6ce536ec0b50#.krwczgbrq



> 23 feb. 2017 kl. 07:55 skrev Alexander Burger :
> 
> Thanks to all who contributed to this thread!! I agree with most of what you
> said.
> 
> However, we are mixing up three different, independent issues:
> 
> 1. My initial post was about political aspects: Ubuntu does not want to build
>   the binary with position-dependent coding (include the -no-pie flag), and in
>   general there is a tendency to Clang, which has certain limitations.
> 

Yes techno political I'd say.



> 2. Using a code repository is fine. But I personally will not use any of the
>   existing ones, because my working style deeply depends on file meta
>   informations (most important the modification date), which are destroyed by
>   those repositories. I explained the situation at various occasions. Checking
>   files *into* a repo is all right, but as soon as I check them out they would
>   be unusable for me.


Maybe we can fix this. Can we discuss this you and I? There may be a solution.

> 
> 3. Being present on StackOverflow would be a good thing.
> 
> 
> As for (2), I see no problem with the current situation. Is it so much worse 
> to
> do a "wget http://software-lab.de/picoLisp.tgz"; instead of "git clone .."?

No not as a distribution method.

However github is not about technology but about the community.

Re: Future of PicoLisp?

[Alexander Burger]

Thanks to all who contributed to this thread!! I agree with most of what you
said.

However, we are mixing up three different, independent issues:

1. My initial post was about political aspects: Ubuntu does not want to build
   the binary with position-dependent coding (include the -no-pie flag), and in
   general there is a tendency to Clang, which has certain limitations.

2. Using a code repository is fine. But I personally will not use any of the
   existing ones, because my working style deeply depends on file meta
   informations (most important the modification date), which are destroyed by
   those repositories. I explained the situation at various occasions. Checking
   files *into* a repo is all right, but as soon as I check them out they would
   be unusable for me.

3. Being present on StackOverflow would be a good thing.


As for (2), I see no problem with the current situation. Is it so much worse to
do a "wget http://software-lab.de/picoLisp.tgz"; instead of "git clone .."? The
change history is in "doc/ChangeLog", and is the same as was checked into
mercury when we were still using google code.

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

Re: Future of PicoLisp?

[andreas]

Hi all

My previous message somehow got broken, half the text is missing.

Please read it here:

http://www.beneroth.ch/pil/picolisp-is-finished.html

Thanks,
beneroth


- Original Message -
From: andr...@itship.ch [mailto:andr...@itship.ch]
To: picolisp@software-lab.de
Sent: Tue, 21 Feb 2017 14:26:53 +0100
Subject: Re: Future of PicoLisp?

Re: Future of PicoLisp?

[andreas]

Hi Petr

Many thanks for your participation and outside view.
Such comments are very valuable to us, as those topics are hard to see from the 
inside.

I believe those feelings are triggered by mainly two source factors:
A) presentation of picolisp information
B) the (rather unusual) state of the picolisp project

A) First and foremost, we as community need to streamline our presence more,
probably mainly by making things more clear on picolisp.com.

We should also more prominently point to the IRC channel, that is where we meet 
daily.

Online repositories like https://github.com/taij33n/picolisp and 
https://bitbucket.org/mmamkin/picolisp
are not mere personal forks, but up to date clones of the official release at 
http://software-lab.de/picoLisp.tgz
Both taij33n and mmamkin are core members of the picolisp community.

Petr, would it help if we would link and describe those repositories 
prominently on picolisp.com ?
Or do you think people don't go first to our website, but find it directly on 
github/bitbucket and are turned of when they see "0 contributors" there?
Maybe putting a prominent note into the readme at github/bitbucket could 
improve this a bit...

For years, PicoLisp used to be hosted in such a online community, actually at 
Google Code.
There are two main reasons why PicoLisp development is not anymore managed over 
such a service:

1) Google Code closed down. Yes, its unlikely that this will happen soon with 
Github, but such offerings from big commercial companies are always up to the 
moods and motivations of the company, which can change suddenly

Re: Future of PicoLisp?

[Lindsay John Lawrence]

Picolisp has a release archive readily downloadable here...
http://software-lab.de/down.html.
In my limited experience with picolisp, it actually reminds me of sqlite  (
http://sqlite.org) in its approach...

"Small, Fast, Reliable. Chose any three"

Sqlite seems to have a particularly effective source management model and
an astonishingly active mailing list.
The only way to get the latest (or even moderately recent) version of
sqlite is to download a pre-compiled snapshot from the website or build it
yourself. Both very trivial tasks for the motivated.

The source repo for sqlite is Fossil (
http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki).
Fossil, written for sqlite, holds all the code, history and docs in a
sqlite database. How 'lisp' is that? ;)

Alex,

Picolisp has the wiki, vip, built in database all written in picolisp... is
an scm such a big leap? Just a thought :)

/Lindsay


On Mon, Feb 20, 2017 at 10:19 AM, Jakob Eriksson 
wrote:

>
>
> I would love for the public repo to be on github!
>
> I think for many, an open source project does not really exist,
> unless it is on Github. We should also try to resurrect somehow,
> the [picolisp] tag on Stack Overflow.
>
> Given that it is encouraged to put in official documentation in the
> form of Q/A on Stack Overflow, I think we could have a coordinated
> effort from here to do it.
>
>
>
>
> On 2017-02-20 18:15, Petr Gladkikh wrote:
> > I admit that I am a passerby here but my impression is that things
> > around PicoLisp feel closed and this is not about the code itself.
> > In particular, there seems to be no public source code repository so
> > source history can only be inferred somehow from releases. I see that
> > some people already try to mirror it (see,
> > e.g. https://github.com/taij33n/picolisp
> > <https://github.com/taij33n/picolisp>) but since it is not "official"
> > there's no development or associated discussions. Since revision control
> > is essential for any non-trivial project, the lack of it is surprising.
> > Also there's no public bug tracker. Instead I have to subscribe to this
> > list so it is hard to track what happened to issues.
> >
> > That said removing some friction for outsiders would help to keep things
> > running.
> >
> >
> > 2017-02-03 8:47 GMT+01:00 Alexander Burger  > <mailto:a...@software-lab.de>>:
> >
> > Hi all,
> >
> > the future of PicoLisp is dark. I'm not sure if it can survive in
> > packaged
> > distribution.
> >
> > Ubuntu doesn't support it any more, probably due to the PIE (position
> > independent executable) on x86-64.
> >
> > And at least on Android they seem to demand switching to Clang. The
> > 32-bit
> > versions of PicoLisp (pil32 and mini) which are written in C cannot
> > be compiled
> > on Clang, because Clang doesn't support dynamically allocated
> > arrays, which
> > pil32 depends on. As far as I notices, pil64 also has trouble on
> > Clang/Android.
> >
> > :( Alex
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de
> > <mailto:picolisp@software-lab.de>?subject=Unsubscribe
> >
> >
> >
> >
> > --
> > Petr Gladkikh
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Christopher Howard]

Well, of course, you guys are free to do want you want to try and please
whomever you want. I'm just an actual user of picolisp. Whenever I find
that a project is on Github, I find the url for cloning the repository,
and then never use any of the project site features ever again (issue
tracker, etc.) Just take it as my $0.02 feedback if nothing else.

On 02/20/2017 10:31 AM, Jakob Eriksson wrote:
> 
> Another tradeoff is that there are very few people and projects
> on any site besides Github. This is the reality.
> 
> -- Jakob
> 

-- 
Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584
mailto:christop...@alaskasi.com
http://www.alaskasatelliteinternet.com
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Rowan Thorpe]

> On 02/20/2017 09:19 AM, Jakob Eriksson wrote:
> > I would love for the public repo to be on github!

I would love for it to be on some kind of public git repo too. I'm
mostly indifferent whether it's github/bitbucket/sourceforge/whatever,
but would just love to be able to pull/branch/rebase for quick
experimenting with the leading-edge source. More importantly in regard
to this thread, a lot of Debian packaging tools and methodologies (and
probably in other distros) are increasingly leveraging git to
streamline the packaging process (e.g.
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.html
and https://www.eyrie.org/~eagle/notes/debian/git.html#combine),
making it easier for packagers (and less excuse for lag-time or
packaging bugs) when using an existing git-upstream, so a public git
repo would help keep picolisp more up-to-date in the distros. Also, I
think public git would make the "downloading -> exploring ->
contributing-patches" pipeline a lot faster and easier for
contributing to picolisp itself (even if the changes are still sent to
the mailing-list, at least they could be commit-ready patches
generated with git-format-patch, allowing merging or cherry-picking
them to be trivially easy and fast).

On 20 February 2017 at 20:46, Christopher Howard
 wrote:
> I'm sure my opinion has very little weight around here, but since other
> people are discussing it I want to put in a plug for Savannah (Non-GNU):
>
> https://savannah.nongnu.org/
>
> If you aren't willing to run the proprietary JavaScript on Github it
> becomes a real pain to work with. (Gets an F rating from FSF
> .)
> Includes Subversion and Git support.

..when thinking of free/libre/open github alternatives, and
particularly if the approval-wait of savannah is annoying, there is
also one of:

 A)
   1] self-host by running (free/open) gitlab -
https://gitlab.com/gitlab-org/gitlab-ce
   2] use their free repo-hosting service at - https://gitlab.com
 B)
   self-host by running (free/open) gogs - https://github.com/gogits/gogs
 C)
   self-host with one of the more minimal solutions like (free/open) gitweb, etc

I haven't looked at how strictly FSF-friendly gitlab.com is (librejs,
etc), but for sure it's a big improvement on github if you care about
privacy/control/librejs issues. gogs is interesting because it is very
lightweight, portable, and easy-maintenance (can even be hosted on a
raspberry pi or nas device), whereas gitlab is bigger and seems
equivalent to github in terms of bells-and-whistles (CI integration,
etc).

-- 
Rowan Thorpe

"A riot is the language of the unheard." - Dr. Martin Luther King
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
"Ignorance requires no apologies when it presents questions
rather than assertions." - Michael Sierchio (OpenSSL mailing list)
"What we need more than an end to wars is an end to the
beginning of all wars." - Franklin Roosevelt
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Jakob Eriksson]

On 2017-02-20 19:46, Christopher Howard wrote:

> The only tradeoffs with savannah nongnu is it sometimes takes them a few
> weeks to approve your project hosting, and they require you to put
> licensing information on each code file (a really good idea anyway).
> 

No. That is like saying that the only tradeoff with using GNU Social
instead of Twitter is that sometimes the messages may arrive a little
slow.  Another tradeoff is that there are very few people and projects
on any site besides Github. This is the reality.

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

Re: Future of PicoLisp?

[Christopher Howard]

I'm sure my opinion has very little weight around here, but since other
people are discussing it I want to put in a plug for Savannah (Non-GNU):

https://savannah.nongnu.org/

If you aren't willing to run the proprietary JavaScript on Github it
becomes a real pain to work with. (Gets an F rating from FSF
<https://www.gnu.org/software/repo-criteria-evaluation.en.html>.)
Includes Subversion and Git support.

The only tradeoffs with savannah nongnu is it sometimes takes them a few
weeks to approve your project hosting, and they require you to put
licensing information on each code file (a really good idea anyway).

On 02/20/2017 09:19 AM, Jakob Eriksson wrote:
> 
> 
> I would love for the public repo to be on github!
> 
> I think for many, an open source project does not really exist,
> unless it is on Github. We should also try to resurrect somehow,
> the [picolisp] tag on Stack Overflow.
> 
> Given that it is encouraged to put in official documentation in the
> form of Q/A on Stack Overflow, I think we could have a coordinated
> effort from here to do it.
> 
> 
> 
> 
> On 2017-02-20 18:15, Petr Gladkikh wrote:
>> I admit that I am a passerby here but my impression is that things
>> around PicoLisp feel closed and this is not about the code itself.
>> In particular, there seems to be no public source code repository so
>> source history can only be inferred somehow from releases. I see that
>> some people already try to mirror it (see,
>> e.g. https://github.com/taij33n/picolisp
>> <https://github.com/taij33n/picolisp>) but since it is not "official"
>> there's no development or associated discussions. Since revision control
>> is essential for any non-trivial project, the lack of it is surprising.
>> Also there's no public bug tracker. Instead I have to subscribe to this
>> list so it is hard to track what happened to issues. 
>>
>> That said removing some friction for outsiders would help to keep things
>> running.
>>
>>
>> 2017-02-03 8:47 GMT+01:00 Alexander Burger > <mailto:a...@software-lab.de>>:
>>
>> Hi all,
>>
>> the future of PicoLisp is dark. I'm not sure if it can survive in
>> packaged
>> distribution.
>>
>> Ubuntu doesn't support it any more, probably due to the PIE (position
>> independent executable) on x86-64.
>>
>> And at least on Android they seem to demand switching to Clang. The
>> 32-bit
>> versions of PicoLisp (pil32 and mini) which are written in C cannot
>> be compiled
>> on Clang, because Clang doesn't support dynamically allocated
>> arrays, which
>> pil32 depends on. As far as I notices, pil64 also has trouble on
>> Clang/Android.
>>
>> :( Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de
>> <mailto:picolisp@software-lab.de>?subject=Unsubscribe
>>
>>
>>
>>
>> -- 
>> Petr Gladkikh

-- 
Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584
mailto:christop...@alaskasi.com
http://www.alaskasatelliteinternet.com
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Jakob Eriksson]

I would love for the public repo to be on github!

I think for many, an open source project does not really exist,
unless it is on Github. We should also try to resurrect somehow,
the [picolisp] tag on Stack Overflow.

Given that it is encouraged to put in official documentation in the
form of Q/A on Stack Overflow, I think we could have a coordinated
effort from here to do it.




On 2017-02-20 18:15, Petr Gladkikh wrote:
> I admit that I am a passerby here but my impression is that things
> around PicoLisp feel closed and this is not about the code itself.
> In particular, there seems to be no public source code repository so
> source history can only be inferred somehow from releases. I see that
> some people already try to mirror it (see,
> e.g. https://github.com/taij33n/picolisp
> <https://github.com/taij33n/picolisp>) but since it is not "official"
> there's no development or associated discussions. Since revision control
> is essential for any non-trivial project, the lack of it is surprising.
> Also there's no public bug tracker. Instead I have to subscribe to this
> list so it is hard to track what happened to issues. 
> 
> That said removing some friction for outsiders would help to keep things
> running.
> 
> 
> 2017-02-03 8:47 GMT+01:00 Alexander Burger  <mailto:a...@software-lab.de>>:
> 
> Hi all,
> 
> the future of PicoLisp is dark. I'm not sure if it can survive in
> packaged
> distribution.
> 
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
> 
> And at least on Android they seem to demand switching to Clang. The
> 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot
> be compiled
> on Clang, because Clang doesn't support dynamically allocated
> arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on
> Clang/Android.
> 
> :( Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de
> <mailto:picolisp@software-lab.de>?subject=Unsubscribe
> 
> 
> 
> 
> -- 
> Petr Gladkikh
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Future of PicoLisp?

[Petr Gladkikh]

I admit that I am a passerby here but my impression is that things around
PicoLisp feel closed and this is not about the code itself.
In particular, there seems to be no public source code repository so source
history can only be inferred somehow from releases. I see that some people
already try to mirror it (see, e.g. https://github.com/taij33n/picolisp)
but since it is not "official" there's no development or associated
discussions. Since revision control is essential for any non-trivial
project, the lack of it is surprising.
Also there's no public bug tracker. Instead I have to subscribe to this
list so it is hard to track what happened to issues.

That said removing some friction for outsiders would help to keep things
running.


2017-02-03 8:47 GMT+01:00 Alexander Burger :

> Hi all,
>
> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
> distribution.
>
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
>
> And at least on Android they seem to demand switching to Clang. The 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot be
> compiled
> on Clang, because Clang doesn't support dynamically allocated arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on
> Clang/Android.
>
> :( Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>



-- 
Petr Gladkikh

Re: Future of PicoLisp?

[Henrik Sarvell]

How convenient then that compiling PL is trivial, it's probably the easiest
and most hassle free thing I've ever had to compile from source.

On Fri, Feb 3, 2017 at 8:47 AM, Alexander Burger 
wrote:

> Hi all,
>
> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
> distribution.
>
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
>
> And at least on Android they seem to demand switching to Clang. The 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot be
> compiled
> on Clang, because Clang doesn't support dynamically allocated arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on
> Clang/Android.
>
> :( Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[dean]

Hi Alex

This is not helpful. I want to define registers *globally", so that values,
arguments and return values can be passed between functions. All functions
get
arguments in 1, 2, or more registers, and *return* values (not just a single
value!) in 1, 2 or more registers, plus direct condition codes.
A Fastproc lets you pass up to 3 registers-worth of arguments to it...Any
more and you'd associate the registers with structures to squeeze more in
like this.

https://forum.powerbasic.com/forum/user-to-user-discussions/powerbasic-inline-assembler/744566-fastcall-using-a-structure-for-arguments
which saves you using the stack but not quite as fast as the value sitting
their in the register.

Hope that helps and no problem if this is not of interest...I just saw it
as a way of overcoming CLANG problems re pil32.

Best Regards
Dean




On 4 February 2017 at 20:46, dean  wrote:

> Hi Alex
>
> >No, I want a *generic way* to call existing external libraries, e.g.
>
> Powerbasic won't do what (native... does because it doesn't do variadic
> arguments like lisp or even c...
>
> Here's an example .
>
> BTW Important words are LoadLibrary  GetProcAddress Call DWORD FreeLibrary
> and recently
>
> IMPORT ADDR
>
> What native does looks very cool
>
> 'Declare function prototype
> Declare Function protoFreeCCSDLL (Key as ASCIIZ,Param as ASCIIZ) as LONG
>
> Function ProcessCreditCards() as LONG
> Local x as LONG
> Local hLib as LONG
> Local ProcAddr as DWORD
> local lResult as LONG
>
> 'Retrieve DLL handle
> hLib = LoadLibrary("FREECCS.DLL")
> If IsFalse hLib Then
> MsgBox "FreeCCS.DLL is missing or damaged, please verify 
> installation", %MB_ICONSTOP,"CCS"
> Exit Function
> End If
>
> 'Retrieve function address
> ProcAddr = GetProcAddress(hLib,"FreeCCSDLL")
> If ProcAddr = %NULL Then
> MsgBox "Could not find function FreeCCSDLL in FreeCCS.DLL"
> Exit Function
> End If
>
> Key = "MyKey"
> Param = "MyParam"
>
> 'Call pointer to the function using Function prototype
> Call DWORD ProcAddr USING protoFreeCCSDLL(Key,Param) TO lResult
>
> 'Do some more calls/processing
>
> 'Release Library
> Call FreeLibrary(hLib)
>
> Function = lResult
> End Function
>
>
>
> On 4 February 2017 at 20:26, dean  wrote:
>
>> Re the carry flag...you can get at that :)
>>
>> On 4 February 2017 at 20:24, dean  wrote:
>>
>>> Hi Alex
>>>
>>> With stack control I mean that you can do unlimited 'push'es and 'pop's
>>> to/from
>>> the stack inside a function, and build arbitrary structures this way on
>>> the
>>> stack. You can add, subtract, increment and decrement the stack pointer
>>> arbitrarily, and switch between different stacks by assigning values to
>>> the
>>> stack pointer.
>>>
>>> I've read these and it looks like it i.e. you can save and restore EBP
>>> and ESP
>>> freeing you to do what you want with them until restoration
>>> also you can push stuff of one size and pop it off in different sized
>>> chunks.
>>> It all looks very freestyle to me as long as you balance the stack when
>>> you've finished.
>>> I'd be very happy to try an example if you want.
>>> https://www.powerbasic.com/help/pbcc/the_stack.htm
>>> https://www.powerbasic.com/help/pbcc/using_esp_and_ebp.htm
>>> https://www.powerbasic.com/help/pbcc/tricks_of_the_stack.htm
>>>
>>> On 4 February 2017 at 19:32, Lindsay John Lawrence <
>>> lawrence.lindsayj...@gmail.com> wrote:
>>>
 I also run PicoLisp out of a TinyCore Linux 'VirtualBox' image...
 This turned out to be the best route for me to get the performance and
 features of picolisp I wanted on microsoft windows hosts.

 TinyCore64 + vboxsf (to access host drives) + picolisp is a great combo
 in < 50Mb
 Exporting that as an 'appliance'  < 15Mb.
 == full linux kernel with all the goodness that provides + picolisp
 awesomeness to easily utilize all that goodness.

 A slightly larger image with docs+w3m+vim (or the picollsp 'vi'
 Alexander published) may make a nicely focused little 'lisp machine'  to
 learn and tinker on.

 /Lindsay


 On Sat, Feb 4, 2017 at 8:40 AM, Erik Gustafson <
 erik.d.gustaf...@gmail.com> wrote:

> Hi list,
>
> Sounds like it's time to update the 'apt-get yourself some PicoLisp'
> section on the wiki, as this is no longer the best route for those new to
> the language.
>
> To confirm, the best options seem to be:
>
> - pil64 for Android
> - Ersatz for Windows
> - Docker Image (Packaged PL + Tiny Core)
> - Build from source
>
> Please add if I'm missing anything.
>
> Now as far as trying PicoLisp goes, could we make a little app like
> http://www.tryclj.com? A sandboxed subset of PL where one could try
> out the language and maybe work through a short accompanying tutorial to
> give a taste of the language, before diving into the

Re: Future of PicoLisp?

[dean]

Hi Alex

>No, I want a *generic way* to call existing external libraries, e.g.

Powerbasic won't do what (native... does because it doesn't do variadic
arguments like lisp or even c...

Here's an example .

BTW Important words are LoadLibrary  GetProcAddress Call DWORD FreeLibrary
and recently

IMPORT ADDR

What native does looks very cool

'Declare function prototype
Declare Function protoFreeCCSDLL (Key as ASCIIZ,Param as ASCIIZ) as LONG

Function ProcessCreditCards() as LONG
Local x as LONG
Local hLib as LONG
Local ProcAddr as DWORD
local lResult as LONG

'Retrieve DLL handle
hLib = LoadLibrary("FREECCS.DLL")
If IsFalse hLib Then
MsgBox "FreeCCS.DLL is missing or damaged, please verify
installation", %MB_ICONSTOP,"CCS"
Exit Function
End If

'Retrieve function address
ProcAddr = GetProcAddress(hLib,"FreeCCSDLL")
If ProcAddr = %NULL Then
MsgBox "Could not find function FreeCCSDLL in FreeCCS.DLL"
Exit Function
End If

Key = "MyKey"
Param = "MyParam"

'Call pointer to the function using Function prototype
Call DWORD ProcAddr USING protoFreeCCSDLL(Key,Param) TO lResult

'Do some more calls/processing

'Release Library
Call FreeLibrary(hLib)

Function = lResult
End Function



On 4 February 2017 at 20:26, dean  wrote:

> Re the carry flag...you can get at that :)
>
> On 4 February 2017 at 20:24, dean  wrote:
>
>> Hi Alex
>>
>> With stack control I mean that you can do unlimited 'push'es and 'pop's
>> to/from
>> the stack inside a function, and build arbitrary structures this way on
>> the
>> stack. You can add, subtract, increment and decrement the stack pointer
>> arbitrarily, and switch between different stacks by assigning values to
>> the
>> stack pointer.
>>
>> I've read these and it looks like it i.e. you can save and restore EBP
>> and ESP
>> freeing you to do what you want with them until restoration
>> also you can push stuff of one size and pop it off in different sized
>> chunks.
>> It all looks very freestyle to me as long as you balance the stack when
>> you've finished.
>> I'd be very happy to try an example if you want.
>> https://www.powerbasic.com/help/pbcc/the_stack.htm
>> https://www.powerbasic.com/help/pbcc/using_esp_and_ebp.htm
>> https://www.powerbasic.com/help/pbcc/tricks_of_the_stack.htm
>>
>> On 4 February 2017 at 19:32, Lindsay John Lawrence <
>> lawrence.lindsayj...@gmail.com> wrote:
>>
>>> I also run PicoLisp out of a TinyCore Linux 'VirtualBox' image...
>>> This turned out to be the best route for me to get the performance and
>>> features of picolisp I wanted on microsoft windows hosts.
>>>
>>> TinyCore64 + vboxsf (to access host drives) + picolisp is a great combo
>>> in < 50Mb
>>> Exporting that as an 'appliance'  < 15Mb.
>>> == full linux kernel with all the goodness that provides + picolisp
>>> awesomeness to easily utilize all that goodness.
>>>
>>> A slightly larger image with docs+w3m+vim (or the picollsp 'vi'
>>> Alexander published) may make a nicely focused little 'lisp machine'  to
>>> learn and tinker on.
>>>
>>> /Lindsay
>>>
>>>
>>> On Sat, Feb 4, 2017 at 8:40 AM, Erik Gustafson <
>>> erik.d.gustaf...@gmail.com> wrote:
>>>
 Hi list,

 Sounds like it's time to update the 'apt-get yourself some PicoLisp'
 section on the wiki, as this is no longer the best route for those new to
 the language.

 To confirm, the best options seem to be:

 - pil64 for Android
 - Ersatz for Windows
 - Docker Image (Packaged PL + Tiny Core)
 - Build from source

 Please add if I'm missing anything.

 Now as far as trying PicoLisp goes, could we make a little app like
 http://www.tryclj.com? A sandboxed subset of PL where one could try
 out the language and maybe work through a short accompanying tutorial to
 give a taste of the language, before diving into the install process. I
 think this has been discussed before...?

 Also isn't there the Emulisp (PL in JS) REPL app? Could that be
 leveraged? Maybe this is a solution without a problem; I agree with others
 that most people discovering PL will likely be comfortable building from
 source, spinning up a VM, etc

 Finally, a side note: I recently came across https://antergos.com.
 It's basically a graphical installer for Arch Linux. I gave it a try and
 found it to be as easy as installing Ubuntu... Click through the install
 wizard and ten minutes later you've got a full-blown Arch desktop
 environment (or base-install if desired) with built-in access to the AUR
 The AUR has always been up to date (many thanks!) with the latest PicoLisp.
 Might be worth a mention?

 Erik

>>>
>>>
>>
>

Re: Future of PicoLisp?

[dean]

Re the carry flag...you can get at that :)

On 4 February 2017 at 20:24, dean  wrote:

> Hi Alex
>
> With stack control I mean that you can do unlimited 'push'es and 'pop's
> to/from
> the stack inside a function, and build arbitrary structures this way on the
> stack. You can add, subtract, increment and decrement the stack pointer
> arbitrarily, and switch between different stacks by assigning values to the
> stack pointer.
>
> I've read these and it looks like it i.e. you can save and restore EBP and
> ESP
> freeing you to do what you want with them until restoration
> also you can push stuff of one size and pop it off in different sized
> chunks.
> It all looks very freestyle to me as long as you balance the stack when
> you've finished.
> I'd be very happy to try an example if you want.
> https://www.powerbasic.com/help/pbcc/the_stack.htm
> https://www.powerbasic.com/help/pbcc/using_esp_and_ebp.htm
> https://www.powerbasic.com/help/pbcc/tricks_of_the_stack.htm
>
> On 4 February 2017 at 19:32, Lindsay John Lawrence <
> lawrence.lindsayj...@gmail.com> wrote:
>
>> I also run PicoLisp out of a TinyCore Linux 'VirtualBox' image...
>> This turned out to be the best route for me to get the performance and
>> features of picolisp I wanted on microsoft windows hosts.
>>
>> TinyCore64 + vboxsf (to access host drives) + picolisp is a great combo
>> in < 50Mb
>> Exporting that as an 'appliance'  < 15Mb.
>> == full linux kernel with all the goodness that provides + picolisp
>> awesomeness to easily utilize all that goodness.
>>
>> A slightly larger image with docs+w3m+vim (or the picollsp 'vi' Alexander
>> published) may make a nicely focused little 'lisp machine'  to learn and
>> tinker on.
>>
>> /Lindsay
>>
>>
>> On Sat, Feb 4, 2017 at 8:40 AM, Erik Gustafson <
>> erik.d.gustaf...@gmail.com> wrote:
>>
>>> Hi list,
>>>
>>> Sounds like it's time to update the 'apt-get yourself some PicoLisp'
>>> section on the wiki, as this is no longer the best route for those new to
>>> the language.
>>>
>>> To confirm, the best options seem to be:
>>>
>>> - pil64 for Android
>>> - Ersatz for Windows
>>> - Docker Image (Packaged PL + Tiny Core)
>>> - Build from source
>>>
>>> Please add if I'm missing anything.
>>>
>>> Now as far as trying PicoLisp goes, could we make a little app like
>>> http://www.tryclj.com? A sandboxed subset of PL where one could try out
>>> the language and maybe work through a short accompanying tutorial to give a
>>> taste of the language, before diving into the install process. I think this
>>> has been discussed before...?
>>>
>>> Also isn't there the Emulisp (PL in JS) REPL app? Could that be
>>> leveraged? Maybe this is a solution without a problem; I agree with others
>>> that most people discovering PL will likely be comfortable building from
>>> source, spinning up a VM, etc
>>>
>>> Finally, a side note: I recently came across https://antergos.com. It's
>>> basically a graphical installer for Arch Linux. I gave it a try and found
>>> it to be as easy as installing Ubuntu... Click through the install wizard
>>> and ten minutes later you've got a full-blown Arch desktop environment (or
>>> base-install if desired) with built-in access to the AUR The AUR has always
>>> been up to date (many thanks!) with the latest PicoLisp. Might be worth a
>>> mention?
>>>
>>> Erik
>>>
>>
>>
>

Re: Future of PicoLisp?

[dean]

Hi Alex

With stack control I mean that you can do unlimited 'push'es and 'pop's
to/from
the stack inside a function, and build arbitrary structures this way on the
stack. You can add, subtract, increment and decrement the stack pointer
arbitrarily, and switch between different stacks by assigning values to the
stack pointer.

I've read these and it looks like it i.e. you can save and restore EBP and
ESP
freeing you to do what you want with them until restoration
also you can push stuff of one size and pop it off in different sized
chunks.
It all looks very freestyle to me as long as you balance the stack when
you've finished.
I'd be very happy to try an example if you want.
https://www.powerbasic.com/help/pbcc/the_stack.htm
https://www.powerbasic.com/help/pbcc/using_esp_and_ebp.htm
https://www.powerbasic.com/help/pbcc/tricks_of_the_stack.htm

On 4 February 2017 at 19:32, Lindsay John Lawrence <
lawrence.lindsayj...@gmail.com> wrote:

> I also run PicoLisp out of a TinyCore Linux 'VirtualBox' image...
> This turned out to be the best route for me to get the performance and
> features of picolisp I wanted on microsoft windows hosts.
>
> TinyCore64 + vboxsf (to access host drives) + picolisp is a great combo in
> < 50Mb
> Exporting that as an 'appliance'  < 15Mb.
> == full linux kernel with all the goodness that provides + picolisp
> awesomeness to easily utilize all that goodness.
>
> A slightly larger image with docs+w3m+vim (or the picollsp 'vi' Alexander
> published) may make a nicely focused little 'lisp machine'  to learn and
> tinker on.
>
> /Lindsay
>
>
> On Sat, Feb 4, 2017 at 8:40 AM, Erik Gustafson  > wrote:
>
>> Hi list,
>>
>> Sounds like it's time to update the 'apt-get yourself some PicoLisp'
>> section on the wiki, as this is no longer the best route for those new to
>> the language.
>>
>> To confirm, the best options seem to be:
>>
>> - pil64 for Android
>> - Ersatz for Windows
>> - Docker Image (Packaged PL + Tiny Core)
>> - Build from source
>>
>> Please add if I'm missing anything.
>>
>> Now as far as trying PicoLisp goes, could we make a little app like
>> http://www.tryclj.com? A sandboxed subset of PL where one could try out
>> the language and maybe work through a short accompanying tutorial to give a
>> taste of the language, before diving into the install process. I think this
>> has been discussed before...?
>>
>> Also isn't there the Emulisp (PL in JS) REPL app? Could that be
>> leveraged? Maybe this is a solution without a problem; I agree with others
>> that most people discovering PL will likely be comfortable building from
>> source, spinning up a VM, etc
>>
>> Finally, a side note: I recently came across https://antergos.com. It's
>> basically a graphical installer for Arch Linux. I gave it a try and found
>> it to be as easy as installing Ubuntu... Click through the install wizard
>> and ten minutes later you've got a full-blown Arch desktop environment (or
>> base-install if desired) with built-in access to the AUR The AUR has always
>> been up to date (many thanks!) with the latest PicoLisp. Might be worth a
>> mention?
>>
>> Erik
>>
>
>

Re: Future of PicoLisp?

[dean]

Hi Alex...I see,
Sorry for the delay...I've spent most of the day trying to get a crashy pc
to run windows and Powerbasic to do this but have done itI did need to
use a Fastproc which creates no stack frame and is a much leaner and meaner
version of a sub/function,

#COMPILE EXE
'#DIM ALL 'commenting out...means no declare line needed

GLOBAL gP???  '??? means DWORD

FASTPROC x
? "1st_half_x"'? short for print
hlf_way:
gP??? = CODEPTR(hlf_way) 'address of halfway
? "2nd_half_x"
END FASTPROC

FUNCTION PBMAIN () AS LONG
p??? = CODEPTR(x) + 0
!call p???   ;asm way to call (x in this case_
CALL DWORD gP??? 'or higher level way to call (hlf_way in this case) :)
WAITKEY$
END FUNCTION

'output is...
'1st_half_x
'2nd_half_x
'2nd_half_x
'waits for waitkey$
~


Fastproc is a mean and lean alternative to a sub/function creating no
stackframe and receiving arguments as register variables.

I'll report back on some of the other stuff.





On 4 February 2017 at 18:06, Mike Pechkin  wrote:

>
>
>
>
>> Now as far as trying PicoLisp goes, could we make a little app like
>> http://www.tryclj.com?
>>
>
> ​Already done in ideone.com​
>
>
>

Re: Future of PicoLisp?

[Lindsay John Lawrence]

I also run PicoLisp out of a TinyCore Linux 'VirtualBox' image...
This turned out to be the best route for me to get the performance and
features of picolisp I wanted on microsoft windows hosts.

TinyCore64 + vboxsf (to access host drives) + picolisp is a great combo in
< 50Mb
Exporting that as an 'appliance'  < 15Mb.
== full linux kernel with all the goodness that provides + picolisp
awesomeness to easily utilize all that goodness.

A slightly larger image with docs+w3m+vim (or the picollsp 'vi' Alexander
published) may make a nicely focused little 'lisp machine'  to learn and
tinker on.

/Lindsay


On Sat, Feb 4, 2017 at 8:40 AM, Erik Gustafson 
wrote:

> Hi list,
>
> Sounds like it's time to update the 'apt-get yourself some PicoLisp'
> section on the wiki, as this is no longer the best route for those new to
> the language.
>
> To confirm, the best options seem to be:
>
> - pil64 for Android
> - Ersatz for Windows
> - Docker Image (Packaged PL + Tiny Core)
> - Build from source
>
> Please add if I'm missing anything.
>
> Now as far as trying PicoLisp goes, could we make a little app like
> http://www.tryclj.com? A sandboxed subset of PL where one could try out
> the language and maybe work through a short accompanying tutorial to give a
> taste of the language, before diving into the install process. I think this
> has been discussed before...?
>
> Also isn't there the Emulisp (PL in JS) REPL app? Could that be leveraged?
> Maybe this is a solution without a problem; I agree with others that most
> people discovering PL will likely be comfortable building from source,
> spinning up a VM, etc.
>
> Finally, a side note: I recently came across https://antergos.com. It's
> basically a graphical installer for Arch Linux. I gave it a try and found
> it to be as easy as installing Ubuntu... Click through the install wizard
> and ten minutes later you've got a full-blown Arch desktop environment (or
> base-install if desired) with built-in access to the AUR. The AUR has
> always been up to date (many thanks!) with the latest PicoLisp. Might be
> worth a mention?
>
> Erik
>

Re: Future of PicoLisp?

[Mike Pechkin]

> Now as far as trying PicoLisp goes, could we make a little app like
> http://www.tryclj.com?
>

​Already done in ideone.com​

Re: Future of PicoLisp?

[Erik Gustafson]

Hi list,

Sounds like it's time to update the 'apt-get yourself some PicoLisp'
section on the wiki, as this is no longer the best route for those new to
the language.

To confirm, the best options seem to be:

- pil64 for Android
- Ersatz for Windows
- Docker Image (Packaged PL + Tiny Core)
- Build from source

Please add if I'm missing anything.

Now as far as trying PicoLisp goes, could we make a little app like
http://www.tryclj.com? A sandboxed subset of PL where one could try out the
language and maybe work through a short accompanying tutorial to give a
taste of the language, before diving into the install process. I think this
has been discussed before...?

Also isn't there the Emulisp (PL in JS) REPL app? Could that be leveraged?
Maybe this is a solution without a problem; I agree with others that most
people discovering PL will likely be comfortable building from source,
spinning up a VM, etc.

Finally, a side note: I recently came across https://antergos.com. It's
basically a graphical installer for Arch Linux. I gave it a try and found
it to be as easy as installing Ubuntu... Click through the install wizard
and ten minutes later you've got a full-blown Arch desktop environment (or
base-install if desired) with built-in access to the AUR. The AUR has
always been up to date (many thanks!) with the latest PicoLisp. Might be
worth a mention?

Erik

Re: Future of PicoLisp?

[Rick Lyman]

https://www.amazon.com/Universal-Assembly-Language-Robert-Fitz/dp/0830627308
http://hackaday.com/2015/08/06/hacking-a-universal-assembler/
http://linuxfinances.info/info/assembler.html


On Sat, Feb 4, 2017 at 4:55 AM, Alexander Burger 
wrote:

> Hi Dean,
>
> > re multiple entry points...assuming that means setjmp and longjmp which
> > save and preserve those registers above (albeit the 16 bit ones SP & BP
> as
>
> Nono, setjmp/longjmp correspond to catch/throw in Lisp. This is something
> completely different, it jumps *up* the call history to an enclosing
> environment. There is only a single entry point to a function in C (and
> also in
> Lisp). I don't know PowerBasic, but traditional Basic allowed that, you
> could
> GOTO any point in a program, also in other subroutines, just like a JMP in
> assembly.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Alexander Burger]

Hi Dean,

> re multiple entry points...assuming that means setjmp and longjmp which
> save and preserve those registers above (albeit the 16 bit ones SP & BP as

Nono, setjmp/longjmp correspond to catch/throw in Lisp. This is something
completely different, it jumps *up* the call history to an enclosing
environment. There is only a single entry point to a function in C (and also in
Lisp). I don't know PowerBasic, but traditional Basic allowed that, you could
GOTO any point in a program, also in other subroutines, just like a JMP in
assembly.

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

Re: Future of PicoLisp?

[dean]

Hi Alex...

re multiple entry points...assuming that means setjmp and longjmp which
save and preserve those registers above (albeit the 16 bit ones SP & BP as
their 32bit equivalents) I've just looked at the code for setjmp and
longjmp and in they're in asm anyway and look fairly innocuous

http://www.jbox.dk/sanos/source/lib/setjmp.c.html
so...I see no reason why they can't be replicated in Powerbasic along with
the save record. (There is a link to the assembler INSIDE the last link of
this post)

I did notice mention of signals in the source code and here's a discussion
re signalling threads in PB

https://forum.powerbasic.com/forum/user-to-user-discussions/programming/62044-what-is-the-best-way-to-signal-a-thread



Stack control was an eye opener i.e. in addition to the meta statement

#STACK num_exprSet the maximum potential stack size.

here's a link re stack overhead reduction with some additional links
further down that expand on the subject.

http://www.powerbasic.com/help/pbcc/stack_overhead_reduction.htm
Best Regards
Dean


On 3 February 2017 at 18:41, Terry Palfrey 
wrote:

> Anyone ever tried the newLISPonRockets.com install? I don't know if
> that will give you ideas for a one touch install.
>
> On Fri, Feb 3, 2017 at 10:10 AM, František Fuka  wrote:
>
>> I think that "adding PPA repository to my system" is not much easier than
>> "downloading Picolisp source and compiling it". You and I can do both.
>> Unskilled users will struggle with both. We need a method for unskilled
>> users that allows them just to download a file, click something, maybe type
>> a line or two --- and have a fully working Picolisp installation as a
>> result. The question of self-updating installed Picolisp (the advantage PPA
>> has over self-compiling) is not relevant for theses users, IMHO.
>>
>> On Fri, Feb 3, 2017 at 6:54 PM, Bruno Franco <
>> brunofrancosala...@gmail.com> wrote:
>>
>>> As for ubuntu, maybe you could make a Personal Package Archive (PPA).
>>> Its lets you make your own packages that can be downloaded by users using
>>> apt-get. Its as easy as downloading the normal packages, but the user must
>>> manually add the repository.
>>>
>>> Here's a useful link:
>>> http://askubuntu.com/questions/71510/how-do-i-create-a-ppa
>>>
>>> It would be more work than having the ubuntu team providing the package
>>> in the official repositories, and I think you would have to make a new
>>> package for every version of ubuntu you want to support. But its also the
>>> only way to make sure that users get the most recent version of the
>>> software. As Edgaras said, ubuntu is bad at keeping up with the newest
>>> releases.
>>>
>>> I'm personally ok with compiling picolisp myself. But I know I wouldn't
>>> have tried it if it had not been available as a package from ubuntu.
>>>
>>> As Dean said, if there's anything we can do, let us know.
>>>
>>> On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
>>> wrote:
>>>
 Hi Dean,

 > Assuming that Wine packages are more numerous than Picolisps...you
 could do
 > a native Windows version in Powerbasic for Wine. Not only would this
 up

 Well, but then we can go as well with ErsatzLisp, the Java version of
 PicoLisp.

 A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
 runtime
 environment. Might be possible in the future with Joe's midipix port.


 > I smiled when I saw your reasons for moving from C to asm because
 > Powerbasic does ALIGN etc in it's stride without needing to drop down
 to
 > it's industrial strength built in assembler.

 Aligning is not so much a problem. But can you control the stack layout,
 condition codes (carry flag etc.) and multiple function entry points in
 Powerbasic? Or do natice calls to external C functions in a completely
 dynamic
 way. All this is not even possible in C.


 > I'd prefer to work in 64 bit asm but would be very happy to assist
 you in
 > any way I can to see Picolisp do well as I'm sure others would be.
 Whatever
 > you decide just let us know how we can help. I'm very new to Picolisp
 but
 > can already see that it's much too good not to do well.

 Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is
 probably
 too late by now.

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

>>>
>>>
>>
>>
>> --
>> *-- Frantisek Fuka*
>> (yes, that IS my real name)
>>
>> -- My Personal homepage: www.fuxoft.cz
>> -- My Google+ profile: google.com/+fuxoft
>> -- My Telegram chat: telegram.fuxoft.cz
>>
>>
>>
>

Re: Future of PicoLisp?

[dean]

Oops our threads have crossed.
Sorry about that.
I'll read what you've said now.

On 4 February 2017 at 08:47, dean  wrote:

> Hi Alex...
>
> re multiple entry points...assuming that means setjmp and longjmp which
> save and preserve those registers above (albeit the 16 bit ones SP & BP as
> their 32bit equivalents) I've just looked at the code for setjmp and
> longjmp and in they're in asm anyway and look fairly innocuous
>
> http://www.jbox.dk/sanos/source/lib/setjmp.c.html
> so...I see no reason why they can't be replicated in Powerbasic along with
> the save record. (There is a link to the assembler INSIDE the last link of
> this post)
>
> I did notice mention of signals in the source code and here's a discussion
> re signalling threads in PB
>
> https://forum.powerbasic.com/forum/user-to-user-
> discussions/programming/62044-what-is-the-best-way-to-signal-a-thread
>
>
> 
>
> Stack control was an eye opener i.e. in addition to the meta statement
>
> #STACK num_exprSet the maximum potential stack size.
>
> here's a link re stack overhead reduction with some additional links
> further down that expand on the subject.
>
> http://www.powerbasic.com/help/pbcc/stack_overhead_reduction.htm
> Best Regards
> Dean
>
>
> On 3 February 2017 at 18:41, Terry Palfrey 
> wrote:
>
>> Anyone ever tried the newLISPonRockets.com install? I don't know if
>> that will give you ideas for a one touch install.
>>
>> On Fri, Feb 3, 2017 at 10:10 AM, František Fuka  wrote:
>>
>>> I think that "adding PPA repository to my system" is not much easier
>>> than "downloading Picolisp source and compiling it". You and I can do both.
>>> Unskilled users will struggle with both. We need a method for unskilled
>>> users that allows them just to download a file, click something, maybe type
>>> a line or two --- and have a fully working Picolisp installation as a
>>> result. The question of self-updating installed Picolisp (the advantage PPA
>>> has over self-compiling) is not relevant for theses users, IMHO.
>>>
>>> On Fri, Feb 3, 2017 at 6:54 PM, Bruno Franco <
>>> brunofrancosala...@gmail.com> wrote:
>>>
 As for ubuntu, maybe you could make a Personal Package Archive (PPA).
 Its lets you make your own packages that can be downloaded by users using
 apt-get. Its as easy as downloading the normal packages, but the user must
 manually add the repository.

 Here's a useful link:
 http://askubuntu.com/questions/71510/how-do-i-create-a-ppa

 It would be more work than having the ubuntu team providing the package
 in the official repositories, and I think you would have to make a new
 package for every version of ubuntu you want to support. But its also the
 only way to make sure that users get the most recent version of the
 software. As Edgaras said, ubuntu is bad at keeping up with the newest
 releases.

 I'm personally ok with compiling picolisp myself. But I know I wouldn't
 have tried it if it had not been available as a package from ubuntu.

 As Dean said, if there's anything we can do, let us know.

 On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
 wrote:

> Hi Dean,
>
> > Assuming that Wine packages are more numerous than Picolisps...you
> could do
> > a native Windows version in Powerbasic for Wine. Not only would this
> up
>
> Well, but then we can go as well with ErsatzLisp, the Java version of
> PicoLisp.
>
> A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
> runtime
> environment. Might be possible in the future with Joe's midipix port.
>
>
> > I smiled when I saw your reasons for moving from C to asm because
> > Powerbasic does ALIGN etc in it's stride without needing to drop
> down to
> > it's industrial strength built in assembler.
>
> Aligning is not so much a problem. But can you control the stack
> layout,
> condition codes (carry flag etc.) and multiple function entry points in
> Powerbasic? Or do natice calls to external C functions in a completely
> dynamic
> way. All this is not even possible in C.
>
>
> > I'd prefer to work in 64 bit asm but would be very happy to assist
> you in
> > any way I can to see Picolisp do well as I'm sure others would be.
> Whatever
> > you decide just let us know how we can help. I'm very new to
> Picolisp but
> > can already see that it's much too good not to do well.
>
> Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it
> is probably
> too late by now.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


>>>
>>>
>>> --
>>> *-- Frantisek Fuka*
>>> (yes, that IS my real name)
>>>
>>> -- My Personal homepage: www.fuxoft.cz
>

Re: Future of PicoLisp?

[Alexander Burger]

Hi Dean,

> Re multiple entry points are we talking setjmp, longjmp and saving/restoring
> ebx esi edi bp sp & pc? I'm looking at this along with stack control.

No, a multiple entry point would be (in C for demonstration):

   void foo(void) {
  doThis();
   bar:
  doThat();
   }

and then, in *another* function:

   goto bar;  // Illegal


With stack control I mean that you can do unlimited 'push'es and 'pop's to/from
the stack inside a function, and build arbitrary structures this way on the
stack. You can add, subtract, increment and decrement the stack pointer
arbitrarily, and switch between different stacks by assigning values to the
stack pointer.


> Re the carry flag...you can easily get at this but do you want change it
> too?

What do you mean? Change what? I do not want to change anything.


> compliant...if you wanted to access C functionality from PB you could
> reduce the c to asm and PB could include it as PB modules. I have this on

No, I want a *generic way* to call existing external libraries, e.g.

  (native "@" "setsockopt" 'I 3 6 1 (I (4 . I) . 0) 4)
  (native "libcrypto.so" "MD5" '(B . 16) Str (length Str) '(NIL (16)))
  (native "@" "printf" 'I "abc%d%s^J" (+ 3 4) (pack "X" "Y" "Z"))

or like it is done in in @lib/openGl.l and other libs.

See? 'native' can call *any* C function defined somewhere else, without knowing
at compile time the number and types of the arguments. This is impossible in C.


> Re register allocation...REGISTER *variable* [AS *type*] [, *variable* [AS
> *type*]]
> The REGISTER statement is used to define certain local variables which are
> stored directly in specific CPU registers,

This is not helpful. I want to define registers *globally", so that values,
arguments and return values can be passed between functions. All functions get
arguments in 1, 2, or more registers, and *return* values (not just a single
value!) in 1, 2 or more registers, plus direct condition codes.

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

Re: Future of PicoLisp?

[dean]

I'll bet most picolisp users are sufficiently motived to compile it but
that means you're probably missing a lot of user's who'd appreciate it if
it was easy to try. As an example I had a right game and failed miserably
on Windows. BTW I'm still working on a response to your questions...In the
meantime

Re multiple entry points are we talking setjmp, longjmp and saving/restoring
ebx esi edi bp sp & pc? I'm looking at this along with stack control.

Re the carry flag...you can easily get at this but do you want change it
too?

Re pb talking to c you have two choices. You can use cdecl and dlls...I
found it easy to with Delphi (stdcall). or because the assembler is masm
compliant...if you wanted to access C functionality from PB you could
reduce the c to asm and PB could include it as PB modules. I have this on
good authority from a leading masm proponent :)

Here are the calling conventions PB supports
http://powerbasic.com/help/pbwin/

Re register allocation...REGISTER *variable* [AS *type*] [, *variable* [AS
*type*]]
The REGISTER statement is used to define certain local variables which are
stored directly in specific CPU registers,



On 3 February 2017 at 17:54, Bruno Franco 
wrote:

> As for ubuntu, maybe you could make a Personal Package Archive (PPA). Its
> lets you make your own packages that can be downloaded by users using
> apt-get. Its as easy as downloading the normal packages, but the user must
> manually add the repository.
>
> Here's a useful link:
> http://askubuntu.com/questions/71510/how-do-i-create-a-ppa
>
> It would be more work than having the ubuntu team providing the package in
> the official repositories, and I think you would have to make a new package
> for every version of ubuntu you want to support. But its also the only way
> to make sure that users get the most recent version of the software. As
> Edgaras said, ubuntu is bad at keeping up with the newest releases.
>
> I'm personally ok with compiling picolisp myself. But I know I wouldn't
> have tried it if it had not been available as a package from ubuntu.
>
> As Dean said, if there's anything we can do, let us know.
>
> On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
> wrote:
>
>> Hi Dean,
>>
>> > Assuming that Wine packages are more numerous than Picolisps...you
>> could do
>> > a native Windows version in Powerbasic for Wine. Not only would this up
>>
>> Well, but then we can go as well with ErsatzLisp, the Java version of
>> PicoLisp.
>>
>> A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
>> runtime
>> environment. Might be possible in the future with Joe's midipix port.
>>
>>
>> > I smiled when I saw your reasons for moving from C to asm because
>> > Powerbasic does ALIGN etc in it's stride without needing to drop down to
>> > it's industrial strength built in assembler.
>>
>> Aligning is not so much a problem. But can you control the stack layout,
>> condition codes (carry flag etc.) and multiple function entry points in
>> Powerbasic? Or do natice calls to external C functions in a completely
>> dynamic
>> way. All this is not even possible in C.
>>
>>
>> > I'd prefer to work in 64 bit asm but would be very happy to assist you
>> in
>> > any way I can to see Picolisp do well as I'm sure others would be.
>> Whatever
>> > you decide just let us know how we can help. I'm very new to Picolisp
>> but
>> > can already see that it's much too good not to do well.
>>
>> Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is
>> probably
>> too late by now.
>>
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>

Re: Future of PicoLisp?

[Terry Palfrey]

Anyone ever tried the newLISPonRockets.com install? I don't know if
that will give you ideas for a one touch install.

On Fri, Feb 3, 2017 at 10:10 AM, František Fuka  wrote:

> I think that "adding PPA repository to my system" is not much easier than
> "downloading Picolisp source and compiling it". You and I can do both.
> Unskilled users will struggle with both. We need a method for unskilled
> users that allows them just to download a file, click something, maybe type
> a line or two --- and have a fully working Picolisp installation as a
> result. The question of self-updating installed Picolisp (the advantage PPA
> has over self-compiling) is not relevant for theses users, IMHO.
>
> On Fri, Feb 3, 2017 at 6:54 PM, Bruno Franco  > wrote:
>
>> As for ubuntu, maybe you could make a Personal Package Archive (PPA). Its
>> lets you make your own packages that can be downloaded by users using
>> apt-get. Its as easy as downloading the normal packages, but the user must
>> manually add the repository.
>>
>> Here's a useful link:
>> http://askubuntu.com/questions/71510/how-do-i-create-a-ppa
>>
>> It would be more work than having the ubuntu team providing the package
>> in the official repositories, and I think you would have to make a new
>> package for every version of ubuntu you want to support. But its also the
>> only way to make sure that users get the most recent version of the
>> software. As Edgaras said, ubuntu is bad at keeping up with the newest
>> releases.
>>
>> I'm personally ok with compiling picolisp myself. But I know I wouldn't
>> have tried it if it had not been available as a package from ubuntu.
>>
>> As Dean said, if there's anything we can do, let us know.
>>
>> On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
>> wrote:
>>
>>> Hi Dean,
>>>
>>> > Assuming that Wine packages are more numerous than Picolisps...you
>>> could do
>>> > a native Windows version in Powerbasic for Wine. Not only would this up
>>>
>>> Well, but then we can go as well with ErsatzLisp, the Java version of
>>> PicoLisp.
>>>
>>> A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
>>> runtime
>>> environment. Might be possible in the future with Joe's midipix port.
>>>
>>>
>>> > I smiled when I saw your reasons for moving from C to asm because
>>> > Powerbasic does ALIGN etc in it's stride without needing to drop down
>>> to
>>> > it's industrial strength built in assembler.
>>>
>>> Aligning is not so much a problem. But can you control the stack layout,
>>> condition codes (carry flag etc.) and multiple function entry points in
>>> Powerbasic? Or do natice calls to external C functions in a completely
>>> dynamic
>>> way. All this is not even possible in C.
>>>
>>>
>>> > I'd prefer to work in 64 bit asm but would be very happy to assist you
>>> in
>>> > any way I can to see Picolisp do well as I'm sure others would be.
>>> Whatever
>>> > you decide just let us know how we can help. I'm very new to Picolisp
>>> but
>>> > can already see that it's much too good not to do well.
>>>
>>> Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is
>>> probably
>>> too late by now.
>>>
>>> ♪♫ Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>
>
> --
> *-- Frantisek Fuka*
> (yes, that IS my real name)
>
> -- My Personal homepage: www.fuxoft.cz
> -- My Google+ profile: google.com/+fuxoft
> -- My Telegram chat: telegram.fuxoft.cz
>
>
>

Re: Future of PicoLisp?

[rick]

I never use packages; only build from sources. Just one more data point
for you, Alex. ;)

Re: Future of PicoLisp?

[František Fuka]

I think that "adding PPA repository to my system" is not much easier than
"downloading Picolisp source and compiling it". You and I can do both.
Unskilled users will struggle with both. We need a method for unskilled
users that allows them just to download a file, click something, maybe type
a line or two --- and have a fully working Picolisp installation as a
result. The question of self-updating installed Picolisp (the advantage PPA
has over self-compiling) is not relevant for theses users, IMHO.

On Fri, Feb 3, 2017 at 6:54 PM, Bruno Franco 
wrote:

> As for ubuntu, maybe you could make a Personal Package Archive (PPA). Its
> lets you make your own packages that can be downloaded by users using
> apt-get. Its as easy as downloading the normal packages, but the user must
> manually add the repository.
>
> Here's a useful link:
> http://askubuntu.com/questions/71510/how-do-i-create-a-ppa
>
> It would be more work than having the ubuntu team providing the package in
> the official repositories, and I think you would have to make a new package
> for every version of ubuntu you want to support. But its also the only way
> to make sure that users get the most recent version of the software. As
> Edgaras said, ubuntu is bad at keeping up with the newest releases.
>
> I'm personally ok with compiling picolisp myself. But I know I wouldn't
> have tried it if it had not been available as a package from ubuntu.
>
> As Dean said, if there's anything we can do, let us know.
>
> On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
> wrote:
>
>> Hi Dean,
>>
>> > Assuming that Wine packages are more numerous than Picolisps...you
>> could do
>> > a native Windows version in Powerbasic for Wine. Not only would this up
>>
>> Well, but then we can go as well with ErsatzLisp, the Java version of
>> PicoLisp.
>>
>> A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
>> runtime
>> environment. Might be possible in the future with Joe's midipix port.
>>
>>
>> > I smiled when I saw your reasons for moving from C to asm because
>> > Powerbasic does ALIGN etc in it's stride without needing to drop down to
>> > it's industrial strength built in assembler.
>>
>> Aligning is not so much a problem. But can you control the stack layout,
>> condition codes (carry flag etc.) and multiple function entry points in
>> Powerbasic? Or do natice calls to external C functions in a completely
>> dynamic
>> way. All this is not even possible in C.
>>
>>
>> > I'd prefer to work in 64 bit asm but would be very happy to assist you
>> in
>> > any way I can to see Picolisp do well as I'm sure others would be.
>> Whatever
>> > you decide just let us know how we can help. I'm very new to Picolisp
>> but
>> > can already see that it's much too good not to do well.
>>
>> Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is
>> probably
>> too late by now.
>>
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>


-- 
*-- Frantisek Fuka*
(yes, that IS my real name)

-- My Personal homepage: www.fuxoft.cz
-- My Google+ profile: google.com/+fuxoft
-- My Telegram chat: telegram.fuxoft.cz

Re: Future of PicoLisp?

[Bruno Franco]

As for ubuntu, maybe you could make a Personal Package Archive (PPA). Its
lets you make your own packages that can be downloaded by users using
apt-get. Its as easy as downloading the normal packages, but the user must
manually add the repository.

Here's a useful link:
http://askubuntu.com/questions/71510/how-do-i-create-a-ppa

It would be more work than having the ubuntu team providing the package in
the official repositories, and I think you would have to make a new package
for every version of ubuntu you want to support. But its also the only way
to make sure that users get the most recent version of the software. As
Edgaras said, ubuntu is bad at keeping up with the newest releases.

I'm personally ok with compiling picolisp myself. But I know I wouldn't
have tried it if it had not been available as a package from ubuntu.

As Dean said, if there's anything we can do, let us know.

On Fri, Feb 3, 2017 at 10:31 AM, Alexander Burger 
wrote:

> Hi Dean,
>
> > Assuming that Wine packages are more numerous than Picolisps...you could
> do
> > a native Windows version in Powerbasic for Wine. Not only would this up
>
> Well, but then we can go as well with ErsatzLisp, the Java version of
> PicoLisp.
>
> A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX
> runtime
> environment. Might be possible in the future with Joe's midipix port.
>
>
> > I smiled when I saw your reasons for moving from C to asm because
> > Powerbasic does ALIGN etc in it's stride without needing to drop down to
> > it's industrial strength built in assembler.
>
> Aligning is not so much a problem. But can you control the stack layout,
> condition codes (carry flag etc.) and multiple function entry points in
> Powerbasic? Or do natice calls to external C functions in a completely
> dynamic
> way. All this is not even possible in C.
>
>
> > I'd prefer to work in 64 bit asm but would be very happy to assist you in
> > any way I can to see Picolisp do well as I'm sure others would be.
> Whatever
> > you decide just let us know how we can help. I'm very new to Picolisp but
> > can already see that it's much too good not to do well.
>
> Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is
> probably
> too late by now.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Alexander Burger]

Hi Dean,

> Assuming that Wine packages are more numerous than Picolisps...you could do
> a native Windows version in Powerbasic for Wine. Not only would this up

Well, but then we can go as well with ErsatzLisp, the Java version of PicoLisp.

A full PicoLisp doesn't yet run on Windows, as PicoLisp needs a POSIX runtime
environment. Might be possible in the future with Joe's midipix port.


> I smiled when I saw your reasons for moving from C to asm because
> Powerbasic does ALIGN etc in it's stride without needing to drop down to
> it's industrial strength built in assembler.

Aligning is not so much a problem. But can you control the stack layout,
condition codes (carry flag etc.) and multiple function entry points in
Powerbasic? Or do natice calls to external C functions in a completely dynamic
way. All this is not even possible in C.


> I'd prefer to work in 64 bit asm but would be very happy to assist you in
> any way I can to see Picolisp do well as I'm sure others would be. Whatever
> you decide just let us know how we can help. I'm very new to Picolisp but
> can already see that it's much too good not to do well.

Thanks for the feedback! Let's see what happens. For Ubuntu 17.04 it is probably
too late by now.

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

Re: Future of PicoLisp?

[dean]

The above addresses only your pil32 problem. I had no idea re pil64 on
Android so glad you sorted it :)

On 3 February 2017 at 13:06, dean  wrote:

> >the future of PicoLisp is dark.
> That sounds about right...I run openbsd and they've just made v6.0
> Linux- incompatible because they don't like the way it's going.
> Pil64 compiles fine on the latest openbsd BTW.
>
> Assuming that Wine packages are more numerous than Picolisps...you could
> do a native Windows version in Powerbasic for Wine. Not only would this up
> your linux exposure but Linux is only 2% of the desktop market whilst
> Windows has about 80%,
>
> I smiled when I saw your reasons for moving from C to asm because
> Powerbasic does ALIGN etc in it's stride without needing to drop down to
> it's industrial strength built in assembler. It also runs on win95 to 10
> and produces exes for the same, both without any dependencies. How about
> that for stable. It also has very fast dynamic arrays.
>
> I'd prefer to work in 64 bit asm but would be very happy to assist you in
> any way I can to see Picolisp do well as I'm sure others would be. Whatever
> you decide just let us know how we can help. I'm very new to Picolisp but
> can already see that it's much too good not to do well.
>
>
> On 3 February 2017 at 08:41, Lindsay John Lawrence <
> lawrence.lindsayj...@gmail.com> wrote:
>
>> I hope it is not dark.
>> I am just starting on my adventure using PicoLisp and having a wonderful
>> time of it.
>>
>> Having said that, I have never used any of the distribution packages.
>> Picolisp is simple to compile with minimal dependencies. Thank you for
>> that as well Alex.
>>
>> On my laptop machine I have just been compiling the latest download
>> whenever it is available.
>> It also runs extremely well in a minimal TinyCore Linux  image.
>> Tinycore+Picolisp+core system utils makes for a great sandbox in a few
>> tens of megabytes as either a virtualbox or as a bootable stick
>>
>> I think I also compiled it on Android a few months ago (in Termux)
>> without issue. I'll have to try it again there.
>>
>> Keep the light on :)
>>
>> /Lindsay
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 2, 2017 at 11:47 PM, Alexander Burger 
>> wrote:
>>
>>> Hi all,
>>>
>>> the future of PicoLisp is dark. I'm not sure if it can survive in
>>> packaged
>>> distribution.
>>>
>>> Ubuntu doesn't support it any more, probably due to the PIE (position
>>> independent executable) on x86-64.
>>>
>>> And at least on Android they seem to demand switching to Clang. The
>>> 32-bit
>>> versions of PicoLisp (pil32 and mini) which are written in C cannot be
>>> compiled
>>> on Clang, because Clang doesn't support dynamically allocated arrays,
>>> which
>>> pil32 depends on. As far as I notices, pil64 also has trouble on
>>> Clang/Android.
>>>
>>> :( Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>

Re: Future of PicoLisp?

[dean]

>the future of PicoLisp is dark.
That sounds about right...I run openbsd and they've just made v6.0
Linux- incompatible because they don't like the way it's going.
Pil64 compiles fine on the latest openbsd BTW.

Assuming that Wine packages are more numerous than Picolisps...you could do
a native Windows version in Powerbasic for Wine. Not only would this up
your linux exposure but Linux is only 2% of the desktop market whilst
Windows has about 80%,

I smiled when I saw your reasons for moving from C to asm because
Powerbasic does ALIGN etc in it's stride without needing to drop down to
it's industrial strength built in assembler. It also runs on win95 to 10
and produces exes for the same, both without any dependencies. How about
that for stable. It also has very fast dynamic arrays.

I'd prefer to work in 64 bit asm but would be very happy to assist you in
any way I can to see Picolisp do well as I'm sure others would be. Whatever
you decide just let us know how we can help. I'm very new to Picolisp but
can already see that it's much too good not to do well.


On 3 February 2017 at 08:41, Lindsay John Lawrence <
lawrence.lindsayj...@gmail.com> wrote:

> I hope it is not dark.
> I am just starting on my adventure using PicoLisp and having a wonderful
> time of it.
>
> Having said that, I have never used any of the distribution packages.
> Picolisp is simple to compile with minimal dependencies. Thank you for
> that as well Alex.
>
> On my laptop machine I have just been compiling the latest download
> whenever it is available.
> It also runs extremely well in a minimal TinyCore Linux  image.
> Tinycore+Picolisp+core system utils makes for a great sandbox in a few
> tens of megabytes as either a virtualbox or as a bootable stick
>
> I think I also compiled it on Android a few months ago (in Termux) without
> issue. I'll have to try it again there.
>
> Keep the light on :)
>
> /Lindsay
>
>
>
>
>
>
> On Thu, Feb 2, 2017 at 11:47 PM, Alexander Burger 
> wrote:
>
>> Hi all,
>>
>> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
>> distribution.
>>
>> Ubuntu doesn't support it any more, probably due to the PIE (position
>> independent executable) on x86-64.
>>
>> And at least on Android they seem to demand switching to Clang. The 32-bit
>> versions of PicoLisp (pil32 and mini) which are written in C cannot be
>> compiled
>> on Clang, because Clang doesn't support dynamically allocated arrays,
>> which
>> pil32 depends on. As far as I notices, pil64 also has trouble on
>> Clang/Android.
>>
>> :( Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>

Re: Future of PicoLisp?

[Alexander Burger]

Hi all,

thanks for your kind words!

Meanwhile it seems that the issue is solved, at least for pil64 on Android :)

For pil32 under Clang there is probably no way in the long term.

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

Re: Future of PicoLisp?

[Lindsay John Lawrence]

I hope it is not dark.
I am just starting on my adventure using PicoLisp and having a wonderful
time of it.

Having said that, I have never used any of the distribution packages.
Picolisp is simple to compile with minimal dependencies. Thank you for that
as well Alex.

On my laptop machine I have just been compiling the latest download
whenever it is available.
It also runs extremely well in a minimal TinyCore Linux  image.
Tinycore+Picolisp+core system utils makes for a great sandbox in a few tens
of megabytes as either a virtualbox or as a bootable stick

I think I also compiled it on Android a few months ago (in Termux) without
issue. I'll have to try it again there.

Keep the light on :)

/Lindsay






On Thu, Feb 2, 2017 at 11:47 PM, Alexander Burger 
wrote:

> Hi all,
>
> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
> distribution.
>
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
>
> And at least on Android they seem to demand switching to Clang. The 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot be
> compiled
> on Clang, because Clang doesn't support dynamically allocated arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on
> Clang/Android.
>
> :( Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[František Fuka]

I was never happy with the packaged Picolisp version being so much behind
the official one. Is it much of a problem to provide .deb installers on the
official site (for Debian and *buntu distros)?

Or, an universal binary that checks all the required dependencies and
compiles the latest version?

Simply something easy for people who are not yet quite comfortable with
compiling...

--- Sent from mobile phone

On Feb 3, 2017 08:57, "Alexander Burger"  wrote:

> Hi all,
>
> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
> distribution.
>
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
>
> And at least on Android they seem to demand switching to Clang. The 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot be
> compiled
> on Clang, because Clang doesn't support dynamically allocated arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on
> Clang/Android.
>
> :( Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Future of PicoLisp?

[Edgaras]

How much of a worry is that though? I would guess that no one installs it
before finding about it on the web or by some other means. And pico lisp is
mall enough to ether easily distribute binaries or just to compile yourself.
Distros can not keep up with realises anyway, or sometimes you have youse older
version of distro, so then can forget about up to date version from them. So on
this fron this does not sound too scary.

Android is of course much more of a pain to install stuff, still i would gues
that motivated user could compile it even there? And would think that picolisp
is "suficiently small" to be considered to be made up of mostly motivated
users.

Or you can provide docker images /s :).

On Fri, Feb 03, 2017 at 08:47:22AM +0100, Alexander Burger wrote:
> Hi all,
> 
> the future of PicoLisp is dark. I'm not sure if it can survive in packaged
> distribution.
> 
> Ubuntu doesn't support it any more, probably due to the PIE (position
> independent executable) on x86-64.
> 
> And at least on Android they seem to demand switching to Clang. The 32-bit
> versions of PicoLisp (pil32 and mini) which are written in C cannot be 
> compiled
> on Clang, because Clang doesn't support dynamically allocated arrays, which
> pil32 depends on. As far as I notices, pil64 also has trouble on 
> Clang/Android.
> 
> :( Alex
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Future of PicoLisp?

[Alexander Burger]

Hi all,

the future of PicoLisp is dark. I'm not sure if it can survive in packaged
distribution.

Ubuntu doesn't support it any more, probably due to the PIE (position
independent executable) on x86-64.

And at least on Android they seem to demand switching to Clang. The 32-bit
versions of PicoLisp (pil32 and mini) which are written in C cannot be compiled
on Clang, because Clang doesn't support dynamically allocated arrays, which
pil32 depends on. As far as I notices, pil64 also has trouble on Clang/Android.

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