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

[Rowan Thorpe]

On Sun, 12 Apr 2020 at 01:04, Guido Stepken  wrote:
> Hello, all!
>
> It might sound a little bit weird, when i tell you, that recently 
> standardized Webassembly Containers in your browser are - Lisp machines.

Aside from the surface syntactic similarities due to the use of
s-expressions in the text format, I think the better
content-comparison of WebAssembly is to a register machine (hence
"assembly" in the name, but something closer to the LLVM IR - which
can be JITted or statically compiled - feels like a good comparison),
as opposed to lisp which is functional. I used to think of it as being
like other stack-machine languages like Forth (or even the JVM), and
the design rationale at https://webassembly.org/docs/rationale/ even
describes it as "a structured stack machine", but
http://troubles.md/posts/wasm-is-not-a-stack-machine/ explains why
this is not quite accurate. Also several Forths (like gforth) are
considered "stack-machine implementations" due to being a forth, but
they can use registers in addition to the typical 2-stack forth core,
so the stack/register boundary gets a little fuzzy there too. When I
first read about WebAssembly the thought that hit me was not that it
was like Picolisp but that it is very similar to the 64-bit assembly
written for and used at the core of the 64-bit Picolisp
implementation, except that - unlike WebAssembly's text format - there
parentheses are not used because as is stated at
https://picolisp.com/wiki/?src64 "Assembly language is not a
functional language, i.e. the individual instructions do not "return"
a value. So a fully parenthesized syntax is useless and just tedious."

By the way what I love most about Picolisp is that it feels like as
good a hybrid as you can get between the "typical functional
lisp/scheme" mental model and something that feels "forth-like" in
terms of minimalism/precision/close-to-the-metal von-neumann
architecture-friendliness. I describe it to friends as "as close as
you can get a lisp to forth while still being able to call it a lisp"
(I hope Alex doesn't hate that oversimplification too much, if he has
a better soundbite-way to capture the core of that sentiment I'd be
keen to hear it and would be happy to modify my soundbite). My two
favourite programming idioms are lisp and forth (rust comes third, and
part of its coolness is its comprehensive support for compiling to
webasm, which is why I started learning rust).

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
PGP fingerprint: 92FA 6C6F ABF2 C1B2 7E1C  7CCD 131F D7A9 542F 12F0

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

Re: Dr. Theobold Text Adventure Game: Looking for Beta Testers

[Rowan Thorpe]

On 2 September 2017 at 09:34, Christopher Howard
<christopher.how...@qlfiles.net> wrote:
> This link is a release announcement for a beta version of a text-
> adventure game I wrote in PicoLisp:
>
> http://lists.nongnu.org/archive/html/dr-theobold-discuss/2017-09/msg000
> 00.html
>
> This is the project home page:
>
> https://savannah.nongnu.org/projects/dr-theobold/

BTW: The download-links for the -r2 version are dead links (and the
"homepage" link is an empty directory, but that is probably just
because you haven't set that up yet).

-- 
Rowan Thorpe
mailto:ro...@rowanthorpe.com
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens

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

Re: Let's Encrypt Expiry

[Rowan Thorpe]

On 28 May 2017 at 12:50, Alexander Burger  wrote:
> Thanks Tomas,
>
>> I got these emails too and everything worked well for me.
>
> OK, this is reassuring.
>
>> Maybe added or removed names?
>
> Yeah, maybe ... ;)

I've always received expiry-reminders for old certs, irrespective of
whether they've already been replaced by new certs on any given
servers, and whether the new ones are being used. I think that is just
a consequence of keeping their service as "stateless" as possible.
They don't/can't keep any indication of whether you are still using
the old cert anywhere, so just in case you are, they don't disable
notifications for it. This is probably because [A] it would become a
scaling-nightmare if they tried, and [B] although they send you new
certs, they can't force you to replace all uses of the old certs with
them straight away (or to reload all services using the old certs -
like email-servers, voip-servers, websocket servers, etc - in addition
to the web-server). I configure various servers' TLS with symlinks to
the latest LE cert-location and add daemon-reloads as end-hooks to the
LE/certbot cronjob for that reason, but some services don't allow or
misbehave with symlinked certs (I think I remember FreeSWITCH borking
on it at some point, for example).

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

Re: Header parsing

[Rowan Thorpe]

BTW: I receive DMARC reports about bounced/quarantined mails spoofing
my address, and just received one from fastmail which matches the
quarantined deliveries vukini reported (they failed validation due to
the accidentally forwarded SPF and DKIM headers, as I predicted).

..so it seems my posts to the list over the years have mostly reached
an audience of one  :-D

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens

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

Re: Header parsing

[Rowan Thorpe]

On 19 April 2017 at 10:45, Alexander Burger <a...@software-lab.de> wrote:
> Hi Rowan,
>
> > On Wed, Apr 19, 2017 at 08:12:11AM +0200, a...@software-lab.de wrote:
> > Rowan, are you sure? I tried your fix, but now it seems the mail
> > body is lost? Any idea?
>
> OK, so I tried a different approach. According to "a CRLF may be inserted 
> before
> any WSP", I simply use (peek) to see if the next line starts with white space.
> Shouldn't this be enough?

Yes, that sounds more like "the right way" :-) ...as long as at least
one byte of push-back is always guaranteed - like for POSIX ungetc() -
and if it doesn't ever cause noticeable performance issues (apparently
not - (till) seems to use the same lookahead anyway).

My patch was a late-night quick-hack adapted from a sed-script of
mine, to the subset of picolisp vocabulary I could easily recall, just
to get the ball rolling (hence my mention that there were surely
better ways to do it). As for my patch eating the message-body during
your test, I can't imagine there is a difference between the
spool-file (mbox) format on your mail-server compared to mine, so
perhaps I fumble-fingered something while preparing the patch?
otherwise the mailing-list might have messed with the attached patches
when inlining them? I won't look into that though because your (peek)
suggestion makes more sense (less invasive) anyway.

PS: Even when using (peek) I think [A] the second patch (for not
chomping the final "^J") may still be applicable (at least for the
last email that appears in the spool file), and also *perhaps* [B] the
first line of the main patch - for skipping trailing timestamp on the
"From " line (but maybe that was just needed to deal with a
side-effect of the sliding-window technique). They were both needed
when testing on my internal Exim server, I'm not sure about Postfix.
The second patch could be tested against your mail-server by sending
it a mail with no trailing blank-line then triggering a run of the
script immediately (so that the mail appears last in the spoolfile),
and looking for something like this:

> ...
> abcdefg: this is the penultimate line
> -- defg: this is the ultimate line
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

.having said that, I see from http://www.postfix.org/local.8.html

> In the case of UNIX-style mailbox delivery, the local(8) daemon
> prepends a "From sender time_stamp" envelope header  to  each  message,
> ..[snip]..
> and appends an empty line.

so maybe the worst that would happen on postfix is having a
non-conformant empty line with two trailing "\r" characters...

PPS: While tweaking to use the sliding-window technique, I used the following:

 * (chop) first line of each header
 * get (index) of the first " " in the first line
 * split the first line using (head) and (tail) based on that index
 * for each continuation line just (chop) then (conc) them to the tail
without extra splitting-and-gluing-on-space

and I think I saw a speedup (anecdotal, not officially tested). If so,
then perhaps it is worth seeing if that part is useful, even when the
'peek' technique is more elegant than the sliding window technique.

PPPS: I see you use (protect) to ensure spool-processing is
uninterruptible by signals, but don't see file-locking of the
spool-file, to avoid race-conditions with the mail-server during
concurrent runs. Looking at:

 http://www.postfix.org/postconf.5.html#mailbox_delivery_lock

and based on the output of "postfix -l" it should be trivial to add
handling for its configured locking mechanism - just to avoid the
"once in a blue moon" garbling/disappearance of an email being
delivered during processing.

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens

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

Re: PilMCU status

[Rowan Thorpe]

On 18 April 2017 at 14:31, Alexander Burger <a...@software-lab.de> wrote:
> ..[snip]..
> > which only folds the next line of a multiline header if the existing
> > line ends with ";" and then chomps a single leading char, yet as far
> > as I understand it, RFC822 supports [A] folding based on (single or
> > multiple) leading TABs or spaces, [B] even if the preceding line
> > doesn't end with a ";" :
> ..[snip]..
> Indeed! This looks like a possible source of the problems.

According to the wording in section 2.2.3 at rfc2822 (supersedes
rfc822, but is probably the same anyway for this case):

 https://tools.ietf.org/html/rfc2822#section-2.2.3

I made an attempt at rewriting the header-folding to use a sliding
window method, it successfully passed a few crude "works for me"
quick-tests I threw at it, so I've attached the patches (against
v17.4.7). My picolisp-fu is rusty so there are probably more
elegant/efficient ways to write it. If you want to use any of it
you'll probably want to cherrypick what makes sense and ignore what
doesn't, but feel free to ask me to explain myself if in doubt. The
reading-to-the-end-of-the-"From " line was because I found I needed it
while testing against some /var/log/X files on my machine (to skip the
timestamp which appears on that line after the email address). It is
closely bound to the changed method logic so I kept it included in the
main patch rather than splitting it out. The other small patch is
because during testing (albeit against my Exim spool files which may
vary from your Postfix ones) I noticed that some emails which ended
without a blank line would end up with the final line half-overwritten
by the "-- ", because there would be a ^M without a corresponding ^J.

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
diff -Nu a/misc/mailing b/misc/mailing
--- a/misc/mailing
+++ b/misc/mailing
@@ -20,16 +20,21 @@
(quit "Bad mbox file") )
 (char)
 (while (setq *From (lowc (till " " T)))
+   (till "^M") (char) (char) # trim rest of line and "\r\n"
(off
   *Name *Subject *Date *MessageID *InReplyTo *MimeVersion
   *ContentType *ContentTransferEncoding *ContentDisposition *UserAgent )
-   (while (trim (split (line) " "))
-  (let L @
- (while (= ";" (last (last L)))
-(char)  # Skip TAB
-(conc L (trim (split (line) " "))) )
- (setq *Line (glue " " (cdr L)))
- (case (pack (car L))
+   (let (L (trim (chop (line)))
+ N (trim (chop (line)))
+ M (index " " L)
+ P (when M (head (- M 1) L))
+ L (when M (tail (- 0 M) L)) )
+  (until (not P)
+ (until (nand N (member (car N) '(" " "^I")))
+(conc L (cons " " (flip (trim (flip N)
+(setq N (trim (chop (line )
+ (setq *Line (pack L))
+ (case (pack P)
 ("From:" (setq *Name *Line))
 ("Subject:" (setq *Subject *Line))
 ("Date:" (setq *Date *Line))
@@ -39,7 +44,11 @@
 ("Content-Type:" (setq *ContentType *Line))
 ("Content-Transfer-Encoding:" (setq *ContentTransferEncoding *Line))
 ("Content-Disposition:" (setq *ContentDisposition *Line))
-("User-Agent:" (setq *UserAgent *Line)) ) ) )
+("User-Agent:" (setq *UserAgent *Line)) )
+ (setq M (index " " N))
+ (setq P (when M (head (- M 1) N)))
+ (setq L (when M (tail (- 0 M) N)))
+ (setq N (when N (trim (chop (line) ) )
(if (nor (member *From *Mailings) (= "subscribe" (lowc *Subject)))
   (out "/dev/null" (echo "^JFrom ") (msg *From " discarded"))
   (unless (setq *Sock (connect *SmtpHost *SmtpPort))
diff -Nu a/misc/mailing b/misc/mailing
--- a/misc/mailing
+++ b/misc/mailing
@@ -96,7 +96,7 @@
   (prinl "You are now unsubscribed^M")
   (prinl "^M^J^M") ) )
 (echo "^JFrom ")
-(prinl "-- ^M")
+(prinl "^J-- ^M")
 (prinl "UNSUBSCRIBE: mailto:" *MailingList "?subject=Unsubscribe^M")
 (prinl ".^M")
 (prinl "QUIT^M") ) )

Re: PilMCU status

[Rowan Thorpe]

On 18 April 2017 at 09:32, Alexander Burger <a...@software-lab.de> wrote:
> Hi Rowan,
>
> > mailing-list configuration - for some reason none of the recent emails
> > to the list from geo got through to me, but everyone else's did (I
> > read the thread on the list's web-archive OK, but it got me wondering
> > if any other emails never got through). Because the list-software
>
> Indeed something must be wrong with the mailing list. We observe rejected 
> mails
> rather often :(
> ..[snip]..
> In fact, everyone of us has the source of the PicoLisp mailing list server. It
> is in the PicoLisp distribution, e.g. in /usr/share/picolisp/misc/mailing, or
> locally in misc/mailing.

I just had a glance at the source and noticed one thing so will
mention it now, and will try to look/test more thoroughly later for
anything else. On lines 28-30 there is the "header folding" logic:

> (while (= ";" (last (last L)))
>  (char)  # Skip TAB
>  (conc L (trim (split (line) " "))) )

which only folds the next line of a multiline header if the existing
line ends with ";" and then chomps a single leading char, yet as far
as I understand it, RFC822 supports [A] folding based on (single or
multiple) leading TABs or spaces, [B] even if the preceding line
doesn't end with a ";" :

 https://tools.ietf.org/html/rfc822#section-3.2 (and see token-def in
section 3.3)

Looking through the source of various emails I've received from other
gmail/google-apps users I noticed they often have a mix of
multiline-header-continuations with leading SPACEs (multiple) and some
with leading TABs, and several are just folded on space without the
trailing ";" so it seems this isn't a theoretical edge-case...

Obviously chomping only one of multiple leading spaces/tabs probably
doesn't matter (other than for readability of mail-source), but only
matching the fold on a trailing ";" certainly does. I suspect that is
causing recipients' SMTP servers (and/or your own Postfix on
localhost) to reject my emails because I have SPF/DKIM configured on
outgoing emails, and those long headers often get folded on space
(without trailing ";"), which I guess short-circuits the header
processing and forwards the remainder of the headers as "the body". If
either the SPF or DKIM headers end up included in the final outgoing
mail they will cause a validation failure (SPF due to wrong sender,
and DKIM due to modified content).

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilMCU status

[Rowan Thorpe]

(geo: I just saw the video - great work!)

regenaxer: I suspect there is something subtly strange with the
mailing-list configuration - for some reason none of the recent emails
to the list from geo got through to me, but everyone else's did (I
read the thread on the list's web-archive OK, but it got me wondering
if any other emails never got through). Because the list-software
doesn't set SPF/DKIM headers, at first I thought it was just my spam
filters being overzealous, but his emails are not in my spam folder
either (yet older spam messages are still there, so they hadn't been
put there and then purged). Even though I never delete list-emails I
checked to see if I'd somehow accidentally deleted only his and no-one
else's(!), but they weren't in the "trash" either. Other people have
clearly received his emails via the list, so my guess is that Google
servers (and perhaps others) are bouncing certain list-emails - from
geo at least - for some obscure reason. Could you please check if your
logs show bounced messages with unusual responses? Can anyone
registered to the list with a Google Apps or Gmail address
confirm/deny they had the same problem?

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilMCU status

[Rowan Thorpe]

On 3 April 2017 at 06:57, Alexander Williams <a...@unscramble.co.jp> wrote:
> ..[snip]..
> I discussed this briefly in the chat, but I would like to know the current
> status of PilMCU (initial announcement here:
> ..[snip]..
> In any case, I think this project is very interesting and I would love to
> get involved with it.
> ..[snip]..
> running on actual hardware, I would be more than willing to pay for a simple
> devkit in order to hack on this.

I'll just throw in my +1 to all those points. I'd kept every PilMCU
email thread labelled "followup" for the same reasons. At risk of
triggering a long thread of content-less "+1"s, I think it is helpful
to point out that AW's request is not a one-off anomaly, but that
there are several of us out here *dying* to mess around with this, and
to help it reach such a usable point, in whatever ways we can, if we
can(?).

-- 
Rowan Thorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: duckduckgo

[Rowan Thorpe]

While searching old mailing list threads I re-discovered the one about
adding a picolisp bang command to duckduckgo, so I checked and saw
there isn't one yet - maybe because no-one submitted it, or it was
submitted but ddg never processed it. Anyway, I just submitted it a
little while ago, but got no confirmation email or anything other than
a "thanks!" flash-page, so will keep an eye on it and will notify the
list if it appears.

On 27 March 2016 at 10:07, Alexander Burger <a...@software-lab.de> wrote:
> Hi Mike,
>
> > 1. can somebody implement !picolisp ?
> > https://duckduckgo.com/bang
> > http://imgur.com/M9F0h1h
> >
> > 2. fun and advertisement
>
> Can probably be done, Requires a HTTP GET to
>
>http://picolisp.com/wiki/?home&*Search=foo

-- 
Rowan Thorpe
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: future?

[Rowan Thorpe]

[reply to beneroth regarding git-hosting so a bit off-topic for
picolisp, just to quickly say...]

On 10 March 2017 at 02:17,  <andr...@itship.ch> wrote:
> ..[snip]..
> GitHub:
> On 2017-03-01 GitHub introduced new Terms of Service (which you
> automatically accept by continueing to use their service)
> ..[snip]..
> Some projects already moved away from GitHub because of this.
>
> https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
> http://joeyh.name/blog/entry/removing_everything_from_github/

..many thanks for pointing this out (the new TOS seems to have gone
live 9 days ago). This sort of thing is why there was such a
long-winded debate on debian-devel mailing-list about migrating to a
git platform - but not to github, bitbucket, etc - not even to
gitlab.com (uses non-free enterprise-gitlab). I'd always felt mixed
about hosting F/LOSS on github (initially done as a shortcut around
the time/cost of setting up self-hosting), so I stealth-migrated my
repos to a few other platforms last year and then decided my real move
would be to self-hosted gogs, and in light of this news I'll push that
schedule rather than grokking github-legalese, so thanks. From what
Thorsten says in one of those links, it seems there's only an issue
for a github-hosted repo when commits are made after 1 March, which
gives a little wiggle-room for now, and luckily git makes migration
super-easy.

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

[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
<christop...@alaskasi.com> 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
> <https://www.gnu.org/software/repo-criteria-evaluation.en.html>.)
> 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: (= code data)

[Rowan Thorpe]

On 6 February 2017 at 20:03, Danilo Kordic <danilo.kor...@gmail.com> wrote:
> ..[snip]..
>
> Hi Rowan.
>
> [de help: [Sym Txt]
>   [def Sym 'help: Txt] ]
>
> [help: "`prop'erty is clearly better than a txt in `prg' if it should
> be extracted by a procedure.  "
>   [de help [Sym]
> "I prefer even this over Reader Comments (``#'').  "
> [get Sym 'help:] ] ]

Thanks for that, Danilo. I was a bit confused for a while though
because (I think?) there is a typo in it - it doesn't work for me
as-is. Anyway, your pointing out the use of a property on the function
made sense. I managed to get a version of it working which I like (see
below), particularly because it makes passing in "lambdas" trivial as
a single arg, and is easy to visually parse with that in mind). I
guess the main benefit of using the property-approach is that it won't
have any speed impact on the function when it runs, whereas including
a "docstring" like I was doing will cause the string to be silently
"evaluated" every time the function is run... Just out of curiosity,
is that the main/only reason? or are there other reasons I haven't
thought of? BTW: The version I came up with is:

8<

(de hde (Sym Txt Fn)
   (def Sym Fn)
   (def Sym 'help: Txt) )
-> hde

(hde 'help "This is the help function"
   '((X) (get X 'help:)) )
-> help

(hde 'tester "This is the tester function"
   '((X) (println X)) )
-> tester

(help 'tester)
-> "This is the tester function"

(tester 123)
123
-> 123

8<

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

REPL in the browser, picolisp as primary example/screenshot

[Rowan Thorpe]

I wrote a little proof-of-concept tool to embed an arbitrary REPL in
the browser using websocketd in the backend - nothing particularly
clever or high-profile about that, I know - but more relevant here is
that I used picolisp (pil) as first example, and in the first
screenshot :-)

  https://github.com/rowanthorpe/ws-repl

The websocketd project links to it as an example project too, so
hopefully some of the Go fans browsing there will end up discovering
picolisp that way...

  https://github.com/joewalnes/websocketd#user-content-example-projects

BTW: Maybe a heavily sandboxed, rate-limited picolisp with a strict
reset-timeout could be included this way in a "Try it online here!"
section on the picolisp.com homepage? If the site is hosted on
standard web-hosting rather than a VPS then the websocket process
would require hosting separately with cross-site protection and/or
firewalling of its port, though. Then again, due to extra load on the
server and potential security holes (extra maintenance burden) it may
not be worth it at all. Anyway, just an idea...

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

Re: (= code data)

[Rowan Thorpe]

On 27 December 2016 at 20:03, Lindsay John Lawrence
<lawrence.lindsayj...@gmail.com> wrote:
> This little gem was an epiphany in my understanding of the equivalence
> of code and data in lisp.
>
> https://rosettacode.org/wiki/Jump_anywhere#PicoLisp

:-) Another nice/simple way to demo Picolisp's homoiconicity is by
implementing "docstrings"
within a small function :-) See here for an example:

 
https://github.com/rowanthorpe/taskwrangle/blob/b14e2fe47a9e03f025442941b2867eb122cefa8b/lib/libtaskwrangle.l#L252

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: FreeBSD 11

[Rowan Thorpe]

I myself, on all my platforms -- be they desktop,
> laptop, server, it doesn't matter -- use scripts (actually one script
> in this case) to install even something as "small" as picolisp:
> https://github.com/cryptorick/pilot.  Even though the standard
> picolisp build is freakin' dead easy, I have other configuration
> tweaks that I require to be accomplished pre- and post-build/install,
> and I have assurance that "my bases are covered" if I use a script.
> So, I'm not telling you to do something that I don't do myself. ;)

I have also had to get my hands way too dirty with such things, like
"auto-rebasing patches on upstream applications and deploying to live
servers" (https://github.com/rowanthorpe/quintain), "auto
installing/configuring an IXP Manager"
(https://github.com/rowanthorpe/ixpm-autoinstall), "configurable
Heroku-style server provision & deployment on arbitrary cloud
providers" (in-house, haven't made it public yet), and
auto-installing/upgrading OpenResty stack & Kong on a bare VM (another
in-house thing I will make public soon). I am deeply interested in me
and others gaining the freedom to do less of such things, especially
when it involves reinventing wheels. Every bit (especially packaging)
helps reduce that load.

> ..[snip]..
> 2. NFSN is (a FreeBSD-based) one that allows the user to build/install
> their own software; there are probably others.

That is my (personal) webhost since 2010 :-) Best webhosts ever. One
reason I want to get picolisp in-tree, and to convince them to
officially support picolisp, is to then convince them to support it
with their NFGI script-acceleration, to eliminate the
interpreter-per-request situation entirely.

Also, regarding the sub-thread about "barrier to entry": I wasn't
thinking as much about barriers due to lack of knowledge or
experience. I was primarily (but not exclusively) referring to
barriers due to lack of time - which is usually *more* the issue for
experienced programmers than for the inexperienced ones.

Cheers,
-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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: FreeBSD 11

[Rowan Thorpe]

On 11 October 2016 at 16:03, Mike Pechkin <mike.pech...@gmail.com> wrote:
> ..[snip]..
> I have PIL on every OS it supports, except IRIX.
> I can update or patch or compile PIL very fast without walls.
> Nobody stay between me and Lisp. Freedom is not for free.

I agree for personal use, and it is what I presently do on my webhost
and personal VMs, but for use at large scale it means duplication of
effort, risk of inconsistencies from doing manual steps, barrier to
entry for new users, less exposure for Picolisp to potential users,
etc. Also, due to the need for auditability and extreme scale with no
maintenance-overhead my webhost would never agree to manually
compile/install Picolisp to their public systems from upstream source
(and definitely not repeatedly for each new release). They would only
consider installing a stable package from the "Ports tree", hence why
I am looking for that.

> ..[snip]..
> As ports ex-maintainer I'would say - you dont need port for PIL, this is
> jail and step backward.
> ..[snip]..

When you say you are an ex-ports maintainer, do you mean in general?
or of a Picolisp Ports-package in particular? If the latter, could you
please point me to the last version of the packaging you maintained
(if there was no maintainer after you), or to the version maintained
now (by whoever maintains it now, out of tree)? Having tinkered with a
few Gentoo ebuilds over the years (with Portage's similarity to Ports)
and with superficial FreeBSD familiarity as a "user", I am trying to
gauge if I could/would want to take on maintaining packaging for it in
Ports, and whether that exists in some form already, or would need
creating.

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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: task db example

[Rowan Thorpe]

On 3 October 2016 at 18:49, Alexander Burger <a...@software-lab.de> wrote:
> ..[snip]..
>
> For
>
>(if (= (type Item) '(+Task))
>
> I have a minor suggestion:
>
>(if (isa '+Task Item)
>
> This is more general, and would survive inheritance.
>
> ..[snip]..
>
> BTW, Joe's exact name is Bogner ;

Thanks for both important corrections (applied)  :-)

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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: task db example

[Rowan Thorpe]

I finally tidied-up and uploaded the task-manager tool I created last
month, based initially on Joe Bognor's wiki-page demo-app (for which I
asked on this list about copyright for the wiki-pages - there were
speculative answers/suggestions, but not a conclusive one yet...):

  https://github.com/rowanthorpe/taskwrangle

I don't get to work often with picolisp, so probably did some things
sub-optimally - feedback welcome!

The quickest way to see what it does is to scan the func-defs in the
lib-file, but here's an overview:

fields:
 * number
 * name
 * priority
 * tags
 * due
 * parent
 * children
 * blocks
 * blockedby
 * comment

functionality:
 * add/destroy/modify tasks
 * return/display tasks:
   - select by field-matches/ranges
   - sort/reverse-sort by field
   - display specific or all fields
   - show raw task-objects or task-numbers in linked fields
 * help output (per-function or all, based on home-cooked docstring system)
 * frontend wrapper funcs like (isdone), (rename), (unparent), etc...

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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: Unexpected behaviour from (sort) with

[Rowan Thorpe]

On 30 September 2016 at 20:24, Alexander Burger <a...@software-lab.de> wrote:
> Hi Rowan,
>
> the explanation is simple.
> ...
> It is the *return* value of 'sort' which is relevant:
> ...

Ah, [facepalm], thanks. Because I hadn't used picolisp for a while,
when I first used (sort) again in a new context I saw the altered (but
not NIL) initial ("A") value before paying attention to the
return-value, and was so convinced that it must be the meaningful part
- and that (sort) must be "destructive and in-place" - that I never
even looked at sort's return-value (or noticed that the documentation
shows its return-values). Ironically picolisp code of mine from 2
years ago uses it correctly [sigh]. I suggest it might be more useful
for newcomers, for people-with-terrible-memory, and for
people-who-have-to-do-too-much-context-switching (like me) if the
first sentence at http://www.software-lab.de/doc/refS.html#sort
changed from:

> Sorts lst by destructively exchanging its elements.

to something more explicit like:

> Returns a sorted lst by destructively exchanging the original lst's elements.

I realise the examples implicitly show the "returns..." part of this,
but it is easy to get distracted from that by the initial "lst" being
transformed (but not NIL-ed) in such initially surprising ways. I
guess there may be other "destructive but not in-place" functions
whose documentation this suggestion could be relevant to as well. Of
course you might feel that is being too verbose in order to pander to
the n00bs and the forgetful though...

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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

Unexpected behaviour from (sort) with transient-sym-with-leading-numeral-in-cdr

[Rowan Thorpe]

I have a perplexing situation with the (sort) function sorting
alphanumeric elements, and can't find any explanation in the
documentation after searching for a while. Unless I am
misunderstanding some painfully fundamental point, this appears to be
a bug.

When I try to sort alphanumeric transient-syms it seems that the
(sort) function bails out early as soon as it hits an element from the
CDR with leading numeral (I guess it is internally attempting to
transform each transient-sym to an internal-sym as it iterates through
the CDR, which won't work for e.g. "3a"), and then it seems to quietly
return one of the halved partitions being internally constructed by
the mergesort algorithm rather than erroring out loudly. I would
expect that:

 * sorting alphanumerically would be possible (leading numbers before
letters), as e.g. (< "3a" "a") and (< "a" "3a") in isolation both work
as expected
 * if it is going to fail it should make it clear that it is failing
rather than "successfully" presenting an incorrect (and initially
baffling) result

The same happens whether assigning A inside (let) or assigning A
beforehand with (set). I am using 64bit (assembler) picolisp v16.7.17
(Debian package). Please let me know if you need more information (or
if I'm an idiot and just didn't understand something). Example
fail-scenarios are below:

> # -- "sort"
> : (let (A '("t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort A) (println A))
> ("t" "z" "q" "a" "3a" "x3" "3")
> ("t" "x3" "z")
> -> ("t" "x3" "z")

> # -- "sort <" [same as above, with implicit < sort-function]
> : (let (A '("t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort A <) (println 
> A))
> ("t" "z" "q" "a" "3a" "x3" "3")
> ("t" "x3" "z")
> -> ("t" "x3" "z")

> # -- "sort >"
> : (let (A '("t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort A >) (println 
> A))
> ("t" "z" "q" "a" "3a" "x3" "3")
> ("t" "q" "a" "3a" "3")
> -> ("t" "q" "a" "3a" "3")

> # -- "sort with CAR-with-leading-numeral"
> : (let (A '("4b" "t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort A) 
> (println A))
> ("4b" "t" "z" "q" "a" "3a" "x3" "3")
> ("4b" "a" "q" "t" "x3" "z")
> -> ("4b" "a" "q" "t" "x3" "z")

> # -- "sort > with CAR-with-leading-numeral"
> : (let (A '("4b" "t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort A >) 
> (println A))
> ("4b" "t" "z" "q" "a" "3a" "x3" "3")
> ("4b" "3a" "3")
> -> ("4b" "3a" "3")

> # -- "sort quoted list" [doesn't do anything at all]
> : (let (A '("t" "z" "q" "a" "3a" "x3" "3")) (println A) (sort 'A) (println A))
> ("t" "z" "q" "a" "3a" "x3" "3")
> ("t" "z" "q" "a" "3a" "x3" "3")
> -> ("t" "z" "q" "a" "3a" "x3" "3")

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"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: task db example

[Rowan Thorpe]

On 24 August 2016 at 16:08, Joe Bogner <joebog...@gmail.com> wrote:
> Some discussion on irc this morning prompted me to create a simple example
> showing how to interact with the db directly.
>
> I posted it to the wiki and am sharing it here in case anyone would benefit
>
> http://picolisp.com/wiki/?taskdb

This is a great example of an intuitive "on-ramp" for a concept which
can feel a bit opaque when reading reference-text, but becomes much
simpler with the "learn by doing" approach. Thanks so much for this.

I got enthusiastic while experimenting with it yesterday, and ended up
adding various features and functionalities to the point that I have a
real-world mini-app (usable for my purposes at least, without the
over-engineered "platform" effect which usually makes me stop using
other solutions due to lack of time/cognitive-bandwidth). I will
upload it but first want to credit the demo-app appropriately as
original source. How is stuff posted on the wiki copyrighted/licensed?
Public Domain? GPL?

-- 
Rowan Thorpe
http://twitter.com/rowanthorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Gorlansky lisp book, 800+ tasks

[Rowan Thorpe]

On 27 August 2015 at 13:43, Henrik Sarvell hsarv...@gmail.com wrote:
 Can the book be freely accessed somewhere so that it's possible see the
 descriptions of the tasks that you solved?

He included a (756 page!) lisp20150507.pdf in that repo, which
appears to be the book in question. It is all in Russian and I very
much doubt Google Translate will handle it in one copy-paste though...
:-/

-- 
PGP: BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD
There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem. - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Eurolisp April 2015 (would love to see something picolisp-related there)

[Rowan Thorpe]

This is a quick heads-up and a question:

I am presently deciding about attending the Eurolisp conference in
April (London) and it occurred to me that:
 (A) If there will be any representation of Picolisp there (talk,
lightning talk, attendees..?) I would have much more reason to go, and
 (B) Especially with all the recent news-worthy developments of PilMCU
it would be a missed opportunity if a talk wasn't presented there for
that. If it is, please let me know and I'll be in the front row...

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

There is a great difference between worry and concern. A worried person sees a
problem, and a concerned person solves a problem. - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: A Minimal PicoLisp DB/GUI Application, Telephone field

[Rowan Thorpe]

On 2015/01/14-14:37, Luis P. Mendes wrote:
 Hi,
 
 2015-01-14 12:09 GMT+00:00 Alexander Burger a...@software-lab.de:
 
  I see. So Norway has different systematics with telephone numbers.
 
  I don't understand them, though. In Germany we have the rule that both
  0049 123 456 and +49 123 456 are the same as 0123 456.
 The 00 to + conversion is of no problem, but the 0 leading local or
 domestic numbers seems to be a feature of some countries, but not of
 others.

There are even more variations though, including for international calling
code:

 from Australia: 0011 + country code + area code + ...
 from USA: 011 + country code + area code + ...

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

There is a great difference between worry and concern. A worried person sees
a problem, and a concerned person solves a problem.
 - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: A Minimal PicoLisp DB/GUI Application

[Rowan Thorpe]

On 2015/01/12-08:34, Alexander Burger wrote:
 Hi all,
 
 perhaps this is useful:
 
A Minimal PicoLisp DB/GUI Application
 
http://picolisp.com/wiki/?minDbGui
 
 ♪♫ Alex

Such clear, precise and informative little gems like this are why I am a fan of
picolisp (the language and the implementation). FWIW: I am subscribed to *many*
mailing lists, but I think the picolisp list is the only one I actually read
every single message from.

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

There is a great difference between worry and concern. A worried person sees
a problem, and a concerned person solves a problem.
 - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Bug building on Hurd (trivial fix?)

[Rowan Thorpe]

A long while ago I bookmarked this build failure of picolisp on Debian
hurd-i386:

 https://buildd.debian.org/status/package.php?p=picolisp
 
and it looks like an OS-independent issue, and seems to be trivially fixable,
according to:

 https://www.gnu.org/software/hurd/hurd/porting/guidelines.html 
 - under Undefined bits/confname.h macros (PIPE_BUF, ...)

(albeit requiring context-dependent ifdefs). Since I saw the issue I haven't
had time to setup a Hurd build environment to actually write and test a
patch. Rather than putting it off for another year, or writing a best guess
patch and opening it as a bug-with-patch on the Debian BTS, I figured it is
simpler and faster to post about it here - so if anyone else finds the time,
and if the fix really is that simple, it can help all users more quickly.

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

There is a great difference between worry and concern. A worried person sees
a problem, and a concerned person solves a problem.
 - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp on Raspi

[Rowan Thorpe]

On Fri 19 Sep 2014 15:47, Jakob Eriksson wrote:
 On September 19, 2014 at 3:18 PM Joe Bogner joebog...@gmail.com wrote:
  This might be off base, but is it within the realm of possibility to
  run PilMCU on a raspberry pi now or in the future? That's an accessible
  piece of hardware that many people already have (myself included). These
  people may also be willing to fund the work

 Raspi runs linux, so you can run PicoLisp on it right now. PilMCU is about
 new hardware chips.
 You could of course go the middle way, that could attract some attention:
 port PicoLisp to bare Raspberry Pi hardware. Also an interesting prospect.
 But the ARM cpu in the pi is not a natural fit, it is not 64 bit, only 32.
 So it would be more of a promo thing. But very cool in its own right.

Strange this came up just now - I am a long-time stalker on the mailing list,
and had been brewing the idea for a long time to get the ball rolling for a
Picolisp equivalent of this:

 http://common-lisp.net/project/movitz/movitz.html

and ultimately perhaps one day a picolisp-based kernel, and maybe even a
predominantly picolisp-OS (...I like to dream big).

I am for sure much more excited about this latest picolisp-machine announcement
though (LISP machines are back! Their time has come! Mwahahahaha!), but there
is probably still a good reason to also go the middle way too, for the
reasons already mentioned - to gain attention and to do meaningful performance
comparisons to existing software.

FWIW: I am totally up for contributing to PilMCU, RasPicolisp or Picolix86_64p
  in any way that I can. Count me in.

--
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

There is a great difference between worry and concern. A worried person sees
a problem, and a concerned person solves a problem.
 - Harold Stephens
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: kill without 'KILL does not work for PicoLisp processes

[Rowan Thorpe]

 On Wed, 17 Jul 2013 09:22:14 +0200
 Thorsten Jolitz tjol...@gmail.com wrote:
 
 ..[snip]..
 I ran into this problem when experimenting with the
 web-framework and my app got into a bad state. When restarting then,
 PicoLisp tells me something like 'Port is already used', so I tried
 to kill the still running (*) PicoLisp processes with a simple 'kill
 PID', but to no avail.
 
 [* are they still running? 'ps' shows them with a '?', and I
 shutted them down on the command-line, so they shouldn't. But somehow
 they still block the port, and the more I shut down, the more are
 shown by 'ps']
 ..[snip]..

Sorry for asking the obvious question, but have you waited the couple of
minutes needed for the kernel (depending on which kernel) to eventually
clean orphaned ports itself? It *may* actually just be the port
remaining open because the owning process didn't cleanly shut it?: as
mentioned here http://superuser.com/a/127865
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: kill without 'KILL does not work for PicoLisp processes

[Rowan Thorpe]

 On Wed, 17 Jul 2013 16:14:11 +0700
 Henrik Sarvell hsarv...@gmail.com wrote:
 
 When developing web apps I keep the code for the server and the rest
 separate and reload the rest on every request. No need for restarts
 at all that way.
 
 Unless you're actually fiddling with the actual server code, then it
 can't be helped I suppose...

..for such times (and for those times that you generally can't be so
organised), there is the sledgehammer approach - SO_REUSEADDR
http://stackoverflow.com/questions/775638/using-so-reuseaddr-what-happens-to-previously-open-socket
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: kill without 'KILL does not work for PicoLisp processes

[Rowan Thorpe]

 On Wed, 17 Jul 2013 12:56:35 +0200
 Alexander Burger a...@software-lab.de wrote:
 
  On Wed, Jul 17, 2013 at 01:28:59PM +0300, Rowan Thorpe wrote:
  ..for such times (and for those times that you generally can't be so
  organised), there is the sledgehammer approach - SO_REUSEADDR
 
 Why sledgehammer approach? This is quite normal, as I see it.
 
 The PicoLisp network functions always set this socket option.
 
 ♪♫ Alex

:-D

I didn't mean that SO_REUSEADDR *is* a sledgehammer. I just meant that
when all else fails it can be used with a decidedly sledgehammer
mentality i.e. I don't know what is killing my process and don't have
time to find out right now, I just need it to start again and talk to
the outside world ASAP...
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: How to set IP address for socket?

[Rowan Thorpe]

  Thanks! The 'make' went fine now. However, when I try to run my web
  app now, I get IP bind error: Address already in use. ;-)
  I think I may have to bother C9 Support again.
 
 Ah, but perhaps this is (partially) good news, because it seems to
 have taken the address! :)

Just throwing in an observation in case it hasn't already occurred
to you - the Address already in use error might well not be a picolisp
or C9 problem at all, but that you are reconnecting to the socket
without having set the SO_REUSEADDR option (or equivalent). Without it
you can't reconnect to an already connected socket, e.g. for about 90
seconds on Linux, or similar duration on other platforms (must wait
for OS to release socket based on its own view of things).

If that is totally unhelpful or irrelevant then sorry for the
line-noise ;-)

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

Re: How to set IP address for socket?

[Rowan Thorpe]

 Alexander Burger wrote:

 I see. So my proposal of calling inet_pton() was not correct :(

 I have no idea at the moment. Somebody (me?) must dig into TCP
 networking (again). Haven't touched that for a while.

Jon,

I think I might have found an explanation for the already bound
error, and if it is this, then the error is not very appropriately
worded (it might actually be a propagated inet_pton syntax error). On
the inet_pton manpage I found this:

   BUGS:
   AF_INET6 does not recognize IPv4 addresses.  An explicit IPv4-mapped
   IPv6 address must be supplied in src instead.

Hopefully someone will get around to fixing that one day (I would have
thought it would be a trivial fix...?!). The ipv6 address space is a
(128bit) superset of the (32bit) ipv4 space anyway, so I don't see a
reason *against* handling that syntax too...

What happens if you do the same steps in the last version Alex told
you to do, but instead of:

  : MyIpAddr asciz 127.6.26.129

you put the ipv6-mapped address for it:

  : MyIpAddr asciz :::127.6.26.129

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

Bug reports?

[Rowan Thorpe]

Sorry if I am posting this to the wrong place (if so, please let me
know where is the right place). I am trying to report a bug in the
latest version of the picolisp-wiki, and can't find where to do that
(there is one page on the wiki which appears unused).

Anyway, in case this is the right place, there are two calls to a
(passwd) function -
  wiki/init.l line 16
  wiki/user.l line 22

I have a standard install of the latest picolisp, socialshareprivacy,
and jquery on a debian system, and the wiki tells me that passwd is
unidentified. It prevents it setting the initial admin password, and
when I brute-force overrode that, it has a problem again when I try to
change passwords.
-- 
Rowan Thorpe
http://identi.ca/rowanthorpe
http://twitter.com/rowanthorpe
http://www.rowanthorpe.com
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Subscribe

[Rowan Thorpe]

Hello Rowan Thorpe ro...@rowanthorpe.com :-)
You are now subscribed


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