<ijp>hmmmmm, (make-struct (make-vtable "") 0) (struct-ref $25 0) <unnamed port>:35:0: <unnamed port>:35:0: In procedure struct-ref: unrecognized field type: #\\nul <ijp>not a great error message <kristofer>I keep running into this "unknown character name" while trying to use davexunit module (guix web sxml) -- is it a locale issue? maybe it's guix and I should update to the latest guile? Historically it has worked, but I haven't tinkered with it in some time <ijp>I expect it is a locale issue, but do you have an example? <kristofer>it's not every character. I have most of them commented out to work though <ijp>davexunit: btw "The owner of git.dthompson.us has configured their web site improperly." <ijp>kristofer: have you tried doing a setlocale in your program? <ijp>just give it the empty string <ijp>first argument LC_ALL <cheim_>davexunit: Does your website have a .onion address? <cheim_>I want to check out Chickadee but the security certificate is expired <roelj>Is there a way to run (mkdir "...") without mkdir throwing an error when the directory already exists? <roelj>Oh I see.. with a (catch ...) <civodul>yeah catch 'system-error' and then check for ENOENT <ijp>hmm, I didn't realise that I actually had enough to make amb work <ijp>why are vm builtins (apply, callcc, etc.) handled that way? backwards compatibility <ijp>specifically they index into an array of builtins <ijp>it seems weird that you can end up with a vm primitive builtin-ref, which you index into to get an array of vm ops, which might just do args checking then call a special vm op for that builtin <ijp>e.g. builtin-ref -> vm_builtin_call_with_current_continuation -> call_cc <ijp>so, since structs were making me crazy, I've been trying to implement the dynamic stack...which will drive me crazy <ijp>I'm a little concerned about how to handle it if continuations are captured in the winders for dynamic-wind <ijp>I'm not sure how common that is, but I don't think I can give correct behaviour for it in Javascript <davexunit>cheim_: sorry, it doesn't. I tried to renew certificates multiple times but failed every time. <davexunit>but you could ignore the expired cert and view the pages <Muto>Does anyone know if Haunt is compatible with Skribilo? or just Skribe? Not sure if I should be asking this on another channel... <Muto>OrangeShark: Okay, thank you for the answer! <ijp>I'm not sure I understand what makes a struct a vtable <ijp>but except for struct-vtable? I seem to be getting the right answers <ArneBab_>wingo: thank you for your article! It’s a nice read (I like your boldness in jumping to the emacs-shell motivation without any intro — and it worked) <ijp>I've just pushed structs and dynamic-wind support to my branch. <ijp>teasing out the logical commits from my boot stuff is tricky <acapulto>Excuse me, but I hesitate between record type and class. I don't know which one is best, any ideas ? <acapulto>It is to implement a binary tree. My first pick is Objects because of the genericity and it is easier to extend. <ijp>classes aren't really classes in the OO sense <acapulto>The issue is it allows to have a easier to extend code. <acapulto>Instead of writing (bst-find tree), we can write (find bst-tree) <acapulto>thus I am very hesitating between the two. <catonano>acapulto: there's a debate among schemers about object systems. The general wisdom is that polymorphism is good. Mutation in place is bad <catonano>acapulto: paroneayea mentioned some mechanism to make class instances immutable in some Lisp based object systems <ijp>my own personal opinion is that generic function based object systems are a huge mistake and should be avoided <acapulto>catonano: I don't want to use setter for classes (actually is there any equivalent to define-immutable-record ?) <catonano>acapulto: AND he implemented is own polymorphism frameworkk for a proect he is working on, because the vanilla GOOPS was not good enough for him <catonano>acapulto: I don't know, I'm just reporting what I know. You might want to ask paroneayea <acapulto>But Ad hoc polymorphism is a neat feature. For creating a BST tree, we need to overload the "<=" operator. <catonano>ijp: I'd like to know youurr opinion better <catonano>what do you mean with "generic function based" ? Are you thinking of some object system that is not generic function based ? <catonano>I have to catch an exception in my guile-freexl thing and I want to ask: is it better touse Guile Exceptions or is it better to use srfi-34 and srfi-5 ? <ijp>rather than fretting so much, just pick one <ijp>catonano: as short as possible: aside from the common confusions regarding how generic interact with the module system, the function is the wrong level of granularity for most interfaces, and basing your notions of polymorphism around names rather than functionality is about as unschemely as it is possible to be <ijp>catonano: how portable are you trying to be? <ijp>also note that guile does not support srfi 5 <spk121>The debate around OO does show how the versatility of Scheme/Lisp makes communal hacking difficult. Everyone always believes everyone else is doing it wrong. Sometimes language limitations are good for progress. :-) <OrangeShark>the generic functions can work on types other than GOOPS classes, right? <amz3>spk121: +1, but it's not forbiden to explore "new" ideas <OrangeShark>daviid: so then acapulto can use records, not really required to use GOOPS? <daviid>OrangeShark: I have to read the log :), sorry I just pulled in but don't have the background of the conversation <OrangeShark>daviid: oh sorry, acapulto wanted to use records or classes, but wasn't sure which to use. A plus for them was generic functions for GOOPS, but that isn't restricted to only classes. <daviid>if he/she does not need inheritance, and if the project is likely nt to have to be later extended (using inheritance precisely), then better use record yes <daviid>and I have a diferent opinin then ijp on this, generic function based object system, invented precisely to avoid all problems raised by all other oops, are the only ones you want to use, other oop systems are just a ile of design (and there fore user code) disasters :) <spk121>As a silly aside, I'd been working on a goops class with methods, but, I've been converting methods back into simple procedures because they look better in the backtrace, at least for 2.0.x. <acapulto>daviid: Actually, I started to hesitate when I looked at the Haskell BSTs. Haskell uses "deriving" and I wanted to have such a nice thing in Guile. It allows to implement the tree without providing a lesser function to every tree functions, or to use a macro for defining the function. <acapulto>* I mean : It avoids using a macro that would change "<=" to "my-type-<=". <daviid>spk121: you mean you had problems to debug your code ? <daviid>acapulto: git it a go and see, just as ijp said, pick one and try... <daviid>acapulto: from what you wrote earlier in the log I would try using goops <paroneayea>generic methods are great for many things, but not all things, whether you use GOOPS or not. GOOPS is a pretty reasonable choice for a lot of things; if things are really performance critical, use srfi-9 records <paroneayea>I used to be a GOOPS skeptic, but now I'm pretty happy with usage in a number of places. And fwiw the reason I have a generic methods system that *doesn't* use GOOPS is because I wrote a wrapper for linked data systems, where an object may have more than one type, and GOOPS doesn't support that nicely. <paroneayea>but, explore different mechanisms; I don't think GOOPS is always a good fit. But I think sometimes people end up in analysis paralysis given the many options available in Guile <paroneayea>pick something, and you can refactor later if need be to try something else <spk121>daviid: Yes. In a backtrace, usually simple procedures show up in the stack. But goops class methods don't always appear in a backtrace. They'll appear as ***dsmith-w` is now known as dsmith-work
<rekado>paroneayea: do you have any recommendations on documentation for GOOPS? Does it make sense to read about CLOS first, or are the Guile manual and the sources sufficient to learn enough about it? <rekado>in the past I often encountered claims about how CLOS is so much better than other object systems, but having read the GOOPS docs I still don’t get what’s special about this kind of thing. <rekado>(compared to e.g. the object system in Ruby) <daviid>rekado: I would recommend to start reading a clos tutorial <paroneayea>rekado: there are various books you could read, but let me give you my summary of what I find compelling about GOOPS <paroneayea>(and, I do agree that CLOS has some better things, but GOOPS is still quite good) <cmaloney>(for those of us playing along at home, what is GOOPS / CLOS?" <daviid>cmaloney: read the tutorial I pasted above... :) <paroneayea>cmaloney: GOOPS is an object oriented programming along the lines of CLOS in Guile, and CLOS is the Common Lisp Object System, an influential "meta-object programming" system <rekado>cmaloney: CLOS = Common Lisp Object System <paroneayea>1) have you ever done any live hacking in guile, and you redefine your record types, and all the stuff you were playing with breaks? GOOPS is designed to embrace live programming <random-nick>I'm pretty sure that the clos specification doesn't actually specify the MOP <daviid>the MOP is at the heart of the design of CLOS <paroneayea>I'm actually changing the functionality of the actors as the program runs <paroneayea>which was great here because I had players connected and giving feedback, and I didn't want to shut down and restart the server while hacking. <catonano>paroneayea: wonderful. Smalltalk was like this <random-nick>I thought the MOP was an implementation-specific thing <rekado>(I rarely even use records. I mostly just use alists…) <rekado>but that sounds already quite useful <paroneayea>now, ijp clearly disagrees, and so do some others ;) <paroneayea>but here's why I think generic methods are great: <rekado>(I’m a big fan of generic everything) <paroneayea> - one easy example, as shown in SICP, is an algebraic system; Scheme has the ability to add together and manipulate many types of numbers right? It's nice that you can do (+ 1 2.5) and not (integer-and-float-+ 1 2.5) <paroneayea>and composing together a ton of things, that's nice <paroneayea> - you can imagine that with a game also, maybe you have some way to be able to get a certain number of coins when you defeat an enemy, and it would be nice to be able to add a (get-coins <foo>) to anything, even if you have a diverse number of "types" of things you might get them from <paroneayea>one thing that is a problem in ruby/python/java/etc though <paroneayea>is you start "fusing" a *ton* of objects to the side of your classes <cmaloney>Or set the disposition of an AI between (-1 and 1) <paroneayea>well what if you add the get_coins() functionality later, right <paroneayea>now you need to go and update all your classes to which it applies <paroneayea>and maybe even you're adding functionality to types that came from a different library <paroneayea>you might not even be able to fuse new methods to the side of them <paroneayea>you just define a new library and start saying how it applies to various types. <rekado>(Ruby has “mixins” for this kind of use case) <paroneayea>rekado: ah but mixins means you have to tweak the class heirarchy for that kind of adding of functionality <daviid>random-nick: section 28.1.8 of cltl2 ... The meta-object protocol specifies a set of generic functions defined by methods on classes ... <paroneayea>you don't *have* to start futzing with a class heirarchy to add functionality with generics <cmaloney>ACTION sits cross-legged at the feet of the teachers <paroneayea>3) inheritance! it's much maligned in many places, and "deep" inheritance, especially anything with multiple inheritance that invokes the "deadly diamond" can become really nasty <paroneayea>however I find that sometimes inheritance is useful... you don't want too much of it <paroneayea>but shallow inheritance is sometimes pretty good, and I found when avoiding GOOPS I frequently ended up implementing my own inheritance systems at times even when I didn't want to <paroneayea>I think that components are better than inheritance when it works <paroneayea>it's there if you need it, but because of generic methods <paroneayea>now, where I think GOOPS is especially maligned in Guile-land is because it "encourages an imperative style"... and there I think people especially mean mutation <paroneayea>mutation is usually bad but sometimes ok if you're really careful, but anyway <daviid>it does not encourage an imperative style <paroneayea>you don't *have to* do mutation when using GOOPS <paroneayea>see also the clone macro ArneBab_ and I worked on and sent to the list <paroneayea>which is, in interface, not *too* far from (srfi srfi-9 gnu)'s design <paroneayea>granted my clone implementation was probably not the most efficient implementation :) <paroneayea>anyway, it's also nice that getters and accessors are themselves generics, and there's a deep dive of meta-object-protocol magic that I think is neat but I've never gotten deeply into <cmaloney>pardon the ignorance, but isn't this akin to how JavaScript bolts OO onto itself? <paroneayea>it just has objects that have a prototype of how to be defined <cmaloney>eh, it sort of does, but it's really wonky <paroneayea>I think it would be a lot harder to write a generics system along the line of goops' in javascript <paroneayea>cmaloney: the whole manual or the GOOPS part? :) <cmaloney>All of it. I think GOOPS is separate right? <cmaloney>Because thank you. This manual is SO READABLE <paroneayea>the GOOPS part I think was mostly lifted from its tiny-clos predecessor and then mutated to whatever degree to the fit of Guile <rekado>(except for the sxml part and the missing match things; a bit spotty) <paroneayea>but the live hacking and generic methods aspects keep bringing me back <daviid>the manual is almost an entire copy of the stklos manual <rekado>paroneayea: these two things do sound very appealing to me, too. <paroneayea>I've written several projects recently where I said "I'm not going to use GOOPS!" and later I found my code was way shorter by rewriting in GOOPS. And I didn't use mutation in either example. <cmaloney>paroneayea: Also: next time I see you whine about impostor syndrome I'm totally bringing up this log. :) <daviid>minus atiny syntax diff between stklos and goops <paroneayea>the two other CLOS style books that I think are well regarded are: <paroneayea>"Object Oriented Programming in Common Lisp" by Sonya E. Keene <paroneayea>and the former of those two books is maybe a bit heavy on mutation, but does say some things that made me think about style. <paroneayea>the latter is really how to implement a CLOS-like system using the meta-object protocol <paroneayea>rekado: you're welcome and glad you found it helpful <paroneayea>I inherited an anti-GOOPS attitude early on from this channel, and it wasn't until I took some time to work through some things using various structures that I decided that I actually liked it quite a bit <cmaloney>I'm finding with my programs that I'm making a lot more globals than I would like <cmaloney>(and maybe this is me not understanding things) <cmaloney>but trying to keep state for a game is challenging <cmaloney>partially because other things keep taking precedence <cmaloney>but will put it more to the top of the pile <cmaloney>I will say I'm guilty of making Python objects that are little more than handy global containers. ;) <paroneayea>I still think Sly's reactive approach to avoiding any mutation is still a very appealing direction! <rekado>what do you think of “The Land of Lisp” or “Realm of Racket” for game programming insights? <daviid>20 pages only: CLOS: Integrating Object-Oriented and Functional Programming <cmaloney>rekado: I'm working through Realm of Racket right now <rekado>daviid: thanks for that one too! <paroneayea>rekado: I found Land of Lisp to be really inspiring but I was also very new to Lisp then... it doesn't really model things in a way that's realistic for writing games though <daviid>rekado: writen by among the best s/w engineers that planet has ever had ... <cmaloney>I think the examples in Realm of Racket are superior as they take advantage of graphical interfaces <paroneayea>rekado: it's a fun book to read and pick up, but at your stage I'm not sure it would be as useful <cmaloney>The first chapter of Realm of Racket / Land of Lisp are pretty identical <paroneayea>though the section on lazy game trees is pretty cool <rekado>I found Realm of Racket a bit … frustrating(?) because I couldn’t tell if the authors really knew what they were doing. I always had the impression that they said “We’re doing this for the first time, but this works for us” <paroneayea>rekado: it was written "by students for students" <rekado>that’s probably really unfair of me to write this <rekado>but that was the feeling I had throughout <cmaloney>yeah, there's 6 freshmen students listed in the credits <cmaloney>They also rely heavily on the helpdesk to explain more <paroneayea>btw if you want to see someone go crazy with CLOS and games <cmaloney>so if you're not running DrRacket you're missing out on half of what they're explaining <rekado>I felt safer safer with Land of Lisp, but it was very heavy on mutation, which was hard to swallow. <paroneayea>rekado: yeah, I think it was a book about learning general concepts in Common Lisp <rekado>(I had just come from Haskell when I read it. Loved the cartoons.) <paroneayea>because that's the book where I first understood what functional programming meant <paroneayea>as opposed to staring at wikipedia pages for some time and being like ??? <random-nick>guile really needs a tutorial for people coming from C <rekado>the best part of the book was …not even part of the book; for me the best is that catchy, silly song <cmaloney>paroneayea: heh. I tried looking at Wikipedia for Y Combinator and Lambda Calculus <dsmith-work>IIRC, Neil Jerram (neiljerram here) did a huge rewrite of the Guile manual a while back. <cmaloney>I think I could have better used that time looking at a hex dump <dsmith-work>GOOPS was originally an add on package. Some of the original goops manual came from something else. clos or stklos or something. <daviid>dsmith-work: stklos, I just pasted the link above... <dsmith-work>I didn't read through the whole log. Sorry about that. <daviid>dsmith-work: goops implementation also started with the stklos source code ... not just the manual <daviid>or 15y maybe, anyway a long time ago ... <dsmith-work>I've only looked at a very small amount of cl code, but it seems to me that CLOS is much more deeply embedded into lisp that goops in in guile. <dsmith-work>1. It's wired into the infrastructure at a very deep level. <paroneayea>dsmith-work: if by lisp you mean Common Lisp, maybe :) <random-nick>hm, I wonder if it would be possible to build a common lisp compiler for guile <daviid>dsmith-work: this is a wrong debate imo, an oop system does not have to be scheme or lispy, it has to be good :) and the best is clos, goops is almost as good (the reason it is not is precisely due to terrible mistakes, in the past, to 'make it schemy', but it got a lot better with the recent corrections of old bugs, and as it is, there are ways to make it work as clos, almost)