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
aw- has joined #picolisp
_whitelogger has joined #picolisp
orivej has quit [Ping timeout: 272 seconds]
_whitelogger has joined #picolisp
<Regenaxer> beneroth, thought so too, but she says it is as before
_whitelogger has joined #picolisp
<tankf33der> Regenaxer: send me code which works in single process and i will try to check via gc+
rob_w has joined #picolisp
<Regenaxer> ok, good
<Regenaxer> http://ix.io/2zM0
<Regenaxer> I run it as:
<Regenaxer> $ ./pil <file> +
<Regenaxer> Gives immediately:
<Regenaxer> (355 . {46}) -- dat mismatch (2)
<Regenaxer> But I'm sure it is not a gc+ issue
<tankf33der> ок
<Regenaxer> it is gc *related*
<aw-> hi Regenaxer tankf33der
<Regenaxer> if I do -'gc 777' then no error
<Regenaxer> it is gc running in between which loses data I think
<Regenaxer> hi aw-!
<Regenaxer> Does anybody have an idea about the grub issle I posted yesterday?
<Regenaxer> s/issle/issue ;)
<Regenaxer> rob_w, home office today?
<Regenaxer> can I call you?
<aw-> grub
<aw-> one sec i'll check the logs
<Regenaxer> Thanks!
<aw-> Regenaxer: grub2?
<Regenaxer> I have only a screenshot of the error
<Regenaxer> it says grub
<Regenaxer> "grub-efi-amd64-signed"
<Regenaxer> She re-installed Mint
<aw-> ohh she can't boot?
<Regenaxer> Ah, wait
mtsd has joined #picolisp
<Regenaxer> on the bottom it says Grub2
<aw-> can she type?
<Regenaxer> She can boot, but doesn't get the choice of OSes any more
<Regenaxer> only Windows
<Regenaxer> Before she re-installed, all worked
<aw-> hmmm
<Regenaxer> So the whole Mint installation ran through
<Regenaxer> only in the final step
<aw-> could be a BIOS secureboot thing.. would need to turn that OFF in the bios
<Regenaxer> when istalling Grub
<Regenaxer> ok, she did I think. I ask once more
<aw-> this kind of stuff is impossible to debug remotely
<Regenaxer> indeed
<rob_w> Hi Regenaxer , I can call u ,. iam at my office but no worries ok ?
<Regenaxer> great, thanks!
<beneroth> Windows update might have overwritten grub, windows update likes to do this
<Regenaxer> Thanks beneroth!
<Regenaxer> Yeah, just heard the same from Robert
<Regenaxer> In this case, there was no Win update in between
<Regenaxer> We will find out :)
<Blukunfando> I’m surprised it doesn’t also overwrite the other operating system at this point.
<Regenaxer> Only the boot loader is gone. Windows is in another partition
<Regenaxer> I'm just glad that I never had to use Windows
<beneroth> Blukunfando, usually it's just overwriting the Master Boot Sector, not touching other partitions
<tankf33der> Regenaxer: right single process fails without crash under gc+
<Regenaxer> yeah
<tankf33der> looks like gc does not respect external symbols and genocide them.
<tankf33der> thats why (gc 32) saves. running it now under gc+
<tankf33der> no, (gc 32) fails too.
<Regenaxer> The heap needs to be big enough so that gc does not run in the wrong moment
<Regenaxer> This part of 'gc' is really hard to debug
<tankf33der> (gc 128) now
<Regenaxer> gc in general
<Regenaxer> cause the heap is in an itermedite state
<Regenaxer> Have not found time yet to dig deeper into it
<Regenaxer> Cool, now I hear that with Mint 20 it all worked now! Thanks a lot to all!!
<Regenaxer> Still stange ...
<tankf33der> code itself i small, (gc 32) should be enough not to run ever.
<Regenaxer> It is not the code
<Regenaxer> the DB data
<tankf33der> : (load "2zM0")
<tankf33der> [2zM0:42] 335 -- val mismatch (2)
<tankf33der> ?
<tankf33der> btw, error text is different from yours
<Regenaxer> Different errors all the time. Random
<Regenaxer> I must find a much simpler case
<Regenaxer> only 2 or 3 external symbols
<Regenaxer> then call gc and see what it does
<Regenaxer> This code is extremely tough, it traverses the $Extern tree by modifying it to avoid stack usage
<Regenaxer> Lines 107 through 215 in src/gc.l
casaca has quit [Ping timeout: 240 seconds]
casaca has joined #picolisp
<Regenaxer> Found one error!
<Regenaxer> Not sure if this is the only one
<Regenaxer> At least much better now. The above simple test passes
<Regenaxer> misc/stress also passes in the main part, just the replicated DB differs, but that is probably another issue
_whitelogger has joined #picolisp
<tankf33der> Regenaxer: same here
<Regenaxer> ok
<tankf33der> all tests passed.
<Regenaxer> Thanks!
orivej has joined #picolisp
mtsd has quit [Quit: Leaving]
rob_w has quit [Remote host closed the connection]
<Regenaxer> tankf33der: ../<oldpil>/misc/stress.l now seems to pass
<tankf33der> did you released something new since afternoon?
<Regenaxer> Yes, just now
<tankf33der> ok
<Regenaxer> I let it run more often now with varying random seed
<Regenaxer> and also more processes (standard is 40)
<tankf33der> did you add stress.l in distr?
<Regenaxer> Not yet
<Regenaxer> I use the one from oldpil
<tankf33der> ok
<Regenaxer> Now running with 120 processes
<Regenaxer> stress.l main purpose is to stress IPC
<Regenaxer> hmm, ok: Pipe error: Too many open files ;)
<Regenaxer> not an IPC issus, but I'm wondering why
<Regenaxer> A file descriptor leak?
<Regenaxer> Trying the same with old pil
<Regenaxer> pil64
dexen has joined #picolisp
<tankf33der> stress.l passed here too.
<Regenaxer> with oldpil it passes with 120 processes
<Regenaxer> So we have a FD leak in pil21
<Regenaxer> Probably pipes to children not closed
<Regenaxer> And I have another strange thing: ^Z in Vip works only *once*
<Regenaxer> After 'fg' in bash all signals seem to be ignored
<Regenaxer> Strangely only in Vip, not in normal pil21 REPL
<Regenaxer> I thought it is (key), but this also behaves cirrect in REPL
<Regenaxer> So I wonder what is special in Vip?
<Regenaxer> ok, it is not only Vip. Also if (key) is called in a 'load'ed script and ^Z is pressed
<Regenaxer> Ha! Fixed it! :) It is related to readline() initialization
<Regenaxer> Lots of progress today! ☺
<Regenaxer> Next days fix the IPC pipe leak
_whitelogger has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]