Re: Call for contributions to update the project list
() [EMAIL PROTECTED] (Ludovic Courtès) () Wed, 05 Dec 2007 22:46:14 +0100 * to list only reasonably active projects, preferably projects that work with 1.8, so that the list is really helpful to newcomers; my stuff works w/ (unofficial) guile 1.4.x. would it be welcome on that page? i suppose the deeper question is, do you think newcomers would enjoy variety? (i would say yes, personally, from when i was a newcomer, but maybe i'm just weird.) thi ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: the future of Guile
"Marco Maggi":
3b. Death to structs! IMO they were "an attempt", but the
resulting code is awful (sorry, but can you disagree?).
Err.. but aren't structs the main part of how GOOPS is
implemented?
IMO Guile's structs do nothing that cannot be done better
with a good old C struct wrapped by a SMOB.
I've mentioned this before, but In Snd there is a function to
automatically create C structs. You have to free
the underlying c object manually though, but adding a SMOB
wrapper around shouldn't be that hard.
Oh, and thats yet another "should" for HBGC:
You don't need to mess with SMOBs to garbage collect C
objects when using the HBGC.
(load "eval-c.scm")
(define-ec-struct
one
twos
three
scm)
(define test ( :one 1
:twos '(2)
:three "three"))
(-> test one)
=> 1
(-> test one 90)
(-> test one)
=> 90
(-> test twos)
=> (2.0)
(-> test twos '(4 5 6))
(-> test twos)
=> (4.0 5.0 6.0)
(-> test three)
=> "three"
(-> test three "four")
(-> test three)
=> "four"
(-> test scm)
=> #f
(-> test scm (lambda (x) x)) ;; stored elsewhere too, so it won't be gc-ed.
(-> test scm)
=> #
(-> test get-size)
=> 16
(-> test get-c-object)
=> ("A_POINTER" 147502592)
(-> test destructor) ;;free it
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
Re: the future of Guile
2007/12/4, Marco Maggi <[EMAIL PROTECTED]>: > I think that it is time for a chat on the future of Guile. Some pieces of input to the discussion: * There is (or should be) a module called "workbook" in the repository. It contains policy documents setting out the direction for Guile development. It is important to be consistent regarding the direction, over long time, otherwise Guile doesn't come very far. The Guile policy documents should be material for discussion if the future of Guile is on the table. * In my personal opinion, Guile needs a bytecode interpreter. Keisuke long ago wrote guile-vm which succeeded well concerning speed. One option is to dust it off and do the last part of development. * Personal wish for Guile-2: Some primitive procedures, like display, + and equal? are, in principle, generics. I think the evaluator (eval.c), which currently is a frightening monster, could be both cleaner and more efficient if all procedures were generic functions. This could lead to the elimination of all special cases in eval.c and elimination of argument checking in all primitives throughout the Guile code base. * It would be great if someone could complete the GOOPS meta object protocol. * What about writing a python-module adapter so that Guile can dynamically load python extension modules, using GOOPS for wrapping? 8-) ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Call for contributions to update the project list
Hi, Thien-Thi Nguyen <[EMAIL PROTECTED]> writes: > my stuff works w/ (unofficial) guile 1.4.x. > would it be welcome on that page? > > i suppose the deeper question is, do you think newcomers would > enjoy variety? (i would say yes, personally, from when i was a > newcomer, but maybe i'm just weird.) He he, that's a tough question. ;-) My personal opinion is that we could have a link to Guile 1.4's main page (say, in the "Core Projects" section), but adding links to 1.4-based projects may lead to confusion since they won't work out of the box with the Guile that's offered for download on this very web site. What do others think? (My deeper feeling about this "schism" is that it's unfortunate for the Guile community, to say the least.) Thanks, Ludovic. ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: [announce] GEE/Streams 0.1
"Andy Wingo" wrote: >> Guile already comes with the (ice-9 streams) module, which >> allows Scheme level code to iterate over non--list sequences >> of values. GEE/Streams is a C language re-implementation of >> the same interface that allows both Scheme and C code to >> define streams. > >Haven't looked closely at what you have, but have you seen the >paper: > >http://cm.bell-labs.com/cm/cs/who/wadler/papers/lazyinstrict/lazyinstrict.ps It had the off-by-one error in it. Fixed. -- 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
Re: the future of Guile
"Andy Wingo" wrote: >> 3b. Death to structs! > >Record types are the hip disjoint type in Schemeland, and >you certainly need a way to deal with them from >Guile. Structs might not be it, but you will need something >smarter than SMOBs... Suggestions? I dunno what you mean by "smarter", anyway my original plan was to put records in a module and structs could go with them. My understanding of records is that: the only thing that structs do that a vector cannot do (without special handling), is to have a print closure used by WRITE and DISPLAY. There is a comment in "boot-9.scm" that lets us understand about a plan to make GOOPS wrap records (maybe) automatically, but if it was implemented it is undocumented. It goes along with other undocumented things that maybe are there but nobody (still here) knows if they were finished and working. And Guile maintainers keep them in for future releases (if they exist), because they are not going to break backwards compatibility... >> 4. If a garbage collector allows to remove the need for >>"scm_remember_upto_here" it must be adopted even if it >>makes Guile slower and it raises memory usage a bit (or >>more than a bit). > >Who cares? I have written thousands and thousands of lines >of guile extensions in C. I have not yet had to use >this. Perhaps it's just dumb luck or something. While coding GEE I had crashes that I fixed by remembering. I am probably using it also in places where it is not required. But I am not able to recognise those places, can you guess why? >> 5. Guile must be loadable/unloadable as a shared library. >>Use case: once I have read a configuration file or a sexp >>data file, I do not need it anymore. > >If you aren't running your app with Guile extensions / code, >you don't need a whole scheme interpreter to read >s-expressions... This depends upon the type and number of transformations that I want to apply before converting data into the application's internal representation. >> 6. More modularity. > >Sure, but any breaking of Guile into modules without >thinking about syncase is half-baked. This is one bit that >r6rs definitely got right IMO. Sorry, I am not competent enough to understand and comment on this, can you elaborate? >> 7a. It makes no sense to discuss if Guile should go R6RS or >> not. The only meaningful discussion is about which >> hooks are needed in Guile's code to make those features >> available as loadable modules. (Yes, this is >> difficult). > >Oh, I don't know. Standards are definitely relevant, whether >it's ERR5RS or R6RS or whatever. The guile hacker community >is a small part of the scheme hacker community, we should >cooperate if at all possible. Well, I am not going to do work for R6RS compliance, and I am not going to ask Ludovic and Neil to do it. In truth, I hope that they will not dive into this because in 2009 it might turn out to have been a full waste of their time. But I am noone, and their motivations are their business only, so they will do what they want. Will Guile gain active users if it goes R6RS? Will Guile loose active users if it does not go R6RS? >Unfortunately for you Guile is widely deployed and coded to; I do not see where is my misfortune in this. >those users also define "what guile is". They define what Guile 1.8 has been. >Radical changes to the C interface are not going to be >forthcoming. This is probably true if Neil and Ludovic stop hacking it. -- 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
Re: Call for contributions to update the project list
If it is fine for you, I will submit a description for each component of GEE as soon as a new usable version becomes available. It makes sense for me because GEE version 0.4 is no more a single, all inclusive, package. http://gna.org/projects/gee";>GEE/Streams description An extension that offers a C implmented replacement for the (ice-9 streams) module. license GPL 2 or later requires Guile 1.8 Maybe you can add a section at the bottom of the projects page that shows the HTML chunk to be used, so that people can prepare it and then post it directly on guile-user when announcing a package. Thanks. -- 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
