Hacking with Guile…
Sassmannshausen, Alex
At: FOSDEM 2017 A more informal talk about how to use Emacs & Geiser, or the commandline REPLto hack on Guile projects. We cover enabling readline for the REPL, we mentionthe colorized REPL project by Nala Ginrut, and then a good setup with Emacs.After this I want to open up the platform to get people to suggest some oftheir favourite REPL based workflows. Room: K.4.601 Scheduled start: 2017-02-05
 Cool. Yeah, so I'm going to be talking about basically hacking in Gile. It's programming in Gile. It's kind of more of an introductory session. We'll cover that in a second. I have to make some slight adaptations to my full screen setup, so hopefully it should work out. We'll see how it goes. So first of all, yeah, my name is Alex Sassmannhausen. I work for PDFS Europe. And I get to work on a library management system, which is used by public and academic libraries, which is free software. So I'm very lucky in that respect. So getting started. Just to gauge the experience in the room, who here has programmed in Gile before? Wow, OK. So yeah, this is an introductory session. Some of it you may already know. So you programmed in Gile. Who here has done a larger project or anything like that in Gile? OK, so that's fewer. OK, that's good. And who feels really comfortable working in Gile? OK. OK. So even the Gile maintainer is like, maybe? OK, so I would say I'm relatively comfortable in Gile, for sure. But so maybe what we're going to cover in this presentation is the bare basics, and then maybe seeing how we can improve our workflow. And I guess maybe also towards the end, if we have time, hopefully, we might be able to share some ideas or share some tips about stuff that we do or workflows we have. We'll see where we go. Down here, this is where we come relevant later. You should be able to see my key commands. This is when we're using Emacs in a second. But for now, it's probably not that important. So first things about Gile, this is probably I can skip. But basically, it's a scheme implementation, which is a Lisp dialect. And that means that there's obviously lots of parentheses, which are wonderful creatures. And you can also use this thing called Wisp, written by someone called Arne. And that's kind of a way. And I think there's a presentation about that later on. It's kind of a way to essentially turn scheme into a less parenthesis language, which is quite neat, actually, to be honest, in fact, that it's possible. But I like my parentheses. So installing Gile on Debian like this shows is super easy. And on Geeks and Geeks SC, of course, is super easy as well. So straightforward. I can skip that. A quick aside, one of the big things about scheme languages, and Lisp in general, I guess, are ripples. And basically, they stand for read evolve print loops. So they're basically just interactive prompts, much like your shell. And it's just kind of a place to evaluate your commands. And most kind of high level languages nowadays have them. At work, I program mainly in Perl and also some PHP, neither of which are particularly known for their ripples. So that's one of the reasons why I like working in Gile, is because I have access to the ripple, because it's great. So but yeah, most languages, most kind of high level languages nowadays probably have them. So normally, firing up the ripples super easy. It's as easy as once Gile was installed, kind of just executing the development command. And you get a ripple. We already saw that before in Ricardo's presentation. By default, it's a bit spartan. I can obviously execute commands. Sure, why not? Let's go with it. Yeah, so it's displayed there. You can see it. I should probably kind of go for. So I've just kind of tried to press. You can see it on here. I've just tried to press the up arrow, thinking, oh, I could get my history up. But no, because the standard ripple doesn't come with history. So like I say, it's a bit spartan. But you can basically use it. It's a ripple. There we go. So yeah, it's a bit spartan by default, which is a bit meh. But we can improve it, because by default, Gile comes with basically a library, which is called ReadLine. So first of all, Gile kind of executes, like Emax basically. It evaluates kind of a startup file, which is, in Gile's case, written in pure Gile. And it comes with a standard library called ReadLine. And you can also, there's a separate project called Colorize written by Nala, which is kind of just as pretty colors. So I'm quickly going to enable those. That didn't work. There we go. There we go. That's better. So I've just kind of tweaked my preprepared Gile ene file. And now we're running it. First of all, I mean, this is just basically like a demonstration. It's a pure scheme file, so you can basically write whatever you want in there. If you want to do some kind of fancy computations before the Rappel fires up, that's fine. You can do that. But the main thing is, I've enabled the Colorize library, so you've got pretty colors there now. And I also have a history now. And as part of the history, ReadLine also provides, obviously, kind of backward search and stuff like that. So already, the Rappel immediately becomes a lot better. So out of the box, installing Gile, if you want to use Gile, the first thing I recommend is definitely enabling ReadLine. It makes a massive difference in terms of using the Rappel. And then after that, I mean, you can even get parent matching, which is lovely if you're kind of doing deep indentation. So yeah, the standard Rappel. Skip that. Anyway, but I guess that's the first thing to do. And I guess at that point, it might be kind of worth talking. I'm not 100% sure whether it's worth talking about this, because again, this is super introductory. Basically, kind of the Gile Rappel comes with some meta commands, which are super useful. And they kind of are prefixed with a comma. So you have help, which is basically just kind of a contextual help command, I guess. There's apropos, which is much like the apropos on the shell, basically provides you with kind of a search through kind of loaded bindings. Binding, which basically just displays all the bindings that are currently loaded. Describe, which is kind of like a way to interactively query the documentation strings from functions. Like Emacs, Lisp, and Python as well in other languages, Gile basically allows you to add documentation strings directly to procedures. So you can query those like this. And it's pretty print, which is quite useful when you're just interactively debugging or messing around. And finally, module and reload are basically just kind of shorthand commands for kind of loading new libraries that are already installed on the system. So I don't know. I should probably start my ruffle first. So apropos, just list them up. And then I can say, OK, well, let's find out what permap does. So the D here stands for describe. Doesn't have documentation string. OK, let's go for it. There we go. So that's just a nice way to kind of add the ruffle, get some extra information. I can load. Let's go for it. And actually, module kind of switches into a new module. So right now, I'm kind of inside the Serfee one module. Serfee one is just a really useful general purpose kind of scheme library that adds lots of wonderful things for processing lists and so on. So from here, I can then say binding, and I can actually have a look at all the procedures, essentially, that this module provides. So it's kind of a way to just let the ruffle explore your kind of code base, essentially, or your procedures and stuff. So yeah, meta commands. Quite useful. But actually, when you're actually working on a project, of course, you've got your ruffle that you can interactively play with, but most of the time you're working in a text editor, presumably. And most text editors will support the kind of syntax highlighting for schemes. So in GNOME, using get it is fine. You can see pretty syntax highlighting. And you can just add it from here. So yeah, it's nice and cloudy out there. So running, obviously, script files as well, just with a S flag in the location. But yeah, let's face it, it's still pretty pair bones. It's not an ideal development environment. So really, at the moment, the way to develop GAL projects is in Emacs. I mean, Emacs in general is a great text editor. And for editing, GAL is basically the way to go. So the first thing you want to do is install Emacs and Geyser. And Debian, it's both, again, like most major distributions probably have both in package and Debian. The usual commands in Geeks, you can also do with the usual commands for Geeks. And then you can just open your GAL script. So I've got it open here. And then the cool thing is that you can basically execute run GAL. And then you basically get your REPL inside Emacs. And at that point, basically, you have inside Emacs without any tweaking, like the better version of the REPL with the kind of history with backward search or whatever you want to do. So that REPL already is a pretty massive improvement. But then it's not just the REPL. I mean, you get this line of meta commands as well. So of course, they work within here. Because this is just a wrapper around the actual GAL process that's running in the background. So it's a fully featured REPL out of the box. But you get also more stuff. You get within the buffer kind of evaluation of GAL code, much like if you've used Emacs before, you know like evaluating elisp within buffers is something that you can totally do. And that's the same with GAL as well, basically. The experience of programming GAL in Emacs essentially becomes very much the same as programming elisp in Emacs. So you can do live coding. You get immediate access to doc strings. And because the GAL documentation is written in info or tech info, you can basically immediately access out of your fingertips as well from within Emacs. So let's look at this one here. I've loaded this file. I've got my REPL open, basically. I'm going to go for geyser, eval, buffer. And what it's done basically is just kind of taking this buffer and just evolve it in the REPL. You don't actually see the output, but it's done it. And the reason that I know that is, for example, if I now hover over this procedure here and I use Control-CDD, I basically can immediately access the documentation for it, the doc string in this case. But for, let's say, match, which is a built-in kind of, well, it's actually exported by the match library. I can do the same thing against CDD. And then I should be able to, hopefully, works. Click on the manual. And there we go. I go to the right chapter in the manual and immediately get full documentation to that, which, again, beats my experience of working with Perl and PHP of manually having to look up various things. So that's one thing. The other thing, as well, is as I start writing, obviously, editing text in Emacs or Lisp in Emacs is so much better than any other text editor that I've come across. So the whole kind of, by comparison, working in Gettiter is something that's painful. Can we see it? Can only the mini buffer at Buffer is hidden. Just one second. I'm just going to resize things a little bit more. And a little more. It refuses to become smaller. Down here is the famous, out of sight is the famous Emacs mini buffer, which, if you've used Emacs, you probably know about. In having guys are enabled, basically, it gives you, whilst you're typing, I can see it here, it's wonderful, it gives you basically the procedure signatures as you're typing them. So basically, you can immediately there see what kind of arguments the procedure expects, which is super useful again. So that's the other thing. We can basically evaluate procedure calls from within the buffer. So I'm now basically pressing Control X E. And you can see basically it immediately evaluates in a kind of buffer next to it. So this is what I meant before with basically buffer evaluation and live coding. You can essentially just write a new procedure definition inside the buffer, and then evaluate it, and then immediately test it for within the buffer without having to switch over to a different kind of test situation or running the script and hoping that everything works out fine, which is, I don't know, just great. It just feels really nice to work that way. So there are a whole host of kind of guys that come in. The most important ones are probably like Evil, Buffer, and Go, which is basically like evaluate the buffer and then kind of switch to the repl, where you have access to the stuff. So again, in the repl, I have access to my functions that I'm defining. There is Geyser, Evil, Last, Sexpe, which basically is like that's what I did before. It just kind of evaluates the last kind of S expression that you were at. And I guess Geyser, Evol, Region is quite useful as well, which is Marker Region and evaluate that. So basically, it allows you to stay within your kind of code file and just kind of evaluate partial parts of the code to kind of see, you know, you see something goes wrong, you kind of quickly tweak it, and you evaluate it again, see if it works then. It's a really nice way of working, basically. So yeah, way better than the standard repl and the standard text editor. So working on a larger project, I mean, basically we kind of have pretty good stuff, like what I've shown so far, it's pretty good stuff to kind of work on scripts and so on, single-contained files. To work on a project, essentially, by and large, this kind of would be, I think, probably a representative kind of layout for a kind of GAL project. You'd basically have your folder, which is kind of your project name, essentially, within that you might have another folder, which is kind of called the same, and that kind of contains support-like modules for your project. And then you've got your main kind of project file, let's say, and then you've got a test folder with some test files in it. And of course, basically, like in GAL, you basically define modules with the defined module form at the top of kind of a module file. And it basically names the module and it kind of exports procedures, and you kind of define what modules you're using. And of course, if you have a project which kind of has several layers of directories deep, as you're working on the project in Geisir, you want to be able to use all the procedures that you have to find deeper down in your project. And the way to do that basically is, well, if you try to do that just normally, you're essentially going to get an error in Geisir because Geisir basically loads GAL from within the load path, and the load path, by default, does not contain your project file. So really, you need to basically, that's the only thing you need to remember when you're kind of working on a project in GAL with Geisir. It's to basically use the Geisir add to load path command. And by default, it will just kind of assume the director that you're in. And then from now on, let's switch to my other example. No, my other example. There we go. So yeah, I'm just quickly going to switch to my Ripple and restart it. OK, so right now it's a fresh Ripple. I've not done that at load path thing yet. So if I do this, it will say, wow, that code doesn't exist. It's not in the load path because it doesn't know about the project. So instead, I'm going to just kind of quickly run the add to load path command. And now it's working fine. And now basically this. So I'm using the kind of GDEM support module, which is in GDEM support. It kind of is really simple. It doesn't do much. But there's a procedure called text-to-greeting. And you can see that this one uses here. So I can evaluate that. And I can do the same thing again. It's a different implementation of the same program. Still cloudy. This is Belgium. And it works again. And that's basically how you can basically work on projects in GAL. You just add to load path. Thank you. So conclusion. Basically, really the way to work at the moment on GAL projects is using the interactive RAPL as gazier inside Emacs together with live coding in buffers and then kind of access to info documentation. That's by far the best way to work on it. And that's kind of what I wanted to cover my introduction. So I don't know. I think it's worth maybe thinking about it. Well, first of all, if you have comments or questions, I'm more than happy to talk a little bit about things that maybe I went through too fast or whatever. But if not, I have a few comments as well possibly about, I think, where GAL should go in order to kind of make it slightly more user friendly. But I think a lot of that has been talked about already previous year and also in the Ricardo's presentation, for instance, and John's presentation as well a little bit. But yeah, first of all, anyone any comments or questions? Yeah? Will GAL ever replace Emacs in mainline Emacs? That question is slightly outside of the remainder of my presentation. I don't know. I think there's some awesome work that exists. And if you're on GeeksSD, actually, you can install GAL Emacs, which actually uses basically GAL as the back end for the presentation. Right, yeah, mainline. Exactly, yeah. So I don't know. Depending on who you talk to, there's more or less excitement about it. A lot of people on Emacs probably quite understand them. We are very concerned about, it's a massive project, basically, and are quite concerned about the amazing stability that Emacs has and what the consequences would be. On the other hand, there's some really cool, it's just an inspiring project in a way. So we'll see what happens. That's my personal opinion. Any other questions? Yeah? Do you use any other IDE-like feature like debuggers? So, oh, of course, sorry. So do I use any kind of other IDE features like debuggers or things like that? So by and large, I want for more or less in basically script-based debugging, mostly. And that's kind of the technique that I use most of the time. But for GAL, there's a debugger that's built into the repel as well. So with GASIA, you basically do get access to the GAL debugger as well. I didn't want to go into that at all in this presentation because it's kind of a talk in itself, really, like how to use it. But yeah, from within Emacs, you have access to that debugger and you can do debugging that way. Other IDE-like features, I mean auto-complete and code completion and code jumping and stuff like that, is pretty much all available via GASIA as well. You can combine GASIA with company mode, which basically gives you auto-completion. Code jumping is, by default, enabled with GASIA. And there's also other. And this is the thing with Emacs, right? There's a million different ways to do it. So the way that I do, for example, project management in Emacs, is using a little file called projectile, which basically allows you to switch to projects and just kind of look at the files within that project. That's quite nice. I think some of the main is that in different regions, there has been a discussion whether you provide a nice environment in Emacs to the tools. So you have to do it step by by hand. Yeah. Any thoughts on that? Yeah, no, I think that's a really valid point. I mean, there are Emacs flavors that are specifically directed towards people's workflows. I mean, the well-known one are things like Space Max. It's just kind of Emacs for people who come from VIM and just want to continue using VIM in Emacs, essentially. Personally, I use Evil and kind of have a heavy customized version of Emacs. But I think there's no reason why we couldn't do something similar for half, basically, an Emacs flavor that's basically set up to out of the box provide a friendlier IDE environment for a GAL development that maybe is more accessible to people who don't come from a VIM or Emacs background. So actually provide the CUA compatibility mode by default, provide gaysier installed by default and working, things like that. And then basically, we can just say to people, if you want to start hacking on GAL, just install this flavor of Emacs and you're good to go. I forgot to repeat the question. The question was, can we make it easier, essentially, to make GAL hacking possible on Emacs? Samurai? Can I discuss this already last night? But I'm going to bring it up again. What do you think of the idea of providing something like a Doctor Racket type thing, but for GAL? Yeah, so the question is, what do I think of the idea of providing a Doctor Racket style thing, but for GAL? I would think that's amazing. I mean, Doctor Racket is basically an IDE and development environment for Racket, essentially. That is pretty much how people start programming Racket by enlarge. And I think that kind of tooling would be amazing to have for GAL. And that's actually probably what my slight problems are about, and problems getting into GAL. Basically, we don't have that kind of really nice, I'm a new person. I want to learn about GAL. This is the tool for you to use. We don't have that kind of nice standalone idea. And I think it would be amazing to have it. The question is just kind of, how do we do it? Or where do we get the energy to do it? That's more the question. Any other questions? OK, so I would just kind of want to add that I think, like Chris has started on this as well, like I think having a nice interactive tutorial or user journey or story for people who start using GAL would be really nice to have as well. Because the documentation for GAL is absolutely amazing. But it's definitely more of a reference documentation rather than kind of a, this is GAL, it's an awesome language, and try out, go with us on this journey. And at the end of it, you'll be a GAL hacker, essentially. And I think it would be really nice to be able to provide people with that as well. Also, one of the downsides that I think at the moment GAL has really is, and we've already talked about that a little bit at the panel, I think Leroy mentioned it, that basically other cool and hip languages have language specific package managers, which have pros and cons. One of the pros is that it becomes so much easier to kind of discover code that is out there and just installing it and using it. And GAL doesn't have that at the moment. And it's a shame, because there's like tons of code out there that no one knows about. And geeks to a certain extent just address that. But I mean, geeks is a bit heavy for just like, if you're just interested in just GAL packages, geeks is a bit heavy probably. So yeah. That's all I have. If you are interested in kind of getting help, like you're just starting to work on GAL and you're kind of interested in getting help, the IRC chat is really user friendly. My name is Payon there, although I'm not very often on there, I must say. The main list is super nice as well. Documentation is fantastic. And some of us hang out on Twitter. Finally, before I leave the place here, we're organizing new hackers meeting this summer. Anyone and all are welcome to come. It's a really cool thing. It's like three days in Germany at this time. And basically, you should check it out, that URL, and sign up if you're interested. Thank you very much. Thank you, Alex. Thank you.
 Cool.  Yeah, so I'm going to be talking about basically hacking  in Gile.  It's programming in Gile.  It's kind of more of an introductory session.  We'll cover that in a second.  I have to make some slight adaptations to my full screen  setup, so hopefully it should work out.  We'll see how it goes.  So first of all, yeah, my name is Alex Sassmannhausen.  I work for PDFS Europe.  And I get to work on a library management system, which is  used by public and academic libraries, which is free  software.  So I'm very lucky in that respect.  So getting started.  Just to gauge the experience in the room, who here has  programmed in Gile before?  Wow, OK.  So yeah, this is an introductory session.  Some of it you may already know.  So you programmed in Gile.  Who here has done a larger project or anything like that  in Gile?  OK, so that's fewer.  OK, that's good.  And who feels really comfortable working in Gile?  OK.  OK.  So even the Gile maintainer is like, maybe?  OK, so I would say I'm relatively comfortable in Gile,  for sure.  But so maybe what we're going to cover in this presentation  is the bare basics, and then maybe seeing how we can improve  our workflow.  And I guess maybe also towards the end, if we have time,  hopefully, we might be able to share some ideas or share  some tips about stuff that we do or workflows we have.  We'll see where we go.  Down here, this is where we come relevant later.  You should be able to see my key commands.  This is when we're using Emacs in a second.  But for now, it's probably not that important.  So first things about Gile, this is probably I can skip.  But basically, it's a scheme implementation,  which is a Lisp dialect.  And that means that there's obviously  lots of parentheses, which are wonderful creatures.  And you can also use this thing called Wisp,  written by someone called Arne.  And that's kind of a way.  And I think there's a presentation about that later on.  It's kind of a way to essentially turn scheme  into a less parenthesis language, which is quite neat,  actually, to be honest, in fact, that it's possible.  But I like my parentheses.  So installing Gile on Debian like this  shows is super easy.  And on Geeks and Geeks SC, of course, is super easy as well.  So straightforward.  I can skip that.  A quick aside, one of the big things about scheme languages,  and Lisp in general, I guess, are ripples.  And basically, they stand for read evolve print loops.  So they're basically just interactive prompts,  much like your shell.  And it's just kind of a place to evaluate your commands.  And most kind of high level languages nowadays have them.  At work, I program mainly in Perl and also some PHP,  neither of which are particularly known for their ripples.  So that's one of the reasons why I like working in Gile,  is because I have access to the ripple, because it's great.  So but yeah, most languages, most kind of high level languages  nowadays probably have them.  So normally, firing up the ripples super easy.  It's as easy as once Gile was installed,  kind of just executing the development command.  And you get a ripple.  We already saw that before in Ricardo's presentation.  By default, it's a bit spartan.  I can obviously execute commands.  Sure, why not?  Let's go with it.  Yeah, so it's displayed there.  You can see it.  I should probably kind of go for.  So I've just kind of tried to press.  You can see it on here.  I've just tried to press the up arrow, thinking, oh,  I could get my history up.  But no, because the standard ripple  doesn't come with history.  So like I say, it's a bit spartan.  But you can basically use it.  It's a ripple.  There we go.  So yeah, it's a bit spartan by default, which is a bit meh.  But we can improve it, because by default,  Gile comes with basically a library, which is called ReadLine.  So first of all, Gile kind of executes, like Emax basically.  It evaluates kind of a startup file, which is, in Gile's case,  written in pure Gile.  And it comes with a standard library called ReadLine.  And you can also, there's a separate project called Colorize  written by Nala, which is kind of just as pretty colors.  So I'm quickly going to enable those.  That didn't work.  There we go.  There we go.  That's better.  So I've just kind of tweaked my preprepared Gile ene file.  And now we're running it.  First of all, I mean, this is just basically like a demonstration.  It's a pure scheme file, so you can basically write whatever  you want in there.  If you want to do some kind of fancy computations before the  Rappel fires up, that's fine.  You can do that.  But the main thing is, I've enabled the Colorize library,  so you've got pretty colors there now.  And I also have a history now.  And as part of the history, ReadLine also provides,  obviously, kind of backward search and stuff like that.  So already, the Rappel immediately becomes a lot  better.  So out of the box, installing Gile, if you want to use  Gile, the first thing I recommend is definitely  enabling ReadLine.  It makes a massive difference in terms of using the Rappel.  And then after that, I mean, you can even get parent  matching, which is lovely if you're kind of doing deep  indentation.  So yeah, the standard Rappel.  Skip that.  Anyway, but I guess that's the first thing to do.  And I guess at that point, it might be kind of worth talking.  I'm not 100% sure whether it's worth talking about this,  because again, this is super introductory.  Basically, kind of the Gile Rappel comes with some meta  commands, which are super useful.  And they kind of are prefixed with a comma.  So you have help, which is basically just kind of a  contextual help command, I guess.  There's apropos, which is much like the apropos on the shell,  basically provides you with kind of a search through kind of  loaded bindings.  Binding, which basically just displays all the bindings  that are currently loaded.  Describe, which is kind of like a way to interactively  query the documentation strings from functions.  Like Emacs, Lisp, and Python as well in other languages,  Gile basically allows you to add documentation strings  directly to procedures.  So you can query those like this.  And it's pretty print, which is quite useful when you're just  interactively debugging or messing around.  And finally, module and reload are basically just kind of  shorthand commands for kind of loading new libraries that  are already installed on the system.  So I don't know.  I should probably start my ruffle first.  So apropos, just list them up.  And then I can say, OK, well, let's find out what  permap does.  So the D here stands for describe.  Doesn't have documentation string.  OK, let's go for it.  There we go.  So that's just a nice way to kind of add the ruffle, get  some extra information.  I can load.  Let's go for it.  And actually, module kind of switches into a new module.  So right now, I'm kind of inside the Serfee one module.  Serfee one is just a really useful general purpose kind  of scheme library that adds lots of wonderful things for  processing lists and so on.  So from here, I can then say binding, and I can actually  have a look at all the procedures, essentially,  that this module provides.  So it's kind of a way to just let the ruffle explore your  kind of code base, essentially, or your procedures and stuff.  So yeah, meta commands.  Quite useful.  But actually, when you're actually working on a  project, of course, you've got your ruffle that you can  interactively play with, but most of the time you're working  in a text editor, presumably.  And most text editors will support the kind of syntax  highlighting for schemes.  So in GNOME, using get it is fine.  You can see pretty syntax highlighting.  And you can just add it from here.  So yeah, it's nice and cloudy out there.  So running, obviously, script files as well, just with a  S flag in the location.  But yeah, let's face it, it's still pretty pair bones.  It's not an ideal development environment.  So really, at the moment, the way to develop GAL projects  is in Emacs.  I mean, Emacs in general is a great text editor.  And for editing, GAL is basically the way to go.  So the first thing you want to do is install Emacs and  Geyser.  And Debian, it's both, again, like most major distributions  probably have both in package and Debian.  The usual commands in Geeks, you can also do with the usual  commands for Geeks.  And then you can just open your GAL script.  So I've got it open here.  And then the cool thing is that you can basically execute  run GAL.  And then you basically get your REPL inside Emacs.  And at that point, basically, you have inside Emacs without  any tweaking, like the better version of the REPL with the  kind of history with backward search or whatever you want to  do.  So that REPL already is a pretty massive improvement.  But then it's not just the REPL.  I mean, you get this line of meta commands as well.  So of course, they work within here.  Because this is just a wrapper around the actual GAL  process that's running in the background.  So it's a fully featured REPL out of the box.  But you get also more stuff.  You get within the buffer kind of evaluation of GAL code,  much like if you've used Emacs before, you know like  evaluating elisp within buffers is something that you can  totally do.  And that's the same with GAL as well, basically.  The experience of programming GAL in Emacs essentially  becomes very much the same as programming elisp in Emacs.  So you can do live coding.  You get immediate access to doc strings.  And because the GAL documentation is written in  info or tech info, you can basically immediately access  out of your fingertips as well from within Emacs.  So let's look at this one here.  I've loaded this file.  I've got my REPL open, basically.  I'm going to go for geyser, eval, buffer.  And what it's done basically is just kind of taking this  buffer and just evolve it in the REPL.  You don't actually see the output, but it's done it.  And the reason that I know that is, for example, if I now  hover over this procedure here and I use Control-CDD, I  basically can immediately access the documentation for it,  the doc string in this case.  But for, let's say, match, which is a built-in kind of,  well, it's actually exported by the match library.  I can do the same thing against CDD.  And then I should be able to, hopefully, works.  Click on the manual.  And there we go.  I go to the right chapter in the manual and immediately get  full documentation to that, which, again, beats my  experience of working with Perl and PHP of manually having  to look up various things.  So that's one thing.  The other thing, as well, is as I start writing, obviously,  editing text in Emacs or Lisp in Emacs is so much better  than any other text editor that I've come across.  So the whole kind of, by comparison, working in Gettiter  is something that's painful.  Can we see it?  Can only the mini buffer at Buffer is hidden.  Just one second.  I'm just going to resize things a little bit more.  And a little more.  It refuses to become smaller.  Down here is the famous, out of sight is the famous Emacs  mini buffer, which, if you've used Emacs, you probably  know about.  In having guys are enabled, basically, it gives you,  whilst you're typing, I can see it here, it's wonderful, it  gives you basically the procedure signatures as  you're typing them.  So basically, you can immediately there see what kind of  arguments the procedure expects, which is super useful  again.  So that's the other thing.  We can basically evaluate procedure calls from within  the buffer.  So I'm now basically pressing Control X E. And you can see  basically it immediately evaluates in a kind of  buffer next to it.  So this is what I meant before with basically buffer  evaluation and live coding.  You can essentially just write a new procedure definition  inside the buffer, and then evaluate it, and then immediately  test it for within the buffer without having to switch over  to a different kind of test situation or running the  script and hoping that everything works out fine,  which is, I don't know, just great.  It just feels really nice to work that way.  So there are a whole host of kind of guys that come in.  The most important ones are probably like Evil, Buffer,  and Go, which is basically like evaluate the buffer and then  kind of switch to the repl, where you have access to the  stuff.  So again, in the repl, I have access to my functions that  I'm defining.  There is Geyser, Evil, Last, Sexpe, which basically is like  that's what I did before.  It just kind of evaluates the last kind of S expression  that you were at.  And I guess Geyser, Evol, Region is quite useful as well,  which is Marker Region and evaluate that.  So basically, it allows you to stay within your kind of code  file and just kind of evaluate partial parts of the code to  kind of see, you know, you see something goes wrong, you  kind of quickly tweak it, and you evaluate it again, see if  it works then.  It's a really nice way of working, basically.  So yeah, way better than the standard repl and the standard  text editor.  So working on a larger project, I mean, basically we kind of  have pretty good stuff, like what I've shown so far, it's  pretty good stuff to kind of work on scripts and so on,  single-contained files.  To work on a project, essentially, by and large,  this kind of would be, I think, probably a representative  kind of layout for a kind of GAL project.  You'd basically have your folder, which is kind of your  project name, essentially, within that you might have  another folder, which is kind of called the same, and that  kind of contains support-like modules for your project.  And then you've got your main kind of project file, let's  say, and then you've got a test folder with some test files  in it.  And of course, basically, like in GAL, you basically define  modules with the defined module form at the top of kind of a  module file.  And it basically names the module and it kind of exports  procedures, and you kind of define what modules you're  using.  And of course, if you have a project which kind of has  several layers of directories deep, as you're working on  the project in Geisir, you want to be able to use all the  procedures that you have to find deeper down in your  project.  And the way to do that basically is, well, if you try to do  that just normally, you're essentially going to get an  error in Geisir because Geisir basically loads GAL from  within the load path, and the load path, by default, does  not contain your project file.  So really, you need to basically, that's the only  thing you need to remember when you're kind of working on a  project in GAL with Geisir.  It's to basically use the Geisir add to load path command.  And by default, it will just kind of assume the director  that you're in.  And then from now on, let's switch to my other example.  No, my other example.  There we go.  So yeah, I'm just quickly going to switch to my  Ripple and restart it.  OK, so right now it's a fresh Ripple.  I've not done that at load path thing yet.  So if I do this, it will say, wow, that code doesn't exist.  It's not in the load path because it doesn't know about  the project.  So instead, I'm going to just kind of quickly run the add  to load path command.  And now it's working fine.  And now basically this.  So I'm using the kind of GDEM support module, which is in  GDEM support.  It kind of is really simple.  It doesn't do much.  But there's a procedure called text-to-greeting.  And you can see that this one uses here.  So I can evaluate that.  And I can do the same thing again.  It's a different implementation of the same program.  Still cloudy.  This is Belgium.  And it works again.  And that's basically how you can basically work on  projects in GAL.  You just add to load path.  Thank you.  So conclusion.  Basically, really the way to work at the moment on GAL  projects is using the interactive RAPL as gazier  inside Emacs together with live coding in buffers and then  kind of access to info documentation.  That's by far the best way to work on it.  And that's kind of what I wanted to cover my introduction.  So I don't know.  I think it's worth maybe thinking about it.  Well, first of all, if you have comments or questions, I'm  more than happy to talk a little bit about things that  maybe I went through too fast or whatever.  But if not, I have a few comments as well possibly  about, I think, where GAL should go in order to kind of make  it slightly more user friendly.  But I think a lot of that has been talked about already  previous year and also in the Ricardo's presentation, for  instance, and John's presentation as well a little bit.  But yeah, first of all, anyone any comments or questions?  Yeah?  Will GAL ever replace Emacs in mainline Emacs?  That question is slightly outside of the  remainder of my presentation.  I don't know.  I think there's some awesome work that exists.  And if you're on GeeksSD, actually, you can install  GAL Emacs, which actually uses basically GAL as the  back end for the presentation.  Right, yeah, mainline.  Exactly, yeah.  So I don't know.  Depending on who you talk to, there's more or less  excitement about it.  A lot of people on Emacs probably quite understand them.  We are very concerned about, it's a massive project,  basically, and are quite concerned about the amazing  stability that Emacs has and what the consequences would be.  On the other hand, there's some really cool, it's just an  inspiring project in a way.  So we'll see what happens.  That's my personal opinion.  Any other questions?  Yeah?  Do you use any other IDE-like feature like debuggers?  So, oh, of course, sorry.  So do I use any kind of other IDE features like debuggers or  things like that?  So by and large, I want for more or less in basically  script-based debugging, mostly.  And that's kind of the technique that I use most of the  time.  But for GAL, there's a debugger that's built into the  repel as well.  So with GASIA, you basically do get access to the GAL debugger  as well.  I didn't want to go into that at all in this presentation  because it's kind of a talk in itself, really, like how to  use it.  But yeah, from within Emacs, you have access to that debugger  and you can do debugging that way.  Other IDE-like features, I mean auto-complete and code  completion and code jumping and stuff like that, is pretty  much all available via GASIA as well.  You can combine GASIA with company mode, which basically  gives you auto-completion.  Code jumping is, by default, enabled with GASIA.  And there's also other.  And this is the thing with Emacs, right?  There's a million different ways to do it.  So the way that I do, for example, project management in  Emacs, is using a little file called projectile, which  basically allows you to switch to projects and just kind of  look at the files within that project.  That's quite nice.  I think some of the main is that in different regions,  there has been a discussion whether you provide a nice  environment in Emacs to the tools.  So you have to do it step by by hand.  Yeah.  Any thoughts on that?  Yeah, no, I think that's a really valid point.  I mean, there are Emacs flavors that are specifically  directed towards people's workflows.  I mean, the well-known one are things like Space Max.  It's just kind of Emacs for people who come from VIM and  just want to continue using VIM in Emacs, essentially.  Personally, I use Evil and kind of have a heavy  customized version of Emacs.  But I think there's no reason why we couldn't do  something similar for half, basically, an Emacs flavor  that's basically set up to out of the box provide a friendlier  IDE environment for a GAL development that maybe is more  accessible to people who don't come from a VIM or Emacs  background.  So actually provide the CUA compatibility mode by default,  provide gaysier installed by default and working, things  like that.  And then basically, we can just say to people, if you want to  start hacking on GAL, just install this flavor of Emacs  and you're good to go.  I forgot to repeat the question.  The question was, can we make it easier, essentially, to  make GAL hacking possible on Emacs?  Samurai?  Can I discuss this already last night?  But I'm going to bring it up again.  What do you think of the idea of providing something like a  Doctor Racket type thing, but for GAL?  Yeah, so the question is, what do I think of the idea of  providing a Doctor Racket style thing, but for GAL?  I would think that's amazing.  I mean, Doctor Racket is basically an IDE and development  environment for Racket, essentially.  That is pretty much how people start programming Racket by  enlarge.  And I think that kind of tooling would be amazing to  have for GAL.  And that's actually probably what my slight problems  are about, and problems getting into GAL.  Basically, we don't have that kind of really nice, I'm a  new person.  I want to learn about GAL.  This is the tool for you to use.  We don't have that kind of nice standalone idea.  And I think it would be amazing to have it.  The question is just kind of, how do we do it?  Or where do we get the energy to do it?  That's more the question.  Any other questions?  OK, so I would just kind of want to add that I think, like  Chris has started on this as well, like I think having a  nice interactive tutorial or user journey or story for  people who start using GAL would be really nice to have as  well.  Because the documentation for GAL is absolutely amazing.  But it's definitely more of a reference documentation rather  than kind of a, this is GAL, it's an awesome language, and  try out, go with us on this journey.  And at the end of it, you'll be a GAL hacker, essentially.  And I think it would be really nice to be able to provide  people with that as well.  Also, one of the downsides that I think at the moment GAL  has really is, and we've already talked about that a  little bit at the panel, I think Leroy mentioned it, that  basically other cool and hip languages have language  specific package managers, which have pros and cons.  One of the pros is that it becomes so much easier to  kind of discover code that is out there and just  installing it and using it.  And GAL doesn't have that at the moment.  And it's a shame, because there's like tons of code out  there that no one knows about.  And geeks to a certain extent just address that.  But I mean, geeks is a bit heavy for just like, if you're  just interested in just GAL packages, geeks is a bit  heavy probably.  So yeah.  That's all I have.  If you are interested in kind of getting help, like you're  just starting to work on GAL and you're kind of interested  in getting help, the IRC chat is really user friendly.  My name is Payon there, although I'm not very often on  there, I must say.  The main list is super nice as well.  Documentation is fantastic.  And some of us hang out on Twitter.  Finally, before I leave the place here, we're organizing  new hackers meeting this summer.  Anyone and all are welcome to come.  It's a really cool thing.  It's like three days in Germany at this time.  And basically, you should check it out, that URL, and sign  up if you're interested.  Thank you very much.  Thank you, Alex.  Thank you.
Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_0_131.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_132_959.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_960_5123.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_5124_6983.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_6984_7163.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_7164_7271.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_7272_7391.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_7392_11015.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_11016_13187.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_13188_15587.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_15588_18647.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_18648_18947.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_18948_19079.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_19080_19127.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_19128_27395.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_27396_28463.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_28464_29423.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_29424_31355.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_31356_31415.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_31416_31763.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_31764_35915.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_35916_35975.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_35976_36143.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_36144_38819.png Hacking_with_Guile_Or_how_I_stopped_worrying_and_learned_to_love_the_REPL_38820_38933.png
Cool. Yeah, so I'm going to be talking about basically hacking in Gile. It's programming in Gile. It's kind of more of an introductory session. We'll cover that in a second. I have to make some slight adaptations to my full screen setup, so hopefully it should work out. We'll see how it goes. So first of all, yeah, my name is Alex Sassmannhausen. I work for PDFS Europe. And I get to work on a library management system, which is used by public and academic libraries, which is free software. So I'm very lucky in that respect. So getting started. Just to gauge the experience in the room, who here has programmed in Gile before? Wow, OK. So yeah, this is an introductory session. Some of it you may already know. So you programmed in Gile. Who here has done a larger project or anything like that in Gile? OK, so that's fewer. OK, that's good. And who feels really comfortable working in Gile? OK. OK. So even the Gile maintainer is like, maybe? OK, so I would say I'm relatively comfortable in Gile, for sure. But so maybe what we're going to cover in this presentation is the bare basics, and then maybe seeing how we can improve our workflow. And I guess maybe also towards the end, if we have time, hopefully, we might be able to share some ideas or share some tips about stuff that we do or workflows we have. We'll see where we go. Down here, this is where we come relevant later. You should be able to see my key commands. This is when we're using Emacs in a second. But for now, it's probably not that important. So first things about Gile, this is probably I can skip. But basically, it's a scheme implementation, which is a Lisp dialect. And that means that there's obviously lots of parentheses, which are wonderful creatures. And you can also use this thing called Wisp, written by someone called Arne. And that's kind of a way. And I think there's a presentation about that later on. It's kind of a way to essentially turn scheme into a less parenthesis language, which is quite neat, actually, to be honest, in fact, that it's possible. But I like my parentheses. So installing Gile on Debian like this shows is super easy. And on Geeks and Geeks SC, of course, is super easy as well. So straightforward. I can skip that. A quick aside, one of the big things about scheme languages, and Lisp in general, I guess, are ripples. And basically, they stand for read evolve print loops. So they're basically just interactive prompts, much like your shell. And it's just kind of a place to evaluate your commands. And most kind of high level languages nowadays have them. At work, I program mainly in Perl and also some PHP, neither of which are particularly known for their ripples. So that's one of the reasons why I like working in Gile, is because I have access to the ripple, because it's great. So but yeah, most languages, most kind of high level languages nowadays probably have them. So normally, firing up the ripples super easy. It's as easy as once Gile was installed, kind of just executing the development command. And you get a ripple. We already saw that before in Ricardo's presentation. By default, it's a bit spartan. I can obviously execute commands. Sure, why not? Let's go with it. Yeah, so it's displayed there. You can see it. I should probably kind of go for. So I've just kind of tried to press. You can see it on here. I've just tried to press the up arrow, thinking, oh, I could get my history up. But no, because the standard ripple doesn't come with history. So like I say, it's a bit spartan. But you can basically use it. It's a ripple. There we go. So yeah, it's a bit spartan by default, which is a bit meh. But we can improve it, because by default, Gile comes with basically a library, which is called ReadLine. So first of all, Gile kind of executes, like Emax basically. It evaluates kind of a startup file, which is, in Gile's case, written in pure Gile. And it comes with a standard library called ReadLine. And you can also, there's a separate project called Colorize written by Nala, which is kind of just as pretty colors. So I'm quickly going to enable those. That didn't work. There we go. There we go. That's better. So I've just kind of tweaked my preprepared Gile ene file. And now we're running it. First of all, I mean, this is just basically like a demonstration. It's a pure scheme file, so you can basically write whatever you want in there. If you want to do some kind of fancy computations before the Rappel fires up, that's fine. You can do that. But the main thing is, I've enabled the Colorize library, so you've got pretty colors there now. And I also have a history now. And as part of the history, ReadLine also provides, obviously, kind of backward search and stuff like that. So already, the Rappel immediately becomes a lot better. So out of the box, installing Gile, if you want to use Gile, the first thing I recommend is definitely enabling ReadLine. It makes a massive difference in terms of using the Rappel. And then after that, I mean, you can even get parent matching, which is lovely if you're kind of doing deep indentation. So yeah, the standard Rappel. Skip that. Anyway, but I guess that's the first thing to do. And I guess at that point, it might be kind of worth talking. I'm not 100% sure whether it's worth talking about this, because again, this is super introductory. Basically, kind of the Gile Rappel comes with some meta commands, which are super useful. And they kind of are prefixed with a comma. So you have help, which is basically just kind of a contextual help command, I guess. There's apropos, which is much like the apropos on the shell, basically provides you with kind of a search through kind of loaded bindings. Binding, which basically just displays all the bindings that are currently loaded. Describe, which is kind of like a way to interactively query the documentation strings from functions. Like Emacs, Lisp, and Python as well in other languages, Gile basically allows you to add documentation strings directly to procedures. So you can query those like this. And it's pretty print, which is quite useful when you're just interactively debugging or messing around. And finally, module and reload are basically just kind of shorthand commands for kind of loading new libraries that are already installed on the system. So I don't know. I should probably start my ruffle first. So apropos, just list them up. And then I can say, OK, well, let's find out what permap does. So the D here stands for describe. Doesn't have documentation string. OK, let's go for it. There we go. So that's just a nice way to kind of add the ruffle, get some extra information. I can load. Let's go for it. And actually, module kind of switches into a new module. So right now, I'm kind of inside the Serfee one module. Serfee one is just a really useful general purpose kind of scheme library that adds lots of wonderful things for processing lists and so on. So from here, I can then say binding, and I can actually have a look at all the procedures, essentially, that this module provides. So it's kind of a way to just let the ruffle explore your kind of code base, essentially, or your procedures and stuff. So yeah, meta commands. Quite useful. But actually, when you're actually working on a project, of course, you've got your ruffle that you can interactively play with, but most of the time you're working in a text editor, presumably. And most text editors will support the kind of syntax highlighting for schemes. So in GNOME, using get it is fine. You can see pretty syntax highlighting. And you can just add it from here. So yeah, it's nice and cloudy out there. So running, obviously, script files as well, just with a S flag in the location. But yeah, let's face it, it's still pretty pair bones. It's not an ideal development environment. So really, at the moment, the way to develop GAL projects is in Emacs. I mean, Emacs in general is a great text editor. And for editing, GAL is basically the way to go. So the first thing you want to do is install Emacs and Geyser. And Debian, it's both, again, like most major distributions probably have both in package and Debian. The usual commands in Geeks, you can also do with the usual commands for Geeks. And then you can just open your GAL script. So I've got it open here. And then the cool thing is that you can basically execute run GAL. And then you basically get your REPL inside Emacs. And at that point, basically, you have inside Emacs without any tweaking, like the better version of the REPL with the kind of history with backward search or whatever you want to do. So that REPL already is a pretty massive improvement. But then it's not just the REPL. I mean, you get this line of meta commands as well. So of course, they work within here. Because this is just a wrapper around the actual GAL process that's running in the background. So it's a fully featured REPL out of the box. But you get also more stuff. You get within the buffer kind of evaluation of GAL code, much like if you've used Emacs before, you know like evaluating elisp within buffers is something that you can totally do. And that's the same with GAL as well, basically. The experience of programming GAL in Emacs essentially becomes very much the same as programming elisp in Emacs. So you can do live coding. You get immediate access to doc strings. And because the GAL documentation is written in info or tech info, you can basically immediately access out of your fingertips as well from within Emacs. So let's look at this one here. I've loaded this file. I've got my REPL open, basically. I'm going to go for geyser, eval, buffer. And what it's done basically is just kind of taking this buffer and just evolve it in the REPL. You don't actually see the output, but it's done it. And the reason that I know that is, for example, if I now hover over this procedure here and I use Control-CDD, I basically can immediately access the documentation for it, the doc string in this case. But for, let's say, match, which is a built-in kind of, well, it's actually exported by the match library. I can do the same thing against CDD. And then I should be able to, hopefully, works. Click on the manual. And there we go. I go to the right chapter in the manual and immediately get full documentation to that, which, again, beats my experience of working with Perl and PHP of manually having to look up various things. So that's one thing. The other thing, as well, is as I start writing, obviously, editing text in Emacs or Lisp in Emacs is so much better than any other text editor that I've come across. So the whole kind of, by comparison, working in Gettiter is something that's painful. Can we see it? Can only the mini buffer at Buffer is hidden. Just one second. I'm just going to resize things a little bit more. And a little more. It refuses to become smaller. Down here is the famous, out of sight is the famous Emacs mini buffer, which, if you've used Emacs, you probably know about. In having guys are enabled, basically, it gives you, whilst you're typing, I can see it here, it's wonderful, it gives you basically the procedure signatures as you're typing them. So basically, you can immediately there see what kind of arguments the procedure expects, which is super useful again. So that's the other thing. We can basically evaluate procedure calls from within the buffer. So I'm now basically pressing Control X E. And you can see basically it immediately evaluates in a kind of buffer next to it. So this is what I meant before with basically buffer evaluation and live coding. You can essentially just write a new procedure definition inside the buffer, and then evaluate it, and then immediately test it for within the buffer without having to switch over to a different kind of test situation or running the script and hoping that everything works out fine, which is, I don't know, just great. It just feels really nice to work that way. So there are a whole host of kind of guys that come in. The most important ones are probably like Evil, Buffer, and Go, which is basically like evaluate the buffer and then kind of switch to the repl, where you have access to the stuff. So again, in the repl, I have access to my functions that I'm defining. There is Geyser, Evil, Last, Sexpe, which basically is like that's what I did before. It just kind of evaluates the last kind of S expression that you were at. And I guess Geyser, Evol, Region is quite useful as well, which is Marker Region and evaluate that. So basically, it allows you to stay within your kind of code file and just kind of evaluate partial parts of the code to kind of see, you know, you see something goes wrong, you kind of quickly tweak it, and you evaluate it again, see if it works then. It's a really nice way of working, basically. So yeah, way better than the standard repl and the standard text editor. So working on a larger project, I mean, basically we kind of have pretty good stuff, like what I've shown so far, it's pretty good stuff to kind of work on scripts and so on, single-contained files. To work on a project, essentially, by and large, this kind of would be, I think, probably a representative kind of layout for a kind of GAL project. You'd basically have your folder, which is kind of your project name, essentially, within that you might have another folder, which is kind of called the same, and that kind of contains support-like modules for your project. And then you've got your main kind of project file, let's say, and then you've got a test folder with some test files in it. And of course, basically, like in GAL, you basically define modules with the defined module form at the top of kind of a module file. And it basically names the module and it kind of exports procedures, and you kind of define what modules you're using. And of course, if you have a project which kind of has several layers of directories deep, as you're working on the project in Geisir, you want to be able to use all the procedures that you have to find deeper down in your project. And the way to do that basically is, well, if you try to do that just normally, you're essentially going to get an error in Geisir because Geisir basically loads GAL from within the load path, and the load path, by default, does not contain your project file. So really, you need to basically, that's the only thing you need to remember when you're kind of working on a project in GAL with Geisir. It's to basically use the Geisir add to load path command. And by default, it will just kind of assume the director that you're in. And then from now on, let's switch to my other example. No, my other example. There we go. So yeah, I'm just quickly going to switch to my Ripple and restart it. OK, so right now it's a fresh Ripple. I've not done that at load path thing yet. So if I do this, it will say, wow, that code doesn't exist. It's not in the load path because it doesn't know about the project. So instead, I'm going to just kind of quickly run the add to load path command. And now it's working fine. And now basically this. So I'm using the kind of GDEM support module, which is in GDEM support. It kind of is really simple. It doesn't do much. But there's a procedure called text-to-greeting. And you can see that this one uses here. So I can evaluate that. And I can do the same thing again. It's a different implementation of the same program. Still cloudy. This is Belgium. And it works again. And that's basically how you can basically work on projects in GAL. You just add to load path. Thank you. So conclusion. Basically, really the way to work at the moment on GAL projects is using the interactive RAPL as gazier inside Emacs together with live coding in buffers and then kind of access to info documentation. That's by far the best way to work on it. And that's kind of what I wanted to cover my introduction. So I don't know. I think it's worth maybe thinking about it. Well, first of all, if you have comments or questions, I'm more than happy to talk a little bit about things that maybe I went through too fast or whatever. But if not, I have a few comments as well possibly about, I think, where GAL should go in order to kind of make it slightly more user friendly. But I think a lot of that has been talked about already previous year and also in the Ricardo's presentation, for instance, and John's presentation as well a little bit. But yeah, first of all, anyone any comments or questions? Yeah? Will GAL ever replace Emacs in mainline Emacs? That question is slightly outside of the remainder of my presentation. I don't know. I think there's some awesome work that exists. And if you're on GeeksSD, actually, you can install GAL Emacs, which actually uses basically GAL as the back end for the presentation. Right, yeah, mainline. Exactly, yeah. So I don't know. Depending on who you talk to, there's more or less excitement about it. A lot of people on Emacs probably quite understand them. We are very concerned about, it's a massive project, basically, and are quite concerned about the amazing stability that Emacs has and what the consequences would be. On the other hand, there's some really cool, it's just an inspiring project in a way. So we'll see what happens. That's my personal opinion. Any other questions? Yeah? Do you use any other IDE-like feature like debuggers? So, oh, of course, sorry. So do I use any kind of other IDE features like debuggers or things like that? So by and large, I want for more or less in basically script-based debugging, mostly. And that's kind of the technique that I use most of the time. But for GAL, there's a debugger that's built into the repel as well. So with GASIA, you basically do get access to the GAL debugger as well. I didn't want to go into that at all in this presentation because it's kind of a talk in itself, really, like how to use it. But yeah, from within Emacs, you have access to that debugger and you can do debugging that way. Other IDE-like features, I mean auto-complete and code completion and code jumping and stuff like that, is pretty much all available via GASIA as well. You can combine GASIA with company mode, which basically gives you auto-completion. Code jumping is, by default, enabled with GASIA. And there's also other. And this is the thing with Emacs, right? There's a million different ways to do it. So the way that I do, for example, project management in Emacs, is using a little file called projectile, which basically allows you to switch to projects and just kind of look at the files within that project. That's quite nice. I think some of the main is that in different regions, there has been a discussion whether you provide a nice environment in Emacs to the tools. So you have to do it step by by hand. Yeah. Any thoughts on that? Yeah, no, I think that's a really valid point. I mean, there are Emacs flavors that are specifically directed towards people's workflows. I mean, the well-known one are things like Space Max. It's just kind of Emacs for people who come from VIM and just want to continue using VIM in Emacs, essentially. Personally, I use Evil and kind of have a heavy customized version of Emacs. But I think there's no reason why we couldn't do something similar for half, basically, an Emacs flavor that's basically set up to out of the box provide a friendlier IDE environment for a GAL development that maybe is more accessible to people who don't come from a VIM or Emacs background. So actually provide the CUA compatibility mode by default, provide gaysier installed by default and working, things like that. And then basically, we can just say to people, if you want to start hacking on GAL, just install this flavor of Emacs and you're good to go. I forgot to repeat the question. The question was, can we make it easier, essentially, to make GAL hacking possible on Emacs? Samurai? Can I discuss this already last night? But I'm going to bring it up again. What do you think of the idea of providing something like a Doctor Racket type thing, but for GAL? Yeah, so the question is, what do I think of the idea of providing a Doctor Racket style thing, but for GAL? I would think that's amazing. I mean, Doctor Racket is basically an IDE and development environment for Racket, essentially. That is pretty much how people start programming Racket by enlarge. And I think that kind of tooling would be amazing to have for GAL. And that's actually probably what my slight problems are about, and problems getting into GAL. Basically, we don't have that kind of really nice, I'm a new person. I want to learn about GAL. This is the tool for you to use. We don't have that kind of nice standalone idea. And I think it would be amazing to have it. The question is just kind of, how do we do it? Or where do we get the energy to do it? That's more the question. Any other questions? OK, so I would just kind of want to add that I think, like Chris has started on this as well, like I think having a nice interactive tutorial or user journey or story for people who start using GAL would be really nice to have as well. Because the documentation for GAL is absolutely amazing. But it's definitely more of a reference documentation rather than kind of a, this is GAL, it's an awesome language, and try out, go with us on this journey. And at the end of it, you'll be a GAL hacker, essentially. And I think it would be really nice to be able to provide people with that as well. Also, one of the downsides that I think at the moment GAL has really is, and we've already talked about that a little bit at the panel, I think Leroy mentioned it, that basically other cool and hip languages have language specific package managers, which have pros and cons. One of the pros is that it becomes so much easier to kind of discover code that is out there and just installing it and using it. And GAL doesn't have that at the moment. And it's a shame, because there's like tons of code out there that no one knows about. And geeks to a certain extent just address that. But I mean, geeks is a bit heavy for just like, if you're just interested in just GAL packages, geeks is a bit heavy probably. So yeah. That's all I have. If you are interested in kind of getting help, like you're just starting to work on GAL and you're kind of interested in getting help, the IRC chat is really user friendly. My name is Payon there, although I'm not very often on there, I must say. The main list is super nice as well. Documentation is fantastic. And some of us hang out on Twitter. Finally, before I leave the place here, we're organizing new hackers meeting this summer. Anyone and all are welcome to come. It's a really cool thing. It's like three days in Germany at this time. And basically, you should check it out, that URL, and sign up if you're interested. Thank you very much. Thank you, Alex. Thank you.
and then maybe seeing how we can improve our kind of add the ruffle, get some extra the better version of the REPL with the kind of project, essentially, by and large, this kind of for the presentation. Right, yeah, mainline. you talk to, there's more or less excitement about it. A lot of people on Emacs probably quite like how to use it. But yeah, from within Emacs, kind of really nice, I'm a new person. I want to