When I need to delete some widget, I do it like this:
parent_obj.removeChild(obj_to_remove)
and then create and recalc
But, though the object deleted does not belong anywhere in the hierarchy of GUI objects,
it still exists. I have a ObjectSpace.each_object() loop in my program iterating over some
of FXObjects, setting new font and text. Naturally, doing anything to a removed object
causes error “This FXLabel (or FXWindow, or …) * already released”.
So, I have two questions:
Is there a way to find out whether the object has already been released?
What else must be done to the FoX object that we want to delete, besides
parent_obj.removeChild(obj_to_remove)
When I need to delete some widget, I do it like this:
parent_obj.removeChild(obj_to_remove)
and then create and recalc
But, though the object deleted does not belong anywhere in the hierarchy of GUI objects,
it still exists.
Correct. Calling removeChild() deletes the underlying C++ object. The
Ruby object that was referring to that C++ object is no longer in use,
but it hasn’t been garbage-collected yet.
I have a ObjectSpace.each_object() loop in my program iterating over some
of FXObjects, setting new font and text. Naturally, doing anything to a removed object
causes error “This FXLabel (or FXWindow, or …) * already released”.
Yes. Accessing a Ruby object whose C++ partner is gone is a no-no.
So, I have two questions:
Is there a way to find out whether the object has already been released?
I don’t guess so (it has never come up). If you were to add this request
to the list of FXRuby bugs at SourceForge, I might add a way to find out
this information in a future FXRuby release.
What else must be done to the FoX object that we want to delete, besides
parent_obj.removeChild(obj_to_remove)
I guess you can try forcing the garbage collector to run immediately
after the call to removeChild(), i.e.
For me it often works to make the child invisible instead of removing
it. But when I hide a child I might want to change the layout to use
the new space. I did not find the method “layout” which is implemented
in FOX but seems to be missing in fxRuby. I chose to just resize the
app to it’s current size which implies a layout change.
Perhaps some variable in my application (or in the FXRuby layer…)
still points to the object, and GC.start doesn’t help. I’ll take a more
thourough look now, as I see now where the problem might be.
You’ve been very helpful, as usual, thank you.
···
On Wed, 19 May 2004 08:43:49 +0900 Lyle Johnson lyle@knology.net wrote:
Yuri Leikind wrote:
> When I need to delete some widget, I do it like this:
>
> parent_obj.removeChild(obj_to_remove)
>
> and then create and recalc
>
> But, though the object deleted does not belong anywhere in the hierarchy of GUI objects,
> it still exists.
Correct. Calling removeChild() deletes the underlying C++ object. The
Ruby object that was referring to that C++ object is no longer in use,
but it hasn't been garbage-collected yet.
> I have a ObjectSpace.each_object() loop in my program iterating over some
> of FXObjects, setting new font and text. Naturally, doing anything to a removed object
> causes error "This FXLabel (or FXWindow, or ...) * already released".
Yes. Accessing a Ruby object whose C++ partner is gone is a no-no.
> So, I have two questions:
>
> 1) Is there a way to find out whether the object has already been released?
I don't guess so (it has never come up). If you were to add this request
to the list of FXRuby bugs at SourceForge, I might add a way to find out
this information in a future FXRuby release.
> 2) What else must be done to the FoX object that we want to delete, besides
> parent_obj.removeChild(obj_to_remove)
I guess you can try forcing the garbage collector to run immediately
after the call to removeChild(), i.e.
parent.removeChild(child)
GC.start
> 2) What else must be done to the FoX object that we want to delete, besides
> parent_obj.removeChild(obj_to_remove)
I guess you can try forcing the garbage collector to run immediately
after the call to removeChild(), i.e.
parent.removeChild(child)
GC.start
Perhaps some variable in my application (or in the FXRuby layer…)
still points to the object, and GC.start doesn’t help. I’ll take a more
thourough look now, as I see now where the problem might be.
Also keep in mind that the garbage collector is conservative. You may
not assume that every unreferenced object is actually destroyed.
I won't ask which is better, since I've just read some of the colorful net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to learn well. I get the impression that this list is about 2 to 1 in VIMs favour for usage (where either is being used). Is this roughly accurate? If so, is this because of VIM's potential to be compiled with Ruby bindings to it's API?
I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
I doubt it's possible to determine. You should just conclude that there
is sufficient usage of both to be able to help you with any problems.
If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?
That's a good question, and the answer is no. Both editors are complex in
their own way, and implement a certain philosophy of text editing. It's a
psychological fit with that philosophy that drives usage, not Ruby
bindings to an API. The former is an order of magnitude more significant
than the latter.
I am an expert in both Vim and Ruby, and don't bother to use the Ruby
bindings. They're cool to have (even thought I rarely have them compiled
in), but I've never thought of doing anything that requires them. BTW, I
hate Vim's inbuilt scripting language.
I won't ask which is better, since I've just read some of the colorful net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to learn well. I get the impression that this list is about 2 to 1 in VIMs favour for usage (where either is being used). Is this roughly accurate? If so, is this because of VIM's potential to be compiled with Ruby bindings to it's API?
Thanks,
Nick
Well, if you decide to go with Vim, then try to keep your fingers off the cursor keys. It's a royal pain to change that habit but the rewards are worth it when you can navigate to any part of a screen full of text with just a few keypresses--all without changing the position of your hands...
I won't ask which is better, since I've just read some of the colorful net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to learn well. I get the impression that this list is about 2 to 1 in VIMs favour for usage (where either is being used). Is this roughly accurate? If so, is this because of VIM's potential to be compiled with Ruby bindings to it's API?
Rather than looking at it for what it's language bindings are, it's better to concentrate on the actual core philosophy behind each of the editors.
The one you decide to use should be whichever editor philosophy fits your own style better. Especially vim's modal editing against emacs's more classical style of operation. It depends a lot on how you gather your own thoughts while programming, and it's really the largest factor as to which will make you a more efficient programmer in the long run.
The ruby bindings aren't really that important or cool.
"Nicholas Van Weerdenburg" <nick@activehitconsulting.com> schrieb im
Newsbeitrag news:40F4A38F.7000103@activehitconsulting.com...
I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
Dunno. I do most Ruby editing with Textpad. (Although, in case you
wanted to know which one I use on Linux, it's emacs.)
I'm sort of stuck between the two. I like them both, but figure it's more productive to stick with one for a stretch. I figured maybe I'd go with the one that was more attuned with Ruby culture, if there was such a learning.
I'm on OS/X if that makes any difference.
Thanks,
Nick
Gavin Sinclair wrote:
···
I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.
However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
I doubt it's possible to determine. You should just conclude that there
is sufficient usage of both to be able to help you with any problems.
If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?
That's a good question, and the answer is no. Both editors are complex in
their own way, and implement a certain philosophy of text editing. It's a
psychological fit with that philosophy that drives usage, not Ruby
bindings to an API. The former is an order of magnitude more significant
than the latter.
I am an expert in both Vim and Ruby, and don't bother to use the Ruby
bindings. They're cool to have (even thought I rarely have them compiled
in), but I've never thought of doing anything that requires them. BTW, I
hate Vim's inbuilt scripting language.
Well, if you decide to go with Vim, then try to keep your fingers off
the cursor keys. It's a royal pain to change that habit but the
rewards are worth it when you can navigate to any part of a screen
full of text with just a few keypresses--all without changing the
position of your hands...
Same deal with Emacs. Try and get used to using the cursor
positioning commands versus the pgup/pgdown/arrow-keys -- you'll
end up moving your hands MUCH less. If you go the Emacs route,
you may also want to look into swapping the capslock key with the
control key, since it seems to be much more comfortable. (at
least, it is for me)
i guess it depends on how and how much you extend the capabilities of
your current editor.
i left the emacs fold ages ago but at the time you were stuck with
elisp if you wanted to extend the editor...
with vim you have your choice between ruby, perl, python (and i
believe lua)
i have vim built with both ruby and perl. i think it's VERY cool to
add an extension to my editor using one of the languages i program
in. i haven't written many ruby functions for vim yet, but i've
written a few perl ones...
···
On Wed, 14 Jul 2004 12:44:23 +0900, you wrote:
The ruby bindings aren't really that important or cool.
I'm sort of stuck between the two. I like them both, but figure it's
more productive to stick with one for a stretch. I figured maybe I'd go
with the one that was more attuned with Ruby culture, if there was such
a learning.
nope (not that I'd really know). As was elgantly put by Gavin, they
"implement a certain philosophy of text editing." Pick one
philosophy, and stick to it for a stretch. After that, feel free to
try the other if it suits you.
I'm on OS/X if that makes any difference.
nope. no difference. both are freely available for OS/X.
Can I just say how impressed I am that one of the oldest and most
incindiary questions in the open source world (Vim vs. Emacs) is being
discussed with such civility in this thread?
Now, if we could only reach such an understanding about programming
paradigms, we'd be set...
