IRC channel logs


back to list of logs

<stratotanker>solved using rnrs bytevectors
<manumanumanu>Morning guilers!
<pmikkelsen>morning manumanumanu!
<manumanumanu>What are you all working on?
<amz3>guile js :)
<amz3>manumanumanu: and you?
<manumanumanu>Nothing in particular. Learning common lisp and porting whatever I like from it to guile
<pmikkelsen>I am woring on writing a meson-build-system for guix, so we can hopefully get the latest gnome when/if they switch ;)
<amz3>I shoud also work on ffi helper
<amz3>(at the present time I am at work, and I don't work on guile ;)
<manumanumanu>I am not a very good programmer (classical musician by profession), and I feel a bit sad I can't really contribute to most oss projects. The guile for-loops I wrote are about as complex as I can write
<manumanumanu>(but I am proud of those. they work very well, and produce optimal code in most cases)
<pmikkelsen>manumanumanu: I am confident you can contribute to guix if you want to, but if you don't use it, maybe it is not so fun ;)
<pmikkelsen>The guix team is very helpfull
<amz3>manumanumanu: fwiw I am programmer by trade and I don't feel like I am up to the task of writing for-loops
<amz3>manumanumanu: you have imposter syndrom ;)
<amz3>like me
<gour>is it reasonable tp expect that one could use guile for configuring emacs in the foreseeable future or am i better learning some elisp as well? otoh, my interest for guile is to use it with gnucash as well as to possibly migrate to guixsd (from fedora) if i manage to find compatible hw not requiring special firmware
<pmikkelsen>Last time i used that guile emacs, it was not very fast, but it may have had something to do with how it was build. Although I can highly recommend learning guile for guixsd, and even just for guix on fedora :)
<gour>pmikkelsen: yeah, guix on fedora might be a good step into right direction
<gour>as far as guixsd, wifi drivers are probably the only/main obstacle since i anyway have/use old ati cards with floss drivers
<pmikkelsen>gour: yeah wifi.. I was really lucky that my system had hardware that just worked out of the box, wifi and all ;)
<civodul>hey wingo
<civodul>wingo: i just emailed you with more data re compiler profiling :-)
<wingo>oh good :)
<civodul>i'll be away for several hours, but i'd be happy to read your thoughts!
<wingo>i will look at it as soon as i can! :)
<civodul>awesome :-)
<wingo>ACTION was hacking on removing the indirection in structs this morning
<wingo>but to do that, class redefinition needs to be reimplemented; so i made it so that class redefinition is a layer on top of "fixed" classes
<wingo>which is a relief in many ways, as redefining <class> itself is terrifying
<wingo>so after this change, we still have redefinable classes, but only some classes are redefinable
<wingo>and the new thing is that after the change, we can have proper goops classes for fixed structs without the indirection
<wingo>and then structs remove their indirection and weird GC interaction, and then "instruction explosion" can do a good job for structs
<wingo>ACTION has been agonizing over this for months :P
<ecraven>wingo: say I wanted to add the simple parts of r7rs to guile (boolean=?, string-for-each, let*-values, such things). where would I start? is there a file where r7rs compatibility code should live?
<ecraven>exact / inexact for inexact->exact and exact->inexact would be simple too, for example
<wingo>i do not know :) would require more thought than i have at the moment. some things like exact->inexact should probably just be renamed in the root env. some things like let*-values are already part of a srfi. you can obviously define a module that exports precisely the r7rs interface...
<wingo>but what the overall guile/r7rs story looks like, i don't know. other people have thought more about this than me.
<wingo>i suspect that we need a command-line arg for --r6rs or --r7rs, something like that, where guile will have r7rs small support built in probably
<wingo>via some module
<wingo>and --r7rs will expose that module
<wingo>in the default env
<wingo>but for the large modules i expect most to remain as 3rd party libraries as they are just libraries
<wingo>but that is just an ignorant thought :)
<ecraven>wingo: it might be "good enough" for starters to at least have the correct names in the initial environment?
<ecraven>especially for existing things that were just renamed in r7rs
<wingo>"correct" :)
<ecraven>wingo: yea, not thinking about r7rs-large yet ;)
<wingo>i think we probably will not expose string-for-each in the default env, for example
<wingo>but with --r7rs we would arrange for that to be the case
<ecraven>so the way to go would be to create something like an r7rs-compat module, that re-exports existing functions under the right names?
<wingo>yes i think that's the right way to go, yes
<wingo>we can always integrate more tightly with time if that becomes a good idea
<wingo>hard to remove added interfaces though!
<ecraven>my interest is mainly poking all Schemes until there is at least *some* way to get an r7rs-small environment ;)
<ecraven>I'm not saying guile should move to r7rs entirely, but it would be nice to have some way to get at least r7rs-small (which [apart from import] shouldn't be too hard, as everything is probably there already, just not under the right bindings)
<ecraven>is there some place in ~ where I can put guile modules so that guile will find them?
<gour>how might guile compare performance-wise with the racket? it's not present in language-shootout ( although i'm aware it might not be close to the real-world...
<ecraven>gour: take it with a grain of salt, but there's
<gour>ecraven: thanks a lot! it seems there is no lack of scheme implementations. ;) noreover, it's interesting to see that chez is very quick and racket dpes plan to depend on it in the future...
<ecraven>gour: just remember that there are many things you *don't* see in those benchmarks
<gour>ecraven: yeah, benchmarks are always tricky...just wonder is it difficult to switch 'context' if one wants to use different implementations of scheme like guile/racket...?
<ecraven>depends on what programs you write, but for anything even remotely complicated, you will have to use implementation-specific code, and that makes things much harder to port
<ecraven>r7rs-large is trying to change this (very sloooowly ;)
<gour>does r7rs includes racket as well or is it too different?
<ecraven>racket has a compatibility mode (which isn't perfect yet)
<ecraven>I think the only implementation that is entirely r7rs is chibi
<gour>that's interesting
<ecraven> is a start at looking at compatibility
<ecraven>cyclone is looking very good too
<ecraven>kawa too ;)
<gour>what would be some scheme implementation suitable as kind-of python replacement for writing tiny scrpts and/or cli utilities?
<ecraven>most of the larger ones are suitable for that ;)
<ecraven>gour: my suggestion would be, start with one (guile isn't a bad choice here), look how you like it
<ecraven>if you find features you need, but which guile doesn't have, either implement them yourself, or look at other implementations
<ecraven>but guile has tons of libraries, you'll find most of what you need pre-made
<gour>ok, learning guile would pay of for gnucash reports as well...
<ecraven>and guixsd, and many other projects
<ecraven>if you learn one Scheme, it will help you with all others, just the libraries are different
<gour>guile's gui is still gtk2? any plan for gtk3 support?
<ecraven>what's your favorite editor?
<gour>ecraven: but Elisp is a bit different
<ecraven>if you know emacs, you should look into geiser
<ecraven>yes, elisp is not Scheme
<gour>starter with the Emacs...using for general writing, orgmode...
<ecraven>geiser has support for guile,
<ecraven>M-x list-packages
<gour>that's why i did originally asked about Emacs & using Guile for it :-)
<gour>let me use-package for geiser...
<ecraven>M-x run-geiser RET guile RET
<gour>very nice
<gour>i know that racket has its own multi-platform library...but wonder any other scheme could be suitable for writing multi-platform (although linux is my native platform) desktop app (i hate JS and browser apps) with good support to bind 3rd party C libs?
<ecraven>again, most of the larger ones have some sort of bindings to GTK or QT or so
<ecraven>and most have a decent FFI
<gour>i'm excuse for being ignorant, but i'm aware only of racket's gui. :-(
<gour>*i excuse myself
<ecraven>gour: well, it depends on what you want to do. what kind of application do you want to write?
<gour>ecraven: 'typical' desktop app, using 4rd party lib to speed up some computations, having sqlite3 as storage back-end...
<gour>ACTION is reading
<manumanu1>amz3: haha, like in all other parts of my life. But anyway, the for-loops are easier than hey look. You can get 98% of racket's functionality with a quarter of the code.
***manumanu1 is now known as manumanumanu
<manumanumanu>are there any non-slow way of comparing symbols/keywords < > = ?
<manumanumanu>how are they represented internally? Is converting to and from strings expensive?
<civodul>manumanumanu: symbols and keywords are "interned", meaning you can compare them with 'eq?'
<civodul>and 'eq?' is pointer comparison (very cheap)
<manumanumanu>civodul: the thing is, I have been using them as keys in an assoc, and I need to sort them :) My option seems to be to convert them to strings, but that seems rather expensive
<civodul>oh right, use strings in this case
<civodul>quizz: which of the following options consumes less memory?
<civodul>the string "(a b c d e)"
<civodul>the list '(a b c d e)
<civodul>the list '("a" "b" "c" "d" "e")
<cmaloney>trick question?
<happy_gnu[m]>The first string civodul?
<civodul>probably the first string, followed by the 2nd list, followed by the 1st list
<civodul>this one is a simple example, but i was wondering about this in the context of a big CPS dump
<cmaloney>Wouldn't the list of symbols be using different memory?
<civodul>(as in "guild compile --to=cps")
<civodul>cmaloney: symbols are interned, so the amount of memory used depends on the frequency of occurrence of these symbols
<stis_>hey guilers!
<manumanumanu>hey stis_
<manumanumanu>stis_: what are you up to?
<stis_>analyzing python constructs and what it means for scheme, also a python->scheme compiler
<stis_>for example an object system that i similar to python and how to make a similar exception mechansims as in python using goops
<stis_>I've also hacked guile to autocompile python files, in discussion to get it into mainline
<stis_>e.g. not python but the nessesary code stubs that must be included in guile in order to get autocompilation of multiple different langugages working
<stis_>manumanumanu: and you?
<manumanumanu>stis_: ported a piece of common lisp code for working with ID3 and Vorbis tags
<manumanumanu>factoring some stuff out into libraries
<manumanumanu>the whole tagging part is still too wonky, but there are some stuff I can see myself reuse
<manumanumanu>BTW: why do we use alists instead of plists?
<stis_>really don't know, but I think that plists is used in the guile compiler though as a list of directives
<dustyweb>tl;dr "there's no fundamental difference between them, just convention, but plists tend to be mutated while alists don't"
<manumanumanu>dustyweb: hmmm. thanks.using plists with apply works in guile as well.
<cmaloney>ACTION feels like he's slacking
<stis_>listening to music and writing about functional programming for my relatives on facebook (I live in another city)
<stis_>it's cool to try to write with words so that even my mother understands.
<manumanumanu>I can't even get my .net-programming friend to understand what macros are. Probably my fault :(
<stis_>I think that macros are more difficult to explain in order to show it's uses, generally it just means that your language can be tiny and that your programming experience can be infinitely rich.
<stis_>the drawback is that people have a hard time seeing what the macros does from source code in case they are complex and under documented and you end up having hard time understanding the code
<stis_>but using advanced functions abstractions also have this problem so donugh, when you don't want the applicativiness of a fucntion or bind variables it's a must else functins usually is fine
<stis_>My focus on functional was the ability to frreeze instruction and pass it to a rotine that can execute it at the right places e.g. higher order programming and show why python is not especially functional because the yield statement is local to the function frame, and non tail calls means that you cant make some abstarctions with functions
<stis_>actually I added the ability to place a yield in another frame inmy compiler and also the functions are the proper scheme tail call ones
<manumanumanu>stis_: I managed to explain them by example, to which he replied "we do that wih templates". At least until I showed him the for loops :D :D
<manumanumanu>Now, good night
<manumanumanu>dustyweb: hmmm. the alist stuff in scheme very much lends itself to mutation, and not in a very pretty way.
<manumanumanu>whereas, writing your own persistent alist/plist is pretty simple
<dustyweb>manumanumanu: I mean, any of these things can be mutated.
<dustyweb>if you have mutable cons cells
<dustyweb>you *can* mutate
<manumanumanu>of course, but the way to work with alists lends itself much better to a mutable way
<manumanumanu>even the docs use set!
<dustyweb>manumanumanu: ok
<manumanumanu>it doesn't matter though.
<dustyweb>manumanumanu: like I said, it's convention, if anything, and the convention is not as strong in scheme land because mutation is somewhat more frowned upon here than in common lisp
<dustyweb>but that, too, is convention of the community, since nothing in scheme stops you from mutating like crazy. (at least we have the ! suffix though)
<dustyweb>(! is also convention !)