Already Initialized Constant THE_APP

Hello everyone. First time here.

I’m posting a debug question because I’ve searched google all over and I
can’t find any other instances of this occurring. And even though it may
be a common error due to a stupid mistake by me, who is just learning
ruby and wx, for some odd reason the internet seems devoid of a
solution. I’ve even searched this forum and the error message is not
here either.

What happens is, the script brings up the login/create window just fine
the first time, but if the user enters too short a password and the
script tries to bring the same window up a second time for another
chance at input, the program crashes with exception “Already Initialized
Constant THE_APP”. I’ve tried rewriting it multiple ways, even the basic
App.run do method. Still no luck.

It seems like I’m not doing something that is needed to completely
destroy the instance of App, as the second time I call it no matter what
it always crashes with the exception.

What’s funny is, I had this login/create window already done using the
TK library and since I had an old version of the library, it had a bug
in PMW which basically caused the same kind of behavior as this bug is
causing. I could only bring up one instance of anything, if another was
ever created, even after all other instances had been destroyed, the
program would crash and tell me that a constant was already initialized.
Without a way to fix it, I moved on to shoes, which I quickly dismissed
because it was WAY too hard to try and get shoes to work from within my
ruby script instead of as a script-launcher. Then I spent a good 5 hours
researching a way to make “require ‘wx’” work, turns out ubuntu 10.04
needs some special installation procedures. Finally got that working,
only to find out that, yep, I can only create one instance of a window
per program run… again… XD

I realize that I can just handle the string check in the button code to
avoid this one occurrence. However, that won’t fix the problem if I need
to be able to reopen a window later in the program. The real problem is
that later on I will be developing a lot of GUI windows for this client
that will need to be opened, then closed, then reopened, then closed,
then reopened, over and over and over again, in order for players to
build. If I can’t do it with the first window, it’s not worth building
all the subsequent windows or even continuing on the project until I can
find a GUI that allows me to create a second instance of a particular
window sometime after the first instance had been destroyed.

Here’s the contents of obtainlogin.rb. This file is required in the main
ruby script.

I’m using Ubuntu 10.04 Lucid and Ruby 1.8

Error: “Already Initialized Constant THE_APP” upon second run of App.

class LoginFrame < Frame
def initialize()
super(nil, -1, ‘Login Or Create’)
# First create the controls
@my_panel = Panel.new(self)
@userid_label = StaticText.new(@my_panel, -1, ‘User ID:’,
DEFAULT_POSITION, DEFAULT_SIZE, ALIGN_CENTER)
@userid_textbox = TextCtrl.new(@my_panel, -1, ‘’)
@password_label = StaticText.new(@my_panel, -1, ‘Password:’,
DEFAULT_POSITION, DEFAULT_SIZE, ALIGN_CENTER)
@password_textbox = TextCtrl.new(@my_panel, -1, ‘’, :style =>
TE_PASSWORD)
@connect_but = Button.new(@my_panel, -1, ‘Connect’)
# Bind controls to functions
evt_button(@connect_but.get_id()) { |event|
connect_but_click(event)}
# Now do the layout
@my_panel_sizer = BoxSizer.new(VERTICAL)
@my_panel.set_sizer(@my_panel_sizer)
@my_panel_sizer.add(@userid_label, 0, GROW|ALL, 2)
@my_panel_sizer.add(@userid_textbox, 0, GROW|ALL, 2)
@my_panel_sizer.add(@password_label, 0, GROW|ALL, 2)
@my_panel_sizer.add(@password_textbox, 0, GROW|ALL, 2)
@my_panel_sizer.add(@connect_but, 0, GROW|ALL, 2)
show()
end

def connect_but_click(event)
$userid = @userid_textbox.get_value
$password = @password_textbox.get_value
close
end

end

class LoginApp < App
def on_init
LoginFrame.new
end
end

def areThereIllegalCharactersInLoginInfo
tBool = false
for i in (0…$userid.length)
if $userid[i] < 32 or $userid[i] > 126
tBool = true
end
end
for i in (0…$password.length)
if $password[i] < 32 or $password[i] > 126
tBool = true
end
end
return tBool
end

def obtainLoginInfo
passBool = false
while passBool == false
#LoginApp.new.main_loop() # This was the original line, I changed it
to try and fix the problem.
tApp = LoginApp.new
tApp.main_loop()
tApp = nil # I added this line to try and fix the problem, it does
not help at all.

passBool = true
if $userid.length < 4 or $userid.length > 20 or $password.length < 4

or $password.length > 20
passBool = false
puts “Please provide a User ID and Password which are at least 4
characters long and at most 20 characters long.”
end
if areThereIllegalCharactersInLoginInfo == true
passBool = false
puts “Please provide a User ID and Password which contain only
standard characters. Special characters are not permitted.”
end
end
end

Hello Ron,

First off, welcome to wxRuby. Your lucky I’m up this early, as I should
have been in bed an hour ago, but you know how it goes. lol

The answer to your solution, is to intercept a evt_close on your window
class, to prevent the window from being destroyed. What is happening,
is
when you run your script, the App instance is initialized with
Wx::App.run
method. And the thing is, there can only ever be one instance of
Wx::App at
any run time of your script. So if you exit out of the Main Loop for
Wx::App, then it’s going to fail, when you try to re-initialize /
re-create
your App / Window. Mainly cause your trying to re-create your Window,
after
wxWidgets has already released the App Instance.

The solution to your problem, is two fold. First off, move your logical
handling code into your Window class. This will ensure that your code
is
executed, and allow wxWidgets to continue operating for you. You should
never exit the Wx::App main loop, unless your actually exiting the
program
itself.

Second, if you want your window to dis-appear, but the app to remain
running, you need to do two things. One, ensure that Wx::App, doesn’t
exit
when the Main Window Instance (The first / Only instance of a Wx::Frame)
is
destroyed. This can be done with Wx::App#set_exit_on_frame_destroy()
method
(Referenced
herehttp://wxruby.rubyforge.org/doc/app.html#App_setexitonframedelete).
This will ensure that if there are no other Window instances available,
that wxWidgets will not close out the app, and de-reference the main
instance of the App.

The second part, is that there are two ways to handle getting rid of a
Window. The first, obviously being the close method, which will close
the
window, and Destroy the reference to the Window. Which will require you
to
re-create a new instance of the Window. The second method, is to simply
hide the window. This is different from minimize, you just use the hide
method on the Frame itself, and it will make the window dis-appear,
looking
as though it had been closed, but the Window instance will not be
destroyed,
and you will have it available, to re-display to the end user, should
you
need to use the window again.

I hope that this helps you understand what is going on.

L8ers,

Mario

Hey Mario, thanks for your quick reply. Incredibly informative too, now
I have a lot of options to deal with the login screen.

I am a little confused though. I still don’t see a way to have more than
one window in the entire ruby script.

“And the thing is, there can only ever be one instance of Wx::App at any
run time of your script.”
“You should never exit the Wx::App main loop, unless your actually
exiting the program itself.”
From what you say here it almost sounds as if every ruby script can have
only one window and no other. What if I needed to use app to show a
login screen first, then after that a main game window, etc? I could
still have the main script running while the main_loop is running if I
gave the window its own thread, but that would still be the only
allowable instance of the app in the entire program? If there can only
ever be one occurence of app in the code, and to create two different
windows from two different classes one would need two occurences of app
in the code… XD doesn’t that mean each rubyscript can only ever
have one window?

I see how the hide method can be useful for the login screen, and I can
certainly place the string verification code into the frame class.
Definitely a solution for the exception on the login screen. But I still
need to have the same ruby script create a main game window after the
login screen is finished/hidden.

Is there perhaps a way to create a second window and show that one
within the execution of the same main_loop? I could automate control of
the main_loop in its own thread through global variables.

Is there any way at all to have two different windows in the same ruby
program?

I’m thinking that if instead of requiring obtainlogin.rb I could perhaps
execute it as a separate process from the main script, and then I could
launch another process later for the main game window, but then global
variables wouldn’t be shared with the main script. Would have to mess
with pipes to do that?

Also, if it’s impossible to have more than one window with wxRuby, is
there another rubygem GUI library that anyone knows about which would
allow two different windows to be opened in the same ruby script?
Somehow it seems like I must be missing something because I wouldn’t
expect such a large robust library to be limited to
one-window-per-program.

Yes, that is much clearer. Thanks for taking the time to write the code
and show me.

I realize I probably seem like a Ruby noob. I’ve been learning Ruby for
almost two weeks and so far I love it. I’ve coded games in VB6 and
PHP/MySQL and Flash Actionscript, and I’ve coded other kinds of programs
in C++. Ruby is definitely different but I can see a lot of good
qualities from different languages packed together into Ruby.

I found Rubygame library and it looks great for the graphical combat
screen, but has absolutely no utilities like buttons/textboxes/etc, so
it’s great that Wx can still be used.

I also see what you mean by having to put all the code of the client
into the Wx classes. I’d prefer if possible to leave things like the
connection protocol, socket communication, macro key functions, sound
effect calls, etc, outside of the frame classes and the main_loop.

If I wanted to keep handling connection events from the main script
while the main_loop was executing, I could use a separate thread for the
main_loop, but would there be a way to hide/show a frame from a thread
outside the main_loop? Like ‘def methodX; self.hide; end’ in one of the
frame classes, and ‘$loginFrame.methodX’ from outside the main_loop
thread? Or $loginFrame.hide?

I know I can call methods defined by the main-thread from spawned-thread
blocks so it ought to work the same way in reverse if I use global
variables for all the frame instances?

Hello Ron,

On Fri, Oct 22, 2010 at 3:36 PM, Ron S. [email protected]
wrote:

Hey Mario, thanks for your quick reply. Incredibly informative too, now
I have a lot of options to deal with the login screen.

Your Welcome.

I am a little confused though. I still don’t see a way to have more than
one window in the entire ruby script.

Okay, I understand where your confusion is below, I’ll just skip down
below
all this, and explain it in better detail.

ever be one occurence of app in the code, and to create two different
Is there perhaps a way to create a second window and show that one
with pipes to do that?

Also, if it’s impossible to have more than one window with wxRuby, is
there another rubygem GUI library that anyone knows about which would
allow two different windows to be opened in the same ruby script?
Somehow it seems like I must be missing something because I wouldn’t
expect such a large robust library to be limited to
one-window-per-program.

Alright, with all that out of the way, the first thing you will need to
realize, is that Wx::App, isn’t a Window Class, and is not sub-classed
of a
Wx::Window or Wx::Frame. If you goto the API reference documentation,
http://wxruby.rubyforge.org/doc/app.html, and look for the Sub-Section
of
Derived From, you’ll see that Wx::App descends from Wx::EvtHandler and
Object.

I don’t know what kind of programming background you have, but to look
at
wxRuby in the fashion of a MVC (Model - View - Controller) setup,
Wx::App
would be the Controller setup. It’s your Main Entry Point into running
your
program, and deciding where to go. Wx::App.run, or Wx::App#on_init is
your
Main Entry point, into your entire program, all your windows will either
be
created from here, or be setup to be ready to be created from the rest
of
your program. All your initialization of library functions, and data
stores
you need, would be done from this method.

The View Part, actually falls under the class of Wx::Frame. There’s a
common mis-conception when first dealing with wxWidgets in general, the
difference between Window, and Frame. Mainly cause of Microsoft
Windows,
and how their API is setup, Window means Window. An actual window
displayed
to the user, that has a minimize, maximize, and close button on it.

Where as with wxWidgets, what is considered a window, is actually
considered
a Frame, with a minimize, a maximize, and a close button on it. A
Window in
wxWidgets is actually considered any control that can be displayed on
the
screen. You’ll find if you go through the API Documentation, and look
at
the sub-section Derived From, a good 90 percent of them, have the Window
class in it. The exception to the rule, is of course Sizers, Menus,
AuiManager, etc, etc, where these are basically internal data
structures,
that wxWidgets utilizes, to create the necessary UI Elements on Linux,
Windows, and Mac OS X.

Each Platform, and basically each GUI Toolkit has different methods in
which
to handle the above cases of items, or may not have them at all (As with
Sizers aren’t native to Windows, but is available on Linux with GTK and
on
OS X with NSView, and with Menus, Windows and Linux with GTK have Menu
Items, where as OS X has Data Entries to Represent Menu Items.) So,
let’s
say with your Example, your wanting to do a Development of a Game, where
you
have a Login, and a Main Display Window, where the Login is a User
Prompt to
ask for Login information to get into the game, and the Main Display
Window,
is where all actual game play occurs. I’ll give you a very basic design
to
show you how it works, and explain it further with comments.

I’m writing the code as I go, so it may not be 100 percent correct, but
you
should be able to run the code, without any problems.

– CODE BEGINS HERE –
#!/usr/bin/env ruby

Here we are loading wxRuby by any possible means, either by a system

install, or by a Ruby Gems install. If we can’t find a system

install,
then we

will try to load through RubyGems, if available, and if that fails,

we’ll
just

return the original error, saying that we can’t load wxRuby, as it’s

probably not

installed.

begin
require ‘wx’
rescue e => LoadError
begin
require ‘rubygems’
require ‘wx’
rescue LoadError
raise e
end
end

This is the window that will be the Main Display Window

class GameWindow < Wx::Frame
def initialize
# The parent of this window is desktop, so nil is used
# We don’t need a specific ID for this window, so -1 is used
# Our Title for our new Window is “Game Window”
super(nil,-1,“Game Window”)
# Here we create all of our stuff needed to play the game,
# such as UI Elements, and stuff that needs to be displayed in
# The game Window. No other window controls are created here.
@te =
Wx::TextCtrl.new(self,-1,:pos=>[0,0],:size=>[200,20],:style=>Wx::TE_RICH2|Wx::TE_AUTO_URL|Wx::TE_PROCESS_ENTER)
# After we create our controls, we setup our event handlers, for
gathering events.
evt_text_enter @te, :input_handle_enter
end

This is where we define our Logical methods, to handle game

def input_handle_enter
Wx::MessageDialog.new(self,“You entered: #{@te.get_value}”,“User
Input”,
Wx::OK)
end
end

Now we setup our Login Window, which will be displayed first, then

will
pass off to

the Main Display Window to continue running.

class LoginWindow < Wx::Frame
def initialize
super(nil,-1,“Login”)
table = Wx::GridSizer.new(3,2,0,0)
table.add(Wx::StaticText.new(self,-1,“Username:”),0,Wx::ALIGN_LEFT)
table.add(@user = Wx::TextCtrl.new(self,-1,“”),1,Wx::EXPAND|Wx::ALL)
table.add(Wx::StaticText.new(self,-1,“Password:”),0,Wx::ALIGN_LEFT)
table.add(@pass =
Wx::TextCtrl.new(self,-1,“”,:style=>Wx::TE_PASSWORD),1,WX::EXPAND|Wx::ALL)
table.add_spacer
table.add(@login = Wx::Button.new(self,-1,"Login

"),1,Wx::EXPAND|Wx::ALL)
self.set_sizer(table)

evt_button @login, :on_login_push

end

def on_login_push
uname = @user.get_value
upass = @pass.get_value
unless uname.empty? AND upass.empty?
# Attempt to login here, and process success or failure.
if success
gw = GameWindow.new
gw.show
self.hide
end
end
end

class MyGameApp < Wx::App
def on_init
lw = LoginWindow.new
lw.show
end
end

MyGameApp.new.main_loop
– CODE ENDS HERE –

As you can see, I create the Login Window, which handles the login
process,
and if it’s successful, then will create the game window, and hide
itself.
The App is still running, and never exits, and your windows will
continue
to display, and run, and you won’t get any Pesky THE_APP already
initialized
segfaults. Now, keep in mind, if you want to call methods on your App
class, you can simply use the method Wx::get_app(), or you can use
Wx::THE_APP to get the instance of your main App, and execute the method
on
it. Though, it’s strongly suggested that you don’t put game loops and
such
that require access to your Game Window, in your App, as your crossing
between objects, and the self reference changes between Objects, when
you
get to that point.

EG: Calling a Method on your App class, means self refers to the
instance of
the App class itself, where as calling a method on your Window class,
means
self refers to the instance of the Window class. And by that, instance
variables will be different between the two, or non-existent between the
two.

I hope this makes things clearer.

Mario

Mario S. wrote in post #957323:

I bit the bullet and just went with the flow, coded the app to
load/show/hide from within the main_loop. I have a login screen, main
screen, and a player creation screen. Although I can’t help but
load/show the player creation and main screens from the socket thread
that is outside the main_loop. Even though it’s calling a method from a
frame class it’s still calling from outside main_loop, etc. It works 10%
of the time, but 90% of the time I get a segmentation fault when trying
to show the player creation screen (the .show() method). Isolated it
down to that line by using puts before and after it.

I’ve searched these forums and found some tips, tried some of them but
they haven’t helped yet. I don’t need to boost GC speed because I am
getting the fault in the same place all the time, it’s just that 10% of
the time it does not occur and the creation screen shows and behaves
normally. I tried GC.disable in my script but that didn’t solve the
problem, so I don’t think it’s caused by garbage collection.

Green Threads. Which basically means, that a Thread is created
internally
in the Interpreter that is basically an Emulated Thread, but not a true
native thread. This basically means that Ruby is handling all the
scheduling and such for each of the threads, instead of the OS itself.
Ruby
1.9 on the other hand, actually implements Native threads, where the OS
is
handling the Threads itself, and not Ruby.

What this means to you, is that if you were to use Ruby 1.8 Threads, and
you
have something like wxWidget’s main_loop running, 99.9999 percent of the
time will be spent on main_loop, giving ruby extremely little chance to
run
any other threads. If at all.

This answers a big question of mine. The client stops communicating with
the server when the GUI is shown, until I start moving the mouse. The
client only continues to process the socket thread if I continue to move
the mouse. So if I run it on ruby1.9.1 that’ll take care of that
problem?

Turns out I can’t uninstall ruby1.8 without removing ruby completely.
Ruby doesn’t run if I have only 1.9.1 installed, oddly enough. So should
I just leave ruby1.8 installed and install ruby1.9.1? Will that mean any
script I run will automatically use ruby1.9.1? RVM seems to be way too
complicated, not sure if I want to use RVM. XD

If all your doing is Reading Variables, and not assigning to them from
another thread, then you should be fine. But if your assigning data
from
other threads, then you need to create a Mutex, lock it for the period
that
your updating the data, then unlock it when your finished. If you
don’t,
then you could get those nice little fatal errors, about access
violation of
memory addresses. I’m sure with your C++ background, you probably have
a
good idea what I mean by this.

I will definitely need to be modifying the properties of the class
instances that are initiated within the main_loop, from outside the
main_loop in the socket thread. So it sounds like I’ll have to be using
locks. Thanks for telling me about that, probably would have taken me a
while to find that.

Also - this is probably what is causing the segmentation faults? The
fact that I don’t have synchronized blocks / mutex locks?

Thankfully, wxRuby allows you to write your own main_loop function, if
you
were to sub-class Wx::App. and using Wx::App#pending to see if there
are
any wxWidgets events pending, and if there are, using Wx::App#dispatch
to
dispatch events to be executed. Using this in concert with RubyGame, or
any
other library’s own way of processing their own events, may help you
utilize
what you want to keep things running smoothly.

What if I don’t need to execute any code in the wx main_loop while the
Rubygame main_loop is running? I can handle the combat mode using only
Rubygame.

Does that mean that, instead of rewriting the main_loop, I could just
execute the Rubygame main_loop from inside of the wx main_loop? I could
tell the wx main_loop to sleep while the Rubygame main_loop is
executing, just to make sure it waits for combat to end.

I do hope that this helps you out, and progresses you further in
developing
your application / game.

L8ers,

Mario

Yeah, you’ve been incredibly helpful. I don’t think I would have got
WxWidgets to show multiple windows without your explanation on the
main_loop etc. Thanks! :slight_smile:

Hello again Ron,

On Sun, Oct 24, 2010 at 2:28 AM, Ron S. [email protected]
wrote:

Yes, that is much clearer. Thanks for taking the time to write the code
and show me.

Not a problem, and I’m glad that you can finally understand where this
is.

I realize I probably seem like a Ruby noob. I’ve been learning Ruby for
almost two weeks and so far I love it. I’ve coded games in VB6 and
PHP/MySQL and Flash Actionscript, and I’ve coded other kinds of programs
in C++. Ruby is definitely different but I can see a lot of good
qualities from different languages packed together into Ruby.

Ruby is Unique in the fact that it’s pure Object Oriented, and
therefore,
fits many encapsulations of elements within a program.

I found Rubygame library and it looks great for the graphical combat
screen, but has absolutely no utilities like buttons/textboxes/etc, so
it’s great that Wx can still be used.

I also see what you mean by having to put all the code of the client
into the Wx classes. I’d prefer if possible to leave things like the
connection protocol, socket communication, macro key functions, sound
effect calls, etc, outside of the frame classes and the main_loop.

I understand, I’ll get a bit more indepth here in a moment…

If I wanted to keep handling connection events from the main script
while the main_loop was executing, I could use a separate thread for the
main_loop, but would there be a way to hide/show a frame from a thread
outside the main_loop? Like ‘def methodX; self.hide; end’ in one of the
frame classes, and ‘$loginFrame.methodX’ from outside the main_loop
thread? Or $loginFrame.hide?

I know I can call methods defined by the main-thread from spawned-thread
blocks so it ought to work the same way in reverse if I use global
variables for all the frame instances?

Threads are a tricky business, especially when you get into Multiple
Threads, and that you also need to realize something else. Depending
upon
what version of the Ruby Interpreter your using, you have to deal with
another layer of trouble. In Ruby 1.8, it is designed at the core, to
use
Green Threads. Which basically means, that a Thread is created
internally
in the Interpreter that is basically an Emulated Thread, but not a true
native thread. This basically means that Ruby is handling all the
scheduling and such for each of the threads, instead of the OS itself.
Ruby
1.9 on the other hand, actually implements Native threads, where the OS
is
handling the Threads itself, and not Ruby.

What this means to you, is that if you were to use Ruby 1.8 Threads, and
you
have something like wxWidget’s main_loop running, 99.9999 percent of the
time will be spent on main_loop, giving ruby extremely little chance to
run
any other threads. If at all. Where as Ruby 1.9, it handles Threads
natively, which allows main_loop to run in it’s own native thread, and
allows you to create other threads, in which to actually
run simultaneously as the Main Thread.

Which brings me to Thread Safety. The main thing you want to be careful
about with dealing with Threads, is using them safely. Thread Safety
basically entails using a Mutex, or Semaphore to get a global lock
within
your program, and allow a certain thread to have exclusive access to the
variable data, including updating it with new information, while
preventing
other threads from having access for the time that your updating the
data.
If all your doing is Reading Variables, and not assigning to them from
another thread, then you should be fine. But if your assigning data
from
other threads, then you need to create a Mutex, lock it for the period
that
your updating the data, then unlock it when your finished. If you
don’t,
then you could get those nice little fatal errors, about access
violation of
memory addresses. I’m sure with your C++ background, you probably have
a
good idea what I mean by this.

Lastly, another thing you will need to be careful of, is the whole usage
of
two different libraries, that utilize a tight end Main Loop. RubyGame
utilizies a tight end Main Loop to allow processing of drawing, events,
and
so on, while wxWidgets also has it’s own tight end Main Loop, to handle
the
same things. Attempting to use these two in conjunction, requires a bit
of
advanced programming to get to work properly. Not to say that it can’t
be
done, it can, but it will be hard to do, as you will need to write a
sort of
merged main loop, that will handle wxRuby events, and handle RubyGame
events
at the same exact time, to keep both libraries running smoothly, as if
they
were separate.

Thankfully, wxRuby allows you to write your own main_loop function, if
you
were to sub-class Wx::App. and using Wx::App#pending to see if there
are
any wxWidgets events pending, and if there are, using Wx::App#dispatch
to
dispatch events to be executed. Using this in concert with RubyGame, or
any
other library’s own way of processing their own events, may help you
utilize
what you want to keep things running smoothly.

I do hope that this helps you out, and progresses you further in
developing
your application / game.

L8ers,

Mario

I am currently in the wxRuby chat room, if you wish to talk with me in
person, and I can answer some of these questions for you.

require ‘thread’
$mutex = Mutex.new

this method is in class MainScreenFrame < Wx::Frame

def showPlayerCreationScreen

this method ends up getting called from the socket thread.

$mutex.synchronize {
$theCreationScreen = PlayerCreationFrame.new()
$theCreationScreen.show # segmentation fault occurs on this line

10% of the time there will be no segmentation fault and the screen

will show/behave fine.
}
end

I’ve placed puts at the end of the def initialize method in the
PlayerCreationFrame class, and the puts always gets shown before the
segmentation fault occurs, so it’s not occurring with initialization of
PlayerCreationFrame (unless it occurs as the initialization method
ends?).

GC.disable has no effect.

Mario S. wrote in post #957691:

I am currently in the wxRuby chat room, if you wish to talk with me in
person, and I can answer some of these questions for you.

Awesome, will drop on by. That’s an IRC chatroom on freenode, right?
#wxruby? Or do you mean another kind of chat room?

For those of you who don’t have an IRC Client, and would like to use a
Web
Page chat system, you can use the following:
Kiwi IRC FreeNode no longer allows
Mibbit to work, so this will allow you to get into the wxRuby channel
without needing to install an IRC Client, or figuring out which room to
go
to. :wink: