From sy1234 at gmail.com  Sat Sep 16 23:18:32 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 16 Sep 2006 22:18:32 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
Message-ID: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>

This was a HUGE problem for me, when I had multiple triggers each
doing their own thing.

I'm not entirely sure what's going on, but I tracked this down to two solutions:

1. Work with match data as soon as possible!
2. Wrap complex methods in their own thread.

1) MatchData

bad:
 conf.remote_triggers['trigger'] = Proc.new do |inwin, outwin, match|
   _complex_method(match)
 end

better:
 conf.remote_triggers['trigger'] = Proc.new do |inwin, outwin, match|
   _complex_method(match[1].to_s)
 end

2) Complex methods should be in their own threads.  It's really simple to do:

 Thread.new do
   _complex_method
 end
 Thread.new do
   _complex_method2
 end

From sy1234 at gmail.com  Sat Sep 16 23:27:33 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 16 Sep 2006 22:27:33 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
Message-ID: <1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>

Oh crap, so much for that.. the problem reappears semi-randomly..
sigh.  Maybe I need to delay my code a little bit, so my triggers
aren't simultaneous..

From sy1234 at gmail.com  Sat Sep 16 23:45:49 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 16 Sep 2006 22:45:49 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
Message-ID: <1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>

On 9/16/06, Sy Ali <sy1234 at gmail.com> wrote:
> Oh crap, so much for that.. the problem reappears semi-randomly..
> sigh.  Maybe I need to delay my code a little bit, so my triggers
> aren't simultaneous..

Ok, threading and a 0.1 sleep statement seems to help a lot..

From zond at troja.ath.cx  Sun Sep 17 05:07:53 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 11:07:53 +0200
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
Message-ID: <20060917090753.GA13448@troja.ath.cx>


Remember that if you modify stuff in one place in ruby, the same stuff
will be modified everywhere. You can try to do ".dup" or ".clone" on
stuff so that you get your own copy in each method, if you plan on
changing it.

//Martin

On Sat, Sep 16, 2006 at 10:45:49PM -0500, Sy Ali wrote:
> On 9/16/06, Sy Ali <sy1234 at gmail.com> wrote:
> > Oh crap, so much for that.. the problem reappears semi-randomly..
> > sigh.  Maybe I need to delay my code a little bit, so my triggers
> > aren't simultaneous..
> 
> Ok, threading and a 0.1 sleep statement seems to help a lot..
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From wccrawford at gmail.com  Sun Sep 17 05:39:03 2006
From: wccrawford at gmail.com (William Crawford)
Date: Sun, 17 Sep 2006 05:39:03 -0400
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <20060917090753.GA13448@troja.ath.cx>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
Message-ID: <1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>

If you get random errors now, a sleep cycle will only slow them down.
they'll appear again later.

Instead, I'd do what Martin says...  When you need to iterate over a hash,
clone it and iterate over that.  The other option is Mutexes and locking and
such, but I've never bothered researching that for Ruby yet.  I would
imagine that Mutexes would be faster, though.

On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
>
>
> Remember that if you modify stuff in one place in ruby, the same stuff
> will be modified everywhere. You can try to do ".dup" or ".clone" on
> stuff so that you get your own copy in each method, if you plan on
> changing it.
>
> //Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/muby-talk/attachments/20060917/024dc43d/attachment.html 

From janne.junnila at gmail.com  Sun Sep 17 08:05:03 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Sun, 17 Sep 2006 15:05:03 +0300
Subject: [Muby-talk] Memory leak
Message-ID: <770a6dc40609170505r297d9316g2879e08614ae906c@mail.gmail.com>

Hi to the list since this is my first post!

And now to the real stuff...

I've been suffering of a memory leak and I finally tracked it down to
lib/style.rb.
(Using this: http://scottstuff.net/blog/articles/2006/08/17/memory-leak-profiling-with-rails)

This could also be the reason why in some post it mentioned slow down
after a while.. (for me it really did after 95% of my 1Gb of RAM got
eaten)

If I interpreted the code correctly it keeps calling init_pairs and
@initialized doesn't switch to true state on any line.

So, my fix for the function was like:

def self.init_pairs
  unless @initialized
     1.upto(Ncurses.COLOR_PAIRS - 1) do |n|
        @@instances << ColorPair.new(n)
     end
     @initialized = true
  end
end

I haven't yet looked much at the user scripting API but I hope to do
so after I get the basics working ;)

- Janne Junnila

From sy1234 at gmail.com  Sun Sep 17 08:19:07 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 07:19:07 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
Message-ID: <1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>

> On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> >
> > Remember that if you modify stuff in one place in ruby, the same stuff
> > will be modified everywhere. You can try to do ".dup" or ".clone" on
> > stuff so that you get your own copy in each method, if you plan on
> > changing it.

On 9/17/06, William Crawford <wccrawford at gmail.com> wrote:
> If you get random errors now, a sleep cycle will only slow them down.
> they'll appear again later.
>
> Instead, I'd do what Martin says...  When you need to iterate over a hash,
> clone it and iterate over that.  The other option is Mutexes and locking and
> such, but I've never bothered researching that for Ruby yet.  I would
> imagine that Mutexes would be faster, though.

Crap.. they _are_ reappearing.

I know that this problem has to do with using triggers.  That's the
only hash I'm using.

I'm not sure how to approach using .dup for triggers.. maybe at the
beginning of my huge procedures I need to dup the trigger hash and use
it instead.. the thing is that I'm only very temporarily using
triggers for these larger routines..

From zond at troja.ath.cx  Sun Sep 17 09:23:45 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 15:23:45 +0200
Subject: [Muby-talk] Memory leak
In-Reply-To: <770a6dc40609170505r297d9316g2879e08614ae906c@mail.gmail.com>
References: <770a6dc40609170505r297d9316g2879e08614ae906c@mail.gmail.com>
Message-ID: <20060917132344.GA13614@troja.ath.cx>


Oooh! Thanks! I must have been a bit too quick when doing that shit!

I just commited a fix, looking like:
------------------8<---------------------
Index: style.rb
===================================================================
--- style.rb    (revision 201)
+++ style.rb    (working copy)
@@ -14,10 +14,11 @@
       @@instances = []
       @@initialized = false
       def self.init_pairs
-        unless @initialized
+        unless @@initialized
           1.upto(Ncurses.COLOR_PAIRS - 1) do |n|
             @@instances << ColorPair.new(n)
           end
+         @@initialized = true
         end
       end
       def self.get_pair(fg, bg)
------------------8<---------------------

//Martin

On Sun, Sep 17, 2006 at 03:05:03PM +0300, Janne Junnila wrote:
> Hi to the list since this is my first post!
> 
> And now to the real stuff...
> 
> I've been suffering of a memory leak and I finally tracked it down to
> lib/style.rb.
> (Using this: http://scottstuff.net/blog/articles/2006/08/17/memory-leak-profiling-with-rails)
> 
> This could also be the reason why in some post it mentioned slow down
> after a while.. (for me it really did after 95% of my 1Gb of RAM got
> eaten)
> 
> If I interpreted the code correctly it keeps calling init_pairs and
> @initialized doesn't switch to true state on any line.
> 
> So, my fix for the function was like:
> 
> def self.init_pairs
>   unless @initialized
>      1.upto(Ncurses.COLOR_PAIRS - 1) do |n|
>         @@instances << ColorPair.new(n)
>      end
>      @initialized = true
>   end
> end
> 
> I haven't yet looked much at the user scripting API but I hope to do
> so after I get the basics working ;)
> 
> - Janne Junnila
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From janne.junnila at gmail.com  Sun Sep 17 09:36:26 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Sun, 17 Sep 2006 16:36:26 +0300
Subject: [Muby-talk] Splitted configuration loading
Message-ID: <770a6dc40609170636w4d3c9777g75a7b606c46868a5@mail.gmail.com>

Hi,

I modified the source code for loading user scripts / config so that
it first loads the config and after the UI has been initialized it
loads the scripts in the userdir.

I'm not sure if this is how it should be done, but IMO it could be
good for scripts to have access to the UI in the loading phase...

Anyways, there's a diff attached... (It's diff'ed against the latest
release, not sure if it still fits the SVN, sorry...)

- Janne Junnila

PS. Sorry for possible lame indenting in some of the files (haven't
had time to adjust my editor yet) Files include: muby.rb
lib/configuration.rb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: muby_config.patch
Type: text/x-patch
Size: 3508 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/muby-talk/attachments/20060917/a989037e/attachment-0001.bin 

From wccrawford at gmail.com  Sun Sep 17 10:00:57 2006
From: wccrawford at gmail.com (William Crawford)
Date: Sun, 17 Sep 2006 10:00:57 -0400
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
Message-ID: <1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>

On 9/17/06, Sy Ali <sy1234 at gmail.com> wrote:
>
> Crap.. they _are_ reappearing.


I won't say it ;)

I know that this problem has to do with using triggers.  That's the
> only hash I'm using.
>
> I'm not sure how to approach using .dup for triggers.. maybe at the
> beginning of my huge procedures I need to dup the trigger hash and use
> it instead.. the thing is that I'm only very temporarily using
> triggers for these larger routines..
>

Yeah, that's where you'd have to dupe them.  That's why I said Mutexes would
probably be faster.  You'll have to make a LOT of duplicates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/muby-talk/attachments/20060917/49080fdb/attachment.html 

From sy1234 at gmail.com  Sun Sep 17 12:11:20 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 11:11:20 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
	<1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
Message-ID: <1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>

On 9/17/06, William Crawford <wccrawford at gmail.com> wrote:
> Yeah, that's where you'd have to dupe them.  That's why I said Mutexes would
> probably be faster.  You'll have to make a LOT of duplicates.

I'm looking at Mutexes, and I think I understand.. but I'm not really
sure how to adapt them to muby's triggers.  Something tells me that
this should all go in a higher level, into the muby code itself..

I'm going to keep playing.. I think I might be able to find a dirty
hack that works, to help me understand and clean up my code some more.

From sy1234 at gmail.com  Sun Sep 17 12:34:51 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 11:34:51 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
	<1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
	<1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>
Message-ID: <1e55af990609170934k2018264ep7c0ef5afccfc64c5@mail.gmail.com>

Inspired by my home-made text replacement feature (go figure..), I was
able to remove the dependancy on triggers in one of the complex
methods, so there is no longer a collision of the need to modify the
triggers list.  Yay!

Basically, I was able to remove trigger use from within a method to
outside that method.

I have a lot of code which creates a trigger on the fly, and then
deletes it once it's been used.. to avoid any unpleasantnesses which
do happen when triggers are left hanging around.

From zond at troja.ath.cx  Sun Sep 17 13:44:20 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 19:44:20 +0200
Subject: [Muby-talk] Splitted configuration loading
In-Reply-To: <770a6dc40609170636w4d3c9777g75a7b606c46868a5@mail.gmail.com>
References: <770a6dc40609170636w4d3c9777g75a7b606c46868a5@mail.gmail.com>
Message-ID: <20060917174420.GA14907@troja.ath.cx>


Ah, but that is what the conf.startup_triggers are for. Each entry in
there will be executed once the environment is completely set up.

This was originally so that the user could change the defaults for how
the environment was set up - how big the input window was etc, and
still get a good hook where the user could insert code to be executed
_after_ the environment was set up.

Your solution may be better or worse, but please motivate why the
separation in execution time you make between rc-file and userdir is
reasonable.

//Martin

On Sun, Sep 17, 2006 at 04:36:26PM +0300, Janne Junnila wrote:
> Hi,
> 
> I modified the source code for loading user scripts / config so that
> it first loads the config and after the UI has been initialized it
> loads the scripts in the userdir.
> 
> I'm not sure if this is how it should be done, but IMO it could be
> good for scripts to have access to the UI in the loading phase...
> 
> Anyways, there's a diff attached... (It's diff'ed against the latest
> release, not sure if it still fits the SVN, sorry...)
> 
> - Janne Junnila
> 
> PS. Sorry for possible lame indenting in some of the files (haven't
> had time to adjust my editor yet) Files include: muby.rb
> lib/configuration.rb


> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From zond at troja.ath.cx  Sun Sep 17 13:47:24 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 19:47:24 +0200
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609170934k2018264ep7c0ef5afccfc64c5@mail.gmail.com>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
	<1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
	<1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>
	<1e55af990609170934k2018264ep7c0ef5afccfc64c5@mail.gmail.com>
Message-ID: <20060917174724.GB14907@troja.ath.cx>


I would guess that you are bringing lots of problem on yourself.

Threads are complex creatures, and they bring with them the need for
locks and duplicates etc.

Are you really sure you are not overusing threads? Cause you may
actually get rid of your problems if you stop using threads
completely. On the other hand, perhaps that is not possible for you.

But if you analyze your problem properly Im sure you will be able to
pinpoint what race condition or deadlock your threads cause, and add a
lock or other solution to solve it.

The muby code itself is extremely simple in its trigger handling, it
starts no new threads on its own, all that horrible logic is left to
the scripter.

//Martin

On Sun, Sep 17, 2006 at 11:34:51AM -0500, Sy Ali wrote:
> Inspired by my home-made text replacement feature (go figure..), I was
> able to remove the dependancy on triggers in one of the complex
> methods, so there is no longer a collision of the need to modify the
> triggers list.  Yay!
> 
> Basically, I was able to remove trigger use from within a method to
> outside that method.
> 
> I have a lot of code which creates a trigger on the fly, and then
> deletes it once it's been used.. to avoid any unpleasantnesses which
> do happen when triggers are left hanging around.
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From sy1234 at gmail.com  Sun Sep 17 14:16:39 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 13:16:39 -0500
Subject: [Muby-talk] Memory leak
In-Reply-To: <770a6dc40609170505r297d9316g2879e08614ae906c@mail.gmail.com>
References: <770a6dc40609170505r297d9316g2879e08614ae906c@mail.gmail.com>
Message-ID: <1e55af990609171116o202ddeddvfdc92b2954645b69@mail.gmail.com>

On 9/17/06, Janne Junnila <janne.junnila at gmail.com> wrote:
> Hi to the list since this is my first post!

Hey there Janne.  Helping to fix a problem is an excellent first post.  =)

From janne.junnila at gmail.com  Sun Sep 17 14:26:02 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Sun, 17 Sep 2006 21:26:02 +0300
Subject: [Muby-talk] Triggers
Message-ID: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>

I ran into a problem with the current trigger system.
It seems that it doesn't support multiple triggers on one match.

Now, I tried to make a module which waits for a local trigger (regexp /^(.*)$/)
and after that starts gathering text from mud until prompt
(remote_trigger regexp /^(.*)$/, for prompt something like /^(.*)>$/)

Now I wanted to make a script which uses the module by first
triggering prompt from MUD input and then query the module for the
result of the previous command given.

The problem is the new prompt trigger overrides the old one, doesn't it?

My way to handle this would be add a more sophisticated / comples
feature for bigger modules - hooks.
It would work like this (or kind of this):

register_mud_input_hook Proc.new do |inputwin, outputwin, match|
  if match.match(/.*/)
    ...
  end
end

same for user input...

- Janne Junnila

From janne.junnila at gmail.com  Sun Sep 17 14:28:43 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Sun, 17 Sep 2006 21:28:43 +0300
Subject: [Muby-talk] Splitted configuration loading
In-Reply-To: <20060917174420.GA14907@troja.ath.cx>
References: <770a6dc40609170636w4d3c9777g75a7b606c46868a5@mail.gmail.com>
	<20060917174420.GA14907@troja.ath.cx>
Message-ID: <770a6dc40609171128n408c14b6rf776c054f8507d6b@mail.gmail.com>

On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
>
> Ah, but that is what the conf.startup_triggers are for. Each entry in
> there will be executed once the environment is completely set up.

Oh oh... didn't know about them... I'm sorry for wasting your time.
I guess the triggers are a cleaner and better way.

- Janne

From sy1234 at gmail.com  Sun Sep 17 14:49:12 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 13:49:12 -0500
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <20060917174724.GB14907@troja.ath.cx>
References: <1e55af990609162018u30d6f330s60ecca915e05dec3@mail.gmail.com>
	<1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
	<1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
	<1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>
	<1e55af990609170934k2018264ep7c0ef5afccfc64c5@mail.gmail.com>
	<20060917174724.GB14907@troja.ath.cx>
Message-ID: <1e55af990609171149i5b837e6emdc2d36aeb1cb7dba@mail.gmail.com>

On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> Are you really sure you are not overusing threads? Cause you may
> actually get rid of your problems if you stop using threads
> completely. On the other hand, perhaps that is not possible for you.

The threads are used to delay certain actions, since spamming too much
will get me disconnected, or when multiple methods can be set off,
when neither one depends on the other.. and they both have
conflicting/overlapping triggers..

Funny that my solution was getting me disconnected..  =)

Well.. I simplified things.. I was just taking things to an extreme to
see what would happen.

> But if you analyze your problem properly Im sure you will be able to
> pinpoint what race condition or deadlock your threads cause, and add a
> lock or other solution to solve it.

I had to do a lot of hunting to understand more about what was going
on.. but once I did it was straightforward to understand.  Luckily I
had an easy way to fix it.. but if my scripting was much more complex,
I'd definitely need to learn some really crazy solutions.

From sy1234 at gmail.com  Sun Sep 17 15:09:20 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 14:09:20 -0500
Subject: [Muby-talk] Triggers
In-Reply-To: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
Message-ID: <1e55af990609171209u42aaaee0o7cfa05bdce0ba3f3@mail.gmail.com>

Maybe I have some ideas which will help..

On 9/17/06, Janne Junnila <janne.junnila at gmail.com> wrote:
> I ran into a problem with the current trigger system.
> It seems that it doesn't support multiple triggers on one match.

That's true.  I've had to resort to various strange solutions.

One way is to create another trigger which is similar to (but not
exactly the same as) the first.

conf.remote_triggers[/A match!/] = ...
conf.remote_triggers[/^A match!/] = ...
conf.remote_triggers[/(A) match!/] = ...
etc..


> Now, I tried to make a module which waits for a local trigger (regexp /^(.*)$/)
> and after that starts gathering text from mud until prompt

Something like this?

@prompt = '^your prompt$'
@everything = '^(.*)$'
@prompts = 0
conf.remote_triggers[@prompt] = Proc.new do
  conf.remote_triggers[@everything] = Proc.new do |inwin, outwin, match|
#    do something with match
  end
  @prompts += 1
  if @prompts == 1 then
# Perform the "teardown"..
   @prompts = 0
    conf.remote_triggers.delete(@everything)
  end
end

I implemented something similar in the aardwolf scripting, for gagging
blocks of text between prompts.


> Now I wanted to make a script which uses the module by first
> triggering prompt from MUD input and then query the module for the
> result of the previous command given.
>
> The problem is the new prompt trigger overrides the old one, doesn't it?

You could do the scripting very differently, to make your one trigger
do multiple things under different circumstances..  you can set/unset
global variables to turn features on/off whenever the prompt is seen..

--+

> My way to handle this would be add a more sophisticated / comples
> feature for bigger modules - hooks.
> It would work like this (or kind of this):

I have no comment on this.. (I don't understand it well enough).. but
a solution in muby would be nice.. perhaps the user-experience would
be something like this:

conf.remote_triggers[1, @prompt] = ...
Where the number is the (optional) identifyer.  Any unique identifyer
could be in there.  Then muby would store this hash differently, so
that you can have stuff like this:
conf.remote_triggers[1, @prompt] = ...
conf.remote_triggers[2, @prompt] = ...
conf.remote_triggers[3, @prompt] = ...

This also leads into the idea of "groups" for triggers.. so this could
become something like this:

conf.remote_triggers["group_a", @prompt] = ...
conf.remote_triggers["group_a", something_else] = ...
conf.remote_triggers["group_a", another_trigger] = ...

and then you can perform group actions like:

conf.remote_triggers_delete("group_a")

.. just an idea..

From zond at troja.ath.cx  Sun Sep 17 15:46:27 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 21:46:27 +0200
Subject: [Muby-talk] Triggers
In-Reply-To: <1e55af990609171209u42aaaee0o7cfa05bdce0ba3f3@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<1e55af990609171209u42aaaee0o7cfa05bdce0ba3f3@mail.gmail.com>
Message-ID: <20060917194627.GA14948@troja.ath.cx>


I agree with Sy, your problems can be solved in simpler ways.

Let your scripting implement a simple state machine, that way you can
do whatever you want on each regexp and even different stuff depending
on what state your script is at the time.

//Martin

On Sun, Sep 17, 2006 at 02:09:20PM -0500, Sy Ali wrote:
> Maybe I have some ideas which will help..
> 
> On 9/17/06, Janne Junnila <janne.junnila at gmail.com> wrote:
> > I ran into a problem with the current trigger system.
> > It seems that it doesn't support multiple triggers on one match.
> 
> That's true.  I've had to resort to various strange solutions.
> 
> One way is to create another trigger which is similar to (but not
> exactly the same as) the first.
> 
> conf.remote_triggers[/A match!/] = ...
> conf.remote_triggers[/^A match!/] = ...
> conf.remote_triggers[/(A) match!/] = ...
> etc..
> 
> 
> > Now, I tried to make a module which waits for a local trigger (regexp /^(.*)$/)
> > and after that starts gathering text from mud until prompt
> 
> Something like this?
> 
> @prompt = '^your prompt$'
> @everything = '^(.*)$'
> @prompts = 0
> conf.remote_triggers[@prompt] = Proc.new do
>   conf.remote_triggers[@everything] = Proc.new do |inwin, outwin, match|
> #    do something with match
>   end
>   @prompts += 1
>   if @prompts == 1 then
> # Perform the "teardown"..
>    @prompts = 0
>     conf.remote_triggers.delete(@everything)
>   end
> end
> 
> I implemented something similar in the aardwolf scripting, for gagging
> blocks of text between prompts.
> 
> 
> > Now I wanted to make a script which uses the module by first
> > triggering prompt from MUD input and then query the module for the
> > result of the previous command given.
> >
> > The problem is the new prompt trigger overrides the old one, doesn't it?
> 
> You could do the scripting very differently, to make your one trigger
> do multiple things under different circumstances..  you can set/unset
> global variables to turn features on/off whenever the prompt is seen..
> 
> --+
> 
> > My way to handle this would be add a more sophisticated / comples
> > feature for bigger modules - hooks.
> > It would work like this (or kind of this):
> 
> I have no comment on this.. (I don't understand it well enough).. but
> a solution in muby would be nice.. perhaps the user-experience would
> be something like this:
> 
> conf.remote_triggers[1, @prompt] = ...
> Where the number is the (optional) identifyer.  Any unique identifyer
> could be in there.  Then muby would store this hash differently, so
> that you can have stuff like this:
> conf.remote_triggers[1, @prompt] = ...
> conf.remote_triggers[2, @prompt] = ...
> conf.remote_triggers[3, @prompt] = ...
> 
> This also leads into the idea of "groups" for triggers.. so this could
> become something like this:
> 
> conf.remote_triggers["group_a", @prompt] = ...
> conf.remote_triggers["group_a", something_else] = ...
> conf.remote_triggers["group_a", another_trigger] = ...
> 
> and then you can perform group actions like:
> 
> conf.remote_triggers_delete("group_a")
> 
> .. just an idea..
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From janne.junnila at gmail.com  Sun Sep 17 15:48:21 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Sun, 17 Sep 2006 22:48:21 +0300
Subject: [Muby-talk] Triggers
In-Reply-To: <1e55af990609171209u42aaaee0o7cfa05bdce0ba3f3@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<1e55af990609171209u42aaaee0o7cfa05bdce0ba3f3@mail.gmail.com>
Message-ID: <770a6dc40609171248l888820bye6506b2c54a08ba1@mail.gmail.com>

I think they could work but they seem a bit 'hack-like' to me...

On 9/17/06, Sy Ali <sy1234 at gmail.com> wrote:
> Maybe I have some ideas which will help..
>
> [...]
>
> That's true.  I've had to resort to various strange solutions.
>
> One way is to create another trigger which is similar to (but not
> exactly the same as) the first.
>
> conf.remote_triggers[/A match!/] = ...
> conf.remote_triggers[/^A match!/] = ...
> conf.remote_triggers[/(A) match!/] = ...
> etc..

Hacky - I want my triggers be exactly the thing I want to match :/

>
> [...]
>
> Something like this?
>
> @prompt = '^your prompt$'
> @everything = '^(.*)$'
> @prompts = 0
> conf.remote_triggers[@prompt] = Proc.new do
>   conf.remote_triggers[@everything] = Proc.new do |inwin, outwin, match|
> #    do something with match
>   end
>   @prompts += 1
>   if @prompts == 1 then
> # Perform the "teardown"..
>    @prompts = 0
>     conf.remote_triggers.delete(@everything)
>   end
> end
>

A bit hacky as well, though it can be useful in some circumstances...

>
> You could do the scripting very differently, to make your one trigger
> do multiple things under different circumstances..  you can set/unset
> global variables to turn features on/off whenever the prompt is seen..

I wouldn't like to put all my stuff into one trigger.
Of course I could implement the hook system with triggers, but it's
quite fundamental
so it might be better to be put in muby itself (Lyntin [A python based
mud-client] used a hook-based system, then a scripter would just
attach to the hooks (s)he would need and lyntin would call the methods
the scripter provided when attaching).

> I have no comment on this.. (I don't understand it well enough).. but
> a solution in muby would be nice.. perhaps the user-experience would
> be something like this:

My example snippet was the user-experience.

> This also leads into the idea of "groups" for triggers.. so this could
> become something like this:
>
> conf.remote_triggers["group_a", @prompt] = ...
> conf.remote_triggers["group_a", something_else] = ...
> conf.remote_triggers["group_a", another_trigger] = ...
>
> and then you can perform group actions like:
>
> conf.remote_triggers_delete("group_a")
>
> .. just an idea..

Well this could of course be a good thing to have. Though maybe some
more 'ruby-ish'
way could be used. Like conf.remote_triggers_add(self) where self
would be a class holding the triggers...

- Janne

PS. Already pretty late here, if I said something very stupid, forget
it :D Didn't bother to think about it so much.

From zond at troja.ath.cx  Sun Sep 17 15:48:33 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 21:48:33 +0200
Subject: [Muby-talk] 'hash modified during iteration' error and
	disconnection (solution)
In-Reply-To: <1e55af990609171149i5b837e6emdc2d36aeb1cb7dba@mail.gmail.com>
References: <1e55af990609162027g38ac9b74ya7f9229c2281ec67@mail.gmail.com>
	<1e55af990609162045v4e7c841bl66816575636824b@mail.gmail.com>
	<20060917090753.GA13448@troja.ath.cx>
	<1b4784dd0609170239y2feb9ea7y31cbddeae0cb2ef5@mail.gmail.com>
	<1e55af990609170519u79411112t7d992c6acaff4e39@mail.gmail.com>
	<1b4784dd0609170700p449c806kd682514b5fdd48d9@mail.gmail.com>
	<1e55af990609170911n36ee50c1ha2ff944611303167@mail.gmail.com>
	<1e55af990609170934k2018264ep7c0ef5afccfc64c5@mail.gmail.com>
	<20060917174724.GB14907@troja.ath.cx>
	<1e55af990609171149i5b837e6emdc2d36aeb1cb7dba@mail.gmail.com>
Message-ID: <20060917194833.GB14948@troja.ath.cx>

On Sun, Sep 17, 2006 at 01:49:12PM -0500, Sy Ali wrote:
> On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> > Are you really sure you are not overusing threads? Cause you may
> > actually get rid of your problems if you stop using threads
> > completely. On the other hand, perhaps that is not possible for you.
> 
> The threads are used to delay certain actions, since spamming too much
> will get me disconnected, or when multiple methods can be set off,
> when neither one depends on the other.. and they both have
> conflicting/overlapping triggers..

I see, well, for that kind of thing threads are usually the simplest
way. I have been thinking about adding some simple time-dependant
trigger helper to muby, but so far it has been hard to think about
something that is easier than what ruby is already giving us...

> Funny that my solution was getting me disconnected..  =)
> 
> Well.. I simplified things.. I was just taking things to an extreme to
> see what would happen.

:)

> > But if you analyze your problem properly Im sure you will be able to
> > pinpoint what race condition or deadlock your threads cause, and add a
> > lock or other solution to solve it.
> 
> I had to do a lot of hunting to understand more about what was going
> on.. but once I did it was straightforward to understand.  Luckily I
> had an easy way to fix it.. but if my scripting was much more complex,
> I'd definitely need to learn some really crazy solutions.

As is always the case :D

//Martin

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From zond at troja.ath.cx  Sun Sep 17 15:53:02 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 17 Sep 2006 21:53:02 +0200
Subject: [Muby-talk] Triggers
In-Reply-To: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
Message-ID: <20060917195302.GC14948@troja.ath.cx>


Well, I say like I usually do to Sy: Implement it in your scripting,
and if you think you have arrived at a simple and powerful solution,
send it to the list and we can talk about it.

One simple way is to just implement the register_mud_input_hook method
using a remote_trigger on /^(.*)$/ and use that for running your code
on all incoming lines.

Or if you really want to, try to implement it in the muby core, and
send the patch here, but then you really have to make it clean,
generic and in the spirit of the existing code.

//Martin

On Sun, Sep 17, 2006 at 09:26:02PM +0300, Janne Junnila wrote:
> I ran into a problem with the current trigger system.
> It seems that it doesn't support multiple triggers on one match.
> 
> Now, I tried to make a module which waits for a local trigger (regexp /^(.*)$/)
> and after that starts gathering text from mud until prompt
> (remote_trigger regexp /^(.*)$/, for prompt something like /^(.*)>$/)
> 
> Now I wanted to make a script which uses the module by first
> triggering prompt from MUD input and then query the module for the
> result of the previous command given.
> 
> The problem is the new prompt trigger overrides the old one, doesn't it?
> 
> My way to handle this would be add a more sophisticated / comples
> feature for bigger modules - hooks.
> It would work like this (or kind of this):
> 
> register_mud_input_hook Proc.new do |inputwin, outputwin, match|
>   if match.match(/.*/)
>     ...
>   end
> end
> 
> same for user input...
> 
> - Janne Junnila
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
Cold hands, no gloves.
###################################################################

From sy1234 at gmail.com  Sun Sep 17 18:35:46 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sun, 17 Sep 2006 17:35:46 -0500
Subject: [Muby-talk] Splitted configuration loading
In-Reply-To: <770a6dc40609171128n408c14b6rf776c054f8507d6b@mail.gmail.com>
References: <770a6dc40609170636w4d3c9777g75a7b606c46868a5@mail.gmail.com>
	<20060917174420.GA14907@troja.ath.cx>
	<770a6dc40609171128n408c14b6rf776c054f8507d6b@mail.gmail.com>
Message-ID: <1e55af990609171535s7a5db317s6d098a0aca93a3c3@mail.gmail.com>

On 9/17/06, Janne Junnila <janne.junnila at gmail.com> wrote:
> On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> >
> > Ah, but that is what the conf.startup_triggers are for. Each entry in
> > there will be executed once the environment is completely set up.
>
> Oh oh... didn't know about them... I'm sorry for wasting your time.
> I guess the triggers are a cleaner and better way.

I'm sorry the documentation wasn't more explicit.  I've added a small
section at the bottom of the programming page, to begin talking about
such advanced topics.

http://jrandomhacker.info/Muby/programming#Modifying_muby_with_user-scripting

If you ever do implement changes to muby's functionality in
user-scripting, please let me know.. I'd be curious to (try to)
document some of it.

From janne.junnila at gmail.com  Mon Sep 18 00:23:11 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Mon, 18 Sep 2006 07:23:11 +0300
Subject: [Muby-talk] Triggers
In-Reply-To: <20060917195302.GC14948@troja.ath.cx>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<20060917195302.GC14948@troja.ath.cx>
Message-ID: <770a6dc40609172123u2188b9ckd3bc698e55f4360f@mail.gmail.com>

Ok, let me try to explain the design I've in my mind more in depth.

In the current muby implementation we have:
 - startup_triggers
 - shutdown_triggers
 - remote_triggers
 - remote_character_triggers
 - local_triggers

This is so far so good, but some programmers would like to have also:
 - text_from_mud_triggers
 - text_from_keyboard_triggers

The programmer should be given a chance to either include ANSI color
codes or drop
them. Two possible solutions would be a parameter when adding triggers
or a filter_ansi
-method. (I think the second one would make more sense.)

This would allow us to make mudy more modular. We could make the trigger system
work on these two new triggers, same with logging and windows. (If it
isn't too hard to
implement it, which I think it's not) Also speaking of performance a
regexp match isn't always needed. Often a plain str=="Blah" will do.

It would offer the programmer the greatest possible control over the
client, where the
trigger system implemented on it would still allow simple regexp
matches and actions.

We could also give triggers priorities. Those would indicate in which
order they are to
be run. It would also be possible to let triggers ran in the previous
stage to modify the arguments of the next one. Features in this
paragraph aren't mandatory, though.

- Janne

On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
>
> Well, I say like I usually do to Sy: Implement it in your scripting,
> and if you think you have arrived at a simple and powerful solution,
> send it to the list and we can talk about it.
>
> One simple way is to just implement the register_mud_input_hook method
> using a remote_trigger on /^(.*)$/ and use that for running your code
> on all incoming lines.
>
> Or if you really want to, try to implement it in the muby core, and
> send the patch here, but then you really have to make it clean,
> generic and in the spirit of the existing code.
>
> //Martin

From zond at troja.ath.cx  Mon Sep 18 03:42:39 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Mon, 18 Sep 2006 09:42:39 +0200
Subject: [Muby-talk] Triggers
In-Reply-To: <770a6dc40609172123u2188b9ckd3bc698e55f4360f@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<20060917195302.GC14948@troja.ath.cx>
	<770a6dc40609172123u2188b9ckd3bc698e55f4360f@mail.gmail.com>
Message-ID: <20060918074239.GA17988@troja.ath.cx>

On Mon, Sep 18, 2006 at 07:23:11AM +0300, Janne Junnila wrote:
> Ok, let me try to explain the design I've in my mind more in depth.
> 
> In the current muby implementation we have:
>  - startup_triggers
>  - shutdown_triggers
>  - remote_triggers
>  - remote_character_triggers
>  - local_triggers
> 
> This is so far so good, but some programmers would like to have also:
>  - text_from_mud_triggers
>  - text_from_keyboard_triggers

text_from_mud_triggers sounds like remote_triggers, and
text_from_keyboard_triggers sounds like local_triggers. What is the
difference?

> The programmer should be given a chance to either include ANSI color
> codes or drop
> them. Two possible solutions would be a parameter when adding triggers
> or a filter_ansi
> -method. (I think the second one would make more sense.)

I've been thinking about this, so far however nobody has reported a
real need for it. And it would not be trivial to add in a sensible way.

> This would allow us to make mudy more modular. We could make the trigger system
> work on these two new triggers, same with logging and windows. (If it
> isn't too hard to
> implement it, which I think it's not) Also speaking of performance a
> regexp match isn't always needed. Often a plain str=="Blah" will do.

What do you mean make the trigger system work on them? And what do you
mean logging and windows?

A regexp without wildcards is as quick as a string equality. Also,
ruby regexp matching is implemented in c, so speed is certainly not a
problem under any kind of normal circumstances.

> It would offer the programmer the greatest possible control over the
> client, where the
> trigger system implemented on it would still allow simple regexp
> matches and actions.
> 
> We could also give triggers priorities. Those would indicate in which
> order they are to
> be run. It would also be possible to let triggers ran in the previous
> stage to modify the arguments of the next one. Features in this
> paragraph aren't mandatory, though.

Priorities could be interesting, but give me an example where it is
actually needed?

//Martin

> - Janne
> 
> On 9/17/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> >
> > Well, I say like I usually do to Sy: Implement it in your scripting,
> > and if you think you have arrived at a simple and powerful solution,
> > send it to the list and we can talk about it.
> >
> > One simple way is to just implement the register_mud_input_hook method
> > using a remote_trigger on /^(.*)$/ and use that for running your code
> > on all incoming lines.
> >
> > Or if you really want to, try to implement it in the muby core, and
> > send the patch here, but then you really have to make it clean,
> > generic and in the spirit of the existing code.
> >
> > //Martin
> _______________________________________________
> muby-talk mailing list
> muby-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/muby-talk
> http://rubyforge.org/projects/muby/

-- 
###################################################################
"The stronger the supernatural beliefs, the worse the inhumanity"
                  [James A. Haught]
###################################################################

From janne.junnila at gmail.com  Mon Sep 18 08:19:21 2006
From: janne.junnila at gmail.com (Janne Junnila)
Date: Mon, 18 Sep 2006 15:19:21 +0300
Subject: [Muby-talk] Triggers
In-Reply-To: <20060918074239.GA17988@troja.ath.cx>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<20060917195302.GC14948@troja.ath.cx>
	<770a6dc40609172123u2188b9ckd3bc698e55f4360f@mail.gmail.com>
	<20060918074239.GA17988@troja.ath.cx>
Message-ID: <770a6dc40609180519t7dfed725tfa942ca13f02d895@mail.gmail.com>

On 9/18/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> On Mon, Sep 18, 2006 at 07:23:11AM +0300, Janne Junnila wrote:
> > Ok, let me try to explain the design I've in my mind more in depth.
> >
> > In the current muby implementation we have:
> >  - startup_triggers
> >  - shutdown_triggers
> >  - remote_triggers
> >  - remote_character_triggers
> >  - local_triggers
> >
> > This is so far so good, but some programmers would like to have also:
> >  - text_from_mud_triggers
> >  - text_from_keyboard_triggers
>
> text_from_mud_triggers sounds like remote_triggers, and
> text_from_keyboard_triggers sounds like local_triggers. What is the
> difference?

The difference is there's no matching so only Procs to be called are
added to these arrays (useful for own logging scripts for example but
I can think of many other cases as well). The problem with current
trigger system is if I add a trigger and give it a function I can't
reuse the same pattern. This makes it hard to write modular code.

> > The programmer should be given a chance to either include ANSI color
> > codes or drop
> > them. Two possible solutions would be a parameter when adding triggers
> > or a filter_ansi
> > -method. (I think the second one would make more sense.)
>
> I've been thinking about this, so far however nobody has reported a
> real need for it. And it would not be trivial to add in a sensible way.

I don't know what's the current approach (ANSI or not) but giving /
filtering ANSI can be useful... (For example the own special
logger)...

> > This would allow us to make mudy more modular. We could make the trigger system
> > work on these two new triggers, same with logging and windows. (If it
> > isn't too hard to
> > implement it, which I think it's not) Also speaking of performance a
> > regexp match isn't always needed. Often a plain str=="Blah" will do.
>
> What do you mean make the trigger system work on them? And what do you
> mean logging and windows?

Logging is writing a log (by using your own special scripted logger)
:P Windows I mean the UI.

> A regexp without wildcards is as quick as a string equality. Also,
> ruby regexp matching is implemented in c, so speed is certainly not a
> problem under any kind of normal circumstances.

This surely might be true, but I still have the prettiness factor to
consider. Writing str=="Blah" is cleaner than writing
str.match(/^Blah$/) IMO.

> > It would offer the programmer the greatest possible control over the
> > client, where the
> > trigger system implemented on it would still allow simple regexp
> > matches and actions.
> >
> > We could also give triggers priorities. Those would indicate in which
> > order they are to
> > be run. It would also be possible to let triggers ran in the previous
> > stage to modify the arguments of the next one. Features in this
> > paragraph aren't mandatory, though.
>
> Priorities could be interesting, but give me an example where it is
> actually needed?
>

Priorities could be used if there was a trigger stack where the
previous trigger could modify the input of the next one. One example
popping into my mind is filtering bad words out but still leaving
"tells you" for the next script to highlight.

- Janne

From zond at troja.ath.cx  Mon Sep 18 09:23:32 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Mon, 18 Sep 2006 15:23:32 +0200
Subject: [Muby-talk] Triggers
In-Reply-To: <770a6dc40609180519t7dfed725tfa942ca13f02d895@mail.gmail.com>
References: <770a6dc40609171126w47a25196pbe9dec43cd7aeea5@mail.gmail.com>
	<20060917195302.GC14948@troja.ath.cx>
	<770a6dc40609172123u2188b9ckd3bc698e55f4360f@mail.gmail.com>
	<20060918074239.GA17988@troja.ath.cx>
	<770a6dc40609180519t7dfed725tfa942ca13f02d895@mail.gmail.com>
Message-ID: <20060918132332.GA19328@troja.ath.cx>

On Mon, Sep 18, 2006 at 03:19:21PM +0300, Janne Junnila wrote:
> On 9/18/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
[snip]
> > text_from_mud_triggers sounds like remote_triggers, and
> > text_from_keyboard_triggers sounds like local_triggers. What is the
> > difference?
> 
> The difference is there's no matching so only Procs to be called are
> added to these arrays (useful for own logging scripts for example but
> I can think of many other cases as well). The problem with current
> trigger system is if I add a trigger and give it a function I can't
> reuse the same pattern. This makes it hard to write modular code.

That doesnt need to be in the core, surely. Try this out:

$TEXT_FROM_MUD_TRIGGERS << Proc.new do |inwin, outwin, line|
	inwin.print("i got the line #{line}")
end
$TEXT_FROM_MUD_TRIGGERS << Proc.new do |inwin, outwin, line|
	inwin.print("i also got the line #{line}")
end

conf.remote_triggers[//] = Proc.new do |inwin, outwin, match|
	$TEXT_FROM_MUD_TRIGGERS.each do |trigger|
		trigger.call(inwin, outwin, match[0])
	end
end

[snip]
> > I've been thinking about this, so far however nobody has reported a
> > real need for it. And it would not be trivial to add in a sensible way.
> 
> I don't know what's the current approach (ANSI or not) but giving /
> filtering ANSI can be useful... (For example the own special
> logger)...

Right now ANSI is filtered out of trigger matching. But as I said, its
not trivial to find out how to do this.

One idea I have is to somehow tell the trigger expression what color
certain parts of it should have to match, another is to simply match
the ANSI escape sequences inside the regexp. Both are a bit horrid in
my opinion. Do you have any idea?

[snip]
> > What do you mean make the trigger system work on them? And what do you
> > mean logging and windows?
> 
> Logging is writing a log (by using your own special scripted logger)
> :P Windows I mean the UI.

I still dont understand what you mean by "make the trigger system work
on them", or what you mean by letting the logging and windows work
with them?

Adding a more generic logging seems like a good idea however.

> > A regexp without wildcards is as quick as a string equality. Also,
> > ruby regexp matching is implemented in c, so speed is certainly not a
> > problem under any kind of normal circumstances.
> 
> This surely might be true, but I still have the prettiness factor to
> consider. Writing str=="Blah" is cleaner than writing
> str.match(/^Blah$/) IMO.

You can always write

str =~ /Blah/

[snip]
> > Priorities could be interesting, but give me an example where it is
> > actually needed?
> >
> 
> Priorities could be used if there was a trigger stack where the
> previous trigger could modify the input of the next one. One example
> popping into my mind is filtering bad words out but still leaving
> "tells you" for the next script to highlight.

Well, we have substitutions and gags that solve a lot of these
problems.

And I dont find that example important enough to implement new
features from :)

//Martin

-- 
###################################################################
"The stronger the supernatural beliefs, the worse the inhumanity"
                  [James A. Haught]
###################################################################

From sy1234 at gmail.com  Sat Sep 23 14:42:16 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 23 Sep 2006 13:42:16 -0500
Subject: [Muby-talk] catching errors in threads
Message-ID: <1e55af990609231142j4b897d7cv5aeb475142e3fcfe@mail.gmail.com>

def test
  Thread.new do
    write "this works"
    write "#{error}"
    write "this never appears"
  end
end

When using this, the error is never seen.  The method just silently dies.

Is there any way to adjust this feature so that I can see the error by default?

From zond at troja.ath.cx  Sat Sep 23 20:11:51 2006
From: zond at troja.ath.cx (Martin Kihlgren)
Date: Sun, 24 Sep 2006 02:11:51 +0200
Subject: [Muby-talk] catching errors in threads
In-Reply-To: <1e55af990609231142j4b897d7cv5aeb475142e3fcfe@mail.gmail.com>
References: <1e55af990609231142j4b897d7cv5aeb475142e3fcfe@mail.gmail.com>
Message-ID: <20060924001151.GA18309@troja.ath.cx>

On Sat, Sep 23, 2006 at 01:42:16PM -0500, Sy Ali wrote:
> def test
>   Thread.new do
>     write "this works"
>     write "#{error}"
>     write "this never appears"
>   end
> end
> 
> When using this, the error is never seen.  The method just silently dies.
> 
> Is there any way to adjust this feature so that I can see the error by default?

A thread will silently die if an exception occurs, unless one of two
things is true:

 * you have set Thread.abort_on_exception = true in which case the
   entire app will die when a thread gets an exception.

 * you wrap the exception in a begin ... rescue ... end block and
   handle it

I would guess that the error printout creates an exception, and
therefore your thread dies silently.

//Martin

-- 
###################################################################
A few hours grace before the madness begins again.
###################################################################

From sy1234 at gmail.com  Sat Sep 23 23:50:54 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 23 Sep 2006 22:50:54 -0500
Subject: [Muby-talk] catching errors in threads
In-Reply-To: <20060924001151.GA18309@troja.ath.cx>
References: <1e55af990609231142j4b897d7cv5aeb475142e3fcfe@mail.gmail.com>
	<20060924001151.GA18309@troja.ath.cx>
Message-ID: <1e55af990609232050j522b3e6q87abe92d026a1d8f@mail.gmail.com>

On 9/23/06, Martin Kihlgren <zond at troja.ath.cx> wrote:
> A thread will silently die if an exception occurs, unless one of two
> things is true:

Aal, good ideas.. I didn't think to catch errors.  It took me a bit of
troubleshooting to figure out what was going on.

Maybe when I experiment with a new thread, I should put in some
troubleshooting code to help me out in these cases..

From sy1234 at gmail.com  Sat Sep 30 19:06:31 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 30 Sep 2006 19:06:31 -0400
Subject: [Muby-talk] mub 0.6.3 has been released
Message-ID: <1e55af990609301606v3e0ae1a4s42dd2759b3226a34@mail.gmail.com>

This is a simple maintenance release.

== Resolved ==

* Thanks to Janne Junnila, a memory leak was found and fixed.

== Aardwolf ==

* There were very significant changes to the aardwolf contrib directory.


http://jrandomhacker.info/Muby
http://rubyforge.org/projects/muby/
http://rubyforge.org/frs/shownotes.php?release_id=7172

From sy1234 at gmail.com  Sat Sep 30 19:10:53 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 30 Sep 2006 19:10:53 -0400
Subject: [Muby-talk] Multi-line status/message lines
Message-ID: <1e55af990609301610t69f36e32g19f42481298d61c2@mail.gmail.com>

Is it possible to have a multiple-line status or message line?

From sy1234 at gmail.com  Sat Sep 30 20:12:50 2006
From: sy1234 at gmail.com (Sy Ali)
Date: Sat, 30 Sep 2006 20:12:50 -0400
Subject: [Muby-talk] tip: weird hotkeys
Message-ID: <1e55af990609301712q23dd2bb9o233f54f116a3e6eb@mail.gmail.com>

Challenged by setting both a HOME and END hotkey, I created a bit of
documentation to demonstrate how to set up different hotkeys which
rely on similar key combinations.

http://jrandomhacker.info/Muby/programming/hotkeys