IRC channel logs
2022-11-25.log
back to list of logs
<singpolyma>rekado: Mastodon at least since that's usually what people test against <singpolyma>Honk and epicyon and microblog.pub are all cool but each a bit more niche than takahe/Pleroma/mastodon <robin>old, i'd love to see more widespead use of format or something similar; string-append and friends seem not-great for localization <robin>(format isn't perfect either, but maybe closer to what people are used to with gettext etc.) <haugh>robin, that is extremely cool but I hope you'll forgive me if I don't have time to grok it. tbh I have no business playing with the reader right now but I can at least spin it as Guile expertise <flatwhatson>re: Higher-order modules from the docs: "... these are pretty kludgey ... If you must know, figure it out from the following grammar." <robin>haugh, yeah, it's really not well-documented at all, i guess the main idea is just that SML/ocaml-style modules can work pretty well in scheme <flatwhatson>you can procedurally create modules in guile, so i think higher-order modules are theoretically possible <robin>there's some (relatively) recent research on ML modules too that might be applicable to scheme, like rossberg's "1ML – Core and Modules United (F-ing First-Class Modules)" (doi:10.1145/2858949.2784738) <flatwhatson>that could be kind of neat for something like "here's fold for my type, generate me the srfi-1 variants based on it" <haugh>my brain jumped to generating API wrappers <robin>yeah, it would be interesting to compare that with e.g. a typical clos/goops approach (optimization would perhaps be easier for the compiler if the "methods" are early-bound, so to speak) <old>What would be the impact on performance for higher <old>That would impact the compiler no? <flatwhatson>i don't think any new compiler features would be needed. the higher-order module is just a procedure to generate modules. so there is some runtime cost when you instantiate it with particular params. <old>Wouldn't inlining be affected for example? <robin>guile already technically has first-class modules, as flatwhatson mentioned, and modules are mutable, so now i'm not so sure about easier optimization :) <robin>old, i think so, redefinitions could certainly invalidate inlining (that can happen already but it's presumably rare except when using the repl/geiser/etc) <cow_2001>weird let syntax defines a local function. (let f ((n 4)) (if (= n 0) n (begin (display n) (newline) (f (- n 1))))) <Zelphir>I recently thought about how to work with modules from macros, as it would be cool to be able to define contracts for procedures outside of the procedures' expressions/forms and I imagine one would have to redefine procedures of a module then or, if not already defined, look up their definition in the module and change it somehow. I've not experimented with manipulating module at all yet. <old>cow_2001: This is special form of let called "named let". It's used for looping. e.g. `(let loop ((i 0)) (unless (= i 10) (display i) (newline) (loop (1+ i))))` <old>The form is: let NAME BINDINGS BODY <old>Zelphir: That would be cool yes. We could almost do some sort of decarator like this. <old>haugh: So we have to use-modules in every module that need the reader? <cow_2001>how do you get information about various guile stuff inside guile? tried ,describe let and it didn't let me in on its secrets. <old>It's my understanding that `read-hash-extend` must be called inside at the begining of the module for enabling the extension <old>Well `let` is a special form. So it's probably confusing the reader or macro-expander <old>Try `,describe string-concatenate` instead <cow_2001>oh, there's a Neil Breen fan on the other side of the Matrix bridge. <cow_2001>old: but i don't want it to describe string-concatenate. ;_; <haugh>old, idk what alternative there is. Seems impolite to subvert the whole module system. <cow_2001>haugh: sorry. i am just hypnotised by your Neil avatar. <cow_2001>haugh: i've tried using kdenlive and i didn't know what i am doing. ~_~ <flatwhatson>so all modules are "procedural" modules, higher-order wouldn't be different <old>cow_2001: I meant that as an example of using `,describe`. It won't work on a special form like `let` or `if`. <old>haugh: I don't have much time on hand for the next weeks, but I'll maybe add a blog post soon about a reader for heredoc. I'll ping you <haugh>no worries, busy time for everyone. it's been nice chatting with you about it <robin>cow_2001, i don't remember how ",describe" works, but the guile info manual is a good reference for most built-in things (e.g. the node for "let" in the index links to the "named let" documentation) <robin>i think of named let as a relatively simple extension of the lambda-calculus equivalent of "let", although in scheme it might be more natural to think of it as a "letrec" that gives the anonymous function (conceptually) constructed by "let" a name for itself <robin>(in λ-calculus, that could be implemented with a fixed-point combinator -- iirc turing's U combinator "works" with applicative order, though scheme isn't pure λ-calculus ofc) <robin>(iirc better-known Y combinator is more natural for normal-order languages like haskell) <robin>e.g. (let ((a 1)) ...) ~= ((lambda (a) ...) 1) and (let foo ((a 1)) ...) ~= (letrec ((foo (lambda (a) ...))) (foo 1)) <robin>the better-known Y combinator* <robin>(if i've mixed up the fixed-point combinators, something like smullyan's _to mock a mockingbird_ should have the correct answer ;)) <haugh>what is the "modern" way to generate an eof-object? <haugh>I guess what I'm asking is "do I need to import RNRS" <haugh>Oh, found it in (ice-9 binary-ports) through trial and error <cow_2001>robin: oh. now i feel dumb for asking… and yet… would have been nice having super succinct information inside ,describe <cow_2001>in the book, it may or may not have been the first place mentioning named let. i am not sure if i just forgotten about the first time it mentioned let. <cow_2001>but it appears again in 6.13.4 API Reference > Control Mechanisms > Iteration mechanisms <tohoyn>daviid: Why is class GtkAlertDialog undefined in G-Golf? <tohoyn>daviid: <gtk-alert-dialog> is undefined even if I use (gi-import "Gtk") <tohoyn>daviid: I solved the problem with GSettingsAction: the callbacks are connected to GSettings rather than GSettingsAction <cow_2001>"Dividing by an exact zero leads to a [sic?] error message, as one might expect." and yet scheme@(guile-user)> (/ 1.0 0) => $9 = +inf.0 <cow_2001>did i find a bug in the documentation?! O_O <cow_2001>down the rabbit hole i go. git clone ...guile.git. <cow_2001>of course it is a minor typo correction ~_~ <cow_2001>oh my god. (inexact->exact 1.1) => huge enumerator / huge denominator <cow_2001>i don't know why i love it so much, but i do. :| <flatwhatson>(- (inexact->exact 1.1) 11/10) => 1/11258999068426240 <flatwhatson>(exact->inexact (- (inexact->exact 1.1) 11/10)) => 8.881784197001253e-17 <old>cow_2001: (/ 1 0) is an error. An integer division by zero is not possible <old>(/ 1.0 0) however is a floating point. It can work with IEEE754 floating point and yield infinity <old>Try in it C. You will get SIGFPE for 1 / 0 but you will get inf for 1.0f / 0 <old>You can even do (/ 0.0 0) with floating point, which is NaN <ArneBab>haugh: getting something included everywhere is a political clustecfuck, yes, but this is what can bring actual simplifications to development. It is what brought us ./configure && make install. But nowadays most new projects opt for the "I don’t care about others or the future, just make it look simple on the outside". Sidenote: Hello Rust, thank you for breaking the build of that library so I cannot install a tool, even though my distro <old>ArneBab: I heard horror story on Rust crate and Guix <cow_2001>oh boy. i love hearing rustlang stories. <old>Can't be worst thank cmake tough. Gosh I hate that build system. <spk121>old: I've come around on cmake. Once you push past how it is literally the worst, it is not so bad. <haugh>arnebab, if you control and are willing to spend the political capital required to move the core, more power to you. Just don't be surprised if others want to save theirs. <ArneBab>old: I once tried to package firefox. After 100 packages I gave up. Someone else later got it done … <ArneBab>haugh: if others have to save their core, then there’s a mistake in the plan. Good planning means that you only try to get into the core what actually benefits most people and doesn’t break the setup for others. <haugh>Okay but I think this is more subjective than your language would imply. On the whole I find myself less and less enamored with centralized policy and more willing to embrace technically specific frameworks for compromise. <ArneBab>old: regarding build systems: after make I tried cmake and scons and waf and a few others — and in the end I arrived at autootools again: the least broken of the build systems once you leave the common paths. <ArneBab>haugh: I like a centralized policy to provide basics that are already known to actually be needed by most, and provide them in a way that enables experimentation to find out which other paths work out. <ArneBab>Part of this is that it makes it easier to build the core into one consistent system which is much easier to understand than a collection of libraries with many different approaches how to build an API <ArneBab>As a practical example: I think that fibers should be in Guile via (ice-9 fibers). They are growing more and more integral to many usages of Guile. <haugh>When I said "others want to save theirs" I mean "their political capital" not "their core [lang]". Re: specific policy, just last night some folks in here mentioned the sort of underlying first-class module system in Guile and I think that's a great example of flexible policy (even though I don't understand it hehe) <ArneBab>As a practical counter-example: I think systemd should have never gotten into the central position it now holds in may distros: it does far too much. <haugh>in re: canonizing modules like fibers, I think the real earth-shattering power of Guix is manifest in how that distinction between a third party and core module is suddenly not so important when there's a consistent environment between them <cow_2001>just being a mere user programmer of rustlang was nice. i love a dominatrix compiler telling me what to do under the type constraints, but i now know there are many other criteria underwhich it fails. <ArneBab>It’s also hard work to find what is actually worth spreading — with 30 I thought I should spread much more, at 35 I started thinking "why should I spread my understanding when someone else might understand this better? I could mislead people!" — now at 40 I arrived at “WTF are people spreading?! Where I grew silent, it wasn’t the more knowledgeable people who got heard. But I have less drive to spread my understanding nowadays”. <ArneBab>ACTION wonders when the fuck he aged to 40 … <ArneBab>haugh: oh, yes, that’s awesome with Guix! <haugh>Isn't systemd a great example of what happens when a small group is granted unrestrained core access, becomes institutionalized, and suddenly is at least as concerned with protecting its own system of political economy as it is with solving the problems it was founded to address? <ArneBab>that’s why it’s usually good that it takes work to get something in core. <haugh>Oh, we agree. How did I get the opposite impression <ArneBab>I have to remind myself consciously how just adding a library blocked me when I still didn’t use Guix (because there are many others whom I exclude when I expect them to have Guix). <ArneBab>haugh: I don’t know, but I also had it :'-) <ArneBab>haugh: maybe because I said that it can be worth to invest the political capital? <ArneBab>that could also be understood as trying to become the dictator who can decide (but it wasn’t what I meant). <ArneBab>or because we interpret "political" differently? (for me that’s talking to and convincing people) <haugh>I could only guess at which part of my lengthy discussion with ~old you were responding to. <ArneBab>maybe I could have given more context what I reply to (by writing more of a complete argumentation) <haugh>Humans primarily perceive change and Guile's module system is light years ahead of some of the crap I've been stuck with, so in conjunction with Guix, which is still very shiny and impressive to me, I'm more than happy to take a very conservative opinion about the core language <haugh>But I'm sure I'll get bored and cranky and opinionated in time :) <ArneBab>It’s totally awesome that I can do that in Guile — and use all capabilities of Scheme in that ("Enter" is a pretty complex nested syntax-case construct. <old>ArneBab: Despite peoples whining about autotools, it actually does a very good a job. Build system are complex beasts <cow_2001>i was about to ask how you handle writing publicly to public mailing lists where all of your mistakes can be publicly ridiculed, but then i recalled this channel is publicly logged… <old>Now if we would throw out the M4 stuffs along with the 1970 shell portability. Something in a DSL in Guile kind of what hall does <old>cow_2001: If you learn from your mistakes -- and aknowledge them -- than you're the oposite of ridicule IMO. So who care if it's public? <old>And a community that would shame someone on a ML or IRC chat for a mistake is not a community I would like to be part of. Fortunatelly, I don't have the impression that Guile's community is composed of peoples who point finger at mistakes other than for correctness :-) <cow_2001>okay, i wrote (define x '((a . x) (b . y) (c . z))) (assq-set! x 'a 'a) and it complains about "expecting mutable pair", so i guess it is a problem of immutability? <haugh>cow_2001 yeah the quoted alist is immutable <old>litterals are always immutable <old>1 "foo" '(1) are all immutable <cow_2001>it (define car1-properties '((colour . red) etc.)) and then (assq-set! car1-properties 'seat-colour 'black) which does not raise an exception <old>assq-set! does not necessary modify the alist IIRC <cow_2001>it may return a new alist with the input difference? <old>that's what I have in my REPL yes <old>The return value is red&black <old>But the variable car1-properties only has red <old>even after the assq-set! <haugh>Okay but why does (assq-set! '((a .b)) 'a 'c) raise type error? <cow_2001>maybe i should pastebin the error message <old>Because you're mutating a value that's already in the alist <old>When previously you were only adding a value, thus consing <old>This is why you have to do: (set! car1-properties (assq-set! car1-properties 'seat-coulour 'black)) <old>So that your variable point to the begining of the alist <cow_2001>oh right. things that end with a bang mutate their input, right? <old>Well '!' really is for pay attention <old>But yeah. Usually is for mutation <old>If you want to mutate an alist, you should not use a litteral alist <haugh>Oh yeah, I was just looking at read-delimited! where the bang seems to mean "this interface is jank incarnate, strap in" <old>Instead do something like: (acons 'wheels 4 (acons 'colour 'red '())) <old>Then you can use (assq-set! properties 'wheels 2) <cow_2001>but why did the car example fail for me and not for you? what's the difference? <old>But always do: (set! properties (assq-set! properties 'wheels 2)) because if there's no wheels in the alist, then there's no mutation but only a new alist by consing the new value <old>This does not throw an error: (let ((alist '((foo . fuz)))) (assq-set! alist 'bar 'buz)) <old>But the variable ALIST is not updated. You will not be able to find the 'bar key in it. <old>This example throw an error: (let ((alist '((foo . fuz) (bar . buz)))) (assq-set! alist 'bar 'buz)) <old>Well if you use the definition at line 4757 no. <old>But if you use the definition at line 4770 yes <old>By bug I meant it does throw an error for defintion of line 4770 <old>Wheter it was intentational or not by the author would define if it's indeed a bug <old>I do see that under it, the result is not correct <old>Now make a patch :-) <old>But I think that the author was using the first definiton in their REPL <cow_2001>hmm. do i first show how it fails, then use the acons definition? <cow_2001>i read it as if first car1-properties is defined with one alist, then it is redefined with another <old>I think the second definition should be named: car2-properties <old>Then you can add an example for car2-properties that throw an example and explain the reason of that <old>s/throw an example/throw an exception <old>Good catch btw! This kind of eror can be confusing for newcomers to the Scheme world <cow_2001>hello. i am a newcomer to the scheme world. ;p <old>Right and you've seen the incoherence when testing the code. So that's great! <ArneBab>There was a time when Guile did not enforce immutability of quoted lists, so the code likely once worked. <cow_2001>looking ahead i see there are acons and exceptions mentioned. maybe i should just say something like "Notice that if we used assq-set! on car2-properties you would get an exception. In section so-and-so you would learn how to avoid that using acons." <cow_2001>hmm... how should i write down the exception i get inside the manual? <old>There's no example in the manual for that eeh <old>Maybe do a `(false-if-exception EXP)` <old>And show that the return value if #f <old>You can also use the `⊣` character to show something that is displayed <old>`⇒` is for returned values <old>So really either: ⇒ #f <old>Or: ⊣ The exception text. Possibly multi-lines .. <cow_2001>what is the texi macro for that -| symbol? <cow_2001>occurred to me i could just C-s ⊣ in emacs and find the right texi file <cow_2001>so i should use the interactive guile session, right? not a script <old>You could not have found the -| by itself in the texi files. I've personnaly searched for a `display` call in the manual, then a grep of it in the texi files <old>A grep of the displayed message <old>Yes interactive session in a REPL. That's how usually one read the manual <old>By evaluation of the example in a REPL <old>Ofc that does not apply well if you're reading the paper version .. <old>Hm I'm not sure if you have to put a @print{} for each line <rlb>If guile were to migrate to utf-8. Could symbols switch from having an indirect, internal stringbuf to just having a raw internal pointer to the relevant utf-8 uint8_t*? The difference I see so far is that they'd be lighter-weight (and not need to be involved in string.c internals) in exchange for losing any structure sharing (storage) across multiple (symbol->string x) calls for the same x. Is that important? <rlb>ACTION is back to toying with a utf-8 conversion... <cow_2001>i'm just cargo culting the @result{} notation where if there is a multi-line result, you put @result{} in its own line followed by a multi-line result <old>Okay a single @print{} is fine <haugh>old, what did you just look up? style guide? <old>See in misc-modules.texi:31 <old>haugh: grep -R '@print\{\}' guile/doc/ref <old>Then cherry-pick a file with a result and follow the style in there <rlb>(I do have it to the point of passing all the tests with all wide access limited to strings.c, but there's still a good bit to go, and I don't know that I'll actually get there...) <old>haugh: But there's GNU related style somehwere IIRC <haugh>The last time I tried to learn the texi format I read an official GNU doc that said something along the lines of "find an existing file and change the content" so you're definitely following the spirit if not the letter <rlb>(And there there'd still be a good bit of work rewriting any number of srfi-*.c calls that rely heavily on scm_string_{ref,set_x}, which will be much more expensive with utf-8, even with the offset indexes, than alternative approaches.) <old>haugh: That's what I did. I like the GNU bison manual a lot. I've took the liberty of reeusing their style/template <cow_2001>old: i'm getting pooped. would have to continue tomorrow. if you have anything else i could do for this WIP, please let me know. thank you! <daviid>sneek: later tell tohoyn nice, could you add this to the application example, the latest version, the one I send you back with a few changes that would need to be 'in' so we can later add the exmpe all together to the g-golf examples gtk4 ... either paste or emnail, but take a few minutes to exaplin what you first tried that didn't work, so I still look nat it (and learn from your attemps ...) thanks <rlb>civodul, wingo: does/must SCM_SYMBOL() and SCM_GLOBAL_SYMBOL() (i.e. IMMUTABLE_STRINGs) work for wchar_t strings? Looks like all internal uses are ascii, but didn't know what the requirements are. <wingo>should be latin1 i would imagine <wingo>but, not sure what it expands to <rlb>It just does sizeof(buf) <rlb>via SCM_IMMUTABLE_STRING in strings.h <wingo>right so without the wide stringbuf flag, they are latin-1 <rlb>With my current mess, ascii-only would be easier because the existing infrastructure will just work. Otherwise, I'll need a third stringbuf type, i.e. non-indexed utf-8. <wingo>but, if you are thinking of changing to utf-8, i think that's the sort of technically-incompatible-change-but-actually-is-fine <rlb>And we don't document latin-1 in the info pages, but I know that doesn't mean it's not a requirement :) <wingo>change to ascii only could be fine too <rlb>OK, well, prefer ascii-only, or unindexed utf-8 strongly either way? <rlb>The latter will be more complex code-wise. <rlb>i.e. we have to have two ways to handle all the relevant non-ascii operations. <rlb>(with or without an index) <rlb>I assumed the hard requirement would be if we considered non-ascii support part of the public SCM_IMMUTABLE* and SCM_*SYMBOL API. <rlb>(May be that non-ascii support would just be additional work, so perhaps I start without it...) <rlb>(Then I also don't have to be sure that adding another tag bit is ok -- seemed like maybe 0x1000 would be allowed, but wasn't positive yet.) <wingo>yeah i don't know what precisely the answer is <wingo>i suspect that if you need to limit to ascii that's fine. utf8 better if possible but not a requirement because the set of SCM_SYMBOL invocations is so limited <rlb>Asking because I'm starting the (less easily incremental) internal strings.c transformation now -- up to this point I was "just" revoking wide support from everything else while still using the current representations. <rlb>Right, inside guile wrt limited -- but didn't know about external code. <wingo>well just think that most of it dates from 1.6 days or earlier ;) <rlb>In any case, to support utf-8, I think we'd need either a third unindexed stringbuf type, or some "clever" way to compute the index during compilation (no idea how that would work). <wingo>the set of people taking advantage of latin1 but not utf8 for their symbols has to be like approximately nobody <wingo>i wish constexpr were a thing in c11 :P <rlb>I could also revoke/remove the whole thing if we don't think it's critical. <rlb>i.e. drop all the IMMUTABLE bits and move the initialization to runtime. <wingo>do you plan for any "external" string support <wingo>i.e. a string whose chars are accessible via pointer (not inline) <rlb>I also hadn't noticed the changes I may need to make to the compiler/tree-il/etc. until today -- probably for the best, since that might have decreased the chance I'd get this far :) <wingo>because they come from elsewhere. static chars could be an instance of this <wingo>most js engines have this. but they have so many string representations it is quite unwieldy <rlb>Not sure what you mean wrt external - do we do that now? <rlb>atm, everything will still bottom out in a strinbuf. <wingo>no we don't do that now, except that the immutable hack is a way to get inline chars where "elsewhere" is the static data section already <rlb>(fairly constrained by the various semantics we promise wrt immutable/copy-on-write/shared/etc.) <wingo>probably not worth thinking about. we don't want to introduce more string polymorphism :P <rlb>Yeah, I'm a bit concerned about trying to avoid having too many conditionals in the common path, though maybe that won't matter. And at least right now, the index and the "content" are all 'inline" in the heap object. <rlb>Oh, I also changed symbols to have a string rather than a strinbuf. Wondered if there's any reason that'd be a concern. It avoids symbols having to know as much about string internals, but I guess it does introduce one new indirection. <rlb>(pointer-wise, to get to the stringbuf) <rlb>But now symbols just rely on the string functions for the few operations they need. <rlb>Been trying to constrain the string api wrt the rest of the code where I can. <rlb>Also still no idea if this is all going to end in tears :) <rlb>It's "non trivial". If I'd know exactly how non-trivial before I started... :) <rlb>(That's a long chromium bug report.) <rlb>Oh, and one other minor thing -- I'd originally put the offset index first, then the chars in the layout, but while talking to a friend, we wondered if it might be better to put it at the end. Argument being that the head of the string will then always have better locality, and you don't always need the index? <wingo>ACTION pleased we don't have to support isolated surrogates <rlb>s/chars in/chars in,/ <rlb>(still wrong... :) ) <rlb>So what did you mean earlier wrt external strings. Did you mean that guile could use wrap string bytes it didn't "own" or something? <rlb>I guess we could, at least if the bytes were either static, or handled via libgc? <rlb>I suppose we'd need another stringbuf "type" (i.e. flag) and some adapters... <spk121>rlb: in 1.8 and before, scm_i_string_chars let you directly access string contents and scm_take_locale_string used a C string directly as an SCM string contents <spk121>scm_take_locale_string still is API but it doesn't let you directly use the C string anymore <rlb>And who freed the C string (and how)? <rlb>ACTION probably knew at some point, but has forgotten. <spk121>scm_take_locale_string meant that Guile was assuming responsibility for freeing, so the C string couldn't be static <spk121>But definitely don't do any of that. Take the hard line that internals are internal <rlb>wingo: I believe we'll still have direct access to the bytes, but they're currently just pointers into the stringbuf block. There's a helper that lets you via varargs ask for any number of pointers to offset chars in the string. <rlb>but only via scm_i_ functions of course <wingo>direct access to utf8 sounds useful <rlb>i.e. the srfis, etc. can use that. <rlb>Right - we never re-use content, mutations to a string end up swapping in a whole new (immutable) stringbuf. <rlb>for non-ascii -- ascii strings can still be mutable per-char. <rlb>(at least with what I have now) <rlb>since that's easy (and easier than anything else, and I assumed might help with the common cases) <rlb>Hah, I saw :) But haven't had a chance to look closely yet. <wingo>it seems to be better. i will make a branch to move guile over. the api is abstract enough to be implemented by bdw-gc <wingo>so we should have minimal risk. later we choose to use different algorithms. probably later we start depending on different algorithms but that is another question <wingo>anyway, i have been working on feature completeness recently. pending topics are (1) growable heaps, currently for evaluation you have to fix the heap size, this is just something to fix; (2) weak tables / ephemerons; (3) finalizers <wingo>currently working on (2) and hope to have something done soonish. <wingo>hopefully after all this we will be able to have guardians that preserve weak-table associations, something that has been broken since 1.8 :P <wingo>also things should be faster <daviid>Andronikos: both guile-gi and g-golf will let you use any lib of the 'GNOME stack' that is (GObject(Introspectable - in particular, it will also let you use and develop using libadwaita, which in turn will let you devlop so called 'convergent' application(s) <spk121>ArneBab: I would very much like to get back to that <spk121>Trying to update guile-ncurses on multiple platforms led to me trying to make Guile work on Win64. I've been playing with that <spk121>Is g-golf feature complete? I'm happy to keep working guile-gi, but, if g-golf is 100%, there's no point <spk121>but anyway, I have a Win64 Guile that works for me, so I'll put out that fork and a new guile-ncurses this week probably. Then I'll be free for other things <daviid>spk121: nearly, but i think g-golf handles 'more' then guile-gi 'already', VFunc full support, iiuc, this is not in guile-gi (?) <ArneBab>daviid: g-golf still says "pre alpha" on its website. Did that change? <Andronikos>Thanks. Will does run on Windows as well? Since I would program it on Linux but actually I need it to run on Windows. <spk121>Andronikos: which project are you asking about? Will Guile work on Windows? or g-golf? <daviid>ArneBab: no, not untill it is complete, and known bugs fixed <daviid>Andronikos: i actually fully depend on spk121's work <daviid>Andronikos: I meant to say, that (g-golf on ouindoze) would depend on spk121's work in making guile-3.0 'a thing' on ouindoze ... and probably your own investment to install the GNME libs, and possibly 'adjust' your code to what ever that environment constraints you to ... <daviid>ACTION identified and is about to fix a very important bug in g-golf, that crashe the all session upon being triggered <spk121>he means Windows, but, doesn't want to say it. It is a free software thing <spk121>But I'm already morally corrupted by my day job and am paid to do Microsoft stuff, so I can't claim any higher ground <daviid>Andronikos: if you try g-golf, make sure to install fro the source, and from the devel branch, it has tremendously important patches that i still have to merge to master <daviid>*from the source and checkout the devel branch ... <daviid>and don't feel ashamed to ask for help here, i am not the only one who can help, but i always do if no one else did 'shim in' <cow_2001>i watched a BBC bit about Infocom and their Interactive Fiction. turns out they used a specialised lisp for their stuff, compiled to some universal assembly running on specialised emulators, or something like that.