IRC channel logs


back to list of logs

<davexunit>I discovered that there is a before-eval-hook that I can take advantage of. :-)
<davexunit>now, I think that it still might not solve all of my issues. I think SDL does not allow you to use certain features from another thread.
<davexunit>so, I might need to look elsewhere for image loading procedures.
<davexunit>I think only shanecelis and mark_weaver will understand what I just said.
<nalaginrut>morning guilers~
<nalaginrut>anybody called me? I saw the notification, but the log didn't record (too long)
<taylanub>Maybe it was
<taylanub>2013-07-30 14:32:11.301935667 +0300 brendyn nalaginrut: I found Skribilo, it looks cool. i wonder if its usable for blogs too
<nalaginrut>taylanub: hah~thanks
<taylanub>Hrm, don't we have channel logs somewhere ?
<nalaginrut>IIRC, rotty made one
<dsmith>it's gone
<dsmith>mark-weaver has got one I think.
<dsmith>sneek, logs?
<sneek>Someone once said logs is
<dsmith>If you click your heels and say mark_weaver mark_weaver mark_weaver, sometimes he appears..
<nalaginrut>well, I guess he bind the IRC notification with a big clock
<nalaginrut>skribilo is so cool to believe...the problem is 'no markdown' hmm...
<taylanub>It seems there are parts in Guile that can't take #nil yet ...
<taylanub>I hate it when I find something that's probably a bug, but can't find enough info to make a proper report.
<nalaginrut>taylanub: me too...
<nalaginrut>wingo: heya
<nalaginrut>wingo: well, busy for moving house
<nalaginrut>wingo: seems inner http server can't handle multiform/data ?
<wingo>heh, moving house is always a pain
<wingo>yep, it seems there is no multipart/form-data support
<wingo>not sure what such support would look like, though :)
<amirouche>nalaginrut, you succeed at compiling skribilo ?
<ArneBab>Any chance to get guile versions of the programs in the debian language benchmarksgame?
<nalaginrut>amirouche: no, just read the intro, didn't try
<nalaginrut>wingo: I'll add it in Artanis
<nalaginrut>but for efficiency, maybe I have to custom the server, fortunately, we have flexible inner server framework ;-)
<nalaginrut>the problem is the default http-server will read the http-body in a row, it's not efficient and I can't do any control to avoid too large uploaded file
<amirouche>the proxy can handle that
<nalaginrut>amirouche: you mean use a reverse-proxy in Guile?
<nalaginrut>but my plan is Artanis could be a standalone server or work with Nginx
<amirouche>I wasn't thinking about a reverse proxy in guile, but nginx
<nalaginrut>since I believe Guile would have power on server development, in the future, or in few months..hmm...
<amirouche>so artanis project is not dead ;)
<nalaginrut>amirouche: It won't be dead, I wrote it for building a community site, some guys waiting for it
<amirouche>I'm also looking for a web framework for doing... web stuff using guile
<nalaginrut>amirouche: Artanis based on real needs of site building, so I think it'll have practical code snippets or docs for the users
<amirouche>I hope at one point we can join forces
<amirouche>right now I learn guile
<nalaginrut>it's good start you're learning Guile
<nalaginrut>besides, we have guile-redis now, so users may take advantage of other useful packages work with Artanis
<nalaginrut>it'll come true, if guildhall become more powerful
<nalaginrut>I wish it could handle C+Guile project now...
<wingo>what's the line width limit? 100?
<wingo>sorry, wrong channel
<nalaginrut> updated, so many errors fixed, since it's copied from Racket version, many things are different from Racket ;-(
<amirouche>I read that
<brendyn>greetings dirty schemers
<ArneBab>nalaginrut: I get a 404 when trying to access the link at the end of your text: — otherwise a pretty nice read!
<davexunit>nalaginrut: artanis is really cool!
<taylanub>Damn, sometimes (or always?) the Elisp nil will appear as a symbol to Guile. (Playing with Guile Emacs).
<taylanub>Ok, this is certainly wrong: (funcall (guile-ref (guile) null?) nil) => #f
*taylanub wishes bipt` was more active on IRC .. e-mail is slow.
<taylanub>I guess nil and #nil simply aren't reconciled yet. I see strings aren't either ..
<taylanub>`t' and `nil' in Elisp are symbols (per `symbolp'), have symbol-plists like any other symbol, give "t" and "nil" when passed to `symbol-name' (think `symbol->string'), etc. etc., I wonder now if Guile's #nil solution can really handle all these cases ?..
<dsmith-work>Hmm. Wouldn't it depend on the current local language? So in scheme #nil is the same as elisp nil ?
<dsmith-work>In scheme, nil is just another symbol
<wingo>i think probably (symbolp nil) => t
<wingo>but (symbol? #nil) -> #f
<taylanub>I see a couple possible strategies: 1) Make nil and #nil be the same object in memory, 1.a) if it's Guile's #nil (a very simple atomic value), then add some weird hacks to some Elisp things like `symbolp', `symbol-plist', etc. to make it still look like a symbol to Elisp, 1.b) if it's a symbol, take care that this doesn't affect Scheme performance, 2) make them separate objects, and convert between them at some points.
<wingo>(1) i think
<taylanub>I'd guess 1.b is the way to go, making Guile's #nil a bit more complicated and actually act like a symbol, because currently it doesn't ...
<wingo>nope, would make scm_is_true and related things more difficult
<taylanub>Yeah, that's what I had in mind wrt. Scheme performance.
<taylanub>Hrm, Elisp hacks are the way to go then ? We'll need to insert special-case code to at least `symbolp', `symbol-plist', `symbol-value', `symbol-function', ...
<taylanub>If I'm seeing it right, there already *are* some weird hacks in the standing Elisp code for nil and t, so maybe things won't really be any dirtier.
<dsmith-work>There was a lot of work and discussion choosing the current values of #f and #nil so that things like scm_is_true are very effcient.
<taylanub>Can it not just use pointer comparison or so if #nil were a symbol ?..
<wingo>taylanub: are you planning on contributing?
<taylanub>Slowly trying to get into both code-bases of Emacs and Guile.
<taylanub>I feel I have a lot to learn ...
<wingo>we definitely need more guilemacs hackers :)
<davexunit>there seems to be some resistance to guilemacs, from what I've seen on #emacs.
<wingo>that's natural
<dsmith-work>davexunit: They just don't know what's good for them...
<wingo>we simply have to be so awesome everyone will realize it :)
<taylanub>Nah, just skepticism, and that will probably go away once we can show off a couple neat things. :P I managed to write built-in macros `guile-ref' and `guile-private-ref' for Elisp which work like @ and @@, and make funcall/apply and symbols' function-slots take Guile procedures, so we could prepare some neat examples of Elisp code using Guile now, maybe.
<taylanub>nicferrier doesn't seem to believe in "one community, two languages" though, that's one actual opposition I've seen so far.
<wingo>i don't think that will win people over
<wingo>faster elisp will be the thing
<davexunit>people seem to be worried about fragmentation if Guile becomes available as a language that emacs extensions can be written in.
<dsmith-work>When emacs runs 10x faster and gnus doesn't hang forever people won't complain.
<wingo>dsmith-work: right.
<davexunit>that's true. I think that will win people over.
<wingo>though don't quote numbers to anyone :)
*davexunit stops typing "Guile confirmed to be 100x faster for Elisp" in #emacs
<taylanub>Hrm, I'm actually in the "faster than fast enough is still just fast enough" camp, and Emacs seems "fast enough" usually, but I guess there's a couple pathological cases like M-x term.
<taylanub>Re. Gnus, there's already a non-Guile threading branch in upstream Emacs. :P
<dsmith-work>Don't tell anyone...
<taylanub>I'll see if I can make Elisp use #nil and see what breaks ...
<YoungFrog>I hope for you it breaks loudly.
<taylanub>Yeah, segfaults everywhere. :P
<YoungFrog>that's fine
<bubu>hello dear guile masters,
<bubu>i have a array of dimension N 2 and would like to work on each of its columns, is it possible in a reasonable way ?
***alexei___ is now known as amgarchIn9
<davexunit>bubu: I believe so. I don't know the array API so well, but it should be fairly trivial to operate on a column easily.
<davexunit>arrays are column major right?
<davexunit>greetings, wingo
<bubu>davexunit, that's what i'm wondering
<bubu>and how to do it
<bubu>it would make things really proper this way
<davexunit>bubu: are you looking for things like map/for-each that operate on arrays? I'm not sure that those exist.
<davexunit>I've used srfi-42 to iterate over the array elements in the past.
<davexunit>for example:
<bubu>davexunit, something like that, i would like for example, tu add both columns of the array
<bubu>array[i][0] + array[i][1]
<bubu>through a "map" like command this would be great
<bubu>but i think it assumes that you can decompose your array as a vector of vectors (set of columns)
<bubu>and i don't know how to handle this properly
<davexunit>I don't know if those just exist in the array API. I think that they would be not-too-hard to write, though.
<davexunit>your example reminds me of the numpy library for python.
<bubu>(maybe because I want to do something similar to what numpy was designed for)
<bubu>but I would expect to be able to do it directly with the guile objects
<davexunit>bubu: I think you could quite easily implement something suitable. srfi-42 would be a good start.
<bubu>i don't want to, neither do i have the skill for it, i'm expecting some array->vector of columns function as it seems equivalent in memory to me
<davexunit>perhaps you will catch the attention of someone more knowledgable than myself that can send you in the right direction.
<davexunit>I imagine you want to write these operations such that they modify an array in-place rather than making a new array?
<davexunit>arrays, especially large ones, don't make much sense to use as immutable data structures to me.
<davexunit>bubu: there is array-map!, array-for-each, and array-index-map! that you can use
<bubu>The src arrays must have the same number of dimensions as dst, and must have a range for each dimension which covers the range in dst.
<bubu>my issue is to figure out how to deal with "sub-arrays"
<davexunit>ah, I see.
<bubu>now I have circumvent this by using a vector of vectors
<bubu>(to have a set of columns)
<bubu>but it really isn't that convenient
<davexunit>an array is essentially a vector of vectors
<bubu>yes it is
<bubu>but how to manipulate it this way ?
<bubu>(starting from a make-array)
<davexunit>I wish I knew more about arrays. I'm not free to tinker with guile stuff at the moment.
<bubu>the other this i was wondering is if there things like "pointers" or "references" to manipulate these columns
<bubu>because i have to (vector-ref mat 0) everytime i want to access one of the columns
<bubu>and as i'm not familiar enough whether functions return a new object or not
<bubu>I struggle a bit
<bubu>I would like to have something like (let ((col1 (vector-ref mat 0)) (col2 (vector-ref mat 1))
<bubu>and (vector-set! col1 index value)
<bubu>now i'm not sure it will update mat
<bubu>i have to check that
<davexunit>bubu: why doesn't that work. col1 and col2 are vectors in mat and you are mutating them.
<davexunit>so that will be reflected in mat
<bubu>I don't know, I have to try
<bubu>but I could suspect that (let ((col1 (vector-ref mat 0))
<bubu>would copy the column from mat[0]
<davexunit>why would it do that?
<bubu>I don't know, I'm just not familiar enough with functional programming
<bubu>In my head it's just, "everything is copied and you don't have things like pointers"
<davexunit>that is incorrect.
<davexunit>col1 and the vector at mat[0] point to the same place in memory
<davexunit>if you're thinking about the more pure side of functional programming, then values are immutable. this is not the case here.
<davexunit>the vector that you run vector-set! on is the same vector that is at mat[0]
<bubu>yes, just made a tiny program to check that
<bubu>seems to work
<bubu>good to know
<davexunit>bubu: you are doing matrix math?
<bubu>columns math
<davexunit>oh, okay.
<davexunit>I was just wondering why you chose to use vectors/arrays over lists.
<bubu>I did with list once
<bubu>bad idea
<bubu>terribly slow
<davexunit>yeah, it depends on what kind of operation you are doing.
<jave>I tried guile-emacs today, pretty impressive!
<jave>I did get a segfault, but that might be because I use a fedora provided guile
<davexunit>jave: you could try your luck with guile 2.0.9. not sure what fedora is providing.
<davexunit>I know debian is stuck on 2.0.7
<davexunit>actually, I don't know that. that's what I *think* it is.
<jave>fedora has 209
<davexunit>oh cool
<jave>yeah, they were stuck on guile 1.8 like forever, and then suddenly 209
<davexunit>it's taken guile a long time to get out of the 1.8 rut.
<davexunit>still in it in many places.
<taylanub>jave: What lead to the segfault ?
<jave>taylanub: it was at the end of my init, im not sure
<jave>emacs -Q runs fine, the stuff i tested anyway
<jave>possibly the "powerline" package
<jave>no, that wasnt it i think
<jave>the gdb bt shows scm_equal_p ()
<taylanub>Interesting, I only ever managed to crash it by exhausting the heap by opening some crazy e-mail in Gnus.
<jave>hmm seems like "recentf" is problematic
<jave>taylanub: care to see if you also get segfault with recentf-mode?
<taylanub>My build is screwed up at the moment because I'm playing with the C code, let me see if I can get a sane build ..
<jave>no worries
<jave>im running my entire .emacs now in guile-emacs, minus recentf. impressive!
<taylanub>jave: I did (require 'recentf), fine so far ..
<jave>I suspect it depends on which files are on the recentf list.
<jave>you also need (recentf-mode)
<taylanub>Returned t.
<jave>I can reproduce it only with the rest of my .emacs, but problem goes away if i comment out recentf-mode
<taylanub>Do you have the full backtrace ?
<jave>i mailed it to bipt
<taylanub>YAY! I managed to reconcile nil and #nil .. the hacks are dirty, and I'm not sure about performance implications, but it only affects Elisp, and once we compile that anyway, should be fine .. or maybe someone will find a better solution.