IRC channel logs

<nalaginrut>morning guilers~

<nalaginrut>mark_weaver: could you take a look at this patch? https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00061.html

<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: http://download.savannah.gnu.org/releases/guile-cairo/

<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> http://git.savannah.gnu.org/cgit/guile-cairo.git/

<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.

<rlb>wingo: http://build-common.alioth.debian.org/cdbs-doc.html http://upsilon.cc/~zack/stuff/dh-vs-cdbs/

<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>-TESTS_ENVIRONMENT=\\

<rlb>- API_FILE=$(srcdir)/cairo.api $(top_builddir)/env guile -s

<rlb>+LOG_COMPILER=\\

<rlb>+ env API_FILE=$(srcdir)/cairo.api $(top_builddir)/env guile -s

<rlb>

<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> http://git.savannah.gnu.org/cgit/guile-cairo.git/

<rlb>I meant -- http://anonscm.debian.org/cgit/collab-maint/guile-cairo.git/

<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>e.g. libguile-2.0.so

<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

<wingo> https://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html

<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>packages

<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>(roughly)

<wingo>right

<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>ouch

<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 release.org] 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>ah!

<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? https://packages.debian.org/source/sid/guile-gnome-platform

<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 bugs.debian.org pages for the relevant packages.

<rlb>(the debian changelog)

<rlb>i.e. http://metadata.ftp-master.debian.org/changelogs//main/g/guile-gnome-platform/guile-gnome-platform_2.16.2-1.1_changelog

<daviid>bbl

<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)

<nobody111>:)

<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.

<rlb>right

<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>sure

<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

<nobody111>oh!

<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.

<nobody111>ok

<rlb> https://en.wikipedia.org/wiki/Persistent_data_structure\\

<rlb> https://en.wikipedia.org/wiki/Persistent_data_structure

<rlb>nobody111: the dumbest implementation would just be a giant recursive memcpy...

<rlb>(don't do that)

<nobody111>hah

<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>:)

<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

<nobody111>nope

<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>heh

<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....

<wingo>sup

<dsmith-work>wingo: Nothing, just checking the bot

<wingo>:)