<aw->
essentially, if there's an error, your prompt changes to "?", so you can debug it.. just press "Enter" and the code will continue
<yunfan>
aw-: yes, i got it, thanks
<Regenaxer>
Thanks aw-!
<Regenaxer>
Minor note: From an error you cannot continue, it goes to top level after resetting the environment
<Regenaxer>
Only from breakpoints you can continue
<aw->
yes sorry
gr8 has joined #picolisp
<gr8>
Regenaxer, do you realize that your project (incl. PilOS) might be in lineage with the TUNES project? http://tunes.org/ Did you hear of that before?
<gr8>
yeah but Tunes is different. They were extremely intelligent people
<Regenaxer>
Yeah, unlike me
<gr8>
you are too :)
<Regenaxer>
Not necessarily. It is just a matter of endurance
<yunfan>
gr8: is it an OS based on hallium project?
<gr8>
nope, tunes is much older.
<gr8>
It was more like an elite computer technology think tank :D
gr81 has joined #picolisp
gr8 has quit [Ping timeout: 260 seconds]
<aw->
stupid project
<aw->
"we seek to bring together the best available software technologies in a coherent system that is stable, comprehensive, understandable, and free. "
<aw->
"There is an existent version 0.0.0.35 of Tunes - it doesn't even compile, of course. My opinion, however, is that these files are a mess"
gr82 has joined #picolisp
gr81 has quit [Ping timeout: 265 seconds]
aw- has quit [Quit: Leaving.]
gr82 is now known as gr8
orivej has joined #picolisp
<gr8>
why not use the FPU in order to support floating point numbers and arithmetic?
<Regenaxer>
It it used in standard PicoLisp. PilOS perhaps not, I don't remember
<Regenaxer>
yes, on the Lisp level there is only fixpoint in pil
<Regenaxer>
But on the asm- and native-level it uses float hardware
<Regenaxer>
see in src64/arch/*
<gr81>
yes right, but why is it not exposed to the higher level?
gr8 has quit [Ping timeout: 276 seconds]
gr81 is now known as gr8
<Regenaxer>
There is no float data type on the Lisp level, only bignums
<Regenaxer>
fixnums are also only during I/O
<gr8>
but why? There are lisp dialects that have full float support, like Racket
<Regenaxer>
PicoLisp has only 3 data types, it is one of the primary design decisions
<Regenaxer>
Simplicity and speed
<Regenaxer>
The same goes for bytes, strings, arrays and the whole zoo of types supported in other languages
<Regenaxer>
The core feature of PicoLisp is that it abandons all that
<Regenaxer>
And gains a lot of advantages from that
yumaikas has quit [*.net *.split]
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<Regenaxer>
oops
<Regenaxer>
Anyway
yumaikas has joined #picolisp
<gr8>
oh I see, scaled fixpoint is much better because it is predictable. Floating point math is a great mess in general
<Regenaxer>
Right, so I would not say better in general. Depends on the use case
<gr8>
I have no picolisp running right now, so when *Scl is set to 3, does "7" that was stored in a variable before become -> 700 automatically?
<Regenaxer>
no, *Scl is used only during read. Internally numbers are just integers
<Regenaxer>
so with *Scl 3 the reader converts 1.2 to 12000
<Regenaxer>
It is only a read macro
<Regenaxer>
7 still reads as _
<Regenaxer>
7
<gr8>
so when I have a variable containing 7, and then I think I might multiply it with pi?
<Regenaxer>
Only if the token contains a dot, it is treated as a fixpoint and gets scaled
<Regenaxer>
if the variable holds 7, it is the number 0.007
<Regenaxer>
(*/ MyVar PI 1.0) will do
<Regenaxer>
You should install pil and play around :)
<Regenaxer>
Are you on Linux?
<gr8>
yep I will
<gr8>
Fedora
<Regenaxer>
ok
<gr8>
what is the difference between picolisp and pil?
<gr8>
(the binaries)
<Regenaxer>
bin/picolisp is the base binary, pil (there are two: ./pil and /usr/bin/pil) is a start-up script loading some runtime libraries
<Regenaxer>
/usr/bin/pil is copied from bin/pil at package creation
<gr8>
hmm I have not installed it manually, just run make in the src64 directory, and the picolisp binary seems to work
<Regenaxer>
Are you sure there is no global installation already4
<Regenaxer>
?
<gr8>
hehe yes
<gr8>
I don't like global installations, I leave that up to my package manager
<Regenaxer>
yes, fine
<Regenaxer>
So you can just use the global on, pil +
<Regenaxer>
the local one is more up to date probably, so ./pil +
<Regenaxer>
./pil + in the installation dir, not in bin/
<Regenaxer>
This is a bit confusing
<Regenaxer>
So to your initial question, bin/picolisp is seldom used directly
<Regenaxer>
usually only in #!/usr/bin/picolisp scripts
<gr8>
I noticed that arrow keys don't work: left-right for correcting a spelling mistake, up/down for browsing history
<Regenaxer>
By default the line editor uses vi mode, but the arrow keys should still work
<Regenaxer>
depends on the terminal perhaps
<Regenaxer>
see doc/tut.html for an intro to the default line editor
<Regenaxer>
There is also a way to switch to emacs mode, but I forgot how to do it
<Regenaxer>
: (em) perhaps?
<gr8>
hmm when I hit escape, it just inserts ^[
<gr8>
right key inserts ^[[C etc.
<Regenaxer>
The line editor runs only in debug mode
<Regenaxer>
Did you start $ pil + ?
<gr8>
ah
<Regenaxer>
For interactive work always 'pil +' or './pil +' is recommended
<gr8>
ok
<Regenaxer>
Also, take a look at "man pil"
<Regenaxer>
and then the tutorial at doc/tut.html
gr81 has joined #picolisp
gr8 has quit [Ping timeout: 260 seconds]
<gr81>
why is the "(code ...)" statement necessary? You have written large part of this in assembler, essentially. Isn't the entire point to abstract away from the assembly logic as quickly as possible, and use a functional logic instead?
<Regenaxer>
See doc64/README, Reasons for the Use of Assembly Language
<gr81>
my point is not why we don't use C, but rather why we are not using Lisp. Every idiom that you use, like this https://preview.ibb.co/fmOk37/code_repetition.png could be expressed once as a lisp function, no?
<gr81>
I would just write a function for it, and then call that function with arguments
<Regenaxer>
But I don't think it gets more understandable with that
<Regenaxer>
ASM in general gives longish code :)
<gr81>
yes that's my point, you have thousands of lines of assembly, that could be compressed a lot by using lisp which expands to assembly instructions
<gr81>
so you would only need to express very few primitives using assembly
<Regenaxer>
No, I don't want that here
<gr81>
and use Lisp for everything else
<Regenaxer>
The point of assembly is a certain explicitness
<Regenaxer>
You don't write this base code all the time
<gr81>
sure but the entire thing should be a piece of art IMO ;)
<Regenaxer>
It *is* :)
<gr81>
reading assembly makes me think about implementation details a lot. I would rather write a function called (function-call) once, and then use it subsequently instead of coding it manually each time
<gr81>
so that later an optimizer can just optimize on the lisp code of function-call
<gr81>
or maybe I am missing something and this is what you are doing?
gr81 is now known as gr8
<Regenaxer>
No, in general I think the same. But sometimes (and also in case of this asm code) over-abstraction is harmful. It obscures too much
<gr8>
you have much more experience with this than I have. But to me having 10k's lines of assembly seems inefficient to me, and leaves less room for low-level metaprogramming.
<Regenaxer>
The asm source is alredy quite short. Compare it to the generated .s code. About 50% more