<beneroth>
razzy, Intel system is the worst. But I don't believe that the main intention or function is surveillance, it's feature-creeped bloatware which can be abused. There were some good presentations about the topic on the cognress, you can find them on media.ccc.de. But even on Intel you can now remove/replace it (thanks to FOSS people, not Intel).
<beneroth>
hi Regenaxer!
<beneroth>
razzy, I mean, do you actively use a non-systemD setup? I guess most of the criticism on the Intel ME can be applied to systemD kinda too.
rob_w has quit [Remote host closed the connection]
<alexshendi>
Good morning! (please adjust for timezone)
<Regenaxer>
☺/
<beneroth>
Good morning alexshendi :)
<alexshendi>
I thought the Chinese had their own MIPS based processors (Loongson/Godson)
kuao has quit [Quit: Connection closed for inactivity]
<beneroth>
alexshendi, they have. But apparently it is used with gcc and not reliably working with clang/LLVM. also, proprietary.
<aw->
re Mizar, I have one here donated by Geo, but I have yet to plug it in
<aw->
i think it runs miniPicoLisp or something similar
<aw->
but.. 32 bit?
<Regenaxer>
I think so
razzy has joined #picolisp
schillingklaus has joined #picolisp
rob_w has joined #picolisp
<schillingklaus>
is there a deeper reason why picolisp is not available for netbsd?
<beneroth>
hi schillingklaus
<beneroth>
I don't think so, probably just nobody packs/maintains it for netbsd. But surely you can download and build from the origin: https://software-lab.de/pil21.tgz
<beneroth>
we recommend to download and build anyway, because the distro packages tend to be outdated (not bad, but maybe missing new features)
<schillingklaus>
debian's was certainly outdated towards the end of the official support time
<beneroth>
picolisp expects a POSIX environment (especially for forking and file locking, which can work very different or are unavailable on other platforms), but should run fine on most unix-likes
<schillingklaus>
file locking... reminds me of problems with pop3 mail retievers etc. who need to lock the mailbox while retrieving mail
<beneroth>
schillingklaus, yeah, well that is debian. we rarely have big or breaking changes, but yeah they happen over the years (biggest recent one was change from pil64 in asm to pil21 in LLVM)
<beneroth>
file locking and forking: this are the primary reasons why picolisp doesn't work really on Windows, because Windows lacks the required OS/kernel functions to provide the functionality picolisp expects. emulators (cygwin and others) don't have them, so far.
<beneroth>
but now wit LLVM picolisp should run on LLVM (and of course it runs on the windows ubuntu subsystem, though the subsystem is a bit fragile)
<beneroth>
I meant: now with LLVM picolisp also runs on MacOS (previously the MacOS special binary format was an obstacle)
razzy has quit [Quit: leaving]
<beneroth>
should run on netbsd. so far I know of no one using it on netbsd, but some people use it on OpenBSD. Some (me included) even use it on Solaris.
<Regenaxer>
I think on *one* of the BSDs there was a problom
<beneroth>
oh I was not aware, thanks for chipping in f8l !
<Regenaxer>
problem
<Regenaxer>
I think alexshendi brought it up
<Regenaxer>
was it with ffi?
<Regenaxer>
or some signal?
<schillingklaus>
f81 oops maybe I just looked for it in the wrong category. wip is a bit unreliable, after all
<beneroth>
schillingklaus, f8l this looks like pil64, not yet pil21. though pil64 is certainly still usable (I use it in production), pil21 has new features and is a complete new rewrite in LLVM.
<f8l>
Yes, I can’t promise everything works, and the version there is probably very outdated.
<beneroth>
the pil64 version I largely use is older, I believe. So should not be a problem. pil64 and pil21 are well compatible. just the documentation etc. is now following pil21 which brought in some new functions and a few changes to existing ones.
<beneroth>
if you have no reason to specially stick with pil64, use pil21 :)
<f8l>
I had to ditch NetBSD and the rest of free software for years, but I just changed my job, so I hope to return to it soon.
<beneroth>
great, welcome back :D
<schillingklaus>
ah, wip category exists on pkgsrc.se but not on pkgsrc.org
<f8l>
Thanks. I just need to have some things explained, as my new contract does not seem to be much more permissive.
<alexshendi>
Regenaxer: Re: pil21. There was a problem bootstrapping it from the supplied bitcode or C files (I dont remember which). Problem was that longjmp() wasn't a syscall or libc function, but some macrology that resolved to ___netbsd_14_longjmp() or some similar crap....
<Regenaxer>
So the base system cannot call it from the .ll file
<alexshendi>
It wasn't a problem once you had bootstrapped with NetBSD llvm
<Regenaxer>
really? It is a function then?
<Regenaxer>
Cause a C macro cannot be called in PilSrc
<f8l>
There is also https://pkgsrc.se/wip/picolisp64 It seems I touched it in 2017 for the last time, and someone else updated it to 19.12.
schillingklaus has quit [Remote host closed the connection]
razzy has joined #picolisp
Hunar has joined #picolisp
Hunar has quit [Client Quit]
<alexshendi>
Regenaxer: Don't remember. But if you recompile, you pull in the macro definition via include files and the ___netbsd_14_longjmp function gets called...
<Regenaxer>
ok
<Regenaxer>
Hmm, but the macro cannot be expanded, as no C code is involved
<Regenaxer>
and the problem with longjmp is that it cannot be called via a glue function
<alexshendi>
OK, then I added a longjmp() glue function in a separate .o file.
<alexshendi>
Memory's a bit hazy now.
<Regenaxer>
I think this does not work. longjump() manipulytes the stack, so you cannot call it via another function
<Regenaxer>
Probably the only C function which behaves that way. And setjmp()
<alexshendi>
You can, if you invoke some GCC-specific declaration magic. something like __attribute__(noreturn) or similar.
<alexshendi>
I wish I could unlearn these things ....
<alexshendi>
I don't hsve a NetBSD machone anymore.
<Regenaxer>
yeah, would be good to know
<alexshendi>
These are lifted from the NetBSD github repo:
<alexshendi>
But I can't remember exactly what I did...
<Regenaxer>
I think putting setjmp() into a glue function wont work, because longjump returns to a different place each time
<Regenaxer>
the only way is to make as many glue functions as there are use cases
<beneroth>
sounds fun :(
<Regenaxer>
:/
<Regenaxer>
What would work is to edit src/base.ll (sed etc.) to fix the names
clacke has joined #picolisp
<beneroth>
that sounds like the best idea, precompiler script
<beneroth>
only specific for netbsd
<Regenaxer>
yes
<alexshendi>
I won't use pil anyway. Insufficient brain space.
alexshendi has quit [Quit: -a- IRC for Android 2.1.59]
alexshendi has joined #picolisp
alexshendi has left #picolisp [#picolisp]
kuao has joined #picolisp
<aw->
¯\_(ツ)_/¯
aw- has quit [Ping timeout: 264 seconds]
rob_w has quit [Remote host closed the connection]
<razzy>
I have forgotten command for cycling buffers in vip. :(
<razzy>
solved. i did not expected to need :
<Regenaxer>
F5 + F6 ?
<razzy>
hmm, I have disabled F1-F12. BT keyboard. I will remap
<Regenaxer>
You can also cycle buffers with :n and :N
Hunar has joined #picolisp
<Hunar>
Hello :) for naming the raylib binding i think joining pil with the name is hard to read, so I decided pil-raylib .. but I have another idea, I want to know if it's silly or good .. i'll use pil as a literal medical pill, like so raylib-pil i.e (the pill for raylib) because there are other libraries that are part of raylib with the names
<Hunar>
(rlgl raymath raudio raygui rres physac rpng) so my naming syntax would also be the pill for them (rlgl-pil raymath-pil raudio-pil raygui-pil rres-pil physac-pil rpng-pil) .. Is my idea silly or it's ok?
<beneroth>
we don't have a common naming standard (like python or so, their community gets really pissed if you use py-prefix for anything not related to them)
<beneroth>
so do as you like
<beneroth>
may pico-ray ?
<Hunar>
that brought a question into my mind that i wanted to ask :) do you prefer the name picolisp or pil
<beneroth>
for source code naming: I recommend either using picolisp namespacing or prefixes, e.g. ray:math ray:rlgl ray:png (: is an reader macro, if a function cannot be found than it looks for a picolisp native library, so this gives the possibility to later using a shared library instead of pil code without changing names if you want to really optimize something)
<Hunar>
I'm not sure yet.. I'll have to decide mid-way through the process to see what feels right
<beneroth>
yeah, such things need a bit playing around to develop proper feeling/taste for it
<Hunar>
pico-ray was my first thought when I started, but that had 2 problems.. 1: I'm positive that Regenaxer prefers pil over picolisp :) 2: the ray didn't feel complete, like if I searched for it in google and saw the result pico-ray my initial thought wouldn't be raylib :(
<beneroth>
picolisp or pil: we don't care. technically, picolisp is the real plan binary/interpreter and pil the bash script to start it up with default libraries loaded. we like it short, so probably pil is often used, but do as it fits you
<Hunar>
Ok, I've decided then, I'll go with my raylib-pil idea :) I'm overthinking it too much, I need to stop wasting time
<beneroth>
Regenaxer prefers extremely short variable names, usually leaving out the vowels entirely. comes from database, because each record stores all property names physically, so what is saved there gets saved space multiplied for all records... but all modern NoSQL document databases work similarly and storage space is cheap, so not so critical as when he formed his habits
<Regenaxer>
Playing around is best. Naming is always hard, so better be prepared to rename everythin for a while
<beneroth>
yep
<Regenaxer>
Making a separate namespace where 'clang' is called may also be a good idea
<beneroth>
T, special case
<beneroth>
the two biggest software problems: 1) naming things 2) cache invalidation 3) off-by-one errors
<beneroth>
brb
<Regenaxer>
exactly :)
<Hunar>
Regenaxer, can you explain more :)
<Regenaxer>
invent a name like 'rays' for the namespace
<Regenaxer>
look e.g. into @lib/simul.l
<Regenaxer>
Defines a 'simul' namespace
<Regenaxer>
or @lib/svg.l
Hunar has quit [Ping timeout: 256 seconds]
<Regenaxer>
or @lib/gis.l
Hunar has joined #picolisp
<Hunar>
Sorry, national electricity went off and I was waiting for the local generators.. People are making quantum computers and my country still doesn't have 24h electricity with the reason being "not enough fuel is being provided to us" while our country is a major oil exporter, and we import car fuels instead of producing it ourselves
<Regenaxer>
oh (
razzy_ has joined #picolisp
<Hunar>
Thanks Regenaxer :) I'll check all of them
<Regenaxer>
Hunar: Are you in northern Iraq? Or south Turkey?
clacke has quit [*.net *.split]
razzy has quit [*.net *.split]
theruran_ has quit [*.net *.split]
<beneroth>
now net split
beneroth has quit [Quit: Leaving]
<Hunar>
I'm in (Kurdistan Regional Government/Iraq) :)
<Regenaxer>
I see!
beneroth has joined #picolisp
<beneroth>
the libera IRC server I connected to went down
theruran_ has joined #picolisp
Hunar has quit [Ping timeout: 256 seconds]
theruran_ has quit [Quit: Connection closed for inactivity]
razzy_ has quit [Ping timeout: 260 seconds]
razzy has joined #picolisp
<razzy>
how do i open multiple files in vip from pil REPL? (vi 'file) opens one
<Regenaxer>
yes, on the REPL only one file
<Regenaxer>
so do :e file2 etc.
<Regenaxer>
On the shell you can do $ vi file1 file2 ...
<razzy>
Thank you. also, i cannot find :find and replace option.
<Regenaxer>
There is no single command
<Regenaxer>
I do /pattern then c<move> and then n . n .
<Regenaxer>
'n' is find next, and '.' repeats last change
<Regenaxer>
you can call external commands thoug
<Regenaxer>
eg, change the whole file: !G fgrep -v ...
<Regenaxer>
or !G sed "s/xxx/yyy/g"
<Regenaxer>
replaces xxx with yyy
<razzy>
i see, thank you.
<Regenaxer>
So !<move> applies shell command to the range
<Regenaxer>
This all the same in vi/vim
<razzy>
i have trouble applying sed.
<Regenaxer>
The above example works
<Regenaxer>
20!!sed "s/xxx/yyy/g"
<Regenaxer>
replaces in the next 20 lines
<Regenaxer>
!G is till end of file
aw- has joined #picolisp
<razzy>
it is :command , yes?
<Regenaxer>
Note that in the above examples '!' is pressed in command mode
<Regenaxer>
no
<Regenaxer>
it is ! command
<Regenaxer>
! plus movement
<Regenaxer>
like all change commands in vi
<Regenaxer>
Maybe I should explain in next PilCon
<Regenaxer>
basic VI principles
<razzy>
Regenaxer: thank you, it works now. I picked emacs, avoided vi in past :]
<Regenaxer>
good :)
<razzy>
i am quite lost in "obvious" vi stuff
<Regenaxer>
Vi has 6 editing commands: "!" "<" ">" "c" "d" "y"
<Regenaxer>
you combine them with any <move> command
<Regenaxer>
and an optional count
<Regenaxer>
Very orthogonal
<Regenaxer>
and "!" is the one applying an external command
<Regenaxer>
"d" is delete
<Regenaxer>
"c" is change (typing in new stuff)
<razzy>
so far i like differentiated "edit mode" and "command mode".
<Regenaxer>
"y" is copy ("yank")
<Regenaxer>
no
<Regenaxer>
it is "insert" mode vs. "command" mode
<razzy>
yop
<Regenaxer>
"editing" is all :)
<Regenaxer>
VI was a strike of genius
<Regenaxer>
these principles
<Regenaxer>
most VI manuals don't tell that
<Regenaxer>
they say isolated commands
<Regenaxer>
like "cw" for change word
<Regenaxer>
but this is "c" combined with "w" (move word right)
<razzy>
thank you.
<Regenaxer>
"de" delete till end of word etc
<Regenaxer>
:)
<razzy>
i do not understand, why i cannot change text when in insert mode
<Regenaxer>
in insert mode you can only backspace the current line
<Regenaxer>
insert mode is not powerful
<Regenaxer>
it just for short time input
<Regenaxer>
95 % of the time you are in command mode
<Regenaxer>
or more
<razzy>
sure, but how do i write? i want some "ci" mode
<Regenaxer>
"ci" ?
<Regenaxer>
change ?
<razzy>
change + insert
<Regenaxer>
yes, that is "c"
<Regenaxer>
If you just want to *insert* (no other change)q type "i" and start to type
<Regenaxer>
or "I" to insert at the line's beginning
<Regenaxer>
or "a" to append (start insert *after* this char)
<Regenaxer>
or "A" to append to the end of the line
<razzy>
i want editor stuff. I want write, delete, enter, modify, all lines
<Regenaxer>
Also "o" to open new lines below or "O" to open new lines above the current line
<Regenaxer>
Yes, this is what we all do when editing files, no?
<Regenaxer>
So you <move> to desired positions
<Regenaxer>
an "c"hange or "i"nsert
<Regenaxer>
or "d"elete
<Regenaxer>
right?
<Regenaxer>
"c" and "d" also as combinations with <move>
<razzy>
i will have to rewrite my head :D
<Regenaxer>
<move> is the core of all
<Regenaxer>
we are <move>ing around all the time
<Regenaxer>
by chars, lines, paragraphs, pages
<Regenaxer>
VI has many many <move> commands
<Regenaxer>
and you <move> with them, or combine with the above 6 editing commands
<Regenaxer>
So the point is to learn the <move> commands
<Regenaxer>
searching is also a <move>
<Regenaxer>
you can combine searches with editing
<Regenaxer>
you can combine almost everything with everything :)
<Regenaxer>
very ortogonal
<Regenaxer>
and simple
<razzy>
i only use find next/previous for jumping. and then move by line or char
<Regenaxer>
yes, this is most common
<Regenaxer>
I move a lot by paragraph
<Regenaxer>
paragrapt is "}"
<Regenaxer>
so yo delete a paragraph with d}
<Regenaxer>
or replace it with c}
<Regenaxer>
or very often is %
<Regenaxer>
s-expression
<Regenaxer>
% is matching paren
<Regenaxer>
so you delete an s-expression with d%
<Regenaxer>
and you change an s-expression with c%
<Regenaxer>
very simple and fast
<razzy>
hmm nice.
<Regenaxer>
copy an s-expression with y%
<Regenaxer>
then you paste it with "p" or "P"
<razzy>
i like orthogonality
<Regenaxer>
yeah, me too
<Regenaxer>
VI style requires very few key presses. Very good for me as a Penti-user
<Regenaxer>
or perhaps the only useful way for me
<razzy>
trouble: c% delete expression, i want the expression to be editable
<Regenaxer>
I can't press modifyer keys all the time
<Regenaxer>
"editable" in which sense?
<razzy>
i want to see what i am rewriting
<Regenaxer>
change it to another expression?
<Regenaxer>
hmm, you see it
<Regenaxer>
c% then type and then ESC
<Regenaxer>
if you want to change only a *part* of it, then don't use %
<Regenaxer>
go to the place you want to change and change only that
<Regenaxer>
you can quickly move to the right place with "w" (word) or "W" (long word) or "f" (find)
<Regenaxer>
"f*" jumps to the next "*" in the line
<Regenaxer>
"t*" jumps "till" the next "*" (one char before that)
<razzy>
yop, i want to change parts. constantly pushing commands and ESC seems wastefull. maybe if i bind ESC to C-f or something
<Regenaxer>
I think it is not wasteful at all
<Regenaxer>
ESC is fast
<Regenaxer>
C-f is harder to type, needs 2 key presses
<Regenaxer>
If you really think about it, the actual typing text followed by ESC is much more seldom than moving to the right positions
<razzy>
more ergonomic, it is one press of two keys :]
<Regenaxer>
Ergonomic depends on where your control key is
<Regenaxer>
I used to map it onto Shift-Lock
<Regenaxer>
when I used querty keyboards
<Regenaxer>
the standard Ctrl as invonvenient
<razzy>
yop, makes sense now
<Regenaxer>
down at the bottom
<beneroth>
so you never use shift-lock?
<Regenaxer>
very seldom
<Regenaxer>
on Penti it is easy
<beneroth>
I use it rarely, but e.g. when writing SQL I like the keywords in traditional uppercase
<Regenaxer>
a single arpeggio
<beneroth>
well okay, you never write SQL :)
<Regenaxer>
yeah
<beneroth>
better strategy ;-)
<Regenaxer>
I used to write Z80 asm in upper key
<Regenaxer>
I think I mapped shift lock to the bottom ctrl
<Regenaxer>
not sure any more
<Regenaxer>
Mapping keys in Linux is a mess. It is separate for console and X~Windows