IRC channel logs


back to list of logs

***aweinsto1k is now known as aweinstock
***duncanm_ is now known as duncanm
***sneek_ is now known as sneek
***berndj-blackout is now known as berndj
*wingo just landed ,optimize-cps, finally
<civodul>wingo: oh, that can be handy
<wingo>is quite verbose; could be better perhaps
<wingo>can be interesting
<wingo>scheme@(guile-user)> ,opt (let ((x (cons (cons "x" (cons 42 '())) '()))) (string? (car (car x))))
<wingo>$1 = (let ((x (list (list "x" 42))))
<wingo> (string? (car (car x))))
<wingo>scheme@(guile-user)> ,optimize-cps (let ((x (cons (cons "x" (cons 42 '())) '()))) (string? (car (car x))))
<wingo>L0: ; at <unknown>:2:61
<wingo> v0 := self
<wingo> L1(...)
<wingo> receive()
<wingo> v1 := const "x" ; arg at <unknown>:2:35
<wingo> heap-object?(v1) ? L4() : L7() ; at <unknown>:2:61
<wingo> string?(v1) ? L5() : L7() ; at <unknown>:2:61
<wingo> v3 := const #f ; val at <unknown>:2:61
<wingo> return v3 ; at <unknown>:2:61
<wingo> v2 := const #t ; val at <unknown>:2:61
<wingo> return v2 ; at <unknown>:2:61
<wingo>i guess that string? test should have folded too
<wingo>and the heap-object? test
<civodul>looks like it
<civodul>i guess we'll find new optimization opportunities :-)
<wingo>that failure to optimize turns out to be that we lack alias analysis
<wingo>in theory we should be able to optimize (let ((x (list (list (list (list "x")))))) (car (car (car (car x))))) => "x"
<wingo>but in practice the way we lower "cons" as allocate + set-car! + set-cdr! confuses the cse pass
<wingo>so we only get to strip off the outer level each time it runs. cse happens to run two times in the optimizer, so we get two levels stripped off, exposing the string? but then the branch folder doesn't run after that
<ArneBab>wingo: nice — thank you!
<dsmith-work>Happy Friday, Guilers!!
<wingo>sometimes i think that we really should ditch the LICM + CSE + DCE thing and "just" do one global code motion pass (the sea of nodes thing) -- but it's maybe not magical and what we have is pretty good
<wingo>heya dsmith-work
<wingo>(the idea being, instead of laboriously trying to move expressions around from their initial orders, just throw away the initial order and compute a new one based on a graph of each expression's data and side-effect dependencies
<civodul>wingo: intuitively if one pass can replace three passes, that's good :-), but i have no idea if it's this "simple"
<wingo>it is simple but not easy :)
<wingo>also am unsure that we would be able to preserve the "online cse" optimizations.
<wingo>so, probably not in the cards in the near term. but funny to think about
<dsmith-work>wingo: what's DCE?
<dthompson>dsmith-work: I believe it is "dead code elimination"
<lloda>wish 'reference to identifier outside its scope' told you WHICH identifier
<vijaymarupudi>daviid: Here's a link to the snippet I used statprof on:
<sneek>Welcome back vijaymarupudi, you have 1 message!
<sneek>vijaymarupudi, daviid says: could you paste the code that lead to this statproof, i'd like to check something, then i'll get back ...
<roptat>I'm trying to play with timezones in guile, but I don't understand how it works...
<roptat>I'm trying to find the current time in different timezones, but it all returns the same result: (tm:hour (localtime (current-time) "CEST")) and (tm:hour (localtime (current-time) "ET")) is the same?
<roptat>(well, more precisely, I want to convert a time to different timezones)
<RhodiumToad>try "Europe/Berlin" and "America/New_York" for timezone names
<RhodiumToad>abbreviations of timezones aren't unique (there's like three timezones called "IST")
<RhodiumToad>also everything about timezones is horrible and the tzdata maintainer is making it worse
<roptat>that doesn't work, it still gives me the same results
<roptat>looks like it's giving me UTC time
<RhodiumToad>I get 22 and 17
<RhodiumToad>er, I used Europe/London not berlin
<RhodiumToad>it's giving you 21 either way?
<RhodiumToad>what OS?
*RhodiumToad wots not of guix
<roptat>maybe I'm missing something in my environment?
<RhodiumToad>such as the tzdata files, for example?
<roptat>I see a TZDIR variable which seems to be set correctly (it points to timezone data)
<roptat>looks like I can use "UTC+5" and co, but that won't work with daylight saving
<RhodiumToad>don't ever try and use posix-style timezone specs
<RhodiumToad>and not just because the +/- is backwards
<RhodiumToad>so $TZDIR/Europe/London exists, for example?
<RhodiumToad>and permissions are ok?
<roptat>I just straced it, and it's not looking there
<RhodiumToad>is it looking somewhere else?
<roptat>it's looking in /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/share/zoneinfo/Europe/London but TZDIR is set to /gnu/store/kl68v5mclwp511xgpsl2h1s9gmsdxpzh-tzdata-2021a/share/zoneinfo
<roptat>(sorry for the long hash: it's looking in glibc, but TZDIR is set to tzdata)
<RhodiumToad>whether TZDIR is respected is probably down to glibc.
*RhodiumToad not linux user
<roptat>mh... though timezones work outside of guile
<RhodiumToad>anyway, the fact that it's looking in the wrong place explains the issue
<civodul>roptat: there's tm:gmtoff
<civodul>otherwise the date API in srfi-19 also gives the current timezone
<roptat>civodul, tm:gmtoff always answers 0, unless I don't specify any timezone, in which case it gives my timezone's offset
<roptat>and it's also 0 if I set TZ before that
<roptat>does that work for you: (tm:gmtoff (localtime (current-time) "Europe/Paris"))?
<civodul>hmm no, i get 0
<civodul>but (tm:gmtoff (localtime (current-time))) gives me the expected offset
<roptat>yeah, because then it doesn't have to lookup the timezone (even if you probably have set the timezone to Europe/Paris)
<roptat>now, if you run TZ=Europe/Paris guile, that won't work anymore
<RhodiumToad>note that tm_gmtoff is an extension to the posix spec
<civodul>woow the code in libguile/stime.c is terrible
<civodul>it works by setting the TZ env var temporarily
<civodul>and does that in a rather ugly way
<RhodiumToad>I don't think there's any other way that's even slightly portable
<RhodiumToad>short of importing all or most of tzcode
<civodul>yes, but it's not even calling setenv(3), it's modifying 'environ'
<RhodiumToad>that's probably not ideal
<civodul>it's aesthetically unpleasant :-)
<roptat>maybe, in setzone it says it's creating a new environment with only TZ, so that's how it ignores TZDIR?
<RhodiumToad>well, that would do it
<RhodiumToad>everything about timezones is at best aesthetically unpleasant