[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] # One-stop Development Environment Invent something. # Mailing Lists Add link to [[mailing_lists]] to page, and suggest following these. # IRC, freenode, #hurd, 2013-08-05 hi guys, I'm new here. I'm a developer from Guile community, and I think maybe it's a proper time to do some work to make GNU stuff use Guile increasingly, but I found the wiki and docs seems a bit old, and I can't find an entry from Hurd source, since there're too many things. Anyone point me out? thanks nalaginrut what exactly is it that you need help with? I've no idea, I saw MIG and I think if it's a language I can write a front-end on Guile platform. But someone suggest me write hurd binding will be a good start I cloned incubator which is cl-binding for hurd, but I've no idea too, since there's nothing in master branch well, fixing guile on the hurd would be a start: https://buildd.debian.org/status/package.php?p=guile-2.0 i won't talk about this, as my personal opinion on the matter is that it's not a proper time to do it but at the same time, people should do what they're interested in so feel free to do it braunr: is there any reason why it's not a proper time? nalaginrut: two words: mig sucks so it'll be replaced by a new stuff? any more reasons to have alternatives, no? sure, please do it :) actually it's more than just mig the low level internals of the hurd are almost fine, but not good enough to reliably develop over it gccgo is currently proving it and such projects are good opportunities to identify and fix such issues but the, if you want to work on guile, be prepared to work on a lot more than just guile I'm afraid I have to collect the reasons and evaluate when is proper to do that, if Hurd has to be redesigned, it is not a proper time ;-) it also happened with openjdk, jeremie had to fix signals (!) anyway, I just want a suggestion how to start well, fixing guile on the hurd would be a start: https://buildd.debian.org/status/package.php?p=guile-2.0 ok, I'll try nalaginrut: "incubator" is a somewhat strange beast. every branch in there is a completely different project. you have to find the right branch for the CL bindings... antrik: thanks for reply, I guess it's clisp branch? nalaginrut: http://www.gnu.org/software/hurd/source_repositories/incubator.html nalaginrut: sounds like it :-) braunr: I'm believe it's important to encourage work on as many different levels as possible. there is no motivation for fixing low-level issues unless there are some interesting high-level things relying on these... antrik: i agree 11:50 < braunr> but at the same time, people should do what they're interested in in fact, it's pretty much impossible to identify what we really need at the lower levels unless working on high-level stuff as well... yes 11:57 < braunr> but the, if you want to work on guile, be prepared to work on a lot more than just guile I prepare to work on Hurd, is that an fair answer? nalaginrut: perfect! ;-) ;-) well, easy to say, but I'll try what I can do yeah, just see how far you get. might be an interesting ride :-)