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 quit [Ping timeout: 256 seconds]
<tankf33der> task is long.
<Regenaxer> Seems so
<Regenaxer> I have still segfaults
<Regenaxer> and the DB is not tested in all aspects
<Regenaxer> The DB is really the critical part. If here is a fault, e.g. in garbage collection, we will lose data
<tankf33der> i am running tests every day :)
<tankf33der> all passed so far
<Regenaxer> yeah, good thing
<Regenaxer> But many things are not tested I think
<Regenaxer> eg the internal DB structures, block lists, clean ups
<Regenaxer> Conflicts in acces by parallel processes
<Regenaxer> replication
<Regenaxer> I tested the transaction journal, but not fully yet
<Regenaxer> hard to test, must be interrupted inside a 'commit'
<Regenaxer> and then binary compared to the db files before starting the commit, to see if every block is restored to the old state
<tankf33der> you could add all these variations to pil21/test files
<tankf33der> the same as minimal stress file too
<Regenaxer> Yeah, I'm thinking, but hard
<Regenaxer> First I want to find the reason for the segfaults
<Regenaxer> The transaction journal think cannot be tested the normal way
<Regenaxer> Needs modifications in the core system, to exit from 'commit' at various places
<Regenaxer> This *can* of course be automated
<Regenaxer> but it is not worth the effort
<Regenaxer> Normally, once it is tested, the code won't change
<Regenaxer> In pil64 it did not change for 10 years
<tankf33der> does one change could brake another part?
<Regenaxer> Depends I think
<Regenaxer> We can never be sure ;)
<tankf33der> you adding tests protect against these things
<tankf33der> it be sure its not broken after testing
<Regenaxer> As I said, it is extremely difficult
<Regenaxer> Needs patches to the source of 'commit'
<Regenaxer> In various places
<Regenaxer> Then create and reset database files
<Regenaxer> A huge project by itsenf
<Regenaxer> For testing about 20 lines of code
<Regenaxer> I do not believe very much in automated tests
<Regenaxer> What is needed is deep inspection of the code
<Regenaxer> You *cannot* test all aspects
<Regenaxer> And once a certain part is secure, you can be sure it will not break
<Regenaxer> Where is the limit of testing? You *must* believe in certain parts
<Regenaxer> E.g. if you test (+ 3 4) -> 7
<Regenaxer> Then will you test *all* numbers?
<Regenaxer> No, cause you know something about the behavior of code
<Regenaxer> I always test only things where I'm not sure about
<Regenaxer> One must *believe* in one's own code
<tankf33der> i see. sounds good.
<Regenaxer> After all, the picolisp core system is small
<Regenaxer> The current crashes are related to coroutines somehow
<Regenaxer> perhaps in interaction with catch/throw
orivej has joined #picolisp
<Regenaxer> I can reproduce, but it is hard to locate where exactly it goes wrong
<Regenaxer> Only in printing in the demo app
<Regenaxer> I changed the printing routine to the new standard, using a coroutine
<Regenaxer> And first print is ok, but second crashes
<Regenaxer> strange ;)
<Regenaxer> If I test isolated parts of the routine, all works. Only in total it fails
mtsd has joined #picolisp
<Regenaxer> Hi mtsd!
<mtsd> Hi Regenaxer!
<mtsd> How are you today?
<Regenaxer> mtsd, yesterday I told you that that the app demo uses a namespace
<Regenaxer> but I forgot that app is not included in the release any longer
<Regenaxer> it is now a separate tarball
<mtsd> Thanks!
<Regenaxer> I'm just struggling with the printing, it still crashes on certain circumstances
<mtsd> I noticed it was missing, but then I got tied up with lots of other stuff
<Regenaxer> OK :)
<mtsd> Downloading app now :)
<Regenaxer> good
<Regenaxer> Mainly only main.l and lib.l changed
<Regenaxer> main.l for the 'ap' namespace
<Regenaxer> and lib.l for the new recommended printing, using a coroutine
<Regenaxer> I use that in all projects with svg
<Regenaxer> but in pil21 it still crashes
<mtsd> I copied one of my production apps to my local pil21 install. I can experiment there
<Regenaxer> Cool!
<mtsd> Somewhat changed way to start the apps in pil21? Including the namespace with the function name? "pil app/main.l -ap~main -'ap~go 4040' +"
<mtsd> Instead of the old "pil app/main.l -main -go +
<Regenaxer> yes
<Regenaxer> See the comment in app/main.l
<Regenaxer> second line
<mtsd> Looks nice
<Regenaxer> :)
<mtsd> The distribution seems cleaner, in a way, with pil21
<mtsd> Just I feeling I get looking through it
<Regenaxer> yes, a lot smaller at least
<mtsd> Even smaller, you mean? ;)
<Regenaxer> The sources are smaller, as ASM is longer code
<Regenaxer> and I'll leave out lots of old examples
<Regenaxer> or make them separate like app/
<Regenaxer> The doc/ will be there
<Regenaxer> want to update some parts, they are still pil32
orivej has quit [Ping timeout: 260 seconds]
<Regenaxer> Yeah, it is a coroutine problem. If I comment 'co' and 'yield', it works
<Regenaxer> tough
<Regenaxer> So the coroutine works, but leaves the system in a corrupted state, and the second printing pass crashes
<mtsd> Sounds tough to me
<Regenaxer> to me too
<Regenaxer> coroutines are one of the complicatest parts in pil
<mtsd> Hard, I'm not competent enough to debug such deep things
<Regenaxer> no worry :)
<mtsd> I will probably have to settle in my place as an application programmer, and leave the system development to the real professionals :)
<mtsd> But still, it is fun to be around when something new emerges, like pil21
<Regenaxer> Glad to hear :)
<beneroth> mtsd, where would you see the difference between application and system programming?
<beneroth> isn't that another arbitrary artificial split like "front-end" and "back-end" ?
<beneroth> for me, different areas of programming taste differently, but in essence it is all programming. the differences are on the surface, but the essence is the same.
<beneroth> in system programming you might care more about individual bits and off-by-one-errors, but then you can have a clear sight of your stack vs. some of todays application programming which is just mountains of dependencies
<beneroth> in the end you have to work with things you don't fully grasp (yet) and have to cling to the parts you can identify as familiar
<mtsd> Hi beneroth!
<mtsd> Maybe there is not much difference? Or am image difference perhaps, system programming being the hard, low-level stuff and application programming the higher level, easier stuff for us mere mortals?
<Regenaxer> You are rigth beneroth
<mtsd> That difference would be a personal one, for every programmer. Different people finding different things hard or easy
<beneroth> T
<beneroth> I find system programming is way easier
<mtsd> The hardest parts can be the users, finding out what they want and what they need.
<beneroth> less structures, less "what is right what is wrong" which on application layer is a question of UX, arbitrary library "standards" etc.
<mtsd> That can be way harder than satisfying the machine :)
<beneroth> yeah, they never know what they want. If they know, then it's not what they need.
<beneroth> or at least not as you would understand them as technician.
<beneroth> but I think the same things which make one a good system programmer makes one a good app programmer: asking why. why does the user need it, and which ways would fit him and which not?
<beneroth> why this library and not the other? why this byte structure?
<Regenaxer> But frontend requires "design", aka "beauty", and that's what I have no feeling for
<mtsd> Me neither.
<mtsd> And who's idea of beauty? Hard question
<beneroth> design has two parts: purpose and beauty
<beneroth> beauty is taste, and fashion, and a bit of science e.g. what colors mixed signal what to humans...
<beneroth> but the important part is purpose. which boils down to having a reason for everything.
<beneroth> iphones have rounded edges not just for the looks, but so they glide better into the pocket
<beneroth> design without purpose is just art. ;-)
<beneroth> and so again it boils down to many why-questions (3-year-olds style): why button on the left and not on the right of the input field? does the user need to see the input field before deciding to press the button or not? if yes, then put the button on the right, as it is more in line with left-to-right reading direction (unless the user is from a right-to-left culture...)
<beneroth> good UX is not a matter of taste
<beneroth> or opinion
<beneroth> most designer don't get that (if they never educated/studied it for real). most design is bullshit.
<Regenaxer> agreed :)
<beneroth> so don't feel bad as programmers when trying to do it. just try. and try to reason why you do it the way you do it.
<beneroth> the problem of good UX, good design in general (including software design): if its well done, it is never noticed.
<beneroth> (unless someone trained with an eye for such things has a focused look on purpose)
<beneroth> users are not able to tell you why they like one software over the another.
<mtsd> I agree. That should be somthing of a guiding principle. Try to make software that goes unnoticed
<mtsd> Just does the job
<beneroth> aye
<beneroth> suckless
<beneroth> the problem in business environment is of course that good design hardly gets appreciated.. well certainly more than software design and infrastructure stability, but still...
<beneroth> if things don't "feel right" the next fashion is chased
<beneroth> oh wow, it is even true for infrastructure/software/system design.. think of cloud
<beneroth> this IT doesn't work. lets outsource everything. lets go cloud. that will solve all our problems.
<beneroth> "why/how?" "no idea, it does for everyone else, no?" (truth is, it does for a specific group with very specific needs, not for the majority)
<beneroth> problem is, asking why a lot doesn't mix well with enteprisey workplace social games :P
<Regenaxer> I'm now boiling down app/lib.l to its essentials, until I know exactly what goes wrong
<Regenaxer> Got it! A one-liner
<Regenaxer> (catch 'stop (co 'gen1 (yield T)) (throw 'stop))
<Regenaxer> It segfaults if this is executed a second time!!
<beneroth> that was quick
<Regenaxer> Well, took quite some time
<Regenaxer> But it is straightforward
<Regenaxer> Start with a copy of app/lib.l, and remove things
<Regenaxer> if it does not crash, undo and remove other stuff
<beneroth> T
<beneroth> as every debugging :P
<Regenaxer> yes
<beneroth> even UX.. take stuff away until it stops being usable ^^
<Regenaxer> :)
<Regenaxer> And another (probably unrelated) bug: Just (co 'a) by itsesf segfaults too
<beneroth> yeah negative tests should be done too ;-)
<Regenaxer> right
<Regenaxer> though (co 'a) is a valid call
<Regenaxer> it *stops* the coroutine 'a'
<Regenaxer> This works:
<Regenaxer> $: (co 'a (yield T))
<Regenaxer> -> T
<Regenaxer> $: (co 'a)
<Regenaxer> -> NIL
<Regenaxer> But if 'a' does not exist it crashes
<Regenaxer> no
<Regenaxer> it crashes if there was never a coroutine created
<beneroth> reliable crashes are acceptable outcomes. random behaviour is not acceptable.
<Regenaxer> indeed
<Regenaxer> ok, this one is fixed
<Regenaxer> Now the tough one
<Regenaxer> It crashes only if 'a' is the *first* coroutine
<Regenaxer> This is good news, catch/throw interaction with coroutines is not completely wrong ;)
<beneroth> :)
<Regenaxer> Seems I fixed it :)
<Regenaxer> No change in code, only global data structure
<beneroth> nice
<Regenaxer> The Coroutines chain root must be inside the 'env' maintained during catch/throw
<Regenaxer> Released. Any test results welcome
<tankf33der> running test suite under llvm7 while having a lunch.
<Regenaxer> Great!
<beneroth> awesome!
<Regenaxer> Nice! Lunch there?
<tankf33der> yea and beer.
<Regenaxer> Perfect
<tankf33der> passed.
<Regenaxer> Thanks!
orivej has joined #picolisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
mtsd has quit [Quit: Leaving]
<Regenaxer> DB crashes
<Regenaxer> Will debug tomorrow
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
anddam has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
anddam has joined #picolisp