Subscribe

[Rick Hanson]

Hello "Rick Hanson"  :-)
You are now subscribed


Yeah, baby!

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

Re: BBWT

[Rick Hanson]

A bit off-topic, but I like how this transformation

On 25 Feb 2017, 09:40:43 +0100, Alexander Burger wrote:
>(if (not (cdr W))
>   (Put C (car W))
>   (Put (car (cdr W)) (car W)) )
> ->
>(Put
>   (ifn (cdr W) C (cadr W))
>   (car W) )

reminds me of factoring in high school algebra.

   xy + xz
->
   x(y + z)

Yes, gotta love lisp for the ability to do this (and other things). :)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Unsubscribe

[Rick Hanson]

Good bye Rick Hanson <cryptor...@gmail.com> :-(
You are now unsubscribed


rick42 removing email from list.  Sorry for the noise.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: flinuxpicolisp

[Rick Hanson]

On Mon, Jul 4, 2016 at 2:17 PM, Thorsten wrote:
> Hi List,

Hi, Thorsten !

> I just discovered a nice article by Joe Bogner about FLINUX as an
> alternative was to run PicoLisp under Windows
> (http://picolisp.com/wiki/?  flinuxpicolisp).
>
> I tried it out, and succeded to a certain point but not further.
>
> When installing necessary tools like wget, make etc. I often hit the
> "could not change the root directory (No such file or directory)"
> error, but it appeared after the last installation step, and after
> an C-c installation appeared successful.
>
> But when trying to compile the 64bit version, Java is missing, and
> when I try to install it, I get the above error in the middle of the
> installation process that thus cannot finish.
>
> There is some info about this
> (https://github.com/wishstudio/flinux/issues/63), but I could not
> really find a solution. Did somebody on the list succeed with the
> Flinux install of the 64bit version on Windows?

I'm not aware.  It looks as if his article

http://picolisp.com/wiki/?flinuxpicolisp

was only meant for 32-bit pil builds.

On the other hand and on the topic of Windows 64-bit pil builds, Joe
is currently working on and very close to a solution based on midipix.

http://www.midipix.org/#sec-midipix

He has been working closely with the midipix author for many weeks now
(back and forth on IRC) to iron out particular problems with getting
pil ported there.

There is not much in the way of documentation yet, but Joe has
cataloged some pil patches related to the midipix build here:

https://github.com/joebo/picoLisp-win-x86-64

(and there might be more he has not pushed yet; not entirely sure.)

At any rate, when we see Joe (joebo) on #picolisp let's remind
ourselves to ask him to update us about it here on the ML.

> Any hints would be welcome.
> Cheers
> Thorsten

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

Re: PicoLisp Docker container

[Rick Hanson]

On Sun, May 29, 2016 at 1:52 PM, David Bloom  wrote:
> Hello List,

Hello David!

> I'm trying to make a PicoLisp container for development and scaling of
> PicoLisp applications.  At first I tried compiling within an Alpine Linux
> container and got musl errors, then tried in a 64-bit Tinycore linux
> container.
>
> Using latest source 16.2 I get the error below, any thoughts?  I'm not a C
> guy so this doesn't make much sense to me even when I look at the source
> code.  Thank you in advance for any suggestions, for the amazing language,
> and a very supportive community.
>
> ~/picoLisp/src $ gcc --version
> gcc (GCC) 5.2.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> ~/picoLisp/src $ make --version
> GNU Make 4.1
> Built for x86_64-unknown-linux-gnu
> Copyright (C) 1988-2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> ---
> ~/picoLisp/src $ make
> gcc -c -O2 -pipe -falign-functions=32 -fomit-frame-pointer
> -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat
> -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE  -D_FILE_OFFS
> ET_BITS=64 -m32 -D_OS='"Linux"' main.c
> In file included from /usr/include/features.h:389:0,
> from /usr/include/stdio.h:27,
> from pico.h:5,
> from main.c:5:
> /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or
> directory
> compilation terminated.
> Makefile:129: recipe for target 'main.o' failed
> make: *** [main.o] Error 1

I'm not a linux dood, but according to
http://stackoverflow.com/questions/7412548/error-gnu-stubs-32-h-no-such-file-or-directory-while-compiling-nachos-source,
"you're missing the 32 bit libc dev package."  (That would makes
sense, because at this point you are trying to build 32-bit picolisp.)

BTW, different linux distros call these packages with different names
(as indicated by the top answer at that URL), but also that the same
libs on different linux distros get installed to different locations.
Welcome to the circus that is development/building on linux. :)

> ---
> ~ $ cd picoLisp/src64/
> ~/picoLisp/src64 $ make
> ./mkAsm x86-64 ".linux" .s Linux base "" ../lib/map  version.l glob.l main.l
> gc.l apply.l flow.l sym.l subr.l big.l io.l db.l net.l err.l
> sys/x86-64.linux.code.l
> ../ersatz/pil: exec: line 5: java: not found
> Makefile:142: recipe for target 'x86-64.linux.base.s' failed
> make: *** [x86-64.linux.base.s] Error 2

This just means that the build process can't find java.  The `java`
executable has to be installed and on your PATH.

Good luck!

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

Re: HttpGate and picoLisp 64-bit

[Rick Hanson]

> so just do an additional
>
>   $ (cd src; make tools gate)
>
> to build the rest (without pil32).

Ah!  I did not know about this.  Thanks!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Redesigned Wiki is Live

[Rick Hanson]

I can't add any more to the discussion (especially beyond bene), but I
still wanted to drop a line and say, thank you!  It's a pleasure to
browse the new-look site.

All the best, --Rick.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Extending the wiki markup syntax

[Rick Hanson]

On 09 Mar 2016, 19:53:22 +0100, Thorsten Jolitz wrote:
> The gitrepo of my iOrg project can be found here:
> 
> ,
> | https://github.com/tj64/iorg
> `

Thorsten, thank you for reminding me of this project.  It looks very
nice!  I wish I could check it out now but I have to wait for this
weekend.  (Bummer, the wait, that is.)

Emacs + Org FTW!  :D
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp on Ubuntu

[Rick Hanson]

Hi Jon!

On Sun, Jan 17, 2016 at 2:30 PM, Jon Kleiser  wrote:
> There is a chance I could have managed to run some 64-bit Linux on
> this old Mac if I went for a non-GUI version, or a version that was
> happy with only 1GB RAM, [...]

If you like Ubuntu-ish and want to see about 64-bit, maybe try
http://lubuntu.net/ on your 1GB RAM machine.  More fun for the
weekend! :)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: A symbol that is bound only once

[Rick Hanson]

I admit that I didn't watch the video; so I don't know why `code` is
even needed, considering that the following expression (which is your
original expression but without `code` parts) gives you what you want
anyway.

(('((Gen) (Gen Gen))
  '((Gen)
('((Partial)
   (list '(N) (list 'if '(=0 N) 1 (list '* 'N (list Partial '(- N 1))
 (list (cons 'quote Gen) (cons 'quote Gen)
 5)  # (fact 5) is computed by this expression.

I know that doesn't answer your question, Christophe; just an
observation.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp Website

[Rick Hanson]

Thanks, Christophe, for putting this up. I'm now like AW, I'm only on the
phone.

Anyway, first thought upon loading the site: Star Trek  :)  I love it!
Great job!
On Dec 18, 2015 1:49 PM, "Christophe Gragnic" 
wrote:

> On Fri, Dec 18, 2015 at 7:17 PM, Erik Gustafson
>  wrote:
> > Sure thing! I'll send a few screenshots when I'm back at my computer in a
> > couple hours.
>
> I brutally «saved as» a local version then uploaded it here:
>
> http://fezzik.free.fr/picolisp/
>
>
> chri
>
> --
>
> http://profgra.org/lycee/ (site pro)
> http://delicious.com/profgraorg (liens, favoris)
> https://twitter.com/profgraorg
> http://microalg.info (langage de programmation pédagogique)
> http://expressions.club/ (structure des expressions mathématiques)
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Released PicoLisp 15.11

[Rick Hanson]

> Please note the new version numbering. With YY.MM[.nn] [...]

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

Re: New article about bin/ssl

[Rick Hanson]

Hi Mansur!

> I've written article about using bin/ssl [...]

I saw it.  It's great!  Thanks!

> Also, I would be glad if someone can review and check for
> grammar mistakes.

Done!  (I just changed it in the wiki ... so check me! :)

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

Re: Announce ARMv8 (arm64) version of 64-bit PicoLisp released

[Rick Hanson]

> I'm glad to announce that the arm64 port of pil64 is done! :)

Very nice!  Congrats!

I also noticed the handy pil-based build script.  "We don't need no
stinkin' make!"  ;)  Cheers!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp in nix

[Rick Hanson]

> if you are using the nix package manager , you
> will be be able to install the latest picolisp (now 3.1.11) very easily.

Thanks, Tomas!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp in TinyCore Linux

[Rick Hanson]

> I've submitted PicoLisp as a TinyCore Linux (http://tinycorelinux.net/)
> extension for x86_64 (64-bit) architecture. An armv7 (32-bit Raspberry Pi 2)
> extension has also been built and submitted, but is not in the official
> TinyCore repo yet.

Nice!  Thanks, A-Dub!

TinyCore seems like a nice fit for pil.  (Or is that the other way around? :)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Bare Metal

[Rick Hanson]

> http://interim.mntmn.com/
>

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

Re: (eval X 1) not behaving as expected

[Rick Hanson]

> It seems that 'apply' and 'let' do not call the same 'bind'
> procedure.

I find this statement very interesting and salient.

The Reference's example of `eval` with cnt is at
http://www.software-lab.de/doc/refE.html#eval and looks like this.

  : (de f (A)
 (list
(eval 'A)
(eval 'A 1)
(eval 'A 2) ) )
  -> f
  : (de g (A)
 (f (inc A)) )
  -> g
  : (one A)
  -> 1
  : (g (inc A))
  -> (3 2 1)

But "aping" the Reference's example with `let`, like this

  : (one A)
  -> 1
  : (let A (inc A)
  (let A (inc A)
(list (eval 'A)
  (eval 'A 1)
  (eval 'A 2
  -> (3 1 1)

shows that the `(eval 'A 1)` expression "goes straight to the top", as
Danilo mentioned and I believe that is precisely what he meant by his
statement I quoted above.  Again, quite interesting.

What I mean, in essence, by "aping" is that in other lisps, `let` is
equivalent to calling a lambda "on the fly"; so e.g., this

  (let A (inc A) ...)

is equivalent to

  ((lambda (A) ...) (inc A))

However, this is not the case with picoLisp, because the "equivalent"
in "lambda" (fexpr) on-the-fly calls of the above nested `let`
expression is

  : ((quote (A)
   ((quote (A)
  (list (eval 'A)
(eval 'A 1)
(eval 'A 2)))
(inc A)))
 (inc A))
  -> (3 2 1)

which yields the 2 that we were looking for[1], as it were, in the
nested `let` expression.

But, as I've learned in the past, picoLisp does not at times behave as
other lisps do -- and for good reason -- so I'm looking forward to
Alex shedding light on this, as he always does, and to learning
something more/new.

Best, --Rick
___
[1] https://www.youtube.com/watch?v=532j-186xEQ=30s
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: The `if-let` construct

[Rick Hanson]

A subtle change in the definition.  Added two quote marks.

(de if-let Args
  ## Better than anaphoric `if` because you can name the test result
  ## yourself.
  (let ((@Pattern Test @Then @Else) Args
@Test-Result (eval Test))
(eval
 (fill
  '(if '@Test-Result
   (let (@Pattern '@Test-Result)
 @Then)
   @Else)
  '(@Pattern @Test-Result @Then @Else)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Let and Glue

[Rick Hanson]

 Hmm, read-macros seem indeed a lot misunderstood. NEVER use a
 read-macro to insert values which are defined at *run*time! As the
 name says, they are evaulated at *read* time!

Maybe I too have been misunderstanding all along.  Alex, you seem to
be inferring here a strict separation between readtime and runtime;
however, I see eval process as intertwining them.

So, are you saying that the following is a kind of abuse (since I am
insert[ing] values which are defined at *run*time with a *read*
macro) and that it gives me the answer I'm looking for is some kind of
happy coincidence (despite my misunderstanding of the eval model)? :)

  ? (let X (+ 3 4) (glue   '(Number `X `(- 4 9
  - Number 7 -5

Or this, even?

  ? (let X (+ 3 4) (glue   '(Number `X `(- X 9
  - Number 7 -2

It seems to me that *read*ing is inherently involved in *run*time (the
eval process, which is recursive of course).

For instance, X in the above expressions is at some point, in the
eval process, bound to 7 before the expression

  '(Number `X `(- X 9))

is evaluated, and that the evaluation of this expression goes through
a reckoning of read macros first (under the context of the current
runtime environment which has X bound to 7).

If so, aren't then the `let` expression usages above *not*
problematic?

Or am I thinking about this incorrectly?  Thanks!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Let and Glue

[Rick Hanson]

Oops. I got that all wrong.  Look.

  $ pil
  : X
  - NIL
  : (let X (+ 3 4) (glue   '(Number `X `(- X 9
  - Number  
  : X
  - NIL

When I copied and pasted results in my last message, I was in a pil
session where I was messing around with `fill` and `run` and it
polluted what I thought was my top-level.  Here was the culprit.

  : (let X (+ 3 4) (run (fill '(glue   (Number  X `(- 4 9))) '(X
  !? (Number 7 -5)
  Number -- Undefined
  ? X
  - 7

But I didn't notice all along that I was at the question mark prompt
and thus *not* at the top-level.  Oops.  So I don't understand.  Back
to the drawing board.  :)  Sorry for the noise.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Let and Glue

[Rick Hanson]

Yeah, sorry.  I had this on the mind -- a different animal altogether.

  $ sbcl
  * (let ((X (+ 3 4))) `(hello ,X ,(- X 9)))
  (HELLO 7 -2)

Thanks, Alex, for taking the time and writing a very nice explanation.
I believe I understand it, but I will re-read and ponder it more.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Let and Glue

[Rick Hanson]

 Reading your other post I was wondering how it worked for you and
 thought it must be because of debug mode, and well ... correctly
 guessed ;-)

Hi Thorsten!  Yes. :) And btw thanks for picolisp-mode.  Please count
me as a happy user.
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Fwd: Making emacs like function documentation.

[Rick Hanson]

Why not just this?

   (de thefunc (A B C)

  This is the help text

  (* A B C) )
On Aug 2, 2015 9:54 AM, Alexander Burger a...@software-lab.de wrote:

 Hi Manuel,

  I'm trying to create a function to define functions with a documentation
  string like emacs defun. I'm trying something like this:
 
  (de defun P
  (def (car P) ...
 
  So the car of P is de function name, but it doesn't works as expected.

 You may try this:

(de defun P
   (put (car P) 'doc (caddr P))
   (def (car P) (cons (cadr P) (cdddr P))) )


 Then:
: (defun thefunc (A B C)
   This is the help text
   (* A B C) )
- thefunc

: (pp 'thefunc)
(de thefunc (A B C)
   (* A B C) )
- thefunc

: (get 'thefunc 'doc)
- This is the help text

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

Re: Websockets now considered stable

[Rick Hanson]

 Hi Rick, seems like a fix would be a check there: if sessions dir
 doesn't exist (and Redis isn't used to store the session) create it
 and move on instead of breaking down in tears.

Hi Henrik!  Yes, I agree.  BTW, thanks.  I forgot to thank you before
for sharing this!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Websockets now considered stable

[Rick Hanson]

What gives?!  This stuff is broken!!!

$ git clone https://bitbucket.org/hsarvell/pl-web
Cloning into 'pl-web'...
fatal: repository 'https://bitbucket.org/hsarvell/pl-web/' not found

Just yanking your chain.  I know this is a mercurial repo.  :)

Thanks, man.  Looks good. I'll study the code when I get time in the
next few days.

On Fri, Jun 26, 2015 at 3:30 PM, Henrik Sarvell hsarv...@gmail.com wrote:
 Hi all, after over a month without any of the prior issues I now
 consider the websockets part of pl-web stable:
 https://bitbucket.org/hsarvell/pl-web Gone are the days of 100% CPU
 usage and zombie processes.

 With Alex's help the main web server is now more stable (he made me
 throw away a few throws in favour of a few byes). The throws were
 causing the zombies.

 I was also including dbg.l (it was causing hung processes at 100%
 CPU), it's basically been deprecated or something, I'll leave it up to
 him to elaborate. It's just something I've been including by habit
 since years ago when at some point I needed to include it to do some
 kind of debugging.

 Anyway atm the WS router is regularly routing up to 40 messages per
 second to upwards 300-500 clients which means that roughly 20,000
 messages are being pushed out per second during peak hours.

 The PL processes show up with 0 CPU and 0 RAM usage when I run top,
 sometimes 1% CPU :) They hardly register even i aggregate, the server
 would be running 99% idle if it was only running the WS server.

 To work around the inter-process limit of 4096 byte long messages the
 router now supports storing the messages in Redis (raw disk is also
 supported if Redis is not available), this is also in effect in
 production and is working flawlessly since months.

 This is how I start the WS server in production:

 (load pl-web/pl-web.l)

 (setq *Mobj (new '(+Redis) pl-ws-))

 (undef 'app)

 (setq *WsAuth '((notifications ((send (put your password/key here))

 (de app ()
(splitPath)
(wsApp)
(bye))

 (de go ()
(wsServer)
(server 9090) )
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

How to manage picoLisp projects

[Rick Hanson]

In looking at Henrik's pl-web, I copied the demo app directory
`demo-app` to a standalone directory that would be a project
directory. I called it `pl-web-demo`.  Then, I copied Henrik's
libraries `pl-web` and `ext` into the project directory.  And since
I'm running a global version of `pil` (in `/opt`), I linked in the
`lib` directory under the project directory.  So, now that project
directory looks like this.

[pl-web-demo]$ l
total 28
drwxr-xr-x 6 rick users 4096 Jun 28 16:49 .
drwxr-xr-x 3 rick users 4096 Jun 28 16:25 ..
drwxr-xr-x 3 rick users 4096 Jun 28 16:27 ext
lrwxrwxrwx 1 rick users   21 Jun 28 16:49 lib - /opt/lib/picolisp/lib
-rwxr-xr-x 1 rick users 1867 Jun 28 16:25 main.l
drwxr-xr-x 4 rick users 4096 Jun 28 16:26 pl-web
drwxr-xr-x 2 rick users 4096 Jun 28 16:25 public
drwxr-xr-x 2 rick users 4096 Jun 28 16:33 sessions

And everything is working fine.

But then I thought about the issues of creating such a project
directory.  It needs to keep track of its dependencies.  Notice that I
installed all the dependencies manually.  (I also had to create an
empty `sessions` directory with which to start -- this is a type of
dependency I guess.)

Now, to my question.  Is there a standard, automatic way to do this?

Basically, I'm wondering if there is a project management tool like
Maven (Java), Leiningen (Clojure), Cask (Elisp), ASDF (CL), but for
picoLisp.  I'd also be interested in hearing arguments for or against
such a thing.  (Not having used these tools, I'm ok just manually
keeping these things up, but many of you here are more experienced
than I in deploying and maintaining software, so I'd appreciate your
thoughts.)

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

Subscribe

[Rick Hanson]

Y-h! Picolisp roolz :)

Re: Test - Please ignore

[Rick Hanson]

On Mon, Jun 1, 2015 at 7:51 AM, Alexander Burger a...@software-lab.de wrote:
 This is a test mail. Please ignore.

I feel like being a contrarian today. :)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: https server side

[Rick Hanson]

 Thank you all for your contributions!

I quite agree.  I really learned a lot from everyone's responses.  Thanks!
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: 4clojure tasks in PicoLisp

[Rick Hanson]

Thanks, Mike. This is a very nice resource.

Re: New article - Installing local wiki with Kerberos authentication

[Rick Hanson]

Very nice guide!  Thanks, Mansur!

On Tuesday, April 14, 2015, Mansur Mamkin mmam...@mail.ru wrote:

 Hi all!
 I'm happy to announce a litle article:
 Installing local wiki with Kerberos authentication

 http://picolisp.com/wiki/?localwikikerberos

 Best regards,
 Mansur Mamkin
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Building picolisp on (some) BSDs

[Rick Hanson]

Thanks, you all.  I'm glad to be involved with such a great community, and
.. I have a *lot* to learn. :)

On Wed, Mar 25, 2015 at 12:07 PM, Jakob Eriksson ja...@aurorasystems.eu
wrote:

 Excellent work!

 On March 25, 2015 4:18:15 PM CET, Rick Hanson cryptor...@gmail.com
 wrote:

 Hello, list!

 I thought I should write a few words on some information I’ve gleaned
 trying to build picolisp on some of the BSDs. There are people on this list
 with more experience than I with both BSD and picolisp; so please comment
 upon what I have to say, and weigh in where you feel, or know, that it is
 necessary, for the benefit of everyone. This is a learning experience for
 me. I am not in a position to write authoritatively. I will try to
 accurately report my findings, but please especially point out where I am
 wrong or being misleading. (I would have done this unintentionally, of
 course.)

 *Bottom Line*

 Starting from the picolisp 3.1.9.13 source — the latest as of this past
 weekend (more about this below) — I was able to successfully build and
 unit-test pil32 on the following BSDs: FreeBSD 10.1, OpenBSD 5.6, and
 NetBSD 6.1.5. Also, I was able to successfully build and unit-test pil64 on
 FreeBSD 10.1. (AFAIK, only FreeBSD, among the three, has bootstrap support
 (with pil32) to build pil64, and I only looked at the bootstrapping option
 for building pil64.)

 The following sections just spell out some detail about the builds. A
 quick note before that: on each BSD box in question, I had to install
 gmake. This shouldn’t be a surprise — picolisp builds need GNU make, and
 the BSDs’ stock make is BSD, not GNU.

 *FreeBSD 10.1*

 I was aiming for a pil64 build in this machine, so I started with a
 64-bit (amd64) FreeBSD 10.1 box. First, I had to build pil32 (for the
 bootstrap build).

 On a fresh FreeBSD 10 box you won’t have gcc, so you need to install
 that. I used pkg for that (i.e. I didn’t build gcc from ports). Its
 interface is installed in /usr/local/bin/gcc48, by the way.

 But, why install gcc? After all, clang (the stock compiler) is a
 “drop-in replacement for gcc“, right? Wrong. If you try to build pil32
 with clang, you will be greeted with the following errors.

 apply.o.log:apply.c:15:40: error: fields must have a constant size: 
 'variable length array in structure' extension will never be supported
 apply.o.log:apply.c:67:43: error: fields must have a constant size: 
 'variable length array in structure' extension will never be supported
 flow.o.log:flow.c:91:37: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:159:40: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:299:34: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:663:37: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:698:34: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:736:37: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 flow.o.log:flow.c:786:37: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported
 main.o.log:main.c:720:34: error: fields must have a constant size: 'variable 
 length array in structure' extension will never be supported

 Yes, that’s right folks, clang does not support dynamically sized arrays
 and never will (!) as unequivocally stated by their error message: “extension
 will never be supported“ (“never”? really?). (Take that picolispers!
 This reminds me of the taunting Frenchman in Monty Python’s Holy Grail: “No
 chance, English bedwetting types!”)

 But gcc does support this; so, back to gcc. The objects build fine with
 gcc, but then we run into a problem in the link step.

 gcc48 -o ../bin/picolisp -m32 -rdynamic main.o gc.o apply.o flow.o sym.o 
 subr.o big.o io.o net.o tab.o -lm
 /usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when searching 
 for -lm
 /usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for 
 -lm
 /usr/local/bin/ld: cannot find -lm
 /usr/local/bin/ld: skipping incompatible 
 /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/libgcc.a when 
 searching for -lgcc
 /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when searching 
 for -lgcc
 /usr/local/bin/ld: cannot find -lgcc
 /usr/local/bin/ld: skipping incompatible 
 /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../../libgcc_s.so
  when searching for -lgcc_s
 /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when 
 searching for -lgcc_s
 /usr/local/bin/ld: cannot find -lgcc_s
 /usr/local/bin/ld: skipping incompatible

Re: Reference Manual diagram conventions

[Rick Hanson]

I think (I’m speculating, that is) that the confusion was due to the
unusual (but not incorrect) choice of having key/val pairs stored in symbol
property lists as

  +-+-+
  | VAL | KEY |
  +-+-+

where VAL is the the CAR position and KEY in the CDR position. There is not
right or wrong about this, that’s just how it works. I find this point very
interesting. I believe it has something to do with streamlining the
picolisp (C or asm) code regarding properties, but I don’t know for sure.
Alex?
​

Building picolisp on (some) BSDs

[Rick Hanson]

Hello, list!

I thought I should write a few words on some information I’ve gleaned
trying to build picolisp on some of the BSDs. There are people on this list
with more experience than I with both BSD and picolisp; so please comment
upon what I have to say, and weigh in where you feel, or know, that it is
necessary, for the benefit of everyone. This is a learning experience for
me. I am not in a position to write authoritatively. I will try to
accurately report my findings, but please especially point out where I am
wrong or being misleading. (I would have done this unintentionally, of
course.)

*Bottom Line*

Starting from the picolisp 3.1.9.13 source — the latest as of this past
weekend (more about this below) — I was able to successfully build and
unit-test pil32 on the following BSDs: FreeBSD 10.1, OpenBSD 5.6, and
NetBSD 6.1.5. Also, I was able to successfully build and unit-test pil64 on
FreeBSD 10.1. (AFAIK, only FreeBSD, among the three, has bootstrap support
(with pil32) to build pil64, and I only looked at the bootstrapping option
for building pil64.)

The following sections just spell out some detail about the builds. A quick
note before that: on each BSD box in question, I had to install gmake. This
shouldn’t be a surprise — picolisp builds need GNU make, and the BSDs’
stock make is BSD, not GNU.

*FreeBSD 10.1*

I was aiming for a pil64 build in this machine, so I started with a 64-bit
(amd64) FreeBSD 10.1 box. First, I had to build pil32 (for the bootstrap
build).

On a fresh FreeBSD 10 box you won’t have gcc, so you need to install that.
I used pkg for that (i.e. I didn’t build gcc from ports). Its interface is
installed in /usr/local/bin/gcc48, by the way.

But, why install gcc? After all, clang (the stock compiler) is a “drop-in
replacement for gcc“, right? Wrong. If you try to build pil32 with clang,
you will be greeted with the following errors.

apply.o.log:apply.c:15:40: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
apply.o.log:apply.c:67:43: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:91:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:159:40: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:299:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:663:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:698:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:736:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:786:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
main.o.log:main.c:720:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported

Yes, that’s right folks, clang does not support dynamically sized arrays
and never will (!) as unequivocally stated by their error message: “extension
will never be supported“ (“never”? really?). (Take that picolispers! This
reminds me of the taunting Frenchman in Monty Python’s Holy Grail: “No
chance, English bedwetting types!”)

But gcc does support this; so, back to gcc. The objects build fine with gcc,
but then we run into a problem in the link step.

gcc48 -o ../bin/picolisp -m32 -rdynamic main.o gc.o apply.o flow.o
sym.o subr.o big.o io.o net.o tab.o -lm
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when
searching for -lm
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for -lm
/usr/local/bin/ld: cannot find -lm
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/libgcc.a
when searching for -lgcc
/usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when
searching for -lgcc
/usr/local/bin/ld: cannot find -lgcc
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../../libgcc_sso
when searching for -lgcc_s
/usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when
searching for -lgcc_s
/usr/local/bin/ld: cannot find -lgcc_s
/usr/local/bin/ld: skipping incompatible /lib/libc.so.7 when searching
for /lib/libc.so.7
/usr/local/bin/ld: cannot find /lib/libc.so.7
/usr/local/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a
when searching for /usr/lib/libc_nonshared.a
/usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a
/usr/local/bin/ld: skipping incompatible /usr/lib/libssp_nonshared.a
when searching for /usr/lib/libssp_nonshared.a

Re: Announce: 7fach BlitzMenu

[Rick Hanson]

Alex,

I forgot to tell you that I tried this a while back.  It's very
impressive!  I'm very sorry that I cannot give you any constructive
feedback, as I need to actually learn the basic rudiments of App Dev in pil
myself first, like literally step through doc/app.html, like a baby (n00b
that I am).

But back to the subject, the fact that you can have the design elements of
the sheet (menu) in the interface like that (for the user to control) is
tres cool.  I can see how this is very useful for your customer!  Thanks
for sharing this with us.  I will use this, as I mature in pil app dev, to
highlight, and as a model for, what can be achievable with pil as a web dev
base.  Very inspirational!

Good luck with your prospects.

All the best, --Rick

On Thu, Mar 12, 2015 at 2:29 PM, Alexander Burger a...@software-lab.de
wrote:

 Hello list,

 let me announce 7fach BlitzMenu, our first attempt for a public
 application since 9 years :)

 It is for gastronomers, restaurants or canteens, to maintain their
 dishes and beverages in a database, and allow them to generate their
 daily or weekly menus with just a few mouse clicks.

 Independent from the question whether it will be a commercial success (I
 hope it does), it has some interesting aspects from a technical
 (PicoLisp) point of view:

 1. It allows the user to directly edit PostScript layout templates in a
Canvas. Then these layouts can be combined with groups of articles
from the database to generate PDF and HTML files.

 2. I found out that the '+Bag' relations can be nested. This allows the
creation of multi-dimensional data structures, directly in the DB
model.

Normally, a (+List +Bag) represents a two-dimensional table, which
maps to a '+Chart' in the GUI. To my own surprise, it works also if
an element in a bag is a (+List +Bag) again (i.e. nested Bags),
resulting in a three-dimensional structure:

(rel grp (+List +Bag)   # Groups/Articles
   ((+Bool))   # Aktive
   ((+String)) # Description
   ((+List +Bag)   # Articles
  ((+Bool))   # Aktive
  ((+Link) (+Art)) ) )# Article

And: I found a way to allow direct editing of these structures in the
GUI, by connecting charts on the different levels with radio buttons.
In principle, this can be extended to as many dimensions as desired.

 The system is ready for production use now, and can be found at

http://BlitzMenu.7fach.de

 Initial language is German, but you can switch to English if you like.
 Other languages are planned but not yet supported.

 The second entry in the navigation on the left is Introduction. Here
 you may view a short video (without sound) showing the basic usage.

 And the third entry is Try yourself. If you click on Start demo
 application you get a private demo database in a sandbox, where you can
 play around yourself. Note that your data are lost when you close the
 browser session.

 Please don't submit the form on New registration (unless, of course,
 you want to become a customer ;)

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

Re: An HTTP(S) client library for PicoLisp

[Rick Hanson]

Great stuff.  Clean code and clear doc.  But I've already told AW this on
IRC.  For others: I highly recommend!

On Mon, Mar 16, 2015 at 11:46 AM, Alexander Williams a...@unscramble.co.jp
wrote:

 Hi everyone,

 Presenting another thing, this time it's an HTTPS library using a native C
 lib for the hard stuff.

 It includes functions for http/https GET/HEAD/POST/PUT/DELETE/*ANYTHING*,
 and can perform authentication.

 It returns the response body in a cons pair, or save to file, and returns
 headers in a list of cons pairs.

 Of course, I've documented most of the functionality here:

   https://github.com/aw/picolisp-https/blob/master/EXPLAIN.md

 And you can get the code here:

 https://github.com/aw/picolisp-https

 Let me know if I missed something, as I haven't fully tested every
 scenario (this was slightly more complex).

 Thanks!

Re: Solaris 10 picolisp 64 build

[Rick Hanson]

Thank you, Alex and Jakob!

Solaris 10 picolisp 64 build

[Rick Hanson]

Sorry in advance if you’ve already covered this issue in the past.

I’m on Solaris 10; I can build the 32-bit picolisp (3.1.9) with no problem.
Then, I go do a (cd src64; make) (which is GNU make btw); this builds the
x86-64.sunOS.base.s file via mkAsm, but it fails in the next step on gas
--64 (which reads the .s file) with a bunch of errors of the form

Error: Unknown opcode: `$OP'

where $OP is any one of several opcodes, e.g. adc, addq, clc, ja, jbe, jz,
movb, mul, etc.

FIrst, I thought that a very old version of gas might be causing the issue
(i.e. maybe it was not able to understand some of the new (?) opcodes; yes,
I was very optimistic :); so I downloaded, built and installed binutils
(2.24.51) which gave me a new gas. The new gas was of no avail — the same
types of errors occurred.

So, I then downloaded the .s files for Solaris from here:
http://software-lab.de/x86-64.sunOs.tgz and unarced them in the picoLisp
directory. As you can imagine, this didn’t work either — the same Unknown
opcode messages were appearing.

I suspect that I’m making a very fundamental mistake here, but I can’t
quite put my finger on it. Am I using gas wrongly, or do I have the wrong
assembler?

Thanks for any help.

—Rick

rick42 on #picolisp
​

Re: A PicoLisp native library tutorial

[Rick Hanson]

This is great stuff.  Nice writing style and very useful for me as a n00b.
If Alexander is a n00b, by his own self-profession, then I'm a
sub-sub-sub-n00b, because this is good stuff. Thanks!

On Tue, Mar 3, 2015 at 11:36 AM, Alexander Williams a...@unscramble.co.jp
wrote:

 Hi list,

 Some of you might know me from IRC @aw-Unscramble.

 I've written my first PicoLisp library, a native C binding for Nanomsg
 (picolisp-nanomsg) - as an experiment for myself to learn this language.

 In doing so, I ran into a few difficulties (mostly noob stuff) but
 Regenaxer has been very helpful and patient.

 I also wrote a tutorial explaining the code, to help other newbies
 understand some useful features of PicoLisp:

   https://github.com/aw/picolisp-nanomsg/blob/master/EXPLAIN.md
 https://githubcom/aw/picolisp-nanomsg/blob/master/EXPLAIN.md

 And of course, the library: https://github.com/aw/picolisp-nanomsg


 Thanks!

Re: Solaris 10 picolisp 64 build

[Rick Hanson]

Duh!  That's it!  And it even says x86 in the name!!! (e.g.
`x86-64.sunOs.tgz`) I hereby turn in any computing creds I've garnered over
the years to be thrown into burning inferno where they belong, and I'll go
live in a box down my the river. :)  Thanks!

On Tue, Mar 3, 2015 at 4:50 PM, Jakob Eriksson ja...@aurorasystems.eu
wrote:


 You are not by any chance on a Sparc platform?




 On 03/03/15 20:57, Rick Hanson wrote:
  Sorry in advance if you’ve already covered this issue in the past.
 
  I’m on Solaris 10; I can build the 32-bit picolisp (3.1.9) with no
 problem.
  Then, I go do a (cd src64; make) (which is GNU make btw); this builds the
  x86-64.sunOS.base.s file via mkAsm, but it fails in the next step on gas
  --64 (which reads the .s file) with a bunch of errors of the form
 
  Error: Unknown opcode: `$OP'
 
  where $OP is any one of several opcodes, e.g. adc, addq, clc, ja, jbe,
 jz,
  movb, mul, etc.
 
  FIrst, I thought that a very old version of gas might be causing the
 issue
  (i.e. maybe it was not able to understand some of the new (?) opcodes;
 yes,
  I was very optimistic :); so I downloaded, built and installed binutils
  (2.24.51) which gave me a new gas. The new gas was of no avail — the same
  types of errors occurred.
 
  So, I then downloaded the .s files for Solaris from here:
  http://software-lab.de/x86-64.sunOs.tgz and unarced them in the picoLisp
  directory. As you can imagine, this didn’t work either — the same Unknown
  opcode messages were appearing.
 
  I suspect that I’m making a very fundamental mistake here, but I can’t
  quite put my finger on it. Am I using gas wrongly, or do I have the wrong
  assembler?
 
  Thanks for any help.
 
  —Rick
 
  rick42 on #picolisp
  ​
 

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

Re: Solaris 10 picolisp 64 build

[Rick Hanson]

down *by* the river.  (I can't even get *that* right.)  Cheers!

On Tue, Mar 3, 2015 at 5:00 PM, Rick Hanson cryptor...@gmail.com wrote:

 Duh!  That's it!  And it even says x86 in the name!!! (e.g.
 `x86-64.sunOs.tgz`) I hereby turn in any computing creds I've garnered over
 the years to be thrown into burning inferno where they belong, and I'll go
 live in a box down my the river. :)  Thanks!

 On Tue, Mar 3, 2015 at 4:50 PM, Jakob Eriksson ja...@aurorasystems.eu
 wrote:


 You are not by any chance on a Sparc platform?




 On 03/03/15 20:57, Rick Hanson wrote:
  Sorry in advance if you’ve already covered this issue in the past.
 
  I’m on Solaris 10; I can build the 32-bit picolisp (3.1.9) with no
 problem.
  Then, I go do a (cd src64; make) (which is GNU make btw); this builds
 the
  x86-64.sunOS.base.s file via mkAsm, but it fails in the next step on gas
  --64 (which reads the .s file) with a bunch of errors of the form
 
  Error: Unknown opcode: `$OP'
 
  where $OP is any one of several opcodes, e.g. adc, addq, clc, ja, jbe,
 jz,
  movb, mul, etc.
 
  FIrst, I thought that a very old version of gas might be causing the
 issue
  (i.e. maybe it was not able to understand some of the new (?) opcodes;
 yes,
  I was very optimistic :); so I downloaded, built and installed binutils
  (2.24.51) which gave me a new gas. The new gas was of no avail — the
 same
  types of errors occurred.
 
  So, I then downloaded the .s files for Solaris from here:
  http://software-lab.de/x86-64.sunOs.tgz and unarced them in the
 picoLisp
  directory. As you can imagine, this didn’t work either — the same
 Unknown
  opcode messages were appearing.
 
  I suspect that I’m making a very fundamental mistake here, but I can’t
  quite put my finger on it. Am I using gas wrongly, or do I have the
 wrong
  assembler?
 
  Thanks for any help.
 
  —Rick
 
  rick42 on #picolisp
  ​
 

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

Re: Solaris 10 picolisp 64 build

[Rick Hanson]

All, does this mean that picoLisp64 cannot be built on a Solaris 10 sparc64
box?  (That's what I have.)  If not, no worries; I can, and will be happy
to, still use picoLisp32 there.  Thanks!

On Tue, Mar 3, 2015 at 5:01 PM, Rick Hanson cryptor...@gmail.com wrote:

 down *by* the river.  (I can't even get *that* right.)  Cheers!

 On Tue, Mar 3, 2015 at 5:00 PM, Rick Hanson cryptor...@gmail.com wrote:

 Duh!  That's it!  And it even says x86 in the name!!! (e.g.
 `x86-64.sunOs.tgz`) I hereby turn in any computing creds I've garnered over
 the years to be thrown into burning inferno where they belong, and I'll go
 live in a box down my the river. :)  Thanks!

 On Tue, Mar 3, 2015 at 4:50 PM, Jakob Eriksson ja...@aurorasystems.eu
 wrote:


 You are not by any chance on a Sparc platform?




 On 03/03/15 20:57, Rick Hanson wrote:
  Sorry in advance if you’ve already covered this issue in the past.
 
  I’m on Solaris 10; I can build the 32-bit picolisp (3.1.9) with no
 problem.
  Then, I go do a (cd src64; make) (which is GNU make btw); this builds
 the
  x86-64.sunOS.base.s file via mkAsm, but it fails in the next step on
 gas
  --64 (which reads the .s file) with a bunch of errors of the form
 
  Error: Unknown opcode: `$OP'
 
  where $OP is any one of several opcodes, e.g. adc, addq, clc, ja, jbe,
 jz,
  movb, mul, etc.
 
  FIrst, I thought that a very old version of gas might be causing the
 issue
  (i.e. maybe it was not able to understand some of the new (?) opcodes;
 yes,
  I was very optimistic :); so I downloaded, built and installed binutils
  (2.24.51) which gave me a new gas. The new gas was of no avail — the
 same
  types of errors occurred.
 
  So, I then downloaded the .s files for Solaris from here:
  http://software-lab.de/x86-64.sunOs.tgz and unarced them in the
 picoLisp
  directory. As you can imagine, this didn’t work either — the same
 Unknown
  opcode messages were appearing.
 
  I suspect that I’m making a very fundamental mistake here, but I can’t
  quite put my finger on it. Am I using gas wrongly, or do I have the
 wrong
  assembler?
 
  Thanks for any help.
 
  —Rick
 
  rick42 on #picolisp
  ​
 

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

Subscribe

[Rick Hanson]

Add me, baby! ;-)