Re: Scheme+
Damien Mattei writes: > I finished today the first version of Scheme+. > Scheme+ is an extension of the syntax of the Scheme language. > Scheme+ makes it easy the assignment of Scheme objects in infix (works also > in prefix) notation with a few new operators ← (or <-), [ ],⥆ (or <+) . > > https://damien-mattei.github.io/Scheme-PLUS-for-Guile/Scheme+io.html Does this build on SRFI-105? Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Scheme+
Linus Björnstam schreef op ma 20-12-2021 om 09:15 [+0100]: > I played around with it and it seems to rely heavily on mutation, > which makes guile (and chez and racket for that matter) box the > values. That adds a layer of indirection to memory access, meaning > slower code (apart from the more obvious problems of continuation > safety and threading safety). Concerning thread-safety and continuation safety: as long as continuations aren't resumed multiple times (*), and as long as no closures are passed, then the mutation doesn't make any observable difference (except fastness). (*) E.g., the continuations that guile-fibers construct are resumed only once. Greetings, Maxime.
Re: Scheme+
yes it is based on SRFI-105 as explained in section 7: Features. The project is based on R6RS (R5RS too) and SRFI for compatibility. Linus we had a discussion about bindings month ago and Scheme+ take in account the impossibility in Scheme to have a single operator for defining a variable anywhere . There is no more mutation in Scheme+ than in other code. If you code already use mutation with set! array-set! then Scheme+ encapsulate it with new and easy operator,that's all. Scheme+ is 100% compatible with R6RS and SRFI. I used it to convert a big code (see section 20:Scheme+ in action) and it worked at the first time. let/ec, which i did not knew, is not standardised but i will work on this,thank you for your advice. Scheme+ is really fast because macro are generally one step expanded ,or have recusivity depth of the size of the object (example array dim 3 , we recall three time the macro expansion) and on a compiled Scheme as Guile i'm not sure it is slower.(I could have done better as SRFI arrays which define a macro for each dimension 1,2,3, until a fixed number) If someone have counter example with call/cc or threads making fail Scheme+ i will do my best to fix that and improve it. This is only version 1.0. Damien On Mon, Dec 20, 2021 at 9:16 AM Linus Björnstam wrote: > Hi Damien! > > I played around with it and it seems to rely heavily on mutation, which > makes guile (and chez and racket for that matter) box the values. That adds > a layer of indirection to memory access, meaning slower code (apart from > the more obvious problems of continuation safety and threading safety). It > could be partially fixed with a very much not fun to write syntax case > macro: you expand a body as far as possible into a letrec* (and > letrec-syntax) shadowing bindings when needed and use set! only in places > where bindings are not declared. > > The workhorse you need for that is syntax-local-binding. > > If you want this system to be resilient and work well with other scheme > code that is probably the path to go. One could imagining having a > procedure form that is fully expanded, analyzed and then > some-kind-of-CPS-transformed so that all variables are passed as state. > That way you would get continuation and thread safety, while allowing > something that seems like and, at least locally, behaves like mutation to > take place. > > This (the local mutation part) is tangential to something I have wanted to > write for a long time, but I have not had the time (nor intelligence). If > you want to discuss some ideas or have any question we can take this > off-list. > > Another thing would be to not use call/cc in the def form. Let/ec is a lot > faster. > > -- > Linus Björnstam > > On Mon, 20 Dec 2021, at 01:05, Damien Mattei wrote: > > Hi, > > I finished today the first version of Scheme+. > > Scheme+ is an extension of the syntax of the Scheme language. > > Scheme+ makes it easy the assignment of Scheme objects in infix (works > also > > in prefix) notation with a few new operators ← (or <-), [ ],⥆ (or <+) . > > > > Scheme+ does much more things,see: > > > > https://damien-mattei.github.io/Scheme-PLUS-for-Guile/Scheme+io.html > > > > or: > > > > > https://github.com/damien-mattei/Scheme-PLUS-for-Guile/blob/main/README.md > > > > static light HTML page: > > https://damien-mattei.github.io/Scheme-PLUS-for-Guile/Scheme+.html > > > > direct link to code and README: > > https://github.com/damien-mattei/Scheme-PLUS-for-Guile > > > > Best regards, > > > > Damien Mattei >
Re: Scheme+
Hi Damien! I played around with it and it seems to rely heavily on mutation, which makes guile (and chez and racket for that matter) box the values. That adds a layer of indirection to memory access, meaning slower code (apart from the more obvious problems of continuation safety and threading safety). It could be partially fixed with a very much not fun to write syntax case macro: you expand a body as far as possible into a letrec* (and letrec-syntax) shadowing bindings when needed and use set! only in places where bindings are not declared. The workhorse you need for that is syntax-local-binding. If you want this system to be resilient and work well with other scheme code that is probably the path to go. One could imagining having a procedure form that is fully expanded, analyzed and then some-kind-of-CPS-transformed so that all variables are passed as state. That way you would get continuation and thread safety, while allowing something that seems like and, at least locally, behaves like mutation to take place. This (the local mutation part) is tangential to something I have wanted to write for a long time, but I have not had the time (nor intelligence). If you want to discuss some ideas or have any question we can take this off-list. Another thing would be to not use call/cc in the def form. Let/ec is a lot faster. -- Linus Björnstam On Mon, 20 Dec 2021, at 01:05, Damien Mattei wrote: > Hi, > I finished today the first version of Scheme+. > Scheme+ is an extension of the syntax of the Scheme language. > Scheme+ makes it easy the assignment of Scheme objects in infix (works also > in prefix) notation with a few new operators ← (or <-), [ ],⥆ (or <+) . > > Scheme+ does much more things,see: > > https://damien-mattei.github.io/Scheme-PLUS-for-Guile/Scheme+io.html > > or: > > https://github.com/damien-mattei/Scheme-PLUS-for-Guile/blob/main/README.md > > static light HTML page: > https://damien-mattei.github.io/Scheme-PLUS-for-Guile/Scheme+.html > > direct link to code and README: > https://github.com/damien-mattei/Scheme-PLUS-for-Guile > > Best regards, > > Damien Mattei
Re: scheme problem!
Oh well, I found the issue. It was because of my special system. The printed representation of unify variables that point to a point to a point to a symbol got printed as a symbol. I really need to tweak the output to hint if it is a unify variable. And if wingo managed to squeeze in tagging - so much sweeter. Anyway I have implemented Subtypes Parameter types Recursive types Now, the subtypes have been tested a little, the rest remains to be debugged. Also there is a weak key map of functions to types of the object that I use to record type signatures. /Stefan
Re: scheme problem!
Stefan Israelsson Tampe writes: > Somewhere in the program I have, > > (pk x) > (pk (caar l)) > (pk (equal? x (caar l))) > > It outputs > > ;;; (number) > > ;;; (number) > > ;;; (#f) > > > > #f is there more to this then meets the eye? > /Stefan Well... scheme@(guile-user)> (equal? 'number (make-symbol "number")) $7 = #f Is it possible that either or both of x and (caar l) is uninterned? (As far as I recall, it's intended that uninterned symbols are distinct.) Neil
Re: scheme problem!
On Thu, May 12, 2011 at 12:59, Stefan Israelsson Tampe wrote: > Somewhere in the program I have, > > (pk x) > (pk (caar l)) > (pk (equal? x (caar l))) > > It outputs > > ;;; (number) > > ;;; (number) > > ;;; (#f) > > > > #f is there more to this then meets the eye? You will get more significative replies if you post a snippet of code which allows people to reproduce what you observe without having to guess what could possibly be causing this. P.
Re: Scheme Implementers
Hello, > What tends to happen is that people that want to do this consider > themselves Scheme programmers, first and foremost, and who do not > identify themselves with one Scheme system; so they release their code > on their own site, with info on using it with various systems, and send > mails to the various implementation user lists. > > But it's rare for an implementer to be in this category. People who > have the luxury of an implementation, if it's big enough, don't appear > to _need_ standardization so much, so they don't work on it. Thanks for this reply. That makes sense. > Scheme is fairly polychromatic right now, culturally. You might find it > useful to interact with the various lists individually, and then come > back and work on this. Otherwise you won't really know where people are > coming from. > > For example, if you are interested in cooperation with Racket, the (very > smart and experienced) Racket people will tell you their view of the > world straight-up on their mailing lists, but are probably tired of > getting into arguments with other worldviews on more general fora. > Likewise you'd need something in R6RS for R6RS schemes. Et cetera. > > I don't mean to discourage more inter-Scheme cooperation. I like Scheme > folks and Scheme implementations. I even like Racket :) I just mean to > say that it's not just space, or lack thereof, that is a barrier to > cooperation, it's culture. Successful cooperation is diplomacy, in the > best sense of the word. Thanks, this makes a lot more sense to me. I might get in touch with Racket or some other Schemes once the parser is far enough along to be used. Noah
Re: Scheme Implementers
Hi Noah, On Sun 30 Jan 2011 17:08, Noah Lavine writes: > My question is, what should I do to let other Scheme variants know > this is happening and get them involved? C.L.S, currently. It could be that there is a need for another forum, but I don't know. What tends to happen is that people that want to do this consider themselves Scheme programmers, first and foremost, and who do not identify themselves with one Scheme system; so they release their code on their own site, with info on using it with various systems, and send mails to the various implementation user lists. But it's rare for an implementer to be in this category. People who have the luxury of an implementation, if it's big enough, don't appear to _need_ standardization so much, so they don't work on it. > I could just post on a bunch of development mailing lists, but it > seemed like it would be better to have one list that handled that > (although maybe not). Scheme is fairly polychromatic right now, culturally. You might find it useful to interact with the various lists individually, and then come back and work on this. Otherwise you won't really know where people are coming from. For example, if you are interested in cooperation with Racket, the (very smart and experienced) Racket people will tell you their view of the world straight-up on their mailing lists, but are probably tired of getting into arguments with other worldviews on more general fora. Likewise you'd need something in R6RS for R6RS schemes. Et cetera. I don't mean to discourage more inter-Scheme cooperation. I like Scheme folks and Scheme implementations. I even like Racket :) I just mean to say that it's not just space, or lack thereof, that is a barrier to cooperation, it's culture. Successful cooperation is diplomacy, in the best sense of the word. Regards, Andy -- http://wingolog.org/
Re: Scheme Implementers
On Sun 30 Jan 2011 16:48, l...@gnu.org (Ludovic Courtès) writes: > The “R7RS” lists are accessible read-only via Gmane: > > http://dir.gmane.org/gmane.lisp.scheme.reports I believe this one is available for anyone to post on. The other two are moderated. Andy -- http://wingolog.org/
Re: Scheme Implementers
Hi, >> I think several Schemes already have a dynamic FFI with a C parser. >> Bigloo has one (info "(bigloo) Automatic extern clauses generation"), >> and it’s GPL’d code, which we could reuse. Larceny has something too. > > Oh, great. Can Guile reuse GPL'd code, though, since it is LGPL? We could have GPL modules, though that would be a case-by-case decision. In this case it may be a bad idea; OTOH it could be argued that the C parser is invoked only a compile-time, and thus users don’t have to be GPL too, just like applications compiled with GCC don’t have to be GPL. But, hmm, that’s tricky. ;-) > I see that Larceny is licensed under the LGPL, but the copyright is > probably not assigned to the FSF. Would reusing that be possible? Yes, if there are good reasons to do so. There are several modules in Guile with non-FSF copyright. > Just to be clear about the overall idea, what I'd like to do is to > work on new features with as many people as possible, and to duplicate > as little code as possible, because I think this would lead to more > cool things made with Scheme, which would ultimately be better for all > of us who like using the language. So that is why I would like to work > with other Schemes on things like the C parser. Some people have been building software on top of R6RS with portability in mind, like Andreas (hi!). That’s another way to share efforts with others. Thanks, Ludo’.
Re: Scheme Implementers
Hello, > I think several Schemes already have a dynamic FFI with a C parser. > Bigloo has one (info "(bigloo) Automatic extern clauses generation"), > and it’s GPL’d code, which we could reuse. Larceny has something too. Oh, great. Can Guile reuse GPL'd code, though, since it is LGPL? I see that Larceny is licensed under the LGPL, but the copyright is probably not assigned to the FSF. Would reusing that be possible? Just to be clear about the overall idea, what I'd like to do is to work on new features with as many people as possible, and to duplicate as little code as possible, because I think this would lead to more cool things made with Scheme, which would ultimately be better for all of us who like using the language. So that is why I would like to work with other Schemes on things like the C parser. Noah
Re: Scheme Implementers
Hi Noah, I think several Schemes already have a dynamic FFI with a C parser. Bigloo has one (info "(bigloo) Automatic extern clauses generation"), and it’s GPL’d code, which we could reuse. Larceny has something too. Thanks, Ludo’.
Re: Scheme Implementers
Hello all, Thanks a lot for the points. Let me be more specific and see what you think of this idea, and if there is a good forum for dealing with it. I think that having a C parser will be a good feature for Guile, because it will let us make C FFI connection automatic by parsing C header files. Other Scheme variants might want a similar feature. I think it would be pretty neat if we could agree on a parse tree format, so that people could write Scheme code to analyze C and it would work in more places. I think it would be even cooler if other variants thought that the C parser was so good they wanted to use Guile's (thanks, LGPL!) and then contributed patches to it and code that used it to do neat things. That way everyone would get more and better tools. My question is, what should I do to let other Scheme variants know this is happening and get them involved? The r7rs lists seem like the wrong place because this is not ready to become a standard feature of anything, and the SRFI lists are only for completed SRFIs. I didn't know about comp.lang.scheme, but now it sounds like it may or may not still be useful. I could just post on a bunch of development mailing lists, but it seemed like it would be better to have one list that handled that (although maybe not). Noah On Sun, Jan 30, 2011 at 7:01 AM, Andy Wingo wrote: > On Sat 29 Jan 2011 23:54, Hans Aberg writes: > >> On 29 Jan 2011, at 21:53, Ludovic Courtès wrote: >> I think there should be a mailing list for people who implement Schemes, to sort of coordinate our non-standard features. ... >> >>> I think comp.lang.scheme is already a good place for this. You >>> quickly >>> get feedback and many implementors seem to participate in it. >> >> The newsgroup did not seem very active. Is it still important? > > There are also lists related to standardization: > r6rs-disc...@lists.r6rs.org, and scheme-repo...@scheme-reports.org. > There are SRFI lists as well, I think. > > The scheme-reports list seems to always end up in my spam box for some > reason, though. I think I tried like three times to subscribe to it, > but never got the confirmation mails, becaus of some problem with that > list. Still I think it is the most active list on the standardization > front. > > Andy > -- > http://wingolog.org/ > >
Re: Scheme Implementers
Hi! Andy Wingo writes: > On Sat 29 Jan 2011 23:54, Hans Aberg writes: > >> On 29 Jan 2011, at 21:53, Ludovic Courtès wrote: >> I think there should be a mailing list for people who implement Schemes, to sort of coordinate our non-standard features. ... >> >>> I think comp.lang.scheme is already a good place for this. You >>> quickly >>> get feedback and many implementors seem to participate in it. >> >> The newsgroup did not seem very active. Is it still important? > > There are also lists related to standardization: > r6rs-disc...@lists.r6rs.org, and scheme-repo...@scheme-reports.org. The “R7RS” lists are accessible read-only via Gmane: http://dir.gmane.org/gmane.lisp.scheme.reports http://dir.gmane.org/gmane.lisp.scheme.reports.wg1 http://dir.gmane.org/gmane.lisp.scheme.reports.wg2 It’s read-only because these are Google groups, which require a Google account to post, I think, and the list admins insisted on allowing only member postings... > There are SRFI lists as well, I think. Only per-SRFI, though. > The scheme-reports list seems to always end up in my spam box for some > reason, though. I think I tried like three times to subscribe to it, > but never got the confirmation mails, becaus of some problem with that > list. Still I think it is the most active list on the standardization > front. That’s because it takes a lot of talk to reinvent the wheel! :-) Thanks, Ludo’.
Re: Scheme Implementers
On Sat 29 Jan 2011 23:54, Hans Aberg writes: > On 29 Jan 2011, at 21:53, Ludovic Courtès wrote: > >>> I think there should be a mailing list for people who implement >>> Schemes, to sort of coordinate our non-standard features. ... > >> I think comp.lang.scheme is already a good place for this. You >> quickly >> get feedback and many implementors seem to participate in it. > > The newsgroup did not seem very active. Is it still important? There are also lists related to standardization: r6rs-disc...@lists.r6rs.org, and scheme-repo...@scheme-reports.org. There are SRFI lists as well, I think. The scheme-reports list seems to always end up in my spam box for some reason, though. I think I tried like three times to subscribe to it, but never got the confirmation mails, becaus of some problem with that list. Still I think it is the most active list on the standardization front. Andy -- http://wingolog.org/
Re: Scheme Implementers
() Noah Lavine () Sat, 29 Jan 2011 16:23:39 -0500 a lot less coordination among Schemes right now than there should be Scheme is a fun platform for experimentation, which is sometimes at odds w/ coordination. Personally, i wouldn't sweat it overmuch.
Re: Scheme Implementers
On 29 Jan 2011, at 21:53, Ludovic Courtès wrote: I think there should be a mailing list for people who implement Schemes, to sort of coordinate our non-standard features. ... I think comp.lang.scheme is already a good place for this. You quickly get feedback and many implementors seem to participate in it. The newsgroup did not seem very active. Is it still important?
Re: Scheme Implementers
Hello, > I think comp.lang.scheme is already a good place for this. You quickly > get feedback and many implementors seem to participate in it. Oh, great. I didn't know about that. Although I must say, it seems like there is a lot less coordination among Schemes right now than there should be. So anything that already exists can't be working too well. Noah
Re: Scheme Implementers
Hi Noah, Noah Lavine writes: > I think there should be a mailing list for people who implement > Schemes, to sort of coordinate our non-standard features. For > instance, you could email the list and say "hey, Guile is thinking of > adding a unicode library with this interface. Does anyone else want to > converge on an interface together?" Or better yet, "does anyone want > to cooperate in the making of this library?" (But that's less likely > because of license concerns, I suppose.) I think comp.lang.scheme is already a good place for this. You quickly get feedback and many implementors seem to participate in it. Thanks, Ludo’.
Re: scheme@(guile-user)> considered ugly
On Sat 02 Oct 2010 00:55, l...@gnu.org (Ludovic Courtès) writes: > Another option would be to keep the prompt but use a simpler one in the > manual, as is often done with shell transcripts. I think I prefer this option, for now. I'll do this the next time our prompt bothers me in the manual :) Andy -- http://wingolog.org/
Re: scheme@(guile-user)> considered ugly
Hello! Andy Wingo writes: > I'm thinking that our prompt is really ugly. Sure, it's useful to know > what language and module you're in (though you probably know the > language). But I was just going over some docs and the prompt really > makes it hard to read. The interaction transcript went like this: I agree that this example is hard to read. That said, in reality, there’d be some color (hello jao! :-)) and a blinking cursor, which make things much better. Also, FWIW, it’s customary to have $PS1 = ‘...@\h:\w]\$’, which is graphically close to ‘LANG@(MODULE)>’. > But what if we elide the language and deparen the module: > > guile-user> (define abc "hello") Yes, that’s clearer. Still, I had got used to seeing the language name, and it’s probably good marketing-wise (though currently only Scheme works at the REPL, but shh!) So I don’t know. No strong feelings. Another option would be to keep the prompt but use a simpler one in the manual, as is often done with shell transcripts. Thanks, Ludo’.
Re: [Scheme Steering Committee announcements] New Scheme Language Steering Committee
Hi, 2009/3/2 Mitchell Wand : > I am pleased to officially announce the results of the election for the > Scheme Language Steering Committee. Thanks to all who voted. I'm not familiar with the work of the steering committee, and so abstained; however, as a scheme user, I am very concerned about its status and future and general social acceptance. I interact daily with Java programmers and Python users, and work on a project whose components are variously written not only in guile, but also perl, C, C++, SQL, and of course python, ruby and java. Many people I interact with do not have a clear idea of what scheme/lisp *is*; and for some reason there's a slight negative connotation associated with lisp .. possibly fear; I cannot gauge the core problem. However, these folks do affect the decision-making process, and push the project in various directions. Thus, as a scheme user, it is vital for me that scheme (guile) have a widespread, positive perception and acceptance. Perception is not enough: I'd like to see the actual fruits: a large selection of libraries; library repositories analogous to CPAN; debugging, tracing and performance-tuning tools, credible integration with other popular technologies, and so on. Aside from a focus on the core language, stuff like this is what's needed to make Scheme vibrant; I'd like to see it happen. --linas
Re: scheme closures: crash during garbage collection
Hi, I'm just now getting around to taking care of this oldie. On Sat, 2006-07-08 at 18:06 +0300, Marius Vollmer wrote: > Neil Jerram <[EMAIL PROTECTED]> writes: > > (See > > http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html > > if you didn't see the whole description on guile-gtk-general already.) [...] >By using this combination of tracing and reference counting it is >possible to break the cycle that is formed by the proxy pointing to >the GtkObject and the GtkObject pointing back. I'm going to look into what it would take to use mark functions, as guile-gtk does, instead of rolling our GC protection scheme, as Gregory did[0]. I'll also look into what python does, as they probably have things right. Then again, I thought I had things right... [0] http://lists.gnu.org/archive/html/guile-gtk-general/2006-07/msg00056.html Cheers, Andy. -- http://wingolog.org/ ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
Marius Vollmer <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: > >>> Guile wants you to integrate your objects with its mark/sweep >>> approach, by providing appropriate smob marking functions, for >>> example. >> >> If I've understood correctly, this isn't possible in Gregory's >> scenario. >> >> (See >> http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html >> if you didn't see the whole description on guile-gtk-general already.) > > I think this (and also the problem of reference loops that easily form > over widgets and signal handlers) has been successfully solved in the > guile-gtk bindings of yore: http://www.gnu.org/software/guile-gtk/ Many thanks for this explanation; it looks good. In principle, however, I still think this is pretty tricky and so it would be nice if libguile could offer some help here. So if it is possible to generalise this into something not GtkObject-specific, it would be nice to provide this as a set of libguile library functions. Neil ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
Neil Jerram <[EMAIL PROTECTED]> writes: >> Guile wants you to integrate your objects with its mark/sweep >> approach, by providing appropriate smob marking functions, for >> example. > > If I've understood correctly, this isn't possible in Gregory's > scenario. > > (See > http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html > if you didn't see the whole description on guile-gtk-general already.) I think this (and also the problem of reference loops that easily form over widgets and signal handlers) has been successfully solved in the guile-gtk bindings of yore: http://www.gnu.org/software/guile-gtk/ Here is the comment describing the wrapping strategy for GObjects: /* GtkObjects. GtkObjects are wrapped with a smob. The smob of a GtkObject is called its proxy. The proxy and its GtkObject are strongly connected; that is, the GtkObject will stay around as long as the proxy is referenced from Scheme, and the proxy will not be collected as long as the GtkObject is used from outside of Scheme. The lifetime of GtkObjects is controlled by a reference count, while Scheme objects are managed by a tracing garbage collector (mark/sweep). These two techniques are made to cooperate like this: the pointer from the proxy to the GtkObject is reflected in the reference count of the GtkObject. All proxies are kept in a list and those that point to GtkObjects with a reference count greater than the number of `internal' references are marked during the marking phase of the tracing collector. An internal reference is one that goes from a GtkObject with a proxy to another GtkObject with a proxy. We can only find a subset of the true internal references (because Gtk does not yet cooperate), but this should be good enough. By using this combination of tracing and reference counting it is possible to break the cycle that is formed by the proxy pointing to the GtkObject and the GtkObject pointing back. It is straightforward to extend this to other kind of cycles that might occur. For example, when connecting a Scheme procedure as a signal handler, the procedure is very likely to have the GtkObject that it is connected to in its environment. This cycle can be broken by including the procedure in the set of Scheme objects that get marked when we are tracing GtkObjects with a reference count greater than the number of internal references. Therefore, each proxy contains a list of `protects' that are marked when the proxy itself is marked. In addition to this, there is also a global list of `protects' that is used for Scheme objects that are somewhere in Gtk land but not clearly associated with a particular GtkObject (like timeout callbacks). */ -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes: > In article <[EMAIL PROTECTED]>, > Neil Jerram <[EMAIL PROTECTED]> wrote: >>If I've understood correctly, this isn't possible in Gregory's >>scenario. >> >>(See >>http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html >>if you didn't see the whole description on guile-gtk-general already.) > > I don't understand. The way I read it, Gregory concludes his email > with a solution for his problem. In any event, it's easy to write your > own GC protection scheme, which can have different semantics. That's true, but surely Guile should be helping developers out here? Is it hard to allow scm_gc_unprotect_object within GC, or does it constrain the GC implementation in some undesirable way? Regards, Neil ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
In article <[EMAIL PROTECTED]>, Neil Jerram <[EMAIL PROTECTED]> wrote: >If I've understood correctly, this isn't possible in Gregory's >scenario. > >(See >http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html >if you didn't see the whole description on guile-gtk-general already.) I don't understand. The way I read it, Gregory concludes his email with a solution for his problem. In any event, it's easy to write your own GC protection scheme, which can have different semantics. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
Marius Vollmer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Han-Wen Nienhuys) writes: > >> No, MV thinks it's a bad idea, and I agree with him. >> >> See >> >> http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160 > > Yep, and let me elaborate a bit: > > The pair scm_gc_protect_object / scm_gc_unprotect_object can be seen > as being Guile's way to implement reference counting for its objects, > maybe analogous to g_object_ref and g_object_unref for glib's > GObjects. This is true, of course: you can use it to implement > reference counting. However, it is not a good idea, as Guile offers a > better alternative with its mostly-precise mark/sweep garbage > collector. So what do you propose, then, for the scenario that Gregory described? > Guile wants you to integrate your objects with its mark/sweep > approach, by providing appropriate smob marking functions, for > example. If I've understood correctly, this isn't possible in Gregory's scenario. (See http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html if you didn't see the whole description on guile-gtk-general already.) Regards, Neil ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes: > In article <[EMAIL PROTECTED]>, > Neil Jerram <[EMAIL PROTECTED]> wrote: > >>[...] >>It seems to me, though, that the same kind of situation, leading to >>wanting to call scm_gc_unprotect_object during GC, is likely to arise >>in any sufficiently complex application, and hence that we should >>support this within Guile itself. >>[...] >>Can people more familiar with the GC code comment on whether this fix >>is feasible? > > No, MV thinks it's a bad idea, and I agree with him. > > See > > http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160 Yep, and let me elaborate a bit: The pair scm_gc_protect_object / scm_gc_unprotect_object can be seen as being Guile's way to implement reference counting for its objects, maybe analogous to g_object_ref and g_object_unref for glib's GObjects. This is true, of course: you can use it to implement reference counting. However, it is not a good idea, as Guile offers a better alternative with its mostly-precise mark/sweep garbage collector. Using the protec/unprotect functions for references that change with a high frequency is quite expensive: Guile objects don't contain a reference count field, and protecting/unprotecting them is implemented by putting them in a global list and removing them again. Also, the 'reference counts' only need to be correct when the GC actually happens, and keeping them correct all the time is wasteful in that sense. Guile wants you to integrate your objects with its mark/sweep approach, by providing appropriate smob marking functions, for example. The function scm_gc_protect_object is intended for long living, global objects that are referenced from global C variables. If the global variable changes often and points to different objects, it might be a good idea to use scm_gc_register_root instead. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
In article <[EMAIL PROTECTED]>, Neil Jerram <[EMAIL PROTECTED]> wrote: >> guile-gnome (up to v. 2.7.98, most recent as of this writing) can >> call scm_gc_unprotect_object() during a scheme garbage collector >> sweep, which is a fatal error in guile-1.8. In earlier versions >> of guile, it is not a fatal error (but still, I think you're not >> supposed to do it.) > >Many thanks for this great analysis. > >It seems to me, though, that the same kind of situation, leading to >wanting to call scm_gc_unprotect_object during GC, is likely to arise >in any sufficiently complex application, and hence that we should >support this within Guile itself. > >(I'm not personally familiar with the GC code, but it may be that the >new restriction in 1.8 against doing this was not strongly intended, >but more of a shortcut that was then forgotten.) > >Can people more familiar with the GC code comment on whether this fix >is feasible? No, MV thinks it's a bad idea, and I agree with him. See http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160 ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: scheme closures: crash during garbage collection
[added crosspost to guile-devel] "gregory benison" <[EMAIL PROTECTED]> writes: > guile-gnome (up to v. 2.7.98, most recent as of this writing) can > call scm_gc_unprotect_object() during a scheme garbage collector > sweep, which is a fatal error in guile-1.8. In earlier versions > of guile, it is not a fatal error (but still, I think you're not > supposed to do it.) Many thanks for this great analysis. It seems to me, though, that the same kind of situation, leading to wanting to call scm_gc_unprotect_object during GC, is likely to arise in any sufficiently complex application, and hence that we should support this within Guile itself. (I'm not personally familiar with the GC code, but it may be that the new restriction in 1.8 against doing this was not strongly intended, but more of a shortcut that was then forgotten.) That said, your proposed solution would be a good short term workaround, until we can fix this in the Guile code. Can people more familiar with the GC code comment on whether this fix is feasible? Regards, Neil ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
