ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
<tankf33der> next task
<Regenaxer> yeah, pathological
_whitelogger has joined #picolisp
rob_w has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
<Regenaxer> Found bug in 'size' of DB objects
<Regenaxer> Still more
<Regenaxer> Fixed
<Regenaxer> And transaction log fully tested
<tankf33der> released ?
<Regenaxer> yes, now
<Regenaxer> there were 2 bugs in size calculations
<Regenaxer> one was for symbol names > 7
<Regenaxer> and one for non-yet-fetched DB objects
<Regenaxer> A test case for symbol names > 7 was missing
<Regenaxer> I added one
<Regenaxer> (test 9 (bytes "abcdefgh"))
<Regenaxer> The wrong size calculation caused DB index nodes to become corrupted
<Regenaxer> really fatal
<tankf33der> passed.
<Regenaxer> thx
<tankf33der> i've created cheatsheet for fixedpoint math, very useful
<tankf33der> use it every time.
<Regenaxer> Very good
<Regenaxer> Perhaps add 'sqrt' too?
<Regenaxer> analog to division
<Regenaxer> : (round (sqrt 64.0 1.0))
<Regenaxer> -> "8.000"
<Regenaxer> And you should announce it somewhere
<tankf33der> :)
<Regenaxer> beneroth, if possible test your projects with pil21. You made things differently, so he chances are high you find bugs which I don't have
<beneroth> aye, will do
<Regenaxer> Great
<beneroth> though the things I do different is mainly that I use multiple inheritance a lot more. the rest is all building on top of the normal pilDB.
<Regenaxer> yes, but this results in different calling patterns
<beneroth> T
<Regenaxer> I found the bugs here only in practical tests
<beneroth> differences I have to take care of I can all find in the changelog, I presume?
<Regenaxer> ah, right
<beneroth> e.g. like the run argument
<beneroth> ok
<Regenaxer> I removed (forked) in apps
<beneroth> oh
<Regenaxer> this is the only typical change
<beneroth> ah okay
<Regenaxer> or I defined (de forked ()) depending on version
<beneroth> I think I haven't used (forked)
<beneroth> just the return value of (fork) itself
<Regenaxer> (forked) was needed after calling (task)
<beneroth> yeah
<Regenaxer> so that the task did not run in children
<beneroth> how do you do it now?
<Regenaxer> but pil21 clears *Run in (fork)
<Regenaxer> So nothing is needed
<beneroth> ah makes sense
<beneroth> yeah, good change
<Regenaxer> yeah, it was an impractical design
<beneroth> if it is already NIL, the cost is surely less than the switch from pil64 to pil21 itself :)
<beneroth> I mean: does not matter really
<beneroth> ah yeah, did you do performance benchmarks in your apps? pil21 vs. pil64 ?
<beneroth> I understand that some number crunching should be a much better in pil21, but general calling is probably a bit slower, aye?
<Regenaxer> No, I think there will be none.
<beneroth> ok
<Regenaxer> yes, correct
<Regenaxer> slightly
<Regenaxer> Then I checked (run ... <n>) and (eval ... <n>)
<Regenaxer> but no cases in apps
<beneroth> ok
<beneroth> yeah this ones I have to check
<Regenaxer> yes
<beneroth> I'm still heavily under water, so no idea when I will do this tests, but I try to do it soon(TM)
<Regenaxer> good, no hurry
<Regenaxer> I wont release to production soon
<Regenaxer> Only PilBox
<Regenaxer> but also no hurry
<Regenaxer> I will do local development with pil21
<Regenaxer> No harm if data are lost
<Regenaxer> In fact, PilBox with pil21 is already downloadable
<Regenaxer> But I won't release to software-lab and Google Play yet
<beneroth> ok
<Regenaxer> Hahaha! While testing *Zap / commit in pil21, I compared with pil64, and found a bug in pil64 !!!
<Regenaxer> (in pil21 it was correct)
<Regenaxer> pil64 crashes when closing the file
<Regenaxer> Wrong file descriptor
<Regenaxer> I released a new pil64
<Regenaxer> OK, DB deletion and garbage collection also seems good
<Regenaxer> free list, dbck and dbCheck
_whitelogger has joined #picolisp
<beneroth> lol
<beneroth> xD
<beneroth> see, its too early to switch. the older version is still not mature </irony> ;-)
<Regenaxer> Indeed
<Regenaxer> Also old stuff has its bugs ;)
<Regenaxer> It did not show up, cause I did not use *Zap and zap_ in projects since 2009 or so
<beneroth> *Zap ?
<beneroth> ah
<beneroth> I see
<beneroth> don't you use *Zap in your distributed database architecture?
<Regenaxer> only in certain cases
<Regenaxer> Only in the Smapper project iirc
<Regenaxer> Massively creating and deleting objects
<Regenaxer> and @lib/conDbgc.l
<Regenaxer> so objects were zapped in other processes and deletion needed to be delayed
<beneroth> Smapper? was that the huge sensor data processing thingy?
<Regenaxer> yes
<beneroth> makes sense
<Regenaxer> not sensors but file server metadata
<beneroth> ah
<Regenaxer> Normally, an application never calls 'zap', and delays it to 'dbgc'
<Regenaxer> s/delays/delegates
<beneroth> T
<beneroth> oh maybe run the concurrent dbgc for testing purpose?
<Regenaxer> yes, might be a good idea
<Regenaxer> but I tested the zap functionaliy manually
<Regenaxer> There is not much about it
<Regenaxer> once tested, there is not much to fail
<Regenaxer> Obviously I never tested in pil64
<Regenaxer> (Smapper was still pil32)
<beneroth> yeah right
orivej has joined #picolisp
rob_w has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 256 seconds]
Blukunfando has quit [Ping timeout: 272 seconds]
orivej has joined #picolisp
<beneroth> Regenaxer, (mapcar pack (mapcar clip Lst)) or (mapcar '((E) (pack (clip E)) Lst) ?
<beneroth> I figure second would be better, as it has lower number of function calls. but first has less cells and the func is a builtin
<Regenaxer> I would also say the second. Mainly because only one list is built
<beneroth> yeah, that also!
<Regenaxer> Not much difference I think
<Regenaxer> perhaps depends on the list length
<beneroth> T
<Regenaxer> I alway try to avoid building a list whih is then processed and thrown away
<Regenaxer> i.e. destructive ops in the following steps
<beneroth> T
<beneroth> (make (for E Lst (when (pack (clip E)) (link E))) even better then?
<beneroth> less function calls
<beneroth> vs. (extract '((E) (pack (clip E))) Lst)
<Regenaxer> right, 'for' is more efficient
<Regenaxer> (if a single list)
<beneroth> T
<Regenaxer> But I think I'd use 'extract' here
<Regenaxer> more readable
<beneroth> T, me too
<Regenaxer> But you are right, the funcall overhead is relatively large
<beneroth> it's some minor input processing here, not an main event handler stuff :)
<beneroth> it depends. context matters. :)
<Regenaxer> exactly
<beneroth> picolisp programming lowers likelyhood to be automated out of job :P
<Regenaxer> :)
<beneroth> automates SQL out of the job (or so is the plan, harhar)
<Regenaxer> hehe
<tankf33der> solved
<tankf33der> http://ix.io/2AIR
<Regenaxer> Wow!
<Regenaxer> Cool
<Regenaxer> :)
<tankf33der> :)
<tankf33der> pil21 ok too
<Regenaxer> Great
<Regenaxer> Well done! :)
orivej has quit [Read error: Connection reset by peer]
orivej has joined #picolisp