<zzach>Is it possible to iterate through a char** array via the FFI, and if yes, how to do it? <taylanub>zzach: Unfortunately I have to go, good luck. <zzach>@taylanub: thanks for the hint. <mark_weaver>zzach: yes, it's certainly possible. do you know the length of the array in advance, or is it NULL terminated? <mark_weaver>some relevant procedures are 'pointer->string', 'dereference-pointer', 'pointer-address' and 'make-pointer'. <mark_weaver>sneek: later tell zzach: yes, the relevant procedures are 'dereference-pointer', 'null-pointer?', 'pointer->string', 'pointer-address', 'make-pointer', and (sizeof '*) to find the size of pointers. <dje42>Is there a way to set the heap size? <mark_weaver>I think Boehm GC looks for the GC_INITIAL_HEAP_SIZE=<bytes> and GC_MAXIMUM_HEAP_SIZE=<bytes> environment variables. <mark_weaver>but by default, the heap will be dynamically expanded as needed. <dje42>Righto. Just wondered what knobs there were. <sneek>I last saw wigs on Jul 16 at 03:17 am UTC, saying: are literal pairs are already supposed to be immutable?. <ijp>civodul: about (info "(guile-reader) Quick Start") <ijp>hmm, what a coincidence <civodul>i've been thinking about "geographical" key bindings <ijp>it mention that you need to use eval-when for guile 2 <ijp>otherwise the fluid gets set after the file has already been read <ijp>civodul: what would a "geographical keybinding" mean <civodul>for instance, what matters about C-x s is the location of the keys, not the letter written on them <civodul>so you would be able to express that, somehow <civodul>and then, if you switch keyboard layouts (like from qwerty to Dvorak), it still works <ijp>it might be fine for standard layouts, but it sounds very hard to generalise <ijp>a one handed keyboard <civodul>well yeah, it's probably not fully generalizable <ijp>the maltron ones look even more crazy <civodul>actually, Emacs can't possibly be used with a one-handed keyboard, can it? :-) <ijp>I dunno, but I'd like to find out <ijp>the price is crazy high though :( <ksinkar>I am trying to use slib with guile. My development environment is emacs. I have soft-linked my guile exectuable to /usr/bin/scheme such that emacs runs guile as scheme in the inferior scheme mode <ksinkar>Now while trying to do this "(use-modules (ice-9 slib))" I get the following error: "While compiling expression:\\n ERROR: In procedure primitive-load-path: Unable to find file "slib/guile.init" in load path"; Here by the primitive load path, are they talking about the emacs load-path function or something else? <ijp>have you installed slib? <ijp>guile does not come with it, only a wrapper module that tries to run the guile.init in slib <ijp>what do you want from slib anyway? <ft>Also, ‘geiser’ for guile in emacs! ;) <Fuuzetsu>Greetings. Where can I find the whole guile standard, including formal operational/denotational semantics description? <ijp>the *scheme* standard comes with a denotational semantics <ijp>but there is not one that includes guile extensions <ksinkar>ijp: yes I have installed slib, I am running guile-2.0 <Fuuzetsu>Well, that's where I was going to look at next but I thought guile might have adopted that standard + adding stuff on top as opposed to referring to the Scheme standard. That's fine I guess. <ksinkar>ijp: I want to do web programming with slib. <ijp>well, I'm not going to disuade you because I assume slib will do a good enough job of that on its own <Fuuzetsu>ijp: Well, how about a place that clears up on ‘supporting the Revised5 and most of the Revised6 language reports (including hygienic macros), as well as many SRFIs.’. The word ‘most’ is not the most descriptive. <ijp>ksinkar: _where_ have you installed slib? <ijp>Fuuzetsu: filling in the IO modules is one of the big problem areas <ksinkar>ijp: I have installed it in "/usr/local/lib/". Just as an aside here are the other details:- (ubuntu: 12.04 LTS x86_64), emacs23 <ijp>and where have you installed guile <ijp>(assq-ref %guile-build-info 'datadir) <ksinkar>scheme is at /usr/bin/scheme whitch is nothing but soft link to guile <ijp>what does the above scheme form evaluate to? <ijp>I see, well, your guile is looking for /usr/share/slib/guile.init <ijp>so since you've put slib in /usr/share/lib/ that probably accounts for it <ijp>ksinkar: were both of these packages installed by ubuntu's package manager? <ksinkar>guile was from ubuntu package manager <ijp>I don't know what slib says in its README, but usually you want it installed in the same --prefix as guile <ksinkar>ijp: should I just delete my source installation and install using ubuntu package manager? I think that will be simpler. What has been your experience? <ijp>if it's available in the package manager, that's usually preferable <ijp>from the package manager version? <ijp>then it's an ubuntu packaging bug (either their guile 2 package or their slib package) <ksinkar>ijp: yes, I think I maybe missing something here. ok <ksinkar>ijp: is there any way to fix this for sure? <ijp>I've told you which file guile is looking for <ijp>if that file is there, guile will load it <ksinkar>ijp: can I do something like (add-to-list 'load-path... the way we do it in emacs? <ksinkar>ijp: actually the ubuntu slib installed exactly in /usr/share/ <ijp>you can do, but remember your .guile doesn't get loaded when you run a script (I think) <ijp>ksinkar: wait, so you are saying /usr/share/slib/guile.init _does_ exist <ksinkar>yes, after I installed it from the ubuntu package manger <ijp>hmm, maybe the problem is in slib then <ksinkar>before I installed slib with ubuntu package manager, i had symbolically linked my source installed slib directory to /usr/share but even that did not work <ksinkar>ijp: it is the correct version for guile-2 <ksinkar>ijp: init files from the source package and the ubuntu package are quite different <ijp>apparently slib support was fixed relatively recently <ijp>so 2.0.5 will be using an old version <ijp>sigh, I really need to start keeping a 2.0.5 install around so this doesn't keep happening <ijp>ksinkar: can you load guile.init fine directly? <ijp>because if so, that's probably your best bet until ubuntu gets a newer package (whenever that is) <ksinkar>I am cloning the repo, and it is taking some time <ksinkar>ijp: should I go and replace the slib.scm in my current guile? What do you mean by directly loading the guile.init file? <ijp>(load "/path/to/slib/guile.init") <ksinkar>ijp: my my this gets better and better <ijp>what did you type and what was the error? <ksinkar>ijp: while it works for the slib source directory <ksinkar>ijp: this is what i typed: (load "/usr/share/slib/guile.init") <ijp>and the actual error? <ijp>hmm, a broken define in guile.init seems like a crazy thing <ksinkar>ijp: do you want me to paste the backtrace as well? <ksinkar>ijp: should I just go ahead with the source installation and load their guile init and be done? <ksinkar>ijp: How can I fix this problem for others? <ijp>well, it _should_ be fixed with current guile <ijp>ah, they tried to define define <ijp>ksinkar: weird, that code shouldn't have even been expanded <ijp>because you are on guile 2, it should have hit the first case in cond-expand <ijp>ksinkar: ah I've gotten confused again <ijp>ksinkar: yes, you should load the one from the slib source <ijp>since that one has the fixes necessary to get to work <ksinkar>ijp: kool, then I shall get back to work <ksinkar>ijp: will ping you if I run into problems again <ijp>cool, I'm off for a walk <ksinkar>ijp: I am getting the following error now, when I do (require 'primes): <ksinkar>ERROR: In procedure open-file: No such file or directory: "/usr/share/guile/site/2.0/slibcat" <sneek>Welcome back davexunit, you have 1 message. <stis>hmm, we should really support monads effectiviely in guile rtl! <ijp>stis: I'm not entirely sure if you are joking <stis>say 10 generators si <- gi(si) and try to maange state effectively . <stis>you just don't want to copy that state information back and forthe to functions. <stis>The problem is in trying to standardize function interfaces with that extra state information <ijp>I have three objections. 1) monadic style is not direct style 2) dynamic languages cannot be polymorphic in the return type 3) monads don't compose well (yes, I know transformers, but I still think they are not great) <ijp>actually, I do have answers to 1 & 3, but they involve delimited continuations <stis>well just say that f(x) means ~ (s1, ..., s10, ret) <- (f s1, ..., s10 x) <ijp>if you want to write an ad-hoc monad for your own purposes, that's fine, I've done it, but why should guile make a special effort? <stis>in that case, along the stream you could force s1, s10 to be on the same place on the stack <stis>I'm afraid that in current rtl s1, ... , s10 would be copied back and forth <stis>so add-hoc or not, guile can do better! <ijp>try formulating what it is you want without talking about monads ***christianabryant is now known as tomsitprocb
