<Schaapjes>davexunit, I think it's interesting how much the stereotype holds. <Schaapjes>When people say "good evening" not mindful of timezones 90% chance they're connecting to a US server. <Schaapjes>mark_weaver, is there a way to easily inspect the bindings that a module exports? <Schaapjes>Get a simple list of the symbols it exports? <ArneBab>Schaapjes: if you get an answer, could you highlight me? <ArneBab>davexunit: I generally say moin whatever the time of the day ☺ <ArneBab>mark_weaver: besides: I’m sorry that I did not answer to the docstring email yet. My local email setup mostly broke down, because kmail created thousands of empty messages per day and that exhausted the inodes on my small server… <Schaapjes>ArneBab, maybe you know if guile has a better repl than the standard one introduced by typing guile though <Schaapjes>As in, one that has the capacity to do cursor movement and tab autocomplete <mark_weaver>Schaapjes, ArneBab: e.g. (module-map (lambda (sym var) sym) (resolve-interface '(ice-9 vlist))) <mark_weaver>ArneBab: no worries; I didn't feel that a response was needed <mark_weaver>Schaapjes: out of curiosity, how do you plan to use the list of exports from a module? <Schaapjes>mark_weaver, I plan to display them all on a line. <Schaapjes>But module-map and resolve-interface are clearly the functions I am after it seems <Schaapjes>mark_weaver, it seems geiser requires emacs to work? <mark_weaver>there's a readline module that you can load to give you basic cursor movement outside of emacs, but fancy features like autocomplete are implemented as emacs modes. <mark_weaver>vim doesn't have very good support for lisp style languages. <Schaapjes>Well, I don't use vim either, it'smore that I'd like to just run it into a terminal rather than a text editor. <davexunit>so, python has a nice little way to start a simple HTTP server via 'python -m SimpleHTTPServer'. I wonder how difficult it would be to make the same thing happen in guile. <mark_weaver>wingolog.org is built on tekuti, which is written in guile and based on the (web ...) modules <ArneBab>davexunit: I think python uses the if __name__ == "__main__" trick for that. It would likely be needed to check in the script whether it is called as script (equal? (current-filename) ("module-filename")) <davexunit>mark_weaver: yeah, I just haven't used them yet. <davexunit>ArneBab: I'm not so concerned with that aspect of it. I just want to write the same simple server in guile. <mark_weaver>davexunit: I like sxml as a representation of XML as S-expressions. <davexunit>I'm currently working on porting my blog from python + pelican to one using org-mode + org-publish <mark_weaver>I don't know the details of what SimpleHTTPServer does, though. <davexunit>and it's useful to have a simple http server running locally for previewing things before I rsync the content to my server. <mark_weaver>davexunit: the web modules could be used to build such a thing, but they don't come with anything ready-made for serving up static files from the filesystem. they are mostly meant for dynamically generated pages. <davexunit>mark_weaver: yeah, I'll add that to my ever-expanding todo list. <davexunit>unusually warm today. time to ride my bike somewhere and get lunch. <tupi>mark_weaver: about these extra decimals we were talking about, ifound out the 'culprit' :) is <gtk-spin-button> <tupi>do you have a guile-gnome-2 around ? <mark_weaver>not at the moment. My thinkpad display died a while ago. <mark_weaver>I'm back to my home-built YeeLoong, which is now being transitioned over to GNU Guix. <mark_weaver>so, does <gtk-spin-button> return a floating-point value? *mark_weaver looks at the docs for it. <mark_weaver>I guess the thing to do is to round the value it returned to the nearest 1/10 of a second. <mark_weaver>something like (define (round-to-tenth x) (/ (round (* 10 x)) 10)) maybe <mark_weaver>e.g. compare (iota 20 0 0.1) to (map round-to-tenth (iota 20 0 0.1)) <mark_weaver>side note: this example shows that (* 1/10 x) is not the same as (/ x 10) <mark_weaver>this doesn't work properly: (define (round-to-tenth x) (* 1/10 (round (* 10 x)))) <mark_weaver>(when x is inexact, (* 1/10 x) is evaluated as (* 0.1 x), where that 0.1 is not represented exactly, and that slight error is multiplied by x) <mark_weaver>in theory, we could improve these cases (operations with mixed exact+inexact arguments) by converting the inexacts to exact, doing the operation exactly, and then converting the result to inexact, but that would slow things down a lot. <ArneBab>mark_weaver: I enjoy writing the articles ☺ <ArneBab>mark_weaver: a home-built YeeLoong with GNU Guix sounds like a geek-dream :) <mark_weaver>"dream" might be a slight exaggeration, but it's a nice little laptop. a bit slower than I'd prefer, but otherwise excellent. <tupi>mark_weaver: sorry, had to leave the kbd, reading now ... <tupi>mark_weaver: i have the folating point rounding code already [we've talked about that in the passed]. my question is is it not a gtk bug? <tupi>too bad you don't have a guile-gnome-2 I wrote an example which shows the problem <mark_weaver>tupi: no, it's not a bug. it's unavoidable if you compute the value by multiplying an integer times an inexact "step". <mark_weaver>if the step cannot be exactly represented (as is the case for 1/10 in binary), then there will be a slight error that gets multiplied. <tupi>ok. i'll round all spin values then [and write a patch for existing kise db, about a million i think :) :)] <mark_weaver>beware that 0.1 (as an IEEE 64-bit double) is slightly larger than 1/10, so your spinner will skip some values. <tupi>by the way there is a bug in either guile-gnome-2 or gtk2 itself, in that in a list-store, the rendereing of a spin button value is wrong: <tupi>(make <gtk-spin-button> ... #:climb-rate .1 #:digits 1) where #:digits is the number of decimals that should be displayed, but as you can see on screenshots of kise's web page, it displays 6 decimals no mater what... <mark_weaver>I have to go afk for a while. sorry, we'll have to continue this later. good luck! <davexunit>wingo: that article is really cool. glad to have more reading material about Scheme applied to game programming. <davexunit>gambit, chicken, and racket get all the attention. <wingo>for high-perf operations on floating-point values guile hasn't had a great story <wingo>which is totally a thing for games -- at least iiuc *wingo actually quite ignorant <wingo>also compile-to-c is necessary for targetting ios -- hence chicken or gambit <davexunit>I don't care about ios, but guile on android would be neat :) <davexunit>this is exactly the type of thing I'm going for. <wingo>you should port compost to arm :) <wingo>the assembler would be much easier than the x64 one, ugh <muep>my impression is that also licensing of gambit is very suitable for targeting ios <mark_weaver>tupi: I'm back now, but I am clueless about the bug you mentioned, and am not in a good position to investigate now (no guile-gnome, nor even gnome, on my system) <muep>at least having a copy of guile in the application would be pretty impossible because apple does not want to distribute under LGPL <wingo>mark_weaver: maybe it's not. at one point they wanted your program sources to be objective-c, of which c is a subset <tupi>mark_weaver: yes, not having guile-gnome-2 makes it difficult to help with pure gui 'problems' <muep>wingo: afaik they do not mandate that anymore <wingo>as long as you don't download code from the network maybe they are fine <muep>native code from some non-objective-c compiler should be just fine <wingo>they do prevent you from generating new native code at runtime though <wingo>muep: really, i hadn't heard that <wingo>anyway, freedom-denying systems &c &c &c <wingo>ios is part of a bleak possible future -- still, shiny in the present day ;) <mark_weaver>yeah, ios is at the forefront of trying to extinguish freedom for computer users. <muep>of the big mobile platforms, pretty much just android allows applications under the GPL <muep>not sure if though the google play store, but at least it allows other application distribution mechanisms <mark_weaver>what is the set of "big mobile platforms" included in your statement? <muep>android, ios, and windows <muep>of course it is a bit unclear, and someone may entirely disagree anyway <tupi>mark_weaver, wingo is there a way, 'just' reading guile-gnome-2 source code, to see/confirm that the #:digits option is 'passed' to the gtk widget [sorry if i'm not clear here, trying though...] <davexunit>despite the demos being on iOS, the functionality that jlongster demos here is the same type of functionality that I need to demo with guile-2d <davexunit>in fact, it should be even nicer because you can do it all from emacs. <tupi>I'm asking because i dobt it is a gtk bug, it would have been detected and solved ages ago, i think <davexunit>one thing I haven't figured out how to handle nicely yet is when code evaluated at the REPL throws an error later in the game loop. ideally, I'd like the game to pause in a way and allow the programmer to fix the issue from the same REPL that they've been using. <mark_weaver>tupi: you said that #:digits is not honored when the spin button is in a list-store. does it ever work? <davexunit>in jlongster's demo, an exception creates a new window with a new gambit repl. <mark_weaver>i.e. have you tried creating a spin button in some other context, and see if you can get #:digits to work anywhere? <tupi>mark_weaver: not sure i understand the question but: it works but does not honor the option of 1 digit only <wingo>gtk-list-store is a treeview thing, no? <tupi>mark_weaver: in a list-store it never honors this option <wingo>i thought that you couldn't put widgets in a treeview, only cellrenderers <tupi>gtk-list-store is a treeview *mark_weaver is mostly ignorant of gtk/gnome APIs <wingo>tupi: do you have a small test case? <davexunit>ArneBab: I must say that wisp code looks pretty good. <davexunit>I still love my parens, but I see the appeal of wsip <wingo>humm, i would think that would work fine <wingo>tupi: not sure what the deal is, that looks fine to me <tupi>yes i thought so to, it's like the option is not reaching the C widget <tupi>i wish i had a C code example <wingo>have you ever seen similar things with other cell renderers? <wingo>do you pass properties to other cellrenderers when you construct them? <wingo>wait there are two spin things there <wingo>a widget in the window and the cell renderer <wingo>this is not a minimal test case ;) <wingo>which one is doing the thing that you don't expect it to do? <tupi>wingo: the one in the list-store should render, the one in the win is for the user setting the vaçlue ... <tupi>the 1 in the liustore is not honoring its option <wingo>you mean the one in the treeview <wingo>it's a cell renderer, which belongs to a view not a store <wingo>dunno, the program looks right to me <tupi>list-store is the model: (model (gtk-list-store-new column-types)) ... <tupi>the column type is <gfloat> ... i reallyu don't know how to debug that <tupi>it should honor, unless the option does get to the 'real widget' <tupi>the <gtk-spin-button> does honor [if you change line 96 to #:digits 2 ...] the <gtk-cell-renderer-spin> does not <wingo>sounds like a gtk bug to me tbh, dunno tho <tupi>ok, i will try to produce a C code sample [how man i am already thick just writing C :)] and talk to 'them' <tupi>or maybe i can send them the scheme code really <mark_weaver>tupi: if you just send them the scheme code, I suspect your bug will be ignored. <wingo>well since it's a gtk2 bug they are not likely to look at it :P <tupi>i will render it my self actually <wingo>at least if you can reproduce it in c that is useful <tupi>it's not worth the effort i think *davexunit is experiencing a weird segfault related to weak key hash tables <tupi>wingo, mark_weaver, I'd like to see guile-gnome-3 coming through, it really becomes important, I think [not just for me] <mark_weaver>I know. I agree that it's important, and I'd like to see it done. <mark_weaver>but I have no idea how long it would take me to do it, really no clue. <mark_weaver>like I said, I'm mostly ignorant of gtk/gnome APIs, apart from a few basic concepts. <wingo>i'd like to do it but i have limited time <wingo>and especially limited fungible time :/ <mark_weaver>I also don't currently have a machine that can run GNOME 3 properly. <wingo>davexunit: there's the ongoing concern about back-compatibility... if that's an issue anyway *davexunit is also pretty ignorant of what's going on with GNOME/GTK <tupi>mark_weaver: i can provide remote access if that is the only obstacle <wingo>well if we use gir/introspection/whatever, can we guarantee back-compat with the 2.x apis? can we even guarantee sensible, stable apis? <mark_weaver>well, my thinkpad still works, just not the display. I can log into it remotely. <tupi>wingo: mark_weaver, gtk is now 3.10, we bound to gtk 2.24 [not supported anymore] and glade files are not even back supported ***Schaapjes is now known as Zildiv
<davexunit>I'm having a hard enough time figuring out how to generate bindings for SDL2. <mark_weaver>yeah, it seems like a good idea to completely revamp the way the bindings are generated, using gir. <mark_weaver>it would be a bigger job of course, but I guess it would make it much easier to maintain and keep up-to-date going forward. <tupi>guile-gnome-2 has no future, we need to do something <mark_weaver>it would also be great to make it pure scheme, using the FFI. <tupi>yes, then i could even help :) <davexunit>does GNOME have a parseable specification of their libraries? <davexunit>that makes all the difference for trying to generate bindings. <mark_weaver>davexunit: that's what gir/introspection is all about, iiuc. <mark_weaver>it's designed to make it easy to automatically generate bindings. <mark_weaver>but we're not using it because guile-gnome predates it. <tupi>wingo: i think we should leave guile-gnome-2 'as is' and start a different project, api can be new [but goops was awsome i hope we can still have that] and call it guile-gnome-3 ... <tupi>it's not as if we had millions of 'customers' here <mark_weaver>tupi: not requiring 100% back compat would certainly make the job easier, though I think we should make an effort to remain reasonably compatible. <tupi>is gtk3 api garantee to be gtk2 compatible anyway? don't know <wingo>but the whole point was to take advantage to break some stuff <tupi>mark_weaver: i don't think we should even try <wingo>ok, let's do a guile-gnome-3 at some point then, and not worry too much about back-compat <tupi>we should make a new totally new <tupi>perfect, I am happy to rewrite what ever will need to be that really is easy enough <tupi>we shold try to make the new project perfect in followihng future version of gtk, clutter and gtk-clutter <tupi>and keeping goops, i think it is essential [to me at least] <tupi>mark_weaver: with your laptop if you have an external screen does it wotk? <davexunit>could anyone take a quick look and see if anything jumps out at them? <davexunit>also accepting suggestions to improve debugging. I must admit that I'm a novice gdb user. <tupi>does the thinkpas has a decent graphic card? <tupi>[i have an 11yo laptop still does the job, slowly but ...] <mark_weaver>it's good enough to run gnome shell acceptably. intel <mark_weaver>(a real gamer would probably call it crap, but e.g. it can run celestia fairly well) <wingo>tupi: i guess we can start over building up from glib/gobject and such <tupi>wingo: i'll do my best to help, could you give me some pointers to read... <tupi>mark_weaver: perfect! let's start guile-gnome-3 then <tupi>it's gone a be fun [I hope :)] <mark_weaver>davexunit: SIGPWR is used internally by Boehm GC to suspend all threads. <mark_weaver>davexunit: when you catch SIGPWR in gdb, just hit 'c'. <davexunit>oh, I guess I didn't get all the way to the segfault then :) <davexunit>"Program received signal SIGXCPU, CPU time limit exceeded." <mark_weaver>I think that's another one used by GC. just keep typing 'c' through those. <mark_weaver>I guess there's a way to make gdb do that automatically, but I haven't gotten around to learning it. <ArneBab>davexunit: I’m still learning how to write wisp code as elegant as possible. <davexunit>my code uses hash-for-each to iterate over the weak key hash table <davexunit>so the scm_internal_hash_for_each_handle call makes sense <wingo>davexunit: echo 'source ~/src/guile/gdbinit' >> ~/.gdbinit <tupi>what/where is the scheme[guile] code we have to do introspection? <mark_weaver>tupi: I'd like to help, but: (1) I need to get Guile 2.0.10, and possibly also 2.0.11 out the door first. there are some important things that need to be done that aren't going to make it into 2.0.10, and I hope the time between 10 and 11 isn't very big. and (2) because of the realities of the places I linger and work, I need to either get a new laptop or a new display for this one. <wingo>davexunit: cat ~/src/guile/gdbinit to see :) <wingo>assuming your guile is there... <tupi>mark_weaver: tha's fine. for (2) we can find a agreement, as i'd be happy to contribute financially [we need to make a plan, the 3 of us, of course i limited contribution fund as I wrote recently... <davexunit>sorry, I got confused because the way I way typing in my shell didn't give me tab completion. <davexunit>so I thought that gdbinit wasn't a file in my guile source dir <tupi>wingo: any other scheme GPL introspection code we could use out there? <wingo>tupi: look for guile-gir on gitorious, or something rotty did somewhere <mark_weaver>the thing is, I really don't want to use a machine that requires binary blobs to work. I'm torn between getting one of those X60s, or getting together with some friends and building some Novenas. <davexunit>wingo: thanks. now I know that gbt is a thing :) <mark_weaver>thanks partly to your recent contribution to me, tupi, I might be able to afford to make a Novena. <tupi>by the way i wrote to him 2 days ago, to ask to move sasp the guile-gnome-2 debian packages to depend on guile-2, guile-1.8 id going to be withdrawn from unstable soon... <wingo>davexunit: probably needs to be removed... <wingo>i think that was from the 1.9 era <davexunit>well it gave me a guile backtrace that looks right <wingo>it was vmstack that's bogus :) <mark_weaver>if you really want good guile debugging, compile the latest GDB from its git repo and use civodul's recent work. <mark_weaver>oh, I'm *so* glad to hear that guile-1.8 is finally getting purged from debian. <wingo>mark_weaver: really! i haven't read that stuff yet <wingo>yes, guile-1.8 purging; excellent <tupi>rotty did not respond though, too bad <wingo>yep, still catching up on the guile lists :) <mark_weaver>he merged some (all?) of the necessary stuff into stable-2.0 recently, iirc. <davexunit> ?: 0 [hash-for-each #<procedure 18402a0 at ../2d/signal.scm:109:17 (output unused)> ...] <mark_weaver>although you also need the Guile scripting support in gdb, which is in gdb git. <ArneBab>mark_weaver: when working on wisp, I got many backtraces which looked like the output of (display . function-arguments). Is there a way to make the guile backtraces show the arguments a function got in a form which I can directly throw into an interpreter? <Fuuzetsu>mark_weaver: I don't appreciate you trying to attack me on the mailing list without a reason to. I never posted any FUD about Scheme/Guile in this channel or the mailing lists and I'd appreciate it if you didn't accuse me of doing so, thanks. <wingo>mark_weaver: i have a pending response to you about pseudo-hygiene -- perhaps we can just error or warn when introducing a toplevel id; that way we provide better feedback to user re: abi implications <wingo>(if we would error/warn then we could remove pseudo-hygiene) <mark_weaver>Fuuzetsu: yeah, well, I don't appreciate the things you have said here about me either (sometimes when I'm not been around) <mark_weaver>wingo: I actually think that simply producing an error when introducing a toplevel binding would be fine, maybe even best. <ArneBab>I don’t manage to provide a minimal example at the moment. <Fuuzetsu>mark_weaver: What have I said? Can you point it out? I don't think I ever talked about you when you weren't here. In fact, I can probably enumerate all the topics I have spoken about in this channel because there are just so few. If you have a problem with something I say, tell me, rather than attacking me baselessly. I'm sure you have logs so feel free to point anything out. <wingo>mark_weaver: perhaps the user should be able to control that; anyway, agreed with your general point that it's not a reliable mechanism <mark_weaver>wingo: it occurs to me, btw, that the "weasely interpretation" involving "every identifier is a top-level binding" would actually mean that those introduced bindings would be introduced in the module where the macro was defined, not where it is used, technically. <wingo>mark_weaver: that weaselly interpretation is the one chicken uses fwiw :) <wingo>i don't know what their module story is, though <wingo>we have had a number of bugs in this space, some of them along the lines you mention (macros defining identifiers in their definition modules instead of the module of the instantiation) <mark_weaver>Fuuzetsu: "attack" is a very strong word for what I wrote on the mailing list. I thought I restrained myself rather well. <Fuuzetsu>I'd prefer you didn't have to restrain yourself at all. If you have a problem with something, say it. ‘Attack’ is the only word I can think of to describe what occurred. Anyway, call it what you will, what you said was baseless and put me in negative light. <mark_weaver>Fuuzetsu: given your barely-concealed contempt for our language and our implementation, I really have no idea why you hang around here. in the few cases where you speak, you come off as very condescending. <mark_weaver>I got tired of you when you gave me a lecture about my improper use of language. <Fuuzetsu>Condescending? I never criticised Guile. <ijp>this is very tedious <Fuuzetsu>mark_weaver: I didn't give you a lecture, we had an argument about a well understood topic to which you ended with ‘I don't want to talk about this anymore’. If anything, I should be the one getting upset here. In any case, that discussion (and any others, be it mvars, STM or whatever we talked about) has *nothing* to do with what I think about Guile/Scheme. <mark_weaver>look, for whatever reason, you and I seem to be like oil and water. I don't want to talk about it. <Fuuzetsu>Stop attacking me for no reason. If I say anything you disagree with, say so: I know I do. That's what discussions are. I'm not exactly coming here shouting ‘Guile is shit’. <Fuuzetsu>mark_weaver: If you don't want to talk about it then don't talk about it instead of posting shit about me on the ML. Don't make shit up. <wingo>don't even know who this guy is, what is his deal <Fuuzetsu>I don't want to be having this conversation either. <wingo>go somewhere else, it's very easy :) <Fuuzetsu>wingo: I am simply a person who dared to point some stuff out to mark_weaver and apparently that's a grave sin around here. <Fuuzetsu>wingo: Why? I want to be here, I'm interested in some of the stuff that gets said here. <wingo>sorry, you're being an ass right now. <wingo>maybe you could get better in time but i kindly suggest you come back later :) <Fuuzetsu>wingo: I am? How? Someone is posting shit about me on ML for no reason, I politely ask them to stop and I get more shit and I'm the ass here? <Fuuzetsu>Shrug, whatever. Mark, just don't post misinfo on the ML and it's all going to be great. Thanks. <mark_weaver>I wouldn't have posted anything at all about you if not in response to you trashing someone's proposal to write a new TLS implementation in Guile, because Guile is only "slightly less unsafe" than C, and because it presumaby wouldn't include proofs of correctness. <Fuuzetsu>mark_weaver: That's not at all what I said or at least not what I meant to say: my sole question to the thread is how the security is going to assure it. If you look, there are 2 more e-mails from me where I re-iterate this. If you weren't sure what I was asking them ask for a clarification. Feel free to reply on-topic on the ML. <Fuuzetsu>how the security of the library is going to be assured* <Fuuzetsu>Sorry, I'm far too tired, I'm going to head to bed. Just post on ML if you have the answer or don't post if you don't. Good night. <davexunit>I can get myself into a situation where (hash-for-each (lambda (key value) (display key)(newline)) table) crashes <davexunit>only the weak ref has issues. 'value' can be displayed without issues. <wingo>i would suggest not using hash-for-each or other traversal procedures on weak tables... <wingo>dunno if that is a suitable answer <wingo>probably there is a bug as well <davexunit>wingo: okay, then I need another way to iterate over a collection of weak refs <mark_weaver>I don't know the details, but wingo made some substantial changes and improvements to the way weak hash tables are implemented in master. <mark_weaver>I guess that there are some problems in stable-2.0 that might be hard to fix, dunno. <wingo>master seems to have a completely separate for-each implementation for hash tables <wingo>i guess we should keep enumeration and just fix the bug in stable-2.0 <davexunit>if I can find some sort of workaround that will be fine. <wingo>davexunit: there's a good quick fix <wingo>if you want to submit a c patch <wingo>dunno if that's your thing :) <davexunit>would this patch have a chance of making it into 2.0.10 or will it likely need to wait for 2.0.11? <wingo>you'd have to reverse the logic <wingo>if !weak-table || !weak-pair-deleted? <davexunit>wingo: thanks. I'll see if that solves my problem and submit the patch if it does. <wingo>a test case would be swell as well <davexunit>I'll see what I can do. hopefully just need to run the GC manually and call hash-for-each <davexunit>interesting, running the gc twice before iterating over the table works fine. <davexunit>thank you so much! my FRP system seems to be stable now! ;_; it's so beautiful <ArneBab>How can I find out inside a module whether the module was invoked directly (guile mod.scm) or used via (use-module)? <ArneBab>something like “if invoked directly, say so” <davexunit>how do I run a single test file in the test suite? <davexunit>I thought it was: test-suite/guile-test hash.test but it's not working <tupi>guile-gir last commit from 2011 <tupi>i wonder if its been used in practice... <davexunit>wingo: patch submitted. thanks for the help. <davexunit>does anyone know how I can write a configure script that checks for guile 2.0.9 or newer? <ArneBab>davexunit: I think autoconf should be able to do it <davexunit>and it automatically checks for guile >= 2.0 <ArneBab>I *think* you should be able to set a variable to the output of guile --version <ArneBab>guile --version | head -n 1 | cut -d " " -f 4 <ArneBab>(but that only checks for exactly 2.0.9 <davexunit>not too important now, but once 2.0.10 is released I want to update guile-2d's configure file to ensure that users have at least that version.