Thanks to kampstrup I just learned the meaning of groping and how unfortunate the name GRope is, I apologize!
2012/5/25 Alberto Ruiz <ar...@gnome.org> > Hello Russell, > > First of all, don't get discouraged if you get no feedback, but it is > really hard to get feedback in most communities if you present a proposal > with no code. > > Note that you are asking our thoughts before you even mention what would > be the benefits of GRopes, so it is really hard for us to judge its > advantages over the ADTs we already have. > > In any case, I will encourage you to go ahead and write GRope as a > standalone library (libgrope?), right after that, try to find a good > usecase where you can show its benefits compared to other solutions. > > It seems to me that GRope could be a nice way to implement GtkTextBuffer, > (obviously, this is in theory). > > As an excercise, once you have GRope implemented, port GtkTextBuffer so > that it uses GRope underneath and write some benchmarks to check whether it > is worth using it. > > If you achieve a better GtkTextBuffer using GRope, rest assured that it > will be considered seriously by the GLib community. > > And if GRope doesn't happen to improve GtkTextBuffer, I am sure that you > will learn a lot of valuable lessons along the way. > > Please keep us posted if you make any advancements, and don't be > discouraged by the lack of response, just note that including GLib is a bit > of a big deal, but that doesn't mean that you cannot write a GRope > implementation that rocks and can be useful to a lot of people, so go ahead! > > > > 2012/5/21 Russell Harmon <r...@eatnumber1.com> > >> I'm looking to implement two things which I think would be quite useful >> if included in glib. >> >> - Ropes [1] >> - Custom string formatting helper routines >> >> What are people's thoughts on this? I was doing a little prototyping and >> was having trouble deciding whether to have the string formatting helper >> routines take and return ropes (which would be algorithmically faster), or >> take and return gchar *s which would probably be faster on very small >> strings, depending on the specifics of the implementation. Or, do you guys >> not worry about performance on that level? >> >> I was also wondering about what you guys' policy on code simplicity vs >> performance is. String formatting routines (that take and return a gchar *) >> could be implemented relatively easily, but would be very inefficient with >> calls to realloc() on every conversion, or could be implemented much more >> efficiently but with a great deal more code. You can see an example of this >> in some code I wrote last year, [2] although I think I can do better than >> this example by a great deal. >> >> Lastly, would you guys even be interested in ropes and string formatting >> routines at all? >> >> Thanks >> Russell Harmon >> >> [1]: http://en.wikipedia.org/wiki/Rope_(computer_science) >> [2]: >> https://github.com/eatnumber1/getmntinfo/blob/master/getmntinfo.c#L314 >> >> _______________________________________________ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list >> >> > > > -- > Cheers, > Alberto Ruiz > -- Cheers, Alberto Ruiz
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
