IRC channel logs


back to list of logs

<mark_weaver>basically what we see in that message is the "open source" philosophy, i.e. that the "relevance" of RMS was that he created a body of software that was technically good. For those of us who consider freedom to be more important than technical issues, i.e. the free software movement, he is still quite relevant.
<mark_weaver>IMO anyway
<zacts>technical issues would be important to copyleft. the goal is to make copyleft superior to all other versions of the same kind of software. right?
<davexunit>the goal is for all software to be free software.
<zacts>but that is not a realistic goal. in reality we have non-free software
<zacts>so you have to take that into account imo
<mark_weaver>my goal is freedom for computer users, notably the four freedoms in GNU's free software definition.
<mark_weaver>it is true that making the software "better" from a technical and practical standpoint is an important goal, but if I have to choose between a technically superior non-free software package and an inferior free software package, I will always choose the latter. Freedom is more important to me than technical convenience.
<mark_weaver>Also, I should note that if the goal is technically superior free software (the best of both worlds), the logical starting point is the inferior free software. Technical problems can be fixed over time. However, there is no reliable way to fix the license of an existing piece of non-free software.
<zacts>I agree with that
<zacts>I'm having a hard time deciding if I should work on minix or hurd.
<taylanub>Which one is GNU ? :)
<zacts>but I own the minix book, so I thought I would start with that to learn how OS work, and then maybe work on hurd
<davexunit>guile-related question: I'm getting an error during configure: ./configure: line 45863: syntax error near unexpected token `LIBFFI,'
<davexunit>I am on debian and have libffi-dev installed. pkg-config --modversion libffi returns 3.0.10
<mark_weaver>that's because you didn't have the FFI dev package when you ran ./
<davexunit>a-ha. thanks!
<mark_weaver>(I think)
<zacts>mark_weaver: what would you do in my situation?
<mark_weaver>hurd :)
<zacts>well there is x15 in the brew
<davexunit>hurd is interesting. I've never used it, though.
<zacts>and propel
<fbs>or write your own kernel
<mark_weaver>x15 in the brew? what do you mean?
<zacts>mark_weaver: do you know what x15 is?
<zacts>it's a new microkernel
<zacts>let me post a link
<fbs>'new' ?
<zacts>the initial commit was in 2012
<fbs>only of that repo
<zacts>the other one yes, is older
<fbs>but i guess its new for kernels
<davexunit>yay I finally have guile compiling on my new VPS
<zacts>I think I'll take your advice mark_weaver fbs
*dsmith-work wonders what a VPD is..
<dsmith-work>vpS even
<mark_weaver>sorry, busy at MIT's radio station at the moment...
<zRecursive>guile -q -l money.scm -c "(div618 4.45 8.29)" works great if executed in the directory containing money.scm. However, guile -q -L $MD/money -l money.scm -c "(div618 4.45 8.29)" will report: ERROR: In procedure open-file: ERROR: No such file or directory: "money.scm" if not in the same directory as money.scm. "-L $MD/money" doesnot work ?
<mark_weaver>zRecursive: %load-path (which is augmented using -L) is used by 'load-from-path' and 'use-modules', but not by 'load' (-l)
<waxysubs>'load' takes a filename (always interpreted relative to the current directory), not a module name.
<mark_weaver>oops, I meant to type that (waxysubs is my logger)
<zRecursive>i see now, thx
<mark_weaver>np :)
<zRecursive>then i must `cd` to the directory using -l ?
<mark_weaver>why not do -l $MD/money/money.scm ?
<zRecursive>because in money.scm, some functions need to use data files in that directory
<mark_weaver>-L wouldn't help to find data files anyway.
<zRecursive>i.e. (call-with-output-file "foo.txt" ...)
<mark_weaver>well, if you write code like that, then indeed you must 'cd' to the directory that is to contain 'foo.txt', yes.
<zRecursive>as it is using relative path
<zRecursive>i am using (asdf:system-relative-pathname 'my-system "foo.txt") in CL, iirc
<mark_weaver>your options include: (1) 'cd' from outside the script, (2) 'chdir' from within Guile, (3) construct the pathnames using a helper procedure from within your code.
<mark_weaver>obviously (2) and (3) require passing in the desired data directory as a parameter or environment variable (which could be accessed using 'getenv')
<zRecursive>mark_weaver: i see now, thx
<mark_weaver>for files that already exist, Guile has 'parse-path', 'search-path', and '%search-load-path' that might be useful.
<mark_weaver>but that won't help for new output files, obviously.
<zRecursive>does '-L' work for data files ?
<mark_weaver>No. -L just adds to %load-path, which by default only affects loading of code modules using 'use-modules' or 'load-from-path'. but of course you can access %load-path from within your code and do whatever you like with it in theory.
<mark_weaver>since -L puts the specified directory in the front of the load path, you could get it using (car %load-path), but IMO that would be kind of an ugly hack.
<mark_weaver>%load-path is simply not meant to specify a data directory.
<zRecursive>yeah, i will use (1) or (2) as you suppested
<mark_weaver>yeah, I think that would be best.
<zRecursive>guile -q -l $MD/money/money.scm -c "(chdir \\"$MD/money\\") (some-func)" works great !
<mark_weaver>as long as $MD doesn't contain a funny characters, that should be fine.
<zRecursive>mark_weaver: MD is a environment
<zRecursive>MD is defined in ~/.cshrc
<mark_weaver>what's the relevance of that?
<mark_weaver>you could access it from within Guile using (getenv "MD") then.
<mark_weaver>so you could do something like (define data-dir (getenv "MD")) and (define (data-path file) (string-append data-dir "/" file))
<mark_weaver>and then use (data-path "foo.txt") in place of "foo.txt"
<mark_weaver>just throwing out ideas...
<mark_weaver>well, I guess that would be (define data-dir (string-append (getenv "MD") "/money"))
<zRecursive>yeah, it is what i need
<zacts>are there any common ./configure options I should maybe want to set for guile, or for general use am I fine with just a plain ./configure?
<mark_weaver>just a plain ./configure is what I usually use, fwiw.
<zacts>that works for me
<Chaos`Eternal>who wrote (ice-9 occam-channel) ?
<Chaos`Eternal>i mean, who has documents about that module...
<zRecursive>I have a function: (define (stopLoss qty pb lossRate) ...) in which lossRate should defaults to 0.02, how to define such a default value ?
<mark_weaver>Chaos`Eternal: I'm not sure. Unfortunately we have some old undocumented modules in ice-9
<mark_weaver>zRecursive: (define* (stopLoss qty pb #:optional (lossRate <default-expr>)) ...)
<mark_weaver>where <default-expr> can refer to any of the earlier arguments.
<zRecursive>mark_weaver: thx
<nalaginrut>mark_weaver: can we add define-values?
<Chaos`Eternal>mark_weaver, i c ...
<zRecursive>mark_weaver: ERROR: In procedure memoization: ERROR: Bad formal #:optional in expression (lambda (qty pb #:optional (lossRate 0.02)) ...
<mark_weaver>zRecursive: you need to use 'define*' instead of 'define'.
<zRecursive>ERROR: Unbound variable: define*, sorry i am using Guile 1.8.8
<mark_weaver>nalaginrut: making an efficient 'define-values' is non-trivial, and quite possibly we won't have it until 2.2. if you're impatient, there's a portable definition of 'define-values' in R7RS section 7.3.
<mark_weaver>zRecursive: can you upgrade to guile 2.0? 1.8 is not really supported anymore.
<nalaginrut>mark_weaver: speak to r7rs, how is it in Guile?
<mark_weaver>2.0 is a *major* improvement over 1.8. well worth the effort to upgrade.
<zRecursive>mark_weaver: there is no 2.x in freebsd ports
<mark_weaver>nalaginrut: since it's not yet finalized, it seems premature to work on it.
<nalaginrut>I'll recommend 2.0.9 if you want to upgrade
*zRecursive maybe i will upgrade it by passing the freebsd ports
<mark_weaver>zRecursive: I'm not sure what's the best way to do an optional argument in 1.8. I can tell you a way that will work, but it's not nice.
<mark_weaver>I really think it's worth upgrading to 2.0.9
<zRecursive>mark_weaver: ok, i will upgrade it later. BTW, why guile -q -c "(+ 1/2 1/3)" no output in xterm ?
<mark_weaver>printing the result of an expression is only done automatically in the REPL. with -c, you need to explicitly print the result.
<zRecursive>oh, not same as `clisp -x (+ 1/2 1/3)` !
<zRecursive>i want the user input the form to be evaluated ...
<zRecursive>not using REPL
<mark_weaver>it _is_ evaluated, but the result is not printed by default.
<zRecursive>i see but seems non-convenient for the user to input
<mark_weaver>guile is not really meant to be used to evaluate small snippets within a shell script.
<mark_weaver>so it wasn't a case we optimized for.
<mark_weaver>one easy way is to write your own little script that contains something like: (define (% x) (write x) (newline))
<mark_weaver>and then do: guile -q -l <the-script> -c "(% (+ 1/2 1/3))"
<mark_weaver>or better yet, write a little script that evaluates its argument and prints the result.
<mark_weaver>so then it's just: my-guile-eval "(+ 1/2 1/3)"
<zRecursive>mark_weaver: i am not sure which functions should be wrapped by (%)
<mark_weaver>out of curiosity, did you want to use this within a shell script, or interactively at the shell prompt?
<mark_weaver>% just prints its argument along with a newline
<zRecursive>it is in a sh script which uses zenity to get the user's input
<mark_weaver>well, you could just do: guile -q -c "(write (+ 1/2 1/3))"
<mark_weaver>just beware that it will not print a newline, so if you use it interactively the next shell prompt will be on the same line as the result.
<zRecursive>the user can input any valid guile expression including our customized functions
<zRecursive>res=$(guile -q -l $MD/money/money.scm -c "(chdir \\"$MD/money\\") $expr") zenity --info --text="$res"
<zRecursive>expr=`zenity --width 350 --entry --text "Please input a expression"
<mark_weaver>so just replace $expr with (write $expr)
<mark_weaver>if you need it to output a trailing newline, just put (newline) at the end as well.
<zRecursive>but some functions in money.scm itself has already called (fortmat #t ...)
<mark_weaver>okay, I don't see the problem.
<mark_weaver>based on what you wrote above, I guess that "clisp -x" will print the result as the last step. what I'm suggesting here will do the same.
<zRecursive>those functions works great now except the built in functions has no output
<mark_weaver>which built in functions? You mean like '+' ?
<zRecursive>(+ 1/2 1/3) (sqrt 1000000) ...
<mark_weaver>so $expr can contain multiple top-level expressions, and you want each one printed, is what you mean?
<mark_weaver>e.g. $expr might be "(+ 1/2 1/3) (sqrt 1000000)" ?
<zRecursive>we force user just input one top-level expr.
<mark_weaver>okay, then I'm confused. are you saying that '+' should print its result by default? so then (+ 1 (+ 2 3)) would print both 5 and 6?
<zRecursive>now (div618 4.45 8.29) works as it uses (format #t ...) in div618. However, (+ 1/2 1/3) doesnot work.
<zRecursive>(+ 1 (+ 2 3)) => 6
<zRecursive>div618 is function in money.scm
<mark_weaver>ah, I see. well, there needs to be a way for the top-level to know whether the result should be printed or whether the function already did so internally.
<zRecursive>yeah, but it is hard to know
<mark_weaver>with CL you'd have the same problem.
<zRecursive>no, clisp -x (+ 1/2 1/3) will output the result
<mark_weaver>one option would be to have the functions that did the printing internally to return a special value that means "I already printed it"
<mark_weaver>right, but then it would also print the result of div618
<mark_weaver>even though div618 already printed something.
<mark_weaver>so then you'd print a spurious result at the end
<zRecursive>here, clisp -x (div618 ...) just printed once
<mark_weaver>what does div618 return?
<mark_weaver>Guile has a special "unspecified" value which the REPL detects and does not print.
<mark_weaver>maybe clisp is doing something like that.
<mark_weaver>the unspecified value is returned by many expressions that aren't really meant to return anything.
<zRecursive>mark_weaver: div618 =>
<mark_weaver>okay, an easy solution is to add a helper function to money.scm: (define (print x) (if (not (eq? x (if #f #f))) (write x)))
<mark_weaver>and then replace $expr with (print $expr)
<mark_weaver>optionally, add (newline) after (write x)
<zRecursive>(if #f #f) ?
<mark_weaver>(if #f #f) is the simplest way to get the special "unspecified" value, the same one that is returned by many other functions like 'for-each' that don't have anything to return.
<zRecursive>i see now,thx
<zRecursive>mark_weaver: Your solution is great, thx
<mark_weaver>glad to help!
***chaos__ is now known as Chaos`Eternal
*mark_weaver --> zzz
<taylanub>Hrm, when the standard talks of an unspecified value, it really means that it doesn't specify the returned value, so testing something against (if #f #f) is probably no more portable than using the variable *unspecified* directly.
<Chaos`Eternal>(eq? (if #f #f) (for-each (lambda (x) #f) '(1 4)))
<Chaos`Eternal>$7 = #t
<Chaos`Eternal> (eq? (if #f #f) (if #t #f))
<Chaos`Eternal>$8 = #f
<taylanub>And I'm saying, that's unportable anyway, so just use *unspecified*.
<taylanub>scheme@(guile-user)> (eq? *unspecified* (for-each (lambda (x) #f) '(0 1)))
<taylanub>$2 = #t
<taylanub>scheme@(guile-user)> (eq? *unspecified* (if #f #f))
<taylanub>$3 = #t
<nalaginrut>IIRC *unspecified* is not standard
<taylanub>And of course it's probably considered bad practice.
<taylanub>nalaginrut: But it's also not standard to rely on (if #f #f) returning the same value each time.
<taylanub>It could return anything at all, whenever it wants.
<Chaos`Eternal>IMHO, when something is documented unspecified, that thing should never be used.
<Chaos`Eternal>every usage of that thing should be considered bug
<nalaginrut>there's no guarantee when one uses unstandard thing
<taylanub>If conforming to the standard, yes. If you're going to make it Guile-specific, then I'd say using *unspecified* is as good as using the return value of (if #f #f). Unless Guile guarantees that all "unspecified" values are the same but doesn't guarantee that the variable *unspecified* will hold it.
<taylanub>(And I don't think it does that; so I'd just use *unspecified* directly, if I must.)
<nalaginrut>taylanub: but even for Guile-specific, IMO there's no guarantee for *unspecified*
<taylanub>Yeah, let's see if the manual says something ..
<taylanub>I see it does mention *unspecified* in a couple places, but doesn't really explain what it is or so.
<nalaginrut>actually I've used for some purpose, and I was suggested that don't rely on it
<taylanub>Yeah, having to use it in some form probably means the code should be restructured somehow.
***Guest40126 is now known as jao
<add^_>Hello #guile !
<add^_>fbs: ping
<add^_>Aaah, nevermind fbs.
<add^_>Now theres something else fbs: Line 104 in network.scm (guile-irc project), network-error is unbound
<add^_>Haven't defined it anywhere in the entire guile-irc project.
<add^_>aha, nevermind that also, I where in the wrong branch -.-
<add^_>Oh well, I've fixed something at least, I've given the option to have gnutls disabled or enabled.
<fbs>add^_: hmm, think you need the dev branch
<fbs>im busy fixing up ddocumentation and stuff, need to merge the stuff into master once im done
<add^_>Yeah, I noticed about the dev branch
<mark_weaver>taylanub: *unspecified* is a top-level variable, which means that it produces code that always has to fetch the variable (in case it changed)
<mark_weaver>taylanub: on the other hand, the compiler can prove that (if #f #f) returns that special value.
<wingo>i think in master *unspecified* is syntax
<mark_weaver>oh, nevermind. *unspecified* is syntax, not a variable. also, there's 'unspecified?'
<mark_weaver>however, in guile 1.8, which is what he's using, *unspecified* _is_ a variable.
<mark_weaver>though I admit that efficiency is not paramount in this case, and if I'd known off-hand that guile 1.8 had 'unspecified?', I would have suggested that.
<fbs>add^_: you found a bug btw :p
<mark_weaver>sneek: later tell zRecursive I didn't know it at the time, but Guile includes a predicate 'unspecified?' that does (eq? x (if #f #f)), so you can use that.
<sneek>Got it.
<add^_>fbs: I did?
<fbs>yea network-error doesnt exist anymore, forgot to replace it
<fbs>add^_: i merged your pr
<fbs>thanks :)
<fbs>still need to update to autoload tho
<add^_>I'm glad I could help :-D
<fbs>hmm i broke the dev branch tho
<fbs>i rebased :p
<fbs>i always mess git up
<fbs>and put in 2 wip commits
<botbotbot>hello master!
<fbs>ok still works
<fbs>the master branch should now work, including your patch :)
<fbs>time for dinner, thanks
<botbotbot>hello master!
<add^_>Welcome back fbs
<taylanub>I don't like this discriminating attitude towards our bots. What if it goes sentinent one day ? It's written in Scheme after all.
<add^_>You did mean the "master" part right taylanub? ;-)
<taylanub>Yeah. :P
<add^_>Make your own bot that sets a good example ;-)
<add^_>taylanub: wb
<taylanub>I had a chat-bot in POSIX sh ... left it in a broken state when I got bored half-way through implementing the ability to be on multiple networks at once.
<add^_>I don't think my bot can do that either :-P It's using guile-irc, and I don't think it supports that yet.
<add^_>guile-irc needs more love.
<taylanub>I would make separate IRC and chat-bot modules; the chat-bot would be written in an abstract manner such that it could use different underlaying chat protocols.
<add^_>Oh well
<fbs>im not sure what the best way to support networks is
<fbs>could support it in the guile irc lib. Or just use multiple 'objects' in the bot
<fbs>taylanub: making it 'abstract' is what i want to achieve one day
<fbs>hide all the messy irc details
<fbs>but it needs a lot of work
***sneek_ is now known as sneek
***Guest47033 is now known as boredomist