<jaaso>I think gdk module name is (gnome gw gdk) <jaaso>Oh my bad, all gdk function is available without importing (gnome gdk) *civodul aims for +2 green on Hydra <Chaos`Eternal>I have a list like this, ((info) (title "helloworld") (some thing_else)) <Chaos`Eternal>and I want to generate cmdline options like this: --info --title=helloworld --some=thing_else <mark_weaver>Chaos`Eternal: it's trivial. I'd use (ice-9 match) to match the elements of your list, and do something like: (map (lambda (elem) (match elem ((key) (format #t "--~a" key)) ((key val) (format #t "--~a=~a" key val)))) lst) <mark_weaver>e.g. (map (lambda (elem) (match elem ((key) (format #f "--~a" key)) ((key val) (format #f "--~a=~a" key val)))) '((info) (title "helloworld") (some thing_else))) => ("--info" "--title=helloworld" "--some=thing_else") <mark_weaver>and then use 'system*' to run the command, so that you don't have to worry about escaping shell metacharacters. <nalaginrut>mark_weaver: as my research, your online time is 20+ hours on average, so any newcomer could call you 'bot' ;-D <Chaos`Eternal>for example, """ a string don't need to escape " would be more easier to use""" <mark_weaver>I don't know, why don't you post about it to guile-devel? I wouldn't be opposed to such a thing. <mark_weaver>note that Guile's reader is extensible, so you could add such a syntax yourself. <mark_weaver>but admittedly it would be much more convenient if it were built-in by default. <mark_weaver>the thing is, we don't usually try to find better solutions than embedding large strings within the source code. for example, for generating HTML templates, we use SXML. <mark_weaver>I suspect that's the main reason there hasn't been a lot of pressure to add such a thing. <mark_weaver>Chaos`Eternal: out of curiosity, what were you planning to use a HERE-STRING for? <mark_weaver>admittedly, we don't yet have such a thing implemented, but I think that's a better solution to work toward. <Chaos`Eternal>my job is test performance of SQLs which written by my customers, from oracle, db2 etc <mark_weaver>composing SQL as strings has many problems and potential security holes. <mark_weaver>how bad would it be to put the SQL code in a separate file from your Guile source code? <Chaos`Eternal>and using separate file makes the script more complex to maintain <cky>I think it'd be fun to write a new reader entirely. :-P <cky>I want to write one just for the lulz. <mark_weaver>I agree that a HERE-STRING feature would be useful, but in the meantime, I'm not sure why it would be problematic to define a little procedure that reads a file with SQL snippets along with the name of the database to pass them to (possibly along with some parameters). seems like it would be pretty straightforward. <mark_weaver>the syntax could be as simple as: use 'read-line' to read one line at a time from a file. lines beginning with ==== are header lines that describe what procedure to call and the initial arguments. and then everything that follows until the next ==== line is the string that gets passed as the last argument. <nalaginrut>And IMO, users should never face SQL/SSQL in any time, there should be an ORM or FPRM(I'm designing it) <mark_weaver>alternatively, you could use 'read-hash-extend' to extend Guile's reader, and then use that custom syntax in your code.. but you'd have to install the extension before loading your code. <nalaginrut>SQL thing should be kept low-level, to avoid some security issue <mark_weaver>nalaginrut: nice! although this won't help Chaos`Eternal because he's been given by the SQL code (as a string) by someone else. <nalaginrut>;-) but you'll never use it directly, unless been a developer of it <mark_weaver>nalaginrut: but I agree wholeheartedly that SQL should be a low-level detail. user code should deal with higher-level data structures like SXML or SSQL. <nalaginrut>you should is CLASS or closure to handle a table or database things <nalaginrut>Chaos`Eternal: I'll write an ORM, it's in my TODO, but lispy guys may like a FPRM which is not anywhere but in my mind <nalaginrut>no release, since SSQL is the prerequisite for them all <nalaginrut>mark_weaver: but for ORM, I wonder how many guys willing to use GOOPS...lispers seems don't like OO, let alone Guile specific GOOPS... <mark_weaver>Chaos`Eternal: I'm cooking up a little code for you to add python-style here-strings to the guile reader <nalaginrut>besides, I found 'format' in Guile is very powerful <cky>Wow, that's the first time I've seen someone from 1.0.0.0/8. <mark_weaver>Chaos`Eternal: just load that module, and then your reader will support #"""here-string""" syntax <mark_weaver>any code you load or compile after loading that module will support that syntax <wigs>apparently that means I am should be located in asia–pacific region, which is accurate :-) <mark_weaver>note that everything between the two """ delimiters will be taken literally. that module doesn't support any escapes whatsoever. though it could be easily extended in that direction if desired. <nalaginrut>wigs: I wrote my style SSQL with macro, covers most of SQLs now, but for FPRM, I have no any clue... <wigs>nalaginrut: what is FPRM? <nalaginrut>wigs: well, a concept of replace OO to FP way in RM <mark_weaver>Chaos`Eternal: if you want escapes, they can be added by adding another clause to the 'match'. just remember that 'chars' will be the most recently read chars in reverse. <mark_weaver>if you have a particular escape that you want, I can add support for it to show you the idea. <mark_weaver>but in this SQL case, I'd guess that you want to avoid escapes so that you don't have to worry about the possibility of the SQL code containing such an escape. <mark_weaver>Chaos`Eternal: but again, for the SQL thing you probably want no escapes. <mark_weaver>I'm sure this code could be made more elegant, but I didn't spend much time trying to make it so. <nalaginrut>mark_weaver: is there any possible to keep src-code in the *.go, so that people can read the src in the REPL? <cky>nalaginrut: You probably don't want to really hold on to the source, but rather just the filename and line/col information. <wigs>(and last-modified time) <nalaginrut>cky: yes, it's an idea, but if just keep the filename and line/col, sometimes we just have *.go files without any *.scm <cky>wigs: Well, that's already done. <cky>wigs: .go files are subject to a staleness check when loaded. <nalaginrut>hmm...maybe it's not a problem, if there's no src-file, it doen't show the src, well, nice idea <mark_weaver>I guess the filename/line/col information is already stored in the .go file, or else the backtraces wouldn't be able to show that information. <mark_weaver>and with that information, you can extract the source code from the source file. <nalaginrut>a new question, I can confirm the begin of the function in src file, but how to confirm the end? <mark_weaver>I don't know off-hand how to do it. I'd have to look into it. wingo would probably know off the top of his head, since he wrote most of that stuff. <wigs>‘read’ will leave the port position just after the expression ends <nalaginrut>mark_weaver: seems a cool idea too, I'll try a prototype <nalaginrut>yes, read then pretty-print, it's amazing result! <wigs>nalaginrut: close enough, but will lose comments <mark_weaver>well, actually I would recommend showing the raw characters from the file.. and use 'read' only to find the end. <nalaginrut>maybe there's some hook for read to keep comments? <mark_weaver>no, but even if there was, there's plenty of other information that would get lost. <mark_weaver>pretty-print is not as good as a human at choosing a good format. <cky>wigs: I dare say comments are unimportant, since Guile uses docstrings not doc comments. <mark_weaver>also, if the code uses something like curly-infix, that will get lost. <cky>mark_weaver: Well, comments are useful, yes, but for a "print source of this function", surely it can't be that big of a deal. <cky>Who knows. Maybe write a custom reader that creates comment nodes (a la XML) when comments are encountered. <nalaginrut>well, I checked out R, seems it don't provide comments <cky>Of course, unlike XML, Scheme has three kinds of comments. <nalaginrut>and yes, I think docstring is enough for Scheme, especially enough for guile <mark_weaver>nalaginrut: anyway, I'd much rather have something that hooks into emacs and has it open the right source file and leave my cursor at the procedure. <mark_weaver>nalaginrut: but I know that you prefer to find solutions outside of emacs. <cky>And Guile has a fourth kind (#! !#). <nalaginrut>mark_weaver: well, emacs hack out of my idea, I'm not so familiar with emacs program <wigs>nalaginrut: I think you would have fun writing a super-repl for guile <wigs>ala. ipython or drracket <mark_weaver>Geiser already has all the needed infrastructure. It would be very helpful to extend it in this way. <nalaginrut>hah~I do really want a super-repl, but Guile's REPL is cool, I think it's no need to write a new one <nalaginrut>mark_weaver: yes, I agree with Geiser, but I'm not familiar with Emacs programming <nalaginrut>and most of time, I try my idea in REPL, but paint my art in Emacs <mark_weaver>I never learned elisp very much either. I'm waiting for guile-emacs to mature :) <nalaginrut>well, back to my question, do you guys think the src in REPL without comments is cool? <mark_weaver>I'd much prefer to see the contents of the original string in the source file. <wigs>and its not at all difficult to do <nalaginrut>(module-filename (current-module)) ==> #f hmm... <wigs>nalaginrut: look up how the backtrace does it <mark_weaver>I want to see the comments, and the programmer-chosen indentation, and, if curly-infix (or sweet expressions or custom read syntax) is used, I want to see what the programmer thought was the best presentation. <wigs>mark_weaver: right, otherwise its not really the _source_ but some pre-parsed, re-formatted interpretation of that <cky>If the starting column is non-zero, you'll have to left-fill the first line. ;-) <mark_weaver>I could figure it out, but it's more efficient to just ask wingo :) <cky>Otherwise, things won't line up, and we can't have that. ;-) <nalaginrut>no matter read way or get string from src-file way, both could be provided <wigs>cky: I would go the other way *nalaginrut reading backtrace... <wigs>de-fill the remaining lines _maybe_ <wigs>cky: mark_weaver: congrats on recent srfi-41 merge <mark_weaver>wigs: the problem with the other way is that there might actually be non-spaces in the columns to the left.. if there's an embedded string, or some fancy syntax (e.g. sweet expressions) <wigs>last minute changes are probably right, imo <mark_weaver>wigs: thanks. I've long wanted srfi-41. cky did most of the work of course :) <mark_weaver>nalaginrut: also, you'd probably want to keep all of the comments preceeding the actual procedure. <cky>mark_weaver: What if it's the first procedure and you're getting all the legalese boilerplate above? ;-) <mark_weaver>in any proper scheme module, there's a module declaration below the boilerplate. <mark_weaver>but admittedly sometimes there is a huge comment within a file that doesn't directly relate to the procedure below it. <nalaginrut>mark_weaver: keep all of the comments maybe little hard, how to parse it? <cky>I think getting the comments _above_ the procedure is tricky. But getting the comments inside the procedure is doable. <cky>After all, you're just getting the starting position, doing a read to ascertain the ending position, and grabbing everything in between. <mark_weaver>nalaginrut: the easy way would be to 'read' the file from the beginning until you found a datum whose source location information matches the procedure you're looking for (or below it). then start from the position of the file before you did that 'read'. <nalaginrut>ok, that's cool, but I'll find a way to implement read way prototype first <mark_weaver>'read' always stops immediately after the end of the thing you read. the whitespace and comments between two datums is read by the latter 'read'. <mark_weaver>note that there's a complication when the procedure in question was not defined at top-level. <nalaginrut>there's less docstring in system vm code, so I have to read the src <mark_weaver>so in general, you may have to look at the source location information of sublists within a top-level datum. <mark_weaver>a procedure might even be some 'lambda' within a larger expression, and in that case it may be more helpful to see the full context. (another reason why I'd rather it open it in emacs :) <nalaginrut>is the a wrong way? I need to get source, and there're source:file source:row <mark_weaver>nalaginrut: that's right. we can't record source location information for any symbol or immediate value. <mark_weaver>nalaginrut: we record source location information for all non-immediate datums however, including lists. <mark_weaver>(it would be nice if we recorded source location information of procedures defined in C code using our snarfing macros, but currently that's not implemented) <mark_weaver>ideally, geiser would be able to send us to the source code of any procedure, like emacs can do. <nalaginrut>but program-sources seems returned all the positions appeared the proc <nalaginrut>(program-sources read-line) returned many things <mark_weaver>nalaginrut: that's a list of mappings between the offset in the VM bytecode and the associated line/col in the file <mark_weaver>e.g. (source:line (car (program-sources read-line))) <mark_weaver>I confess that I'm making some guesses here. wingo is the person to ask. <mark_weaver>Chaos`Eternal: I consider that code too trivial to care what happens to it, but I hope you will use either GPLv3 or LGPLv3 for your code. <mark_weaver>Chaos`Eternal: I'm afraid that code has a bug. it'll turn \\\\n into \\n and then into newline. <mark_weaver>the simple matching logic doesn't gracefully handle the case where an escape can produce one of the components of an escape sequence. <ijp>is it just me or has scsh been a coder trap? :P <ijp>seems someone gets sucked into it every few years, and we don't hear from them again <ijp>(also, good morning) <mark_weaver>more generally, it seems to me that the value of a special """ syntax to avoid escaping " is undermined somewhat by having to escape \\ <mark_weaver>granted, it seems to be popular in the python world. <cky>Maybe we want Perl-style here-docs. :-P <mark_weaver>but if you have to worry about escaping \\, then why not handle escaping " while you're at it? <cky><<foo = interpolated (\\ and $ are special); <'foo' = non-interpolated (no characters are special); <-foo = strip leading spaces <cky>Oops, <<'foo' and <<-foo of course. <mark_weaver>I can hardly imagine a case where they would be useful. <mark_weaver>on the other hand, it's easy to imagine cases where they will munge your string in bad ways. <ijp>nalaginrut: I think wingo suggested keeping gzipped source in the file when we move to elf <mark_weaver>cky: I used to use perl quite a bit, but every time I tried to go beyond a low level of complexity, I found the results too gross to bear. I'm glad to have left perl behind. <nalaginrut>ijp: well, seems no easy to parse from gzipped src, my idea is, if there's relative .scm for the .go, REPL could show it, if no, no <ijp>I don't see how it is fundamentally more difficult <nalaginrut>and for an user who just need *.go, he may don't want to read the src <ijp>yes, you need to extract if first, but other than that, it is the same process <cky>mark_weaver: Hehehehe (re too gross to bear). <ijp>and it isn't like users read .go files in the first place <cky>nalaginrut: I presume these blobs would just live in a .guile_src section or something. <cky>since with ELF you can have sections for everything. :-) <Chaos`Eternal>mark_weaver, i'll keep them unless i make sure they are useless. <cky>You can have one section per function, if you so wanted. <nalaginrut>well, I got an idea, if we have gzipped src, we may extract them to one specified path, that avoid to choose the path in %load-path <mark_weaver>I like Racket's here strings. I think maybe I'll propose adding this to Guile's reader. <nalaginrut>but since the gzipped src haven't provided now... <nalaginrut>hey, why not just provide src string in .guile_src section? Why use gzipped wrapped way? <mark_weaver>Chaos`Eternal: better yet, how about I write a new module that implements Racket's here strings.. because I will propose adding those to Guile's core reader, and then you won't have to carry it in your own code anymore. <mark_weaver>it might even be part of Guile 2.0.8, due to be released next week. <nalaginrut>I enjoyed 2.0.8- so long a time, that I just consider the superb 2.1.x ... <ijp>mark_weaver: I think you are pushing it a bit here :) <ijp>mark_weaver: I'm talking about the timing, not the design <mark_weaver>I can't promise anything. Maybe it will be blocked. ijp's response makes me wonder. <mark_weaver>I'm just one contributor, but IMO it would be a good addition. <mark_weaver>ijp: you think that this is a decision that should be mulled over for a few months? <ijp>mark_weaver: if anyone can get this done in a week, it's probably you. <mark_weaver>the only question is whether it will be nak'd for some reason. <ijp>but I'm concerned about touching the reader in general <ijp>fortunately, I'll be away this weekend, and so unable to comment :) <nalaginrut>if I want to move the pointer of port to xxx line <nalaginrut>well, there's ugly way: (define (seek-lines n) (for-each read-line (iota n))) <ijp>nalaginrut: that won't work as expected <ijp>since you are passing an integer for the port to read-line <nalaginrut>just read way done, I don't think I should be hurry for 2.0.8 <ijp>adding new repl commands isn't documented (I think), but it isn't hard to do <nalaginrut>yes, I've ever hacked the REPL command for printing backtrace in level number rather than "|||..." <nalaginrut>the problem is I don't have an idea to parse a procedure src with all its comments <nalaginrut>comments inline is easy, but our comments seems no format *ijp makes a note to document them when he gets back from emacsconf <wigs>nalaginrut: dont parse it; if you get this far, you have used ‘read’ to find the end so just print _exactly_ from start to end <wigs>forget the output from ‘read’ <cky>mark_weaver: Is there a way to make the readtable look ahead to find <<? <cky>mark_weaver: so that you could use #<foobar> for something else? <wigs>nalaginrut: it is only a little bit extra to get the result everyone likes, with comments etc. <mark_weaver>cky: not with read-hash-extend. but I can make that work in guile's core reader, and will do so. <nalaginrut>well, a new problem, how can I confirm the path from %load-path? iterate them all? <ijp>I know we have other things whose print representation begins with #< <ijp>but are any of them readable? <cky>ijp: Currently, no. But with proper lookahead, it's theoretically possible. <mark_weaver>ijp: no, I can see from read.c that #< isn't handled except for read-hash-extend. <ijp>and (string eol) won't work if the eol is \\r\\n <cky>mark_weaver: Also, delimiter, not delimeter. The root word being "limit". :-) <mark_weaver>ijp: I know. I thought of that too. Unfortunately 'read-line' returns only a character for the EOL. <ijp>mark_weaver: that's odd <ijp>sometimes I want to go back in time and shake the people who were working on guile very roughly <cky>ijp: You mean, not all the world's a GNU? ;-) <ijp>I felt that way the other day, when I learned just how old the q module is <cky>ijp: You should so port Racket's data/queue to Guile, then! <cky>ijp: I almost, almost did, when I was implementing srfi-41. <mark_weaver>ijp: yes, I often feel that way myself. the (ice-9 popen) module comes to mind, but it's far from the only example. <ijp>well, now that we have a second streams module, the argument for a second queue module is a little better <cky>ijp: We might get a second promise module, too, depending on how things go. :-P <cky>ijp: mark_weaver has roped me into writing a SRFI (which I might polish over this weekend). <ijp>for those of you who didn't rush out and read ice-9/q.scm ";;; "queue.scm" Queues/Stacks for Scheme ;;; Written by Andrew Wilcox (awilcox@astro.psu.edu) on April 1, _1992_." <mark_weaver>or maybe we should just fix the core promises to be good. <cky>mark_weaver: That, too. But that would change the size of the promise data structure. <cky>mark_weaver: And I thought we were against changing the size of anything. <ijp>though I note it was an April 1st module, so... <ijp>I thought promises where Scheme anyway <mark_weaver>well, I mean to make the core promises more like srfi-45 (except with support for multiple values) <mark_weaver>i.e. add lazy and eager to the core, and make them have good iterative behavior. <cky>Lemme peek at promise.c and see what it involves. <mark_weaver>cky: it would still be good for it to be a SRFI though. <mark_weaver>ijp: regarding queues: yes, please, let's have a sane queue module. <mark_weaver>ijp: I nominate you for that task, if you're willing :) <cky>I wonder if I still have my copy of the ported Racket data/queue. <cky>I might have nuked it when I decided it was unnecessary. <mark_weaver>nalaginrut: yes, you should make sure to close ports explicitly <mark_weaver>file descriptors are scarce; we cannot afford to wait for them to be GCed. <mark_weaver>also, leaving files open has bad effects like preventing unmounts and deletions. <sneek>Welcome back Chaos`Eternal, you have 1 message. <nalaginrut>mark_weaver: don't compete with me~ I've already done a rough <nalaginrut>where's the pastbin site? I'll show you a prototype to play <Chaos`Eternal>but i'd say, i prefer #""" rather than racket's way, it's too perlish <mark_weaver>nalaginrut: codepad.org is the one I've been using. not sure whether it's the best choice, but works well for me. <cky>nalaginrut: I use Gist. :-) <cky>(But I also have a CodePad account too.) <cky>mark_weaver: I should take a stab at implementing SRFI 45 promises inside promises.c. <mark_weaver>cky: codepad account? what does that get you? I don't have an account, and yet I can paste to it anyway. <cky>mark_weaver: You can easily find your previous pastes, for example. <mark_weaver>civodul: do you have a suggested here-string syntax? <nalaginrut>cky: I see, both of us like gist, but it seems most of guys here don't use it <mark_weaver>Chaos`Eternal: the thing I don't like about """ style is that if you want to quote something that has """ in it, you're out of luck. <mark_weaver>I like a method that allows you to quote *anything* without any kind of escapes. <nalaginrut>this rough implementation didn't handle the module isn't any file, say, defined in the REPL <cky>mark_weaver: Does anybody use Guile's make-promise? Right now it's documented as the procedural form of delay, but to implement SRFI 45, it needs to be the procedural form of lazy, instead. <mark_weaver>nalaginrut: 'skip-lines' could be written more elegantly though. <ijp>IIRC the original paper on racket's scribble syntax suggests "how easy is it to use this language to write about itself" as a metric of sorts for escape sequences <cky>mark_weaver: Granted, it's easy to make make-promise work as currently, and just wrap the given procedure with an eager. <ijp>that's an odd argument <cky>i.e., (make-promise foo) => (make-new-promise (compose eager foo)) <cky>Not quite sure how to compose at the C code level, but never say never. <mark_weaver>cky: eager needs to be syntax, in order to handle multiple values nicely. <mark_weaver>cky: make-promise seems more fundamental to me anyway. I suspect eager should be built on top of something like Guile's core make-promise, not the other way around. <cky>Correct, but you can still have a (private) C-level eager-like thing to handle current uses of make-promise. <cky>Well, see, make-promise currently contains a thunk that returns the delayed result. This is not compatible with SRFI 45. <cky>In SRFI 45, the thunk should return a promise. <cky>(Either an eager or lazy one.) <nalaginrut>I found even the proc defined in the REPL has a line/column, is there any way to get the src from REPL? <mark_weaver>Chaos`Eternal: just use """ after the #<< and then it'll look kind of like what you want :) <mark_weaver>Chaos`Eternal: that flexibility that you don't like is precisely what let's it quote *any* text. <mark_weaver>Chaos`Eternal: try quoting a Python script with the """ syntax, for example. You can't do it. <cky>mark_weaver: I can repurpose SCM_PROMISE_COMPUTED_P to mean eager (if true) or lazy (if false), and SCM_PROMISE_DATA to be either the eager value or the lazy thunk. That way it won't expand the data structure size of the promise. <cky>mark_weaver: But the thunk still needs to return a promise, not the value. <mark_weaver>cky: I haven't looked at the code, and I don't have time to right now, so I can't help. <wigs>nalaginrut: noone here knows about repl internals really, so you have to read the source <cky>mark_weaver: No worries. I'll play with it some over the weekend, if I have time. <mark_weaver>nalaginrut: I think you're out of luck for procedures typed at the REPL. <mark_weaver>nalaginrut: the REPL uses 'read', and loses the original string. <cky>mark_weaver: If we're lucky, it might even get done around the same time as your in-core here-strings. :-) <mark_weaver>well, civodul seems opposed, so it probably won't happen anyway. <cky>I don't think he's opposed per se, just that he finds the syntax distasteful while acknowledging a need for such a thing. <cky>Chaos`Eternal: You can't argue with mark_weaver, he usually wins. ;-) <wigs>so assume the winning position more often d: <mark_weaver>cky: regarding promises, we can't change the ABI in 2.0. that means that any C code that used the public macros in promises.h must continue to work with a new version of guile 2.0.x <mark_weaver>cky: so maybe it won't be possible. if it is possible at all, it will have to be done cleverly. <cky>mark_weaver: That could make things very tricky, since it's hard to audit for such uses in modules. <cky>Chaos`Eternal: What wigs said. I mean, I'm pretty sure that mark_weaver is Triple Nine Society material. ;-) <mark_weaver>cky: we have to assume the worst. we must assume that there's code out there that uses all of these macros. <nalaginrut>I found even the proc defined in the REPL has a line/column, is there any way to get the src from REPL? <nalaginrut>what's the meaning of source:line to a REPL-defined thing? <wigs>nalaginrut: that line/column is _probably_ just related to stdin stream, which is not kept around <nalaginrut>wigs: so there's no way to get the src of a REPL defined proc? <cky>mark_weaver: Like Mensa, but hardcore. <ijp>sounds a little snobbish <cky>mark_weaver: I mean it, but thanks. :-) <wigs>nalaginrut: I would not think so, not at present. <nalaginrut>so should I ignore that? just provide the defined in file procs <mark_weaver>I hang around MIT, where there are lots of people much quicker than I am. <cky>ijp: There are snobs, but not everyone in Mensa are snobs. (I can't speak about TNS since I'm not a member there.) <nalaginrut>mark_weaver: hmm...I dream to go to MIT, but it's far away from me now <cky>ijp: For me, Mensa is just another social circle, like #guile. <mark_weaver>nalaginrut: it can't be helped. at the REPL, not only are the original characters lost, but I'm pretty sure the sexpr is lost too. <ijp>I came to the conclusion a while back that no good would come of me learning my actual IQ <cky>mark_weaver: I can believe it, and probably many of those people would say the same about you. <mark_weaver>there are many different kinds of intelligence. I'm strong in many areas, but weak in many others. <nalaginrut>mark_weaver: OK, so I could drop REPL defined things for print-src <cky>mark_weaver: Actually, that's why Mensa allows you to qualify from many different tests (and you only need to pass one). These tests test different kinds of intelligences. <mark_weaver>nalaginrut: I think the source typed at the repl is lost. <cky>mark_weaver: The test I did was totally visual and language-free. I guess my strength is in visual/spatial stuff. :-P <cky>mark_weaver: There is a language-based test, and there's an analogies-based one (though, I'm not sure if Mensa accepts that one), etc. <wigs>nalaginrut: perhaps, though to me it just suggests there is no such information <mark_weaver>to focus too much on the question of "how intelligent am I?" or "how intelligent are you" is not a good thing. let's just work together to make the world better. <ijp>that was my thinking <wigs>nalaginrut: anyway, the specifics of the not-available response is not important, people will get the idea <cky>nalaginrut: I haven't done a real proper IQ test, so I can't say whether I qualify for TNS. I have done the Mensa test (which is an IQ test, but they won't tell you your actual score). <mark_weaver>In my experience, it's unhealthy to have too weak an ego, but it's also unhealthy to have too strong an ego. <cky>mark_weaver: Indeed. <mark_weaver>I've suffered from both of those problems in the past. <cky>mark_weaver: I'm not a fan of the snobs in Mensa either. I'm just there to have fun, nothing more. <cky>nalaginrut: I don't understand your question. <civodul>mark_weaver: actually i think it's more the term "here document" that scares me <civodul>but the general idea of having a "text-preferred" syntax seems good <nalaginrut>cky: "that was your thinking", I think it's about " let's just work together to make the world better." <mark_weaver>civodul: I don't care that much about the details. I'd just like to have something that lets us include an arbitrary string without escapes. <mark_weaver>civodul: if you have a suggested syntax, I'm open to ideas <cky>nalaginrut: "that was my thinking" was ijp's comment. <civodul>mark_weaver: let's open the discussion for 2.0.9 or so <nalaginrut>civodul: can we add epoll/kqueue in a (ice-9 linux) and (ice-9 bsd) <civodul>nalaginrut: there's (ice-9 poll) already, but hmm, that's just poll(2) right? <cky>I thought wingo did some stuff with epoll. <cky>But, not sure where that went. <wigs>cky: web-ethreads or something <nalaginrut>cky: wingo left ethread/nio things for a while... <civodul>if it's possible to have an an thing abstraction over both epoll and kqeue, the better <cky>Sure, I'll see how Java does it and port the abstraction here. ;-) <wigs>right, and that probably requires a bit of work to get right <nalaginrut>civodul: well, I did wrote such thing in Ragnarok, but I don't know if it's proper for Guile core <cky>(in the same way I want to port Java's ConcurrentHashMap to Guile once Guile has atomics.) ***adu_ is now known as adu
<janneke>,break (@ (schikkers music-layout) move-cursor-to-y-range) <janneke>ERROR: In procedure #<procedure 44be820 ()>: Unbound variable: ((schikkers music-layout) move-cursor-to-y-range #t) *janneke tears hair again *civodul is a happy Geiser user <civodul>janneke: the error does not relate to Geiser <janneke>civodul: ah, good. shows what a newbie i am! <civodul>is it the right module? the right name? is it exported? <janneke>so my question is: how to set a breakpoint to a method in a module? *civodul notices that this is undocumented <janneke>what if there was a syntax error and i did a reload? <janneke>,import (schikkers music-layout) again <janneke>...strangely, it gave no error when there was a syntax error. hmm <wigs>janneke: to actually reload you must use ‘(reload-module (resolve-module '(schikkers music-layout)))’ <janneke>Trap 0: Breakpoint at #<<generic> move-cursor-to-y-range (1)>. <janneke>hmm, now i get no source in the other window... <janneke>isn't also: ,up supposed to do that? <civodul>,up is like "up" in GDB: it shows the stack frame above <ijp>soegaard originally did some of that for Ikarus, I think <janneke>civodul: yes... and in GUD you get the matching source in the other window *janneke thought geiser is a sort of GUD without the "GU" <ijp>it's more like th U without the G or D <ijp>since it doesn't do anything special for the debugger (I think), but it works the same for Racket <civodul>i actually rarely use the debugger in Scheme <ijp>I use the debugger, but not as much as I could or should <janneke>ijp: i'm sure i saw matching source in another emacs window? *ijp attempts to summon jao <janneke>is anyone hooking geiser or guile debugger up with gud? <civodul>ah ah! it's a secret debugging tool that only wizards know! <ijp>taylanub: basically (define (pk . v) (write v) (newline) (apply values v)) <ijp>it does handle multiple return values, right? <mark_weaver>taylanub: in prints all of its arguments to the console and then returns the last one. very useful for wrapping around expressions in your code, usually prefixed by some symbols and/or relevant variables, and it helps you see what's going on as your code runs. <civodul>ijp: not quite, it returns (last args) <ijp>I would have expected (car args) <civodul>it's convenient this way, because you can do (pk 'foo bar) <mark_weaver>taylanub: if you use 'paredit', it's super easy to wrap them around bits of code and/or remove them. <mark_weaver>paredit was a bit painful to learn, but I'm *so* glad I took the time. it has revolutionized my scheme editing. <taylanub>I learned paredit before doing much Lisp hacking so it wasn't very hard. I think every Lisp introduction should mention it, and how s-expressions aren't necessarily worse than other syntax. (Many people find them superior, AFAIK. I do, certainly.) <mark_weaver>I think you'll get no disagreement in this channel :) <mark_weaver>I'm probably the outlier in thinking that curly-infix might be worthwhile to use in a few places here and there. <ijp>a while back, I had an idea to do a (language linear) for linear programs, so you could drop them right into guile programs <taylanub>I also think SRFI-105 might be useful, but not anything beyond it. Curly braces still are a form of parentheses so they should go well with paredit. <ijp>but I have so little need for it, it's hard to convince myself to write it <mark_weaver>taylanub: I agree. speaking of which, I should probably make a version of paredit that deals with curly-infix and a few other aspects of guile syntax that regularly trip me up (like backslash at the end of the line) <mark_weaver>civodul: are you sure that @var is the right thing for scheme variable names? the texinfo docs say "Use the `@var' command to indicate metasyntactic variables. A "metasyntactic variable" is something that stands for another piece of text. For example, you should use a metasyntactic variable in the documentation of a function to describe the arguments that are passed to that function. <mark_weaver>civodul: notably, it goes on to say: "Do not use `@var' for the names of particular variables in programming languages. These are specific names from a program, so `@code' is correct for them (*note code::)." <mark_weaver>"For example, the Emacs Lisp variable `texinfo-tex-command' is not a metasyntactic variable; it is properly formatted using `@code'." <mark_weaver>therefore, I think 4a0821a8d5cfff50fef8c119a0d76355b6126009 should be reverted. *mark_weaver looks into building guile against GMP 4.2 <civodul>mark_weaver: ooh, interesting; i had always thought otherwise <civodul>so yes, you can revert the @var part (but keep the @defvr) <mark_weaver>yeah, it's a fine point. I didn't realize it until recently. <civodul>it's great to see that the details have been thought out <mark_weaver>civodul: well, stable-2.0 seems to build against GMP-4.2 and even pass numbers.test. I'm trying again with your GMP 5 fix reverted, just to make sure my test is good. <mark_weaver>indeed, my test fails without the GMP <5 fix, so my test seems to be good. So we're all good for GMP 4.2. <mark_weaver>civodul: any thoughts on what syntax to use for augmenting %load-compiled-path from the command line? <mark_weaver>civodul: do you think it deserves a single-character option? <civodul>esp. if we want it to be usable from shebangs (which would be nice) <mark_weaver>I confess to thinking that our shebang support is fundamentally broken, and that we should think up a new mechanism. <mark_weaver>I don't care that much. I'm not good at coming up with names. <mark_weaver>okay, I'll cook up a patch and post it for comments. ***sneek_ is now known as sneek
<ijp>the intent of a promise is to delay a computation, and it may never be computed <ijp>futures are for fine grained parallelism, and the intent is that they will be computed <ijp>the api is very similar though <ijp>see you guys sunday/monday <mark_weaver>davexunit: promises are single-threaded. they are not computed until the first time they are forced, and they are forced in the same thread. <mark_weaver>davexunit: so 'force' actually does the computation before returning. <mark_weaver>with futures, the computation typically starts immediately is typically done in another thread. <mark_weaver>I confess I'm a bit fuzzy on the details, because I usually avoid threads. <davexunit>mark_weaver: thanks! I also avoid threads to avoid headaches. ***adu_ is now known as adu
<mark_weaver>*nod* but only if you avoid all mutation, including things like promises or streams. <mark_weaver>oops, that was me, accidentally typing from my logger :) *sneek waves at waxysubs` <mark_weaver>my logger is just Emacs/ERC running within a screen :) <mark_weaver>because I couldn't be bothered to research a better solution. <mark_weaver>one of these days, I'd like to set up a bot with a Guile 2 REPL for this channel. <dsmith-work>Off Topic: Anyone here ever mess with the Linux PPS system? <dsmith-work>mark_weaver: Yes, I looked into adding that to sneek at one point, but it was just too scary. <mark_weaver>dsmith-work: I was thinking of running all the REPLs within a VM running civodul's boot-to-guile :) <mark_weaver>one process per REPL, using rlimit to control resource usage. <mark_weaver>not ideal, for sure, but until we have a decent sandbox :) <sneek>Sneeky bot running on Guile version 2.0.5.90-c0580 using bobot++ 2.3.0-darcs <dsmith-work>I remember having to add swap to build stuff at one point. <mark_weaver>the first patches I wrote for guile were written on a Psion 5MX with 36 MHz ARM processor and 24 megs of RAM. <mark_weaver>(the main feature of that computer being its super low power consumption, so it could be used for long periods while camped out in the woods) <mark_weaver>I could use it for an entire week on 2 AA batteries. <mark_weaver>also, it's monochrome display that can be read easily in bright sunlight. <dsmith-work>I also have a qube 3 (which is intel), but I havn't taked the time to put a modern Debian on it. <mark_weaver>hehe, I'm sometimes shocked by the number of typos I produce on irc. *dsmith-work enabels flyspell-mode <mark_weaver>I suppose at this point you could do better with a $35 Raspberry PI :) <mark_weaver>actually, I have one that's currently only being used to access the serial port on my server. <dsmith-work>Nice thing is, it's only about 35Watts. I even took the fan out, so it's quiet. <dsmith-work>I ran netbsd on it for a while, until Debian started working nicely. <mark_weaver>maybe that's the solution. just run the REPL's on a raspberry pi. <mark_weaver>I used to run netbsd. for many years, starting with the very first released derived from 386BSD (which I ran before netbsd came out) <dsmith-work>The only really painful thing is building Guile (and dependencies) takes a whole weekend. <mark_weaver>or at least I was not aware of any association between 386BSD and Dr Dobbs. <mark_weaver>dsmith-work: why don't you just run Debian wheezy? it's quite stable. <mark_weaver>on wheezy, the dependencies are all built already. (it's a good idea to build a newer Boehm GC, but that's a fast build) <dsmith-work>Not sure how good the mipsel support is. I'll check it out. <mark_weaver>dsmith-work: mipsel support is reasonably good, although it uses the O32 ABI. <dsmith-work>The qube has no keyboard or mouse. Just a little character LCD display and 4 buttons. <mark_weaver>my server, an old Sun Netra T1, also has no console or keyboard. I have to access it via the serial port only. <dsmith-work>When obsd booted, the image size was so large that it ate into the display memory. <dsmith-work>And of course when something updated the display, it corrupted the kernel image, crashing it. <dsmith-work>IT was cool. You could actually watch the kernel on the bitmapped display. For a while. <dsmith-work>There was a local dial up "public access unix" that I talked to on my C64. That machine was a TRS80 Model 16. <mark_weaver>nice. I had a bunch of friends with C64s and Vic 20s, but I had an Apple ][ plus. <dsmith-work>First thing I did was make a custom termcap entry to get my C64 cursor keys to work. <mark_weaver>so you got started on unix a lot earlier than I did. I didn't use unix until 1988 when I went to university. <dsmith-work>It wasn't until early '90's before I touched a real unix machine through. <mark_weaver>when did you start running unix on your own machines? <dsmith-work>The first thing I did on that machine was hack the soundcard driver to enable the cdrom so I could install from cd instead of floppies. <dsmith-work>I remember I ran a grep on the files on the cdrom looking for a package, and it took a long time. <dsmith-work>And then I ran another grep, and it was like instant. <sneek>Linux blueboy 2.6.32-5-r5k-cobalt #1 Wed Jun 15 00:53:04 UTC 2011 mips GNU/Linux <sneek> 18:37:38 up 45 days, 21:44, 0 users, load average: 0.57, 0.49, 0.46