From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Marco Maggi" Newsgroups: gmane.lisp.guile.user Subject: Re: the future of Guile Date: Wed, 5 Dec 2007 23:32:24 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1196893966 20126 80.91.229.12 (5 Dec 2007 22:32:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 22:32:46 +0000 (UTC) To: "guile-user" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Dec 05 23:32:53 2007 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J02nU-0004j3-GX for guile-user@m.gmane.org; Wed, 05 Dec 2007 23:32:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J02nD-0006F7-PV for guile-user@m.gmane.org; Wed, 05 Dec 2007 17:32:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J02n7-0006Bi-Jl for guile-user@gnu.org; Wed, 05 Dec 2007 17:32:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J02n4-00065w-EZ for guile-user@gnu.org; Wed, 05 Dec 2007 17:32:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J02n3-00065g-UA for guile-user@gnu.org; Wed, 05 Dec 2007 17:32:25 -0500 Original-Received: from relay-pt1.poste.it ([62.241.4.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J02n3-0006L5-D0 for guile-user@gnu.org; Wed, 05 Dec 2007 17:32:25 -0500 Original-Received: from poste.it (192.168.144.24) by relay-pt1.poste.it (7.3.122) (authenticated as marco.maggi-ipsu@poste.it) id 4755F85800007D4F for guile-user@gnu.org; Wed, 5 Dec 2007 23:32:24 +0100 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 83.190.104.94 X-detected-kernel: by monty-python.gnu.org: Solaris 9 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6343 Archived-At: @Julian Graham >I've been frustrated with the situation, too. Might I >direct your attention to the Snow project? >(http://snow.iro.umontreal.ca/) Rules, rules and rules! I don't know... It is not for me because I am using C and GOOPS everywhere. @Mike Gran >As far as being an LFE, 1.8.x has been a big improvement >over 1.6. The API is much cleaner when wrapping stuff by >hand. >From what I have seen of 1.6, I agree. >One problem here is that there does need to be a richer >library that is official and downloadable right from >www.gnu.org/software/guile. This is impossible. Too much coordination work. TCL has something like this, but only because ActiveState is backing it (and they make money with consultancy). It would be an enormous success if every Guile related package maintainer opens a project at the same site, like GNA!, so that all the source code can be found with a search for the string Guile at that site. >Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), >but, each has its own packaging scheme, documentation >scheme. I feel guilty here because I do not digest GNU Automake, and I have built my own (shock! horror!) GNU Make automation using its functions. And I am the only one that can understand it... :-/ >None of them are released in a coordinated manner with the >Guile releases themselves. This is true for different reasons. I, for example, am still moving stuff around in GEE. If a roadmap comes with milestones for Guile 1.9, I can try to make alpha releases that build with them. >First, dependencies on the many libraries are difficult to >coordinate. Ugh! And I am making it worse with GEE 0.4 ... This is linked with the application deployment problem. With a self executing archive we could distribute a single executable with everything in it. It is not a tool that we can build in an afternoon, though. @Ludovic Courts >It took me some time, but I now think there's no such sharp >distinction between "LFE" and "SI". Yep. Probably I am giving too much importance on the size of the core library. >> As a SI my opinion is that some sort of compiler is a must, > >An interpreter *can* be much faster than what we have now Really? Fine! >>an interface to bind the class to a symbol in a module. > >[...] is easily addressed, by defining said class in your >module to `(@ (oop goops) )' Woah! I had not noticed that the binding is created in (oop goops). >> Anyway, remembering "scm_remember_upto_here" is really >> annoying. And it is needed almost every time I access the >> client data of a custom SMOB. > >This is strange. I rarely had to use it, and I can't think >of a common programming pattern where it's useful. SCM my_func (SCM arg) { client_data_t data =3D (client_data_t)SCM_SMOB_DATA(arg); /* Do something with "data" but do not access "arg" anymore. With compiler optimisations the reference to the SMOB can disappear. If here I call scm_* functions, GC collects the SMOB removing the carpet from under my feet and if I access "data": crash. So: */ scm_remember_upto_here_1(arg); } >> If structs are moved into an external shared library, >> records can go there, too. > >Records are too common to be removed from the core: almost >everyone would end up loading that module. This surprises me. I thought that they were a rarely used feature because they are unschemey :-) and because of the existence of GOOPS. -- Marco Maggi "Now feel the funk blast!" Rage Against the Machine - "Calm like a bomb" _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user