IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>mark_weaver: could you take a look at this patch?
<Profpatsch>Can I surpress the ;;; note source file newer … somehow?
<nalaginrut>Profpatsch: IIRC you can't, unless you disable auto compile
<Profpatsch>nalaginrut: So guile --auto-compile test.scm | grep -v ;;; it is. :)
<Profpatsch>Oh, that one is printed to stderr, so it’s even easier.
<nalaginrut>you can ignore all the err output starting with ";"
<Profpatsch>Ugh, this must be very basic, but when I do (display "xyz") I get "xyz\\n#<unspecified>" on stdout.
<Profpatsch>Oh, simple.
<Profpatsch>I just have to leave display out. :)
<civodul>Hello Guilers!
<janneke>hi civodul!
<artyom-poptsov>Hello civodul
<dsmith-work>Morning Greetings, Guilers
<daviid>wingo: I don't understand why, in overrides clutter.defs [and in any overrides, glib, ...], you sometimes specify (leave-guile-mode #f) and most of the time not. what does that do exactly? I looked at (gnome gw support defs) but still don't understand, so don't know exactly when I should use it. in the get-background-color special wrapper I posted recently, I did use it, because you did in get_perspective and both methods are
<daviid>extremelly 'similar', but i'd like to know better, if possible [it sounds that if you don't use it, calling that method will exit guile :)]
<wingo>i think that creates a stack segment that gc doesn't scan, and it allows gc to proceed without stopping that thread
<wingo>usually you want to do that when you are calling something that can be reentrant to guile
<wingo>like a main loop or something
<rlb>civodul: thanks wrt NEWS -- I asked because I was poking at some packages (curious about what it'd take to update them), i.e. when they call things like gh_eval_file().
<rlb>Of course I'd have to unrust my guile/c knowledge -- does the bwgc mean no more explicit marking of pointers?
<rlb>I'll just need to read-up...
<rlb>daviid, mark_weaver: if I decided to prod at guile-cairo, etc., which one should I start with, and what'd be the appropriate upstream "release".
<wingo>rlb: if you need another release let me know
<rlb>ok -- so start with that package.
<wingo>the changes in git are minor and mostly build-related
<wingo>so if that one doesn't build i can roll a new release
<rlb>wingo: is that release also tagged in git somewhere?
<wingo>rlb: yep
<rlb>ok, thanks
<daviid>wingo: tx. from you just wrote, not sure it should be used in get_perspective, get-background-color...
<civodul>wingo: while you're at it ;-) a guile-rsvg release would be nice :-)
<wingo>daviid: i don't remember, it could be that constructors for those return types use the scm API
<wingo>civodul: ok :)
<rlb>(ouch -- existing guile-cairo is cdbs -- that might slow me down...)
<wingo>rlb: what is cdbs?
<rlb>one of the debian meta packaging systems
<rlb>(and one I don't know at all)
<rlb>but not the end of the world -- though I'd probably convert it to debhelper if I spent much time there.
<wingo>rlb: it should be easy fwiw, just a normal autotools package...
<rlb>wingo: right -- it's a very short cdbs rules.
<rlb>wingo: know of any likely non-dfsg bits?
<wingo>rlb: none that i know of
<rlb>(in the new version wrt what's in debian -- 1.4.0)
<rlb>only debian patch in the old version appears to be this:
<rlb>- API_FILE=$(srcdir)/cairo.api $(top_builddir)/env guile -s
<rlb>+ env API_FILE=$(srcdir)/cairo.api $(top_builddir)/env guile -s
<rlb>Description: Cope with the new Automake parallel test harness
<rlb>no idea if that's still relevant
<daviid>wingo: yes they do use the scm API, but is it not the case for any overridden function and/or method?
<wingo>civodul: done
<wingo>daviid: i really don't remember :/
<daviid>ah ok
<wingo>rlb: i think i worked around that by forcing serial tests
<wingo>hackety hack
<rlb>hmm, it's already in collab-maint, so I guess I'd start by forking that locally...
<rlb>I meant --
<wingo>4 years ago ;)
*rlb wonders if people(?) would be grouchy if he switched it to git-dpm using his normal branch/tag naming conventions (which are a bit long-winded...), i.e. deb/v/2.0.11... deb/guile-2.0/d/sid/master, etc.
<rlb>wingo: though is guile-cairo likely to need the per-major-version packages like emacs and guile?
<rlb>be nice if it didn't...
<daviid>wingo: ah, I found an example: wrap_clutter_units_from_pixels does not use the scm api, but _wrap_clutter_color_from_string does, only the later uses (leave-guile-mode #f)
<rlb>(that's a pain)
<wingo>rlb: depends on how you want to do it -- certainly if you want to have guile-cairo for 2.0 and 1.8 (e.g.) at the same time
<wingo>i would just have it use the latest guile tho
<rlb>wingo: what about when there's the next soname transition?
<rlb>(or effective equivalent)
<wingo>rlb: guile changes library names as its primary thing
<wingo>so you can have both
<wingo>with 1.8 and 2.0 the separation isn't as complete
<wingo>but with 2.0 and above you should be able to have both development packages installed at the same time
<rlb>right -- but say guile-2.1 comes out, and we have guile-cairo against guile-2.0...
<wingo>rlb: dunno, cross that bridge when we come to it?
<wingo>dunno :)
<rlb>right -- well eventually guile (and/or packagers) probably need a clear plan on that front
<rlb>which will probably require some promises upstream...
<rlb>(analogous to the "don't break ABIs" promise)
<wingo>we will break abi between 2.0 and 2.2
<wingo>but since it's parallel installable it shouldn't affect 2.0 installations
<rlb>ok, so then perhaps that tells us that if we want people to be able to use guile-cairo (for example) in debian without a forced all-or-nothing transition, then we have to package it as guile-2.0-cairo?
<rlb>(and upstream needs to make sure that's possible)
<wingo>upstream == guile-cairo, no?
<rlb>wingo: and guile itself potentially
<rlb>i.e. all the upstreams can't do something that makes the approach impossible
<wingo>see the above link to the manual.
<rlb>wingo: right -- suppose it may be worth understanding what python/etc. do -- since we're in a similar situation. (i.e. python 2.X and python 3.X installed at the same time with all the attendant sub-packages)
<rlb>anyway -- sounds like all the pacakges that depend on guile probably do need to be packaged as guile-X.Y-foo.
<rlb>unless they're guile-version agnostic (if that's even possible)
<rlb>i.e. in emacs we have /usr/share/emacs and /usr/share/emacs24
<rlb>though I forget offhand if (and to what extent) packages are really allowed to use the non-XY emacs support
<rlb>in any case, there's the generic emacsen dependency...
<wingo>in guile there's a set of version-specific dirs under /usr/share/guile/ -- e.g. /usr/share/guile/2.2 for guile 2.2 system packages, /usr/share/guile/site/2.2 for guile 2.2 site packages, etc
<wingo>similarly under /usr/lib/guile/...
<rlb>wonder to what extent we could automate some of this -- it's a non-trivial amount of work to manage packages that change names with the major version...
<rlb>(though some of that work is exclusively at the "base" of the tree, i.e. emacsXY and guile-X.Y -- i.e. getting the dead versions removed)
<rlb>(and just takes time/tenacity)
<rlb>ok, well, I'll think about it -- thanks
<civodul>wingo: thank you!
<wingo>civodul: np :) anythign else? :)
<civodul>heheh, we'll see ;-)
<daviid>rlb: to answer your question, depending on your available time, guile-cairo is the first pkg we'd want to keep in debian, then g-wrap, then guile-gnome. note that, for info, our clutter binding never made it to debian [no guile-gnome2-clutter or guile-clutter [I'd prefer] and that would be awsome, in the future...]
<daviid>imo ^
<Ulrar>Is there a function already existing that would convert the number of millisecond since 1st january 1970 to some
<Ulrar>usable date format ? I'll do it myself, just wanted to check that I'm not reinventing the wheel
<civodul>Ulrar: in (srfi srfi-19)
<civodul>you can use 'make-time' first, and then say time-monotonic->date, and then date->string
<civodul>something like that
<civodul>"See you in 2021!", writes wingo :-)
<wingo>the last release was in 2007 ;)
<Ulrar>make-time takes seconds and nano seconds, don't think that's it .. thanks anyway, i'll look into it
<daviid>wingo: don't forget to fix the bug that breaks guile-gnome pleaaase
<wingo>daviid: indeed, will do, sorry things have gotten in the way
<wingo>actually Riastradh from #scheme came to visit this weekend, that was fun
<daviid>wingo: sometimes you named the wrapper _wrap_bla_bla, sometimes wrap_blu_blu, any logic when to use the preceeding #\\_
<daviid>wingo: I understand, tx
<wingo>in that vein somehow i was invited to speak at the scheme workshop in washington dc in november
<wingo>if any of yall are around you should come ;)
<daviid>that would be great, if money allows...
<janneke>daviid: talking about my guile-gnome event patch you said it changed the api; how is that?
<janneke>i don't think it changes anything on the scheme side at least...
<daviid>wingo: about the preceeding #\\_ [or not] any idea?
<wingo>daviid: i don't know, sorry...
<daviid>janneke: my mistake then, but I've just been too busy to deeply read it and include it... I'm sorry
<janneke>daviid: okay thanks. np. there's no hurry, would be very nice to have it in debian though
<daviid>janneke: in debian woule be too optimistic I think, guile-gnome-platform is not even in ebiananymore...
<janneke>oh my...
<daviid>janneke: but a release, soon, sounds feasible, would you help me with that?
*daviid never released in the name of the guile community and wishes to concentrate on further patching guile-gnome and guile-clutter
<janneke>daviid: what could i do?
<daviid>janneke: read/study the guile/RELEASE [or] and release. I would prepare and do the git house keeping, till having master tagged with v2.16.3 and ready for the tarball and release...
<daviid>janneke: does your patch needs/means change(s) in the documentation?
<daviid>janneke: about your example I don't like the .slot-name notation and would like to come, if possible, to a consensus between us... I suggested !slot-name instead, which I use in clutter exammples [that I will push in the near future], wdt?
<janneke>daviid: i chose `.' because it resembles member accessors in all other languages i know. I have no problems with !slot-name
<janneke>daviid: i'm not sure how much a documentation update is needed or where i wyould describe this...
<civodul>wingo: the rule that runs guile-snarf fails with: "guile-rsvg.c:24:22: fatal error: libguile.h: No such file or directory"
<civodul>somehow it seems to ignore GUILE_CFLAGS
<janneke>daviid: i see doc/release in guile-gnome -- having done LilyPond releases I wonder why there is all this documentation instead of executable documentation as `make release'
<janneke>humans make errors?
<janneke>daviid: the release info in guile is tailored to guile i suppose
<daviid>janneke: about accessor names, yes I know, the java way, but I'd prefer ! instead. of course we [all] know that in goops[clos], it is just a convention not a requirement. I've long used the slot-name itself, but realized that having a preceeding char helps users [quite a lot, in avoiding nasty bugs [using slot-name in let defs...]]
<janneke>daviid: it seems to me that writing a sensible NEWS is most work?
<daviid>janneke: i don't know anything about release. I already did the NEWS update [except that it does not include your patch yet]
<janneke>daviid: yes, [c,pascal,c++,python,java,javascript etc]
<janneke>it should be as `simple' as the steps in docs/release in guile-gnome
<janneke>with LilyPond, we used to release twice a week, so only for major releases we would do the mailing lists and news. website would be automated too
<janneke>daviid: but i'm happy with any special char in the example, ! is fine
<daviid>janneke: perfect [for !]. i'll read docs/release, if it's really that simple i'll do it
<daviid>janneke: ah it's easier then I thought, I can do it then :) [sorry I thought it was awfully complicated]
<janneke>daviid: releasing is a learning process -- sometimes you goof up and then doc/release gets updated [and bits moved int MAKE or a script ;-)
<janneke>daviid: too bad it's no longer in debian, why was it removed?
<daviid>janneke: it's been removed a while ago, don't know why, don't remember
<tadni_>Were there any active maintainers?
<rlb>tadni_: generally speaking, I'm guessing there was some serious+ bug and no response from the maintainer...
<rlb>(for a while)
<janneke>daviid: what about this?
<janneke>daviid: esp. this page is interesting
<janneke>it seems that rotty is the maintainer, what happened?
<daviid>janneke: about your patch and possibly some documentation, the question is [I still have to re-read the patch, excuse the lack of apropriate terminology maybe]: is the documentation as it is now covers all a user needs to know to use these signals?
<rlb>janneke: I believe rotty's been unavailable wrt debian for some time now.
<rlb>janneke: see the changelog and the pages for the relevant packages.
<rlb>(the debian changelog)
<janneke>daviid: it is now possible to actually do (make <gdk-event-type>) so it would be nice to have that documented. however, <gdk-event-type> is not present in the documentation although it existed before?
<janneke>rlb: thanks, that's too bad --who's got time?-- let's see if he shows up here ;-)
<rlb>janneke: not promising anything, but I may poke at at least NMUs -- though we're awfully short of time wrt jessie.
<rlb>(but anyone else interested should not let my tentative comments dissuade them)
<janneke>rlb: thanks! ;-D
<janneke>rlb it would be nice if rotty could help you
<nobody111>As far as i gather from playing with Guile (define q 10) (let ((f q)) (set! f 5)) won't change q, but if q was a list (say '(1 1)) and , instead of set! we used set-car! , q would change to '(5 1) . Is this behaviour implementation specific, or something specified on the level of the Scheme language.
<rlb>that's because in the first case, you're changing f to point to something new, and in the second case you're modifying the same data structure that both f and q are bound to.
<rlb>(reaching in and modifying)
<rlb>nobody111: ^
<nobody111>yes , rlb, this is my diagnosis, I am just not sure if this is how all Scheme implementations behave, or just some. Why is not f totally new, but points to the same structure as q?
<nobody111>In case q is a list, i mean.
<rlb>because let just binds f to whatever q was bound to (by definition)
<rlb>if you want a deep-copy, you have to ask for that
<rlb>i.e. (let ((f (list-copy q) ...
<rlb>and even that's just a top-level "spine" copy, i.e. not a full recursive copy of the list and each item in the list
<rlb>(...and as an aside, in many/most cases, you may be better off avoiding functions like set-car! when you can)
<rlb>though that'd be easier if there were a standard set of immutable structures....
<rlb>(in some cases)
<nobody111>it was more a philosophical question, since I am trying to understand the difference (not from the point of the implementation, but the language. Since it is clear that when passing a list in my let , f gets to be a pointer to q)
<rlb>ok, right -- then yes, that's effectively what happens
<rlb>i.e. f and q point to the same chunk of memory
<rlb>so for anything that can be modified, you'll see the changes through both bindings
<nobody111>yeah, and set! totally ruins the connection (i. e. a new object is formed), but set-car! just within
<rlb>right -- set! is more or less traditional assignment and set-car! is a list-specific (cons specific) modifier.
<rlb>somewhat like "list.head = x" in C.
<rlb>and set-cdr! would be something like "list.tail = x"
<rlb>well perhaps more like list->...
<rlb>but if you know C, perhaps that helps...
<nobody111>Yeah, it's just that I thought a biding in a let form is 'by value', but it appears it is not so, or , at least, what is considered to be a value of a list (or any more complex object) is not it's contents, but the "pointer" to it.
<nobody111>On one hand it seems incoherent to me that scalars and more complex objects are treated differently, on the other hand -- well it's a change of the world view :)
<rlb>but some things like numbers can't be modified
<nobody111>thanks for the explanation
<rlb>i.e. iirc everything's a pointer copy (wrt let bindings), but some things don't have modifiers
<rlb>so really scalars aren't treated differently
<rlb>i.e. a small integer fits in the pointer itself, a larger one doesn't (but that's just an implementation detail)
<nobody111>this also holds for args to functions, right?
<rlb>yep -- let bindings and function bindings are isomorphic
<rlb>and you can write let in terms of lambda (if you like)
<taylanub>conceptually, (let ((var val) ...) body) = ((lambda (var ...) body) val ...)
<nobody111>yeah, i seem to remember this from last when i read SICP (and that was a while ago)
<rlb>I'm still somewhat interested in the possibility of adding something like clojure's sequence abstraction to guile (if I ever get time), along with a corresponding set of immutable data structures -- (that and/or a clojure dialect).
<rlb>nobody111: in that case, the "deep copy"'s irrelevant since you can't change the data structures.
<nobody111>rlb, you mean, you'd get 'deep copy' behaviour by default (for immutable structures)
<nobody111>rlb, (in an example like my question)
<rlb>nobody111: no, just that deep copy doesn't mean anything since there's only one copy of any given data structure, i.e. [1 2 3] can never change
<rlb>the trick is to make altering that structure (which produces a completely "new" value) efficient
<nobody111>keeping a 'skeleton' ? :)
<nobody111>i mean the storage
<rlb>i.e. you never modify the structure, you always create a "new" one (though to make it efficient, there's sharing involved -- and a healthy GC)
<rlb>nobody111: more or less -- it's a well-established idea (haskell/clojure/a-bazillion-others?), and there are scheme implementations of the relevant data structures too...
<nobody111>i was thinking about this since i was implementing an API to a FFT C library which means handling big arrays
<rlb>nobody111: cf. tries, etc.
<rlb>nobody111: the dumbest implementation would just be a giant recursive memcpy...
<rlb>(don't do that)
<nobody111>no, that would be a death to FFT arrays, since they need to be properly aligned
<rlb>i.e. (assoc [1 2 3 4 5] 3 42) would just return a complete deep copy of the original vector, but with the 4th element changed to 42.
<nobody111>yes, you should definitively implement something like this
<rlb>but in clojure (for example), normal vectors aren't really contiguous, they're 32-way tries.
<nobody111>all right
<rlb>so lookups are O(log_32(n)), which is close enough to constant ;>
<rlb>(in many cases)
<rlb>but obviously not what you'd want for heavy FFT work
<rlb>(that's what arpack/lapack/blas/atlas/... is for)
<nobody111>that's why i'm implementing an API
<rlb>i.e. you *really* want fortran ;>
<nobody111>i just want to have a convenient wrapper around the FFTW library
<nobody111>so all the heavy duty work is inside the library, just a couple of things need to be changed from Scheme
<rlb>nobody111: ahh -- well without knowing much about fftw, I'd imagine you're going to have a non-persistent API in that case.
<rlb>(perhaps too expensive otherwise)
<nobody111>so far i'm using bytevectors masked as arrays to touch where i need
<nobody111>through FFI
<nobody111>everything is allocated by the library, given the special requirements (alignment, contiguity)
<nobody111>Obviously, I could use R, or numpy, or such, but why not doing it in Scheme :)
<rlb>but of course
<nobody111>So , will we ever see Guile as a universal scripting platform for GNU-based things? Or, is it too much to hope for? Everybody wants to code in Python these days.
<nobody111>I guess similar discussions were happening here before :)
<rlb>nobody111: just need a compatible python dialect that's better than cpython
*rlb is not planning to write it
<nobody111>Cheers lads
<nobody111>see you some other time
<dsmith-work>rlb: I remember more than one attempt at python-in-guile
<dsmith-work>sneek: seen wingo?
<sneek>I last saw wingo on Oct 13 at 03:38 pm UTC, saying: daviid: i don't know, sorry....
<dsmith-work>wingo: Nothing, just checking the bot
<wingo>sneek: botsnack
<dsmith-work>Been on vacation all last week
<sneek> 20:19:43 up 29 days, 5:14, 0 users, load average: 0.00, 0.01, 0.05
<lloda`>sneek: later tell nobody111
<sneek>Will do.
<lloda`>man, that bothered me
<lloda`>Guile has had proper arrays forever and every-frigging body wants to use nested lists and rigged bytevectors and whatever
*rlb is going through old bugs -- is this the expected behavior?
<mark_weaver>that's for 1.6
<mark_weaver>I think the situation is probably improved.
<mark_weaver>rlb: I saw you poking at guile-cairo earlier. any progress?