<saul>In ice-9 'threads', why is there a need for 'letpar'? Doesn't R5RS allow 'let' bindings to be evaluated in parallel? <mark_weaver>in R5RS, the initializers can be evaluated in an unspecified order, but they must be evaluated in some serial order. <mark_weaver>and ditto for the order in which operands (and the operator) are evaluated in a procedure call expression. <saul>What benefit does requiring a serial order gain? If the arguments can be evaluated in any order, why not in parallel? <ijp>saul: typical race condition I think <saul>Perhaps so that it is known when all of them have be evaluated (and the application of the procedure occur)? <mark_weaver>well, suppose each initializer in a let calls a procedure that consults a counter and increments it, to get a unique id. <mark_weaver>you may not know the order of these unique ids, but you don't have to worry about mutex locks and such. ***fangism1 is now known as fangism-ctrl-Z
<taylanub>I made a change to the thread creation code and now am getting random segfaults during make check. :( Gotta hate indeterminism. <wingo>why did you make a change to the thread creation code? <taylanub>wingo: Guile simply aborts when thread creation fails due to running out of FDs. <wingo>in the meantime just use futures :) <taylanub>I added some machinery to propagate errors back up during thread creation, but how I did it might be quite contrived, I'm not sure; will post to the ML if I get it to actually work. <taylanub>wingo: by the way, when I try to build master, I consistently get an out-of-memory while compiling assembler.go. (I think the limit is ~512 MB, should be enough?) Could be something OpenBSD related again, but in case you have an idea... <wingo>taylanub: dunno; there are things we can do to try to reduce memory use, but i don't understand enough where the usage is coming from <wingo>i would suggest doing a make -k and then once more of the compiler is compiled, compiling assembler.go should take less memory <wingo>why does your process have that memory limit? <taylanub>oh, I could just increase it then, I assumed something was simply broken :) <taylanub>~500 seems to be OpenBSD's default ulimit -d *taylanub will probably switch to Debian or so soon :P <nalaginrut>there're so many servers was/will be restarted because of CVE-2014-0160 today, include mine... ***ijp` is now known as ijp
<Onslauth>Hi guys, is there a page describing the output from gc-stats? <Onslauth>Sorry, is it a fixed size determined by some variable? <Onslauth>Would you guys mind if I ask a few questions about the output of gc-stats? ***Fuuzetsu is now known as Guest41168
<ijp>just ask them, I don't guarantee an answer ***Guest41168 is now known as Fuuzetsu
<Onslauth>Ok, i am busy looking at the output from gc-stats ***Fuuzetsu is now known as Fuuzetsu`
<Onslauth>but I see a lot of it is pulled directly from bdw-gc functions <Onslauth>I wanted to know if heap-size is always a fixed value, as I dont see that changing, but the rest do. <Onslauth>Is heap-total-allocated the current total bytes allocated, or the total bytes allocated since start of program? <Onslauth>Ok, I see the functions are all part of bdw-gc, i'll try track them down there. Thanks for the help. ***linas_ is now known as linas
<vinek>So...how extensive is the elisp support? <vinek>I ask because I'm browsing the git repository and it says that it will have full elisp support in 2.2. <taylanub>vinek: We can run most/any non-trivial Elisp program, e.g. dunnet was tested AFAIK, although some fundamental user-interface types like windows are missing, which should be alleviated via the actual Guile/Emacs integration effort whose last status is at http://git.hcoop.net/?p=bpt/emacs.git <taylanub>The effort was/is mostly/entirely driven by BT Templeton aka bipt during GSoCs, I dunno about the GSoC of this year. <vinek>Okay. I just wanted to play with it separate from obvious emacs apis. <vinek>Okay...is guile-elisp going to be distributed with guile or emacs? <taylanub>The purpose is to make upstream Emacs Guile-Emacs, since Guile-Emacs is (meant to be) a drop-in replacement. <fcsa>Hello, #guile. I would like to present a free as in freedom Skype replacement: Tox. Tox is a P2P, totally distributed, trustless network. The core is written in ANSI C and there are many clients/frontends for it. <fcsa>I would like to invite you to make a Guile wrapper and Client for it, as there is no good Multi-platform (Windows, Linux, OS X, BSD, etc.) for it. <taylanub>(Just faster and with some added features, like being able to execute Scheme natively.) <vinek>taylanub: But you can also use elisp packages outside of emacs, right? That is, if they've been separated from emacs apis. <vinek>Which means emacs would have to actually define an api I guess. <taylanub>fcsa: Neat! I know Tox from somewhere but don't remember where, it looked very promising last I looked into it. <taylanub>vinek: Yes, though I can't imagine someone learning Elisp as a stand-alone language when Scheme is right next to it. ;) <fcsa>It's developing quite nicely. Audio and Video have been already implemented in the Core and now TCP Client/Server is being done in order to be useful at mobiles <vinek>taylanub: Not for that, but for using e.g. org-mode on the command line without requiring an emacs installation. Calc could be distributed as a separate package. Etc. <taylanub>vinek: Good ideas, didn't think of that. <davexunit>tox looks interesting, but I'm dubious of how secure it is. <davexunit>I talked to someone involved with tor about it and they didn't seem very optimistic. <fcsa>A security audit will be done before it's considered secure and goes stable. <taylanub>Not going through Microsoft servers is a good start for better security compared to Skype. :P <davexunit>but I do wish tox the best because it's needed software. <tupi>fcsa: what is its license, i can't find it on the web site <tupi>fcsa: may i suggest you make it clear on the web site, also in the title, like <fcsa>The main website (tox.im) is destined to the general public, such as your grandma. We don't want to put anything the mainstream people wouldn't understand or care. <fcsa>The license is in the Github and Wikipedia. <tupi>fcsa: i disagree, the grand public must know and should be more and more beeing teached what it means and why we care, why they should care too ... <fcsa>Stallman (rms) asked us if we wanted to become a GNU package, but the main developer refused because he thinks GNU doesn't push free software enough. <tupi>but it's just an opinion of course ... <davexunit>fcsa: I wish that the screenshot on tox.im wasn't from windows <fcsa>As in, the FSF and GNU care about Free Software, but when it barely works, that's fine by them. Do the end users have to set up servers? "So what, it's better than proprietary garbage! It's god already! Just learn how to set it up!" <fcsa>Tox has the vision of making it extremely easy for the end user to use it, gaining more adoption. <vinek>fcsa: That isn't what "doesn't push free software enough" means to me. <fcsa>user friendliness isn't taken too seriously over the FSF <fcsa>My bad, perhaps my wording wasn't too precise, vinek <davexunit>fcsa: at libreplanet a few weeks ago it was stressed over and over again that free software needs to be easier to use. <vinek>fcsa: It sounded misleading. <fcsa>But Tox wants to actually have people using Tox, even those who don't care about their freedom <ijp>fcsa: I can't say I like the name <fcsa>It's a play with "Talks" <ijp>it's the part where it shares a root with "toxic" that bothers me <tupi>fcsa: jitsi stated on its home page, quite clearly, almost as its principal 'feature' that it's free software, fyi <davexunit>I don't want to be too negative, but I think it was a strategical error not to join with the GNU project. <tupi>imo, it is as important as beeing easy to use <fcsa>Well, try reasoning with the main developers at #tox-dev <fcsa>I don't have access to the core, I just pull some commits here and there <didi>Heh, GNU doesn't push free software enough but the main page doesn't mention software freedom because some people just don't care. <tupi>yes, it's like people promoting political resistence and calling themselves pirate.org ... <vinek>fcsa: It isn't always clear what is meant by "user friendliness". People don't distinguish e.g. familiarity and usability. You could clone Skype in every facet, and that will help bring Skype users. <fcsa>Skype is seen by many people as bad in the graphical sense. <vinek>But chasing familiarity is chasing a moving target. When the GNU project started, Unix was popular, and so the command line environment was familiar with a lot of people. <fcsa>Actually, just try Tox out and see for yourself! Apart from some things missing (such as usernames), it's already pretty user friendly as in: easy to use, no configuration, intuitive. <davexunit>regarding the topic of guile bindings for libtox (or whatever the name may be): I could see it being useful, but we currently lack good bindings to other libraries for making a good graphical client. <fcsa>Someone started working (as a hobby) on a Racket wrapper to later make a client. Perhaps that helps? <taylanub>Anyone know how I can install two similar versions of Guile at the same time, like 2.0.11 and stable-2.0 ? With --program-suffix it still overwrites "libgulie-2.0" so all "guile" executables with different suffixes actually launch the same Guile. <fcsa>Anyway, I've seen great work on Guile concerning Graphical Interface <tupi>davexunit: are you sure? guile-gnome-platform, guile-clutter are very good imo <tupi>they just need a bit of love :) <davexunit>fcsa: roughly how large is the public API? I don't have time to look at the source right now. <didi>guile-gnome needs work last time I checked. <davexunit>fcsa: is there documentation in a format that can be used to automatically generate bindings from? <davexunit>for example, you can generate opengl and xcb bindings from XML files. <fcsa>davexunit: Small. Around 70 functions, I believe? <tupi>didi: it works perferctly fine <DerGuteMoritz>why would you start a new crypto-based project in C today :-( <fcsa>What do you mean, DerGuteMoritz? <taylanub>DerGuteMoritz: It's a Skype replacement. <tupi>didi: no, it's just that it still uses gtk2. i'm trying to get some resource to write guile-gnome-3, but that does not mean guile-gnome-platforme-2 is not ok, it is perfectly ok, using gtk2 <didi>tupi: Even using gtk2. I couldn't make it work, even though people kept saying it was working fine. <taylanub>To be fair, wasn't that just some simple logic mistake in the code that could happen in any language ? <tupi>didi: i can help you, what do you mean couldn't make it work? <tupi>if you still are interested of course <fcsa>Let's not start a language flamewar, shall we? ;-) <DerGuteMoritz>taylanub: didn't it allow you to remotely read arbitrary memory blocks? <ijp>this isn't really a flame war <didi>tupi: Thank you for your assistance. I appreciate it. But I'm not interested in the moment. <taylanub>Guile is written in C so I don't think anti-C flaming would go very far here. :P <tupi>ok, but out of curiousi, was it a compiling installing problem? <DerGuteMoritz>yeah there's no 100% safety anyway, but you can start at a higher level than 0% at least <ijp>it's a flame war in the sense that throwing a match away on embassy soil is a flame war <fcsa>Nice fact: Tox (the Core) compiles on a wide range of operating systems, from Plan9 and Inferno to Haiku and MINIX <davexunit>fcsa: so it should be fairly easy to write wrappers for these functions using Guile's C FFI <fcsa>I've seen that, DerGuteMoritz <fcsa>davexunit: Nice to hear that! <didi>tupi: I can't remember now, I'm sorry. And I know it's not really fair saying something "doesn't work" and not point out what one means by "doesn't work". But I remember the dissonance between those saying "it works!" and me. <davexunit>fcsa: I see "typedef struct Tox Tox;" but where is the struct defined? <davexunit>the less custom data types, the easier the wrapping becomes. <fcsa>davexunit: the struct Tox isn't actually called unless it's in pointer form. <fcsa>Apart from that, I'm not really sure. Try #tox-dev <tupi>didi: it work perfectly fine, it is a fact: i use it since it exists, every single day... and as you probably know, i also developped a free s/w app [kisê], which is installed on some of my customer's servers as well ... so yes, i thing one should be carefull saying it does not work <didi>tupi: I didn't work perfectly, even though people kept saying it did. <tupi>didi: i assume you had difficulties to compile/install which i understand, it's not excatly easy. when i say it works didi , it is because i've had no bug, not a single bug, in years of daily usage. whenever you're interested, i'll you the best i can to use it too <taylanub>DerGuteMoritz: Aha, "Is this a MITM bug like Apple's goto fail bug was?" .. two SSL bugs revealed in short time. :\\ <didi>tupi: I think you are right. I couldn't compile/install it. There was also no working release IIRC. <tupi>s/to use it/to help you to use it too <tupi>didi: ok, that's another thing, let me know when you're willing to try again then <didi>tupi: I don't think it's another thing. It's part of the project. <DerGuteMoritz>taylanub: this one is even worse than the goto fail bug. but yeah, the frequency of vulnerabilities being found in openssl is quite staggering. <tupi>didi: i won't enter further in the discussion, but i'll help you to my best as i did say <didi>tupi: It's very kind of you. I appreciate it. Thank you. <fcsa>I will keep track of your Github, davexunit. Hope to see a Guile and/or Haskeel wrapper and eventual Client there one day ;-) <davexunit>fcsa: check gitorious, it's where I host code these days. <taylanub>`scm_with_guile' returns void*, so it can't use the return value to signal an error (or is NULL an invalid return?). An option is to add an e.g. `int *err' argument which if non-NULL it fills with a non-zero value; however, an error happens very rarely there. I don't know how often `scm_with_guile' is used in common C code; would it be too cumbersome to add another argument to it ? <taylanub>Are there more alternatives to error-reporting in C ? I imagine some global variable could be set (not good), or with C11, a thread-local one (better?) <ijp>taylanub: I didn't know you *actually* used guile <taylanub>I'm trying to patch thread creation to signal errors. <didi>Tho getting rid of the limitation is the best outcome. Documenting such limitation in the manual is a good start. <taylanub>didi: That'd be more difficult; apparently we use two FDs per thread, for some reasons, and OSs do limit FDs allowed to a process .. <taylanub>`ulimit' should be able to set it by the way. <taylanub>"ulimit -n" it is .. Bash manpage says "most systems do not allow this value to be set" <didi>Racket doesn't seem to have this limitation. Or at least, it doesn't abort. It has "green threads" but I don't know exactly what it means. <taylanub>didi: That means it doesn't use pthreads .. but that's not relevant because what limits Guile is that it uses up 2 FDs per thread, for reasons of its own (i.e. not something intrinsically tied to pthread creation) <didi>taylanub: Tho IMO it's relevant. <taylanub>It might be relevant in that with pthreads, one perhaps doesn't have a portable alternative to FDs for certain things ? Mark's words: "[...] for every thread that's ever put into Guile mode, Guile creates a pipe which is used to wake it up while it's sleeping or waiting in 'select', e.g. if an async is queued." <didi>I'm talking about the thread abstraction. <taylanub>no idea if there's other portable ways for waking up a pthread, but yeah, with green threads I guess one would have a custom mechanism for that ? anyway, I'll continue on my patch <ijp>davexunit: preemptive, I think <ijp>read the fine manual! <ijp>I'm not a great fan of the css change though <davexunit>ijp: just didn't have time to read the manual right now. but I _did_ have time to bug you fine folks. ;) <ijp>scheme.guru is available if any of you are looking for a tld *taylanub didn't know .guru TLD exists <ijp>taylanub: there is a ridiculous number of them <ijp>e.g. there is a .ceo <taylanub>Is there some cleanup I can do on the source directories that won't remove the .go files that take eons to compile ?