newLISP Fan Club

Au contraire I, at gmail.com, got the notification email from this forum today. Which is great. Something got improved ...

Thanks @itistoday!! Great to be at a new forum home.

Here's a pointer to a few of my newlisp projects

Most of them are functional, but generally they are for fun.

Eh? Doesn't your ISP provide rDNS setup?

EDIT: it's not related to email as such, and I agree that setting up your own MTA would be too much.

EDIT 2: not sure if relevant:
https://clientarea.ramnode.com/knowledgebase/19/How-do-I-set-reverse-DNS-RDNSorPTR.html

Well, I'm not trying to support any of Google's business practices; just trying to assist in getting the forum emails delivered to @gmail.com addresses (especially since I happen to have one).

And for that I believe it would be good getting the rDNS sorted for newlispfanclub.com.

Yes, the MTA setup would be fine, but afaik gmail will want the original sender (newlispfanclub.com) to have rDNS set up (as well), especially for resolvable hosts "without history".

Ah; I looked up rDNS for 168.235.93.184 and got 168-235-93-184.cloud.ramnode.com rather than newlispfanclub.com, which would be the origin of an email.

This morning I got a blurb here about the pains of sending emails to addresses @gmail.com, detailing a bit about how finicky they, Google, are.

Whilst that is true, I've held this email address some 20 years mostly because their spam filtering has been quite outstanding. During that time I have set up some number of MTA (typically small and smallish ones), and like apparently this forum, come to realize both that in order to deliver to @gmail.com addresses all the "ducks" need to be in perfect order, and that getting attention and assistance by Google staff to figure out the "ducks" is near impossible.

This forum is close to perfect in its setup apart from lacking its reverse DNS setup, which I believe is one of the "ducks", i.e. one thing that @gmail.com is finicky about.

(And if it'd be of any help. I'm more than happy to be a trial target for MTA configuration trials.)

maybe check out

https://web.archive.org/web/20230000000000*/http://www.newlisp.org/downloads/manual_frame.html">https://web.archive.org/web/20230000000 ... frame.html">https://web.archive.org/web/20230000000000*/http://www.newlisp.org/downloads/manual_frame.html

I'm confused about why you appear confuse... of course (string ""a""b"") is the same as (string ""   a   ""  b  ""); the string function packs together the stringifying of its arguments ignoring any (optional) whitespace between them. No strangeness involved afaict.

.. and you should dazzle me with the code as well :)



I had a hard time avoiding brute-force, which I thought too boring, but then it started to take too much time for me so I gave up.



Ralph.

Yes it's a bug in the handling of the "incoming cell data" for an ffi_type_float at nl-import.c:814.

That current line is

Code Select Expand

floatV = (float) *(double *)&cell->aux;
and should be replaced with the following

Code Select Expand

floatV = (float) ((cell->type == CELL_FLOAT)? *(double *)&uint64V : uint64V);
which corresponds to how it's handled in the pack function.

My fully repeatable test is:

Code Select Expand

> (push x x)
(?)
> (x 0 0)

ERR: list reference changed
> x

Same behaviour in "newLISP v.10.7.5 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h"

tried to edit, to wrap the sym term into an eval, but the server doesn't let me...

1) a "hashmap" is a context without default functor, i.e.

Code Select Expand

(and (context? S) (nil? (sym (term S) S nil)))

2) using the symbol as functor results in its list if entries, i.e.

Code Select Expand

(apply S)