IRC channel logs
2015-12-15.log
back to list of logs
<leedleLoo>I'm trying to write a guile module with the c api. I'm fine with wrapping my functions and registering them with scm_c_define_gsubr, but I'm not sure what to do next. <leedleLoo>I wouldn't sue scm_with_guile(...) in a main function would I? <mark_weaver>leedleLoo: see section 6.20.3 (API Reference -> Foreign Function Interface -> C Extensions) in the Guile manual. <mark_weaver>and you might consider writing the module in pure scheme and using the dynamic FFI to access any C functions that you need. <davexunit>if you, fellow guilers, were translating a C enumeration of keyboard scancodes into Scheme, what data type would you use to represent them? I'm deciding between symbols and characters <davexunit>I'm thinking symbols, because this enumeration has all of the non-printable keys like F1-F12 <daviid>davexunit: not that it answers 'proper' your quizz, but clutter's (get-key-symbol e), e being a clutter key-press-event/key-release-event, returns an integer <davexunit>I'd like to avoid integers in favor of something human readable <daviid>davexunit: sure, is there any standard anywhere about this, symbols I mean? I guess clutter's int are X11 'what ever standard it is', then there should be a higher level binding... don't know <paroneayea>civodul: will promote the guix fundraiser thing this morning. In the meanwhile <paroneayea>civodul: I started using it last night. I wish I had been using it years ago! <civodul>paroneayea: wait a minute, we haven't sent an announcement :-) <davexunit>not many people have seen it yet, so we're okay. <civodul>initially i thought we'd wait for FSF's announcement, but maybe not <civodul>we should add something to the web site though <davexunit>(but I saw it this morning via Manoulis so direct blame at him, please) <davexunit>I'd like to be able to fill-paragraph and such <paroneayea>davexunit: I've recently switched to using one sentence per line for documents I'm checking into version control. My instinct is to M-q, but the argument was convincingly made to me that if you M-q all the time in documentation, version control stops working so well for it <civodul>davexunit: yes skribe-mode is somewhat broken and would need the expertise of an alezost ;-) <civodul>i use it though, but yeah, many things don't quite work well <davexunit>lines longer than 80 characters are painful to deal with <paroneayea>davexunit: yeah, I'm trying to force myself to do it <paroneayea>davexunit: one intermediate way to do things would be to do <paroneayea>but emacs doesn't give you anything nice like M-q for that. <davexunit>I'm not particularly convinced by the version control argument <davexunit>it's much better to have text that is easy to read and write <paroneayea>davexunit: it's harder if you're doing standards work <paroneayea>and have get patches to affect the same paragraph <davexunit>I've opened enough markdown files with 1 line per paragraph to know that I absolutely hate reading them <paroneayea>well one line per paragraph != one line per sentence <paroneayea>so I'm starting to work on a guile tutorial in Skribilo <paroneayea>Petit_Dejeuner: I spelled that out in the email I wrote on this <davexunit>I imagine that you'll build up to using the module system and such <Petit_Dejeuner>paroneayea: I'm still not sure if you're writing for people who don't know programming or just don't know Scheme. If it's both, that seems confusing. <Petit_Dejeuner>Sorry if I missed some of the conversation, my computer froze up. <paroneayea>Petit_Dejeuner: like many language tutorials, it's aiming to be acceptable for people who don't know any programming, but aims to be a good fit also for those who do <paroneayea>Petit_Dejeuner: "experience in another language" might mean tottally different optimizations depending on the language <paroneayea>eg, a person who knows emacs and python only is different than someone who knows eclipse or other heavy IDE only and java <paroneayea>Petit_Dejeuner: so I'm doing my best job to be "good for newcomers" and will tweak later as people try it. <paroneayea>my assumption is, you don't necessarily know any programming languages while trying this tutorial, but it'll be a lot easier if you do. but there will be things to relearn no matter what if this is your first lisp! <paroneayea>it's hard to know what assumptions are implied until someone tries things too <paroneayea>I don't expect to get it right totally the first time, but I think having a document and iterating later will be easier than trying to define everything perfectly ahead of time. <paroneayea>I once tried to be helpful showing someone an example of how to do something before they coded it and turned around to ask if that helped, and they were tearing up because they couldn't follow me splitting and joining emacs windows and I unintentionally made them feel foolish because they had no idea what was happening. We started again with just gedit and a terminal (which was familiar to them) and they followed it just fine the <paroneayea>but from my vantage point, it was hard to anticipate that, because I've forgotten what it's like to not know these things. So I'll do my best and refine based on feedback. <Petit_Dejeuner>The reason I'm bringing this up is because while reading the tutorial, I see things I want to change, but I don't know how I'd want to change them because I don't know who I'm trying to write for. In the tutorial you explain what a text editor is and why one is needed, so I assume it's for people who have never programmed before, but at the start of the tutorial you explain that Guile is actually a language virtual machine and you talk <Petit_Dejeuner>about object-oriented programming and functional programming without defining the terms. If you're writing for people who can't program, I'd edit the tutorial so that Guile is introduced as a programming language and then I'd define "programming language". I'd also remove the terms "object-oriented" and "functional programming", because they're not defined, and defining them would be cumbersome to do in the introduction. If you're <Petit_Dejeuner>writing for programmers who don't know Scheme, I'd make different edits, like taking out the part explaining what a text editor is. <Petit_Dejeuner>And I think you're right. Trying to explain something to a newb with Emacs would be a bad idea. <paroneayea>Petit_Dejeuner: Ack, I know that can be risky, but I'm trying to point at paths for people to possibly explore later <paroneayea>Petit_Dejeuner: while giving a simple setup in case you don't know enough now <paroneayea>Petit_Dejeuner: my favorite programming tutorials and manuals have done this. <paroneayea>Petit_Dejeuner: it's a tradeoff taking that approach. <Petit_Dejeuner>One way to do that would be to have little footnote/sidenote boxes. <paroneayea>Petit_Dejeuner: could be. I'll worry about optimizing that way later, if at all <paroneayea>Petit_Dejeuner: for now, this thing will be written how-paroneayea-feels-like-writing-while-keeping-his-goals-in-mind style, because that's the fastest way I'm likely to actually write something useful at all <paroneayea>Petit_Dejeuner: if I spend a lot of time worrying about these details, I just won't do it. <Petit_Dejeuner>Sounds good. The hardest part about writing for me was always getting something down, so you're doing way better than I am. <paroneayea>Petit_Dejeuner: yeah I kinda gotta free flow write in the moment while it's clear for me <paroneayea>I write down a lot of notes and outlines beforehand <paroneayea>so I have the structure there, then I flush it out while things are clear, I mean <paroneayea>I wrote most of the Hy docs while in a car as something interim because the language had no docs at that time