beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
seninha has quit [Quit: Leaving]
hrberg has quit [Ping timeout: 250 seconds]
hrberg has joined #picolisp
rob_w has joined #picolisp
beneroth has quit [Ping timeout: 276 seconds]
beneroth has joined #picolisp
seninha has joined #picolisp
<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".
<abu[m]> It is all a consequence of the above
<abu[m]> They do not "skip"
<abu[m]> They just fill on the first call
<abu[m]> (vi 'line)
<abu[m]> ... (unless C (setq C (call $Get))) ...
<abu[m]> Similar in all reading functions
<abu[m]> (de read1 ((i32 . End)) (unless (val $Chr) (call $Get) )
<fbytez> I mean in the sense that `(line)` "provides" the NULLs whereas the others are "interrupted"; can't determine EOF.
<abu[m]> As (char) and (peek) handle only one single char, this test happens upon each call
<abu[m]> I don't remember the details of (line) atm
<abu[m]> (out "a" (wr 65) (wr 0) (wr 66) (wr 10))
<abu[m]> (in "a" (line)) -> ("A" NIL "B")
<abu[m]> Anyway, this is undefined behavior
<fbytez> It's not something you'd ever change?
<abu[m]> Never ever ☺
<fbytez> That's unfortunate.
<abu[m]> You can produce tons of illegal input
<abu[m]> It is not only the null bytes
<abu[m]> Why care? Garbage in, garbage out
<fbytez> Security experts could give you better answers than me.
<fbytez> That aside, why waste time processing garbage as though it's not?
<abu[m]> It is not a security issue
<fbytez> "Fail fast".
<abu[m]> No! Why waste time checking for thins which should be checked at better places
<abu[m]> In 99% percent you are *sure* there is no null byte. Why check each time?
<abu[m]> Do you also check that after adding 3 and 4 it is *really* 7 ?
<fbytez> Depends on how it has supposed been determined.
<abu[m]> If you generated the data, they are OK. Period. If they might be damaged during transmission, you need general integrity checks
<fbytez> "IF"
<abu[m]> not at hoc stupid isolated checks
<abu[m]> Come on!
<fbytez> "Come on" indeed. A server doesn't mostly receive data that it generated itself.
<abu[m]> Then they must be checked in an intelligent way. Not at the low level byte reading.
<fbytez> Byte is what all the data is.
<abu[m]> But not only null bytes
<fbytez> Indeed.
<abu[m]> If a client sends garbage, it may be wrong data
<abu[m]> Or non-UTF
<abu[m]> doesn't matter
<fbytez> Yep. It has be parsed / validated / whatever.
<abu[m]> Pil does not crash, just the user's data are garbage
<abu[m]> You are free to modify pil input Have fun!
<abu[m]> I think this is not a security problem. It is all about the semantics of user data.
<abu[m]> It may be all legal digits, but still the numbers might be wrong
<abu[m]> There is no general check to be hardcoded, and which then eats CPU time every time
<abu[m]> Then, the next problem is that if you abort at such a low level, it is very hard to handle at the higher application levels
<abu[m]> Have you ever written a real practical application?
<abu[m]> And do you know what "premature optimations" are?
<fbytez> Do you know how sensitive, defensive and rude you are?
<abu[m]> Oops, no, I don't know. Sorry!
<abu[m]> I just asked you
<abu[m]> Your views are typical for academic text books, from authors who never wrote a real program ;)
<abu[m]> So I assumed you are a student
<abu[m]> Perhaps I'm rude because all this is totally opposite the PicoLisp philosopy
<abu[m]> hex-parsing, http header line length, null-bytes. PicoLisp is pragmatical, not fundamentalistic.
<fbytez> I think it's time to say goodbye.
<abu[m]> OK, sorry!
fbytez has left #picolisp [Leaving]
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
<beneroth> ¯\_(ツ)_/¯
<abu[m]> yo
<abu[m]> Perhaps I was too rude. But I was more and more annoyed by being urged to useless "correctness" demands.
<beneroth> haskell programmers ¯\_(ツ)_/¯
<abu[m]> sigh
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
seninha has quit [Ping timeout: 256 seconds]
fbytez has joined #picolisp
<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> 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
lagash has quit [Quit: ZNC -]
<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:
<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.
<beneroth> stratified design as eric calls it