<Regenaxer>
As for "JS, pick VERY carefully", very true
<beneroth>
there are some other good (short) lists further down
<beneroth>
haha
<beneroth>
of course this one applies: "No-maintenance software must live in an environment which never changes (certain microcontroller code, and kiosk-type installations fit this definition)."
<Regenaxer>
Well, we both don't agree that nosql is bad
<Regenaxer>
T
<beneroth>
well, depends if you mean NoSQL as in "not sql", or NoSQL as in "hyped databases which leave most of the database implementation to the application using it"
<beneroth>
hm
<beneroth>
damn, the second kinda applies to pil though xD
<Regenaxer>
yep
<beneroth>
but not as in "no implementation exist" (e.g. most "NoSQL"-DBs lack transactions)
<Regenaxer>
it is a wide field
<beneroth>
yeah
<Regenaxer>
can't be covered with simple statements like that
<beneroth>
and pilDB is only not a pure graph-db or such, pilDB doesn't really fit the established categories, it's multi-paradigm
<Regenaxer>
In any case, we agree about simplicity
<beneroth>
T
<Regenaxer>
I see again in the llmm irc channel
<beneroth>
over-engineering is a big issue, only restricted by self-discipline
<beneroth>
yeah?
<Regenaxer>
A build seems to take soo long that a bot anounces it every time a build finished!!!
<beneroth>
a bot creates a ticket, because a dependency changed.
<beneroth>
a second bot merges the change.
<beneroth>
a third bot motivates them with some internet picture.
<Regenaxer>
uh
<beneroth>
then humans find out the existing test don't work anymore, because of the change. the dependency version number (semver.org) indicated "no breaking change", and the bots trusted this without tests
<Regenaxer>
horror
<beneroth>
we need more AI in development!!!
<beneroth>
:D
<Regenaxer>
Not "artificial", but human I
* beneroth
was in favor of semver scheme a while, but now I believe it's just a nice dream, you can never now if the version number issuer really has the discipline (or understanding) to do it properly. only safe way is proper tests.
<beneroth>
well the problem with secure and safe AI is that the problem is not really solved with natural intelligence. humans become more peaceful (it even seems we self-select for this for thousand of years and intelligence might be primarily a byproduct of that), but we still screw up a lot :)
<beneroth>
the picolisp way as I understand as trying to optimize the way for flexibility, instead of attempting to get around obstacles by finding another way (which will have obstacles again!) and making rules with too many exceptions.
<Regenaxer>
correct
<beneroth>
JS seems to have gone the other extreme, whenever someone has an issue they create a new JS library, like every week or so. and of course that new library will not solve everything.
mtsd has joined #picolisp
<mtsd>
Good morning everyone!
<Regenaxer>
Hi mtsd!
<mtsd>
Hi Regenaxer!
<mtsd>
Working on pil21?
<Regenaxer>
Yes, from time to time :)
<Regenaxer>
Still exploring the limitations of LLVM-IR
<Regenaxer>
A lot more tedious than PilAsm
orivej has joined #picolisp
<mtsd>
A bit frustrating?
<Regenaxer>
Not at all, interesting
<mtsd>
Good to hear.
<mtsd>
It will be interesting to see how it develops
<Regenaxer>
ok :)
<Regenaxer>
"tedious" is the wrong word
<Regenaxer>
less flexible
<Regenaxer>
more like C in this regard
<mtsd>
I see
<tankf33der>
Regenaxer: you use only llvm-ir manual, right?
<Regenaxer>
main.bc was made new? Or is it from tgz?
<tankf33der>
as is
<tankf33der>
indeed
<tankf33der>
let me regenerate
<tankf33der>
regenerate on llvm9 the same
<Regenaxer>
Perhaps main.bc is not so system-independen as I hoped
freemint has quit [Ping timeout: 276 seconds]
<Regenaxer>
Transients read/print work now
<jcowan>
Regenaxer: I don't mean arrays as a new datatype. They would still be lists, just allocated in a physically contiguous block of cells instead of from the free list. So the *only* new operations needed are make-vector, vector-ref, and vector-set! (only with more picoish names)
<jcowan>
So they would take 2x the space of C arrays, but have the O(1) performance that array users want.
<Regenaxer>
I see, ok, and use indexing access functions
freemint has joined #picolisp
<Regenaxer>
But you must prohibit manipulation functions on them
<Regenaxer>
i.e. 'con' or 'conc', as this would break it
<Regenaxer>
And how to tell the system to build such list?
<Regenaxer>
You can't use normal cons, list, mapcar or make
<Regenaxer>
I think this oqens a can of worms :)
<Regenaxer>
As I wrote in the above article, worrying about O(x) performance is preliminary optimization
<Regenaxer>
Short lists won't gain, and long lists are better handled in other data structures
<jcowan>
I thought the pico attitude was "If you break it, that's your fault"
<Regenaxer>
e.g. database
<Regenaxer>
yes, but even more important is "keep it simple"
<Regenaxer>
Here we would introduce new *concepts*
<Regenaxer>
and rather hard to understand concepts
<Regenaxer>
i.e. when is such a list existent so that we can index it
<Regenaxer>
You are right tha such a list could be easily created
<Regenaxer>
For example by taking a fresh heap chunk
<Regenaxer>
(make-linear 1000) ?
<Regenaxer>
Then how to fill it?
<Regenaxer>
And you can't really use it
<Regenaxer>
For example, Vip holds text in a list of lists
<Regenaxer>
each line a list
<Regenaxer>
So a large file may give a list of hundred thousand lines
<Regenaxer>
But if that list were linear, it would be useless for editing
<Regenaxer>
You need to insert, delete etc. stuff all the time
<Regenaxer>
Quickly the linearity is gone
<freemint>
Is there a messahe store (IMAP or POP server) written in PicoLisp?
<freemint>
Ok, thanks. I was speculating about writting a ticketing system. IMAP seems very friendly towards a LISP implementation (some parts of the protocal are 'pretty s-expr). Having people check the ticketing system from their mail client would be a cool feature.
<freemint>
This begs a question though. I know how i can have a family listen to one port (see chat, or http.l) but how can i have a family listen on two different ports?
<Regenaxer>
You could have each child listen at a different port
<Regenaxer>
or use 'task's and 'accept'
<Regenaxer>
But it always needs a 'listen' initially I think
<Regenaxer>
No, should work, just 'port'
<freemint>
If i have a child listening at each port the process which handle sockets/sessions would no longer be in the family of first process (from which the per-port processes are forked)?
<Regenaxer>
I would expect each child to handle its socket
<Regenaxer>
otherwise you can 'tell' another process
<Regenaxer>
(same family)
<Regenaxer>
or named sockets (fifos) if non-family
<freemint>
Doesn't that mean only one person can be connected to the http or the imap port at the same time?
<Regenaxer>
yes, but extremely short time
<freemint>
mhh would that prevent me from using (app)?
<Regenaxer>
no
<Regenaxer>
In Http servers you have the same. One process listening on a single public port
<Regenaxer>
then dispatches
<Regenaxer>
(app) is called by child processes
<Regenaxer>
they don't interfer with the listening process
<freemint>
So we have a Grand parent which opens the database, parents which listen on a port, and childs forked from those parents which handle a socket and call (app) if necessary?
<Regenaxer>
No grand parent, only a normal parent
<Regenaxer>
Like the http setup, no?
<freemint>
Yeah but the http setup only listens on one port and i am thinking listening on a port for sockets is blocking so i could never check both?
<Regenaxer>
yes, true, unless you have two 'task's
<freemint>
I never understood 'task or '*Run
<Regenaxer>
It is just a front end to select(2)
<Regenaxer>
or poll(2) which is the same system call
<freemint>
How does select work?
<Regenaxer>
It listens at an arbitrary number of file descriptors (not only sockets)
<freemint>
And what does it do if some data is given to a FD?
<Regenaxer>
if data are available at one or severl FD's, select returns
<Regenaxer>
man 2 select
<freemint>
thanks
orivej has quit [Ping timeout: 240 seconds]
Blue_flame has joined #picolisp
<jcowan>
Regenaxer: I know I'm a newb here and I don't want to be a nuisance.
freemint has quit [Ping timeout: 245 seconds]
<Regenaxer>
No worry! Not a nuisance at all!
<Blue_flame>
I tried to compile pil21 on 32bit android termux. Unfortunately get this error: LLVM ERROR: Don't know how to emit this value.
<Regenaxer>
tankf33der also had a strange error on 32 bit Linux (today, above)
<Regenaxer>
I tested only on 64 bit so far
<Regenaxer>
Termux/Android mainly
karswell has joined #picolisp
<Regenaxer>
but sometimes on Debian
<Blue_flame>
Yes, i saw that hence reported the issue. If it could help. Not as portable as one would think!
<Regenaxer>
yeah
<Regenaxer>
thanks!
<Blue_flame>
Welcome!
<Regenaxer>
Would be great if it ran on 32 too
<Regenaxer>
We will find :)
<Blue_flame>
Eventually, till next year :D
<Regenaxer>
yep, till 21
<jcowan>
What I'm talking about is a mental set: I trade off the ability to freely mutate the cdrs of the pairs in such a list for fast access to the cars.
<Regenaxer>
yes
<Regenaxer>
But then, as I said above, the operations on this list are very limited
<jcowan>
To answer your specific question, once you have allocated a linear list, you can put things in it by ordinary list mechanisms, or by the fast path. You can't use it for things like keeping a list of lines in an edit buffer, but for example you can use it for an efficient hash table among many other data structures.
<jcowan>
Most operations on a list don't mutate the list at all.
<Regenaxer>
In the editor it would be useless, as it modifies the list
<jcowan>
I haven't counted how many "mutate the cdr" operations there are in pico, but I bet the number is not *that* large.
<jcowan>
Yes, as I say that is not an application for a Lisp array.
<Regenaxer>
Mutating cdrs are destructive operations, yes, not so many
<jcowan>
But to make an O(1) hash table you need an O(1) array of buckets, and you never mutate the cdrs.
<Regenaxer>
But you also cannot operat on the list normally
<jcowan>
How so?
<Regenaxer>
Vip for example operates nondestructively
<Regenaxer>
as it does undo/redo
<Regenaxer>
Still the top-level list changes all the time
<Regenaxer>
'append' 'delete' 'replace'
<Regenaxer>
non-destructive
<Regenaxer>
but producing new lists all the time
<Regenaxer>
these lists are connected and chained
<jcowan>
vip is the editor?
<Regenaxer>
The powerful thing is Lisp is that it produces lists all the time
<Regenaxer>
yes
<Regenaxer>
You map over lists and produce new ones
<Regenaxer>
Wont work in such a static global setup
<Regenaxer>
Vip is my primary editor, @lib/vip.l
<jcowan>
A few additional operators like vector-map would certainly be handy (same as map except it gets the length of the input first and then does a make-linear to create the output), but it is not core.
<jcowan>
Core is just the three functions (plus a stern warning)
<Regenaxer>
It won't help. You need to re-produce the whole vector on every primitive operation
<jcowan>
I still don't understand. Can you help me with an example?
<Regenaxer>
E.g. if you insert a line on position 100000 in a 200000 lines edit buffer
<Regenaxer>
then 'append' or 'insert' build only partially new lists, and append the rest
<Regenaxer>
Extreme example
<Regenaxer>
replacing the first line needs only 1 cell
<Regenaxer>
instead of re-creating the whole vector
<Regenaxer>
The 99999 lines in the tail are shared
<Regenaxer>
Typical Lisp programs will not use static buffers
<jcowan>
Yes, what that shows is that that is not an application for vectors.
<Regenaxer>
What would be an application for vectors?
<jcowan>
That doesn't mean there are no applications for vectors. Lisp 1.5 had vectors.
<Regenaxer>
Yes, but what would *you* do with them?
<Regenaxer>
At times of Lisp 1.5 machines were very limited
<Regenaxer>
Even short Lists were expensive
<Regenaxer>
Now this doesn't count any more
<jcowan>
I already mentioned hash tables, which IMO ought to be a standard library for everyone.
<Regenaxer>
I use Vip with hundred thousand lines without problems
<Regenaxer>
PicoLisp uses a binary tree for purposes of hasing
<Regenaxer>
hashing
<jcowan>
(Actually, vectors over linked lists are probably more of a win now, when memory access time was a constant and there were no processor data caches, but that's by the way.)
<Regenaxer>
What would *you* use a vector for?
<Regenaxer>
As I said, even for Vip it turned out to work fine with linked Lists
<Regenaxer>
with hundred thousands of lines (if ever)
<Regenaxer>
I'm just now trying a file with 372897 lines in Vip
<Regenaxer>
It gets a *little* sluggish, but is usable
<Regenaxer>
I stay with what I said: With vectors you get a *little* performance gain, but lose almost *all* flexibility of what you can do with your data
<Regenaxer>
You and basically only append things to the end
<jcowan>
More than a little, if the vector is very big
<Regenaxer>
and that also only if the cells are still free
<jcowan>
Actually you can't even append things, though you can construct ropes.
<Regenaxer>
yeah
<jcowan>
(oh, yes, if stil free)
<Regenaxer>
*Where* do you use "if the vector is very big"?
<jcowan>
When you have very Big Data.
<Regenaxer>
Isn't then a database or more structured data better
<Regenaxer>
Yes, big data go to the database
<Regenaxer>
with multiple indexes and cross-linking
<Regenaxer>
a lot more flexible than a plain vector
<Regenaxer>
Tell me an example where you would need that
<Regenaxer>
I must say that I don't have any in my 40 years of programming
<Regenaxer>
Lisp is not for bulk data. If you would manipulate a pixel image, you better use native glue routines anyway
<jcowan>
I've been doing it about that long too.
<jcowan>
And write them in C? Ugh.
<Regenaxer>
Yes, why not? Or, better, use existing libraries
<Regenaxer>
PicoLisp has a very powerful native call mechanism
<jcowan>
That's what Python has to do, so the truly versatile Python programmer needs two languages, safe slow flexible Python and diffcult dangerous fast C
<Regenaxer>
I don't think Python's native calls are as easy as pil's
<Regenaxer>
Did you find @doc/native.html ?
<jcowan>
(Cython helps a lot)
<jcowan>
No, I"ll read that now
<Regenaxer>
OK, I know almost no Python at all
<jcowan>
do you have an URL I can look at re: native support?
<jcowan>
But the gc does not know about pointers there, correct?
<Regenaxer>
correct
<Regenaxer>
For numbers no problem
<jcowan>
Right
<jcowan>
But bignums or lists = trouble.
<Regenaxer>
Other data you could keep in lists
<jcowan>
Lists are a universal data type, yes. So are arrays, for that matter. But each behaves badly in certain circumstances.
<Regenaxer>
right
freemint has joined #picolisp
<jcowan>
Anyhow, my impression is that you see this particular point as the thin edge of the wedge for Big Lisp and all its complexity and difficulties. I just think it need not be so with a few primitive operations and some programmer discipline. Certainly linear lists are far safer than C-ish arrays.
<Regenaxer>
As I like to go with a single one, I came ti the conclusion that Lists are the more general ones
<jcowan>
And it would not require reimplementation of all list functions.
<Regenaxer>
See, PicoLisp even avoids Strings! :)
<Regenaxer>
Instead it uses either symbols or lists of characters
<Regenaxer>
If you study it for a while, you will see that this is no limitation
<Regenaxer>
the opposite
<Regenaxer>
Now we use all list manipulations for strings
<jcowan>
Strings are uninterned (temporarily interned, but that's just string coalescence and lots of language have that) symbols, I get that, but manipulating them as lists must be very inconvenient, since you get them in batches of 8 bytes (not even 8 characters)
<jcowan>
Definitely a case for a high-level string library
<jcowan>
(without mutation!)
<Regenaxer>
This is exactly the point where people misunderstand the power of PicoLisp
<Regenaxer>
It is not inconvenient, but the opposite
<Regenaxer>
Lisp has tons of powerful list manipulating functions
<Regenaxer>
If you also have vectors and strings, you need the same set of functions on them too
<Regenaxer>
The problem is that people do preliminary optimization
<Regenaxer>
PicoLisp doesn't need a separate string manipulation library
<Regenaxer>
Fact is, it needs almost no libraries for data manipulation at all
<Regenaxer>
it is all in the core system, in a very simple and orthogonal way
<jcowan>
Needs, no. Convenient, yes. You can build a house out of logs, but most people prefer a certain amount of prefabricated parts.
<Regenaxer>
Why "needs"? Can you give an example?
<Regenaxer>
What string manipulation library would be usefuld in pil?
<jcowan>
Eh? You said "needs", not I
<jcowan>
or rather "doesn't need", and I agree with that.
<jcowan>
But once you have written a routine to, say, extract characters m through n out of a symbol and return either a list of codepoints or another symbol, you don't want to write it again. You want it in a Lisp library where it is handy.
<jcowan>
(Ah, that's an idiom for "Not needed, but convenient"
<jcowan>
)
<Regenaxer>
You do that with 'head', 'tail', 'nth', 'match' and any other List function directly
<Regenaxer>
OK, I see :)
<jcowan>
But the head of a string is not its first character.
<jcowan>
If you really want to treat strings with list functions, you want what used to be called explode and implode: change a symbol to a list of codepoints and the inverse of that.
<Regenaxer>
You get used to that quickly, have to learn only one set of functions
<jcowan>
That's the APL argument. :-)
<Regenaxer>
What example for string manipulation would you like to see?
<Regenaxer>
Note that the 'chop' and 'pack' are not used that often
<Regenaxer>
especially 'pack' is not needed, as many functions accept also lists of characters, eg. 'prinl' or 'format'
<Regenaxer>
I did use string functions e.g. in Java or JavaScript
<Regenaxer>
but always found that in PicoLisp directly it is easier and cleaner
<jcowan>
where you are just supposed to be able to see that X[⌽⍒+\(⍳⍴X)∊+\⎕IO,Y] means "reverse each of the subvectors of length X in array Y individually"
<Regenaxer>
haha, yes
<jcowan>
I worked for a while with a company using K, which is an ASCII-based relative of APL (with some Lisp aspects) that overloads *everything* by type and arity because there are fewer characters
<jcowan>
in 2!!7!4, each ! means something different, and even when there are functions, it's typical to name them with a single letter.
<Regenaxer>
uh ;)
<jcowan>
! is modulo when its arguments are numbers, but rotate when the right-hand argument is a list, and when it's unary, it means "generate a list from 0 to n-1".
<jcowan>
I had to make myself flash cards like people use to learn vocabulary in foreign languages to train myself on all the possible meanings.
<jcowan>
and even then there are thousands of idioms to learn
<Regenaxer>
I believe so
Blue_flame has quit [Remote host closed the connection]
mtsd has quit [Quit: Leaving]
<Regenaxer>
jcowan, concerning your original hashes: PicoLisp uses the 'hash' function in combination with 'idx' binary trees for that
<Regenaxer>
see 'cache' memoization for example
<Regenaxer>
: (vi 'cache)
<Regenaxer>
: (doc 'cache)
mario-go` has quit [Quit: ERC (IRC client for Emacs 25.1.1)]
mario-goulart has joined #picolisp
<Regenaxer>
freemint, so the setup in your case could be something like that: