***micro is now known as Guest54372
<bogdan>Damn that guy is pretty popular...what he is doing? <bogdan>or to better formulate question, for what reason he is got his fame...There is lot of irc users that said the same stuff ***bogdan is now known as bogdan-
<homoerotictetris>taylanub, don't you think the ideal solution is list-ref as it is now, except that (list-ref list k default) returns default in the event that k is out of bounds <ijp>scheme doesn't have keywrods <ijp>IMO, more problematic is that (foo (symbol->keyword 'bar) baz) = (foo #:bar baz) <ijp>you can get get bare keywords as rest arguments, but there is no good solution to treating keywords as special function calling syntax and allowing them to be passed in as arguments <mark_wea`>homoerotictetris: there is no problem passing keywords as normal arguments. (not that I'm defending Guile's keyword handling as being particularly elegant) <mark_weaver>homoerotictetris: I would appreciate it if you didn't talk about so much off-topic stuff here (you and your >100 nicks that I've seen you use) <mark_weaver>for the record, here are the nicks that I've seen ~nevzets@unaffiliated/nevzets use: <mark_weaver>ActivateKruger Ahli[DE] AirWolfTheme Al-Akir AlanShore Barbequor Borland_Islaam Bortaqqq Captain_Islaam ChernoPutin CuneytArkin DXanatos DavidXanatos DeKolonel Dolfje DrMeredithMcKay DrPhil DrPhil- Dzurko EdwinPoole EvilTheCat FaxIsTheFuture FinestScottishAc Fishlord_Murloc Floantstin Froggy_G Galmagneet Gillecomgain HalfALobster Islaminati Jaffa_kree JantjePietjeKlaa JeromeTheFrench JJSacreBleu Johann JudgeDreadlock Justor JustorGX <mark_weaver>KahviIslaamilain Kleptocracy Kmalton Kuollutrunkkau5 La`Tisha Lajjla LLCordonBleu LordProtector Max_Gentlemen McBurgerMc Molkolev_Zed MorphinTime Muhammad_Ahli Peqlez Porkele Quarkson Quintessenz Ratticus SacreBleu SacreBleu_ Schaapjes ScottishAccent Segabyte Shaolinburper SmurfettePrincip TELawrence TODACHOPPA Televangelor TheRepublicans Tsvekno Turkish_pizza Twirlystache UltimateEyePatch UltimateNickFury VonCuneytArkin W-Crusher <mark_weaver>Wasmachine Zildiv ZurfUndZurf ad___latebras ad_latebras anencephelia bionic_lemur cedric_ze_French chermobylae dat_eye_socket dirtystache essential_lemur flatworm_bitmask french_cheese gaybargaybar homo-eroticaXL homoerotictetris iTweyBook imaaminpoika imaaminpoikienko imaaminpojat infinite_barbecu keem lemur_with_banan libquebec-dev lord_flatworm monobrow_tetris monumental_deuce octopodes optimus_swine phallicAndPaedan phallic_elbegast <mark_weaver>phallic_zed quintessential_l raiskailija shilliamwatner the_essential_le trifling_gnome tuhannetkoirat tuhannetpikkukis turbo_islaam unsafeCoerce very_phallic <mark_weaver>Profpatsch: 'char-ci=?' is implemented by converting both arguments to uppercase using 'uc_toupper' from libunistring, and seeing if the results are equal. <mark_weaver>if you think there's a bug, could you report it to bug-guile@gnu.org ? <homoerotictetris>It does vaguely imply two paragraph before that it "implements unicode semantics" <homoerotictetris>"These procedures are consistent with Unicode’s locale-independent mappings from scalar values to scalar values for upcase, downcase, titlecase, and case-folding operations. These mappings can be extracted from UnicodeData.txt and CaseFolding.txt from the Unicode Consortium, ignoring Turkic mappings in the latter." there's this in the notes though <mark_weaver>if we're not doing so in this case, then it's either a bug in libunistring, or our strategy of converting both to uppercase is somehow flawed. <mark_weaver>Profpatsch: libunistring-0.9.4 was released recently. Upgrading to that version might be worth a try. ***homoerotictetris is now known as GeraldUnlimited
<Profpatsch>mark_weaver: That is my standard test of testing case invariant unicode, more out of trolling than anything else. <mark_weaver>Profpatsch: nonetheless, if there's a bug we'd like to fix it. <Profpatsch>There is the general problem that toupper of ß in German is historically handled as the string “SS”. <mark_weaver>hmm, I guess we would need to convert characters into strings, upcase the strings, and then compare the results. <mark_weaver>but that sounds painfully inefficient for something like a character comparator :-( <Profpatsch>I assume (string-ci=?) is implemented by means of (char-ci=?) <ijp>the SS case is explicitly mentioned in the r6rs, iirc <ijp>at least for strings, not chars <ijp>(string-ci=? "Straße" "STRASSE") ⇒ #t <Profpatsch>For the case of ß there *is* ẞ now, but it seems it’s not implemented in unicase.h yet. <Profpatsch>I don’t know of any other cases, but there is a lot of languages nowadays. <Profpatsch>Out of interest: Is there a way to include Guile in golang programs? <mark_weaver>Profpatsch: Guile's 'string-ci=?' compares the characters individually, and does not handle ß properly. <Profpatsch>mark_weaver: I see. Yet, using the string function in the C library for string comparisons might be a lot faster anyway. <mark_weaver>at present, Guile uses two different internal string representations (Latin-1 when possible, else UCS-4), which means that we can't directly use libunistring for string operations, there are 4 cases for each binary string op, etc. <mark_weaver>there's a longstanding item on my TODO list to make Guile use UTF-8 as the internal string representation, and to use libunistring for many more operations. <mark_weaver>if/when that happens, then these case mapping bugs will be fixed. <mark_weaver>Profpatsch: those can handle the cases where both strings have the same representation, but not where one is Latin-1 and the other is UCS-4. <mark_weaver>I remember looking into this a couple of years ago, and concluding that the code is already too complex, and that fixing these case-mapping bugs properly would be a huge mess with the current dual-representation strategy. <taylanub>Profpatsch: Guile has a C API; perhaps Go can use C libraries? <mark_weaver>so yeah, we knew about the case mapping problem in general, but I confess I was surprised that it would cause a bug in char-ci=? <mark_weaver>I don't know enough about Go's runtime system. it would have to be compatible with bdwgc also. <ijp>goroutines might be problematic <Profpatsch>I guess the biggest problem one would have is that both languages use garbage collectors. <ijp>Profpatsch: does go's move objects? <ijp>I think our ffi implicitly assumes static gc <mark_weaver>yeah, that does indeed sound like a serious problem. <mark_weaver>(the fact that there are two garbage collectors in the same process that don't know how to work together) <Profpatsch>But yeah, if I wanted to write a program with Guile I’d most likely start off in Guile and implement C functions for time-critical stuff. <Profpatsch>Another way I could think of would be to implement the basic program in Go, run Guile indepently and use ipc or sockets. <mark_weaver>that stackoverflow page says that Go 1.3 uses a fully precise GC. that's a problem if you want pointers between Go data structures and C or Guile data structures. <mark_weaver>I'd like to see precise GC for Guile in the future, but it's a ways off. <mark_weaver>(we would have to continue supporting conservative GC as well, of course, since we aim for good interoperability with C) <mark_weaver>ijp: yes, I used it to implement quite a bit of code, some of which I think ended up in Guile. <daviid>why is goops partially written in C, any one knows? <mark_weaver>if we were writing it today, we might write it in pure Scheme on the assumption that we'll probably native compilation in a few years anyway, but GOOPS was written a long time ago. <mark_weaver>method dispatch in particular needs to be highly optimized. <daviid>mark_weaver: I think we should rewrite it in pure scheme, some day :) <rlb>is guile-config going away? <rlb>I ask because I'm having to hack it up a bit to handle multiarch. <rlb>Though perhaps it doesn't matter since it's probably not going away in the next few days ;> <mark_weaver>rlb: guile-config is deprecated in favor of pkg-config, but we need to keep it around for now because a lot of existing software relies on it. <rlb>right -- I'm going to have to hack it up to look for GUILE_DEB_HOST_GNU_TYPE in the envt, and invoke GUILE_DEB_HOST_GNU_TYPE-pkg-config when that's set. <rlb>then we'll have various FOO-guile-config scripts that set that var and invoke guile-config. <rlb>as yet, not sure it's relevant for you upstream <mark_weaver>rlb: but the current 'guile-config' works by calling 'pkg-config' anyway. <rlb>but I'll shout if it is <rlb>yes, but that doesn't work with multiarch <mark_weaver>hmm. so this hack will only work when building debian packages? <rlb>i.e. we need to have it so that if someone invokes FOO-guile-config, that eventually invokes FOO-pkg-config <rlb>debian now supports installing multiple architectures for a given package at the same time <rlb>and I'm finishing up support for that in the guile-2.0 packages <rlb>(also means you can "apt-get install guile-2.0:arm" on an amd64 laptop and then run the *arm* guile via qemu binfmt cleverness if you like) <mark_weaver>I know the basics of Debian multiarch, but I haven't thought much about the consequences for Guile. <rlb>well, no worries -- once I have it working, I'll let you know if there are bits you'd care about upstream. <mark_weaver>if you have suggestions of what we could do in upstream Guile to make multiarch easier, please do let us know! <rlb>having to swap back in scheme knowledge -- keep typing nonsense b/c been off in clojure-land lately... <rlb>if I can figure it out, and have the time, I really do think some of the clojure concepts could be handy in guile (perhaps as modules?) -- but we'll see <rlb>things like ->, cond-> case-> ->>, etc. <rlb>though some of them may really only be fully useful with full destructuring, and if I get that far, we might be back to talking about a separate dialect <mark_weaver>I'd certainly like to include more of clojure's purely-functional persistent data structures into guile. <mark_weaver>rlb: regarding destructuring, are you familiar with (ice-9 match) ? <rlb>right, in an ideal arrangement, maybe we'd have a clojure/guile dialect that shares/provides as much as possible on the scheme side (one way or another) too. <rlb>wrt ice-9 match, not in any detail <rlb>been a long time -- have to look <mark_weaver>rlb: our docs for ice-9 match aren't great, better to look at the comments at the top of module/ice-9/match.upstream.scm <rlb>keep wanting to type (str "a" "b" "c"), but that doesn't work ;> <taylanub>rlb: you mean like destructuring strings? <rlb>taylanub: no bindings, i.e. <rlb>mark_weaver: string-append <rlb>(just example of remembering the wrong thing) <rlb>taylanub: (let [[x y :as rest] (foo) ...] ...) <rlb>which would bind x to the first element of the result of (foo), y to the second, and provide the entire result as "rest". <rlb>and if (foo) doesn't provide a match for any of the bindings, they're nil <rlb>i.e. if it only returns one thing, etc. <mark_weaver>and it's written in portable scheme, available on most any scheme implementation, so it's not guile specific. <rlb>also allows keywords to bind to map (hash-table) items, etc. <rlb>and since it works for let, lamda, etc. you don't need any "extra" support for optional/keyword args, just use destructuring. <mark_weaver>ice-9 match also includes match-lambda and match-lambda* <rlb>ok -- it's built-in in clojure -- but wonder if I could use match to handle (or hack it to handle) that part of any clojure/guile dialect... <mark_weaver>and match-let, match-let*, match-letrec, match-named-let <mark_weaver>(not mentioned in our manual, sadly, but documented in the upstream source code) <daviid>rlb: not sure it answers your needs but ... : (string #\\a #\\b #\\c) <rlb>daviid: thanks -- in this case, I just needed (string-append arch "-guile-config") <mark_weaver>(sorry match-named-let is an internal helper, not part of the API) <rlb>not really sure I even have a good idea of everything that'd be needed to get a minimal dialect going -- but definitely some decent work on the parser... <rlb>though clojure's approach means that you can punt on any number of things and still be "doing it right", i.e. ok to say that clojure/guile's numbers are just guile numbers, etc. <rlb>(so maybe you can rely on string->number, etc.) <mark_weaver>well, we're certainly interested in implementing other popular languages on top of guile. <taylanub>.oO( string destructuring in `match' might be interesting. mucking with filenames comes to mind. ) <rlb>I can tell you that the clojure community might also be quite interested if we also managed to get guile-emacs working well ;> <rlb>i.e. emacs with elisp+scheme+clojure <mark_weaver>I suspect it would be a lot of work to make Guile meet the expectations of clojure users, but I believe it's all very useful work, even to those who don't want to use clojure syntax. <mark_weaver>ideally, I would want most of the interesting functionality and data structures to be available at the Scheme level, and then the clojure language layer would be relatively thin. <mark_weaver>I confess I haven't look very carefully at clojure, beyond watching some talks by Rich Hickey from a couple of years ago. <paroneayea>dispnew.c starts spitting out errors nonstop, forever, it looks like <rlb>mark_weaver: exactly <taylanub>paroneayea: did you use the "wip" branch of bipt's Guile repository? stock Guile isn't enough <mark_weaver>speaking for myself, mostly I'm interested in clojure's approach to concurrency and its data structures. <rlb>I'd even like (if possible) to bring the sequence abstraction to the scheme side <paroneayea>$ LDFLAGS="-L/home/cwebber/programs/guile/lib/" ./configure <rlb>talking with people earlier here, sounded like for now, might still require goops <paroneayea>but gcc seems tuck in some weird infinite loop of spitting out an error <taylanub>paroneayea: you might also need CFLAGS, CPPFLAGS, etc. <rlb>but in the longer run, at least the clojure side might want something faster for the common cases (assuming goops is fairly heavyweight dispatch) <rlb>clojure/jvm has full-blown multimethods, but they're the "last resort" <mark_weaver>paroneayea: you probably need PKG_CONFIG_PATH when running the emacs ./configure, to make sure it pulls in the modified guile libraries and headers. <mark_weaver>and LD_LIBRARY_PATH when running it, to make sure the modified libguile is found at runtime. <rlb>for perf reasons, the common case is designed to be "as fast as the jvm can go" by mapping directly to java/single-argument dispatch <paroneayea>I'm not sure how to set it... I'm admittedly not a very savvy autoconf user :) <rlb>(i.e. that's with protocols, which are a (very) limited subset of multimethods) <rlb>but a nice practical perf-concession <rlb>and still quite useful <mark_weaver>rlb: Guile has something called "primitive generics", which use C code to handle some set of built-in types, and then dispatches to C as a last resort. most of our arithmetic procedures (e.g. '+') are primitive generics. <rlb>anyway -- suppose that's also something guile/scheme might want, if it works out (and there's a perf advantage in guile too) <rlb>possibly -- at least in clojure/jvm you just need to implement the "sequence interface", and of course all of this could just start off using goops, and worry about efficiency later *tadni would personally be shocked if Guile supported a translator for Clj, before CL. <mark_weaver>paroneayea: guile installs guile-2.0.pc in $PREFIX/lib/pkgconfig <rlb>tadni: well I'd assume CL is a much bigger proposition <mark_weaver>paroneayea: to make sure emacs finds that one, set PKG_CONFIG_PATH to $PREFIX/lib/pkconfig <rlb>(well unless you already have a scheme "cl" lib lying around) *tadni should try to build Guilemacs again. Guile wip pooped out on me. <rlb>i.e. since CL is *big* *rlb waits for guile to build again -- see if multi-arch works *tadni starts build of Guile wip, for guilemacs. <mark_weaver>I don't know about full CL, but I've occasionally considered implementing a subset of CL for Guile: just large enough to run Maxima, which was originally written in MACLISP, later ported to CL but only uses a small number of CL features. <mark_weaver>paroneayea: note that PKG_CONFIG_PATH is consulted when 'configure' is run, so you'd need to run it again after setting it. LD_LIBRARY_PATH would be set to the directory that contains the modified libguile, $PREFIX/lib. <mark_weaver>bipt: and your work on elisp will make that much easier! :) <bipt>my current spare-time project is converting the CL ANSI draft from tex to latex, because $reasons <mark_weaver>and of course, one we have a subset, I could easily imagine people contibuting more bits to it over time. it might eventually grow to have most of the commonly used features of CL. <rlb>...of course any chance of actually getting anywhere with a clojure/guile (or the relevant features in guile) would depend on a *lot* of help -- doubt it's something I could easily do on my own, and it's not really clear how likely that'd be. But if I get started, I'll probably try to come up with some minimally useful bit in the hope that'll provoke interest/help. <rlb>...someone else suggested racket would be the best platform, but suspect I'm more likely to choose guile ;> <bipt>guile-elisp is explicitly designed to be a CL subset where that doesn't conflict with elisp <mark_weaver>rlb: I'd be willing to help a _lot_ with the data structures and concurrency support that I find compelling, and a fair amount with the other parts :) <ijp>stis started working on a guile-cl, but I can't vouch for its quality <mark_weaver>I'd be surprised if we could use anything from stis. <rlb>mark_weaver: ok, I'll shout here if I get anywhere even a bit meaningful... <rlb>(I'd started by grabbing the elisp module and trying to convert it to understand a dumbed-down clojure syntax, but haven't gotten very far yet) <daviid>just in case someone has an idea, i'm facing the following problem: i'll paste a chat I started on #clutter [that nobody answered yet], then further explain some more guile related stuff here <tadni>Guilemacs is compiling... :^) <tadni>Welp, guilemacs already errored. <daviid>then here is the funny thing! if I do ,use (oop goops describe) and this sequence [in the spawned server repl]: (define l2 (make <clus-text> #:text "Gravity" #:bg "black")) (add-child *stage* l2) (describe l2) (set! (!gravity l2) 'west) <daviid>then it works, I mean although I triggered 1 event only on the newly added actor to the stage, which means that describe, which basically reads slot-names and values, provoques a side effect ... describes actally triggers 2 glib-gobject critical messages and a couple of warnings <tadni>bipt: The brief is, make[1]: *** [lread.o] Error 1 <janneke>could it be that goops with guile-master is twice as slow as stable-2.0? <daviid>by the way i see we have 2 describe ./2.0/oop/goops/describe.scm and ./2.0/system/repl/describe.scm, both exporting describe: this potentially could trigger the error I was refering to in our last goops related discussions <mark_weaver>janneke: that would be most surprising to me, and worthy of a bug report. <mark_weaver>daviid: I looked at what you wrote, but I have no clue to offer, sorry :-( <janneke>mark_weaver: i'm seeing real 0m1.488s with stable-2.0 and 0m3.433s with latest master :-( <janneke>i just finished converting my app to goops ... and without goops it was < 0.5 sec <janneke>quite possible that i'm doing something stupid tho <daviid>mark_weaver: tx for the attempt! <janneke>i'll have a look if i can create a useful report <bipt>tadni, thanks. i have to go now but will take a look in a couple hours. looks like it might be a guile-snarf problem