IRC channel logs


back to list of logs

<cmhobbs>does anyone have a good comparison of racket and guile? i think i read somewhere that racket is kind of leaving the sfris a bit
<cmhobbs>i'm trying to decide on a language for a current project and guile might be that language
<kristofer>cmhobbs: it's dated a bit, but maybe helpful
<Jookia>"It's LGPL, so it doesn't impose any licensing requirements on your C program," >_>
<cmhobbs>kristofer: thank you
<cmhobbs>Jookia: zeromq takes the same approach
<Jookia>cmhobbs: But it does impose licensing requirements- Good ones, but ones
<cmhobbs>ZeroMQ is safe for use in close-source applications. The LGPL share-alike terms do not apply to applications built on top of ZeroMQ.
<cmhobbs>You do not need a commercial license. The LGPL applies to ZeroMQ's own source code, not your applications. Many commercial applications use ZeroMQ.
<Jookia>The LGPL does apply to applications
<cmhobbs>well, i guess someone ought to contact them
<cmhobbs>the thing i'm building will be libre. should i avoid zmq under that point?
<Jookia>It's not that big a deal since the requirement is basically 'ship your program so you can replace the LGPL parts and don't try to lock out people doing ths'
<cmhobbs>interesting. they're looking to move to the mplv2
<cmhobbs>we're getting off topic, sorry
<Jookia>This is true, sorry
<cmhobbs>anyway, i'm trying to decide if guile is going to be the language for the product
<cmhobbs>it'll end up being an adaptor layer between a message queue and an mta
<cmhobbs>how's concurrency in guile?
<davexunit>cmhobbs: what are your requirements?
<davexunit>cmhobbs: guile has the usual thread stuff. mutexes and whatnot.
<davexunit>a few fun things like par-map and par-for-each, too.
<cmhobbs>talk to a message queue a lot at once, relay to an adaptor layer that eventually spews triggers out to a (yet to be determined) mta
<cmhobbs>nothing huge right now
<cmhobbs>usual thread stuff should work for the time being
<cmhobbs>i'm still real fumbly with guile but i know more about it than any other scheme and i like that it's a gnu project
<cmhobbs>i keep building crap in guile in spurts
<cmhobbs>learn a bunch, forget a bunch, rinse, repeat
<cmhobbs>we initially started this project in guile
<cmhobbs>but i made a damn mess and we stopped work and decided to start over. i know more than i did
<cmhobbs>and we sketched a prototype in ruby
<cmhobbs>so i've got a better idea of what we're trying to build
<cmhobbs>i tire of ruby
<cmhobbs>and oop in general
<cmhobbs>but it pays my bills
<davexunit>pays mine as well
<davexunit>and I'm tired of ruby for the same reasons
<cmhobbs>now we drink, i suppose
<cmhobbs>oh man, looks like guile-zmq is gone :/
<cmhobbs>anyone know of a mirror?
<cmhobbs>i've got a local copy but i have no idea how old it is
<cmhobbs>and autoreconf appears broken
<davexunit>cmhobbs: maybe the url is different due to the new gitorious mirror
<cmhobbs> looks valid
<cmhobbs>bleh, i don't want to create a wikidot account to update the zmq documentation
<cmhobbs>anyone have an account?
<cmhobbs>libtool resolved the exploding errors in that paste, btw
***Korhonen is now known as Frankenlouie
<ecraven>greetings :)
<ecraven>say I were to implement srfi-4 in another FSF Scheme, would I be able to use the source code for the tests that comes with guile without too many problems?
<taylan>ecraven: GNU projects tend to have this neat convention of putting a copyright & license header into every source file, so you can just see what the file's header says.
<ecraven>copyright FSF :) so this should not be a problem, if the other project is FSF also?
<taylan>Guile overall is under the LGPL, so using part of its code might mean your project also has to be LGPL. but there's also sources in Guile that come from software with a more lenient license, like say the typical SRFI license, so it could be even less "encumbered"
<taylan>ecraven: it's more about the license than the copyright
<ecraven>ok, thank you :) (un)fortunately I didn't have to worry about these things much so far
<taylan>IANAL but AFAIK all copyright that isn't your own is functionally equivalent. only the license matters for reuse.
<taylan>happy to help :)
<ecraven>that does make sense
<Jookia>IANALE but wouldn't that just make your test suites LGPL
<ecraven>well, it's not like it has very complicated code, it'd just be easier than writing it all from scratch :)
<kristofer>good morning!
<dsmith-work>Tuesday Greetings, Guilers
<stis>hello guiers!
<ArneBab>ecraven: the other project can be LGPL, GPL or AGPL.
<galex-713>So actually does guile implement javascript?
<kristofer>galex-713: ecmascript, yes. it does not implement the DOM
<galex-713>What’s the difference between javascript and ecmascript?
<galex-713>I thought ecmascript was the name of the standard
<peterbrett_work>JavaScript is the popular name for ECMAScript, as I understand it
<galex-713>Ah ok
<galex-713>And, err, so, would it be *possible* to implement TeX within Guile?
<stis>sure yes.
<galex-713>So it could just load LaTeX and it could be possible to eval it within emacs-guile?
<nalaginrut>galex-713: good idea
<galex-713>And would it be *difficult* to implement?
<nalaginrut>well, depends on what you want, it's not hard to write a frontend on Guile, but not easy to write a good one
<galex-713>What do you mean by a good one?
<davexunit>I finally found the time to write a new language frontend for Guile. it's a pretty nice interface.
<nalaginrut>I mean strong enough to use it in your real work
<galex-713>nalaginrut: and what do you mean by “strong enough”, I mean, what would be the problems of “an easy to write not good one”?
<nalaginrut>galex-713: have you ever implement a compiler?
<nalaginrut>or interpreter
<nalaginrut>hmm...then it's not so easy to explain
<davexunit>for guile, you'd need to figure out how to compile the source language into a language that guile already knows how to compile.
<galex-713>davexunit: you mean compiling it into lisp? assembly? anything between?
<nalaginrut>but anyway, the simplest idea is parsing the code and convert your AST to tree-il, from this perspective, it's not so hard to write a frontend
<stis>well you can rest on an interpreter only without compiling. That's the simplest I think.
<stis>but slow
<davexunit>galex-713: Tree-IL (where IL stands for "intermediate language") is the typical thing one would target
<nalaginrut>yes, write an interpreter with Scheme is easier, but that's not the best way to take advantage of Guile
<davexunit>the language extension I was working on compiled to Scheme
<davexunit>Scheme gets compiled to Tree-IL and s on.
<davexunit>so on*
<stis>The thing is I'm not sure TeX is compilable.
<nalaginrut>actually, I'm continuing to write guile-lua-rebirth these days, the whole last year I was focusing on artanis
<davexunit>stis: tex wouldn't make sense in this case, yes.
<kristofer>galex-713: I'm not an expert, but the code to implement brainfuck has been really helpful in understanding the guile tower
<davexunit>yes, the brainfuck example helped me, as well.
<davexunit>it was also helpful to read the guile-xcb language modules
<galex-713>How much languages are implemented within guile?
<stis>I did a prolog one, both swi-prolog and iso-prolog
<nalaginrut>js/lua/php/joy/brainfuck/prolog, but php seems long time no maintain
<nalaginrut>never tried it
<kristofer>obviously scheme as well :)
<nalaginrut>IMO there's a python one, but dunno how's it now
<nalaginrut>when I done lua, I want to write a wrapper layer to let users write artanis plugins with lua
<nalaginrut>it's not necessary, just funny
<galex-713>Ok, and are all of these are JIT compiled to native code?
<nalaginrut>galex-713: neither at present, but will be native code in the future, maybe JIT
<galex-713>Oh, I thought guile did JIT
<nalaginrut>galex-713: we just have a brand new backend based on registerVM, only if it's done, the AOT (native code generating) can be started
<nalaginrut>not yet
<stis>all compiled langs will benifit from what is done in guile.
<galex-713>So Guile just do compile all these to Tree-ILL and interpret it?
<stis>galex-713: there is a VM that are quite fast compared to an interpreter
<stis>but that is a kind of interpretter as well if you like
<nalaginrut>tree-il is just a friendly layer for compiler writers, more work and IRs in the lower level
<nalaginrut>with tree-il, the frontend writer don't have to care the complicated compiling optimizing
<galex-713>Oh I see
<nalaginrut>something similar to LLVM IR, but Guile is for functional programming languages, IMO
<galex-713>TeX is functionnal
<galex-713>So could it be possible to implement it?
<galex-713>at least to being able to load and expand it within guile
<galex-713>at most maybe to compile it to image/pdf/whatever
<galex-713>or even text and html
<davexunit>you wouldn't use guile's compiler tower for this
<davexunit>the output of guile's compiler is a guile object file which contains bytecode that can be run on guile's virtual machine
<davexunit>this wouldn't make sense for tex.
<galex-713>Oh yeah I see
<galex-713>Oh also, is it possible with guile to use a function of one language in another?
<bavier>by default, but you could implement a tex->html compiler in guile scheme
<stis>davexunit: you can always compile to (TeXeval "string")
<stis>so technically you can use the compiler
<bavier>that is, it wouldn't compile to something executable, or make use of guile's existing tree-il compiler
<galex-713>bavier: stis: wait, sure? TeX is a functional language like another, I can defun \\fun, with two args, and maybe wanting to be able to compile what it does to bytecode in order to get its output in function of its two (string) args, right?
<davexunit>I think it's wrong to say that Guile is only suitable for implementing functional languages
<galex-713>Ok, but anyway TeX is one
<davexunit>sorry, that was more of a comment for nalaginrut
<galex-713>I’d like to know if I could be able one day to eval \\fun{thing}{other} within emacs using guile
<nalaginrut>davexunit: never mind, but it's good for continuation based languages, usually they're FP
<bavier>galex-713: that should be possible, I don't see why not
<davexunit>nalaginrut: sure, that I can get behind. :)
<galex-713>bavier: that would be awesome, I want to use TeX-quality output everywhere
<galex-713>Imagine a webengine written with guile, featuring ecmascript and using TeX
<galex-713>And imagine it displaying Emacs UI
<galex-713>Well, no, imagine any graphic engine using guile and TeX, and also doing web engine btw
<ecraven>I don't see how TeX is especially functional :-/
<galex-713>Well the only sideeffect is var definition
<galex-713>And even scheme does that, along with a lot of other things
<kristofer>galex-713: I've also wondered if the guile tower might be able to replace spidermonkey or v8, allowing scheme to be used in the browser
<galex-713>kristofer: would be awesome
<galex-713>But maybe we should switch it to LGPL if so, no?
<kristofer>it's ambitious..
<galex-713>GNUnet is more ambitious
<stis>galex-713: do you know about texmacs?
<galex-713>stis: yes, I know its developer
<galex-713>The only problems it has is C++, some bugs (due to not enough contribution though I think) and it’s not emacs (so I loose all my lisp code, macros, modes, etc.)
<galex-713>I’d like if Emacs became a new TeXmacs
<galex-713>and replaced the LibreOffice shit btw
<galex-713>because XML should die, and C++/Java too
<nalaginrut>well, it's interesting if it can replace v8 someday, that means we may never need js
<galex-713>and because it copied Word which implement contradictory concepts
<nalaginrut>but back to the earth, maybe add WASM as backend to Guile is more reasonable
<galex-713>nalaginrut: what’s WASM?
<nalaginrut>it's a new ASM in this era written in JS
<nalaginrut>js become an industry standard nowadays, but it sucks, and can't be changed
<nalaginrut>the best solution IMO is let it be a new ASM, and we never use it directly
<nalaginrut>then we can use any language we like, and compile them to js(as kind of assembly)
<galex-713>Well replacing spidermonkey is a good way to kill javascript
<galex-713>and to get more developers
<galex-713>bavier: but if we implement TeX within guile, would it use Tree-IL?
<amz3>galex-713: it depends, but I would say no
<amz3>pdf or html is the compiled form of latex
<bavier>galex-713: idk, it would depend on the implementation, compiling tex directly to pdf, or compiling tex to guile object code via tree-il that produces a pdf when executed.
<bavier>the latter seems interesting
<nalaginrut>I suddenly got an idea to research the sound system on Linux, and I found someone has used Guile for his Sound software almost twenty years ago,
<nalaginrut>it's interesting, he said it's nice experience
<bavier>just found out about this software that includes guile scriptability:
***Frankenlouie is now known as Friedriechson
<daviid>wingo: hello! Chris Vine reported a Guile-Gnome bug, segfault actually, related to the use of g-idle-add. He first thought it was a guile/guile-gnome thread related problem, but I convinced him it was not. Here is a code snipset which segfault, if you let it run for a couple of minutes. Then at the end of the paste a manually cleaned strace of the segfault 'session'
<daviid>wingo: I hope you will find some time to help me with this one!
<wingo>i will try but prolly not tonight :)
<daviid>wingo: ok thanks! I really did my best to prepare ... hope you'll find it clean
<paroneayea>greetings, *
<kristofer>why does longest always return an empty list?