<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. <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'm having a hard time deciding if I should work on minix or hurd. <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 ./autogen.sh <zacts>mark_weaver: what would you do in my situation? <zacts>well there is x15 in the brew <davexunit>hurd is interesting. I've never used it, though. <fbs>or write your own kernel <zacts>mark_weaver: do you know what x15 is? <zacts>the initial commit was in 2012 <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.. <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. <zRecursive>because in money.scm, some functions need to use data files in that directory <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>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') <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. <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>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. <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>well, I guess that would be (define data-dir (string-append (getenv "MD") "/money")) <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. <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: 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. <mark_weaver>2.0 is a *major* improvement over 1.8. well worth the effort to upgrade. <mark_weaver>nalaginrut: since it's not yet finalized, it seems premature to work on it. *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. <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>i want the user input the form to be evaluated ... <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>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. <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? <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>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>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>so $expr can contain multiple top-level expressions, and you want each one printed, is what you mean? <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. <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. <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>Guile has a special "unspecified" value which the REPL detects and does not print. <mark_weaver>the unspecified value is returned by many expressions that aren't really meant to return anything. <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>(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. ***chaos__ is now known as Chaos`Eternal
<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. <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>scheme@(guile-user)> (eq? *unspecified* (if #f #f)) <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. <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^_>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. <fbs>yea network-error doesnt exist anymore, forgot to replace it <fbs>add^_: i merged your pr <fbs>still need to update to autoload tho <fbs>hmm i broke the dev branch tho <fbs>i always mess git up <fbs>and put in 2 wip commits <fbs>the master branch should now work, including your patch :) <fbs>time for dinner, thanks <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? ;-) <add^_>Make your own bot that sets a good example ;-) <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. <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. <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