IRC channel logs

2018-06-21.log

back to list of logs

<snape>does anyone know a way to autoformat one-line Scheme code? The minimum so that it's readable.
<snape>(with Emacs)
<cehteh>replace every ( with (\\n, then select the while block and M-x indent-region
<cehteh>whole
<snape>sounds good, I'll do that. Thank you!
<cehteh>certainly not perfect :D
<cehteh>and \\n( rather than (\\n .. well i am scheme noob and dont get the favored indenting either
<snape>it'll be surely better than one line :-)
<ecraven>or just use your Scheme's pretty-print function
<snape>ecraven: cool! thank you
<ecraven>also, in Emacs, auto-fill-mode seems to work ok for me
<ecraven>just set your fill column, and type a space after your line
<snape>a combination of both solutions, plus indent-region, seems to more or less do the job :-)
<civodul>wingo: scm_i_vm_mark_stack can be called from a thread other than the one whose stack is being scanned, right?
<civodul>so what happens if thread A is running, while thread B is scanning A's VM stack?
<wingo>civodul: mark procedures run when the world is stopped
<wingo>civodul: the vp->sp and vp->fp will always be current
<wingo>vp->ip might be out of date though. for that reason the innermost (most recently pushed) stack frame is scanned conservatively
<wingo>but for the rest, the saved return address in each frame indicates the suspended ip, so those frames are scanned precisely
<wingo>if instead of using signals, we used safepoints, we could scan innermost frames precisely as well; not currently the case tho
<wingo>additionally, things that munge the stack like vm_expand_stack, continuation hacks, etc happen within the alloc lock, so no race condition there
<wingo>i.e. a mark from a remote thread will see the stack before or after expansion, not during
<wingo>speaking about the ideal world that we don't yet have: ideally threads would mark their own stacks, when they notice that there's a pending gc safepoint. improves locality.
<wingo>but, we are where we are :)
<wingo>incidentally the whole c file refactoring was driven by a desire to inline struct scm_vm into struct scm_thread; they exist in a 1-to-1 relationship
<civodul>wingo: thanks for the explanations!
<civodul>i'm trying to find out how we can end up with cells being reclaimed too early
<wingo>have you been able to come up with a reproducible test case?
<civodul>i have a bunch of them :-)
<wingo>:)
<civodul>some take a while to reproduce it, others are faster but require bits of Guix
<civodul>no perfectly reduced test case unfortunately
<civodul>wingo: i don't see the special treatment of the innermost frame in scm_i_vm_mark_stack
<wingo>civodul: slot_map will be NULL on first iteration
<wingo>if you suspect slot maps are to blame, you can make slot_map NULL on every iteration, to test
<civodul>oh i see
<civodul>yes
<wingo>i see that gnutls has mark and free functions for its smobs. can you get rid of the mark functions?
<wingo>is gnutls loaded in the test cases you have?
<civodul>hmm i don't think so
<civodul>what's the gdb incantation to leads the loaded .so files again?
<civodul>ah, "info sharedlibrary"
<civodul>well it is loaded
<civodul>however in GnuTLS the mark free functions are for 1.8 only
<civodul>hmm
<civodul>or maybe not
<wingo>maybe you can remove support for 1.8 at this point, dunno
<wingo>might not fix the issues, of course!
<civodul>yeah
<wingo>ACTION brb
<civodul>with 'desc' set to SLOT_DESC_LIVE_SCM unconditionally, it still crashes, though perhaps slightly less frequently (hard to say)
<civodul>so find_slot_map for 'subr_stub_code' returns NULL, right?
<wingo>sneek: later tell civodul yes, find_slot_map for subr_stub_code returns null
<sneek>Got it.
<sahithi-ihtihas>ERROR: In procedure iota: Wrong type argument: #("phase foo failed after 100 seconds" (0 . 34) (0 . 5) (5 . 10) (10 . 22) (22 . 27) (27 . 34))
<sahithi-ihtihas>what might be the reason for this error
<OrangeShark>sahithi-ihtihas: iota expects a number while the argument was not a number
<sahithi-ihtihas>understood...Thank you
<sahithi-ihtihas>how do i get range using iota??
<sahithi-ihtihas>(define (range from to) (map (lambda (x) (+ from x)) (iota (- to from))))
<sahithi-ihtihas>(range 5 10)
<sahithi-ihtihas>without a seprate definition like this
<OrangeShark>so you want a list (5 6 7 8 9)?
<sahithi-ihtihas>yeah
<daviid>sahithi-ihtihas: iota accepts a start
<daviid>and a step
<daviid>sahithi-ihtihas: look for the definitin in the manual tehere ar a few examples as well
<OrangeShark>(define (range from to) (iota (- to from) from))
<OrangeShark>(iota count start)
<daviid> ,use (srfi srfi-1)
<daviid> (iota 5 5)
<daviid>$3 = (5 6 7 8 9)
<OrangeShark>oh hmm, there is a stream-range procedure
<OrangeShark>that basically does this, would be nice to have a normal list range version
<OrangeShark>in srfi-41 is the stream version
<rekado_>sahithi-ihtihas: note that there are *two* implementations of iota.
<rekado_>sahithi-ihtihas: srfi-1 provides the more advanced implementation that accepts a start and step value
<sahithi-ihtihas>Thank you OrangeShark and daviid
<sahithi-ihtihas>rekado_: Ohh
<OrangeShark>rekado_: I can only find the srfi-1 version
<OrangeShark>where is the other?
<daviid>OrangeShark: the guile core, if you do not import srfi-1, it will raise an exception if you pas ore then one arg ...
<OrangeShark>oh hmm, it not documented at all in the manual
<sahithi-ihtihas>but when i give this kind (iota 1 5) ??why dont i gt same result?
<sahithi-ihtihas>i expect (1 2 3 4) as output
<daviid>sahithi-ihtihas: becaue unlike yout range procedure, iota expect the count as its first arg, not from
<daviid>(iota 4 1)
<sahithi-ihtihas>but that includes 5
<daviid>it works like this: give that 'count' many numbers, starting with ... and using step to compute the next values ...
<daviid>scheme@(guile-user)> (iota 4 1)
<daviid>$4 = (1 2 3 4)
<OrangeShark>oh, totally forgot I had guile installed on this computer :)
<sahithi-ihtihas>I am somewhere looking around for range kind implementation.....anyways thank you so much
<daviid>sahithi-ihtihas: np! but iota is fine, yu'll get use to it :)