<wingo>sneek: later tell TMM cool :) <dsmith-work>wingo: net_db.c:468:***Missing or erroneous `#define FUNC_NAME s_AI_ADDRCONFIG);' <dsmith-work>Change the regex from /^SCM_DEFINE/ to not match SCM_DEFINE_CONSTANT <wingo>lots of those things that should be fixed :P <dsmith-work>wingo: I'd send a patch but I'm over my 10 line limit. <wingo>there are other SCM_DEFINE things like SCM_DEFINE_PUBLIC etc <wingo>i will take a look, sending an email is best tho :) <dsmith-work>That match sets up checking for FUNC_NAME, so oonly should match "functions" <wingo>i wonder with the new racket-on-chez how much room there is for guile-on-racket or racket-on-guile etc <wingo>probably a considerable amount regardless! <paroneayea>wingo: seems like a big rewrite to get guile-on-{other-scheme} probably still, right? <wingo>trickiest part is the module system i think. but our module system should at some point look more like racket's <wingo>the rest of it is easy peasy scheme shims around whatever the host scheme offers <wingo>js is important too somehow! <avoine>wingo: yeah, with webassembly coming, we could have a bytecode backend for it <wingo>only thing is with wasm as it stands is that there's no gc <paroneayea>just run gdw-gc through emscripten and we get a gc, bam, like magic right? ;) <wingo>some projects actually do that :) <davexunit_>if we did guile-on-racket or some other scheme, what is the point of guile? why not just use racket? <wingo>so firstly that argument works for any $racket <wingo>secondly guile-on-$racket doesn't preclude guile <wingo>like pypy and cpython are both used. <wingo>for similar reasons as cpython existing libguile will approximately always exist <wingo>then we go to more serious questions -- what's the essential difference? <wingo>i honestly think there is no essential difference. it's just accidental. (these accidents are important and reconciling them is not cheap) <wingo>between guile and racket concretely i mean <wingo>you can imagine a world in which guile and racket are the same -- it's a better world, right? <wingo>i mean, more good hackers learning from each other and working together <wingo>making free software, making scheme. <wingo>it's a little less gnu-centered so as gnu hackers there would be challenges <wingo>and racket has some specific approaches to modules that we don't have -- phases/staging etc <daviid>goops is an essential diff with racket <wingo>yeah goops too; there was another goopsy project in racket but it's not a current thing <paroneayea>but could surely be written on a guile-racket or whatevs right? <wingo>afaiu it being pushed out actually pushed out one of racket's core contributors <wingo>yeah. yeah so right now today you can implement racket in guile and the reverse <paroneayea>live hacking in guile is my main motivator for using it <wingo>racket has a mutable toplevel if you know the right 'unsafe' incantations <davexunit_>if a merger with racket is seen as a good end goal then it's a bit disappointing to have been working with guile all these years. <wingo>and i'm not saying that a merger with racket is _the_ end goal. only saying that there's a world, close to this one, in which we can work together better and be more effective <amz3>that said, competition is good somehow <wingo>personally i want to compete with chez :) <daviid>ACTION is compiling master to see of goops latest fixes (thanks wingo!) actually fixes guile-gnome <wingo>paroneayea: oh yes of course! <wingo>we need to steal more of their code <amz3>also guile is small that is also a nice aspect of it <wingo>davexunit_: honest question: why? :) <amz3>it seems to me racket is much bigger, and much more less approcheable... somehow... <davexunit_>"the top level is dead" is very unlike what I think scheme should be <paroneayea>I feel like if Guile is going to be the de-facto underlying system for something, it would be nice if we were free from C ourselves, or at least bootstrappable (a-la mes) <wingo>i really admire matthew flatt in many ways, and one is his willingness to rebase his work on a better now-open-source VM <paroneayea>davexunit_: yeah you and I are echoing the same thing there :) <wingo>davexunit_: i think it wasn't "dead", it was "hopeless" i think :) <davexunit_>hmm maybe, I don't know where the source of the quote is so you could be right. <davexunit_>racketeers just seem to have a different philosophy that runs against the "emacs thesis" <wingo>paroneayea: over time our amount of C will go down, eventually to a level where we will say "this is OK and to port Guile, just reimplement these bits in JS/whatever" <paroneayea>wingo: as long as you aren't saying, let's run Guile on v8 ;) <wingo>it's not a really great target, unless tail recursion is embraced there <wingo>but it is widely deployed, and in the sense that we should be able to run guile in a browser then totally yes, let's run guile in v8! <wingo>dunno. i try to think of what stick-in-the-mud ideas i have that i should just throw away <paroneayea>what I think you're saying wingo, and what seems to be a good idea to me, in the reading I'm having <wingo>is guile one of those? i think probably not for me, i like working on the vm, and i like bringing guile programmers closer to contemporary ways of programming that avoid past mistakes <paroneayea>is for racket-on-guile, a) well, Guile's VM should be so good that it's as good a target as Chez for something like Racket <wingo>but maybe i could be spending my efforts better elsewhere? always a question. <wingo>still guile is a good space for me :) <paroneayea>and b) our interface of what guile's vm is built on should be generic enough that we can find what to bind it to as in terms of the best fit whether it's racket or C or v8 or what :) <wingo>(a) yes and (b) mmmm somehow <wingo>(b) i mean, what is guile, is it the vm? less that than the body of programmers and programs built on it. <wingo>some of those programs are C, most are Scheme at this point <wingo>we have a duty to convert the former to the latter :) <wingo>so in a world in which Guile is just a dialect of Scheme, if you are not implementing C bindings or whatever then your Scheme can be implemented in many ways <wingo>on chez, on racket, whatever. <wingo>that's part of where racket is going -- a multi-vm language <wingo>like java, if i dare to say it ;) <wingo>pycket, chez, racket's C implementation now, etc <amz3>I didn't knew about racket-on-chez <wingo>yeah interesting thing isn't it! <amz3>yeah they have the bandwidth to do that kind of stuff <wingo>so another thing, i think gnu is often very backward-looking. it would be nice if gnu as a community of people who care about software and user freedom were able to experiment more and absorb more change ***rokf_ is now known as rokf
<wingo>that is another thing i admire out of racket folks which i would like gnu to learn from <wingo>amz3: not sure yo -- that is just one person <wingo>they don't essentially have more vm bandwidth than we do. <amz3>they don't have more maitainers? <wingo>they have more maintainers but from a VM POV it's just mflatt. <wingo>(racket folks who are in the room will correct me I hope.) <amz3>I understand why it's a good question <davexunit_>there are plenty of stick-in-the-mud GNU folks (one of my big frustrations when I was paid to deal with them at FSF) but in Guile land I haven't experienced that. <amz3>yeah there is the debbugs stuff for instance <wingo>i think there are things that we don't even let ourselves do or think because of a kind of fear of change <amz3>but I grew to like debbugs somehow. <wingo>amz3: ah i like debbugs tbh :) <wingo>maybe that's one instance :) <amz3>that said, seeing the numerous pull request of CPython on github is nice <wingo>even when i don't like the balance between pr submitter and reviewer on gh in general <wingo>it is nice to be able to comment on specific things <mthl>wingo: you mean like with inline patch comments? ;) <wingo>mthl: yes that's fine but i dunno, my email workflow is different :) <wingo>i am sure that is just a personal problem tho :) <wingo>i will say that it's nice to be able to give someone a URL in chat and ask them for comments <mthl>wingo: I agree that in certain contexts it is very helpful <daviid>the ultimate goal is to write an OS in guile <amz3>I did not try the new review interface of github yet <wingo>daviid: hehe yeah i like rewriting stuff :) <daviid>wingo: yes! it does not sound such an impossible goal anymore :), then a windowing manager and we'd be back to real 'confort' à la symbolics/genera era... <wingo>yeah but tbh i think of pining for symbolics as a backward thing, i mean yes there are good things from then that we don't have now. but it's not generative and energy-giving to think of it in that way -- we need to make new things that service the updated versions of those goals <wingo>and maybe they are based on raspberry pi or whatever <wingo>and in the meantime many things are way better and we need to take advantage of them <wingo>so i definitely agree with the positive goals, just wanted to push back against the "lost-paradise" narrative that the lisp world sometimes has <wingo>ACTION talked too much, i think i made other people shut up :) <catonano>wingo: noooooo, I love reading youur opinions ! <wingo>lol be careful what you say :) <avoine>indeed, as a newcomer this is really interesting <daviid>ACTION thinks wingo makes people talk, at the contrary, which is good <spk121>wingo: using gov't terms, it all comes back to the CONOPS for Guile. <wingo>ACTION waits for explanation :) <spk121>what end user uses guile, and for what purpose. <spk121>given that purpose, does Guile fulfill end user req'ts <spk121>up through 1.6, 1.8, the CONOPS of guile was to have a guile upon which guile hackers could hack guile <spk121>with 2.0, the primary conops is to have a functional language upon which to express Guix. <spk121>a list of requirements descends in a tree from the CONOPS <spk121>For Guix, that Guile be a good scheme is important. That req't descends from the root CONOPS <spk121>but now, there are "requirements" that we hold onto, that no longer can trace their way back up, tree fashion, to the primary user <spk121>dsmith-work: Right Concept of Operations <spk121>these requirements that can't trace up the tree are "orphan" requirements <spk121>orphan "requirements" which aren't requirments at all should always be ready to be ignored. <amz3>OrangeShark: do you we can do something like github review using guile git? <OrangeShark>amz3: a review system would probably only need to touch a couple of git features, so I doubt it depends too much on guile git <wingo>tbh i think there is room for more parallel guile development; too much is centralized atm <wingo>i mean people feel that they can't review because they aren't empowered to do so <wingo>and people don't get patches in because they aren't reviewed <wingo>it's not precisely a catch-22 -- there are norms that you have to follow to get a patch into guile, and that's a real thing <wingo>but a bit more parallelism, a bit more people reviewing each others' code would be useful <avoine>wingo: you said earlier "we need to steal more of their code" what ideas you think would be worth sealing? <catonano>wingo: I may be naive but I think that a server with a Free Sotware based service similar to Github or Assembla would suffice. <wingo>catonano: yeah sure :) github of course has a sort of mindshare thing (you might be already logged in for work) but if the 3rd party service remembers your password it could be good :) <catonano>wingo: as for guile on several targets, is it like Clojure today ? The vm, thhe C# runtime, avascript for clourescript a maybe a clang based compilation ? <wingo>yes! i mean that's one my goals personally :) <wingo>who knows where it will actually go <wingo>as with many of these VM things they are very very very very much dependent on what individual hackers choose to do <paroneayea>wingo: anyway, I look forward to what the future holds in Guile, I'm sure things will go well one way or another <paroneayea>wingo: I think as long as we don't give up live hacking ;) and make sure that the things that people are working on "carry forward" <wingo>i think in the near term (5 years) they will go well in the same way they have been (guile-own vm, native compilation, that direction) <wingo>there may be discussions about what it means when you change a top-level function :) i.e. can it be inlined? <wingo>that's a big problem in guile these days, that top-level functions in modules can't be inlined ever <paroneayea>wingo: it might be fine, also, if there's a way to somehow mark a module during hacking <paroneayea>to keep it from being inlined / keep it live hackable <paroneayea>or, maybe have it so that things are inlined via guild <wingo>i had a proposal to the list at some point in this regard <wingo>whether a module should allow its definitions to be inlined <paroneayea>wingo: yeah I haven't read the post but the general idea seems ok <paroneayea>as long as live hacking can be preserved when you want it <paroneayea>I'm okay with it being optimized away when you don't need it <paroneayea>davexunit_: probably I imagine that applies to you too, yeah? <wingo>basically i think there is a way to define the language that both allows for inlining and live-patching everything, depending on what the user chooses <wingo>note that guile currently does effectively inline + and similar "primitives"; often allowing for goops fallbacks but generally assuming that + is bound to what it was bound to at compile time <davexunit_>for me there are low-level things that I wanted to be inlined af and then there are high-level things that I want to tweak constantly at the REPL <wingo>it's a somewhat unsatisfying thing from a language implementor POV -- ***what does this program actually mean???*** <wingo>depends on what the modules mean at runtime, rather than what they meant when the modules were compiled... <daviid>wingo: 2.1.7.10-f261eaf fixes guile-gnome, it appears, and guile-lib make check pass as well, great, thanks! further tests witin 1 week or so (using gnu foliot) but it seems ok <daviid>paroneayea: ^^ i think you can package guile-lib 0.2.5 for guix 'as is' now <paroneayea>So, I read a bunch of the "top-level is hopeless" stuff <paroneayea>and it seems like the real complaint about the "hopelessness" is about syntax forms / macros <paroneayea>and whether or not language would have to be re-evaluated after being initially established <paroneayea>but, I don't feel like that bothers me. If I change a macro, I know the previous code that used that macro won't be suddenly "updated" for it, and that I have to re-evaluate those. <daviid>macros are what makes lisp dialects an order of magnitude superior to any other anguage <daviid>'... are one of the things that makes ...'