<Regenaxer>
but why can't I download this as text without registering?
<beneroth>
copy paste works
<Regenaxer>
As I see it, only two changes
<Regenaxer>
SunOS (illumos),
<Regenaxer>
added (illumos)
<Regenaxer>
added twice
<Regenaxer>
ie s/SunOS/SunOS (illumos)/g
<Regenaxer>
?
<Regenaxer>
copy/paste is inonvenient
<Regenaxer>
ie it is
<Regenaxer>
7 -It compiles and runs on current 32-bit GNU/Linux, FreeBSD, NetBSD, OpenBSD, 8 -SunOS, HP-UX, AIX, IRIX64, Mac OS X (Darwin), Cygwin/Win32 (and possibly oth 9 -systems. A native 64-bit version is available for arm64/Linux, x86-64/Linux,10 -ppc64/Linux, x86-64/FreeBSD, x86-64/OpenBSD and x86-64/SunOS. 11 +It compiles and runs on current 32-bit GNU/Linux, FreeBSD, NetBSD, 12 +OpenBSD, SunOS (illumos), HP-UX, AIX
<Regenaxer>
quite a mess
<Regenaxer>
Why does this page not have a "raw" mode as pastebin has?
<Regenaxer>
anyway, I insert (illumos) twice
<beneroth>
Regenaxer, I wondered that myself recently. makes no sense.
<beneroth>
Regenaxer, I suspect sometimes some Mozilla-ism spills over to canonical/ubuntu
<Regenaxer>
T
<Regenaxer>
I did the change
<Regenaxer>
will release next time I'm at a PC
<Regenaxer>
Thanks tankfeeder!
<beneroth>
Regenaxer, hopefully one last pilog question for today: I understood correctly, all generators within a select form an AND, so the set each generator produces must be the same or a super-set of the total result set
<beneroth>
total result set = what the select produces in the end
<Regenaxer>
hmm, I would not say AND
<Regenaxer>
I see it this way:
<Regenaxer>
The generators run kind of parallel
<beneroth>
they're alternative ways to get to the same result
<Regenaxer>
where each gets priority when it succeeds (the filters succeed)
<Regenaxer>
As soon as one generator is exhausted, the search terminates
<Regenaxer>
so this is a kind of AND, yes
<beneroth>
good
<Regenaxer>
yes, "alternative ways to get to the same result"
<Regenaxer>
But *only* those generators which have a non-NIL criterion
<Regenaxer>
The others don't even start
<Regenaxer>
except the first one
<beneroth>
just asking because at the very beginning I thought of it as an OR, e.g. a generator puts records in the pool of potential results (which is then filtered) independently of each other. this is wrong. was no problem in practice as I re-read the relevant section in the select documentation to grok that :)
<Regenaxer>
the first one also starts with NIL
<Regenaxer>
ok
<Regenaxer>
yes, no OR
<beneroth>
why not? :D
<Regenaxer>
So the first generator should be a fall-back
<beneroth>
ok
<Regenaxer>
typically the "number" or "name" index
<Regenaxer>
something all objects have
<beneroth>
yeah, the index which holds all records
<Regenaxer>
yes
<Regenaxer>
this gives an ordered output for an empty search
<beneroth>
T
<beneroth>
unordered when other generators are active
<Regenaxer>
yes
<Regenaxer>
not predictable order
<beneroth>
T
<Regenaxer>
beneroth, probably you know already, I usually debug select calls simply with (trace 'init) and sometimes also (trace 'step)
<Regenaxer>
This shows nicely what it looks for
<beneroth>
ah, nice idea
<beneroth>
yeah of course those functions get used
<Regenaxer>
yes
<beneroth>
good trick, no I didn't think of that :)
<Regenaxer>
And usually my error is to pass the wrong search criteria
<Regenaxer>
ok
<Regenaxer>
or the wrong indexes, that's why the 'init'
<beneroth>
yeah, I see
zod has quit [Disconnected by services]
<m_mans>
Hi all!
<Regenaxer>
Hi m_mans!
<Regenaxer>
How are things?
<m_mans>
pilog question
<m_mans>
:)
<Regenaxer>
ok
<beneroth>
hi m_mans
<beneroth>
haha, we had just many of those. I just dived head-first into it, got some bruises but turned out nice :)
<m_mans>
let I have '+Node' object in @Nd pilog variable. How could look generator clause for select that returns items from 'itm attribute of that object?
<Regenaxer>
The generator should do it automatically
<Regenaxer>
It should know about +List
<m_mans>
itm is defined as (rel itm (+List +Joint) nd (+Component))
<Regenaxer>
yes
<Regenaxer>
I don't remember atm, does it not return the objects one after one?
<m_mans>
and I already have '+Node' object, so no need to traverse index
<m_mans>
tried to use lst/3, but no luck
<Regenaxer>
ok, then you can use (lst @Itm @Nd itm)
<Regenaxer>
if you had (select (@Comp) ((nm +Node lst) ... it should work
<Regenaxer>
ie the generator traverses the node tree
<Regenaxer>
then returns the items
<Regenaxer>
(select (@Comp) ((nm +Node @Nm itm) ... I mean
<Regenaxer>
If you have the node, you can do (? @Nd '{207} (lst @Itm @Nd itm))
<m_mans>
Initially I thought to do that (get some indexed attrib of Node, then do usual index traversing)
<Regenaxer>
this returns the items
<Regenaxer>
yeah
<m_mans>
but then I thought that is a little overhead
<Regenaxer>
I think the problem is that select iterates indexes
<m_mans>
I've read this:
<m_mans>
In the most general case, a generator clause can be an arbitrary Pilog query. Often this is a query to a database on a remote machine, using the remote/2 predicate, or some other resource not accessible via database indexes, like iterating a +List of +Links or +Joints.
<Regenaxer>
true
<Regenaxer>
perhaps I forgot some less-used details
<m_mans>
exactly my case, not? I alreade have pointer to object, so wanted to bypass index traversing
<Regenaxer>
yes
<m_mans>
but why I try to use 'select - because I wonder if I can add more generator or/and filters
<Regenaxer>
hmm, I don't remember atm, and don't have access to old sources here
<Regenaxer>
right
<m_mans>
np
<m_mans>
ok, at least I can try to do index traversal
<Regenaxer>
I think you are right, there is a syntax for it
<Regenaxer>
if the generator starts with a @Var
<m_mans>
yeah, docs says that, but I never touched that part
<Regenaxer>
So we are on the right track! :)
<Regenaxer>
it is line 494 ff in @lib/pilog.l
<Regenaxer>
(let (Var (++ Lst) Val (++ Lst))
<Regenaxer>
(and
<Regenaxer>
(or Flg (apply or Val))
<Regenaxer>
(cons Var (goal (++ Lst))) ) ) ) )
<Regenaxer>
Here the generator can call Pilog
<Regenaxer>
as you say, "Nested Pilog Queries" in doc/select.html
<m_mans>
things are go slowly. I have an experimental task trying replace C++ code with PicoLisp+native. Problem is that the task is close to kernel things
<Regenaxer>
close to kernel?
mtsd has quit [Remote host closed the connection]
<Regenaxer>
Good that you reminded me of these Nested Pilog Queries. I almost forgot that they are there :)
<m_mans>
some clustered storage, need to develop something very new
<Regenaxer>
Powerful feature
<m_mans>
hehe
<Regenaxer>
Cool! Sounds very interesting
<m_mans>
I even don't understand the whole task
<Regenaxer>
Well, you just started ...
<m_mans>
currently I'm just diving into libaio in Linux
<m_mans>
not much documented things
<m_mans>
my question was concerning other task, not that kernel things of course :))
<Regenaxer>
Is libaio1 useful for pil DBs?
<m_mans>
I'm thinking of that, but currently I'm not sure
<Regenaxer>
Linux kernel asynchronous I/O
<Regenaxer>
ok
<Regenaxer>
My feeling is that it is not useful for pil
<Regenaxer>
bottleneck is not I/O
<Regenaxer>
but disk caching
<Regenaxer>
ie. memory
<m_mans>
it's not blocking IO, so one need to control queue of events
<Regenaxer>
ok, perhaps it helps when many blocks are written in a commit
<Regenaxer>
Worth testing anyway
<m_mans>
In general I think bottleneck might be count of syscalls (I've read somewhere)
<m_mans>
needs testing
<Regenaxer>
T
<m_mans>
e.g. compare just inmemory disk with some userspace implementation without need of read/write syscalls
<m_mans>
both cases are in-memory, but second will be without syscall overhead
<Regenaxer>
In case of a Pil DB all operations happen in-memory already, so I found that *read* is not a bottleneck
<m_mans>
btw, they use native AIO (libaio) with O_DIRECT, so bypassing caching
<Regenaxer>
OK, nice
<m_mans>
but you *do* syscall when reading/writing to files?
<Regenaxer>
yes, sure
<m_mans>
Imagine inserting 1M objects in DB
<m_mans>
ok. I need finally read your answer about pilog ;)
<freemint>
Also is 32bit only currently but will make a 64 bit ISA in the next 1-3 years (will try to stay 16 bit)
<freemint>
and FPU is a pure co-processor so the PIL it could be replaced with something usefull
<freemint>
*so for pil
<Regenaxer>
well, an FPU is useful as it is
<freemint>
How is an FPU usefull?
<Regenaxer>
pil64 supports float and double internally
<freemint>
Huh?
<Regenaxer>
for native calls etc
<Regenaxer>
Check it out
<freemint>
Huh native calls on PilOS?
<Regenaxer>
No, I'm talking of normal pil64
<freemint>
Do you have any estimates how much faster hardware gaberage collection is?
<Regenaxer>
not faster at all I suppose. Bottleneck is the memory bus(ses) bandwidth
<freemint>
mhh to bad.
<Regenaxer>
CPUs are so fast
<Regenaxer>
prefetching etc
<Regenaxer>
so the bottleneck is always memory
<freemint>
Is there anything preventing collecting garberage while the interpreter is running?
<freemint>
if so what?
<Regenaxer>
Not calling functions which do 'cons'
<Regenaxer>
only destructive functions for example
<freemint>
why does cons collide with the gc?
<Regenaxer>
Why are you so worried about garbage?
<freemint>
I am not
<Regenaxer>
ok
<Regenaxer>
cons does not collide, but it *triggers* gc
<Regenaxer>
sometimes
<freemint>
but that is just by design not by necessity?
<Regenaxer>
only the cons* functions in @src64/gc.l trigger a collection
<Regenaxer>
necessity
<Regenaxer>
Without consing you need no collection
<freemint>
Would it be necessary if you had a seperate co processor doing garberage collection?
<Regenaxer>
and if cons finds it has no free cells, it *must* collect
<Regenaxer>
no, see above
<freemint>
Nah it musu wait till the gc gives it an empty cell
<freemint>
the gc is running all the time
<Regenaxer>
not the cg
<Regenaxer>
what a waste
<Regenaxer>
gc runs seldom
<Regenaxer>
and then very fast
<freemint>
T
<Regenaxer>
It rebuilds the free-list
<freemint>
Sorry read to much recent GC literature some bad assumption stuck with me
<Regenaxer>
the cons just takes a cell from that list
<Regenaxer>
ok
<freemint>
They are doing really perverted things
<Regenaxer>
:)
<freemint>
Wanna know?
<Regenaxer>
yes
<Regenaxer>
academic sports?
<freemint>
They do copying, compacting garberage collectors. The resulting problem is that every half cycle of the GC you have to rewrite all the pointers while interpreter is working. If the interpreter tries to follow a pointer it checks that the pointer links to it's own half space and if not (was already moved or will be moved later) it is calculated and looked up where the thing you are pointing to is.
<freemint>
Which still has synchronisation issues you take care of with object wise CAS flags
<Regenaxer>
yes, understand
<freemint>
I am impressed
<Regenaxer>
In fact pil has such a continuously running gc too
<freemint>
huh?
<Regenaxer>
but on the DB level
<freemint>
But not copying i hope
<Regenaxer>
right
<Regenaxer>
lib/conDbgc.l
<Regenaxer>
incremental, in a separate process
<Regenaxer>
I needed it once in a big DB which could not be stopped for collection
<freemint>
Is the db sufficently documented to allow to be read in a future where pil is lost but the databases still exist
<Regenaxer>
But that's a special case
<Regenaxer>
of course ;)
<freemint>
How big was the database?
<Regenaxer>
It was about 700 million objects
<freemint>
in gigs?
<Regenaxer>
a lot in the 2005s
<Regenaxer>
I don't know, it was distributed in 70 databases on several blades
<freemint>
Oh
<freemint>
Does it still exist?
<Regenaxer>
each object has some indexes too of course
<Regenaxer>
no, the project is long gone
<freemint>
Is it under NDA?
<Regenaxer>
ran out of money :)
<Regenaxer>
I don't think so
<Regenaxer>
But all the components needed are in the standard pil distr
<Regenaxer>
o
<Regenaxer>
like lib/conDbgc.l
<freemint>
sqlite did a marketing stunt recently where they did design an alternative odp format using sql and saying how much better sql database is compared to a zip of xml files
<Regenaxer>
or all the remote IPC stuff
<Regenaxer>
strange
<Regenaxer>
something not comparable I would say
<Regenaxer>
Sorry, must stop now
<Regenaxer>
Nice evening!
<freemint>
I played with the thought to take up their challenge and make the same in picolisp without blobs of xml
<freemint>
Nice evening
<Regenaxer>
:)
<Regenaxer>
yes, please try that!
<Regenaxer>
afp
<freemint>
not sure how to go about it
<freemint>
bye
<freemint>
adr is fun but dangerous
<freemint>
Is there a way to get a list of continous cells guaranteed?
<beneroth>
-> ("b" "l" "a" "b" "l" "a" "b" "l" "a")
<beneroth>
(till) does not behave according to documentation. it stops at NIL byte (aka "^@" aka "\0")
<beneroth>
and NULL byte counts as (eol)
<beneroth>
also, (till) seems to skip over NULL bytes...
<beneroth>
: (in "test.txt" (till) (peek))
<beneroth>
-> "b"
<beneroth>
: (in "test.txt" (till) (rd 1))
<beneroth>
-> 98
<beneroth>
: (char @)
<beneroth>
-> "b"
<freemint_>
How does that violate the documentation
<beneroth>
(till): Reads from the current input channel till a character contained in any is found (or until end of file if any is NIL)
<beneroth>
but it actually stops at NULL, aka it behaves as (till "^@")
<freemint_>
Isn't \0 end of file in uft8
<beneroth>
: (in "test.txt" (till) (eof))
<beneroth>
-> NIL
<beneroth>
it is so? if so it is not handled in (eof)
rob_w has quit [Read error: Connection reset by peer]
<beneroth>
freemint_, to my knowledge EOF is never encoded. for what reasons? you know that you are at the end of a file from the filesystem.
<beneroth>
(aka from the filesize)
<freemint_>
ahh right
orivej has joined #picolisp
<beneroth>
my input source contains null bytes in the middle of strings. it probably shouldn't have such NULLs, it is stupid and makes no sense. still, that (till "^J") stops there instead of going till TAB occurs caused me now some ugly problems
<freemint_>
Have you looked at your test.txt ?
<beneroth>
see my first line, I just generate it from pil.
<freemint_>
Sorry used the wrong editor
<freemint_>
thought picolisp printed ^@
<beneroth>
it shows as ^@ when I open the text file in nano
<freemint_>
also in less
<beneroth>
funny. picolisp doesn't know the ^@ and doesn't print it:
<beneroth>
the (prin "^@") is debatable, but the (till) behaviour is a bug for me. either documentation or implementation should get adapted.
<freemint_>
ok, why not just build your with rd?
<beneroth>
what I don't even understand your sentence
<beneroth>
ah
<beneroth>
you mean I should read with (rd) instead of using till?
<freemint_>
Ok why not built your own 'till with rd?
<beneroth>
that would be much slower than (till), to check every character and collect in a list. the buffer in the (till) implementation is surely better, I'm pretty sure
<beneroth>
well, I assume
<freemint_>
As long as you assume your till does not get multibyte chars it is quiet easy
<freemint_>
It will be slower ofc.
<beneroth>
well I have german umlauts in the input, so yeah I have mutlibytes
<beneroth>
no
<beneroth>
I just add an detector to check the invalid stops
<freemint_>
By the way you can built you can use 'rd to read in chunks
<beneroth>
if the next character is not one given as argument to till (but there is a next char, so not eof), than it was an bad stop caused by NULL byte
<beneroth>
well I don't know the byte count in advance, it is not fixed length but TAB-separated... therefore I use (till)
<freemint_>
Have you ever used arrays which were bigger than half a megabyte in code where they were actually intended to be used as arrays?
<beneroth>
yes.
<freemint_>
Example ?
<beneroth>
pictures in memory :)
<freemint_>
Other?
<beneroth>
other I haven't worked with, I think
<freemint_>
ok
<beneroth>
btw. you can export from GIMP to C code -> pixel arrays
<freemint_>
I am currently planning to missuse 'adr to build arrays and tries
<beneroth>
why?
<beneroth>
there were left out of picolisp for good reasons
<freemint_>
Because i can?
<beneroth>
ok
<beneroth>
that is a reason :)
<beneroth>
so you do art? :P
<freemint_>
Because tinkering in fun
<beneroth>
ok
<beneroth>
that is good reason :)
<freemint_>
because it is calming exercise
<beneroth>
as long as you count correctly
<freemint_>
Because i can make some code faster
<beneroth>
probably premature optimization
<beneroth>
I worked with bittables. bittables are fun, and very usable sometimes.
<beneroth>
s/usable/useful
<beneroth>
but off-by-one-errors are really annoying when working with arrays
<beneroth>
and can happen so easily
<freemint_>
Calling adr is supperior to nth after more than 15 elements
<freemint_>
T
<beneroth>
well, do you only read that array, or do you also build it?
<beneroth>
if you build it, and you don't know in advance how big it will end up, but you just want to insert elements.. well then you can quickly spend a lot time reallocating that array
<freemint_>
reading only was that. I am currenty building it manually
<beneroth>
then a list with cells is better
<freemint_>
T i was thinking more about look up tasks
<freemint_>
It would be interesting to see how it scales against trees
<beneroth>
for lookup tasks, so to use it as a bittable, yeah for that it is faster than a list
<freemint_>
needs a little more work.
<freemint_>
Also i am currently restricted to 1024*508 long arrays
<freemint_>
otherwise i can guarantee that the building terminates
<beneroth>
well would also be faster for lookup than a cell-based B-Tree. But the cell-based B-Tree can be splitted up into different parts (that is how the DB indices work), which don't have to be all in RAM. your array had to be fully in RAM.
<freemint_>
T
<beneroth>
and whenever you want to edit/extend the index with new entries, you have to do re-allocations so cell-based tree is better again
<freemint_>
yes but that is not my use case
<beneroth>
cell-based structure: memory has not to be in one block. so better use of memory, and easier allocation.
<freemint_>
Maybe also tables i hack on in parralell
<freemint_>
T i know
<beneroth>
well if your use case is a pure lookup in a array which you can easily hold fully in memory: then such an array might be the absolute right thing.
<freemint_>
beneroth i had discussion with Regenxer on this for several hours
<beneroth>
well did you explain him your use case?
<freemint_>
I did not had this one. "Because i want to can" is not a good arguement in the face of wisdom
<freemint_>
Also i can always make up an use-case
<beneroth>
the lack of array is/was apparently one of the first critic points some people (mainly common lispers?) jumped to, therefore Regenaxer talks against arrays in the picolisp FAQ and is probably also a reason why Regenaxer is quickly annoyed when you use "but but arrays" when he has written about it in the FAQ.
<freemint_>
beneroth: That is possible because i will not have to work under any economic pressure for atleast 5 years.
<beneroth>
and without a specific use case explained one has to assume you talk about the general case.
<freemint_>
I know his reasons but i still not get why he just does not provide C library which does arrays for ints and chars.
<beneroth>
freemint_, oh basic research and learning and trying out, "hacking", is absolutely a good endeavour
<beneroth>
for what use?
<freemint_>
To silence critics
<beneroth>
why should he (or anyone) try to silence critics? or care about them? they will just find another thing to talk about
<freemint_>
You know how i meant it
<beneroth>
he didn't make picolisp to get approval from other people. he made it to build applications with it.
<freemint_>
T
<beneroth>
no, I don't really know how you mean it :)
<beneroth>
the picolisp sense would be, if you want to do such heavy binary stuff -> do it in C or assembler. just do the abstract high level stuff with picolisp, and call pil asm (e.g. ht:Prin etc) or via (native) (or inline C in pil32)
<freemint_>
I bet he has spent more time discussing arrays than it would take to implement all popular data structures in C to deal with cells and make a lisp interface for them.
<freemint_>
Yeah that is what i ment
<beneroth>
well why should he create these wrappers when he doesn't need them?
<beneroth>
the people who need them can create them for themselves.
<freemint_>
To save time
<beneroth>
whos time? his own?
<freemint_>
Yes
<beneroth>
no, he just tells "shut up", saves more time
<beneroth>
problem is, he is too friendly for that :)
<freemint_>
That is what i mean
<beneroth>
well you could implement this wrappers and save his time then.
<beneroth>
he made it very easy to write such wrappers by providing (native)
<freemint_>
I do not have any experience with writing working C programms
<freemint_>
All i wrote failed
<freemint_>
I could not even build a 2d mesh of nodes connected 4 neighbors
<beneroth>
well how do you consider yourself than to have enough knowledge to rightly criticise Regenaxer for his decisions on arrays, when you (probably?) haven't fully understood them yourself yet?
<freemint_>
I have no problems with data structures my problem is that i got some problem with C
<beneroth>
well then it is even more weird that you try to bring more C into picolisp :)
<freemint_>
Got it exactly wrong.
<beneroth>
you or me?
<freemint_>
Let me explain
<freemint_>
*try to
<freemint_>
Yeah you are right i am irrational and to fearfull to implement it myself so i should not deserve to have
<beneroth>
no that was not what I said
<freemint_>
But that is what is true
<beneroth>
no
<freemint_>
Oh how is that wrong?
<beneroth>
you should just not expect other people to implement it for you
<freemint_>
That is equivalent to what i said under the condition that i will not implement it.
<beneroth>
how are too fearfull? you are already very good by thinking about such stuff. why not try?
<freemint_>
Because i am irrational and fearfull when it comes to C and would like to be able use all usefull of C without having tink i am doing C but fun "shot yourself in the foot" picolisp
<beneroth>
I see no reason why you can't be a good C programmer.
<freemint_>
objectivly there is not any. personally there is one
<beneroth>
what properties of C do you consider useful / so good?
<freemint_>
Being able to address what you have kept in your hands.
<beneroth>
I don't understand that sentence.
<beneroth>
you mean that the result is compiled and so you can keep the source code for yourself?
<freemint_>
No
<freemint_>
Being able to get data by an address you remeber or calculate
<freemint_>
*from
<freemint_>
That is the feature i am missing in Picolisp
<beneroth>
what advantage does that give?
<freemint_>
You can play with more data structures from the fun heaven of picolisp
<beneroth>
(beside being cool, I mean)
<freemint_>
nothing then
<beneroth>
there are various good approaches for doing "lookup" in picolisp available. e.g. (idx)
<beneroth>
I'm not saying there are no reasons for your use case.
<beneroth>
but it makes a bit the impression you just want to have pointer arithmetic because it is complicated and cool, and you can feel great if you achieve something with it.
<freemint_>
Picolisp is good enough.
<freemint_>
beneroth: Yeah that is a good description
<beneroth>
picolisp VM consists mainly out of pointer magic, but the VM handles it so good that you don't have to handle this as a programmer.
<freemint_>
Agree
<beneroth>
yeah don't take me wrong, I worked with pointer arithmetic and it does feel cool once you have something running with it :)
<beneroth>
but I also spent hours debugging such shit because of very little mistakes ^^
<freemint_>
I am glad i do not have to work with it but i would want to when i want to
<cess11>
Symbols have some advantages.
<beneroth>
freemint_, well if you want to program C, do C :)
<freemint_>
I do NOT want to programm C
<beneroth>
arrays and pointer arithmetic are C. I don't know any other language which has it.
<freemint_>
I just want to the cool pointer arithmetic tool C has without having to be in the compiled family
<beneroth>
maybe Go or Rust would be something for you to try out.
<beneroth>
still compiled tough.
<freemint_>
ewwwww
<beneroth>
what is wrong about that? :)
<freemint_>
Imagine a small child wanting to have the one cool toy the other kid has because he comes from russia without having to give up his own cool toys and move to russia
<beneroth>
joebo, good link for this topic
<beneroth>
freemint_, well the toy doesn't behave and feel the same when taken out of russia
<freemint_>
But the child won't notice and still be happy
<joebo>
beneroth: thanks - I recalled it on the ML years ago
<joebo>
I've never had a need for it though
<beneroth>
joebo, it is new to me
<beneroth>
yeah well, it makes sense in some contexts, e.g. picture manipulation, machine learning etc... but then it makes even more sense to move the whole number crunching into C or ASM and just call it from picolisp
<freemint_>
T
<beneroth>
or you want to move it into shader code and run it on the GPU
<freemint_>
T
<freemint_>
That is the next nice toy the kid would want to have
<freemint_>
oh the second next
<beneroth>
so the kid wants to C without the hazzle of C. sounds like Rust or Go :P
<freemint_>
wrong
<beneroth>
what do you don't like about C, or what are the main reasons you don't wanna programm C?
<freemint_>
personal irrationality, a small trauma something like that
<beneroth>
when you grokked pointers, then C should be easy. C is much much easier than C++.
<freemint_>
i know
<freemint_>
but i can not do C
<freemint_>
for irrational personal reasons
<beneroth>
well... to overcome such things it is often the best to face it.
<freemint_>
T
<beneroth>
joebo, Enriques argument is actually the same as freemint_: fast lookup
<freemint_>
No my want is "I want pointer arithmentic too" It allows me to do things more "speedy" is a post-hoc rationalization
<beneroth>
well the problem is, in practice you don't need that speedy in nearly all practical use cases, and it comes at great development speed costs, as you have to be more careful and mistakes are hard to find.
<freemint_>
H<v
<freemint_>
Have you read what i just wrote
<freemint_>
No my want is "I want pointer arithmentic too" It allows me to do things more "speedy" is a post-hoc rationalization
<beneroth>
yeah, I just give also a counter argument to that :P
<beneroth>
can you imagine that I can do disputes with myself in my head and annoy myself pretty much?
<beneroth>
:)
<freemint_>
beneroth: Thank you for telling the child: "Nah he is older than you. You are to young you can not have. Having that toy sucks"
<beneroth>
hm, I still have to improve my wording then.
<freemint_>
beneroth: I do that constantly so i assume you do too.
<beneroth>
nothing wrong with that toy. but nothing wrong with visiting russia, too
<freemint_>
"So if you are not willing you to get yourself you do not deserve it"
<freemint_>
I got to go battery dying
<beneroth>
you don't deserve anything.
<freemint_>
Ok you denied that sentence up there
<beneroth>
nobody deserves anything. and if they do, they don't get it because of that.
<beneroth>
you can have it, you just have to get yourself into a situation where you can have it.
<beneroth>
you can either change the picolisp vm (e.g. see joeboes link) yourself, or you go to C and do it in C.
<freemint_>
more tomorow
<freemint_>
bye
<beneroth>
and if you can't do that, you can find out what you need so you get the abilities to do that
<beneroth>
okay
<freemint_>
bye
<beneroth>
good night. take care.
<freemint_>
thanks
<freemint_>
I am glad we agreed on that i do not deserve it
<freemint_>
bye
<beneroth>
sorry. I'm also not deserving anything.
<beneroth>
the universe doesn't care.
<beneroth>
do it yourself, or try to get other people do it, by paying them, by forcing them, or by pleading to them with good arguments.
<beneroth>
there is no other way to get toys.
<beneroth>
it is even a miracle that those toys exists (when they actually do).
freemint_ has quit [Ping timeout: 260 seconds]
freemint has joined #picolisp
<beneroth>
joebo, I think I have a solution.
<freemint>
beneroth: Did you know what is was doing today. I was building my own version of arrays with what i have to play with
<beneroth>
cool
<freemint>
I just realized that when i was quitting
<freemint>
using 'adr
<beneroth>
hehe, see.
<beneroth>
you CAN do it. trust yourself more.
<freemint>
You tried to push me into C the whole time
<freemint>
I can't do it there
<beneroth>
the people who make toys are just people who overcame their fear of "I-am-not-able-to-this" so often that they know that they can do it.
<beneroth>
well you surely can do whatever you want to do in picolisp. it is turing complete, so everything computable works.
<freemint>
Except that is arrogant because there are things out of the reach of us mortals.
<beneroth>
is it a good idea for you personally? maybe. is it a good idea to introduce arrays to picolisp in general? no. too big of a trap for future problems.
<freemint>
You got to admit Pointer arithmetic is only fun if you can get faster then before.
<beneroth>
freemint, nothing is true, everything is allowed. if it doesn't violate the laws of physics, then it is possible. if it is restricted by the laws of physic.. well sometimes even they can be bended.
<beneroth>
freemint, picolisp is not meant to fast.
<beneroth>
freemint, picolisp is only to be meant fast while not violating some principles.
<beneroth>
arrays violate multiple of the core picolisp principles.
<freemint>
My claim is pointer arithmetic is only fun because it is a game
<beneroth>
what isn't a game?
<freemint>
reread!
<beneroth>
just a question of perspective.
<beneroth>
everything is a game.
<freemint>
The rule of the game is to be faster than without it.
<freemint>
i doubt survival is one but mostly yes
<beneroth>
well if you don't survive you can't play :)
<freemint>
unrelated but true
<beneroth>
joebo, I think you could have a a continuous block of binary memory in picolisp, without any modifications to picolisp, and even without an "array" library!
<freemint>
I am working on that
<beneroth>
just do file io! (rd) (wr). a binary file created on a RAM partition.
<freemint>
That is in some cases two times faster than cells
<freemint>
*two times more compact
<freemint>
beneroth, "picolisp is not meant to fast." It should be able to eat all the data structures it likes