From: William J. <wi...@jo...> - 2006-11-29 16:23:59
|
I am looking into languages for linux programming and came upon the ruby language. I use gnome so I was looking for gtk bindings. When I started using the bindings included in edgy eft (the released ones) I kept running into errors. It seems like the bindings are way out of date. I compiled CVS and it helped some, but it is still pretty unusable. I filed a bug about the problem I had. The question is, what is the current status of this project? Is it being maintained? Should I look into wxruby? Thanks |
From: Joao P. <joa...@gm...> - 2006-11-29 17:33:20
|
Hi, On 11/29/06, William Johnston <wi...@jo...> wrote: > I am looking into languages for linux programming and came upon the ruby > language. I use gnome so I was looking for gtk bindings. When I started > using the bindings included in edgy eft (the released ones) I kept > running into errors. It seems like the bindings are way out of date. I > compiled CVS and it helped some, but it is still pretty unusable. I > filed a bug about the problem I had. > > The question is, what is the current status of this project? Is it being > maintained? Should I look into wxruby? As a long time user, the status: * 0.15.x versions have tried to fix some hard (involving closures) to fix memory leaks, which cause some destabilization, but which is slowly disappearing; as long as errors are fixed and they are being. Report one with an example to reproduce it if you please. :-) * GTK and Gnome are in full development, constantly. Thus, even though the Ruby-GNOME2 has tried to keep with the times, it's harder than it seems. Masao and now Kouhei have always tried their best (given their free times) to maintain the project. I think Masao has worked on some new GTK 2.10+ bindings, but it's an endless job, because new versions of GTK+ come every few months, and there's even documentation to maintain... Kouhei is the author/maintainer of the RCairo which is used in the newest GTK+ support as well. Last time I did a grep for Cairo in the project files, it showed a large list of hits. * wxruby might be interesting, but I for one don't like it that much. YMMV. :-) Lastly, it seems that there are always new users of Ruby-GNOME2 showing up around here. But some of them did have some problems with the 0.15.x destabilization, even though the CVS HEAD version seems to be more stable for everybody. Cheers, Joao |
From: Mario S. <eu...@tr...> - 2006-11-30 02:15:59
|
Joao Pedrosa wrote: > Hi, > > On 11/29/06, William Johnston <wi...@jo...> wrote: > <snip> > As a long time user, the status: > > * 0.15.x versions have tried to fix some hard (involving closures) to > fix memory leaks, which cause some destabilization, but which is > slowly disappearing; as long as errors are fixed and they are being. > Report one with an example to reproduce it if you please. :-) > > * GTK and Gnome are in full development, constantly. Thus, even though > the Ruby-GNOME2 has tried to keep with the times, it's harder than it > seems. Masao and now Kouhei have always tried their best (given their > free times) to maintain the project. I think Masao has worked on some > new GTK 2.10+ bindings, but it's an endless job, because new versions > of GTK+ come every few months, and there's even documentation to > maintain... Kouhei is the author/maintainer of the RCairo which is > used in the newest GTK+ support as well. Last time I did a grep for > Cairo in the project files, it showed a large list of hits. > > * wxruby might be interesting, but I for one don't like it that much. YMMV. :-) > > Lastly, it seems that there are always new users of Ruby-GNOME2 > showing up around here. But some of them did have some problems with > the 0.15.x destabilization, even though the CVS HEAD version seems to > be more stable for everybody. > > Cheers, > Joao I just wanted to add a couple of things to Joao's excellent explanation of the current status of Ruby-GNOME 2's project. It is very much still being actively worked on, though, as much as can be expected from only 2 developers working on the C[++] backend of the deal. Which is where the biggest deals of Ruby-GNOME2 has to be worked on. Add to that, (No offense Masao or Kouhei), neither speak much English. So it's kinda a language barrier there to. Though we're slowly educating them to the way us American's talk, I'm sure. Plus, the difference between the bindings of Gnome2 and wxRuby, are major, and substantial. wxRuby is going through a complete re-work of the entire code base, for the bindings. They are converting from hand-coded wrappers, to a SWIG interface. So there are still quite a few instabilities with wxRuby, and it's not guaranteed that the API is going to remain the same. Where as, with Gnome2 bindings, there's a lot of foundation there already, that will work with most newer versions of GTK+ API, however, the changes the GTK+ Development team are doing to the memory handling, and such, is causing a lot of headaches, but a lot of patches to be added to the bindings, from other authors, to fix these problems. Ruby-GNOME2 will become stable again, as these patches come along, and people help test the newest code. But, till such time, kinda have to go with the flow of things, and understand, that it's mostly a 2 man team that is working on the backend of this thing. I only wish, there was a GTK-Slim for Windows, that would make the distro a lot smaller for applications that I write, and make certain things a bit faster, then I'd come back to Ruby-GNOME in a heartbeat. As for the comment about the certain things a bit faster, I'm mainly talking about the fact that Ruby-GNOME2's Gtk::Entry in one of my applications seems to be a bit slow to respond, when typing. I'll end up having to try the newer version of Ruby-GNOME2 to see if it has improved. Which reminds me, anyone have a mswin32 compile of Ruby-GNOME2 bindings for CVS? L8ers, Mario Steele |
From: Mathieu B. <mbl...@ru...> - 2006-11-30 05:13:35
|
Hi, > Add to that, (No > offense Masao or Kouhei), neither speak much English. So it's kinda a > language barrier there to. Though we're slowly educating them to the > way us American's talk, I'm sure. WTF! Educating them?? What about you learning Japanese? You know, you Americans are not the only people on earth. A (free software) community is about people from all over the world, with different backgrounds, cultures, and languages... Unlike you, I don't feel that barrier and I think that their English skills are enough to communicate on this list and carry out their maintainer's duties. Besides, as this thread shows, there are always other people to answer. What you said is irrelevant. I think this is more of a technical issue. 0.14.1 bindings were very good and quite stable despite those memory leaks. In an attempt to fix them, 0.15 unfortunately introduced some new problems and the bindings got much more unstable. As it was pointed out many times on this list, the point is that those GC problems are very tough to debug. It is difficult to isolate the problems from big existing applications (seg faults, uninformative warnings etc). CVS version is slowly getting better and we can hope that in a near future all major problems will be fixed. If you can't wait, I recommend you use the 0.14.1 version. The only problem with that is that you won't be able to take part to the debugging effort. The bindings remain for me the best bindings so far. Making UI with ruby flavor is so great! I hope you guys Masao and Kouhei won't get pissed off by those comments. Keep on the good work! Mathieu |
From: Mathieu B. <mbl...@ru...> - 2006-11-30 05:30:02
|
Hi again, > As it was pointed out many times on this list, > the point is that those GC problems are very tough to debug. This makes me think that RG2 does (or it seems to) not have unit tests. I would be great to have a battery of tests that could be run every time new code is committed to the CVS. It would also allow to detect regressions. Mathieu |
From: Nikolai W. <no...@bi...> - 2006-12-01 08:11:28
|
On 12/1/06, Mario Steele <eu...@tr...> wrote: > 5.) American isn't even a language per say, it doesn't conform to the > English dialect as it was truely meant to be spoken in England. It is, in > all terms of the word, slang. Gaah! And you just keep on doing it! American English is in every respect as much a language as English English. The two languages have grown from the same English used during the colonization of America. One might consider American English a /dialect/ of English English, but considering the amount of time they've been separate and the amount of change incurred on both languages it's reasonable to describe them as two separate languages with the same origins. You can find more information here: http://en.wikipedia.org/wiki/English_language http://en.wikipedia.org/wiki/American_English http://en.wikipedia.org/wiki/English_English nikolai |
From: Guillaume C. <gco...@gm...> - 2006-12-06 10:05:33
|
> Already, Ruby/GTK, GdkPixbuf, GDK, Pango have been updated completely > against the newest version of GTK+, Pango. This is very good news! I feel sorry I began working on adding new features of gtk+2.10 but couldn't complete. It's fortunate you could complete it. > Then, I'll release the new version of Ruby-GNOME2. It will be the end of this year. I've just built latest CVS and tried to toy around with my program booh to see if there was still problems. Unfortunately, the program eventually aborted with the "[BUG] Segmentation fault" ruby message. And even more unfortunately, it happened after quite a lot of operations in the program and was not reproduceable with the last thing I did when it happened :/ The suggestion to track it down to a small reproduceable program is very hard in that kind of scenario. So I tried to use a different approach: run the program through valgrind, it is often a very useful and clever tool to hunt down memory allocation problems. It showed me some invalid reads in rbgobj_closure.c (read within a memory chunk which is already free'd). I had a tough time understanding the intrinsics of rbgobj_closure.c and understand the scenario of the problem, but I came up with something: 1. at a point of time, Ruby's GC decides that a closure holder's memory needs to be reclaimed, thus calls gr_closure_holder_free, which in turn calls rclosure_invalidate, which doesn't call rclosure_unref because the counter is at 2 at that time 2. at a later point of time, GTK's GC sees that the closure corresponding the the closure holder's of step #1 needs to be finalized, thus calls rclosure_invalidate, with the same outcome as upper (no rclosure_unref), then finalizes the closure (frees the memory allocated for it) 3. at an even later point of time, GTK's GC finalizes an object on which the closure was attached, so calls rclosure_weak_notify, which calls rclosure_alive_p, which performs two invalids memory reads (to get the count and the holder), as the memory allocated for the closure was freed at step #2 A possible fix might be to not use rclosure_alive_p in rclosure_invalidate, in favor of only testing whether the counter is superior to 0, so that rclosure_invalidate would really perform the necessary weak_unref calls - this seems to fix the problems I could see. -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Guillaume C. <gco...@gm...> - 2006-12-06 11:30:15
|
> > 1. at a point of time, Ruby's GC decides that a closure holder's > > memory needs to be reclaimed, thus calls gr_closure_holder_free, which > > in turn calls rclosure_invalidate, which doesn't call rclosure_unref > > because the counter is at 2 at that time > > > > 2. at a later point of time, GTK's GC sees that the closure > > corresponding the the closure holder's of step #1 needs to be > > finalized, thus calls rclosure_invalidate, with the same outcome as > > upper (no rclosure_unref), then finalizes the closure (frees the > > memory allocated for it) > > > > 3. at an even later point of time, GTK's GC finalizes an object on > > which the closure was attached, so calls rclosure_weak_notify, which > > calls rclosure_alive_p, which performs two invalids memory reads (to > > get the count and the holder), as the memory allocated for the closure > > was freed at step #2 > > > > A possible fix might be to not use rclosure_alive_p in > > rclosure_invalidate, in favor of only testing whether the counter is > > superior to 0, so that rclosure_invalidate would really perform the > > necessary weak_unref calls - this seems to fix the problems I could > > see. > > In rclosure_unref() (from rclosure_invalidate()), > rclosure_weak_notify() is removed from all attached objects: > > for (next = rclosure->objects; next; next = next->next) { > GObject *object; > object = G_OBJECT(next->data); > g_object_weak_unref(object, rclosure_weak_notify, rclosure); > } > > So, it seems that 3. can't call rclosure_weak_notify(). Please check again my explanation: rclosure_unref is *not* called in step #1 or #2. > Hmm... Could you make a patch for your idea? I explained it in the last paragraph of my previous message, but I can show it as code if you prefer: --- glib/src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 +++ glib/src/rbgobj_closure.c 6 Dec 2006 11:25:31 -0000 @@ -260,7 +263,7 @@ { GRClosure *rclosure = (GRClosure*)closure; - if (rclosure_alive_p(rclosure)) { + if (rclosure->count > 0) { rclosure->count = 1; rclosure_unref(rclosure); } > I can't commit your idea until I can reproduce your problem > and confirm your idea fixes the problem... I understand, unfortunately, as I explained, it would be very hard to make a small testcase exhausting a segfault. But maybe we can discuss the principles of the problem, that's what I've tried to explain in my 1/2/3 scenario upper. Maybe with the additional information I've replied upper, you would agree with the scenario? In my opinion, the scenario I've explained clearly demonstrates a flaw which should amyway be fixed. Else, if you're willing to use valgrind and to try with my program booh, I can explain a way for you to reproduce the valgrind-reported memory problem (though it's a bit long to setup, and then it takes a couple of minutes each time because of valgrind overhead). -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Guillaume C. <gco...@gm...> - 2006-12-06 13:47:38
|
> > Please check again my explanation: rclosure_unref is *not* called in > > step #1 or #2. > > Both #1 and #2 calls rclosure_invalidate() but don't call > rclosure_unref(). Is it OK? That's right. > If it's true, it seems that the first rclosure_invalidate() > call invokes rclosure_unref(). Because rclosure_invalidate() > force to decrease the counter to 1 when rclosure is alive: > > if (rclosure_alive_p(rclosure)) { > rclosure->count = 1; > rclosure_unref(rclosure); > } > > Ah. Does what you said mean that rcosure is already dead > when the first rclosure_invalidate() call? Yes. Remember that in #1, this is the Ruby's GC who's firing, hence it calls your callback gr_closure_holder_free which sets the holder to Qnil before invoking rclosure_invalidate. > > I explained it in the last paragraph of my previous message, but I can > > show it as code if you prefer: > > Thanks. I'm good in programming language rather than > English. X< That's maybe the best common language we have, that's right :) > > --- glib/src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 > > +++ glib/src/rbgobj_closure.c 6 Dec 2006 11:25:31 -0000 > > @@ -260,7 +263,7 @@ > > { > > GRClosure *rclosure = (GRClosure*)closure; > > > > - if (rclosure_alive_p(rclosure)) { > > + if (rclosure->count > 0) { > > rclosure->count = 1; > > rclosure_unref(rclosure); > > } > > rcosure isn't freed but rclosure->rb_holder is freed. Is it > OK? If it's true, does the following patch solve your That's correct. > problem: > > Index: src/rbgobj_closure.c > =================================================================== > RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_closure.c,v > retrieving revision 1.37 > diff -u -p -r1.37 rbgobj_closure.c > --- src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 > +++ src/rbgobj_closure.c 6 Dec 2006 13:12:18 -0000 > @@ -251,6 +251,7 @@ rclosure_unref(GRClosure *rclosure) > GRClosureHolder *holder; > Data_Get_Struct(rclosure->rb_holder, GRClosureHolder, holder); > holder->closure = NULL; > + rclosure->rb_holder = Qnil; No. Remember, rclosure_unref is unfortunately never called in the described scenario. Btw, the point of my suggested patch is exactly to be able to call rclosure_unref (with a count of 1) in case rclosure_invalidate is triggered. Remember, when GTK calls rclosure_invalidate, it means the memory for the closure will be freed right after that, so in my opinion the flaw is in your rclosure_invalidate, which should always take necessary actions so that no code would lookup again data in the closure after that, so calling the series of weak_unref is crucial. That's the spirit of my patch. -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Kouhei S. <ko...@co...> - 2006-12-07 14:48:01
|
Hi, In <dc3...@ma...> "Re: [ruby-gnome2-devel-en] What is the current status?" on Wed, 6 Dec 2006 14:47:35 +0100, "Guillaume Cottenceau" <gco...@gm...> wrote: > > Both #1 and #2 calls rclosure_invalidate() but don't call > > rclosure_unref(). Is it OK? > > That's right. > > > If it's true, it seems that the first rclosure_invalidate() > > call invokes rclosure_unref(). Because rclosure_invalidate() > > force to decrease the counter to 1 when rclosure is alive: > > > > if (rclosure_alive_p(rclosure)) { > > rclosure->count = 1; > > rclosure_unref(rclosure); > > } > > > > Ah. Does what you said mean that rcosure is already dead > > when the first rclosure_invalidate() call? > > Yes. Remember that in #1, this is the Ruby's GC who's firing, hence it > calls your callback gr_closure_holder_free which sets the holder to > Qnil before invoking rclosure_invalidate. Ah. OK. I understood. > > > --- glib/src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 > > > +++ glib/src/rbgobj_closure.c 6 Dec 2006 11:25:31 -0000 > > > @@ -260,7 +263,7 @@ > > > { > > > GRClosure *rclosure = (GRClosure*)closure; > > > > > > - if (rclosure_alive_p(rclosure)) { > > > + if (rclosure->count > 0) { > > > rclosure->count = 1; > > > rclosure_unref(rclosure); > > > } I've committed your patch. Thanks, -- kou |
From: Guillaume C. <gco...@gm...> - 2006-12-10 13:24:13
|
> I've committed your patch. Thanks. I can now confirm that using latest CVS, my application booh has zero crashes, and valgrind also reports zero memory allocation problems. That is good news! Thanks for your hard work. -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Kouhei S. <ko...@co...> - 2006-12-06 13:24:07
|
Hi, In <dc3...@ma...> "Re: [ruby-gnome2-devel-en] What is the current status?" on Wed, 6 Dec 2006 12:30:13 +0100, "Guillaume Cottenceau" <gco...@gm...> wrote: > Please check again my explanation: rclosure_unref is *not* called in > step #1 or #2. Both #1 and #2 calls rclosure_invalidate() but don't call rclosure_unref(). Is it OK? If it's true, it seems that the first rclosure_invalidate() call invokes rclosure_unref(). Because rclosure_invalidate() force to decrease the counter to 1 when rclosure is alive: if (rclosure_alive_p(rclosure)) { rclosure->count = 1; rclosure_unref(rclosure); } Ah. Does what you said mean that rcosure is already dead when the first rclosure_invalidate() call? > I explained it in the last paragraph of my previous message, but I can > show it as code if you prefer: Thanks. I'm good in programming language rather than English. X< > --- glib/src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 > +++ glib/src/rbgobj_closure.c 6 Dec 2006 11:25:31 -0000 > @@ -260,7 +263,7 @@ > { > GRClosure *rclosure = (GRClosure*)closure; > > - if (rclosure_alive_p(rclosure)) { > + if (rclosure->count > 0) { > rclosure->count = 1; > rclosure_unref(rclosure); > } rcosure isn't freed but rclosure->rb_holder is freed. Is it OK? If it's true, does the following patch solve your problem: Index: src/rbgobj_closure.c =================================================================== RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_closure.c,v retrieving revision 1.37 diff -u -p -r1.37 rbgobj_closure.c --- src/rbgobj_closure.c 12 Oct 2006 13:30:22 -0000 1.37 +++ src/rbgobj_closure.c 6 Dec 2006 13:12:18 -0000 @@ -251,6 +251,7 @@ rclosure_unref(GRClosure *rclosure) GRClosureHolder *holder; Data_Get_Struct(rclosure->rb_holder, GRClosureHolder, holder); holder->closure = NULL; + rclosure->rb_holder = Qnil; } } } Thanks, -- kou |
From: Kouhei S. <ko...@co...> - 2006-12-06 11:18:25
|
Hi, In <dc3...@ma...> "Re: [ruby-gnome2-devel-en] What is the current status?" on Wed, 6 Dec 2006 11:05:24 +0100, "Guillaume Cottenceau" <gco...@gm...> wrote: > 1. at a point of time, Ruby's GC decides that a closure holder's > memory needs to be reclaimed, thus calls gr_closure_holder_free, which > in turn calls rclosure_invalidate, which doesn't call rclosure_unref > because the counter is at 2 at that time > > 2. at a later point of time, GTK's GC sees that the closure > corresponding the the closure holder's of step #1 needs to be > finalized, thus calls rclosure_invalidate, with the same outcome as > upper (no rclosure_unref), then finalizes the closure (frees the > memory allocated for it) > > 3. at an even later point of time, GTK's GC finalizes an object on > which the closure was attached, so calls rclosure_weak_notify, which > calls rclosure_alive_p, which performs two invalids memory reads (to > get the count and the holder), as the memory allocated for the closure > was freed at step #2 > > A possible fix might be to not use rclosure_alive_p in > rclosure_invalidate, in favor of only testing whether the counter is > superior to 0, so that rclosure_invalidate would really perform the > necessary weak_unref calls - this seems to fix the problems I could > see. In rclosure_unref() (from rclosure_invalidate()), rclosure_weak_notify() is removed from all attached objects: for (next = rclosure->objects; next; next = next->next) { GObject *object; object = G_OBJECT(next->data); g_object_weak_unref(object, rclosure_weak_notify, rclosure); } So, it seems that 3. can't call rclosure_weak_notify(). Hmm... Could you make a patch for your idea? I can't commit your idea until I can reproduce your problem and confirm your idea fixes the problem... Thanks, -- kou |
From: Masao M. <mu...@hi...> - 2006-11-29 23:33:23
|
Hi, On Wed, 29 Nov 2006 10:23:57 -0600 William Johnston <wi...@jo...> wrote: > I am looking into languages for linux programming and came upon the ruby > language. I use gnome so I was looking for gtk bindings. When I started > using the bindings included in edgy eft (the released ones) I kept > running into errors. It seems like the bindings are way out of date. I > compiled CVS and it helped some, but it is still pretty unusable. I > filed a bug about the problem I had. Could you explain about your bug ? |
From: William J. <wi...@jo...> - 2006-11-30 03:14:58
|
Masao Mutoh wrote: > Hi, > > On Wed, 29 Nov 2006 10:23:57 -0600 > William Johnston <wi...@jo...> wrote: > > >> I am looking into languages for linux programming and came upon the ruby >> language. I use gnome so I was looking for gtk bindings. When I started >> using the bindings included in edgy eft (the released ones) I kept >> running into errors. It seems like the bindings are way out of date. I >> compiled CVS and it helped some, but it is still pretty unusable. I >> filed a bug about the problem I had. >> > > Could you explain about your bug ? > http://sourceforge.net/tracker/index.php?func=detail&atid=470969&aid=1602773&group_id=53614 Here is the bug report. If you need any more info please ask. Thanks |
From: Kouhei S. <ko...@co...> - 2006-11-30 07:23:08
|
Hi, 2006/11/30, William Johnston <wi...@jo...>: > http://sourceforge.net/tracker/index.php?func=detail&atid=470969&aid=1602773&group_id=53614 You need to add a widget to each tab. It seems that this is a problem of glade. Thanks, -- kou |
From: Masao M. <mu...@hi...> - 2006-12-01 13:45:40
|
Hi, I noticed glade-2 creates some helper source codes for GtkNotebook. I'll try that ruby-glade-create-template creates them. But now, you need to write the same code in Ruby by yourself. On Thu, 30 Nov 2006 16:22:58 +0900 "Kouhei Sutou" <ko...@co...> wrote: > Hi, > > 2006/11/30, William Johnston <wi...@jo...>: > > > http://sourceforge.net/tracker/index.php?func=detail&atid=470969&aid=1602773&group_id=53614 > > You need to add a widget to each tab. > It seems that this is a problem of glade. > > Thanks, > -- > kou > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > ruby-gnome2-devel-en mailing list > rub...@li... > https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en > |
From: Mario S. <eu...@tr...> - 2006-12-01 01:45:33
|
Mathieu Blondel wrote: > Hi, > >> Add to that, (No >> offense Masao or Kouhei), neither speak much English. So it's kinda a >> language barrier there to. Though we're slowly educating them to the >> way us American's talk, I'm sure. >> > WTF! Educating them?? What about you learning Japanese? You know, you > Americans are not the only people on earth. A (free software) community > is about people from all over the world, with different backgrounds, > cultures, and languages... > > Unlike you, I don't feel that barrier and I think that their English > skills are enough to communicate on this list and carry out their > maintainer's duties. Besides, as this thread shows, there are always > other people to answer. What you said is irrelevant. > <snip> The rest isn't applicable here, cause I agree with it, and it doesn't apply to what I wanted to reply about. I had a feeling something like this would come out, if I made the remark, and was trying to light step it. But, I did want to point out a few things. 1.) Educating them was meant to be a light talk, wasn't meant to be derogatory. 2.) I have been learning some Japanese, but it's been sparse and in between. I love to learn their language, and their history more in-depth, cause I am completely fascinated by their culture. 3.) Yes, I know American's aren't the only ones on the face of the Earth, there are many cultures that make up the Earth, many religions, and so forth. I believe in the right to be different, and have one's own view of the world, being Wiccan and all. So you won't get no argument from me there. 4.) I don't see it as a barrier, for what Masao and Kouhei does, is very admirable. Communication is one of the hardest things to do, when there are so many perspectives, I meant it only as a warning for others, that may get upset when they look at their replies, and may start to flame. Hence for the part of the No offense to Masao and Kouhei. And they are learning I am sure, by reading what we say, and translating it back into their own natural language. It's a learning experience for anyone who speaks another language, Programming or not. 5.) American isn't even a language per say, it doesn't conform to the English dialect as it was truely meant to be spoken in England. It is, in all terms of the word, slang. 6.) Lastly, I didn't mean this or the last as an offensive email to anyone, I am sorry you took it that way. I only meant to point out to be patient with the developers. They are doing what they can, with what little time they have. Also, note that this is an English speaking mailing list, designated by the ruby-gnome2-devel-*en* part of the email address. Again, I apologize for the offensiveness of my last email that anyone took. Apologetically yours, Mario Steele |
From: Masao M. <mu...@hi...> - 2006-12-01 13:35:38
|
Hi, Thanks folks. I should explain the status of Ruby-GNOME2 and me ;). At first, I need to comment some points. On Wed, 29 Nov 2006 20:15:46 -0600 Mario Steele <eu...@tr...> wrote: > Joao Pedrosa wrote: > > Hi, > > > > On 11/29/06, William Johnston <wi...@jo...> wrote: > > > <snip> > > As a long time user, the status: > > > > * 0.15.x versions have tried to fix some hard (involving closures) to > > fix memory leaks, which cause some destabilization, but which is > > slowly disappearing; as long as errors are fixed and they are being. > > Report one with an example to reproduce it if you please. :-) A lot of GC problem have been fixed by Kouhei. The next version of Ruby-GNOME2 will be stable again. # But we can't test the whole of APIs yet, I hope your helps more. The most causes to delay developing Ruby-GNOME2 is that I couldn't spend my private time to develop Ruby-GNOME2. * My business has been so busy for a long time. You may surprise this thing, I work 10:00am to 23:00pm now. It's not so special thing in Japan. But actually I've not have enough spare times. Unfortunately, it will continue until next March. # My business is not related both of Ruby and Ruby-GNOME2. * Develop Ruby-GetText-Package for Ruby on Rails. I needed to make it as the most useful L10n library for Rails. So I concentrated to improve it on 4th quoters. * Helped some sections of "The Ruby Way second edition" I wrote Ruby-GetText section and updated Ruby-GNOME2 section. It was valuable experience but it consumed my private times. * Helped some other Japanese books for Ruby on Rails. > I just wanted to add a couple of things to Joao's excellent explanation > of the current status of Ruby-GNOME 2's project. It is very much still > being actively worked on, though, as much as can be expected from only 2 > developers working on the C[++] backend of the deal. Which is where the > biggest deals of Ruby-GNOME2 has to be worked on. Add to that, (No > offense Masao or Kouhei), neither speak much English. So it's kinda a > language barrier there to. Though we're slowly educating them to the > way us American's talk, I'm sure. Hmm. I think there is no language barrier here. Japanese developers join this ML and we discussed a lot of things here. And also many sub-libraries are maintained by non-Japanese. # I admit I'm not good at English, though. If you feel there is a few replying messages recently from me, it's just my problem which I describe it above. Second, I explain the status of Ruby-GNOME2. The last month, I've been back to develop Ruby-GNOME2 again. Already, Ruby/GTK, GdkPixbuf, GDK, Pango have been updated completely against the newest version of GTK+, Pango. Now I'm working to update Ruby/ATK, and next, I'll update Ruby/GLib and other gnome stuff. Then, I'll release the new version of Ruby-GNOME2. It will be the end of this year. But I've not have enough time for developing Ruby-GNOME2 yet. Any helps are welcomed. |
From: William J. <wi...@jo...> - 2006-12-01 14:34:37
|
Kouhei Sutou wrote: > Hi, > > 2006/11/30, William Johnston <wi...@jo...>: > > >> http://sourceforge.net/tracker/index.php?func=detail&atid=470969&aid=1602773&group_id=53614 >> > > You need to add a widget to each tab. > It seems that this is a problem of glade. > > Thanks, > -- > kou > It seems to have worked. Thanks! I say seem because I ran into another bug while doing it, but I will figure this one out. On another note, I am not a C programmer so I have no clue what the difficulty is, but has anyone ported or considered porting libsexy? Thanks |
From: Peter J. <pe...@pe...> - 2006-12-01 18:46:48
|
On Fri, Dec 01, 2006 at 08:34:34AM -0600, William Johnston wrote: > > On another note, I am not a C programmer so I have no clue what the > difficulty is, but has anyone ported or considered porting libsexy? As someone who has tried to port bits of libsexy to gtk# (the C# language binding of gtk+), I can say from experience that libsexy makes use of some private fields in GtkEntry, etc to manage to do what it does for things like the validating/input masked entry. Mainly for accessing private GdkWindows to resize them, etc, iirc. There's probably lots of libsexy that could be ported, but beware of things like this which are not so easily done from a language binding of gtk+. -pete |
From: Mario S. <eu...@tr...> - 2006-12-02 01:53:16
|
Nikolai Weibull wrote: > Gaah! And you just keep on doing it! American English is in every > respect as much a language as English English. The two languages have > grown from the same English used during the colonization of America. > One might consider American English a /dialect/ of English English, > but considering the amount of time they've been separate and the > amount of change incurred on both languages it's reasonable to > describe them as two separate languages with the same origins. > > You can find more information here: > > http://en.wikipedia.org/wiki/English_language > http://en.wikipedia.org/wiki/American_English > http://en.wikipedia.org/wiki/English_English > Thank you for the Articles Nikolai. But, I'm not going to digress back into this subject. I still believe in the fact that a lot of the English words used today amongst the North America, have been turned into slang quite a bit. Not saying so much that English isn't a Language, or American English isn't a language, hence for the part about "per say" in my last email. You have to admit, that a lot of cultural complexities have diverged the barrier of Proper English, Germanic English, and so forth. Many, normal words that are perfectly good words, have been given derogative meanings to them. One perfect example being the word "Gay" as such. It was originally an adjective meaning "carefree", "happy", or "bright and showy", however, it's been turned into a derogative meaning for Homosexuality, and meant to be a curse word. But, I digress, and therefore will no longer post any more messages concerning this. Once again, if anyone is offended by my emails concerning this subject, it was in no way meant to be that way, Masao has admitted that he doesn't speak English well, so that was my only point to this entire matter. L8ers, Mario |
From: Nikolai W. <no...@bi...> - 2006-12-03 11:04:31
|
On 12/2/06, Mario Steele <eu...@tr...> wrote: > Many, normal words that are > perfectly good words, have been given derogative meanings to them. One > perfect example being the word "Gay" as such. It was originally an > adjective meaning "carefree", "happy", or "bright and showy", however, > it's been turned into a derogative meaning for Homosexuality, and meant > to be a curse word. Considering that the word "gay" was initially used by homosexuals to describe themselves, this isn't quite the turn of events. It's even noted in the Wikipedia article I'm guessing you got the meaning from. And just because some idiots have a hard time with homosexuals doesn't mean that "gay" should be considered derogative or a curse word in the large. Finally, languages evolve. As soon as a language stops changing, it's dead. nikolai |