IRC channel logs
2014-08-01.log
back to list of logs
<taylanub>wow, my mindset was that doing or not doing Cheney-on-MTA is a fundamental design decision that cannot just coexist with other approaches .. the more you learn the less you become prone to black&white assumptions <mark_weaver>oooh, gdb 7.8 came out, the first release with support for Guile scripting :) <tadni>davexunit: Just saw you renamed Guile-2d ... it took a minute or two to understand the branding, but. I like it! *tadni is excited to do a gamejam with it next-year. <davexunit>but a contributor came along and is adding joystick support. <davexunit>I'm slowly trying to get things together so I can apply to be a GNU project. <davexunit>I need to get a working scene graph and write docs, mainly. <davexunit>maybe next year it will work decently enough to be used for a game jam. <tadni>davexunit: That would be great! Man, I'm so excited of the ecosystem slowly being formed around Guile and/or for the GNU system. It's really what's pushing me to want and rationalizing myself to learn Scheme. :^) <davexunit>I have some performance issues right now, but I think I just need to finish basic functionality and make a release. <tadni>davexunit: Yeah, unless it's dreadfully slow -- features before speed ... unless it is something inherently flawed in it's core. :^I <davexunit>tadni: yeah, it's exciting. guile really is some top-notch software. <davexunit>maintained by 3 very smart people, with a small, but friendly community. <davexunit>tadni: I don't think it's an inherent flaw, I just haven't optimized certain things yet. I blame it mostly on the lots of matrix multiplication that's happening. <tadni>It's what is really getting me into ELisp because I want to know enough of it to make the switch to Guilemacs when that's ready. It's kindof been my segway and it's been fun thus far. :^) <tadni>davexunit: Andy, Ludo, and whose the 3rd? <davexunit>3 co-maintainers is a pretty nice thing for a software project to have. <tadni>Yeah, Guile and projects like Guix and Dmd have kindof single handily restored my hope for GNU's relevance in the years to come. <davexunit>I hope that the GNU community embraces Guile more. <tadni>davexunit: I'm pretty sure that if the GNU distro picks up any steam (even if it's just becomes the primary free-software dirsro community in this niche (taking over Trisquel and Parabola)) we will see at least more of an interest from developers in-general. <davexunit>agreed. will be tough to unseat trisquel and parabola, but it's also important not to view it as a competition, because those projects do great things for software freedom. <tadni>Yup, I much rather have "competition" in the from of a project that has the same goals/ideals in any case. That being said, I think having GNU becoming the "standard" of the Free Software community, will do a load for GNU's branding and too hopefully earn GNU more acknowledgment from the rest of the greater community. <tadni>30 years in and it feels like the beginning of this great journey, once again. I'm pretty hopeful we have the infrastructure in-place now though to deliver something stellar. <davexunit>the GNU system stands out over fully free distros because it's a leader, not a follower. It's not ubuntu or arch with nonfree stuff removed, it stands on its own. <tadni>davexunit: True and it's doing stuff that really one other distro can claim to do and even then, said mentioned distro is not even in the top 10 (maybe top 20-30) distros out there, being used right now. <tadni>We are of course lower than that currently, but we have MUCH room to grow, just if we don't expand further than just the Srong Copyleft community. <davexunit>it's nice to not only have free software, but to have free software that has better features than proprietary software. <davexunit>and it's good because I'm worried about the future for existing flagship GNU software like GCC. <davexunit>if LLVM/clang beat GCC, it won't be good. :( <tadni>Yeah, though features aren't always an appeal to the general public. That's why I'm so glad that GNOME is a GNU project, it is something that I can see my Mom or Sister using without a problem and know that they don't have to compromise their freedom for x, y, and z. <tadni>davexunit: People are very worried about that and namely, that Linux will go LLVM/Clang over GCC... so worried that they want increased development to take place in the realm of the Hurd. <tadni>I've heard this a couple times in the past couple months. <davexunit>yeah, there's lots of speculation, who knows what will happen. <tadni>That being said, I would love if the Hurd team would do a fundraiser for a rewrite one of these days. <davexunit>a rewrite? that might be a bad idea considering how many issues the project has had already. <tadni>Yeah, I'm not saying a major rewrite really as much as a port off Mach. Mach is ancient and it sounds like it's hard to do anything of adequate complicity with the Hurd without heavily and messily mucking up Mach more. There has been some attempt ports to other micro-kernels, but to no avail thusfar. <tadni>If I ever do my masters, I'm probably going to do a microkernel as my thesis. Seems so fun. <tadni>But right now, I know so little beyond that of the trivial. <daviid>hi davexunit, how are things these days? right now i'm working on a couple of clutter examples, it's fun. i have to push guile-gnome, guile-clutter patches, g-wrap doc updates and house keep its html pages... lots to do but now i'm having a little fun :) <davexunit>daviid: that's some good work you are doing. being able to write gnome applications in guile will be a great thing. <daviid>davexunit: everytime i play with clutter i think about you :), guile-2d and sly ... :) <davexunit>I just merged a patch from my first major contributor today. <daviid>davexunit: there are guile-gnome applications already, i'm just [trying to] updating it... <daviid>but clutter is a hip hop library really <daviid>still is I mean. with 1.12.2 we'll have a scrolling actor, which is really necessary for app not using gtk, the all thing in clutter i mean... <davexunit>I'd be very interested in seeing a small demo application for guile-clutter <daviid>I know nothing about gaming, but I very curious to see if you think it would be possible to use clutter. having said that, I really understand you want to program your own gaming api in guile, just curious really <daviid>davexunit: i very nit picky about what i write and push, because it becomes public.. :) but I am finalizing 3 clutter examples and shouyld push that in 1 or 2 weeks <daviid>do you have a guile-gnome installed? <mark_weaver>I was the one who persuaded davexunit to use pure scheme for the important components of his game library, and now daviid is trying to persuade him to move much of the core functionality to a C library. <davexunit>mark_weaver: heh, I'm being tugged in 2 directions. <mark_weaver>here's the thing. first of all, whenever you use C for such an important part of the animation, you lose a huge amount of flexibility that you get by using scheme. <davexunit>pure scheme is the way I want to go, unless clutter had something that I haven't even imagined that is really great. <mark_weaver>and there are many thorny problems associated with garbage collection that come into play. <davexunit>I use C libraries for the really low level stuff only. <davexunit>guile-opengl, guile-sdl, and a couple functions from an image loading library. <mark_weaver>fwiw, it's not that I feel the need for everything to be written in a single language. however, moving GC-based languages with non-GC languages has very serious problems. <mark_weaver>I realize that in practice we need to mix with C, but it's good if we can push that mixing to the lower levels as much as possible. <daviid>mark_weaver: sure, to the extreme, i'd like an os written in guile. i'm not trying to persuade davexunit, but share ideas and clutter is really nice, well thought, concise... now, maybe i should write clutter using sly ... instead of maintaining guile-gnome, guile-clutter ... that is [also] a way to go <davexunit>I think guile-clutter is good to have, but probably not for my project. <davexunit>and sly wouldn't be a good fit for projects that want clutter. <daviid>i still would like to know if it would be feasible though [sly written using clutter I mean], i'm really curious <mark_weaver>the question is not whether it would be feasible. of course it would be feasible. the question is whether the pros would outweigh the cons. <mark_weaver>there is a huge impedance mismatch between C and Scheme, both in terms of calling back and forth between C and scheme (callbacks, etc), and in terms of pointers between C data and Scheme data (think GC, finalizers, etc). <mark_weaver>so, the boundary between C and Scheme code is a messy one, and IMO it's a good idea to keep that boundary from running right down the middle of your programs primary area of interest. <mark_weaver>now, if you're writing a GUI program, and the animation that clutter does is at a lower-level than what your program's primary domain of interest, that's fine. <mark_weaver>but for sly, the animation is at the core of what it's trying to do. <mark_weaver>having said all that, borrowing some _ideas_ from clutter would not entail any impedance mismatch, so maybe it's still worth looking at for that reason, I don't know... <davexunit>yeah, I have plenty to learn about scene graph implementations <davexunit>currently working on cameras and the matrix math behind it all <daviid>on the pro side, i'd say that it is an advanced and very good library: we could use it _and_, as time goes along, rewrite part of it in scheme [guile-opengl ...]: that would save a lot of time, merge our efforts, and I beleive also save 'us' from some [not to say quite a lot] of design mistakes, maybe [no offense here, but knowledge is experience, these guys, ebassy and company, have been in the stage biz for years, so there is a lot to <davexunit>sure, there's a lot to learn from, but my needs and goals are different. <davexunit>there's not much existing software that works like sly does. <davexunit>I've borrowed concepts from a lot of other projects, but collectively it's quite unique. <mark_weaver>the thing is, no matter how smart they are, they are constrained by the fact that it's a C library, designed to run in an environment without GC. <daviid>ok, the the question is [for me]: for how long will sly be around? if it becomes a guile co-maintainers maintained project, for ever, then i'd prefer to write the stage part upon it then having to maintain guile-gnome and guile-clutter <mark_weaver>looking closely at clutter is probably a good idea, to learn from their experience and to avoid making mistakes, yes. <davexunit>daviid: the problem with that is that sly will not work nicely with GTK, it specifically uses a OpenGL context for all rendering. <daviid>davexunit: clutter does not use neither requires gtk <daviid>the main Q is: it must become an official guile project <mark_weaver>daviid: I vaguely remember hearing of a plan to make GTK use clutter at some point. is there any truth to that? <mark_weaver>and gnome applications are increasingly using clutter for their UI. <daviid>davexunit: yes. mark_weaver i'm not sure but i'v heard aboiut that idea too <daviid>i beleive clutter will become the gui for future apps, no gtk... because of smartphones and friends <mark_weaver>daviid: you think the plan is to phase out GTK entirely? that would surprise me. <mark_weaver>but admittedly, I haven't been following the gnome community much lately. <daviid>davexunit: you could provide sly without SDL, i mean 2 levels of sly, the core, and for the gamers... <davexunit>maybe, but there's really nothing left to sly if you remove the parts for game development. <mark_weaver>I vaguely thought the idea was to use clutter as a base for the UI, yes, but for GTK to still be in the picture but on top of clutter. <davexunit>that might be the case, I also haven't closely followed GNOMEs development. <mark_weaver>in any case, for normal GUI apps, there is generally a huge advantage to using the same toolkit libraries as the rest of the system. <daviid>mark_weaver: no, gnome will still use it. but I think in a [long] future, clutter will include actors that will render possible full app in clutter. gtk will exist for ever i think, it will use clutter [clutter-gtk] to beter integrate clutter stage(s) in a gtk ui ... <daviid>guile should think about making sly an official project, then i would use it <davexunit>daviid: I would like to be a GNU project, it will take time. <daviid>in 25y i have seen too many ui projects falling apart and dying in the dark... <daviid>davexunit: that's not a problem, the problem is to be officially maintained by guile <daviid>GNU of course, but that's 'easy' <davexunit>daviid: well sly needs to prove it's usefulness first and be used for a real piece of software. <daviid>the difficulty is 'it has to be here for ever', with or without you :) <davexunit>and by "maintained by guile", do you mean become part of the guile source tree and distribution? I would think it's better left out of that due to its size. <mark_weaver>daviid: I don't think anyone is suggesting that sly should be a base for normal GUI apps. <mark_weaver>daviid: so, I think that guile-gnome and guile-clutter is still needed. <davexunit>sly is specifically focused on the things that video game developers need. <mark_weaver>it would be good to rewrite guile-gnome and guile-clutter in pure scheme (no C) and based on GIR, which should significantly ease future maintenance. <daviid>mark_weaver: that would be great yes. it is also in my plan, but since we have what we have, and because i'm learning while doing, i'm happy to update the existing binding. then once i fell strong enough [glib and gobject principely] i'd like to think about gir dynamic ffi based binding... <mark_weaver>yeah, for the short term it's good to update our existing bindings. thanks for your work on that! <daviid>yeh, we have to get rid of guile-1.8 dependency in all distro, that's the first step <daviid>yes, i've seen he said he finally got rid of guile-1.6 <daviid>the thing is distro that have guile-gnome are depending on guile-1.8 <daviid>mark_weaver: i need help, guile quiz, test suite quiz pleeeeaaaase :) would you have a litle bit of time for me? <daviid>could you look at my last guile-gnome [devel] related email ? <mark_weaver>"Subject: guile-gnome, devel: corba test suite fails if using scm_make_vtable", is that the right one? <daviid>i have change calls fom scm_make_vtable_vtable to scm_make_vtable <daviid>as suggested by civodul. but it breaks the test suite and i doubt it is related to corba <daviid>i the original call, the last arg is also SCM_LIST1 (gsubr), but civodul suggested passing gsubr directly [which i think is ok]. the question is, do you have an idea why this simple change would break the test suite? <mark_weaver>sorry, no ideas jump out at me, and I don't have time to debug this now. <ijp>if you use (catch #t .... list), you don't get any hanging behaviour, so we must be trying to get the lock in the repl? <ijp>but the implementation seems to imply that 1. the unlock is added as an unwind handler, and 2. unwind handlers are called when you have non-local exits, so maybe the problem is in a preunwind handler? <mark_weaver>ijp: yeah, I had the same questions, but haven't yet had the time to investigate <jemarch>what you guys think about splitting a module definition on several files? <jemarch>having several files with (define-module (foo) ...exports...etc) seems to just work fine with guile, provided you explicitly load every file <taylanub>jemarch: I think you don't need the define-module form in any but the first file that's loaded <jemarch>well, the idea is for each file to not rely on the others being loaded <jemarch>kind of a "dynamic" module that I can expand at any time, by loading additional files <jemarch>I want a (dynamic) set of classes to be interned in a module (objstore) <jemarch>I could put all the classes in a single file <jemarch>but I prefer to have a directory store/ where I can just drop .scm files defining new classes <jemarch>each .scm file has a (define-module (objstore) ...blah...) which seems a bit funny, hence my question :) <taylanub>hmm, I think I'd just use `include' for that <taylanub>oh, dunno how to iterate over a directory and include every file in it <taylanub>maybe `load' instead. I'm not sure right now what differences it would make <taylanub>I suppose `include' would make it possible to compile the one "master" file at any time and have all the classes end up in the compiled file, whereas `load' would require one to compile all the files in store/ separately and they would be loaded at run-time <daviid`>taylanub: one has to be carefull with the fact that the module that <ijp>why is it important that all of these need to be added to the same module? <jemarch>just to have all the classes interned at the same namespace, yet encapsulated <ijp>that's not really an answer, more a repetition <jemarch>an answer to your question, you mean? <ijp>I can see this being possible, but rather unsatisfying <taylanub>daviid`: indeed, auto-compilation won't fire as the store/ is expanded <taylanub>with the `include' way, that is. using `load' should work better in that regard <ijp>load is include if you give a filename <ijp>jemarch: how do you want to handle exports? <ijp>the simplest solution to your needs is something like (for-each load ((@ (ice-9 ftw) scandir) "yourdirectory")) <jemarch>I have #:export entries on the several define-module. Looks like the resulting export is the sum of all the #:export entries. <jemarch>I am loading the files with scm_c_primitive_load <taylanub>ijp: trying that snippet right now, it's full of thorns -_- *taylanub hates it when simple things aren't simple <ijp>taylanub: I never tried it