fxruby-users Mailing List for FXRuby (Page 31)
Status: Inactive
Brought to you by:
lyle
Menu
▾
▴
fxruby-users — General-purpose discussion list for FXRuby
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(75) |
Jul
(90) |
Aug
(61) |
Sep
(56) |
Oct
(56) |
Nov
(39) |
Dec
(83) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(56) |
Feb
(45) |
Mar
(61) |
Apr
(40) |
May
(95) |
Jun
(79) |
Jul
(63) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|
From: Recheis M. <Mei...@av...> - 2003-07-29 11:02:59
|
i managed to catch the mousewheelevent of the FXGLCanvas. i get the sender, selector and data.=20 sender =3D=3D FXGLCanvas selector =3D=3D 2490368 data =3D=3D nil how is the selector to be interpreted? thanks for help, Meinrad -----Urspr=FCngliche Nachricht----- Von: Recheis Meinrad=20 Gesendet: Dienstag, 29. Juli 2003 12:04 An: fxr...@li... Betreff: AW: [Fxruby-users] where can i look up a list of all possible events? thanks, that is a the best Fox docu i've ever seen. now, i know the GLCanvas inherits a onMouseWheel function. how do i make = use of this in ruby? meinrad -----Urspr=FCngliche Nachricht----- Von: Hugh Sasse Staff Elec Eng [mailto:hg...@dm...] Gesendet: Montag, 28. Juli 2003 14:31 An: fxr...@li... Betreff: Re: [Fxruby-users] where can i look up a list of all possible events? On Mon, 28 Jul 2003, Recheis Meinrad wrote: > where can i look up a list of all possible events a FXGLCanvas can = produce? > the FXRuby doc is not very helpful with events. There is a lot of information about the C++ api here: http://www.fifthplanet.net/foxdoc-stable/classes.html which may help you. Have you noticed any missing? (My usual mistake is to forget about those which are inherited, which must be found in the ancestor classes). Hugh > > > > > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Fxruby-users mailing list Fxr...@li... https://lists.sourceforge.net/lists/listinfo/fxruby-users ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Fxruby-users mailing list Fxr...@li... https://lists.sourceforge.net/lists/listinfo/fxruby-users |
|
From: Dalibor S. <da...@in...> - 2003-07-29 10:37:22
|
Quoting Hugh Sasse Staff Elec Eng <hg...@dm...>: > Can I install FXRuby 1.0.24 on top of the Pragmatic Programmers > Ruby-1.6.8 distribution (of 07-JAN-2003) that I have on the Winxp > machine? I fairly sure the answer is yes, but can't remember where > I saw this. I do it regulary without any problem. As FXRuby tends to be updated more frequently than Ruby it is a good way to keep your Fox and FXRuby up to date. When a newer version is available you can safely remove the older FXRuby using standard Windows tools and then install the new version. > Comparing behaviour with Unix, because it has been different, > requires some access to X from Windows so I can see the widgets on > the same screen. Exceed is expensive (I don't mean value for money > -- it works well, I just mean expenditure), and last time I tried > XFree86 with Cygwin it didn't work. Do any other alternatives exist > for this? Few years ago I used Labtam X Server at the university I don't know the price but it was good. As the last resort - would VNC help you? Regards, Dalibor Sramek -- Dalibor Sramek http://www.insula.cz/dali | In the eyes of cats, dal...@in... | all things belong to cats. |
|
From: Hugh S. S. E. E. <hg...@dm...> - 2003-07-29 10:18:11
|
A couple of questions about using FXRuby on Windows:
Can I install FXRuby 1.0.24 on top of the Pragmatic Programmers
Ruby-1.6.8 distribution (of 07-JAN-2003) that I have on the Winxp
machine? I fairly sure the answer is yes, but can't remember where
I saw this.
Comparing behaviour with Unix, because it has been different,
requires some access to X from Windows so I can see the widgets on
the same screen. Exceed is expensive (I don't mean value for money
-- it works well, I just mean expenditure), and last time I tried
XFree86 with Cygwin it didn't work. Do any other alternatives exist
for this?
Hugh
|
|
From: Recheis M. <Mei...@av...> - 2003-07-29 10:03:25
|
thanks, that is a the best Fox docu i've ever seen. now, i know the GLCanvas inherits a onMouseWheel function. how do i make = use of this in ruby? meinrad -----Urspr=FCngliche Nachricht----- Von: Hugh Sasse Staff Elec Eng [mailto:hg...@dm...] Gesendet: Montag, 28. Juli 2003 14:31 An: fxr...@li... Betreff: Re: [Fxruby-users] where can i look up a list of all possible events? On Mon, 28 Jul 2003, Recheis Meinrad wrote: > where can i look up a list of all possible events a FXGLCanvas can = produce? > the FXRuby doc is not very helpful with events. There is a lot of information about the C++ api here: http://www.fifthplanet.net/foxdoc-stable/classes.html which may help you. Have you noticed any missing? (My usual mistake is to forget about those which are inherited, which must be found in the ancestor classes). Hugh > > > > > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Fxruby-users mailing list Fxr...@li... https://lists.sourceforge.net/lists/listinfo/fxruby-users |
|
From: Hugh S. S. E. E. <hg...@dm...> - 2003-07-28 12:32:37
|
On Mon, 28 Jul 2003, Recheis Meinrad wrote: > where can i look up a list of all possible events a FXGLCanvas can produce? > the FXRuby doc is not very helpful with events. There is a lot of information about the C++ api here: http://www.fifthplanet.net/foxdoc-stable/classes.html which may help you. Have you noticed any missing? (My usual mistake is to forget about those which are inherited, which must be found in the ancestor classes). Hugh > > > > > |
|
From: Recheis M. <Mei...@av...> - 2003-07-28 11:46:49
|
where can i look up a list of all possible events a FXGLCanvas can = produce? the FXRuby doc is not very helpful with events. |
|
From: Lyle J. <jl...@cf...> - 2003-07-23 14:21:37
|
Emmanuel Touzery wrote:
> now how to display a dialog box at this stage, as Lyle remarked.. is there
> a nicer solution than to create a brand new FXApp object?
Use the main window as the owner for the dialog box. To do this you'll
need to save a reference to the main window in a local variable, e.g.
mainWin = GlossaryMainWindow.new(application)
and then pass that as the first argument to FXMessageBox.error:
FXMessageBox.error(mainWin, MBOX_OK, "Error", "Boom!")
Lyle
|
|
From: Lyle J. <jl...@cf...> - 2003-07-23 14:17:59
|
Aaron Schrab wrote: > At 15:40 +0100 23 Jul 2003, Emmanuel Touzery <emm...@wa...> wrote: >> C:\programs\glossary\test>ruby test.rb >> test.rb:38:in `onCmdOpen': undefined local variable or method `pouf' for >> #<Gloss >> aryMainWindow:0x52d3c78> (NameError) >> from test.rb:61:in `run' >> from test.rb:61 > > NameError exceptions don't get caught by a bare rescue since that's > equivalent to "rescue StandardError". If you truly want to catch all > exceptions you need to use "rescue Exception". Yep, Aaron beat me to it ;) When I went back and tried running Emmanuel's program I got different results under Ruby version 1.6.8 and 1.8.0. It turns out that for Ruby 1.6, the NameError exception is derived from ScriptError and not StandardError, so the plain 'rescue' won't catch it. In Ruby 1.8.0, which I originally used to run the program, NameError is now derived from StandardError, and so the plain 'rescue' /does/ catch it. So, in summary, FXRuby does appear to be doing the right thing as far as passing Ruby exceptions up the call chain. |
|
From: Emmanuel T. <emm...@wa...> - 2003-07-23 14:06:39
|
Hello, > At 15:40 +0100 23 Jul 2003, Emmanuel Touzery <emm...@wa...> wrote: > > C:\programs\glossary\test>ruby test.rb > > test.rb:38:in `onCmdOpen': undefined local variable or method `pouf' for > > #<Gloss > > aryMainWindow:0x52d3c78> (NameError) > > from test.rb:61:in `run' > > from test.rb:61 > > NameError exceptions don't get caught by a bare rescue since that's > equivalent to "rescue StandardError". If you truly want to catch all > exceptions you need to use "rescue Exception". thank you! this was my problem! now how to display a dialog box at this stage, as Lyle remarked.. is there a nicer solution than to create a brand new FXApp object? sorry to ask so much, but i don't see examples to base myself from on this... emmanuel |
|
From: Aaron S. <aa...@sc...> - 2003-07-23 13:58:48
|
At 15:40 +0100 23 Jul 2003, Emmanuel Touzery <emm...@wa...> wrote: > C:\programs\glossary\test>ruby test.rb > test.rb:38:in `onCmdOpen': undefined local variable or method `pouf' for > #<Gloss > aryMainWindow:0x52d3c78> (NameError) > from test.rb:61:in `run' > from test.rb:61 NameError exceptions don't get caught by a bare rescue since that's equivalent to "rescue StandardError". If you truly want to catch all exceptions you need to use "rescue Exception". -- Aaron Schrab aa...@sc... http://www.schrab.com/aaron/ [It is] best to confuse only one issue at a time. -- K&R |
|
From: Emmanuel T. <emm...@wa...> - 2003-07-23 13:37:52
|
> Emmanuel Touzery wrote:
>
> > i'm happy to read that FXApp#run is going to "forward me" the exception.
but
> > it doesn't seem to work here (see code snippet at the end of the mail).
>
> Ahem.
>
> Emmanuel, when you run this program, you are correct that it raises an
> exception. Did you notice which line of code the backtrace was pointing
> to? ;)
>
> The exception that is raised in your onCmdOpen() method is being caught
> by the 'rescue' block at application.run. The code in that 'rescue'
> block raises yet another exception, though (hint: what does 'self' refer
> to in the call to FXMessageBox.error?).
not here..
i think we're not using the same version of fxruby:
C:\programs\glossary\test>ruby test.rb
test.rb:38:in `onCmdOpen': undefined local variable or method `pouf' for
#<Gloss
aryMainWindow:0x52d3c78> (NameError)
from test.rb:61:in `run'
from test.rb:61
i tried putting nothing in the rescue, or just a puts (before posting).
are you using some kind of development version of FXRuby? i'm testing under
windows2000 with the latest version on sourceforge. i tried yesterday under
linux as well and IIRC it didn't work either (but it was late, etc, i could
have did sth wrong).
emmanuel
|
|
From: Lyle J. <jl...@cf...> - 2003-07-23 13:31:26
|
Emmanuel Touzery wrote: > i'm happy to read that FXApp#run is going to "forward me" the exception. but > it doesn't seem to work here (see code snippet at the end of the mail). Ahem. Emmanuel, when you run this program, you are correct that it raises an exception. Did you notice which line of code the backtrace was pointing to? ;) The exception that is raised in your onCmdOpen() method is being caught by the 'rescue' block at application.run. The code in that 'rescue' block raises yet another exception, though (hint: what does 'self' refer to in the call to FXMessageBox.error?). |
|
From: Emmanuel T. <emm...@wa...> - 2003-07-23 13:13:58
|
> Emmanuel Touzery wrote:
>
> > I'm having the problem that my GUI app might have some bugs; in that
> > case, instead of seeing it exiting violently, dumping the stack on the
> > command line (which will never be seen by the user in most cases), i
would
> > like to catch the exception and display a nice dialog box.
> > Wrapping the app.run call (i don't remember how it's called, but
it's
> > something like that) in a begin/rescue block doesn't seem to catch this
> > exception.
>
> Is it a standard Ruby exception, or is the Ruby interpreter (ruby)
> seg-faulting? If it's the former (a regular exception), it /should/ be
> raised all the way to the "top" and get caught in your begin-rescue
> block around the call to FXApp#run.
standard exception. for an interpreter crash there is not much to display
anyway ;O)
i want a backtrace so that i can debug.
i'm happy to read that FXApp#run is going to "forward me" the exception. but
it doesn't seem to work here (see code snippet at the end of the mail).
> This sounds way too complicated, IMO. If wrapping the call to FXApp#run
> with a "last-chance" begin-rescue block is failing to catch exceptions,
> I would like to see that demonstrated and get it fixed. I think the best
> solution is to get a good group of testers and get them to help you find
> the bugs ;)
maybe i'm doing something wrong, but how about this code:
click on file->open
#!/usr/bin/env ruby
require 'fox'
include Fox
class GlossaryMainWindow < FXMainWindow
include Responder
ID_OPEN,
ID_LAST = enum(FXMainWindow::ID_LAST, 2)
def initialize(app)
# Initialize base class first
super(app, "Glossary", nil, nil, DECOR_ALL, 0, 0, 400, 300)
FXMAPFUNC(SEL_COMMAND, ID_OPEN, :onCmdOpen)
# Make main window; set myself as the target
# setTarget(self)
# setSelector(ID_TITLE)
# Make menu bar
dragshell1 = FXToolbarShell.new(self, FRAME_RAISED|FRAME_THICK)
menubar = FXMenubar.new(self, dragshell1, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
FXToolbarGrip.new(menubar, menubar, FXMenubar::ID_TOOLBARGRIP,
TOOLBARGRIP_SINGLE)
# File menu
filemenu = FXMenuPane.new(self)
FXMenuTitle.new(menubar, "&File", nil, filemenu)
# File Menu entries
FXMenuCommand.new(filemenu,
"&Open... \tCtl-O\tOpen document file.",
@openicon, self, ID_OPEN)
end
def onCmdOpen(sender, sel, ptr)
pouf # <-- invalid code
end
# Create and show the main window
def create
super
show(PLACEMENT_SCREEN)
end
end
if $0 == __FILE__
# Construct an application
application = FXApp.new('Glossary', 'Emmanuel')
# Construct the main window
GlossaryMainWindow.new(application)
# Create and show the application windows
application.create
# Run the application
begin
application.run
rescue
FXMessageBox.error(self, MBOX_OK, "Error", "Boom!")
end
end
|
|
From: Lyle J. <jl...@cf...> - 2003-07-23 13:03:30
|
Emmanuel Touzery wrote:
> I'm having the problem that my GUI app might have some bugs; in that
> case, instead of seeing it exiting violently, dumping the stack on the
> command line (which will never be seen by the user in most cases), i would
> like to catch the exception and display a nice dialog box.
> Wrapping the app.run call (i don't remember how it's called, but it's
> something like that) in a begin/rescue block doesn't seem to catch this
> exception.
Is it a standard Ruby exception, or is the Ruby interpreter (ruby)
seg-faulting? If it's the former (a regular exception), it /should/ be
raised all the way to the "top" and get caught in your begin-rescue
block around the call to FXApp#run.
> So it would seem i need to wrap each event handler in a begin/rescue
> block.
You might also see if the Fox.setIgnoreExceptions() method is a suitable
workaround; see the "Debugging Tricks" at the end of this page:
http://www.fxruby.org/doc/differences.html
> I thought about something like (didn't look at the code, untested
> snippet, just to give the idea):
>
> class FXWindow
> def connect(event, &block)
> begin
> super
> rescue
> FXMessageBox("an error occured, here is the stacktrace, contact
> the developer of the application"...)
> exit
> end
> end
> end
No, this wouldn't work. The connect() method just sets up the mapping
between a message type (e.g. SEL_COMMAND) and the block or method that
handles it. It doesn't actually execute the code.
> and the same for other ways to connect the events (ie event tables). i would
> put that in a "exceptionfox.rb", and do a "require 'exceptionfox.rb'"
> instead of "require 'fox'", so i wouldn't have to change my code. i could
> also call a user-defined function when getting an exception.
> i didn't try this approach yet (no time). but i'm wondering if it seems
> possible, and if there is maybe a better solution?
This sounds way too complicated, IMO. If wrapping the call to FXApp#run
with a "last-chance" begin-rescue block is failing to catch exceptions,
I would like to see that demonstrated and get it fixed. I think the best
solution is to get a good group of testers and get them to help you find
the bugs ;)
|
|
From: Emmanuel T. <emm...@wa...> - 2003-07-23 09:55:25
|
hmm now that i think about it more, wrapping the connect won't help.
maybe something like:
before :
def onOK()...
after:
def handler(symbol, &block)
# write me: generate method calling the block in a begin/rescue block
end
handler :onOK {
...
}
something like that.
i think this would work but would require changing my code.
anything better?
emmanuel
----- Original Message -----
From: "Emmanuel Touzery" <emm...@wa...>
To: <fxr...@li...>
Sent: Wednesday, July 23, 2003 11:54 AM
Subject: catching exceptions in event handlers
> Hello,
>
> I'm having the problem that my GUI app might have some bugs; in that
> case, instead of seeing it exiting violently, dumping the stack on the
> command line (which will never be seen by the user in most cases), i would
> like to catch the exception and display a nice dialog box.
> Wrapping the app.run call (i don't remember how it's called, but it's
> something like that) in a begin/rescue block doesn't seem to catch this
> exception.
> So it would seem i need to wrap each event handler in a begin/rescue
> block.
>
> I thought about something like (didn't look at the code, untested
> snippet, just to give the idea):
>
> class FXWindow
> def connect(event, &block)
> begin
> super
> rescue
> FXMessageBox("an error occured, here is the stacktrace,
contact
> the developer of the application"...)
> exit
> end
> end
> end
>
> and the same for other ways to connect the events (ie event tables). i
would
> put that in a "exceptionfox.rb", and do a "require 'exceptionfox.rb'"
> instead of "require 'fox'", so i wouldn't have to change my code. i could
> also call a user-defined function when getting an exception.
> i didn't try this approach yet (no time). but i'm wondering if it seems
> possible, and if there is maybe a better solution?
>
> i'm sure i'm not the first one facing this problem?
>
> thank you,
>
> emmanuel
>
|
|
From: Emmanuel T. <emm...@wa...> - 2003-07-23 09:50:47
|
Hello,
I'm having the problem that my GUI app might have some bugs; in that
case, instead of seeing it exiting violently, dumping the stack on the
command line (which will never be seen by the user in most cases), i would
like to catch the exception and display a nice dialog box.
Wrapping the app.run call (i don't remember how it's called, but it's
something like that) in a begin/rescue block doesn't seem to catch this
exception.
So it would seem i need to wrap each event handler in a begin/rescue
block.
I thought about something like (didn't look at the code, untested
snippet, just to give the idea):
class FXWindow
def connect(event, &block)
begin
super
rescue
FXMessageBox("an error occured, here is the stacktrace, contact
the developer of the application"...)
exit
end
end
end
and the same for other ways to connect the events (ie event tables). i would
put that in a "exceptionfox.rb", and do a "require 'exceptionfox.rb'"
instead of "require 'fox'", so i wouldn't have to change my code. i could
also call a user-defined function when getting an exception.
i didn't try this approach yet (no time). but i'm wondering if it seems
possible, and if there is maybe a better solution?
i'm sure i'm not the first one facing this problem?
thank you,
emmanuel
|
|
From: Riccardo G. <ric...@fi...> - 2003-07-22 14:23:12
|
Yes sure .. as an example Marco Frailis has done a ColoredListItem starting from some C++ code snippsets he found on the Fox project page .. the conversion to the FXRuby domain was quite straightforward .. my question was originated by the fact that I'll probably need to support a C++ application (not all the people around like Ruby .. I know, it seems impossible :) .. )that will use FOX and that probably need me to develop some new widgets .. I would like than to be able to use that widgets also for my other ruby projects, without implementing them twice .. but anyway this is a maybe scenario, so for now it is just a personal curiosity .. Thanks for the reply, Riccardo :) Lyle Johnson wrote: > Riccardo Giannitrapani wrote: > >> I have some small C++ Fox widgets that I derived in the past from >> standard ones for my applications; my question is if there is an >> "easy" way to use them in FXRuby; I know I can just get the FXRuby >> sources, add my C++ code and the relative swig wrappers and recompile >> FXRuby including them .. but this means that I'll end working with a >> non official release of FXRuby, and moreover it is an operation I need >> to perform every time an FXRuby new version is released .. any >> alternative idea? > > > Is it possible to port the C++ code for those widgets to Ruby? One of > the goals for FXRuby is that you can do most anything with it that you > could with the C++ library, including subclassing existing widgets to > build new ones. > > > -- +--------------------------------------------------------------+ | Riccardo Giannitrapani | | | | Dipartimento di Fisica - Room L1-14-BE | | Universita` di Udine - Via delle Scienze, 206 Udine (Italy) | | Tel (Home): +39-0432-470011 -- (Office): +39-0432-558209 | | Home Page: http://www.fisica.uniud.it/~riccardo | | ICQ# 86590904 | +--------------------------------------------------------------+ |
|
From: Lyle J. <jl...@cf...> - 2003-07-22 14:10:35
|
Riccardo Giannitrapani wrote: > I have some small C++ Fox widgets that I derived in the past from > standard ones for my applications; my question is if there is an "easy" > way to use them in FXRuby; I know I can just get the FXRuby sources, add > my C++ code and the relative swig wrappers and recompile FXRuby > including them .. but this means that I'll end working with a non > official release of FXRuby, and moreover it is an operation I need to > perform every time an FXRuby new version is released .. any alternative > idea? Is it possible to port the C++ code for those widgets to Ruby? One of the goals for FXRuby is that you can do most anything with it that you could with the C++ library, including subclassing existing widgets to build new ones. |
|
From: Riccardo G. <ric...@fi...> - 2003-07-22 07:09:12
|
Hi all I've been a while distracted away from Fox and Ruby, but now I'm back and I have a (probably silly) question (probably for Lyle, but I think posting on the mailing list is better). I have some small C++ Fox widgets that I derived in the past from standard ones for my applications; my question is if there is an "easy" way to use them in FXRuby; I know I can just get the FXRuby sources, add my C++ code and the relative swig wrappers and recompile FXRuby including them .. but this means that I'll end working with a non official release of FXRuby, and moreover it is an operation I need to perform every time an FXRuby new version is released .. any alternative idea? As always thanks to Jeroen, Lyle and all for Fox people around :) Riccardo P.S. If someone is interested, it will be published on the Proceedings of the CHEP conference 2003 (Computing in High Energy Physics) a paper on FRED, an event display application written in Ruby and FXRuby. If you are interested you can find a preprint here http://arxiv.org/abs/cs.gr/0306031 P.P.S. On a completely different topic; does anyone here have any experience with QT Python? I'm tring to promote FXRuby and Ruby to some colleagues of mine, but they asked why not using QTPy instead; apart the obvious licence situation (Fox is free, QT is not, at least for Windows), I have no experience with neither Qt or Python to answer their question .. someone has tried in the past some sort of comparison? Ok, not so important, just a curiosity. Thanks :) -- +--------------------------------------------------------------+ | Riccardo Giannitrapani | | | | Dipartimento di Fisica - Room L1-14-BE | | Universita` di Udine - Via delle Scienze, 206 Udine (Italy) | | Tel (Home): +39-0432-470011 -- (Office): +39-0432-558209 | | Home Page: http://www.fisica.uniud.it/~riccardo | | ICQ# 86590904 | +--------------------------------------------------------------+ |
|
From: Lyle J. <jl...@cf...> - 2003-07-21 19:41:22
|
Emmanuel Touzery wrote: > but for me it's quite amazing, i tried to reduce the program to reproduce the > crash (i hoped to port it to C++ to see if it's a FOX problem maybe) I wouldn't bother porting it to C++, it's extremely unlikely to be a FOX problem. > what is your system? I have access to SuSE linux boxes at work (a bit old > versions i'm afraid). if (big luck but ok) i would have access to the same > version of linux than you, i could try to make it reproduceable there.. (i > assume you're on x86). Yes, I'm running Red Hat Linux 8.0 on x86. > if you can debug on windows, too (i assume), which windows? i have access to > 98/XP/2000 boxes. i can try to make it crash for sure on those too.. I can run the code on Windows (either Win2000 or WinXP) but have never found a good solution for interactively debugging Ruby extensions (like FXRuby) on Windows. The best I can do with Windows (usually) is to just add print statements to the C++ source code to try to "triangulate" the source of the error ;) As you've already discovered, the best route is to try to consistently reproduce the problem under Linux, where it's generally easier to debug. > (i'll try to generate dummy .glo files until i get something) OK. > i agree with you it should be related to the ruby garbage collector.. AND in > my case, the systematic crash under linux goes away when i add GC.disable at > the start of the program. i'll try under windows to see if my other crashes > go away, tomorrow... OK. I would still like to actually track down the bug (and not just work around it!) but I'm glad the GC.disable trick seems to help for now. |
|
From: Emmanuel T. <emm...@wa...> - 2003-07-21 18:36:38
|
Hello, thank you VERY MUCH for the quick answer!!! On Monday 21 of July 2003 17:08, Lyle Johnson wrote: > Emmanuel Touzery wrote: > > This bug really blocks me, as the application is not usable in this > > state; I was wondering if you could just tell me approximately when you > > hope to fix it (days, weeks, months?). > > I am still trying to find a way to *consistently* reproduce the crash > under Linux. Unlike your experience, the program doesn't crash when I > simply try to load the glossary file (lyle-good.glo). I did get it to > crash once, I think in the Bibliography dialog box, but haven't been > able to do that again. oh.. i guess it must be a combination of glibc, ruby, etc... my system is a= =20 mandrake 8.0, kernel 2.4.3-20mdk, glibc 2.2.2-4mdk. but for me it's quite amazing, i tried to reduce the program to reproduce t= he=20 crash (i hoped to port it to C++ to see if it's a FOX problem maybe), i=20 started by trying to reduce the input file that creates the crash=20 (good-lyle.glo). as a result, i could remove maybe one or two lines out of= =20 200 or so! removing any single of the others, and the crash (at startup)=20 goes away (i didn't try to reorder lines). crashes on use under windows=20 happen at one point or another, always. i didn't use it long enough under=20 linux to know. what is your system? I have access to SuSE linux boxes at work (a bit old=20 versions i'm afraid). if (big luck but ok) i would have access to the same= =20 version of linux than you, i could try to make it reproduceable there.. (i= =20 assume you're on x86). if you can debug on windows, too (i assume), which windows? i have access t= o=20 98/XP/2000 boxes. i can try to make it crash for sure on those too.. (i'll try to generate dummy .glo files until i get something) > > I tried with ruby 1.8 and the problems persist. I tried to fix it > > myself, but it seems to be some kind of memory corruption problem, and > > without knowledge of the source, i'm not getting anywhere. I would try = to > > reduce the source code related to the bug, but it's so easy to reproduc= e, > > and the code is generally so simple, that i guess it wouldn't help (only > > maybe if i reduce it a lot and try to port it to FOX/C++ to see if it's= a > > FOX bug maybe.. but it would take me forever...). > > As already noted, it's not so easy to reproduce (for me anyways ;) I > agree with you that it's probably some kind of memory corruption > problem; most of these difficult-to-reproduce bugs end up being related > to interactions with Ruby's garbage collector. As a workaround, you > might simply try disabling garbage collection altogether by adding the > line: > > GC.disable > > at the beginning of the program. thank you very much! i agree with you it should be related to the ruby garbage collector.. AND i= n=20 my case, the systematic crash under linux goes away when i add GC.disable a= t=20 the start of the program. i'll try under windows to see if my other crashes= =20 go away, tomorrow... thank you, it seems that's the workaround i was looking for! i'll still try to reproduce the bug 100% under windows. emmanuel. =2D-=20 "Droit devant soi, on ne peut pas aller bien loin" - Le petit prince, Antoine de Saint Exup=E9ry |
|
From: Lyle J. <jl...@cf...> - 2003-07-21 14:57:43
|
Emmanuel Touzery wrote:
> This bug really blocks me, as the application is not usable in this
> state; I was wondering if you could just tell me approximately when you hope
> to fix it (days, weeks, months?).
I am still trying to find a way to *consistently* reproduce the crash
under Linux. Unlike your experience, the program doesn't crash when I
simply try to load the glossary file (lyle-good.glo). I did get it to
crash once, I think in the Bibliography dialog box, but haven't been
able to do that again.
> I tried with ruby 1.8 and the problems persist. I tried to fix it
> myself, but it seems to be some kind of memory corruption problem, and
> without knowledge of the source, i'm not getting anywhere. I would try to
> reduce the source code related to the bug, but it's so easy to reproduce,
> and the code is generally so simple, that i guess it wouldn't help (only
> maybe if i reduce it a lot and try to port it to FOX/C++ to see if it's a
> FOX bug maybe.. but it would take me forever...).
As already noted, it's not so easy to reproduce (for me anyways ;) I
agree with you that it's probably some kind of memory corruption
problem; most of these difficult-to-reproduce bugs end up being related
to interactions with Ruby's garbage collector. As a workaround, you
might simply try disabling garbage collection altogether by adding the line:
GC.disable
at the beginning of the program.
|
|
From: Hugh S. S. E. E. <hg...@dm...> - 2003-07-18 16:14:27
|
On Fri, 18 Jul 2003, Lyle Johnson wrote:
> Hugh Sasse Staff Elec Eng wrote:
>
> > Sorry, very badly phrased: I meant the modal?() method was not
> > inherited, which I expected for reasons of reflection.
>
> So... it's OK now? Right? You do see that modal?() is an instance method
> for the FXApp class?
Yes, and as per my other reply, I think I've argued my way round to
not needing it in any dialogs. Thank you for your patience!
Hugh
>
>
|
|
From: Lyle J. <jl...@cf...> - 2003-07-18 16:09:50
|
Hugh Sasse Staff Elec Eng wrote: > Sorry, very badly phrased: I meant the modal?() method was not > inherited, which I expected for reasons of reflection. So... it's OK now? Right? You do see that modal?() is an instance method for the FXApp class? |
|
From: Hugh S. S. E. E. <hg...@dm...> - 2003-07-18 15:37:08
|
On Fri, 18 Jul 2003, Lyle Johnson wrote:
> Hugh Sasse Staff Elec Eng wrote:
>
> >> On Fri, 18 Jul 2003, Lyle Johnson wrote:
> >>
> >> > getApp().modal?(theDialogBox)
> >>
> >
> > I've just checked: it doesn't even inherit this method.
>
> I'm not sure what you mean. getApp() is an inherited instance method for
Sorry, very badly phrased: I meant the modal?() method was not
inherited, which I expected for reasons of reflection.
Thank you,
Hugh
>
>
>
|
3 messages has been excluded from this view by a project administrator.
