ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
Blukunfando has joined #picolisp
Nistur has quit [Ping timeout: 260 seconds]
Nistur has joined #picolisp
Nistur has quit [Ping timeout: 272 seconds]
Nistur has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
<Regenaxer> Pil21 for Termux seems dead. No reactions at all from Fredrik Fornwall to my last 6 mails
<Regenaxer> Perhaps I should ask him to at least *remove* pil64
<tankf33der> sometimes it happens.
<tankf33der> deadend.
<Regenaxer> %
<Regenaxer> T
<tankf33der> distribution over all distros.
<tankf33der> FYI
<Regenaxer> cool
<Regenaxer> A bit outdated. Debian unstable is already on 21.1.8-1
mtsd has joined #picolisp
<Regenaxer> Good morning mtsd!
<mtsd> Hello Regenaxer!
<mtsd> How are you?
<Regenaxer> Thanks! All good :)
<mtsd> Good to hear! Has the year started off nicely?
<Regenaxer> Yes, a bit more calm than usuallyq so all right
<mtsd> I have been off work for about 3 weeks, starting again today.
<Regenaxer> Home office?
<mtsd> Yes, no sign of any change
<mtsd> I don't mind home office, really
<Regenaxer> yeah, me too (naturally ;)
<mtsd> Of course :)
<mtsd> A new law was passed here, from yesterday, with som more restrictions
<mtsd> Mild ones, though, compared to the rest of the world
<Regenaxer> Same here, no really big thing
mario-go` has quit [Quit: ERC (IRC client for Emacs 26.1)]
<mtsd> Seems like things are going to stay thos way for quite some time
mario-goulart has joined #picolisp
<Regenaxer> T
rob_w has joined #picolisp
rob_w has quit [Remote host closed the connection]
rob_w has joined #picolisp
orivej has joined #picolisp
mtsd_ has joined #picolisp
mtsd has quit [Ping timeout: 256 seconds]
<tankf33der> morning
<tankf33der> Regenaxer: i think *.ll files still contains debug output for stem
<tankf33der> # ../pil
<tankf33der> 140724687148656 T
<tankf33der> : (stem (1 2 3) 2)
<tankf33der> 140724687148656 T
<tankf33der> 140724687148656 T
<tankf33der> -> (3)
<tankf33der> :
<tankf33der> of course it disappears if i remove ll files and regenerated them from scratch.
<Regenaxer> oh
mtsd__ has joined #picolisp
<Regenaxer> Luckily, the Debian version seems clean
mtsd_ has quit [Ping timeout: 240 seconds]
<Regenaxer> Hmm, but pil21.tgz on software-lab.de is all right too
<Regenaxer> hmm, wait, I looked at src/subr.l only
<tankf33der> i got this via git mirror
<tankf33der> pil21 works in kernel 5.11
<Regenaxer> you are right
<Regenaxer> base.ll still has it
<Regenaxer> I fix
<tankf33der> officially llvm 11.0.1 released, pil21 works.
<Regenaxer> ok
<Regenaxer> I released again, with re-built base.ll
<Regenaxer> So Debian was ok because Kanru rebuilt base.ll
Blukunfando has quit [Ping timeout: 246 seconds]
mtsd__ has quit [Quit: Leaving]
mtsd has joined #picolisp
mtsd_ has joined #picolisp
mtsd has quit [Ping timeout: 240 seconds]
Blukunfando has joined #picolisp
mtsd__ has joined #picolisp
mtsd_ has quit [Ping timeout: 256 seconds]
<Regenaxer> haha, I changed my e-mail in twitter to a one-time-mail, and they threw me out
<Regenaxer> Let's forget about twitter
<tankf33der> sometimes i used this as temp email
<Regenaxer> I use https://www.squizzy.de/
<Regenaxer> very nice, works in w3m
<Regenaxer> I didn't use twitter for several weeks anyway
<Regenaxer> Only Mastodon
<Regenaxer> too bad not more people use it :(
<beneroth> Regenaxer, lol
<beneroth> how dare you to not pay with currency they can reuse (data they can sell)
<beneroth> for such things I often create a specific mailadress to a domain I own. then it's kinda useless to them (I would spot if they give it away).
<Regenaxer> yeah
<beneroth> granted, trash mailadress could maybe be used to "steal" your twitter account, if the mail account is obtainable publicly somehow
<Regenaxer> I could easily re-activate the account by using Chrome and solving a captch, bot I wen't
<Regenaxer> captch
<Regenaxer> captcha
<Regenaxer> won't
<Regenaxer> grr
<beneroth> yeah you have to help the AI effort!
<Regenaxer> :)
<Regenaxer> hehe
<Regenaxer> Also, I hate Twitter cause I use to clear the cookies in the browser frequently
<Regenaxer> then each time I get a noisy mail after logging in again
<beneroth> yeah same with google
<Regenaxer> Mastodon doesn't do that
<Regenaxer> right
<Regenaxer> PlayConsole
<beneroth> I use google (search & youtube) mostly from private window, I have to disagree their BS every day or so
<Regenaxer> sigh
<Regenaxer> btw, if anyone cares to chat with me on Delta: delta@software-lab.de (don't use WhatsApp since a year)
* beneroth should take a look at delta once again...
<Regenaxer> yeah
<Regenaxer> works nice
<Regenaxer> nicely
<Regenaxer> all my friends and family members are there
<tankf33der> me too
mtsd_ has joined #picolisp
mtsd__ has quit [Ping timeout: 246 seconds]
mtsd_ has quit [Ping timeout: 264 seconds]
aw- has quit [Quit: Leaving.]
mmmattyx has joined #picolisp
rob_w has quit [Quit: Leaving]
beneroth_ has joined #picolisp
beneroth has quit [Ping timeout: 265 seconds]
beneroth_ has quit [Quit: Leaving]
beneroth has joined #picolisp
mmmattyx has quit [Quit: Connection closed for inactivity]
Seteeri has joined #picolisp
<Seteeri> I'm attempting to port PilOS to arm64, but I can't figure out why the system (qemu) seems to hang at different points in the main function.
<Seteeri> Sometimes if I remove code, it'll hang at seemingly unrelated different points in the main function.
<Regenaxer> Oh, tough!
<Regenaxer> Arm64 has so many hardware setups, and not a real BIOS, right?
<Seteeri> I'm still new to assembly and this is bare metal so it's difficult to debug
<Seteeri> I have a raspberry pi 4 to test on
<beneroth> congrats to trying this, Seteeri
<Seteeri> I can get it to print to the uart
<Regenaxer> PilOS for x86-64 depends a lot on standard BIOS
<Regenaxer> cool
<Seteeri> yeah I replaced the boot code
<Regenaxer> Great, sounds promising
<Seteeri> arm is a pain since it hasn't been standardized like IBM PC
<Regenaxer> yes
<Regenaxer> Besides this, the Arm architecture is much more clean than x86
<Seteeri> also why I wanted to move pilos to arm
<Seteeri> but if this fails, I'll just use pilos as a starting point
<Regenaxer> ok
<Seteeri> I'm still amazed at the architecture of PicoLisp and all the environments you've adapted it to - it's a work of art :)
<Regenaxer> thanks :)
<beneroth> T
<beneroth> pilos running on bare metal... with a network stack... *dream*
<Seteeri> assembly seems to be less of a priority these days besides embedded dev
<Seteeri> I dream of a lisp machine too
<Seteeri> my plan was to port one of the ethernet drivers from one of the BSDs
<Regenaxer> How would it be if you started with pil21 right away? i.e. based on LLVM instead of assembly?
<Regenaxer> Would that also be a way?
<Seteeri> I looked at it briefly...but learning LLVM/SSA and assembly and the architecture at the same time was a bit too steep for me
<Regenaxer> yeah
<Seteeri> I tried replacing the posix/os calls with stubs in pil64 but I ran into the same issue Im having now
<Seteeri> everything seems to be properly aligned...
<Regenaxer> PilOS is also a radical pruning of pil64
<Regenaxer> cut off all I/O
<Seteeri> the initial stack address seems correct - place at the high end of memory (for pi it is below the mmio address)
<Seteeri> and the heap start is right after the data section
<Regenaxer> yes, common set up
<Regenaxer> I have no idea how pi boots
<Seteeri> removing the io made pilos easier to understand
<Seteeri> it's a weird device
<Regenaxer> hmm
<Seteeri> it's more of a gpu with an arm core so its actually boots from the gpu
<Regenaxer> oh
<Regenaxer> funny indeed
<Seteeri> eventually it loads the img
<Seteeri> the "bios" is basically a txt file on the boot partiton
<Regenaxer> If you find a way, it should be possible to port to pil21 later
<Regenaxer> after all, it also ends up in asm
<Seteeri> i'd have to figure out how to include asm for the boot code
<Regenaxer> normally it is C?
<Seteeri> i think i could also do it in c
<Regenaxer> right
<Seteeri> it's really nice not dealing with c haha
<Regenaxer> pil21 is easier to link with C than pil64
<Regenaxer> true
<Seteeri> i saw the code for native
<Regenaxer> yes, but for booting a direct call of C is the easiest
<Regenaxer> like the posix glue in pil21/src/lib.c
<Seteeri> so pil uses registers differently for efficiency versus the standard abi?
<Regenaxer> pil64 uses standard arm64 abi
<Regenaxer> pil21 uses it automatically
<Regenaxer> via llvm-ir -> asm
<Regenaxer> pil21 is not even aware of that layer
<Regenaxer> as opposed to pil64
<Seteeri> ah ok
<Seteeri> what will be really interesting is how to do smp
<Regenaxer> pil64 uses its own register assignment, and switches to ABI for C calls only
<Regenaxer> indeed
<Seteeri> thats my understanding
<Seteeri> my idea is to run an interpreter on each core
<Regenaxer> thats the easiest
<Seteeri> but have to figure out how to manage access to memory
<Regenaxer> each interpreter with its own heap and stack is easiest
<Regenaxer> at least in the first stage
<Regenaxer> later intermix heap and stack chunks
<Seteeri> mmm then link the cells
<Regenaxer> like normal pil now does with coroutines
<Regenaxer> yes
<Seteeri> technically if this is bare metal, i shouldnt need virtual memory assuming i forego the concept of proccesses
<Regenaxer> I think so
<Seteeri> id use namespaces to provide seperation, not necessarily protection
<Regenaxer> Namespaces are not very helpful here
<Regenaxer> you'd need to namespace *all* symbols
<Regenaxer> several separate interpreters are easier
<Seteeri> diff heaps = diff sym tables
<Regenaxer> right
<Regenaxer> plus diff stacks
<Seteeri> to share symbols would require either copying or synchronization primitives
<Regenaxer> yes
<Regenaxer> and even sync is not enough
<Regenaxer> symbols are bound locally
<Regenaxer> so one cpu sees the *current* value of a symbol
<Regenaxer> But with different heaps, stacks and globals all is safe
<Regenaxer> and fastest
<Regenaxer> needs some ipc
<Regenaxer> aka pipes
<Seteeri> interrupts
<Regenaxer> All that is too early to worry about
<Seteeri> haha yes
<Regenaxer> would be nice to boot *one* process first
<Seteeri> I'll probably start with x86 since much more stable and more resources
<Regenaxer> you mean pil64 / arm
<Seteeri> the raspberry pi foundation does not even have proper arm64 linux os yet
<Regenaxer> really?
<Seteeri> I'll start with pilos
<Regenaxer> compiled to arm64?
<Seteeri> the linux distros are hit or miss
<Seteeri> Ive been trying for a week to get it to run on arm64
<Regenaxer> and raspbian?
<Seteeri> raspian 32-bit works on pi
<Regenaxer> I thought 64 is ready meanwhile
<Seteeri> they have test images but no official one yet
<Seteeri> my end goal is having a machine that will allow me to gradually understand the system
<Seteeri> instead of a bunch of black boxes
<Regenaxer> yeah
<Regenaxer> important
<Seteeri> the tech stacks theses days are mindboggling sometimes
<Seteeri> like modern web dev
<Regenaxer> yep, horror
<Seteeri> fortunately and unfortunately x86 will still be around for a while
<Regenaxer> I'm happy to be independent now of the arch with pil21 ;)
<Seteeri> i feel the risc-v ecosystem might be fragmented like linux distros versus a more complete ISA analagous to an integrated system like the bsds
<Seteeri> less code yeah?
<Regenaxer> a bit less, and no need to study the low levels and ABIs
<Seteeri> I wanna see powerpc make a comeback, especially now that its free like risc
<Regenaxer> I did not want to port pil64 to risk-v because it has no CPU flags
<Seteeri> i remember the discussions regarding that
<tankf33der> i will try setup this to test
<Regenaxer> powerpc is similar to arm
<Seteeri> right now risc is more popular with embeded devices
<Regenaxer> good thing
<Seteeri> x86 boot code is really confusing haha
<Seteeri> protected mode, long mode, 64 mode etc
<Regenaxer> T
<Regenaxer> legacy stuff
<Seteeri> we'll see how apple's m1 chip performs
<Seteeri> good for competiton :)
<Regenaxer> Seems very good
<Seteeri> although apple is really good at marketing
<Seteeri> btw this is the pilos code on arm64 - maybe you can spot any obvious errors?
<Regenaxer> not on a first glance
<Regenaxer> as long it contains nothing inavailatle at link time
<Regenaxer> e.g it calls getStdin_A
<Seteeri> ok
<Regenaxer> calling getBinaryZ_FB
<Regenaxer> so it is still based on the DB model
<Regenaxer> should be good this way
<Seteeri> i removed the db code in main
<Regenaxer> only the lowest I/O needs to be replaced
<Seteeri> temporary
<Regenaxer> ok
<Seteeri> i replaced ttyoutb to print to uart
<Regenaxer> good
<Seteeri> altho
<Seteeri> one of the funcs couldnt compile
<Seteeri> it had (tos X)
<Seteeri> i removed it for now (it doesnt seem to be called by main etc)
<Regenaxer> 'tos' is just a stack/register operation
<Seteeri> top of stack, correct?
<Regenaxer> yes, but in arm64 it can also be a register
<Regenaxer> on the lowes call nothing is pushed
<Seteeri> X = x0 register
<Regenaxer> the return address is in a register
<Regenaxer> I forgot which one
<Seteeri> x30 i think
<Seteeri> bl will set it
<Regenaxer> yes, sounds right
<Regenaxer> mov x21, x30
<Regenaxer> x21 is X
<Regenaxer> now I remember :)
<Seteeri> what was puzzling me was why removing like a funcall completely changes things
<Seteeri> it seemed to hang at doVersion
<Seteeri> when it gets to the div code
<Regenaxer> no idea ;)
<Seteeri> idk removing an instruction causes the pointer addresses to be off
<Seteeri> more power = more bugs
<Regenaxer> Depends on what that inst does with the stack
<Regenaxer> Easy to shoot into one's feet
<Seteeri> according to arm docs, arm64 must keep stack aligned to 16 bytes
<Regenaxer> yes
<Seteeri> 8 bytes for 32
<Regenaxer> but only when you call C
<Regenaxer> not in pil code iirc
<Seteeri> ok
<Regenaxer> then it is aligned by hardware to 64 bits
<Seteeri> it says enforced by hw
<Regenaxer> hmm, not sure but I think it is ok
<Regenaxer> if so, then src64/arch/arm64.l takes care of it
<Regenaxer> but I dont remember there is such alignment
<Regenaxer> only for 'cc'
<Seteeri> this is the linker
<Regenaxer> ok, defining sections
<Seteeri> i tried removing the bss part since it should only be necessary for c lib
<Regenaxer> uninitialized area?
<Seteeri> the bootloader would zero it out, also tried zeroing the heap
<Seteeri> ya
<Seteeri> the obj code always shows its size is zero
<Regenaxer> ok
<Regenaxer> 'cc' aligns here:
<Regenaxer> (prinst "add" "x20" "x20" "#8") # Align
<Regenaxer> (prinst "and" "x20" "x20" "#~15")
<Regenaxer> I think this is the only place where the stack is aligned to 16 bits
<Seteeri> pil works on arm normally (on an os) so is the kernel doing something also?
<Seteeri> otherwise alignmint doesnt necessarily matter
<Regenaxer> yes
<Seteeri> besides being inefficient
<Regenaxer> the kernel may need aligned stycks on interrupts
<Regenaxer> but that happens in the kernel staack space
<Regenaxer> not in pil
<Regenaxer> oops
<Regenaxer> "stack" mistypes :)
<Seteeri> btw all of this is running in ring-0
<Seteeri> well, arm doesnt have to setup all the modes intially at least
<Regenaxer> nice
<Seteeri> ill eventually push the repo once i clean it up a little
<Seteeri> hmm interesting
<Seteeri> when i add nops, sometimes it will print properly
<Seteeri> when i remove it, it doesnt print
<Regenaxer> an alignment issue then
<Seteeri> my thoughts also
<Regenaxer> is it in code?
<Regenaxer> in code it is not relevant
<Regenaxer> but data have no nops
<Seteeri> thats the main fn
<Seteeri> this is ttyOutB
<Regenaxer> ok
<Regenaxer> uart port I presume
<Seteeri> yeah
<Seteeri> with the nop "PilOS" prints
<Seteeri> without it, nothing
<Seteeri> what was confusing me was how code after could affect code before it
<Regenaxer> strange indeed
<Regenaxer> I would expect the nops are not needed
<Seteeri> im gonna do more research on the alignment issue
<Regenaxer> How did you get the idea to add them?
<Seteeri> i noticed adding/removing code would sometimes cause the "PilOS" print to execute or not execute
<Regenaxer> funny
<Seteeri> still doesnt seem right to me...
<Regenaxer> all instructions on Arm are 32 bits wide
<Regenaxer> so it causes some alignment to 64 bits
<Regenaxer> but in code it should not matter
<Seteeri> fill the remainder with zeroes
<Regenaxer> some interference with harware port writes?
<Seteeri> happens in the emu and the real device
<Regenaxer> ok, so not a timing issue
<Seteeri> whether it is the virtual uart or real uart
<Regenaxer> Sorry, some duties here
<Seteeri> also PC alignment checking
<Seteeri> based on what ive read, in contrast, x86 is very lenient with alignment
<Regenaxer> yes, byte alignment is ok
<Regenaxer> just performance degrades
<Seteeri> maybe if I use balign 16 directive
<Regenaxer> Still no reason why
<Seteeri> btw, i was able to get minipicolisp to work but much easier branching into c code
<Regenaxer> also a good way
<Regenaxer> ok, sorry, must stop now
<Seteeri> technically, could compile pil64 as emu but performance drops significantly ofc
<Seteeri> getting late
<Regenaxer> yes, and some family duties ;)
<Seteeri> ofc
<Seteeri> ty for the feedback!
<Regenaxer> before compiling emu, I would definitely tyr pil21 first
<Regenaxer> thanks for the interesting plans!
<Regenaxer> :)
<Regenaxer> see you!
<Seteeri> night!
<Regenaxer> :)
<Seteeri> I have it working!!! :))
<Seteeri> I ensured everything was aligned to 16 bytes
<beneroth> wooow
<beneroth> Seteeri, awesome
<beneroth> congrats
<Seteeri> I still have to hook up the input but the rest should work
<Seteeri> I really enjoy assembly...then again, I haven't written any large programs with it yet so I've yet to experience the reasons as to why C was invented lol
<Seteeri> I'll announce it on the list once I get input working and clean it up a bit :)
<beneroth> afaik C was invented so you can write one compiler and cover multiple CPU's
<beneroth> same reason as LLVM got invented recently LOL
<beneroth> and I suspect it has the same downsides as the (pretty bad, dumb) libraries used to cover multiple database backends with one interface... you get the lowest denominator, meaning all the disadvantages and seldom any of the benefits of a specific platform
<beneroth> of course with compiling you can optimize a bit and maybe use some of the benefits, but it's a more abstract generalized level
<beneroth> Seteeri, did you play around with Forth?
<Seteeri> I recently learned about it - I dont think it gets any simpler than that haha
<Seteeri> but the programs seem to get unweildly like asm
<Seteeri> between the three most dynamic languages - Lisp, Smalltalk, Forth - I find lisp the best or at least seems to make the most sense to me
<Seteeri> btw, once I port the ethernet driver to pilos arm64, that should provide some reusability for the original pilos :)
<beneroth> uuh
<beneroth> well establishing a network stack is huge
<beneroth> huuuuge, afaik
<beneroth> I would not be the only one happily run stuff on pilOS servers
<beneroth> just alone to get away from regular updates and systemD ;-)
<beneroth> @Forth: yeah Regenaxer came to the same conclusion, too much hazzle to keep the stack states in mind all the time. I certainly believe that (haven't tried Forth yet)
<beneroth> Smalltalk is considered dynamic? that is new to me, I only know it as the origin of OOP. Should I try it out?
<beneroth> (my background is primarily C/C++)
<Seteeri> ive looked at the resources for implementing usb also - it is not fun. to support the latest usb, you must implement all the prior protocols :/
<Seteeri> I would say smalltalk is one more abstraction above lisp in regards to the object metaphor
<beneroth> lol USB
<Seteeri> and forth is an abstraction below lisp
<beneroth> just do it like nintendo, use the hardware but only bother to implement as much as of the protocol as you need. no need to get certified and that USB logo.
<Seteeri> ive never been a big fan of oop, at least now the way, java does it
<beneroth> I quite an OOP guy,I learned programming with C++ (from a german gamedev book) and I'm good at software design.
<Seteeri> common lisp's clos system is interesting but sometimes i feel a bit overengineered
<beneroth> I find picolisp the most elegant OOP implementation I saw so far
<Seteeri> luajit is also another work of art
<Seteeri> ironically by another old school german hacker
<Seteeri> picolisp code feels really light
<beneroth> I never looked into common lisp, unfortunately. I saw that they are still in the "C/C++ of the 90s?"-stage with commercial compilers and heavily platform dependence... I was on my quest for learning lisp, when I saw this, I turned right away from Common Lisp, no thank you, had enough of that with C/C++
<beneroth> so I ended up here
<Seteeri> common lisp needs some updating but it's excellent for a compiled lisp
<beneroth> well ordered multiple inheritance I only saw in picolisp. I found such an elegant solution. No diamond problem when there is an explicit ordering.
<Seteeri> ya
<beneroth> interfaces (like in Java/C#) always felt like a ugly hack for me. also not solving the issue
<beneroth> useful and legitimate for bigcorp code monkey herding, granted. but not for good software architecture.
<Seteeri> I started on the web as a kid, then java, then C in hs, python later, then settled on lisp
<beneroth> hehe
orivej has quit [Quit: No Ping reply in 180 seconds.]
<Seteeri> ya java seems engineered for that
<Seteeri> have you tried clojure?
<beneroth> yeah I started with C++, including template programming (ha! so wonderful! so powerful! so rarely needed) and then switched from an art education into IT. man I struggled heavily with my first web exams.
orivej has joined #picolisp
<beneroth> I haven't tried clojure, but my older friend (who talked me into lisp) loves it
<Seteeri> niceee
<Seteeri> I did some contract work on Blender which is when I got really exposed to C++ - it's like the war machine of programming languages haha
<beneroth> though he now also follows largely the "functional programming means immutable" paradigm I understand the attraction of yet. In my understanding a programmer should be capable to judge when to use immutable and when to use mutable structures.
<beneroth> but well I have no idea and I'm happy with picolisp :)
<Seteeri> Im trying to get into IT currently - at least working on my certs
<beneroth> I think the most important thing to know about C++ is that no team on earth does C++ - everyone just agrees on a subset of it, in a specific style (e.g. I love the STL style and hate the Qt library style)
<beneroth> design by committee. just a too big hodge podge melting pot.
<beneroth> which part of the world are you based in?
<Seteeri> databases is proabably where I lack most knowledge
<Seteeri> i live/work in the UK, but im american
<beneroth> I'm in Switzerland. Did an apprenticeship (dominant way here to get an education besides studying/academia). but then I worked like 2 years before getting my own company, so well...
<Seteeri> Im trying to move to europe
<beneroth> haha, database is probably the field I have the most knowledge
<beneroth> yeah outside Schengen it is not so easy. but then in IT you should be able to find a sponsor
<Seteeri> i like systems programming the most. ive taken a liking to more embeded stuff lately
<Seteeri> hopefully
<beneroth> I definitely programmed more in my freetime than in my worktime (until I started to do my own company thing in ernest and all became blurry)
<Seteeri> i saw a few companies here use lisp
<beneroth> hehe
<beneroth> yeah
<Seteeri> ravenpack in spain
<beneroth> system programming is... so blissfully restricted.
<Seteeri> i applied to one of their cl positions unsuccesfully
<beneroth> (in comparison to the anarchic chaos in the web)
<Seteeri> i guess knowing how everything works is nice
<Seteeri> one thing im still pondering over is how to do concurrent gc effectively
<beneroth> I strongly believe that should be the goal. maybe secondary goal after getting something useful done, but then again how to come up with good plans without understanding?
<beneroth> hm
<Seteeri> ive read all the literature but ive concluded it's best done in hardware
<beneroth> I think there is no real concurrent gc. it's all just pushing the work to a place it doesn't disturb you. and hopefully the administrative overhead for doing this pushing around doesn't cost you more than what it is worth
<Seteeri> barriers tend to be expensive
<beneroth> picolisps gc is like: not worth to do the overhead, just to it in place when necessary. programmer may pre-allocate memory if required.
<beneroth> works.
<Seteeri> with pilos, if the interpreters have seperate heap/stack then it can be done independently
<beneroth> nice idea!
<Seteeri> so it scales with your cores
<Seteeri> i dont think the original lisp machines had multicore so thisll be interesting
<beneroth> I didn't know about ravenpack. they come into my known commercial lispers bookmark
<beneroth> the most fascinating tale about the original lisp machines I heard was about: everything is sexpr/lisp, including all config, and snapshotted, so you could never really end up in a bad state.. or if you did, you just restart into the last good one.
<Seteeri> ive seen the youtube videos and read the stories - they seemed so cool
<beneroth> I have a feeling I saw this github before, but it's not bookmarked on my machine here.... thx
<beneroth> "This list intended only for company with Common Lisp and Scheme usage"
<beneroth> see
<beneroth> they started with that, now I feel entitled to feel like a smug picolisper
<beneroth> tztz
<beneroth> nice list
<beneroth> lol Switzerland
<Seteeri> haha
<beneroth> blockchain bullshit money trap. and some hobby gamedev.
<beneroth> kinda.. expected :)
<Seteeri> im also going to put picolisp on the pinephone
<beneroth> oh yes!
* beneroth has a pinephone next to him
<Seteeri> which i also have
<Seteeri> :))
* beneroth didn't setup and used it yet :((((((((((
<Seteeri> im waiting for my serial cable
<beneroth> I'm waiting for a block of time to properly get into it
<Seteeri> i havent done any work on it either
<beneroth> usable as replacement for daily usage yet?
<Seteeri> not quite
<Seteeri> my concern with it is it lacks proper power management
<Seteeri> aka overheating/charging is possible
<beneroth> I've also ordered a librem phone... but yeah, 2019 there were hardware/cpu/battery problems, 2020 covid.. so I hope civil war or something will not be their 2021 excuse
<beneroth> uh
<beneroth> I see
<Seteeri> i will find the post
<beneroth> you mean..like don't charge unsupervised, you want to detect the heating/blowing up before it explodes, this kind of concerns? :/
<beneroth> which edition do you have?
<beneroth> I've got the postmarketOS edition, if that tells anything
<Seteeri> "Let's talk about safety of Pinephone"
<Seteeri> i have the second one - ubports?
<Seteeri> i still have to rip out one of the chips to get the usb to work properly which theyve now fixed on newer revisions
<Seteeri> i have compiled picolisp on pinephone so it does work :)
<beneroth> uh this blog entry made me feel unsafe
<beneroth> damn!
<beneroth> afaik this topic is (or was?) also the biggest obstacle in the librem phone...
* beneroth wants to get rid of android asap.
<Seteeri> me too
<Seteeri> librem - i think theyre trying to do too much too soon all at the same time
<beneroth> yeah it certainly persistently looked that way
<Seteeri> i like pinephones approach which was get the devs onboard first
<beneroth> T
<Seteeri> instead of building a store and making deals with wireless carriers etc
* beneroth misses the N900 :'-(
<beneroth> well I believe the librem guys are sincere
<beneroth> but it's a big cake to eat
<Seteeri> i miss slider phones - touchscreen just doesnt cut it
<beneroth> exactly!
<beneroth> arrow keys! damnit!
<Seteeri> haha
<Seteeri> well, i also use a mech keyboard so i need that tactile feel
<beneroth> I also donated ("preordered" haha) to some german project who wanted to do a hardware-upgrade for the n900 (including fixing the way-to-quickly-breaking-usb-socket but much more)
<beneroth> but well.. haven't heard from them. the website is still up with like one post per year.
<Seteeri> was it a kickstarter?
<beneroth> no
<beneroth> I think that was even before kickstarter was a thing
<beneroth> it run first under the umbrella of some FOSS project/payment/merch organisation
<Seteeri> also
<Seteeri> oh i think i read about that...there still around?
<beneroth> who kicked them out because they believed this will go nowhere and "preorders" just betrayed for their money (not on purpose but in practice). the neo900 guys asked friendly to transfer the funds to a newly made german limited and made it sound more like "creative differences"
<beneroth> I went along.. didn't hurt me, at least someone tried
<beneroth> but yeah.. webpage is still up, but practically dead ¯\_(ツ)_/¯
<Seteeri> ic
<beneroth> oh another epic nice phone to preorder!
<beneroth> but android? no thanks
<beneroth> I liked the android from 10 years ago (just so, it was much less usable than the N900 maemo linux os)
<Seteeri> i think you can change the os
<Seteeri> google has changed haha
<beneroth> I'm still pissed that there is no meaningful practical way to even simple things like export/import contacts to CSV (yes their apps for that. they suck. works probably via google cloud but that is something I don't do).
<Seteeri> really an understatemint
<beneroth> and that was already this case 10 years ago. while the n900 did this easily.
<Seteeri> on my android, even firefox wont let me export my bookmarks without joining their cloud
<beneroth> google has changed, yeah they became the top dog, like MS in the 90s, while MS is now the good guy to attract community/devs (after their windows phone failed because of the lack of devs)
<beneroth> but I never was a cloud fan or even gmailer back when they were the good guys
<Seteeri> a dream of mine would be if i could sell lisp devices like apple - like symbolics before
<beneroth> XMPP/jabber bridge made them go evil in my eyes, and that is long ago
<beneroth> yeah
<Seteeri> i thought about creating a service like evernote or something
<Seteeri> pildb on the backend
<Seteeri> also rip rss
<beneroth> mine too. I'll start with SaaS (i guess. I'm still trying to turn from service/consulting business into product company). but then I would like to sell appliances.. here have your little small business hardware business server. get a second for fallback/backup. be in control.
<Seteeri> ya exactly
<Seteeri> ive been studying what happened to lisp machines. its quite unfortunate
<beneroth> I've several projects now running on pilDB (and may own db layer and webframework on top of it). business applications. but not general products yet, that were individual solutions.
<beneroth> I studied the history once but I cannot recall now what happened to them exactly...
<Seteeri> ive played around on digitalocean
<beneroth> I think they had some business failures (from non-technical reasons) and so just vanished?
<Seteeri> multiple reasons
<Seteeri> culture and economics
<beneroth> yeah well.. it's more randomness than one would think
<Seteeri> apple did a lot of their research in lisp in the 90s
<Seteeri> hypercard
<Seteeri> newton
<Seteeri> sk8
<Seteeri> it was all before my time so unfortunately never got to see it in person
<beneroth> it thought I must overlook some quality of PHP, some reason why it is so popular. a discussion here in this chat helped me to understand. it was really simply just that PHP was better (more approachable) than perl back when it was all just cgi, and since then PHP just lives of from its popularity. because most people simply just stay with the first language they learn.
<beneroth> yeah same
<Seteeri> ruby in that same category also?
<beneroth> dunno...
<beneroth> ruby got big with ruby on rails
<Seteeri> ive never studied php or perl
<beneroth> which was a better php and a better python django, I guess
<Seteeri> just heard good for string manip?
<Seteeri> i experimented with flask and apache
<beneroth> well perl is probably clever, but too clever. too many additional complications, not simple. not kiss.
<beneroth> unreadable
<beneroth> regex comes from perl.
<Seteeri> and redis
<beneroth> regex is writeonly code.
<Seteeri> ah ok
<Seteeri> i really should properly learn sql lol
<beneroth> well learn it properly or leave it. pilDB is so much better :P
<Seteeri> haha
<Seteeri> coming from lisp it makes a lot of sense
<Seteeri> for pilos, the storage is going to be pildb :p
<beneroth> my take on that stuff
<Seteeri> whats your take on zfs?
<Seteeri> ive been reading a lot about it
<beneroth> I feel a bit mixed about it
<Seteeri> im trying to move to bsds
<Seteeri> its all i see on freebsd
<beneroth> for operation it seems to be a really wonderful fs
<Seteeri> it seems overkill for a desktop user
<Seteeri> and single drive lol
<beneroth> but then the license is at oracle, and while ubuntu and some other distros bundle it, without a clear legal statement Linus will never take it into the kernel (rightly so)
<beneroth> yeah absolutely
<beneroth> I'm following proxmox a bit
<Seteeri> mmm oracle
<beneroth> the current best practices seems to be run proxmox on ceph
<Seteeri> im running void on my systems right now
<Seteeri> finally moved from arch
<beneroth> hehe wow
<beneroth> I'm still on ubuntu with i3wm
<Seteeri> nice
<Seteeri> im on sway
<beneroth> mostly a practical/business thinking, I guess best hardware support, most libraries without effort on my side
<beneroth> but then again ubuntu did spyware-things, systemd, and just more components then there should be...
<Seteeri> yeah the linux ecosystem has changed a lot
<Seteeri> i dont know much about sysadmin stuff but systemd seems to make their life easier
<Seteeri> as a desktop user, seems unecessary
<Seteeri> more black boxes
<Seteeri> less transparency
<beneroth> absolutely
<beneroth> I looked once into some of the good reasons for systemd, and I don't remember the details but I remember that there were some good reasons
<beneroth> but then again..systemd is completely against UNIX style and a bloaty blackbox monster
<Seteeri> haha ya
<beneroth> if they would have made it well, then things should be configurable and it should be possible to reduce it to some very few parts required on a desktop or special-purpose server setup
<beneroth> the conspiracy theory about "not being able to get Linus/get stuff into kernel, process 1 is the next best thing" is not completely implausible, I find
<Seteeri> im starting think maybe there is more of a distinction now between users and enterprise
<beneroth> not so far to say that there is purpose, but a big bloaty monster is just an invitation to undermine it without being noticed
<beneroth> absolutely
<beneroth> lol look at android
<Seteeri> linux used to be simpler but its become something else now...
<Seteeri> and now apple with full vertical integration
<beneroth> ubuntu surely goes into that direction for a good time... apple-style... certainly they have great and well-doing people but the business strategy surely smells like wannabe-apple-with-some-more-freedoms
<beneroth> just wait for fuchsia OS ;-)
<Seteeri> idk how the business survived for so long
<beneroth> which business?
<Seteeri> ubuntu
<Seteeri> or shuttleworth had deep pockets
<beneroth> dunno if they make money. I guess some redhat style (enterprise & server biz).
<beneroth> but then I understood they where a donation by shuttleworth
<Seteeri> on the bright side, they popularized linux/foss a bit
<beneroth> who got richt with Thawte (the cert vendor)
<beneroth> a lot, I would say
<beneroth> especially the desktop use
<beneroth> I hated them for their own desktop adventure, I loved gnome2.... but then, everything has to be changed every year just for marketing purposes...
<Seteeri> haha ya
<beneroth> all in all they are still mostly true to the FOSS spirit
<beneroth> unlike..let's say.. Mozilla
<Seteeri> i remember the backlash over the gnome change
<Seteeri> a picolisp browser would be cool, but that I would need funding to make happen lol
<Seteeri> browsers are an os in their own right
<beneroth> the naming was also horrible... "unity". I've run VMware VMs back at that time (customer servers images for developing), that didn't work anymore with unity and googling "ubuntu unity vmware" gave nothing because "unity" is also a vmware product (to run an application seemingly in a native window even when it runs in its own vm)
<beneroth> haha
<beneroth> don't tell me
<Seteeri> pretty much turining into a virtualization platform
Blukunfando has quit [Ping timeout: 246 seconds]
<beneroth> since 2 years or so I rumble here around about having to write my own browser
<beneroth> probably will do it as a proxy application I can use with a "mainstream" browser
<beneroth> yes, that too
<Seteeri> could hook up the js engine by fabrice bellard
<beneroth> finally we mostly figured out how to make OS's safe, then we move all and everything into the browser
<Seteeri> haha
<Seteeri> and now wasm
<beneroth> haha
<beneroth> flash
<Seteeri> the web was not designed for this lol
<beneroth> it's like the feeling you get when people on twitter say "twitter should allow people to configure some music to play when you visit their page"
<Seteeri> hahaha
<Seteeri> reminds me of myspace
<beneroth> yeah
<Seteeri> and old school js
<beneroth> well I remember webrings and altavista
<Seteeri> yahoo pages
<Seteeri> geocities
<beneroth> geocities is lost art
<beneroth> sparkling gifs! when gif were gifs and not videos.
<Seteeri> the creator of js originally wanted to use lisp
<Seteeri> but ended up writing js in two weeks haha
<Seteeri> how some things come to be...
<beneroth> you mean the guy who created js in one weekend and got forced to step down as Mozilla CEO because this SJW'ed company cannot forgive a donation he made many years ago?
<Seteeri> i forgot his name lol
<Seteeri> there we go
<Seteeri> oh wow hes developing brave
<beneroth> yeah
<beneroth> I cannot decide if brave is a good thing or essentially a cryptominer scam
<Seteeri> ad network + angel investors + venture capital firms...im sure in time it will be
<beneroth> but see how much better Mozilla is doing now! with their diverse-correct CEO (earning millions a year) they fight for the freedom of the web, was it was meant to be by the people who created it (well not brendan eich, though he helped creating it... )
<beneroth> the CEO who gets payed so much they had to get rid of all their good engineers and the future of firefox
<Seteeri> i was looking for a decent fork of firefox
<beneroth> yeah
<beneroth> is there one?
<beneroth> can there be one with a future which is not chromium?
<Seteeri> or safari for that matter
<beneroth> well chromium is basically safari which is basically webkit which was once konqueror on kde
<beneroth> I was there, 3000 years ago... :P
<beneroth> the most horrible thing is that browser now all look and behave the same
<beneroth> they are VM's for running bloated js applications and youtube.
<Seteeri> haha yup
<Seteeri> electron...
<Seteeri> another time
<Seteeri> i gtg
<beneroth> what about client side certificates? Tim Barners-Lee himself protested when W3C declared <keygen> deprecated
<beneroth> W3C anyway now just follows the de-facto standards which are done by google
<beneroth> hehe
<beneroth> yeah
<beneroth> good night
<Seteeri> we'll see how fast i can get an ethernet/tcp driver going haha
<Seteeri> night!
<beneroth> let me know in case you consider moving to switzerland and work for bad pay (for swiss standards), I need to extend my picolisp team eventually
<beneroth> thanks for the chat :)
<Seteeri> sounds like a good opportunity!
<beneroth> well you can always find me here or on the ML ;-)
<beneroth> at the moment we are a team of 2
<beneroth> based near Zurich
Blukunfando has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]