<freemint>
They not more dishomoiconic in Lisp than in other languages
<freemint>
*They are
<beneroth>
they can't be represented as one of picolisp native types: list, symbol, number.
<beneroth>
well ok, can be represented as number :)
<freemint>
:D
<beneroth>
but can't be treated as a number...
<freemint>
A number where the cells are next to each other and their car's encode the data
<freemint>
they can
<freemint>
the array is not very dense but is an randomly adressable storage of data of the same type for which any insertion calls for a complete recopying
<freemint>
beneroth the idea of a memory mapped binary file was really gross please so not say that again when i am listening
<beneroth>
what is gross about it?
<beneroth>
you're arrays are gross :P
<beneroth>
s/you're/your
<freemint>
Not that gross
<beneroth>
how not?
<beneroth>
where is the difference?
<beneroth>
both times it is a pointer pointing to a block of memory
<freemint>
You are caling the OS for every access to get an datastructure where you can find pieces only be reading from the beginning (files can not be randomly seeked) It is the combination of the bad aspects of list crossed with bad aspects of of a array plus it breaks type distinctions my arrays will have
<beneroth>
of course you can seek
<freemint>
Sorry you can seek but not jump you have look through everyblock before it
<beneroth>
in RAM you also can't jump, only tell "I want to read N bytes starting at the Xth byte"
<beneroth>
same as file
<beneroth>
pointer = seek number within RAM
<freemint>
I do not think you can O(1) access the memory mapped file that because files are divided in to blocks (on disk atleas)
<freemint>
*atleast
<beneroth>
the block division happens a level lower than your access. for your access, a file looks like one big block of memory.
<freemint>
Yeah but it is not!
<beneroth>
and when the file is on a RAM partition, it is actually in RAM, so it is actually that one big block.
<beneroth>
well except that it is also not in RAM, but neither is your RAM
<freemint>
ok.
<freemint>
mhh than it is not that gross
<beneroth>
RAM is also splitted into blocks, just not regular size. and the OS makes the RAM look for your program like one big block.
<beneroth>
in reality, some chunks of your RAM might be here and there.
<freemint>
but that mapping is hardware accelerated
<freemint>
not pure OS magic but that is a valid point
<beneroth>
and? why should the RAM filesystem not be accelerated?
<beneroth>
it is like a normal filesystem, just leaving the "tell disk to load that block into RAM" away...
<freemint>
because page tables are optimized by hardware. A file to ram mapping vodoo not as far i konw
<beneroth>
page tables is RAM:
<freemint>
How would you go about doing a ram file in picolisp. Maybe i can benchmark it
<freemint>
Yes
<freemint>
page tables are accelerated by hardware and the mmu. File to memory mappings do one more mapping in software as far as know
<freemint>
there are no good sources . atleast i not found anyyet
<beneroth>
the second link..what does it even have to do with SSDs ?
<beneroth>
it compares 3 kinds of RAM usages
<freemint>
mmap returs an array tmpfs returns a file
<beneroth>
the access api is different, but technically it is the same.
<freemint>
mmap is suggested to be faster
<freemint>
T
<beneroth>
tmpfs has probably some security checks built-in.. e.g. when it grows it gets swapped eg.
<freemint>
Yeah we can agree on that
<beneroth>
maybe ramfs is faster than tmpfs, having less securities afaik
<freemint>
tmpfs also goes over a kernel driver where direct memory access does not
<freemint>
same for RAMfs
<beneroth>
you can mmap a file.
<freemint>
Yes
<freemint>
But than it is an array in RAM
<freemint>
Not an file in RAM. I claim that calling the OS and having an driver emulate a file interface is slower than using the MMU provided by the CPU
<freemint>
Is that reasonable?
<beneroth>
it is. but would need benchmarking to see if the difference does matter.
<freemint>
T
<freemint>
But i have not found any
<beneroth>
other peoples benchmark are not a good decision base.
<beneroth>
they just give you a tendency.
<beneroth>
but their tests might not be comparable to your use case. or their test might be completely wrong, or simply outdated.
<freemint>
T
<freemint>
#intuition just gives you a tendency too
<beneroth>
T
<beneroth>
and (peek) seems to return weird values when the input is NULL byte
<beneroth>
and the article says that both might end up be the same speed when the OS is doing filesystem caching :)
_whitelogger has joined #picolisp
<Regenaxer>
uhh, long discussions
<Regenaxer>
Won't read that all
<Regenaxer>
beneroth: I general PicoLisp does not represent null bytes in symbol names
<Regenaxer>
they are a terminator as in C
<Regenaxer>
so no way
<Regenaxer>
Nothing to do with I/O or EOF
<Regenaxer>
'wr' and 'rd' can handle them
<Regenaxer>
but never in symbol names
alexshendi has quit [Ping timeout: 240 seconds]
rob_w has joined #picolisp
mickiebyrd has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 240 seconds]
rudha has joined #picolisp
<beneroth>
good morning all
<beneroth>
Regenaxer, yeah saw that. still, the (till) stopping at NULL was a bit unexpected. granted, NULL in there was also unexpected..
<beneroth>
Regenaxer, I find either the documentation or implementation should be adapted for (till). that it strips NULL away when returning a symbol I consider okay (though should maybe be documented too)
<Regenaxer>
Hi beneroth
<beneroth>
when returning a list, (till) could return NIL elements for NULL in input
<Regenaxer>
NULL does not exist in PicoLisp (?)
<beneroth>
no reason to stop at NULL for (till)
<Regenaxer>
You mean null byte
<beneroth>
yeah
<beneroth>
as in my example
<Regenaxer>
It does not stop
<Regenaxer>
But it reads a truncated symbol name
<Regenaxer>
As I said, a null byte is an end-of-name
<Regenaxer>
Like in C
<Regenaxer>
So you get an empty or truncated symbol name
<beneroth>
-> ("b" "l" "a" "b" "l" "a" "b" "l" "a")
<Regenaxer>
as (till) returns a symbol
<Regenaxer>
Exactly what I say
<beneroth>
I find it should return "blablablablubblubb" in this case!
<beneroth>
there was no "^J" in the input, so continue until EOF
<Regenaxer>
I think it continues
<Regenaxer>
You just don't see the data
<beneroth>
no it doesn.t next (peek) returns "b"
<Regenaxer>
If a symbol contains a null byte, the characters following in the name are ignored
<Regenaxer>
Yes, because it is reading
<Regenaxer>
but the symbol name was created already
<Regenaxer>
I think it does read till eol
<Regenaxer>
But you don't see the characters
<beneroth>
EOL, you say
<beneroth>
not EOF
<Regenaxer>
beyond the terminating null byte
<beneroth>
and it treats \0 as EOL
<Regenaxer>
In any case, a null byte in the input stream is illegal
<Regenaxer>
It can't be represented as a legal character in pil
<Regenaxer>
Like other illegal UTF-8 chars (we talked about that)
<Regenaxer>
The input stream must be legal UTF-8
<beneroth>
is \0 illegal in UTF-8?
<Regenaxer>
Pil doesn't bother to check ;)
<beneroth>
isutf8 considered the file legal
<beneroth>
I checked
<Regenaxer>
Not illegal UTF-8 code, but a "no char" in pil
<beneroth>
yes, then just it should handle it as non-existent
<beneroth>
not as EOL
<beneroth>
and (till "^J") does not stop at EOL but only at EOF, right?
<beneroth>
(and on \0, wrongly, I say)
<beneroth>
"Reads from the current input channel till a character contained in any is found (or until end of file if any is NIL)"
<beneroth>
that sentence should be then ""Reads from the current input channel till a character contained in any is found (or until end of file if any is NIL, or until a NULL byte is found in the input)"
<Regenaxer>
Nono, NULL byte is no concept in Pil
<beneroth>
T, so why does (till) stop at NULL byte? why not ignore it?
<Regenaxer>
(char 0) gives NIL, so it is undefined what happens in the individual reading functions
<Regenaxer>
Probably (line) thinks it detected EOF
<Regenaxer>
as NIL is EOF
<beneroth>
when is NIL = EOF ?
<Regenaxer>
In any case, DON'T READ NULL BYTES
<Regenaxer>
NIL is always EOF
<Regenaxer>
no, opposite
<beneroth>
a yes
<Regenaxer>
EOF gives NIL
<beneroth>
right
<Regenaxer>
in (read), (line), (char) etc.
<Regenaxer>
but (char 0) also gives NIL, to have *some* value
<Regenaxer>
but the low-level reading does not care
<Regenaxer>
It assumes that there is no null bytes
<beneroth>
ok, so you say, a text file which contains stupid NULL bytes in the middle I can't read with picolisp utilities. I have to write a parser myself all based on (rd) or write one in C?
<beneroth>
yeah?
<Regenaxer>
You have that in C too
<beneroth>
yeah in the real world programs have to work with shitty input data from other programs.
<Regenaxer>
Shitty input is always better filtered
<beneroth>
well apparently I cannot do this filtering in picolisp
<Regenaxer>
For example, Vim also gets confused if there is a null byte in a line
<Regenaxer>
it displays nonsense, doesn't get the position right
<beneroth>
wrong
<Regenaxer>
You can do such filtering with 'rd' and 'wr', yes
<beneroth>
it displays the NULL as ^@
<beneroth>
"blablabla^@blubblubb"
<beneroth>
vim does so, nano does so
<Regenaxer>
Ah, sorry, my mistake
<Regenaxer>
yes
<beneroth>
emacs does so
<Regenaxer>
They can also handle multiple character encodings
<Regenaxer>
PicoLisp handles only UTF-8 text
<beneroth>
it is not an multile character encoding.
<Regenaxer>
This was decided from the beginning
mtsd has joined #picolisp
<Regenaxer>
Keep character encoding stuff outside, delegate to the many Unix tools out there
<beneroth>
yeah, this is okay, but then it should be in documentation.
<Regenaxer>
I think it is mentioned somewhere about the null byte
<Regenaxer>
It is at the lowest level of symbol representation
<Regenaxer>
As I say, like in C
<Regenaxer>
So maybe it is assumed as self-understood
<Regenaxer>
Symbol names *need* some way to know the end
<Regenaxer>
Cannot use a count, as the length of a symbol name is unlimited
<beneroth>
well vim, emacs, nano and probably most other good editors handle it more reasonable
<Regenaxer>
So there must be a delimter
<Regenaxer>
Pil is NO editor
<Regenaxer>
This is the philosphy
<beneroth>
so you use NULL byte as a delimiter in symbol names? then NULL has a meaning in picolisp.
<Regenaxer>
don't do all you can imagine in your simple stupid interpreter, but give the tasks to tools suitable for that
<Regenaxer>
NO
<Regenaxer>
NULL has NO meaning
<Regenaxer>
it can't be represented
<Regenaxer>
it is part of the internal structure
<Regenaxer>
so NUL is the only 16-bit character that cannot be in a symbol name
<Regenaxer>
It is explicitly checked:
<Regenaxer>
: "^@"
<Regenaxer>
Bad input '@'
<Regenaxer>
?
<beneroth>
yes!
<Regenaxer>
'char' does that explicitly
<Regenaxer>
But I don't want each and every reading primitive to check that
<beneroth>
but (till) does just silently prematurely stop at NUL instead of giving an error message or doing what it does according to reference
<Regenaxer>
Because NULL does not exist!!!!!
<Regenaxer>
grr
<Regenaxer>
It is a non-concept
<Regenaxer>
not define
<Regenaxer>
d
<Regenaxer>
unpredictable
<Regenaxer>
whatever
<beneroth>
well the behaviour of (till) seems pretty predictable in thise scenario
<Regenaxer>
probably
<Regenaxer>
the low-level char input gives EOF
<Regenaxer>
so 'till' thinks it is EOF, cannot get EOL, so it stops
<Regenaxer>
if you continue reading, you get the next char
<beneroth>
probably. though the high-level (eof) correctly returns NIL in that situation
rob_w has quit [Remote host closed the connection]
coffeecup12345 has joined #picolisp
<beneroth>
bb
beneroth has quit [Quit: Verlassend]
coffeecup12345 has quit [Ping timeout: 255 seconds]
rha_ has quit [Remote host closed the connection]
rha_ has joined #picolisp
rha_ has quit [Remote host closed the connection]
rha_ has joined #picolisp
coffeecup12345 has joined #picolisp
freemint_ has joined #picolisp
<freemint_>
Hi
<DKordic>
Greetings freemint_.
<freemint_>
Hi I am trying to check whether a list of number is increasing by one every step. Can you think of a better way than (de check (L) (loop (NIL (cdr L) T) (NIL (= (inc (pop 'L)) (car L)) NIL)))
<tankfeeder>
freemint_: let me try
<freemint_>
Ok
<freemint_>
let's bench it against (range 1 bigN) and (range bigN 1)
Regenaxer has joined #picolisp
<Regenaxer>
tankfeeder: I would put the tag for catch and throw on the same line
<tankfeeder>
3rd variation, breaks immediately when found not increasing number
<tankfeeder>
freemint_: do you check on huge list ?
<freemint_>
for what defintion of huge?
<tankfeeder>
show me the code
<tankfeeder>
why 20secs
<freemint_>
I currently do (do 20 (nil (bench (do 50000 (check2 (range 1 1000))))))
<tankfeeder>
aaa
<tankfeeder>
i see why
<tankfeeder>
try 3rd paste then
<tankfeeder>
why (nil ... ?
rha_ has quit [Quit: Leaving]
<freemint_>
so i do not get spammed with (range 1 1000)
<tankfeeder>
ok
<freemint_>
it is quiet annoying
orivej has joined #picolisp
<tankfeeder>
2nd takes 3.9secs, 3rd takes 2.5secs
<tankfeeder>
on every loop of 20
<freemint_>
Then my pc sucks
<freemint_>
When i am really bored i will write a benchmark suite for picolisp which does some nice statistics
<tankfeeder>
Regenaxer: i've updated pil
<freemint_>
your check3 is faster rn
<tankfeeder>
and still dont see catch and throw on the same level
<tankfeeder>
what i missed ? :/
<tankfeeder>
i've download picoLisp.tgz after your second update
<freemint_>
according to my prelimary result (de check4 (L) (let N (dec (car L)) (fully '((X) (= (inc 'N) X)) L ) ) ) blows yor check3 out of the water
<freemint_>
Can you check that on your machine too?
<tankfeeder>
check4 is 2.1secs
<tankfeeder>
your code dont break when found nonincreasing.
<freemint_>
(check4 (range 8 1)) -> NIL here
<freemint_>
What do you mean tankfeeder
<tankfeeder>
no, i was wrong, fully breaks if nil found
<tankfeeder>
check4 is ok too
<freemint_>
The there is still alot of head room '< around 2 secs here were check4 takes 13
<freemint_>
but check4 is good enough thanks for showing me 'fully
mtsd has quit [Remote host closed the connection]
freemint_ has quit [Quit: Page closed]
alexshendi has joined #picolisp
rob_w has joined #picolisp
<Regenaxer>
tankfeeder, sorry!
<Regenaxer>
Has your updated version a @lib.l from today?
<Regenaxer>
The diff is
<Regenaxer>
< # 08mar17abu
<Regenaxer>
---
<Regenaxer>
> # 03nov17abu
<Regenaxer>
364c364
<Regenaxer>
< ((memq (car X) '(T NIL ! if ifn when unless case casq with catch push bind job in out err ctl))
<Regenaxer>
---
<Regenaxer>
> ((memq (car X) '(T NIL ! if ifn when unless case casq with catch throw push bind job in out err ctl))
<Regenaxer>
i.e. 'throw' added
coffeecup12345 has quit [Ping timeout: 248 seconds]
freemint_ has joined #picolisp
<freemint_>
Hi
<DKordic>
Hi freemint_.
mickiebyrd has joined #picolisp
<freemint_>
Hi DKordic
alexshendi has quit [Read error: Connection reset by peer]
freemint_ has quit [Ping timeout: 260 seconds]
freemint_ has joined #picolisp
<freemint_>
Hwo was interested in moving objects databases?
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
nonlinear has joined #picolisp
nonlinear has quit [Remote host closed the connection]