<stacksmith>
shit. I don't know enough about picolisp build process.... when I force the architecture to arm64, the linker chokes on __sF and __errno. There is some flag missing.
<beneroth>
urgh
<stacksmith>
I am a bit like a monkey with a wrench trying to fix a car, however. Never dealt that much with makefiles, usually got frustrated and just wrote a script to build.
<beneroth>
same
<stacksmith>
Not a fan of declarative languages - prolog for that matter. I hate not knowing why something works or doesn't.
<stacksmith>
Although I understand the appeal. It just always bites me in the ass.
<stacksmith>
I wonder if arm64 expects the OS to be android or something like that...
<beneroth>
maybe. I wouldn't think so, but I don't know it.
<beneroth>
In 4-5 hours you will get help.
<beneroth>
it is 3 AM here
<stacksmith>
I am sure it will take 1 minute for someone who knows the system...
<stacksmith>
You are on hacker time, eh?
<stacksmith>
Hmm. I think I did it.
<stacksmith>
file ./picolisp
<stacksmith>
./picolisp: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=0ca8034319df765ad5c9c49b92203172a4a309ed, stripped
<beneroth>
do not forget to make the global symbol links in /usr/bin etc
<beneroth>
(see INSTALL)
<stacksmith>
yeah, that next.
<beneroth>
there are also tests to test the build
<beneroth>
congratz :)
<beneroth>
what did you have to change?
<stacksmith>
After the initial test in Makefile, the one that checks MAKEGOALS, I just forced MACHINE = arm64 and UNAME = linux ...
<stacksmith>
Then built 32-bit version, followed by 64-bit.
<beneroth>
yay
<stacksmith>
I also moved the -lm link option to the end of command, but I don't think that matters.
<stacksmith>
For some reason, you can't just build with the .s files
<beneroth>
weird
mtsd has joined #picolisp
<stacksmith>
Any idea why, after setting up global symlinks to pil and picolisp, starting pil prints "/}{ro|isr/li open: No such file or directory" ???
<stacksmith>
Apparently, loading lib.l
karswell_ has joined #picolisp
karswell has quit [Ping timeout: 240 seconds]
rob_w has joined #picolisp
mtsd has quit [Remote host closed the connection]
<Regenaxer>
beneroth, I would expect that the parent class for a +Ref2 relation needs +Ref, not +Key
<Regenaxer>
you won't typically have uniqe indexes any more up there
<Regenaxer>
I have (+Ref2 +Ref) and (+Ref2 +Key) in the subclasses and always (+Ref) in the superclasses
<Regenaxer>
If the key were unique in the superclass, then you don't need +Ref2
<Regenaxer>
in the subclass
<stacksmith>
Regenaxer - any idea why calling pil would print "/}{ro|isr/li open: No such file or directory" ?
<Regenaxer>
uh ;)
<Regenaxer>
something is wrong in the binary I suspect
<stacksmith>
I compiled for arm64 on raspberry pi - perhaps not successfully
<Regenaxer>
yeah
<stacksmith>
Had many problems - makefile did not work as architecture reported is aarch64...
<Regenaxer>
I wonder if it needs changes in src64/defs.l
<Regenaxer>
I sei
<Regenaxer>
see
<Regenaxer>
hmm
<Regenaxer>
I also never tried Arm64 on Debian, only Android
<Regenaxer>
On Android it works fine, it is my main workhorse
<stacksmith>
I have to go - but if you have any thoughts or suggestions, let me know...
<Regenaxer>
sure
<Regenaxer>
let's keep on it
<stacksmith>
Thanks - good day.
<Regenaxer>
cu
<cess11>
morning
<cess11>
weird building problems
<Regenaxer>
yeah
<beneroth>
Good morning all
<Regenaxer>
Good morning beneroth!
<beneroth>
Regenaxer, so you never used +Ref2 on a inherited +Key?
<Regenaxer>
right
<Regenaxer>
And I believe it does not make sense
<beneroth>
My reason for this is shorter tree.. e.g. a global index over which all records are available, and per-class indexes which are arguably much shorter and quicker
<Regenaxer>
this needs more space, doesn't it?
<beneroth>
my objects in that case go through different phases, each is another child class
<Regenaxer>
If the key is unique, you need one only in the superclass
<Regenaxer>
I think, theoretically it works though
<Regenaxer>
But I think if you check you have conflicts
<Regenaxer>
ie. the keys in the superclass are not unique
<beneroth>
I think it has less branches to follow before reaching the right node with the child-index, but yeah
<Regenaxer>
less branches in the sublcass?
<beneroth>
in the subclass index
<Regenaxer>
The idea for +Ref2 was that you have a single index to search if you are interested in the general type
<beneroth>
the +Ref2 which is specific to one subclass should be a much smaller index than the index of the parent class which contains all objects, while the +Ref2 only contains the objects with that subclass
<Regenaxer>
otherwise several (sub)classes need to be searched
coffeecup12345 has joined #picolisp
<Regenaxer>
yes, it is smaller
<Regenaxer>
but I would not worry about the number of nodes to traverse
<beneroth>
(class +foo) (rel id (+Key +Number)) (class +A +foo) (class +B +foo) (rel id (+Ref2 +Key +Number))
<Regenaxer>
typically, for 1000 objects, you have just 2 levels
<Regenaxer>
for 1 million 4 levels
<beneroth>
hm, I see. according to block size of index.
<Regenaxer>
I think +Key in the subclass should work
<Regenaxer>
I rather suspect you don't have uniqueness there
<Regenaxer>
so you don't find some entries
<Regenaxer>
Hi coffeecup12345!
<beneroth>
if there is any non-uniquness, than the index is changed/corrupted by the +Ref2 somehow (or by the (set>) when switching to the subclass which has that +Ref2)
<beneroth>
if I do everything the same, just commenting out the +Ref2 relation, it all works.
<Regenaxer>
hmm, so you think it is unique?
<beneroth>
all 'id values are set within one place, the T message of A (another child class)
<beneroth>
yes, I'm pretty sure
<beneroth>
but as you saw in the index node I posted, when having +Ref2 then the index nodes start to look weird
<Regenaxer>
Then there is an assumption that the superclass is +Ref
<Regenaxer>
did you look at the tree in the superclass?
<beneroth>
maybe as if the +Ref2 upon (set> 'obj (list childclass)) changes the node entry in the global inherited +Key index
<Regenaxer>
Does it have +Key's, or cons-pairs for +Ref?
<beneroth>
yes, one node is from the superclass index tree, the other from the subclass
<beneroth>
parent: (rel id (+Key +Number))
<beneroth>
child: (rel id (+Ref2 +Key +Number))
<Regenaxer>
In any case, having 2 trees gives a lot worse performance
<beneroth>
working index node (from child index): (NIL (46 NIL . {7202}))
<Regenaxer>
What I found concerning indexes, size is all that matters
<Regenaxer>
the less trees/nodes the better
<beneroth>
yes I understood that. will not use +Ref2 for my use case here.
<Regenaxer>
It all boils down to caching
<beneroth>
question is if +Ref2 +Key works or if there is a bug
<Regenaxer>
((46 . {7202})) is not a +Key, right?
<Regenaxer>
looks like a +Ref
<beneroth>
that is the parent +Key class
<beneroth>
yeah
<Regenaxer>
I thinke 'rel>' in '+Ref2' assumes that
<Regenaxer>
Should be in the reference for +Ref2
<beneroth>
"Can only be used as a prefix class to +Key or +Ref. "
<beneroth>
so -> can be used with +Key
<Regenaxer>
this is correct
<Regenaxer>
no
<Regenaxer>
+Key is fine
<beneroth>
in the example you also inherit from +Key
<coffeecup12345>
morning!
<beneroth>
I get a healthy node from the parent index tree when not having any +Ref2 involved.. a moment
<beneroth>
coffeecup12345, good morning!
<beneroth>
(NIL (46 NIL . (NIL . {7212})))
<beneroth>
that looks like a +Key node, right Regenaxer ?
<Regenaxer>
yep
<Regenaxer>
but this is the subclass, right?
<Regenaxer>
the subclass may be +Key or +Ref
<beneroth>
but when I have a +Ref2 in a child class, start out with another childclass then switch to that class with the +Ref2 -> parent index looks suddenly like +Ref2? wuut?
<beneroth>
no, this is the parent class
<beneroth>
ah
<beneroth>
you mean the subclass index might be +Key even when the parent is +Ref
<Regenaxer>
yes
<beneroth>
but you say only +Ref as parent index is acceptable
<Regenaxer>
this is even the tyical case
<Regenaxer>
you have unique objects in the subclass
<Regenaxer>
and the superclass merges them
<Regenaxer>
so they are no longer unique on that level
<beneroth>
but in your example you make it exactly like me
<beneroth>
(class +Ord +Entity) # Order class
<beneroth>
(class +EuOrd +Ord) # EU-specific order subclass
<beneroth>
...
<beneroth>
(rel nr (+Ref2 +Key +Number)) # Order number with backing index
<beneroth>
(rel nr (+Need +Key +Number)) # Order number
<beneroth>
parent class is +Key
<Regenaxer>
oh
<Regenaxer>
right
<Regenaxer>
bad example
<Regenaxer>
Take a look at 'rel>' of +Ref2
<beneroth>
and I don't understand why the (set>) has to touch the relation in the parent
<Regenaxer>
(dm rel> (Obj Old New Hook)
<Regenaxer>
(with (meta (: cls) (: var))
<beneroth>
the parent index
<Regenaxer>
(let Tree (tree (: var) (: cls))
<Regenaxer>
(when Old
<Regenaxer>
(store Tree (cons Old Obj) NIL (: dbf)) )
<Regenaxer>
(and New
<Regenaxer>
(not (get Obj T))
<Regenaxer>
(store Tree (cons New Obj) Obj (: dbf)) ) ) )
<Regenaxer>
It creates a +Ref entry, right?
<Regenaxer>
I must fix the reference
<beneroth>
why doesn't it just leave it as it is
<Regenaxer>
because the purpose is +Key -> +Ref
<Regenaxer>
this is what makes sense
<Regenaxer>
logically
<beneroth>
yeah so the reference is wrong, as there is no comment about what type the parent relation is allowed to be, and the example is wrong because it exactly does what is not allowed
<Regenaxer>
not physically for what you tried for optimization
<beneroth>
yeah
<Regenaxer>
No, what is allowed to be is correct
<Regenaxer>
may be +Key or +Ref
<beneroth>
for the child relation
<beneroth>
not for the parent relation
<Regenaxer>
but the supercalss must be +Ref
<Regenaxer>
yes
<Regenaxer>
The ref says so
<Regenaxer>
Prefix class for maintaining ...
<Regenaxer>
prefix class to +Key or +Ref
<beneroth>
the ref says nothing about parent relation, so I would understand it as it allows the same stuff as the child relation does
<Regenaxer>
right
<Regenaxer>
Probably I thought it is logical
<beneroth>
and the example gives me right :P
<Regenaxer>
that the superclass cannot be unique any more
<Regenaxer>
if things are merged
<beneroth>
well whoever made the example had my interpretation in the head :P
<Regenaxer>
merging two +Key are typically not unique
<Regenaxer>
and if they were, they should reside *there*
<beneroth>
well I'm nowhere merging
<Regenaxer>
+Ref2 does merge
<beneroth>
its double indexing of the same value
<Regenaxer>
it merges from subclasses to a superclass
<beneroth>
ah, because +Ref2 is the prefix, I see
<Regenaxer>
I think one problem is that the class hierarchy assumes to be a tree, but you use a graph of classes
<Regenaxer>
if it is a tree, the structure is clear
<beneroth>
well.. why couldn't +Ref2 just now "the entry is in the parent index, I just leave it and walk away!"
<Regenaxer>
How do you mean that?
<beneroth>
+Ref2 should not rewrite the entry in the parent index during the (set>) operation
<Regenaxer>
uh? This is the main purpose (?)
<beneroth>
haha
<beneroth>
yeah
<beneroth>
in your usage
<beneroth>
not in the example and not in my usage (which doesn't make sense for optimization, agreed)
<Regenaxer>
If the index is not rewritten, then you don't need +Ref2 at all
<Regenaxer>
The example is wrong
<beneroth>
so your viewpoint is starting from the child class (as the code of course does)
<beneroth>
my viewpoint was from the parent class
<Regenaxer>
both viewpoints should be right
<Regenaxer>
I don't understand ;)
<beneroth>
in your viewpoint the parent is a extra additional index to the current one.
<Regenaxer>
exactly
<beneroth>
in my viewpoint it is the other way around
<beneroth>
:)
<Regenaxer>
yes, and this does not make sense
<beneroth>
of course the execution order matches your viewpoint
<beneroth>
haha
<Regenaxer>
why make two redundant indexes?
<Regenaxer>
A huge waste
* beneroth
looks for arguments but doesn't find any
<Regenaxer>
The purpose is to avoid searching many classes
<Regenaxer>
I have only use cases for "Belege"
<Regenaxer>
many Beleg-Types
<beneroth>
yeah
<beneroth>
common in ERPs
<Regenaxer>
you can search e.g. an invoice by number
<beneroth>
I see
<Regenaxer>
unique
<Regenaxer>
yeah
<Regenaxer>
but if I just have a number, but don't know which type
<beneroth>
I have kinda the same, but I have not ype field
<Regenaxer>
I would need to search all the classes
<beneroth>
the type is indicated by the childclass
<Regenaxer>
so here just search the superclass
<beneroth>
T
<beneroth>
that was my thinking. with just the number I search in the (larger) global index which goes over all classes
<Regenaxer>
this is good
<beneroth>
when knowing the type (of what I look for) I search in the type-specific index
<Regenaxer>
but if it is uniqe, then you don't need indexes in the subclasses
<Regenaxer>
I think it will be slower
<Regenaxer>
due to worse caching
<beneroth>
which of course was premature optimization based on the wrong assumption that a node hop is more expensive than loading a whole index block from file xD
<beneroth>
silly.. sorry :D
<Regenaxer>
nono :)
<beneroth>
yes, you are right
<beneroth>
I can see that
<beneroth>
now
<beneroth>
:D
<Regenaxer>
I fixed the reference meanwhile
<beneroth>
great!
<Regenaxer>
I release, moment
<Regenaxer>
done
<Regenaxer>
BTW, I found my use cases for 'leaf'
<Regenaxer>
It was indeed mainly for optimization
<Regenaxer>
as 'minKey' is expensive
<Regenaxer>
I found:
<Regenaxer>
(for Vol *Volumes
<Regenaxer>
(put!> Vol 'ok 0)
<Regenaxer>
(let Tree (tree 'ino '+File Vol)
<Regenaxer>
(dbSync)
<Regenaxer>
(while (leaf Tree)
<Regenaxer>
(lose> @)
<Regenaxer>
(at (0 . 1000)
<Regenaxer>
(commit 'upd (at (0 . 1000) (zap_)))
<Regenaxer>
(dbSync) ) )
<Regenaxer>
(commit 'upd (zap_)) ) )
<Regenaxer>
(mapc 'lose!> *Volumes)
<Regenaxer>
<beneroth>
ah, some sort of gc
<Regenaxer>
yeah
<beneroth>
I cannot recognize the sort yet (could I from the code?)
<beneroth>
no
<beneroth>
schema specific gc
<beneroth>
I see
<beneroth>
so lets add (otherleaf) too? :P
<beneroth>
*joke*
<Regenaxer>
hehe :)
<Regenaxer>
would be rather simple
<Regenaxer>
So in the above case, it is more a boolean check
<beneroth>
I thought so.. the hard part is the naming ^^
<Regenaxer>
it could pick *any* node
<Regenaxer>
*any* leaf I mean
<Regenaxer>
yeah
<beneroth>
but does that gc find everything it want's to find?
<beneroth>
doesn't it ignore the leafes on the greater half of the tree?
<Regenaxer>
hmm, why 'gc'?
<beneroth>
I mean your schema-specific code from above. nothing to do with (gc) nor (dbgc)
<Regenaxer>
right
<Regenaxer>
there is 'zap_'
<Regenaxer>
This was the Smapper app, which did not use 'dbgc'
<beneroth>
well I can see the use of a schema-specific garbage collecting
<Regenaxer>
it used lib/conDbgc.l though
<beneroth>
ah, I still have that on my todo list
<Regenaxer>
The above is not garbage collection, but a complete remove
<beneroth>
ah okay
<Regenaxer>
it zaps all nodes, then the volume objects
<beneroth>
well in case you do de-duplication within database, then you need a application-specific garbage collecting of that deduplicated data
<Regenaxer>
I don't remember the background or reason
<beneroth>
kk
<beneroth>
well we found the reason for (leaf), and it is as suspected :)
<beneroth>
thanks for the info
<Regenaxer>
I think 'dbgc' would handle this
<beneroth>
T
<Regenaxer>
yes, the reason is quite clear now
<beneroth>
you are right, (dbgc) would out of the box handle it, haha
<beneroth>
impossible on SQL
<Regenaxer>
yes, cause it is so simple
<Regenaxer>
mark and sweep like the built-in gc
<beneroth>
and because it has all information
<Regenaxer>
right
<beneroth>
back to +Ref2.. why the word "typically" instead of "must be"? :P
<beneroth>
what else than a +Ref could it be?
<beneroth>
+Aux +Ref ?
<Regenaxer>
yes, or +IdxFold or so
<Regenaxer>
hmm
<Regenaxer>
no
<Regenaxer>
you are right
<beneroth>
+IdxFold has the same node structure as +Ref?
<Regenaxer>
no
<Regenaxer>
checking rel> of +Ref2 again
<beneroth>
as far as I grokked the topic the parent relation must be +Ref or a decorated (by prefix class) +Ref
mtsd has joined #picolisp
<beneroth>
hi mtsd
<beneroth>
how was your first day?
<Regenaxer>
rel> of +Ref2 seems to produce just a +Ref index
<beneroth>
Regenaxer, so currently it can only be used with plain +Ref parent indexes?
<Regenaxer>
I write "must be"
<beneroth>
ok. thx
<beneroth>
but 1) I understand correctly that (rel> '+Ref2) could possibly be made smarter (by inspecting the daemon class of the parent relation) to handle other cases, right? 2) would this make sense? maybe for +Aux and spatial stuff or so?
<Regenaxer>
yes, right
<beneroth>
ok, thanks. then my mental model is ok again :D
<beneroth>
I owe you one for the silly premature optimization :D
<beneroth>
thank you :)
<mtsd>
Hi beneroth and everyone!
<Regenaxer>
Hi mtsd!
<beneroth>
ah Regenaxer I had one other weak reason for the second indexing... (db) and (collect) find the (tree) themselves, and are clever enough to handle class inheritance.. (iter) wants the real tree
<beneroth>
(isa) does load the external symbol, right?
<beneroth>
it must
<Regenaxer>
yes
<Regenaxer>
to get the value
<beneroth>
so this is a bit of a slow down when modeling record type as subclass
<beneroth>
Regenaxer (class A) (dm foo> () (set> This '(B)) (bar> This)) (class B) (dm bar> () ...) <- is this okay?
<beneroth>
calling (set> '+Entity) within a class method (which only belongs to the former class) and then calling another method (which only belongs to the new class) within that method?
<beneroth>
I assume it is fine as long the object has the methods when they get called on it
<beneroth>
or am I doing something unusually weird once more :)
<Regenaxer>
Sorry beneroth! Was on phone all the time
<beneroth>
no problem
<Regenaxer>
Not sure if I understand correctly, but the order of these calls doesn't matter
<Regenaxer>
It is all dynamical
<Regenaxer>
both classes and methods
<beneroth>
right
<beneroth>
the question is: is it okay to change the class within a method - the method only belongs to the former class
<Regenaxer>
Yes, because the class is only needed when the method is looked up
<beneroth>
exactly
<beneroth>
thanks!
<Regenaxer>
So (bar> This) refers to the new class B
<beneroth>
T
<Regenaxer>
You can perhaps achieve the same effect with 'method'
<Regenaxer>
((method 'bar> '+B) ..)
<beneroth>
T
<beneroth>
though I want the object to change its class, as it changes its type
<Regenaxer>
good, i.e. peranently, while 'method' does it on the fly
<beneroth>
yeah
<beneroth>
it's not about borrowing a method from another class :)
<Regenaxer>
yes
<beneroth>
the object might change again the class within the same method call (if it is ready for the next type/status), or it might stay in the first changed type
<beneroth>
the process is a bit like a document going though state changes draft -> review -> publish
<beneroth>
in each phase it might have other/additional properties and different methods
<Regenaxer>
yes, I've done that too by changing the class
<beneroth>
ok. so you find it an elegant design?
<Regenaxer>
yes
alexshendi has joined #picolisp
<Regenaxer>
There is even a GUI for that
<Regenaxer>
+ClassField
<beneroth>
right!
<beneroth>
such a design is very OOP. I like OOP, allows to keep relevant code together. but overused OOP can also result in the code being too much splitted up and distributed, or the combination of objects get too complicated to hold in the mental model.
<Regenaxer>
exactly!
coffeecup12345 has quit [Ping timeout: 240 seconds]
<beneroth>
Regenaxer, your method lookup / inheritance equalising "chain of responsibility" is such an elegant architecture (I keep saying this all the time, but so it is!)
<Regenaxer>
:)
coffeecup12345 has joined #picolisp
mtsd has joined #picolisp
mtsd has quit [Remote host closed the connection]
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
mtsd has joined #picolisp
coffeecup12345 has quit [Ping timeout: 255 seconds]
<joebo>
I received a new win10 laptop at work yesterday (finally) quite nice...
<joebo>
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 32gb of ram
<joebo>
of course, first thing I tried is whether picoLisp can run under bash for windows
<joebo>
it seems WSL (windows subsystem for linux) has issues with file locking too
<joebo>
:~/picoLisp$ ./pil lib/test.l +
<joebo>
[test/src/db.l:14] File lock: Bad address
<joebo>
and running app/main gives the same
<joebo>
just an FYI :)
<joebo>
I may investigate it but just thought I'd share
coffeecup12345 has quit [Ping timeout: 258 seconds]
coffeecup12345 has joined #picolisp
<tankfeeder>
joebo: try msys2
<tankfeeder>
or cygwin
<joebo>
tankfeeder: thanks... I've used those years ago and had fork issues
<joebo>
has that become more stable?
<tankfeeder>
i think so
<tankfeeder>
both pass buildin test for pil
<tankfeeder>
it have fork tests
<tankfeeder>
it has
<joebo>
ah, I remember why... pil64 doesn't build for msys2/cygwin
<joebo>
emu could be an option
<tankfeeder>
aha :)
<Regenaxer>
tankfeeder: encode+b32enc looks good
<tankfeeder>
ok
<tankfeeder>
(setq Lst (1 2 3 4 0 0 0))
<Regenaxer>
coffeecup12345: I understood that on your win system pil runs well
<tankfeeder>
how to return list without zeroes ?
<tankfeeder>
just (1 2 3 4)
<tankfeeder>
index+head ?
<joebo>
I still have hope in my midipix port but midipix has been quite delayed at releasing
<joebo>
I was optimistic that win10 and WSL would just work
<coffeecup12345>
Regenaxer: yeah it seemed to run fine :)
<Regenaxer>
(filter n0 Lst) is not correct?
<Regenaxer>
only trailing 0s?
<joebo>
coffeecup12345: pil32 or pil64?
<Regenaxer>
coffeecup12345: thanks!
<tankfeeder>
Regenaxer: correct
<coffeecup12345>
joebo: 32 only, alex and i tried getting 64 to run but ran into issues and had to stop before fixing it
<tankfeeder>
and if paddings are 61, filter ok too?
<tankfeeder>
(setq Lst (1 2 3 4 61 61 61))
<tankfeeder>
?
<Regenaxer>
coffeecup12345, no, the built-in was also pil64, just very old
<Regenaxer>
yes
<tankfeeder>
ok
<Regenaxer>
unless 61 appears also earlier
<joebo>
coffeecup12345: is it the cygwin/msys2 build?
<tankfeeder>
Regenaxer: no, only somewhere in tail
<tankfeeder>
like padding
<Regenaxer>
ok, good then
<tankfeeder>
ok
<coffeecup12345>
joebo: its a subsystem for linux running on windows 10..it comes natively
<joebo>
odd... 32bit doesn't work for me on the subsystem for linux... It's apparently not possible to run 32 bit binaries on it
<joebo>
maybe you compiled it though?
<joebo>
the 64-bit version runs, just has issues with file locking
<Regenaxer>
yes, and coffeecup12345's was also pil64
<Regenaxer>
we checked *CPU
<Regenaxer>
x86-64
<joebo>
Regenaxer: that makes sense then... did you both test any DB operations?
<Regenaxer>
ah, no
<Regenaxer>
are there problems with file locking too?
<Regenaxer>
We tried to build a newer version but did not succeed
<Regenaxer>
some linker error
<Regenaxer>
so we gave up :)
<joebo>
yes
<joebo>
: (pool "test.db")
<joebo>
-> T
<joebo>
: (new T)
<joebo>
File lock: Bad address
<Regenaxer>
ok, old issue, like with cygwin too
<joebo>
yep yep
<joebo>
my midipix port is farther along
<Regenaxer>
:(
<joebo>
although I could probably apply the same learning and just make the file locking a nop
<joebo>
since file locking isn't implemented there either
<joebo>
won't be suitable for production use but maybe ok for DEV
<Regenaxer>
must be some deeper problem in win
<Regenaxer>
yes
<Regenaxer>
single user DB is ok
<Regenaxer>
no locking needed
<joebo>
I will research further and keep everyone updated when I get a chance
<joebo>
thanks!
<Regenaxer>
thanks to you too!
mickiebyrd has joined #picolisp
alexshendi has joined #picolisp
coffeecup12345 has quit [Ping timeout: 255 seconds]
<stacksmith>
Regenaxer - any suggestions about the arm64.linux weirdness?
<Regenaxer>
One thing to check is the system definitions
<Regenaxer>
current is for Android
<Regenaxer>
src64/sys/arm64.linux.defs.l
<Regenaxer>
you can generate these definitions by building sysdefs.c on the target and run it
<stacksmith>
I will take a look.
<stacksmith>
BTW, this is the kind of a situation I was talking about re development environment... In CL/slime I can just compile form after form until the error comes up.
<Regenaxer>
this is a different issue, right? Here we can't compile yet
<Regenaxer>
(if the system definitions don't fit)
<Regenaxer>
Concerning forms, pil does not need to compile anything, so it is a non-issue
<Regenaxer>
(you mean "expressions" when you say "forms" I assume)
<Regenaxer>
In pil the term "form" more refers to GUI forms I would say
<stacksmith>
Not being critical - just a workflow thing. Of course there is no compilation.
<Regenaxer>
yeah, I did not see this as criticism
<stacksmith>
since picolisp starts up - I would just love to be able to send top open lib.l, and send expressions one at a time stepping through the file...
<stacksmith>
until the problem appears...
<Regenaxer>
I put ! in some places then
<Regenaxer>
Interpretation drops into a debug REPL
<Regenaxer>
Continue with Enter
<stacksmith>
Right, that would work.
<Regenaxer>
So still this setup, one term with an editor and one with the repl
<Regenaxer>
You just stop on the interesting points
<Regenaxer>
no need to step it all
<stacksmith>
I will try that. I gues I should start with sysdefs.c
<Regenaxer>
*code* can be single-stepped then
<Regenaxer>
yes, this is what I meant with different issue
<Regenaxer>
without it nothing works at all ;)
<Regenaxer>
But I'm not sure if this is the problem
<Regenaxer>
you can see immediately if you look at sysdef's output
<stacksmith>
picolisp starts up by itself, and the repl seems to work OK
<stacksmith>
pil does not
<Regenaxer>
so we can exclude this reason perhaps
<Regenaxer>
yes, maybe just some defs
<stacksmith>
Well, it prints that garbage, then the repl starts up.
<Regenaxer>
the vm itself works already
<Regenaxer>
yes
<stacksmith>
So it's not sysdefs?
<Regenaxer>
Probably not, but I would check to be sure
<Regenaxer>
It is an Arm64 CPU with a 32-bit Linux?
<Regenaxer>
raspbian?
<stacksmith>
Arm64 CPU with a 64-bit linux, HypriotOS compiled for 64-bits... Debian derived.
<Regenaxer>
Sounds good
<stacksmith>
Can you run 64-bit pil in a 32-bit linux?
<Regenaxer>
no
<Regenaxer>
except 'emu' of course
<Regenaxer>
If garbage happens it could also be an alignment problem
<stacksmith>
I will look at it as soon as I have my system back - I am short a raspberry pi so it serves a double function. Luckily just slipping in an SD card does the trick.
<Regenaxer>
great
<stacksmith>
When I do - what should I look for in sysdefs?
<Regenaxer>
It outputs almost identical format to what it is in src64/sys/arm64.linux.defs.l
<stacksmith>
termios, sigaction, etc are different
<Regenaxer>
the first difference is BUFSIZ
<Regenaxer>
the (oct ...) are the same
<stacksmith>
right. Also note __sF - I was having problems with it being undefined linking at one point.
<Regenaxer>
yes, this is not generated by sysdef
<Regenaxer>
not sure what we need here
<Regenaxer>
stdio
<Regenaxer>
TERMIOS is different too
<Regenaxer>
this is terminal output related
<Regenaxer>
may explain the garbage
<Regenaxer>
hmm, the signal stuff is also different
<Regenaxer>
yeah, lots of differences
<Regenaxer>
so this won't run properly
<stacksmith>
Do you have a pi?
<Regenaxer>
no
<Regenaxer>
Debian in qemu would do probably
<stacksmith>
bummer. It's US$35
<Regenaxer>
I don't want to fiddle with more hardware
<stacksmith>
Hah. I know what you mean.
<stacksmith>
It's a pretty good little box. I was resistant, but now have 4 and it's not enought.
<Regenaxer>
:)
<Regenaxer>
I test Debian/ppc64 in qemu sometimes
<Regenaxer>
I don't want a dedicated hardware to maintain lots of systems
<stacksmith>
I use a couple as media servers - all my super-fast I7 boxes stumble on hidef, but the pi works pretty well with 1080p.
<stacksmith>
Yes, qemu may work. I did force the makefile to use arm64 - maybe incorrectly - as my linux reports aarch64
<Regenaxer>
So actually "src64/sys/arm64.linux.defs.l" may be the wrong name
<Regenaxer>
should be "src64/sys/arm64.android.defs.l"
<Regenaxer>
:(
<Regenaxer>
hard to change now perhaps
<stacksmith>
After the MAKECMDGOALS ifeq I just forced "MACHINE = arm64" and "UNAME = Linux". I thought that should work for testing - eventually it should be a check in the indented ifeq...
<stacksmith>
I could not get the makefile to work without building the 32-bit version first...
<stacksmith>
So my whole situation is suspicious.
<stacksmith>
I just don't know enough about the system...
<Regenaxer>
you don't need to bootstrap with pil32 if you download the pre-built *.s files
<Regenaxer>
But they don't help in your case
<Regenaxer>
Hmm, so I must change all that
<Regenaxer>
And get the Debian port done
<stacksmith>
Oh, I did download the .s files. Did they just get ignored and rebuilt with pil32?
<Regenaxer>
Must find out if eg the Termux maintainer uses it
<Regenaxer>
should not be rebuilt
<Regenaxer>
unless you modified the time stamps of some source files
<Regenaxer>
But the .s files don't fit anyway, right?
<stacksmith>
OK, I think it is safe to say it is not working properly... As I am out of my league, I will have to wait till you fix it... Any thought on the timeline?
<Regenaxer>
well, no, they don't care about the sys/ stuff
<Regenaxer>
You could fix it for yourself easily
<stacksmith>
You think?
<Regenaxer>
just use the output of sysdefs
<Regenaxer>
with some editing
<stacksmith>
Happy to try
<Regenaxer>
cool
<stacksmith>
But not clear on the strategy.
<Regenaxer>
The rest is more an administrative or organizatorial issue
<stacksmith>
Should I replace sys/arm64.linux.defs.l with generated sysdefs?
<Regenaxer>
Just edit the sys/ file according to the values
<Regenaxer>
If it works, we can use it for the official Linux releases
<Regenaxer>
Just that I have this naming problem
<Regenaxer>
Not sure if something breaks somewhere if I change the names
<stacksmith>
should I change bufsiz
<Regenaxer>
But probably it is only me and the Termux maintainer Fredrik Fornwall who use it
<Regenaxer>
yes, BUFSIZ is the first
<Regenaxer>
according to your diff
<stacksmith>
OK, this will take a few minutes as my vim skills are near zero.
<Regenaxer>
no hurry
<Regenaxer>
next one is TERMIOS
<Regenaxer>
then SIGACTION ... SA_FLAGS
<Regenaxer>
then NI_NAMEREQD
<Regenaxer>
and AI_ADDR
<Regenaxer>
tata!
<Regenaxer>
that's all!
<stacksmith>
whew
<Regenaxer>
done? ;)
<stacksmith>
"/}{ro|isr/li open: No such file or directory"
<Regenaxer>
hmm
<stacksmith>
But the ? prompt is up.
<Regenaxer>
did you rebuild?
<stacksmith>
no...
<stacksmith>
as in make?
<stacksmith>
should I?
<Regenaxer>
do first $ rm *.o
<Regenaxer>
not a complete clean
<Regenaxer>
make clean also removes the *.s files
<stacksmith>
I noticed...
<Regenaxer>
:)
<stacksmith>
So here is what happes: there are a bunch of undefined references to __sF
<stacksmith>
also __errno
<Regenaxer>
ok, so there is more
<Regenaxer>
we need to change also arm64.linux.code.l
<stacksmith>
OK
<Regenaxer>
ok, then let's better wait
<Regenaxer>
I will try to install Debian on Arm64
<Regenaxer>
sigh
<Regenaxer>
I tried two years ago but never succeeded
<stacksmith>
I can give you access to the Pi - if there is an easy way to do it... hm...
<Regenaxer>
Thanks, but I want a local solution
<Regenaxer>
optimally in qemu
<Regenaxer>
is then in the backups etc
<stacksmith>
right. Sorry I am not more useful. I am happy to dick around like this, but it is suboptimal.
<stacksmith>
BTW, this is what happens - I get __sF and __errno undefined errors
<Regenaxer>
No, you helped a lot
<Regenaxer>
Still the binary ran?
<stacksmith>
If I rebuild the 32-bit pil and immediately rebuild the 64-bit one, it works with that garbage from pil.
<Regenaxer>
yes, this is strange
<stacksmith>
Yup, just compiles cleanly after 32-bit build
<Regenaxer>
cause it contains the _F too
<stacksmith>
and that strange line, which may be just garbage and not a real open error message?
<Regenaxer>
ah
<Regenaxer>
we must remove them?
<stacksmith>
The repl seems functional
<Regenaxer>
I misread the diff
<Regenaxer>
< (equ BUFSIZ 8192)
<Regenaxer>
---
<Regenaxer>
> (equ BUFSIZ 1024) 29a28,33
<Regenaxer>
> > (push '*Globals '__sF)
<Regenaxer>
> (equ stdin '__sF)
<Regenaxer>
> (equ stdout '(& (__sF 152)))
<Regenaxer>
> (equ stderr '(& (__sF 304)))
<Regenaxer>
this is *not* in the new version
<Regenaxer>
can you remove and try again?
<stacksmith>
right. One minute.
<Regenaxer>
makes sense
<Regenaxer>
my error, sorry
<stacksmith>
OK, should I delete .o and make?
<Regenaxer>
yes
<Regenaxer>
delete is not even necessary
<Regenaxer>
as the source is newer now
<stacksmith>
undefined references as before
<Regenaxer>
references to __sF ?
<stacksmith>
many to __sF, 2 to __errno
<stacksmith>
linking arm64.linux.base.o
<Regenaxer>
was that rebuilt too?
<Regenaxer>
__errno is clear, it is also in ..code.l
<Regenaxer>
but __sF should not
<Regenaxer>
better make rm *.o
<Regenaxer>
then only __errno should remain
<stacksmith>
I thought I did... Will try again.
<Regenaxer>
ok
<stacksmith>
No, still the same.
<Regenaxer>
where does __$F come from then
<stacksmith>
in function giveupX, execErrS, .39 and more
<stacksmith>
Also a warning from the assembler (I ignored it before, but maybe relevant to you)arm64.linux.base.s:5468: Warning: unpredictable load of register pair -- `ldp x29,x29,[x28],16'