<zacts>so I guess I just realized that racket is actually another dialect / family of dialects that evolved from scheme <zacts>so it's not really scheme per se <taylanub>zacts: yes, AFAIK, in "racket" mode, Racket diverges from the Scheme standards, as opposed to just extending them in a compliant manner like most implementations do <b4283>ArneBab: sorry i just went offline after i said that ***cluck` is now known as cluck
<lamefun>Ie. why does it allow modifying lists returned by quote? <mark_weaver>lamefun: modifying literals leads to unspecified behavior, but guile 2.0 doesn't detect when you do it. <mark_weaver>please don't use pastebin.com, because it blocks tor users outright. <lamefun>If I try to do this with strings I get error, that the string is read-only, why aren't there read-only pairs? <wleslie>if you use codepad.org, it will run your guile code for you. it's an old version of guile, though. <mark_weaver>in our representation of pairs, we don't have any extra bits to spare <lamefun>can't you just extend it? for user-facing extension language, predictability > memory use. <mark_weaver>pairs use 2 words. we'd have to add another word just for that extra bit. <lamefun>mark_weaver: don't you have any spare bits in GC header? <wleslie>I'm sure that andy will at some point decide that x86_64 is really a 48-bit architecture and we may as well use those spare 32 bits <mark_weaver>lamefun: in guile 2.2, for compiled code loaded from a file, immutable pairs are put in read-only segments, so attempts to write to them will fail and segfault. <wleslie>if quoted lists get allocated into static, read-only memory, we might accidentally have read-only pairs for free when <mark_weaver>lamefun: in all other heap-allocated objects, the low bit of the first word is 1 <mark_weaver>so a pair is represented as a pointer to a block such that the low bit of the first word is 0 <mark_weaver>and Boehm GC, which we use to allocate these blocks, doesn't have per-block headers either <mark_weaver>blocks of the same size and "kind" are allocated together in pages, and there's a global table mapping these pages to their sizes and types. <lamefun>hm... does Scheme have undefined behavior at all? <mark_weaver>every time the standards say "is an error", that means the behavior is undefined <wleslie>evaluation order within an application is a well known one <paroneayea>the lack of definition in that in r5rs makes me wonder how much "r5rs cross-compatible" libraries would be if things ran in a not imperative-ish order <mark_weaver>attempting to modify literal data is an example of undefined behavior in scheme <mark_weaver>see the last paragraph of section 3.4 (Storage model) of R5RS <mark_weaver>and see section 1.3.2 (Error situations and unspecified behavior <mark_weaver>paroneayea: what do you mean by a "not imperative-ish order" ? <mark_weaver>the procedure+arguments of a procedure call are evaluated in an unspecified order, but their evaluation cannot be interleaved. <mark_weaver>(at least not in any way that could affect the result of the program) <paroneayea>mark_weaver: hearing other peoples' comments on this at another time, I began to get the impression that something like <paroneayea>might run in whatever order according to the spec (but I have not read it) <mark_weaver>in that example, there are three items to evaluate: 'something' '(foo 0)' and '(bar 1)' <paroneayea>which would seem like maybe some side effect heavy code might not work in the right order? <paroneayea>an imperative-ish version, I'd expect (foo 0), (bar 1), (something ...) <paroneayea>that's my experience with most imperative languages :) <mark_weaver>let's pick a slightly simpler example: ((foo 0) (bar 1)) <mark_weaver>either (foo 0) is completely evaluated before (bar 1), or the other way around. <mark_weaver>so it's safe for (foo 0) and (bar 1) to mutate the same data structure without locking, for example. <mark_weaver>in that example, the set! might happen before (foo a) and (bar a) are evaluated, or after both, or in between. the order could be different each time that code is run. <paroneayea>but a (begin) has a set order obviously right :) <paroneayea>I'm not crazy in that I expect l->r there right ;) <mark_weaver>also, in procedure calls, the procedure+arguments are all evaluated before the procedure is called. <paroneayea>though I've hit it enough, I assume it's when nothing is returned explicitly though <mark_weaver>there's a special value SCM_UNDEFINED that has two purposes: when stored in the value slot of a variable object, it means that the variable is not actually bound <mark_weaver>and when a Scheme procedure with optional arguments is defined in C, SCM_UNDEFINED is what you pass to that C function to mean "this argument was omitted" <mark_weaver>it might have some other marginal uses, but those are the two major ones I know of. <mark_weaver>you see, if you bind a variable 'foo' in a module, and then unset that variable, the variable object stays around but gets this special SCM_UNDEFINED value stored in it. <mark_weaver>the reason the object stays around is because, as an optimization, when code accesses a top-level variable, the pointer to that variable object gets cached. <mark_weaver>that optimization greatly improves the performance of top-level variable accesses. <mark_weaver>paroneayea: (if #f 'blah) returns #<unspecified>, which is different <paroneayea>mark_weaver knows all the things! (and I really don't :)) <mark_weaver>I know a fair bit, but not all the things. wingo knows lots about guile that I don't <lloda>ot, how do I get back to emacs mode when I accidentally press the vi-mode key in the repl <civodul>maybe "info readline" has the answer <lloda>I don't really know. I only ever press it by accident. I hate it. <lloda>ok, so info readline says it's C-e, but that doesn't work :-( I just get '^E'. <civodul>it works in the emacs->vi direction for me, but not the other way around <civodul>contrary to what the "Readline vi mode" node says <civodul>interestingly C-M-j doesn't work at all in Bash <civodul>lloda: oh it's C-M-j for emacs->vi, and then C-e for vi->emacs while in command mode <civodul>now you need to send 'em a doc patch :-) <lloda>thanks civodul, I missed that C-e only worked in 'command mode'. So I needed to do ESC C-e :p <lloda>however I don't see the error in the doc. I just failed to read it. *ArneBab_ will be AFK till tuesday <davexunit>wingo: I was reading the backlog for #guix and saw what you mentioned about Clojure's transients and a feature that will land in Guile master. <davexunit>if you get a chance, could you elaborate just a bit about it? <davexunit>people are very attracted to Clojure's persistent data structures <wingo>davexunit: have you looked at intmaps yet? <davexunit>I haven't had a chance yet. I was under the impression that they were just an internal, private data structure for the compiler. <wingo>they're internal but not really compiler-specific <wingo>as long as they are in the compiler module tree i feel free to change their interface <wingo>and i'm adding a transient interface to them <wingo>or at least i was until my new laptop arrived ;) <davexunit>wingo: will the module become a public one anytime soon? <davexunit>vlists/vhashes are cool, but Clojure's persistent vectors and hashes seem to be better. <wingo>intmaps with transients will not have threading issues <davexunit>would be nice to direct analogs to what Clojure has so I can point to it when people familiar with Clojure look at Guile. <wingo>so intmaps are like clojure's vectors <mark_weaver>I would be keen to important several ideas and data structures from clojure <wingo>and they have a facility for being used as sets <wingo>intsets are similar but for bit sets <wingo>a generic HAMT facility like clojure's PersistentHashMap would be very, very nice. <wingo>racket recently redid their functional maps to be based on HAMTs <wingo>cue the conversation topic of yesterday :) <davexunit>working on Sly has made me really desire a better persistent vector type <wingo>davexunit: what are your keys? <davexunit>a persistent hash map would be great, too, to replace large alists. <wingo>i'll let you know when this transient stuff lands <davexunit>but most of the time for me, I'm modeling grid-based games <davexunit>2D tile-based things. since I'm doing the "functional reactive" thing, persistent data is a must. <wingo>davexunit: how many elements does a typical vector contain <davexunit>wingo: it all depends on the game, but for anything nontrivial it's easy to get to hundreds or thousands <wingo>clojures persistent vectors are better optimized for packed vectors, and for appending to those vectors <wingo>hundreds or thousands is fine <wingo>hundreds of thousands can be a challenge but the data structure is fine <davexunit>a tile-based world map would be mostly static. <davexunit>but I'm also trying to deal with highly dynamic things, like thousands of moving objects. <davexunit>but that will likely involve additional clever solutions <wingo>well intmaps are 32-way branching tries <wingo>so an update to a "thousands"-element vector would mean allocating three 32-element vectors <wingo>if you use the persistent interface <wingo>if you can use the transient interface of course there would be no allocation <wingo>oftentimes you can use the transient interface, too <wingo>just grab a snapshot when you need with (persistent-intmap foo) <wingo>and then then next time you do an (intmap-add! foo ...) it will re-clone the parts that need to be updated <wingo>and leave the other parts alone <davexunit>I have to familiarize myself with this concept <davexunit>I can't quite tell if I'd be able to use that technique <davexunit>sometimes I think I'm silly for doing all of this work just to make a silly old-school "bullet hell" shooting game <wingo>yeah but structuring your game update as a fold is a real pleasure :) <davexunit>if I were using C or something, I'd just have a simple array of structs and would mutate the hell out of it. <davexunit>wingo: yes, it is. thus far, I've written minesweeper and 2048 in that style. <davexunit>it feels really good. I didn't know about functional programming many years ago, but this sort of thing is how I imagined game programming was like. <paroneayea>oooh, we might get more immutable structures in guile??? <davexunit>"If a pure function mutates some local data in order to produce an immutable return value, is that ok?" <paroneayea>I'm using vhashes in opstimal, and they work, but I'd love something where changing a key doesn't just keep the old key :) *paroneayea sees the vhash grow and grow ;) <mark_weaver>paroneayea: yeah, I've had that problem too. really we need a nice fast HAMT implementation <davexunit>I had this sort of thought when I read the implementation of 'memoize' in guix <davexunit>memoized functions are still pure, despite a mutable hash table being used to cache values <davexunit>I put that in the "functional runtime" category that Haskelly folks mention from time to time. <davexunit>it's just, for us, we build our own functional runtime in the same language. *ijp challenges davexunit to a fiddle contest for his soul *davexunit moves to Georgia <davexunit>ijp: we were just talking about the need for a "nice fast HAMT implementation" <ijp>mine could do with some optimisation, I never did any real benchmarking <davexunit>the important thing is that you have already written a solid implemenation of HAMTs <davexunit>that perhaps could be brought into Guile core and optimized? <ijp>I have no problem with it being in Guile, but at the same time, I'd prefer if as much of the optimisations could be kept implementation neutral <zanta>Can someone help me? i can't seem to make guile-gtk, it errors out. <zanta>guile-gtk.c:31:22: fatal error: guile/gh.h: No such file or directory <daviid>zanta: guile-gtk is not used/supported since many many years. you should cosider installing guile-gnome instead, which has a (gnome gtk) module, among many others <davexunit>zanta: looks like that library hasn't been updated in many many years <zanta>I'll look for it in the AUR, if not, install it manually. <daviid>zanta: installing guile-gnome is not a piece of cake actually, you should install manually <davexunit>daviid: how goes guile-gnome? I haven't yet had a chance to look at it <davexunit>(I've barely ever done any gnome programming) <zanta>seems out of date in the aur, ill go to the site <daviid>zanta: what guild version are you using <daviid>davexunit: the devel branch is ready for relaesaing 2.16.3, i have yet o find out the distcheck problem, but right now busy with something else <daviid>zanta: perfect. you should install, manually, from git, guile-cairo, then g-wrap, then guile-gnome [all these from git] <daviid>then ./autogen.sh --prefix=/opt [for example], ./configure --prefix=/opt, make, make install <davexunit>zanta: daviid has been working hard on GNOME bindings, but they haven't been officially released yet. <zanta>Where can i find the git repo? <daviid>davexunit: but as a all, guile-gnome is binding rather old version of gnome... <daviid>zanta: look foe guile-gnome, then the developer page <daviid>davexunit: yes, we will get there, nd the good news is it copiles with guile-2.2 as well [i checked with 2.1 of course] <daviid>davexunit: i've been slow because i neede to learn so many things while doing... <daviid>zanta: don't forget to git clone all <daviid>you won't be able to make with the tarbals, they are out of date <davexunit>daviid: don't feel bad about slowness. it's good work. <davexunit>I've been working on a game engine for years and haven't released 0.1 yet. <daviid>zanta: web pages are out of date, but relax and it will be easier once you have git clones because then you'll just git pull for future releases... <daviid>here the clone cmd for guile-caro: <zanta>Thank you for being so helpful <daviid>git clone git://git.savannah.nongnu.org/guile-cairo.git <daviid>./autogen.sh --prefix= [your favorite prefix here, no space after the =] <daviid>try to build guile-cairo first, end let me know <zanta>Should I mkdir before i clone it? <zanta>Will it clone to ~/ if i do it from therE? <daviid>yuu'll need the devel cairo lib packages of course <daviid>zanta: as yu wish, you can do that in your home dir, or /usr/local/src ... <daviid>ok, i'm on debian so i can't tell you the exact name of the lib packages <daviid>here is what i have here: libcairo2-dev <zanta>I dont understand the point of the prefix? <daviid>it is the directory under which everything will be installed, for example, /opt, or /usr/local are common options [i prefer /opt but again, matter of taste] <daviid>it is called prefix because the system will organize things acording to gnu coding standard 'rules', so below the prefix, /opt in my exmple, it will create and/or fill things as approrpiate, for example /opt/share/guile-gnome-2 ... <daviid>zanta: you should have a /opt directory on your system right? <daviid>yes, of course you need write access to /opt <daviid>you can install the documentation as well: make install-html <daviid>perfect! the we do the same with g-wrap <daviid>git clone git://git.sv.gnu.org/g-wrap.git <zanta>okay, I did that and ./configure, but make failed <zanta>g-wrap.texi:1160: raising the section level of @subsection which is too low Makefile:438: recipe for target 'g-wrap.info' failed <daviid>zanta, be right back, hold on :) <daviid>zanta: this was to clean the attempt, now, please do this: <daviid>then yu try autogen, configure and make again <zanta>Holy crap, you are a wizard. <zanta>Can you explain why that fixed it? <daviid>i will but let's compile guile-gnome now <daviid>git clone git://git.sv.gnu.org/guile-gnome.git <daviid>then i also suggest you checkout the devel branch <daviid>then the autogen, configure, make dance ... <zanta>fatal: A branch named 'devel' already exists. <daviid>ah it wold be with ; but don't do it :) <zanta>No package 'g-wrap-2.0-guile' found <daviid>could you list the content: /opt/share/aclocal <daviid>g-wrap-2.0-guile.pc should be there right ? <zanta> ls -a /opt/lib/pkgconfig/ \\. .. guile-cairo.pc <daviid>that would mean you did not use the /opt prefix while autogen, configure g-wrap ? <daviid>then something went wrong while making g-wrap or make install <daviid>go back to your g-wrap directory ***dje is now known as xdje
***siel_ is now known as siel
<zanta>I went back and installed it <daviid>export ACLOCAL_FLAGS="-I /opt/share/aclocal";export LD_LIBRARY_PATH=/opt/lib:/usr/lib:/lib;export PKG_CONFIG_PATH=/opt/lib/pkgconfig:/usr/lib/pkgconfig <daviid>try echo each of these variable to check <daviid>ok i guess the others are ok as well <daviid>scrolling up, there is line which says what wrappers will be built <daviid>the output of the configure is verbose, scroll up until you see this line: <daviid>All available wrappers will be built: <daviid> atk cairo corba gconf glib gnome-vfs gtk libglade libgnome libgnomecanvas libgnomeui pango <daviid>this is in my case, let's see yours :) <zanta>atk cairo corba gconf glib gnome-vfs gtk libglade libgnome libgnomecanvas libgnomeui pango <zanta>it is giving me a beautiful show <daviid>great! ready to hack!! examples are in the git clone directory here: <daviid>gtk/examples _but_ be aware that some [quite a lot actually :)] won't work :(:( some will ... this because they are very old and nobody hacked them for new version, neiterh I , i have too much to do <daviid>this said some work, try from there <zanta>I am trying to learn as much as possible right now, for GSOC. Asked me to make a quick program, let's see what I can do <zanta>daviid: That's really sad :( <daviid>this an app entirely writen using guile and guile-gnome <zanta>is emacs the best environment for guile? <ijp>emacs is the best everything <ijp>54.5 out of 10,000 neckbeards can't be wrong <daviid>zanta: try this to see which of the examples still run: <zanta>Wrong question to ask in a irc of lispers hehe <daviid>cd ~/gtk/examples/guile-gtk-demo; ./guile-gtk-demo.scm <ijp>some of you will have noticed that this is only 0.545% <daviid>some will crash, start again and try all until you know which work... <zanta>./guile-gtk-demo.scm: line 3: exec: guile-gnome-2: not found <daviid>zanta: add /opt/bin to yur PATH env var