SD4F: (exist? procedure-**maximum**-arity)
Hiya Guilers, I've just started Sussman & Hanson's new book "Software Design for Flexibility" and am trying to translate one of the functions from MIT-Scheme to Guile: #+BEGIN_SRC scheme (define (get-arity proc) (or (hash-table-ref/default arity-table proc #f) (let ((a (procedure-arity proc))) ;arity not in table (assert (eqv? (procedure-arity-min a) (procedure-arity-max a))) (procedure-arity-min a (define arity-table (make-weak-key-hash-table)) #+END_SRC So far this has lead me to these associations: |--+--+-| | MIT | Guile| Comments | |--+--+-| | procedure-arity | arity| | |--+--+-| | hash-table-set! | hashq-set! | possibly =hash-set!=| |--+--+-| | hash-table-ref/default | hashq-ref| possibly =hash-ref= | | | | or =hash-get-handle=| |--+--+-| | make-key-weak-eqv-hash-table | make-weak-key-hash-table | ∃(module) w/eqv-hash? | | | | think I saw it before | |--+--+-| | assert | assert | in (rnrs base) | | | &assertion | + (ice-9 exceptions)| | | assert-macro | + in (debugging assert) | |--+--+-| | procedure-arity-min | procedure-minimum-arity | | resulting in this translation of the function: #+BEGIN_SRC scheme (define (get-arity proc) (or (hashq-ref arity-table proc #f) (let ((a (arity proc))) (assert (eqv? (procedure-minimum-arity a) (**procedure-minimum-arity** a))) (procedure-minimum-arity a #+END_SRC So now I'm just left with figuring out a function for getting the **maximum**[1] arity of a procedure, but I'm unsure how to go about this. I'm a sorta-new schemer and a very new guiler, so I'm unsure where to look... any advice would be appreciated![2] Thanks & happy hacking, Blake [1] double earmuffs to emphasize its a function I need but dont have [2] there is this inquiry already posted, but there was no conclusion https://mail.gnu.org/archive/html/guile-user/2021-05/msg00044.html -- “In girum imus nocte et consumimur igni”
Re: SD4F: (exist? procedure-**maximum**-arity)
Olivier Dion writes: > Out of topic here, but what's your first impression of the book? I was > thinking of asking it for my birthday :-) As someone whose introduction to scheme was sicp about a year ago, which I spent about three months with only moving forward after solving each problem, getting my ass kicked every few sets of exercises (some taking a week!) until I decided to just do a cursory overview of the rest of the material from Chapter 4 onwards, so far SD4F has been fantastic. So far it's a lot of the same ideas from sicp, but instead of traversing the entire gamut of programming it's focused on one objective: explaining how to write the most generic, composable, maintainable and reusable software possible. So in a sense, it feels like a "refined, abbreviated, applied sicp follow-up". Not to say SICP isn't geared towards application of ideas, because it absolutely is, but the first exercises don't, for example, ask that you prove Ackermann's function. So far it sticks to the practical aspect of software design, and has been easy to follow. As someone new to scheme it seems like the first text I've encountered that doesn't only teach scheme but teaches how to design software in scheme. Highly recommended! -- “In girum imus nocte et consumimur igni”
Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Dear Guix (and guile users, who I've Cc'd), My apologies for turning this in last minute. There had been discussion about this proposal on the guix mailing list, and I had missed that I need to submit a formal proposal until roptat mentioned it at Fosdem. Nonetheles here it is: * TITLE: A Deep Dive into the Guile Documentation & Makeover Proposal * FORMAT: Standard Talk * LENGTH: Approximately 30 minutes (pre-recorded) * SUMMARY: Recent discussions on the Guix mailing list revealed that many in the Guix community have found the Guile Reference Manual difficult to navigate as newcomers. That should come as no surprise -- in PDF form, the docs span approximately /850 pages/, making it a quite hefty set of documents for an implementation of a minimal programming language like Scheme, even when compared to the documentation of relatively large PLs; the Racket Guide, for instance, is only 450 pages, while the Rust Book is approximately 550 pages. Serving at once as a referrence manual & API specification, the large size may in part be attributed to what simultaneously makes Guile an appealing project to contribute to, while also rendering the documentation process somewhat delicate: Guile is a massive collective project featuring the contributions of many authors over the course of three decades, contributions which Guilers would hate to trivialize or treat as insignificant or edit away on a whim. Additionally, Guile comes from a long set of traditions within Scheme hacking which itself is deep with sage wisdom spanning many pedagogical philosophies and one of the greatest literature traditions of hacker culture. Is it possible to perform a makeover of the Guile Documentation while respecting these historical threads, at once rendering it more approachable for new users while not forsaking the deep nuggets of wisdom that lie therein? Since mid-December I have been mulling over these questions as newcomer, both studying & analyzing the docs, and trying to come to grips with it's strengths and shortcomings. For this talk, I will present my research to the Guix community, culminating with a plan for a full makeover of the existing docs which would respect the above concerns. I will use the 5 minute presentation to focus on the plan of action, with hopes that during the Q&A we can come to consensus on what is to be done. The decisions made by the group will form the basis of a proposal to be made to the Guile community, and once everyone is in agreement with plans for how to move forward I will undertake the effort to implement the makeover proposal. Additionally, as a newcomer to Guix, I will use the first 10 minutes of my talk to briefly introduce my work and how I'm using Guix & Guile to create a remotely deployed large-scale public interactive video mapping installation commissioned by the city of Singapore which will be installed in Marina Bay at the heart of the city this summer for 8 weeks from June - August 2022. * BIO: Blake Shaw is a media artist and theorist most well known as one of the founders of the SWEATSHOPPE urban media art collective. His works have been shown in over 40 cities on every continent of the world (excluding Antarctica) at venues including: The Venice Biennale (2017), The Brooklyn Museum, Akademie de Kunste Berlin, The Museum of the Moving Image, The Biennial of the America, Luminato (Toronto), The Media Architecture Biennale, and the Museum of Contemporary Art Zagreb. His work have been featured in publications including The New York Times and the Atlantic, and online they have been viewed over 30 million times across various channels. He holds a Masters degree in Philosophy from the EGS Switzerland, and was pursuing a PhD in the Philosophy of Mathematics under the supervision of Boris Groys prior to the COVID-19 pandemic.
Re: Newbie thoughts on Guile Hall + Guix
Vijay Marupudi writes: > I don't think it's fair to say that using packages in Guile just as > easy/hard as other languages. Python / Javascript make this incredibly > easy, and their ecosystem is evidence for that success. Their package > managers have flaws, but they have benefits too, and those benefits > would be great for Guile. I would just like to tag onto this convo that I agree that its not fair to say that Guile is easy and will quickly bless those who endeavor to learn it with superpowers. My experience w/Racket was very smooth and I got working in it very quickly. I was a contracted to work on a project in Python a few months ago and without ever studying it I was able to start doing production work in it (ridiculous how intuitive it is, really). Before I started learning Guile I read Edwin Brady's book on Idris and found Idris much easier to get from start to end of small projects I was working on (because there is a well written book on it). While Guile has become my favorite programming language, it took me several months to learn how to navigate & figure out how to navigate the SRFIs, how to plan a program so that I can know what to expect along the way (what features I'll need to implement myself, etc) before I was able to get productive in it beyond the realm of Guix. And I think most would agree that Scheme is a less advanced language than Idris (I did some category theory in school so I have some intuition for the ideas, but still). And to be honest, I still hit plenty of road blocks. There were definitely some times where I was digging around trying to figure out how to do things and came across messages in the archives saying "its so easy you just do [vague hand wavy explanation]". And I found that quite frustrating, like there is an insularity meant to weed out the bad apples. And when this topic popped up on the guix list a few weeks ago some others expressed similar concerns, folks who are doing very impressive work. A programming language should never make programmers feel dumb -- it should make us feel empowered! [end rant, thanks for humoring me] -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Jérémy Korwin-Zmijowski writes: > I could not put a word on it precisely but I was in between the feeling of > having too much info or not > enough. haha I can totally relate! That succinctly captures part of the core issue -- I might quote you on that if you don't mind ;) -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Neil Jerram writes: > Speaking as one of the past authors of the manual, I look forward to > hearing your thoughts. It is genuinely challenging to present this > amount of material and explain its complexity, and there is no reason > at all to consider any current arrangement as cast in stone. Thanks > for thinking about this. > > Best wishes, > Neil for sure. on the guix list a lot of people expressed their frustrations (many which I share to be sure, which is why I'm drawn to work on this), and some suggested solutions of "we should follow x format". while I understand that sentiment, I as a recovering academic who has helped friends with countless dissertations I also realize that too hasty judgements in an editing process can lead to frustrations which ultimately stall progress. nonetheless, I'm pretty confident that most of my proposal will resonate with the newcomers and old timers alike, and folks will agree to let me move forward without getting bogged down in bikeshedding. it's been quite a trip learning guile! and I'm happy I've put the effort into it and hope I can contribute in such a way that will make it a smoother process for future newcomers :) -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
james writes: > I too would like to state my interest in your talk. As someone who is > relatively new to GNU Guile, I definitely see the interest in such a > discussion as I do my self sometimes find the documentation a bit hard > to navigate although I don't claim to have any knowledge of the history > surrounding it. It does seem like a large, and perhaps a difficult > task to produce a talk on the subject so I would very much be > interested in seeing it. Great! I'm glad to hear that there is lots of interest and look forward to hearing any feedback you might have to offer :) -- “In girum imus nocte et consumimur igni”
Re: Newbie thoughts on Guile Hall + Guix
adriano writes: > Just don't > That stuff is too low level for human beings > [...] > Anyway, I feel your frustration, I've been there myself > > Actually I've been there with Guile more than with Guix > > But still I feel you > > I hope this message of mine can sooth your frustration, to some extent > Wasn't intended for me, but I found it soothing! Somewhat off topic, but I feel like briefly relating these types of sentiment could even be useful to interject in within the Guix docs at times. There are many points of docs where the sales pitch bleeds into points far past the point of sale, so to speak. There are lots of "Guix makes this easy by x y z" deep in the docs, but the longer I've been in the community the more I've seen long time contributors relate that there are lots of points of frustration around certain things that may be called easy in the docs. If you're frustrated, and someone is there telling you what you're confused about this is simple and easy, that can come across as rubbing salt in wounds. While I share the enthusiasm, and I realize how much Guix eases things compared to traditional methods, it has been de-motivating for me at times. On the other hand, I think briefly relating, for example, "Depending on the complexity of a package, packagers at times will be exposed to low-level details that aren't traditionally meant for humans. This can be a genuinely frustrating experience..." becomes encouraging. Hope that makes sense, just food for thought! We could all use a pat on the back at times, especially given the human-ness of a project like guix that is waivers between the social and solitary :) -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Daniel Tornabene writes: > just a simple guile user here, sitting next to my printed out 2.2.6 > manual. I'm interested in this topic as well though I'd say my own > experience with the documentation is less a problem with it as it is > then with its organization. Perhaps I'm an anomaly, but I enjoy and > appreciate a manual with significant, bordering on completeness of > coverage of not simply the language, but the relevant api. I'd also > add that the small examples littered throughout the text which add to > the length have however been quite helpful to me personally, and > demonstrating multiple possible paths one might take given a language > construct is a good thing in a lisp, especially one that attempts to > be as approachable as guile does. The comparisons to racket and rust > printed manuals are enlightening though, and I'd be very interested in > a "close reading", as it were, that susses out the structural and > stylistic details in a comparative way. Successfully done that in and > of itself would be both a major accomplishment for our corner of the > PL world and other software communities with a serious commitment to > documentation and even to non programmers wanting to understand how > such complicated endeavours such as a community developed programming > language effectively communicates information and practices. > for sure, just to clarify as a few folks have commented on this -- & so it seems the summary i provided may have been misleading -- my talk will deal primarily with the structure of the docs, not what can be cut out. i'm really focused here on the user experience, and cutting out not length but instead inconsistencies: in language, layout, order, and style so that users can anticipate a general cadence and thus navigate with greater ease. in fact, i think the end result may be a longer manual, but one in which users will have a simplified mental map, so that amidst hacking you can navigate whether by paper of texinfo to what you're looking for, and be in and out, back to the repl as seamlessly as possible. the hope is to cut out downtime caused while consulting the docs, while also preserving the deeper more essayistic nuggets for when its time to take a plunge. i will offer suggestions for sets of guidelines dealing with various aspects of structure, that intend to both add and preserve existing structure. so it's kind of a 'functor' approach to structuring the docs. this is also where the feedback session will be key, as longtime users will have the knowledge of what would be *objectively bad*. so in a sense, I will offer *weak* or abstract guidelines, and for those that the community agrees are beneficial we should focus on collectively strengthening them such that they may compose as a system that is general, concrete, and true to the language itself. -- “In girum imus nocte et consumimur igni”
Re: Newbie thoughts on Guile Hall + Guix
Chris Vine writes: > Everything is capable of improvement but the guile manual is a manual > and not I think primarily intended as a language tutorial (although > Chapter 3 of the manual does have a very cursory introduction to the > scheme language). If you are looking for a tutorial, I suggest reading > https://www.scheme.com/tspl4/ . It covers the R6RS flavour, but at the > tutorial level I don't think the various current standard flavours > (R5RS, R6RS and R7RS) matter too much. > > I would be reluctant to see the manual turned into a tutorial if that > were to mean abridging any of its current completeness. > For sure, but I didn't say anything about the manual here or anything about a tutorial. -- “In girum imus nocte et consumimur igni”
Re: Newbie thoughts on Guile Hall + Guix
Catonano writes: Hi Adriano, > I personally believe this is a good chunk of why Guile wasn't as successful > as Python > > With Guile the overall experience is extremely frustrating > > I've been hanging around here for years, on and off, and overall I haven't > done anything, in Guile I think this type of response should be taken seriously by all of us, and we should seek to know why this happens for some users, as I've seen plenty of people express the same sentiment. Guile seems to be a community that takes pride in its openness, so in order to grow it seems we should seek to know: + Where do some users get stuck? + What kind of applications are they trying to write? We might find that there is a lot of overlap where there is a set of solutions for doing things, but its difficult to find out where to find the know-how. If we are able to recognize this, we are closer to address the issues, and it seems like something many guile users have in common is that they want to make the community and learning experience better. > I managed to do some widgets in clojurescript, some modest datapipes in > Clojure, a game of life with some 2d graphics library in Clojure > > I made some things in Python > > In Guile ? > > Nothing, nisba, nada I feel you! And there seems to be many others who have had similar experiences. Perhaps a survey is due. Are those who are highly productive in guile relying heavily on the FFI? What is their workflow and how does it differ from those who are hitting walls? > > I can relate to the experience of feeling frustrated about how casually some > things are referred to on Guile channels > > Last time it was about the new exceptions > > But I remember I asked for an example of some usage of the APIs for web > serving in Guile, some years ago > > I was kindly offered an example by Andy Wingo nonetheless > > But then I could follow up, I got lost, I don't remember why exactly, but I > was ashamed to keep gong n any way > > Something similar happened when I asked about lazyness > > I don't think I've ever seen a community that suffers the curse of knowledge > more than the Guile community > > This is why I was enticed to attempt the only video in my life about how to > read a file (a basic use case) with Guile > > And I'm mumbling to do a new series about project management and package > building > > And about delimited continuations > > And, and, and Totally. I think many of us can relate. > > That is, my hope now is that Guile can be made into something empowering, so > that it will be useful to someone else in the future > And so that we can work on cool projects together, and grow as a community :) > rather than disempowering as it has always been (for me at least) > > I've been terribly frustrated about this in the past and I'm so refreshed to > see you landing here, in Guile land Thanks! I'm glad to be here and meet you. I'm about to attempt my first professional project that will use Guile, and I'm a bit nervous. Nevertheless, I'm the type of nerd that has always used obscure academic programming systems for commercial art projects, and theres certainly something sisyphean about it, as it means that I end up writing a lot of C, which brings me little pleasure. But as a former Puredata programmer, I realize that when you get in the swing of things it usually pays off majorly, especially the aspect of being a part of a community that is small and close-nit. > > One final note: while I have been emotional about this in the past, I believe > I'm not being emotional now I'd hope the Guile community can similarly refrain from taking criticism personally, and recognize that everyone is here to contribute to something we see as powerful, beautiful, and reflects humanity's better attributes. Nobody is here to bring the community down... we're here to build, and see our contributions grow like a nice garden of blooming hacks and programs :) > > My remarks are not meant to disparage the Guile/Guix community, I acknowledge > the generosity of this community, overall > > I just think that it's right and useful to raise perceived problems Without a doubt. I think we're all here for community, free software, and comradely discourse, not just scheme. > > And I think this initiative to reconsider the structure of the manual is one > of the best things that happened in a very long time I'm super glad folks have taken to it well! It's the type of subject that can get bogged down in bikeshedding when too many long-time users are set in their ways. So the fact that folks seem to be excited about it, seems to indicate that won't be the case this time around. > > After so many years I still can't tell where to look in it when I need > something > Let's fix that! :) Looking forward to your feedback on my presentation. ez, b -- “In girum imus nocte et consumimur igni”
Re: Ideas for making Guile easier to approach
Just a reminder I'm doing a presentation that covers all this (almost verbatim!) and more for Guix Days :) (ie Christine you be stealing my thunder! 😆 🤣 😂) I'm kidding (kinda). it doesn't hurt to have the conversations already rolling and im sure it will mean the session will be extra productive :) So continue forth and steal! On Thu, Feb 10, 2022, 03:12 Christine Lemmer-Webber wrote: > I've been appreciating the feedback in this thread about Guile; I'm > starting a new topic name because I think we've deviated from talking > about Guile Hall and more about Guile. > > Some stuff below. > > Chris Vine writes: > > > On Tue, 08 Feb 2022 19:19:06 +0700 > > Blake Shaw wrote: > > > >> Vijay Marupudi writes: > >> > I don't think it's fair to say that using packages in Guile just as > >> > easy/hard as other languages. Python / Javascript make this incredibly > >> > easy, and their ecosystem is evidence for that success. Their package > >> > managers have flaws, but they have benefits too, and those benefits > >> > would be great for Guile. > >> > >> I would just like to tag onto this convo that I agree that its not fair > >> to say that Guile is easy and will quickly bless those who endeavor to > >> learn it with superpowers. My experience w/Racket was very smooth and I > >> got working in it very quickly. I was a contracted to work on a project > in > >> Python a few months ago and without ever studying it I was able to > >> start doing production work in it (ridiculous how intuitive it is, > >> really). Before I started learning Guile I read Edwin Brady's book on > >> Idris and found Idris much easier to get from start to end of small > >> projects I was working on (because there is a well written book on it). > >> > >> While Guile has become my favorite programming language, it took me > >> several months to learn how to navigate & figure out how to navigate the > >> SRFIs, how to plan a program so that I can know what to expect along the > >> way (what features I'll need to implement myself, etc) before I was able > >> to get productive in it beyond the realm of Guix. And I think most would > >> agree that Scheme is a less advanced language than Idris (I did some > >> category theory in school so I have some intuition for the ideas, but > >> still). And to be honest, I still hit plenty of road blocks. > >> > >> There were definitely some times where I was digging around trying to > >> figure out how to do things and came across messages in the archives > >> saying "its so easy you just do [vague hand wavy explanation]". And I > >> found that quite frustrating, like there is an insularity meant to weed > >> out the bad apples. And when this topic popped up on the guix list a few > >> weeks ago some others expressed similar concerns, folks who are doing > >> very impressive work. A programming language should never make > >> programmers feel dumb -- it should make us feel empowered! > > > > Everything is capable of improvement but the guile manual is a manual > > and not I think primarily intended as a language tutorial (although > > Chapter 3 of the manual does have a very cursory introduction to the > > scheme language). If you are looking for a tutorial, I suggest reading > > https://www.scheme.com/tspl4/ . It covers the R6RS flavour, but at the > > tutorial level I don't think the various current standard flavours > > (R5RS, R6RS and R7RS) matter too much. > > > > I would be reluctant to see the manual turned into a tutorial if that > > were to mean abridging any of its current completeness. > > The manual does contain a very brief tutorial, but it's brief... the > Guix cookbook also contains something short. Both seem a bit lacking to > me but they could be starting points. > > Regarding the manual as a manual, I actually personally like the Guile > manual a lot. I think it's very well written. But it's a reference > guide. > > But I do remember finding it overwhelming and confusing initially. I > think a few things could improve the situation, some manual related, > some other things: > > > Guile Reference vs Guile Guide > == > > Personally I think the *best* experience I have ever had in reading > manuals is in Racket. > > Racket has a nice way of handling things: > > - There's a set of initial "short tutorials" that are really to get you >up and running an
Re: Newbie thoughts on Guile Hall + Guix
Aleix Conchillo Flaqué writes: > My 2 cents: > > - Doing something in Guile is tough. I've been trying since 2011. > > Why is it tough? > > - The manual is written by very smart people for very smart people. Not for > newcomers. I've seen this sentiment expressed a few times when this topic has popped up, and I think it can come across as assuming that the people who struggle with it are either not very smart, new to programming, or both. For instance, I know that someone who described a difficult experience which shared many of the same attributes as my experience, and they are the author of a popular programming book that is certainly not for newcomers. Before the pandemic threatened to separate me from my partner if I returned to school, I was doing my PhD in philosophy of mathematics focusing on categorical logic, and I've been programming since I was 15, almost 20 years now (but I will admit I'm no super hacker, my work has been specifically limited to audio dsp, opengl, opencv and stage video & lighting). And I worry that beyond possibly scaring off folks who could possibly become very active members of the community, this form of sentiment functions to allow us to forgo the difficult work of understanding what the problems are and how they can be addressed. > I'm excited to see what Blake comes up with, but the content will > probably still be not-trivial. At the end of the day it's a reference manual, > not > a book to teach you how to write a new project from scratch. I'm glad to hear it! It good to see so many people get excited about documentation! Which certainly indicates a shared desire to see the documentation improved. And I agree its a manual, and if anything there is a good amount of inconsistency when the manual is itself unsure whether its a tutorial or a manual. I think I have a very simple guideline that I'll present that allows us to maintain most of the existing material while allowing us to revise sections in a consistent way to make them less tutorial-like, quicker to consult, and easier to understand, at once! It's not magic, but I think will offer a notable improvement both "for the working hacker", but also for the little schemers like myself. I'll be excited to hear what you think of it. > > - There are no simple and modern resources that teach what is the > "Guile/Scheme" > way. How do you even organize a project when you start? Or something like > https://go.dev/tour/ to teach the basics. Yes, you can read books but most > people > when they start to learn a new language they just want to try to do something > quick. And the books that teach Scheme are not trivial/practical. I agree, and I'm really excited to see how Jeremy Korwin's book develops because from just a glance at it, it seems to be on the right track to fill those shoes. > > - Lack of libraries. We do have libraries but the ecosystem is not big and for > those libraries we have it's hard to get started, most don't have simple > examples > or don't have examples at all. > > - Assuming you find the library you need... how do you start using it? How do > you > install it? Now there's Guix, but not everyone has Guix or wants to install > Guix. > I'm on macOS currently so I can't even install Guix unfortunately. > > - Lack of support in editors other than Emacs (yes, geiser is great!). > There's a > project that might help there: https://gitlab.com/rgherdt/scheme-lsp-server. > But > LSP is not enough, you need a paredit equivalent, etc. > > - Creating a new library is (or was) not easy. guile-hall and guix help here. > But > how do newcomers even find "guile-hall"? Should guile-hall be part of Guile > and > included in the manual? > > - Distributing the new library you have created is (or was) not easy either. > Also, guile-hall and guix issues here. > > So basically today we are kind of forcing people to learn Emacs and Guix (if > you > can even use Guix) to have a minimum decent environment. > > For me starting with Guile was not hard because of autotools, I already had to > deal with that for many years. For me the hardest part was the lack of > resources > (libraries, tutorials, examples, simple books). > > As for myself, I've been trying to create libraries to replicate what I use at > work (and I'm far from that) or others that I find fun. And I will try to keep > doing that to improve Guile's ecosystem and help with anything else I can. > > Best, > > Aleix > I address many of your concerns in my presentation, but not all of them, and I agree with most them. Will be interested to hear what you think! ez, blake -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
hiya guix, my apologies for not turning my presentation yet! I know people expressed excitement about it so I just want to give you a heads up that I just finished it, but alas I'm too tired to record the video now. but I will do it ang get it turned in first thing in the morning. but i think it will be worth the wait. if you don't want to do your next presentation from the REPL after seeing this, I'll personally refund your guix-days ticket. sorry again and thanks for the patience, I had to deadlines converge at this moment and had to prioritize. best, blake -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Blake Shaw writes: hiya guix, my apologies again for the hold up in getting this video to everyone. for those who won't have time to view it, I will rehash the suggested changes in the 5 minutes before; perhaps because of the delay in being able to get this together for everyone we can view my session as more of a "birds of a feather" project. also, I unfortunately went over my allotted time by spending a bit too much time on my about me. so please feel free to skip past the first 20 minutes of the video. if you are *very* pressed for time, there is also a fair amount of Guile trivia opening onto the documentation section. if you want to cut that out as well, skipping to around the 30 minute mark should be fine. https://tube.nocturlab.fr/videos/watch/2b55ca09-f0fd-4899-9cb0-9632cd90b3d1 thanks and my apologies again; writing software freelance for a living at times makes commitments to free software difficult to uphold. looking forward to any feedback. best, blake > Dear Guix (and guile users, who I've Cc'd), > > My apologies for turning this in last minute. There had been > discussion about this proposal on the guix mailing list, and I had > missed that I need to submit a formal proposal until roptat mentioned > it at Fosdem. Nonetheles here it is: > > * TITLE: A Deep Dive into the Guile Documentation & Makeover Proposal > * FORMAT: Standard Talk > * LENGTH: Approximately 30 minutes (pre-recorded) > > * SUMMARY: > Recent discussions on the Guix mailing list revealed that many in the > Guix community have found the Guile Reference Manual difficult to > navigate as newcomers. That should come as no surprise -- in PDF form, > the docs span approximately /850 pages/, making it a quite hefty set > of documents for an implementation of a minimal programming language > like Scheme, even when compared to the documentation of relatively > large PLs; the Racket Guide, for instance, is only 450 pages, while > the Rust Book is approximately 550 pages. > > Serving at once as a referrence manual & API specification, the large > size may in part be attributed to what simultaneously makes Guile an > appealing project to contribute to, while also rendering the > documentation process somewhat delicate: Guile is a massive collective > project featuring the contributions of many authors over the course of > three decades, contributions which Guilers would hate to trivialize or > treat as insignificant or edit away on a whim. Additionally, Guile > comes from a long set of traditions within Scheme hacking which itself > is deep with sage wisdom spanning many pedagogical philosophies and > one of the greatest literature traditions of hacker culture. Is it > possible to perform a makeover of the Guile Documentation while > respecting these historical threads, at once rendering it more > approachable for new users while not forsaking the deep nuggets of > wisdom that lie therein? > > Since mid-December I have been mulling over these questions as > newcomer, both studying & analyzing the docs, and trying to come to > grips with it's strengths and shortcomings. For this talk, I will > present my research to the Guix community, culminating with a plan for > a full makeover of the existing docs which would respect the above > concerns. I will use the 5 minute presentation to focus on the plan of > action, with hopes that during the Q&A we can come to consensus on > what is to be done. The decisions made by the group will form the > basis of a proposal to be made to the Guile community, and once > everyone is in agreement with plans for how to move forward I will > undertake the effort to implement the makeover proposal. > > Additionally, as a newcomer to Guix, I will use the first 10 minutes > of my talk to briefly introduce my work and how I'm using Guix & Guile > to create a remotely deployed large-scale public interactive video > mapping installation commissioned by the city of Singapore which will > be installed in Marina Bay at the heart of the city this summer for 8 > weeks from June - August 2022. > > * BIO: > Blake Shaw is a media artist and theorist most well known as one of > the founders of the SWEATSHOPPE urban media art collective. His works > have been shown in over 40 cities on every continent of the world > (excluding Antarctica) at venues including: The Venice Biennale > (2017), The Brooklyn Museum, Akademie de Kunste Berlin, The Museum of > the Moving Image, The Biennial of the America, Luminato (Toronto), The > Media Architecture Biennale, and the Museum of Contemporary Art > Zagreb. His work have been featured in publications including The New > York Times and the Atlantic, and online they have been viewed over 30 > million times across various channels. He holds a Masters degree in > Philosophy from the EGS Switzerland, and was pursuing a PhD in the > Philosophy of Mathematics under the supervision of Boris Groys prior > to the COVID-19 pandemic. > -- “In girum imus nocte et consumimur igni”
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Olivier Dion writes: > On Thu, 17 Feb 2022, Blake Shaw wrote: > >> looking forward to any feedback. > > Some things that I think could use some improvement: > > When you play a video while you're talking, make sure that the > volume of the video is very low so we can still hear you. For > example, around 4.20 I can't hear you anymore (headphone). At > least the music is good. > > There's time where you say Guix when you meant Guile or Scheme I > think. For example around 13.40, you show a Git tree as a S-exp > and refer to Guix. > > Looks like there's a latency between the audio and video. Maybe > it's peertube and not your recorder. > > If you use the REPL again for a presentation that is presented > live, I would suggest to add page number so that it's easier to ask > questions and reference the good slide. In theory, one can use the > $* variable of the REPL for that also. > noted! first screencast on Guix so a few issues I didn't anticipated, I'll keep them in mind for next time. > The very good points of your presentation I think are: > > Your language is impeccable and very cleared/articulated. > > I like that you show your real world usage of Guile. I feel that it's > very important to show what Guile is capable of and that it can be > used in a professional working environment. > > Overall, a great presentation. > thanks! > For your `scribble jam` project, maybe you should look into > guile-chickadee <https://dthompson.us/projects/chickadee.html>. It's a > game development toolkit -- based on guile-opengl -- which I think > support most of what you want. So you could use it in some way for your > project. > yes, I've looked at it, but not deeply (this was a recently commissioned work). I won't really be getting started on scribble jam for a few weeks, but will poke at chickadee to see if it's suitable in the meantime. > Other comments: > > For `Initialization with C` I would call it `C runtime initialization`. > > IMO, `Snarfing macro` should be in the same section as FFI. > > `Scheduling` -> `Multi-Threading` | `Parallelism`. > > `GOOPS` should be under `Guile Modules` or renamed to `Object > Oriented Programming` like `Functionnal programming`. > > SXML is not just used in Web. So I'm not sure if it should be > under the same section. Perhaps under parsing? > > `File Tree Walk` moved to `File System` and rename `POSIX/File System` > to just `File System`. > > Best regards, > old thanks for the feedback and hope you join in tomorrow. best, blake -- “In girum imus nocte et consumimur igni”
Re: guile-oauth 1.1.0 released
Aleix Conchillo Flaqué writes: > Hi, > > I'm happy to announce guile-oauth 1.1.0. This is a minor release that just > adds a missing #:body keyword argument to OAuth1 and OAuth2 HTTP request > procedures and improves documentation. > > https://github.com/aconchillo/guile-oauth/ > > * About > > guile-oauth is an OAuth client module for Guile. It supports the following > features: > > - OAuth 1.0a: HMAC-SHA1 and PLAINTEXT signatures. > - OAuth 2.0: Authorization Code and Client Credentials grant types. > > * Download > > Compressed sources and a GPG detached signature[*]: > > https://download.savannah.nongnu.org/releases/guile-oauth/guile-oauth-1.1.0.tar.gz > https://download.savannah.nongnu.org/releases/guile-oauth/guile-oauth-1.1.0.tar.gz.sig > > [*] To verify download both files and then run: > >gpg --keyserver keys.openpgp.org \ > --recv-keys 7CEC5511C8D057A9EF17470C54D4CC6FFC7468F4 > >gpg --verify guile-oauth-1.1.0.tar.gz.sig > > * Changes since 1.1.0 > > https://github.com/aconchillo/guile-oauth/blob/master/NEWS > > Bugs and comments can be reported at > https://github.com/aconchillo/guile-oauth/issues > > Happy hacking! > > Aleix thanks you Alex! -- “In girum imus nocte et consumimur igni”
Re: Shell commands with output to string
Olivier Dion via General Guile related discussions writes: > On Wed, 23 Feb 2022, Zelphir Kaltstahl > wrote: > >>> There's ton of missing stuffs in the standard library IMO. On top >>> of my >>> head, filesystem paths manipulation (e.g. path-join) is also one >>> that is >>> probably getting re-invented a lots. >> Nice work Zelphir! >> I actually made something for that, trying to copy mostly the Python >> behavior for os.path.join: >> >> https://notabug.org/ZelphirKaltstahl/guile-fslib >> >> Also available as a GNU Guix package, but not updated in a while on >> Guix. Repository contains more up to date version. > > This is great and should be merged into the standard library of Guile. > Maybe not at it's (I have not read everything), but this would be trully > benifical to all Guile users. > I very much disagree. While it's a large implementation of Scheme, Guile is still Scheme. This is all really simple stuff, and there are many ways to implement these functions. Do the Guile maintainers really need to be burdened by adding trivial functionality to the core library? This is really simple stuff, but it was nevertheless difficult for me to figure out how to do much of it in Guile. Many things that confused me to death ended up being a big "oh, its just that??" Which seems to indicate that the issue is less with the core library lacking functionality and more with the presentation of Guile itself -- the docs, which in December we heard a large number of complaints about. > By keeping this as an external library such as a Guix package, I fear > we're aiming at the 'nodejs syndrome' where everything -- down to > the simplest hello world -- is a package dependency. > >>> I believe that the successful story of Python is not just about its >>> pretty syntax, but also dues to its very large standard library. >> >> I think so too. Although I sometimes have the feeling, that Guile does >> things in a cleaner way, once one figures out how to do them in the >> first place. One thing I really like are the ports. Stuff like >> call-with-output-string. Takes some twisting of the brain, but once >> one gets it, it becomes very useful and elegant. > I agree, there is just a mental leap getting to there. I think with examples based on the "expressive graduation" strategy I outlined in my Guix Days presentation can lessen that load quite a bit, and get folks moving with the goods they need to build their own tools quickly. > Of course Scheme does things better than Python. I wouldn't be hacking > with it if it was not the case ^^. Not only the syntax, but the > programming paradigms. You want FP, you got it. You want OOP, sure. > You prefer procedural, no problem. With Python it's more like just OOP > although there's been progress on the FP side. > >> But yes, Python is very beginner friendly in terms of batteries >> included. Although I think that its syntax feels a bit ad-hoc. As in >> "Oh we want some syntax for X … lets invent this keyword here. or some >> new operators or things like that." > > Yeah they were late to the FP paradigm so they had to invent something > without breaking their OOP echo chamber I guess. IIRC, there's talks > about adding patterns matching which Lisp has since the begining. So > yeah very late to the game of FP. > >> I like Guile syntax (or Scheme in general) much more. However, it is >> difficult to motivate others in a quick demo to learn the language, >> when you cannot take half an hour time to explain, what that for other >> people weird looking syntax is actually really cool. > > I'm not sure if it's only the syntax. Yes we often see "but the > parentheses burn my eyes" but I believe that things are more complex > than that. What I think is difficult is to explain to someone why they > should try to learn new languages in the first place. On top of my > head, people ask themself the following question before learning a new > language: > > - Profit -> Can I easily find a good paying job by developing in > this language? So why are Haskell and Rust some of the most popular languages today besides the "big names" (which I don't its reasonable to imagine a scheme implementation suddenly breaking the mold and acceding to) > > - Field -> Can I develop in my field (e.g. video game, mathematic) > with this language? Is there a community? Yes and yes to those fields, with great tools! (Haunt, recent vector libs) But the community, like many a scheme, is a bit hermetic, and this is based in practices like mailing lists, which I don't think can/will change. We could start a guile-hackers discourse server, or something else more public-facing, but would any of the current users join? So then we are the Day Zero guile crew, and thats gonna be rough to get going. > > - Support -> Can I find solutions to my problems easily online? > Are there libraries for common problems that I could encounter? This! While I think the Guile website is re
good papers on graphics in scheme/lisp?
Hiya Guilers, Blake here, who delivered the presentation on the Guile documentation for Guix Days recently[1]. I'm in the process of gathering a summary of the proposed changes which I'll send out in the next week or two, but in the meantime I was hoping I can pick your brains on other matters. Next week I will start working on my installation /Scribble Jam/ for iLight Singapore[2], and I'm planning to do it all in Guile OpenGL + GLSL. I've started fiddling with Guile OpenGL and it seems pretty complete and performant (I haven't experienced any GC hiccups from the small stress tests I've put it through, but its still only minor stuff). There is still a chance I might choose to create a Guile interface to a subset of the C++ OpenFrameworks[3] library, which I have a fair amount of production experience with, to create something equivalent to Clojure's Quil which wraps Processing, but I won't decide until I do a little solo hackathon this weekend to compare the two options. But anyway, thats not actually what I came here to discuss. I usually like to use these commissions to dive into some good literature and experiment with novel techniques along the way. I know I have read in in the past that Lisp actually has quite a long history of being used in VFX, and I'm wondering if anyone here knows of any decent papers that discuss the use of Lisp in general, and perhaps Scheme in particular, for rendering graphics. Having some nice literature to dig into along the way makes doing this kind of work all the more enjoyable. Also, one last thing, I'm considering attempting to create a DSL that compiles to a subset of GLSL like Chicken's GLLS library[4], as I'm becoming more and more interested in compilation. I remember reading somewhere about a Guile library that allows you to write C in Guile, and figure that could be a good source, as GLSL is C-like. Does anybody know what project I'm talking about, and where I can find it? I've searched quite a bit but can't find it -- nevertheless, I'm convinced it was a guile project and I wasn't merely mixing things up. thanks & happy hacking! Footnotes: -- [1] https://xana.lepiller.eu/guix-days-2022/guix-days-2022-documentation.mp4 [2] it's discussed in the above video within the first 20 min for those interested [3] https://openframeworks.cc/ [4] http://wiki.call-cc.org/eggref/5/glls ez, b -- “In girum imus nocte et consumimur igni”
Re: good papers on graphics in scheme/lisp?
Hi Alex! Aleix Conchillo Flaqué writes: > On Wed, Mar 2, 2022 at 8:57 AM Blake Shaw > wrote: > > Hiya Guilers, > > Hi! > > But anyway, thats not actually what I came here to discuss. I > usually > like to use these commissions to dive into some good literature > and > experiment with novel techniques along the way. I know I have read > in > in the past that Lisp actually has quite a long history of being > used > in VFX, and I'm wondering if anyone here knows of any decent > papers that > discuss the use of Lisp in general, and perhaps Scheme in > particular, > for rendering graphics. Having some nice literature to dig into > along > the way makes doing this kind of work all the more enjoyable. > > I don't really know what I'm talking about but maybe you find some > inspiration in https://github.com/libfive/libfive > Aleix > Yes, I have looked at it a bit. Very cool/impressive project! But it seems very-specifically oriented toward the domain of parametric design. I still need to do a proper dive into the C++, but I'm sure it will be a very useful reference to steal ideas from. Thanks for the heads up :) -- “In girum imus nocte et consumimur igni”
Re: good papers on graphics in scheme/lisp?
Olivier Dion writes: > On Wed, 02 Mar 2022, Blake Shaw wrote: > >> Next week I will start working on my installation /Scribble Jam/ for >> iLight Singapore[2], and I'm planning to do it all in Guile OpenGL + >> GLSL. I've started fiddling with Guile OpenGL and it seems pretty >> complete and performant (I haven't experienced any GC hiccups from the >> small stress tests I've put it through, but its still only minor >> stuff). > >> There is still a chance I might choose to create a Guile >> interface to a subset of the C++ OpenFrameworks[3] library > > FFI for C++ is a real pain to do. You can't juste use plain Scheme (at > least I don't know how for C++). If you go that route, I have C++ > templates that can help you for the glue between Scheme and C++ > (e.g. std::vector, std::map, std::string). Thanks for this heads up, I've been curious about the C++ FFI experience in Guile (while less excited about actually getting into the weeds). If I go this route, I'll probably wind up approaching it from using libguile, adding a guile interpreter as an abstraction layer over the creative coding I'm doing in C++, as my experience with that has so far been pretty straight forward (in pure C). But I also worry that if I go down this route, out of habit and familiarity I'll for the most part just end up doing the whole thing in C++, with Guile acting as more of a sort of controller for livecoding. Which could end up really great! I'll be putting a couple days aside this coming week to take it for a test drive with old projects to see how it feels. But after some hacking tonight I'm feeling pretty excited about the pure-Scheme route, so if it appears feasible after weighing my options it will certainly be the direction I head in. > >> Also, one last thing, I'm considering attempting to create a DSL that >> compiles to a subset of GLSL like Chicken's GLLS library[4], as I'm >> becoming more and more interested in compilation. I remember reading >> somewhere about a Guile library that allows you to write C in Guile, > > I think you are refering to > <http://sph.mn/computer/guides/c/c-indent.html>. > Yes! thank you so much, this is it. And looking through the code base I can see there are already some pieces there that seem to illustrate how to work out formatting issues I was confused by as a newcomer to srfi-159 (which is amazing, I might add for folks searching the archive. go check it out ASAP:). I've also come across srfi-166, which is Alex Shinn (same author)'s monadic formatting procedure that deprecates fmt/srfi-159 in order to improve accuracy and safety, which apparently caused some minor headaches in glls. so I'll probably be porting srfi-166 to guile as well :) I've actually gone ahead and started porting GLLS to Guile and to my astonishment its been a piece of cake so far. If I keep up this pace I could even have a working prototyp by the end of the weekend -- but that just seems to good to be true (am I finally acquiring the famed lisp super powers? tbd) > There's also <https://www.nongnu.org/nyacc/> that can be helpful if > you're familiar with LALR(1) parsers. > > Regards, > old yes! nyacc has been extremely helpful. great software, my thanks to the authors, I was even able to use it to wrap glValidateProgram, which seems to be fine "out of the box", so to speek. thanks! b -- “In girum imus nocte et consumimur igni”
Re: good papers on graphics in scheme/lisp?
writes: > On Wed, Mar 02, 2022 at 12:34:32PM -0500, Olivier Dion via General > Guile related discussions wrote: >> On Wed, 02 Mar 2022, Blake Shaw wrote: > > [...] > >> > Also, one last thing, I'm considering attempting to create a DSL that >> > compiles to a subset of GLSL like Chicken's GLLS library[4], as I'm >> > becoming more and more interested in compilation. I remember reading >> > somewhere about a Guile library that allows you to write C in Guile, >> >> I think you are refering to >> <http://sph.mn/computer/guides/c/c-indent.html>. >> >> There's also <https://www.nongnu.org/nyacc/> that can be helpful if >> you're familiar with LALR(1) parsers. > > Actually NYACC comes with a pretty complete C99 compiler [1], which is > used to generate FFI bindings. So perhaps using that as a stepping stone > towards GLSL doesn't sound that crazy... > > Cheers > > [1] https://www.nongnu.org/nyacc/nyacc-c99-ug.html oh wow i didn't see that it ships with a c99 parser, I have only touched the FFI helper -- thanks for pointing me here, this is a massive leg up. sounding less and less crazy by the minute :) -- “In girum imus nocte et consumimur igni”
Re: good papers on graphics in scheme/lisp?
Matt Wette writes: > On 3/3/22 11:29 AM, Blake Shaw wrote: >> writes: >> >>> On Wed, Mar 02, 2022 at 12:34:32PM -0500, Olivier Dion via General >>> Guile related discussions wrote: >>>> On Wed, 02 Mar 2022, Blake Shaw wrote: >>> [...] >>> >>>>> Also, one last thing, I'm considering attempting to create a DSL that >>>>> compiles to a subset of GLSL like Chicken's GLLS library[4], as I'm >>>>> becoming more and more interested in compilation. I remember reading >>>>> somewhere about a Guile library that allows you to write C in Guile, >>>> I think you are refering to >>>> <http://sph.mn/computer/guides/c/c-indent.html>. >>>> >>>> There's also <https://www.nongnu.org/nyacc/> that can be helpful if >>>> you're familiar with LALR(1) parsers. >>> Actually NYACC comes with a pretty complete C99 compiler [1], which is >>> used to generate FFI bindings. So perhaps using that as a stepping stone >>> towards GLSL doesn't sound that crazy... >>> >>> Cheers >>> >>> [1] https://www.nongnu.org/nyacc/nyacc-c99-ug.html >> oh wow i didn't see that it ships with a c99 parser, I have only touched >> the FFI helper -- thanks for pointing me here, this is a massive leg up. >> >> sounding less and less crazy by the minute :) >> > > Note nyacc comes with a c99 parser, not compiler. mes has the back end. > > The best paper I read on C++ for FFI was the one wrapping Qt for python, > but that was many years ago. I found this more recent link: > https://doc.qt.io/qtforpython/shiboken6/shibokengenerator.html > Maybe it can be helpful.. > > Matt > This looks like great help, thanks! ez, b -- “In girum imus nocte et consumimur igni”
[feature request] merge sxml->html from (haunt html) into guile?
Hiya Guilers, Having just wrapped up the Scribble Jam project I mentioned in my Guix Days talk on the Guile Docs makeover, I'm getting back to the topic of the documentation. I figured this is a good excuse to finally move my hiney and finally do something I've been putting off for the simple reason I find writing HTML a bore -- creating a blog where I can collect all these thoughts and tips to help improve the Guix/Guile knowledge ecosystem. So of course, I figured I will try to make the web process less boring by doing it in Guile, and naturally went to the SXML docs, as I've had some ideas for a Guile extension that combines ideas from structured writing to make an easy and fun documentation and tutorial system that can be queried from the Guile repl. I could kill two bird with one stone! So I thought... This lead me to spend the last two nights learning XSLT and XHTML. I read Peter Bex's dynamic web tutorial, and then started hitting the XSLT textbooks. And after two nights and several hundred loc, I had as you may imagine, a poor skeleton of a website from 1995. Jeez, I thought, how much work are they doing to write the Guix website in Guile? They're really sticking to XHTML? Usually I'm not the type that heads straight to examples. I typically want to get away from the world with something new, try to study it on my own, and then later look to what others are doing. In this case, that lead me to try to poke at figuring out an sxml->html transformation myself, digging through Oleg Kisleyovs papers, and various ancient texts on the merits of XHTML, XSLT, XPath, etc... but it became clear that XML really isn't just a simple markup format that can be learned quickly, and my total lack of web skills weren't going to ramp up quickly enough to go from a "My First Geocities" aesthetic to the beautiful read I had been scheming up in my imagination. Finally I caved and decided to look at the Bootstrappable source code, and voila! (haunt html) provides sxml->html... the piece of the puzzle I was missing. Massive, near comical, relief. I'd like to suggest that, with Dave Thompson's approval, we could incorporate this function into Guile as I can imagine others going through a similar process. SXML remains a powerful tool, but without a modern way to get your results on screen it can appear archaic. But also, as someone who doesn't work in web *at all*, I don't really know how often HTML changes and how much of a burden the maintenance could be for the maintainers. So if its likely to become a fussy hairball, I understand. But I do think it could be an extremely helpful addition to (sxml simple), which also is in need of documentation, so if folks would agree this would be useful I'd be happy to, in turn, provide documentation for the currently missing SXML page, covering all the functions in (sxml simple). WDYT? ez, b -- Blake Shaw Director, SWEATSHOPPE sweatshoppe.org ---
Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?
Hi Luis, (copying in Guix as I digress into the subject of a Wiki for Guix & Guile communities) Thanks for this! It's cool and I would not have found it without your help. Which brings up another thing I've been considering working on thats been discussed in the Guix community: the need for click-to-edit wiki, written in Guile. If we had a wiki up, there could be an "HTML" stub, for instance, that collects links to all projects using HTML in guile. Finding out whats available would be streamlined, and relatively painless to update and moderate. I have some free time for the next month, and should be able to knock out a basic wiki system in this time (I found what looks like a nice book about wikis that I could read and use as a guide for implementing it). Since getting feedback on my presentation for Guix Days, where I think a lot of good criticism was raised, I've been thinking about ways to organize contributions to the docs. An idea I've had is to create a wiki that has a basic system of tags that can link with Mumi so that while folks are looking things up they can also get a sense if there are "TODOs" concerning a subject they reading up on, even beyond contributing to the docs. Many folks have expressed that they want to start chipping in, but aren't quite sure where to start. Perhaps something like this could help ease that process, and make updating information more dynamic and less critical than in the main docs. Any thoughts? ez, b On Tue, Jun 28, 2022, 20:26 Luis Felipe wrote: > Hi Blake, > > On Monday, June 27th, 2022 at 06:57, Blake Shaw > wrote: > > > Finally I caved and decided to look at the Bootstrappable source code, > and > > voila! (haunt html) provides sxml->html... the piece of the puzzle I was > > missing. Massive, near comical, relief. > > Just to mention that there is also htmlprag, from guile-lib ( > https://www.nongnu.org/guile-lib/doc/ref/htmlprag/).
Re: guile-oauth 1.3.0 released
Thanks for keeping all these essential tools in shape Alex! On Thu, Jun 30, 2022, 13:15 Aleix Conchillo Flaqué wrote: > Hi, > > I'm happy to announce guile-oauth 1.3.0. This release allows you to use > other HTTP client libraries to perform HTTP requests. An *http-proc* > procedure can be specified in all guile-oauth procedures that make HTTP > requests, it defaults to Guile's (http-request). Thank you Nala Ginrut for > the suggestion. > > https://github.com/aconchillo/guile-oauth/ > > * About > > guile-oauth is an OAuth client module for Guile. It supports the following > features: > > - OAuth 1.0a: HMAC-SHA1 and PLAINTEXT signatures. > - OAuth 2.0: Authorization Code and Client Credentials grant types. > > * Download > > Compressed sources and a GPG detached signature[*]: > > > https://download.savannah.nongnu.org/releases/guile-oauth/guile-oauth-1.3.0.tar.gz > > https://download.savannah.nongnu.org/releases/guile-oauth/guile-oauth-1.3.0.tar.gz.sig > > [*] To verify download both files and then run: > >gpg --keyserver keys.openpgp.org \ > --recv-keys 7CEC5511C8D057A9EF17470C54D4CC6FFC7468F4 > >gpg --verify guile-oauth-1.3.0.tar.gz.sig > > * Changes since 1.3.0 > > https://github.com/aconchillo/guile-oauth/blob/master/NEWS > > Bugs and comments can be reported at > https://github.com/aconchillo/guile-oauth/issues > > Happy hacking! > > Aleix >
Re: Curiosity: Microkernel implemented in Guile ?
Here is a toy kernel implemented in Loko Scheme that I just came across: https://github.com/luksamuk/loko-kernel On Sat, Jul 2, 2022, 16:48 Matias Jose Seco Baccanelli < matias_jose_s...@autoproduzioni.net> wrote: > Hello fellow Guilers! > Thank you so much for the wide input! > So cool to see many thriving initiatives! > > Il giorno Thu, 23 Jun 2022 09:34:25 +0200 > Maxime Devos ha scritto: > > > Matias Jose Seco Baccanelli schreef op do 23-06-2022 om 08:11 [+0200]: > > > Feels like a nice recipe for User Empowerment ! > > > > How does this empower users? > > My rationale is about having the advantage of scheme programming > approach than c paradigm. I feel this brings it's magic pedagogic and > mind friendly source code. > > > Sure, if the user is a programmer they > > can modify their custom microkernel in Scheme, but then you have a > > very niche OS that practically no other software already supports, > > which is very inconvenient for the user and the user will have > > practical difficulties sharing the software with other people using > > other OSes > > Indeed, i'm too newbie about the topic, i thought integration between > kernel and software was straightforward, but i can imagine that many > additional tools/steps might be required for that. > > > ,so I think you're better of modifying another > > pre-existing microkernel to be usable from Guile (see answer by Dr. > > Arne Babenhauserheide). > > I think that's a great idea and initiative! > > > Greetings, > > Maxime. > > Thanks for the interesting reflection! > Again my knowledge on these fields are still under > development^^ so this are mainly curiosities and sensations! > Thanks! > >
Re: The Spritely Institute publishes A Scheme Primer (the long-requested "Guile tutorial"?)
Wow I'm just now looking through this and it looks amazing. It's great that there is finally something that shows idiomatic extra-scheme practices from the outset (things not in the core spec but widely implemented like pattern matching) and gets straight into the goods by concluding with a simple interepreter. Have already sent to some friends who have been wanting to learn. Hope this becomes hit, can't wait to read it myself! On Fri, Jul 8, 2022, 21:10 Max Brieiev wrote: > Hi, > > Christine Lemmer-Webber writes: > > > I've considered making a Guix package of the .info version. What do > > people think? Would that be useful? > > Yes, please. > > Possibly, this tutorial could also be referenced in > (info "(guix-cookbook) Scheme tutorials") > > Or even included in guix cookbook? > >
Re: Guile Steel: a proposal for a systems lisp
The name is gold (well, actually Steel, but...) I love the idea as I'd love to be able to do systems programming in Scheme. I've actually been playing with Loko scheme lately which is really cool and designed for bare metal. There are some really cool things going on there, such as Valand, an experimental wayland-like compositor written purely in Scheme (see the dev branch if you're interested). But its still garbage collected. Another cool example of what maybe counts as a systems lisp/scheme is the xtlang from extempore, designed to allow for the low-level bit fiddling and performance requirements of per-sample DSP. If this initiative takes off I'd like to offer my help however I could contribute :) --- Blake Shaw Director, SWEATSHOPPE sweatshoppe.org --- On Sat, Jul 9, 2022 at 3:38 PM Christine Lemmer-Webber < cweb...@dustycloud.org> wrote: > > A little blogpost this morning, not actual software, but software > desiderata: > https://dustycloud.org/blog/guile-steel-proposal/ > > I'd love to see something like the above happen. I'd love to help make > it happen. So this is more of a call to arms than anything else. > > Can we have a "systems lisp"? Can we do better than Rust? Let's put > some interesting things on that compiler tower of ours! >
Re: New "GNU Guile Made" and "Guile Hall Managed" badges
These are great, super slick On Sat, Jul 16, 2022, 21:26 Jérémy Korwin-Zmijowski < jer...@korwin-zmijowski.fr> wrote: > Neat ! > > Le 16 juillet 2022 15:22:37 GMT+02:00, Luis Felipe < > luis.felipe...@protonmail.com> a écrit : > >Hi, > > > >I made some badges you can use to let people know that your software is > made with Guile and managed with Hall. > > > >See the picture for an example rendering on GitLab with a dark theme > (they should work on a light theme too). > > > > > https://luis-felipe.gitlab.io/media/2022/07/gnu-guix-guile-hall-badges-2022-07-16.png > > > >Grab the source SVG from my website: > > > >https://luis-felipe.gitlab.io/media/badges/gnu-guile-made.svg > > > >https://luis-felipe.gitlab.io/media/badges/guile-hall-managed.svg > > > >The Guix badge is available too: > > > >https://luis-felipe.gitlab.io/media/badges/gnu-guix-packaged.svg > > > > > >Enjoy 🙂 > > > > > > > >--- > >Luis Felipe López Acevedo > >https://luis-felipe.gitlab.io/ >
boiler plate class generation, writing fresh variables with macros
Hiya guilers, Right now I am working on a window manager extension system in Guile and GOOPs, and I want to eliminate the boilerplate for generating class slots, with a syntax-case macro like: #+begin_example scheme (define-syntax slot-machine (λ (form) (syntax-case form () ((_ category quality value) #'(let* ((sym (symbol-append category '- quality)) (set-sym! (symbol-append 'set- sym '!)) (get-sym (symbol-append 'get- sym)) (acc-sym (symbol-append 'acc- sym))) (quasiquote (,sym #:init-value value #:setter ,set-sym! #:getter ,get-sym #:accessor ,acc-sym)) #+end_example With this I can evaluate (slot-machine 'inner 'color "green") resulting in what looks like an acceptable slot definition: => (inner-color #:init-value "#BF3D52" #:setter set-inner-color! #:getter get-inner-color #:accessor acc-inner-color) Indeed, if I define a class with this slot definition in place (ie manually/without calling the macro), it works fine: #+begin_example scheme (define-class () (inner-color #:init-value "#BF3D52" #:setter set-inner-color! #:getter get-inner-color #:accessor acc-inner-color)) (describe ) => is a class. It's an instance of Superclasses are: Directs slots are: inner-color (No direct subclass) Class Precedence List is: Class direct methods are: Method #< ( ) 7f7b27e10ac0> Generic: setter:acc-inner-color Specializers: Method #< () 7f7b27e10b00> Generic: acc-inner-color Specializers: Method #< ( ) 7f7b27e10b40> Generic: set-inner-color! Specializers: Method #< () 7f7b27e10b80> Generic: get-inner-color Specializers: #+end_example But if I try to use `slot-machine` inside a class definition i'm out of luck: (define-class () (slot-machine 'inner 'color "green")) => While compiling expression: Syntax error: socket:7257:0: source expression failed to match any pattern in form (define-class-pre-definition ((quote inner) (quote color) "green")) I have tried to remedy this ina number of ways, using datum->syntax, quasisyntax/unsyntax, make-variable and by defining a new syntax-case macro to define classes, all without luck. This is actually a recurring theme with my experience with Guile, working on a project, needing to generate boilerplate, and then being unable to find a result, so I figured its time I reach out to figure out what I'm doing wrong in this situation. Thanks for your help! Best, Blake
Re: [ANN] Guile SRFI-146 0.1.0 released (purely functional data structures)
Nice, thank you! Hope its accepted into guix quickly :) On Mon, Aug 8, 2022, 15:56 pukkamustard wrote: > > Hello Guilers, > > I'm pleased to announce Guile SRFI-146 0.1.0: > https://inqlab.net/git/guile-srfi-146.git/tag/?h=v0.1.0 > > Guile SRFI 146 provides bindings to SRFI 146 (Mappings). SRFI 146 > provides two purely functional mapping data structures: One that uses an > ordering of keys and another that uses a hash on keys. The > implementations use red-black trees and hash array mapped tries (HAMT). > > The library re-uses the SRFI sample implementation with some minor Guile > specific fixes and optimiztions. The SRFI test suite has also been > ported. > > The package has been submitted to Guix so you should be able to start > some purely functional hacking very soon > (https://issues.guix.gnu.org/57055). > > Bug reports, fixes and patches are very welcome. > > Best regards, > pukkamustard > > > >
Re: fun with wayland
Wow this looks great, I currently configure my Herbstluftwm with an ad-hoc guile edsl, but I may have to switch over to Wayland now :) Looking forward to play with this, cheers On Mon, Feb 6, 2023, 20:31 Matt Wette wrote: > > > On 2/5/23 11:25 PM, Sascha Ziemann wrote: > > Am So., 5. Feb. 2023 um 20:05 Uhr schrieb Matt Wette < > matt.we...@gmail.com>: > >> 2) I am using my proposed mmap wrapper for Guile, in C, to create a > file- > >> mapped shared drawing. > > What is a "file-mapped shared drawing"? > "file-mapped shared drawing buffer" -- sorry about that. > >
Re: fun with wayland
I had just briefly browsed the email and thought it was a simple compositor. I'll try to dig in in the near future, exciting to see someone implementing Wayland in guile. Perhaps a guix window manager would be be a good GSoC project suggestion 👀 On Sun, Feb 12, 2023, 04:51 Matt Wette wrote: > So, you are looking to implement a compositor? > My scanner doesn't generate that side of the protocol > (yet), but I could add it. > > > On 2/6/23 10:09 PM, Blake Shaw wrote: > > Wow this looks great, I currently configure my Herbstluftwm with an > ad-hoc > > guile edsl, but I may have to switch over to Wayland now :) > > > > Looking forward to play with this, cheers > > > > On Mon, Feb 6, 2023, 20:31 Matt Wette wrote: > > > >> > >> On 2/5/23 11:25 PM, Sascha Ziemann wrote: > >>> Am So., 5. Feb. 2023 um 20:05 Uhr schrieb Matt Wette < > >> matt.we...@gmail.com>: > >>>> 2) I am using my proposed mmap wrapper for Guile, in C, to create a > >> file- > >>>> mapped shared drawing. > >>> What is a "file-mapped shared drawing"? > >> "file-mapped shared drawing buffer" -- sorry about that. > >> > >> > > >
