<fbytez>
It seems that `(char)` and `(peek)` skip single NULL bytes and return NIL on consecutive ones;
<fbytez>
`(line)` seems to read them as any other character;
<fbytez>
`(from)` seems to pay them no attention;
<fbytez>
`(till)` will always stop at a NULL.
<abu[m]>
This may well be. As I said, a null byte is not expected in an input stream. Thus it is used as "uninitialized" for the internal $Chr global variable.
<fbytez>
I would've thought that `(line)` and `(from)` were implemented in terms of `(char)` and `(peek)`, yet the behaviour is different.
<abu[m]>
They all use $Chr, but do not really call (char) or (peek)
<fbytez>
Why do they treat the (= $Chr 0) differently?
<abu[m]>
Basically, $Chr is checked before every read operation, and if zero, a prefetch triggered to fill it first
<abu[m]>
Stress here on *before*
<abu[m]>
i.e. to handle a freshly opened stream
<abu[m]>
after that, $Chr is assumed to hold a non-zero byte
<fbytez>
Yeah, I'm not understanding why `(line)` doesn't skip but `(char)` and `(peek)` do.
<fbytez>
Well, and `(line)` doesn't get "interrupted".
<fbytez>
How do I unsubscribe from the mailing list?
fbytez has left #picolisp [Leaving]
rob_w has quit [Quit: Leaving]
zaWanderer has joined #picolisp
seninha has joined #picolisp
<zaWanderer>
hihi
<abu[m]>
Hi zaWanderer @zaWanderer:libera.chat
<zaWanderer>
hi abu. I have a conceptual question.
<abu[m]>
ok
<zaWanderer>
Is there a way or any benefit from writing the db rel specs in Pilog format?
<abu[m]>
Interesting idea
<abu[m]>
You mean (rel var (+Cls) ... etc.?
<zaWanderer>
yes
<zaWanderer>
I see this spec as my model. And I want to grow it/refine it with time
<abu[m]>
Writing as Pilog clauses means they would be unified later
<abu[m]>
Currently they simply run and create relation objects
<abu[m]>
there was no need for searching which is typical for evaluating Pilog clauses
<zaWanderer>
I see.
<abu[m]>
growing/redefining can be done with subclasses, inheritance and overriding
<zaWanderer>
you mean it is better to write my rules/limits for the class and its relations through subclass, inheritance, and overriding?
<abu[m]>
Not sure if it is better. Perhaps your idea is even better
<abu[m]>
Currently it is done with these OOP methods
<zaWanderer>
I see the db rel specs as a business rulebook/contract
<abu[m]>
yes, me too
<abu[m]>
The entities and relations are the core of an application, the model
<abu[m]>
I always start with er.l and use it as the main ref
<zaWanderer>
yes, but I am unable to figure out the best way to put boundaries and limits. I think the limitation is in me since I am an engineer and not a computer scientist
<zaWanderer>
how to better apply boundaries or rules to the er.l
<zaWanderer>
some cases is that I want the values of one rel to be OneOf, etc..
<abu[m]>
In such cases I define a method
<zaWanderer>
I thought that Pilog statements would help here, but maybe I am not finding the right approach yet
<zaWanderer>
ok, and when do you run these methods? say from the GUI?
<abu[m]>
Boundaries are perhaps too simple to use a Pilog machinery for them
<abu[m]>
I have usually check> methods
<abu[m]>
They are called by the GUI in certain situations, like printing or closing entities
<abu[m]>
Another place is overriding the upd> method for +Entity
<abu[m]>
It can do checks and trigger side effevts like modifying other attributes of the entity
<abu[m]>
upd> is called whenever an entity changes
<zaWanderer>
chnages in GUI or in db?
<abu[m]>
in db
<abu[m]>
so also if db changes are caused from GUI
<zaWanderer>
oh, so this is more suitable for triggering other side effects once it changed
<abu[m]>
Yes
<zaWanderer>
and check> would do soemthing more of actions before writing to db?
<abu[m]>
exactly
<zaWanderer>
ok, that's definitely worth studying more in details. many thanks
lagash has joined #picolisp
<abu[m]>
Let me copy some fragments as an example
<zaWanderer>
I am trying to organically populate entitites based on how are they related in db
<zaWanderer>
sure, please do :)
<abu[m]>
I don't find a really simple example, but how about this: http://pb1n.de/?241bf4
<abu[m]>
The check> method returns a possibly empy list
<abu[m]>
with a list of error strings
<abu[m]>
(note ,"View not possible" (uniq @)) displays an error dialog
<abu[m]>
I often have a whole hierarchy of check> methods
<abu[m]>
They call each other with (super), accumulating a diagnostic list)
<zaWanderer>
Thanks abu. I will study these examples, and come back to you if needed :)
<abu[m]>
Great!
zaWanderer has quit [Quit: Leaving]
<beneroth>
nice discussion
<beneroth>
I would use relation prefix classes, maybe create additional ones, but used in same as form.l uses +Mis, +Need, etc. :)
<beneroth>
I think that is the right approach. be flexible on the bottom layer, be more restricted on the top layer. the higher up a layer, the more likely it is subject to unforeseeable changes
<beneroth>
similar to how the most bottom layer of pilDB is plio, then key/value store, then entities and objects, and then index trees.
<beneroth>
the lower down a layer, the fewer and more basic but also the more flexible/reusable are the lego blocks. the higher up, the more restricted and specific the lego blocks which in turn are assembled/based on lego blocks from a lower layer.