IRC channel logs
2014-02-11.log
back to list of logs
<TravisD>Has anyone had any success installing guile on Mac OS using macports /and/ getting readline to work? <TravisD>guile version 1.8.8. When I evaluate (use-modules (ice-9 readline)), I get the following error: ERROR: file: "libguilereadline-v-17", message: "file not found" <TravisD>I have installed the readline library via macports <mark_weaver>well, first of all, we haven't supported guile 1.8.8 in several years. can you switch to 2.0.x? it is a massive improvement over 1.8, and I'm familiar with its code so I can help more efficiently. <TravisD>Hm, strange. Guile 2.0.x is not in the macports tree <TravisD>For sure I can switch to 2.0, though. I didn't realize 1.8 was so outdated <davexunit>TravisD: not exactly what you're asking about, but guile 2.0.9 *is* in the homebrew repository. <mark_weaver>but you have to pass --devel to the install command, last I knew. <TravisD>yeah, I recently moved from home-brew to macports because it ships binaries for lots of software <davexunit>homebrew is annoying because it has to compile nearly everything. <TravisD>It's a bit concerning that the ticket was opened 3 years ago <mark_weaver>guile 2 was released just a few days shy of 3 years ago. <TravisD>yeah, the concerning part is that it hasn't been closed yet :) <davexunit>does anyone use guile on os x besides shane celis? :P <mark_weaver>we certainly have several users on macos x. we've received bug reports from several, and I generally assume that the number of user who report bugs in a small minority. <TravisD>mark_weaver: Are you involved in the development of guile? <TravisD>oh, I thought your sed command was for my question, not your previous message :P <TravisD>mark_weaver /is/ the development of guile <mark_weaver>no, the sed was a fix for my "number of user who report bugs in a small minority." <TravisD>On a somewhat unrelated note - do you know of any good linear algebra modules for scheme (maybe guile-specific since it will probably use fortran libraries or something and that may be interpereter-specific?) <mark_weaver>in that ticket, you'll find that someone contributed a package description for guile 2. I guess the macports devs can't even be bothered to add a contributed package :-( <mark_weaver>TravisD: hmm, I don't know of such a library off-hand, but Guile 2 has a dynamic FFI that can be used to link to arbitrary libraries with a C interface, so it probably wouldn't be hard to write bindings to the GNU Scientific Library http://www.gnu.org/s/gsl/ <mark_weaver>someone ported it to Guile at one point, although I don't think that binding has been upgraded to Guile 2.0 yet. <mark_weaver>but if you need high performance, you probably want to bind a C library. <mark_weaver>(or a fortran library, but Guile's dynamic FFI probably doesn't make that easy, or at least I don't know that it would be) <TravisD>yeah, I saw some plt-scheme bindings for BLAS and LAPACK <mark_weaver>scmutils is the software base for Structure and Interpretation of Classical Mechanics, which is a *great* book if you're into that sort of thing. <mark_weaver>what are you working on? how large will your matrices be, and what kind of operations do you need? <TravisD>I study computational learning. We want to get some empirical results for a learning algorithm which involves some expensive optimization. I was planning to implement an interior point method specialized for our problem. <mark_weaver>I actually don't know what the calling convention of fortran is, so for all I know it's not a big deal to call fortran from Guile'd FFI. I just don't know. <mark_weaver>but in any case it wouldn't be hard to write a C bridge between Guile and a fortran library. <TravisD>although it might be easier to implement the whole thing in C++ <TravisD>I'm not a fan of the matlab-style languages :( <b4283>peculiar, i was just reading guile manual about FFI the this morning <TravisD>I have been using python + numpy for exploration and c++ with Eigen3 whenever efficiency is important. Was hoping to switch to scheme for some things because it seems like it would be a more stimulating language :) <mark_weaver>I'm afraid that Guile's floating-point numbers are currently heap-allocated, so you pay a heavy cost in the garbage collector when you do floating-point math in Guile. We have homogenous numeric vectors, which are basically implemented as packed arrays of floats, but at present if you do any math on them from Scheme then you'll do a lot of heap allocation. <mark_weaver>we plan to fix that in the future, when we have native code generation (probably in 2.4), by working with unboxed floats wherever possible. we're also considering nan-boxing in 2.2. <mark_weaver>basically, using doubles as the type for Scheme values, with everything that's not a float represented as a NaN. (There are about 2^53 of them) <mark_weaver>yeah, it is admittedly a bit hacky, but sadly we need some bits for type tags, and IEEE doubles don't give us any free bits, nor any reasonable way to steal any bits from it. <mark_weaver>on the flip side, we can't really support heap sizes anywhere near 2^48 bytes anyway, because of the costs of garbage collection. <mark_weaver>(it would be prohibitively expensive to collect garbage from such a large heap) <mark_weaver>probably the best solution is good type inference in a native compiler, but we're not quite there yet. <TravisD>I guess if the objects on the heap were all very large you should be able to do it efficiently, no? <mark_weaver>yeah, if most of the heap is made up of large pointerless objects (that don't need to be scanned), then yes, it's feasible. but in that case, you can add a layer of indirection to point to those large objects. so the tagged (nan-boxed) objects would point to a pointer in the first 2^48 words, which would contain an arbitrary unboxed pointer to any address. <TravisD>Is the current plan for nan-boxing in guile to use an indirection scheme like that? <TravisD>use some bits for type information and the other bits to point to a pointer in the first 2^n words? <mark_weaver>well, in most cases we'd avoid the indirection. but in most cases, large objects have a header object anyway, so it would end up that way by default. <mark_weaver>sorry, that was confusingly put, and sounds self-contradictory :) <mark_weaver>we wouldn't point to a pointer, but rather to a header object that itself contains an unboxed pointer to the large data, is what I mean. <TravisD>Ah, and then you just don't use the higher memory addresses or something? <mark_weaver>we wouldn't use them for small objects or for header objects. those would be constrained to the first 2^n words of the heap. <TravisD>cool :) I don't know very much about PL implementation <mark_weaver>it's a messy business, I'm afraid. at least if you want good performance. <mark_weaver>but on the plus side: if properly done, it can allow more elegant code in the upper layers. <TravisD>Yeah, I remember reading that pypy works by having a JIT compiler for a small subset of python, then they wrote a python interpreter using only that subset. Then the interpreter itself is jitted. Not sure if that actually gives good performance, but it's neat anyways <mark_weaver>anyway, if you'd like to work in Scheme, you might want to take a look at scmutils. It has an interesting generalization of matrices, and includes several numerical optimization routines. MIT Scheme also has native compilation. <mark_weaver>Structure and Interpretation of Classical Mechanics makes heavy use of numerical methods. <TravisD>if you use MIT-scheme's compiler to compile code with scmutils, is the result efficient? <mark_weaver>they use the principle of least action, so they are basically doing path integrals. and they don't limit themselves to very simple problems that can be solved symbolically. <TravisD>and does SICM have an introduction to Scheme? I never really had a proper introduction, though I've been reading through SICP <mark_weaver>SICM doesn't really have much of an introduction to Scheme, no. It has an appendix with the basics, but not much. <mark_weaver>SICM, like SICP, is available in its entirely online, gratis, btw. although of course it's good to support the authors by buying the physical book if you like it. <mark_weaver>but anyway, what I mean to say is that scmutils on MIT Scheme is reasonably efficient. <mark_weaver>I doubt it's as efficient at C++, but if you'd prefer to work in a higher level language it might be worth looking at. <TravisD>yeah, I might take a look. I only really care about it being fast enough that our experiments don't take too long <TravisD>it might also be a nice environment to learn about these kinds of algorithms. The final implementation can probably be in any language <zRecursive>chezscheme is said to be fast, i have not used it though. <mark_weaver>please don't recommend non-free software on this channel :-( <nalaginrut>well, even petite, there's no code revealed, so you can learn nothing from it, although it claims faster than C <TravisD>mark_weaver: Actually, I think I probably will read SICM. I've been a bit curious about the Lagrangian of a system for a while. This might be a fun way to learn about it! <mark_weaver>(Sussman was kind enough to let me sit in on his class for free) <TravisD>Hehe, that's great :) I have very little background in physics (but I have a good background in math). Will that be an issue? <mark_weaver>yes, I live in Boston. No, I don't think it will be an issue. <mark_weaver>if you're strong in math, I think SICM would serve as an alternative introduction to classical mechanics. <TravisD>(I don't live in Boston, though, but my sister does.) <TravisD>I'm just starting to hear back about my phd applications, though, so I'll almost certainly be moving to the USA by September <TravisD>yep! I grew up in Calgary which is a few hours south by car <mark_weaver>I should warn that although I doubt you'll need much knowledge of physics at the start, SICM is definitely quite challenging. <mark_weaver>and it uses a non-standard mathematical notation which takes some getting used to. <mark_weaver>one reason is that the traditional notation for partial differential equations is ambiguous. it cannot be understood by a computer. <mark_weaver>you can find the details of this near the start of SICM. <mark_weaver>(the traditional notation also is generally misunderstood by humans) <TravisD>The whole "local tuple" of a function? <TravisD>er, that's the notation you're talking about? <mark_weaver>in this book, derivative is an operator that maps functions to functions. it's a higher-order notation. <mark_weaver>but e.g. in section 1.5 they point out that the traditional way of writing Lagrange's equations is totally inadequate to really understand what's going on. <mark_weaver>I always thought of mathematics notation as being unambiguous, but in fact where calculus is concerned at least, it's kind of a mess. <mark_weaver>it's easy to fail to notice these details until you try to teach a computer about them. <mark_weaver>sussman rightly points out elsewhere that even in mathematics, scientists tend to communicate with each other by painting sort of impressionistic pictures of their ideas. just enough so that someone else with enough relevant background can fill in all the details that are being omitted, and sometimes to fix up the bits that are flat out wrong. <mark_weaver>SICM is, IMO, groundbreaking work because it attempts to communicate the ideas of modern classical mechanics in unambiguous notation, suitable for direct interpretation by a computer system, namely scmutils. <mark_weaver>and their methods are designed to work for systems that are far too complex to solve symbolically. <TravisD>that sounds pretty interesting! I have been noticing lately how informal most mathematics actually is. One of my friends is interested in constructive mathematics and automated proof verification. It's amazing how much longer proofs become when you write them in a computer-verifiable way <mark_weaver>right, and with lots of help from computers to reduce the amount you have to do by hand. it's not a subject I've looked at very carefully, but it's important work to be sure. <adhoc>are there other online/pdf books i can use to learn more scheme/guile? <civodul>oh, the array implementation registry is gone <wingo>civodul: yeah, wdyt about that? <wingo>it was always private so there's no compat worry; seems a shame to do away with a layering mechanism but it lets arrays be much faster, so it seemed the right thing <wingo>lloda: a couple of other things i thought about :) one is that many arrays are still not readable from the repl, because the new compiler doesn't handle them yet <wingo>and you had some test cases designed to stress this but they didn't actually go through the compiler <lloda>wingo: noted! some of my private code doesn't run on master b/c of that, actually... <lloda>re: the array implementation, no. 1 problem (for me) was that arrays themselves were in it. Arrays are still quite general (for example, strings and bitvectors are still arrays) so I don't think anything has been lost. <civodul>wingo: i was a bit surprised because it was quite young ;-) <civodul>but i don't know, i haven't checked the details yet <civodul>well it's good to get better performance on that part anyway <taylanub>TIL `read-eval?' and `#.', this must be some legacy stuff. (Reading bug reports ATM.) <mark_weaver>later, that same build succeeded, but that's been the pattern for this recent heisenbug. <mark_weaver>(well, maybe "heisenbug" is not really appropriate here) <wingo>we could disable the madvise call i guess <wingo>and see if that makes the issue go away <mark_weaver>keep in mind that it's not necessarily clear which commit introduced the problem. <mark_weaver>there were several commits introduced around that time, and the crash doesn't happen that often. <mark_weaver>I wonder how hard it would be to rig things so that we get a C backtrace from hydra when it happens. <wingo>we could install a sigsegv handler of course :) <wingo>not something i want to maintain tho :) <wingo>there might be a glibc routine, or an LD_PRELOAD thing we can do <mark_weaver>I wonder if the new guile-scriptable gdb would help here. <dje42>Does valgrind work well on guile? <wingo>well, i use callgrind for profiling <wingo>i don't use memcheck very much <civodul>there's a suppression file somewhere, right? <wingo>i think so; perhaps the googles know <madsy>Hm.. I wonder if I should toss this code out and begin from scratch <madsy>Rather than implementing a high-level wrapper for OpenGL as guile functions, implement low-level OpenGL as guile functions and create the high-level interface in scheme <davexunit>I would suggest writing as much Scheme and as little C as possible. <davexunit>madsy: I think that I've been in a very similar situation to yours. <madsy>Thanks. I'll create a new branch and try that <davexunit>I was trying to write mostly C and expose a small Guile API. Now I'm writing purely Scheme. <madsy>The nice thing about my high-level API was to have transparent objects for stuff like textures and other OpenGL objects <madsy>Having integers as objects feels clunky and not very scheme like <davexunit>I write high level wrappers around the low level GL stuff. <madsy>Yep. I just think having integers as the "lowest" level is icky too, that's all <madsy>Guess I just have to get used to it <madsy>I don't mind it in C or C++ ;-) <madsy>But when I code scheme, I code with beauty in mind <davexunit>you need to build up a beautiful language on top of that stuff. :) <madsy>By the way, what's the most efficient array type to use in guile, when I need to convert it to a C array in my C code? <madsy>I think I have seen more than one type of array <davexunit>you will use them a lot if you use guile's FFI. <davexunit>you can convert them to foreign pointers with bytevector->pointer and such. <madsy>So I can use memcpy directly instead of copying every element while iterating <madsy>What if I want an array of a certain scheme type, like floats, and not a bunch of bytes? <davexunit>bytevectors can be accessed in different ways to yield integers or floats. <davexunit>check out the bytevectors section in the manual. <taylanub>Be wary that it's not as efficient as one might wish; offsets aren't calculated at compile-time like they are in C. I was going to make a macro-based alternative for that but lost motivation, and I believe the implementation's optimizer should do that instead, though Guile can't do that yet. <taylanub>Also, I probably need to write some "real-world" code with that to get a feeling for how convenient the API really is ... I once looked into the ELF parsing stuff of Guile and noticed use-cases that weren't handled nicely at all by my API. <taylanub>davexunit: I realize it's very complex if one never thought of how exactly C's type-system works, and my documentation is comprehensive but perhaps not the clearest, so feel free to ask any questions. (That code has been lying around idly for a long time now, I wish I had a few users. :P) <mark_weaver>taylanub: I think it needs the compile-time offset computations. admittedly, it would be fairly advanced macro work. <mark_weaver>running a loop over the type specification to compute the offset every time you access a field is very bad. <davexunit>taylanub: maybe you could take a look at guile-figl's packed-struct data type for some prior art on this stuff. <mark_weaver>taylanub: fwiw, although I haven't looked closely, I suspect that your bytestructures work would be quite useful. just that one missing piece, I think. <davexunit>it would be a nice way to write wrappers for C structs. <davexunit>I saw some common lisp code that used the FFI to describe structs that made me jealous. <cluck>yeah, cl's ability to peek and poke raw memory is really neat when you have to deal with shuffling bits around <mark_weaver>Guile's bytevectors can also peek and poke raw memory too. However, I don't doubt that there was some much nicer APIs currently available for CL. <mark_weaver>I suspect it's just a matter of building something higher-level on top of what we already have. <davexunit>yeah I think so. bytestructures would probably be that abstraction. <ijp>yeah, I think I quit IRC for about a month <mark_weaver>it can be useful for getting work done, sometimes :) <ijp>I didn't really have a reason, it just sort of happened <taylanub>Now that I think of it, I remember I had an idea of turning the procedural/dynamic bytestructure implementation into the desired syntactic/static one by use of some thin wrapper macros that would force the offset-calculation of the existing implementation to happen at compile-time. <taylanub>Hrm, apparently it doesn't cause an error when my #:export list of my `define-module' form lists a variable that isn't even defined. (When I import the module, it simply isn't there; compilation shows no warnings either.) Is there a rationale, or should I file a report ? <ijp>well, it could be defined at runtime <mark_weaver>yeah, it's not clear how to implement the checking, given the current nature of guile modules. <mark_weaver>namely that in guile, first the module is declared with its export list, and then the bindings are added later at runtime. <davexunit>so, I've discovered sweetjs, a way to write macros in javascript. <davexunit>and I should think "that's cool" but instead I'm thinking "this might be bad for sexps". <taylanub>I'm pretty sure that macros for non-homoiconic languages have been implemented many times in the past, and never became popular enough for even lispers to know of it. :P <ijp>sweet.js was written by an ex-racket guy <ijp>pre-syntax-parse though <davexunit>yeah, the source files still need to run through some compiler <davexunit>which makes it not as nice as the macros we've come to love in lispland. <ijp>actually, I mixed up the initial author with one of the contributors <taylanub>Perhaps, conversely, people will get the taste of macros, but have horrible experiences with the non-homoiconic syntax, then decide to try out a homoiconic language. :) <davexunit>people love JS, good luck getting them to change their minds. <taylanub>Could always sell them a homoiconic JS with all the misfeatures like the object-system and duck-typing removed and a couple neat features added like first-class continuations. <wingo>first-class continuations are silly :) <taylanub>Don't delimited continuations fall under "first-class continuations" ? <TravisD>Hmm, this is a really random question, but do you pronounce SICP as S-I-C-P or sick-pee? <ijp>after the great renaming, it should have been sic? <ijp>but as a rule, acronyms get spelled out <ijp>TravisD: what jcowan calls the change in r[23]rs when scheme got rid of a lot of the sillier lisp names <ijp>TravisD: so, e.g. nullp became null? <TravisD>ah, I'm not familiar enough with scheme to know :) Hehe, that's good though <TravisD>oh weird, I just assumed the convention was always to put a ? after it <TravisD>I guess that doesn't really mean that it's a predicate though <davexunit>it's one of those "so terrible that I like it" things. <wingo>maybe we need a third boolean <ijp>besides, we already have a third boolean <ijp>but the less said about #nil the better *mark_weaver is now connected to the net using the FSF-approved USB wireless adapter, using firmware that he built from its free source code. <wingo>what compiler did you use, out of curiosity? <mark_weaver>it includes a nice little set of makefiles and scripts to build the toolchain (mpfr/mpc/binutils/gcc) with minimal patches. <ft>And which adapter is that? <davexunit>I have thinkpenguin's mini pci-e wireless chip. <mark_weaver>davexunit: yeah, I built the toolchain and firmware on my Yeeloong, using a pure Guix environment. <mark_weaver>(only Guix packages in my PATH and various other environment variables) <mark_weaver>I recently made the switch to a pure Guix user environment, within X. <davexunit>it will be a nice day when I'm running guix full time. <mark_weaver>(I still need non-Guix stuff to boot the machine, and the X server is still not built from Guix. But the window manager and everything else within is from Guix) <ArneBab>SRFI-105 suggests that neoteric is part of curly-infix. Can I enable curly-infix without neoteric expressions? (testing #!curly-infix looks like it does not actually do neoteric expressions but I’m not sure if I miss something) <mark_weaver>ArneBab: neoteric expressions are not enabled at the top-level, but are enabled within curly brackets (to any depth) <ArneBab>then it should not hurt wisp (within the curly-braces wisp-processing is disabled anyway) <ArneBab>I now documented using curly-infix with wisp <ArneBab>(and wanted to ensure that I did not miss anything) <ArneBab>(there is now a section with an example and a note how to enable it) <mark_weaver>curly-infix seems to me like a very natural thing to use along with wisp. in certain select cases where it improves readability, not all. <madsy>davexunit: Do you use symbols, keywords or constants for your OpenGL enums? <ArneBab>mark_weaver: the fibonacci-example definitely benefits from curly infix <ijp>on #emacs earlier, we were discussing the possible benefits of color <davexunit>madsy: figl has implemented an enumeration macro and I use that. <davexunit>for example, (begin-mode quads) will look up a key for quads in an alist (I think) and return the associated integer value. <madsy>davexunit: I see. Not a bad idea. <ijp>ArneBab: have you seen colorforth? <ijp>the idea is that instead of adding in new kinds of syntax, you would instead have new colours <ijp>comments would be one colour, keywords another, etc. <ijp>so a blue "if" might refer to the keyword if, but a red one to the variable "if" <ijp>there is a similar idea in Coq, where notations are defined in particular scopes <davexunit>interesting idea, but I can't help but think that it would computer programming even harder for the blind. <taylanub>Hrm, in my bytestructures code, the procedure to be ultimately applied to a bytevector comes from some record object; since macro output can't contain procedures, I'll at minimum need to expand to code that makes some record fetches. Unless I change the base system substantially, which is what I want to avoid. :\\ <ArneBab>ijp: it seems to me that this could simply be achieved with ascii and highlighting <ijp>ArneBab: well, we already do it, kinda, with syntax highlighting <ijp>this is just a substitution of punctuation for colour <taylanub>Let's extend Emacs's Elisp engine to treat propertized strings specially while reading. :P <madsy>Hm.. does the guile documentation format support clickable web urls? <wingo>you mean the .texi format? look for @url or @uref in the "info texinfo" <madsy>Nice to have links to longer documentation for bigger APIs <cluck>ijp: that sounds really stupid in a way, colors end up being types but how do you define a color with your editor? what if you're daltonic? i mean, i'm not against using multidimensional spaces to simplify the resolution of certain tasks (yay, quaternions for gaming!) but that sounds awfully annoying (ie, no changing themes for daytime/nighttime/indoors/outdoors etc ) <ijp>cluck: I'd say name the scopes, and let the user choose the colour <cluck>mark_weaver: fwiw, i'm jealous. congratulations :) <ijp>id_scope, keyword_scope, comment_scope, whatever <cluck>ijp: don't get me wrong, i like the idea (heck i was rooting for rms when he said on the ml he wanted emacs to be wysiwyg) there's potential there (synaesthesia can be helpful at times) but i don't think it necessarily belongs in the programming language stack <mark_weaver>cluck: no need to be jealous. you can do it too if you want :) <madsy>What about different fonts for different semantics? Or audible queues? :p <cluck>mark_weaver: i'm running on cheapskate mode right now, can't afford hw for recreational purposes right now, didn't you hear? europe is under an economic crisis right now! :D <ijp>madsy: different fonts for different threads :) <ijp>then mix the code in a horrible overlapping way <madsy>The Fortress language understands unicode symbols. I think that's kind of a cool concept <madsy>But colors.. I'm not impressed <cluck>madsy: that's the suggestion of colorforth's author and also why i was saying it doesn't belong in the programming language stack <ijp>unicode symbols are not really an evolution though <ijp>they're just the obvious next thing <madsy>ijp: I know. Some other older language already did it before Fortress <madsy>I just don't remember which one <cluck>ijp: tell that to APL fanboys <ijp>the only problem with unicode symbols is input <madsy>ijp: That's why fortress both allow unicode and ASCII constants like \\sum <madsy>So either you use the unicode coding point for sum, or you use "\\sum" <ijp>which is really the problem with most ideas for a separate display versions of the language <ijp>hmm, I think there was a separate display version of algol <madsy>ijp: And there's nothing in the way of making an IDE for fortress with buttons/digital keyboards for unicode symbols <cluck>emacs already supports a superset (yes SUPERSET) of unicode <ijp>I can't find a decent cite, but there does seem to have been a "publication" variant of algol 60 <madsy>If I want to put my C-defined guile functions with scm_set_current_module(), what do I put as a parameter? A symbol? <ArneBab>madsy: using λ in guile works quite well, and I think Σ and ∫ would be very nice additions for implementing algorithms. <madsy>Or do I have to create a module and pass that? <madsy>Err.. I want to put my functions in a module with scm_set_current_module() I mean <ArneBab>madsy: being able to use them just requires a good keyboard layout (I can input them directly) <ijp>(set-input-method "TeX") <ijp>(just so no-one is confused, that was not the result of emacs TeX input method, but a script I have) <taylanub>I don't have the required fonts .. now I'm really curious. :P <ijp>taylanub: fraktur factorial <ArneBab>ijp: does it select fraktur-letters from higher unicode code points? <ijp>ArneBab: incidentally, the code range is not continuous, so I just used a table <ArneBab>taylanub: it’s not fonts, it’s symbols. Like Chinese <ijp>a few of the capitals were included in an earlier revision (symbols for field, etc.) <taylanub>Oh, Wikipedia explains, there's just a couple intended as maths symbols ... <ijp>the rest of "mathematical bold" was added later <ijp>I also have a script for: (ｄｅｆｉｎｅ (ｆａｃｔｏｒｉａｌ ｘ) (ｉｆ (ｚｅｒｏ? ｘ) 1 (* ｘ (ｆａｃｔｏｒｉａｌ (- ｘ 1))))) <ijp>but I can actually type that one in <ijp>fullwidth makes a little more sense to include than mathematical bold <ijp>taylanub: I thought germans were deprecating ß anyway <ArneBab>ijp: in the new spelling, ß was just defined much stricter: It is the long sharp s. <taylanub>With "long" don't they actually mean that the preceding vowel is pronounced long ? <mark_weaver>madsy: use 'scm_c_define_module'. See the manual section 6.20.3 (API Reference -> Foreign Function Interface -> C Extensions) for an example. <ArneBab>taylanub: the short sharp s is the double s. <mark_weaver>madsy: btw, Guile already supports Unicode identifier names. <mark_weaver>in fact, λ is in the default namespace, as an alias for lambda. <ArneBab>ass (as in “pik ass”) vs. aß (as in “I ate”) <taylanub>I see, thanks. (I live in Germany, should learn this stuff. :P) <ArneBab>taylanub: if you have questions, feel free to ask ☺ <ijp>ArneBab: I'd be more surprised if you didn't <ijp>who has time to create #x1F389 glyphs for a font? <ArneBab>ijp: that would be easy if most fonts were free. But sadly the vast majority of fonts are strictly proprietary ☹ <ijp>there are people trying to do fonts for all the BMP, but I don't think there is a concentrated effort for non BMP codepoints <ijp>and then you get into combining characters... <ijp>.oO(I wonder if my font supports hierogyphs?) <taylanub>ArneBab: BTW you have like the most possibly German surname ever. <ArneBab>what I miss in fonts is that there is no clean fallback mechanism: each glyph should have an implementation in some permissively-licensed base-font, and if my font does not have it, the glyph should be taken from other fonts <ArneBab>taylanub: ah - yes ☺ — but very memorable: If people learned it once, they seldomly forget it ☺ <taylanub>Indeed, I just noticed that I strangely have no problems memorizing it! <ArneBab>back when I was at school, half the pupils knew my name - which is kind of a mixed blessing ☺