dirt-client-devel Mailing List for dirt-client

You have been added.  Welcome!  I'm glad to see interest.  I still use
the client from time to time, but do not really mud anymore.  I think
I wrote some quite amazing (IMHO) code for triggers and aliases, and I'd
like to not have it die... ;)

If I recall, the most serious problem I wanted to fix is the screen
handling, which is simply arcane.

Please let me know if there's any way I can help.

Attached is a diff of CVS and my local codebase.  I've been using it
as-is for years, and I think checking these changes in won't be a
problem.

Kieran Farrell [kie...@gm...] wrote:
> I know this project seems dead, But I would like to revive it.
> 
> Could you add me as a developer please.

Kieran Farrell [kie...@gm...] wrote:
> Oh, my sf username is kjfarrell

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "One of the best ways to get yourself a reputation as a dangerous citizen
    these days is to go about repeating the very phrases which our founding
    fathers used in the great struggle for independence." --Charles A. Beard

Oh, my sf username is kjfarrell
--=20
Kieran Farrell
ICT Administrator=20
Christies Beach and Noarlunga Downs Primary Schools
PH: (08) 8382 1511
PH: (08) 8384 4395
MB: 0422 848 772

"We have enough youth, how about a fountain of SMART?"

I know this project seems dead, But I would like to revive it.

Could you add me as a developer please.


--=20
Kieran Farrell
ICT Administrator=20
Christies Beach and Noarlunga Downs Primary Schools
PH: (08) 8382 1511
PH: (08) 8384 4395
MB: 0422 848 772

"We have enough youth, how about a fountain of SMART?"

CVS just committed with Abigail's new telnet handling code, and updates
for perl 5.8 (dirt now requires 5.8).  Also fixed the segfault on
exiting.

Cheers,
Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]

    "You measure democracy by the freedom it gives its dissidents, not the
    freedom it gives its assimilated conformists." -- Abbie Hoffman

Abigail Brady [mo...@ev...] wrote:
> On Tue, 2002-09-17 at 00:46, Bob McElrath wrote:=20
> > I have checked your code into CVS and will keep IAC IAC in mind during
> > the rewrite...(but will probably discard the goto ;)  I will also be
> > nice and use the defines in arpa/telnet.h.  ;)
>=20
> Cool.  There are a few other things I'd like to see it support (e.g.
> TTYPE, NAWS, xterm-titlebar), but that's the only thing I could find
> that was actively broken.
>=20
> > If you feel like working on this, help would be appreciated.  ;)
>=20
> Alas, I, too, am busy. (writing the mud that wants the above features,
> and an experimental client with no bells or whistles, just really good
> terminal emulation/telnet protocol support. :)

Hey there, sorry it's been so long since I looked at dirt...

Did you realize the telnet code you sent also breaks all mud triggers?
Have you worked on this further?

Trying to fix...

Cheers,
Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]

    "You measure democracy by the freedom it gives its dissidents, not the
    freedom it gives its assimilated conformists." -- Abbie Hoffman

Bryan Richter [btr...@uc...] wrote:
>=20
> Hello, everyone-
>=20
> I just wanted to write to say I'm interested in helping out on this
> project. It doesn't look like there's been much action on this list for a
> while, so I hope people are still working on it..=20
>=20
> I don't have oodles of free time, but if there's anything anyone would li=
ke
> some work on let me know. In the meanwhile, I'll just try to hunt down any
> little bugs I find.
>=20
> I should mention that I only have a couple years experience with C/C++, a=
 2
> week introduction to Python, and all the Perl I know has been learned from
> writing MCL scripts. :) I've been wanting to know some more Python, thoug=
h,
> so maybe I'll get a book on that and try to contribute whatever I learn.
>=20
> I've already experienced a few bugs, but I'm going to make good and sure
> that my environment is set up correctly before I start complaining about
> them (e.g. /help <command> doesn't work, but then, I moved a bunch of
> directories around after `make install'ing).

Well thanks for your interest.  ;)

I'm afraid the CVS is in a sad state.  If I remember correctly it
doesn't even compile.  Any help you can offer would be greatly
appreciated.  I'll try to answer any questions you may have.  Also see
my TODO file for a honking lot of things I want to fix.  :)

I'm finishing my Ph.D. this semester so have been extremely busy.  I
haven't done any mudding in probably a year at least...

Cheers,
Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]

    "You measure democracy by the freedom it gives its dissidents, not the
    freedom it gives its assimilated conformists." -- Abbie Hoffman

Hello, everyone-

I just wanted to write to say I'm interested in helping out on this
project. It doesn't look like there's been much action on this list for a
while, so I hope people are still working on it.. 

I don't have oodles of free time, but if there's anything anyone would like
some work on let me know. In the meanwhile, I'll just try to hunt down any
little bugs I find.

I should mention that I only have a couple years experience with C/C++, a 2
week introduction to Python, and all the Perl I know has been learned from
writing MCL scripts. :) I've been wanting to know some more Python, though,
so maybe I'll get a book on that and try to contribute whatever I learn.

I've already experienced a few bugs, but I'm going to make good and sure
that my environment is set up correctly before I start complaining about
them (e.g. /help <command> doesn't work, but then, I moved a bunch of
directories around after `make install'ing).



-Bryan Richter
btr...@uc...

Abigail Brady [mo...@ev...] wrote:
> Well, here's a first attempt at proper telnet/ansi stacks, using proper
> state machines.
>=20
> In addition to cleaning up the code a lot, it adds support for ESC[22m
> (bold off), ESC[39m (default fg), ESC[49m (default bg), and telnet
> terminal type identification.

Cool!  Thanks!

> I probably lost support for unterminated prompts, but should be easy to
> add back in.

Unfortunately I have a lot of unchecked-in prompt related code in there.
:(

I'll try to merge our changes soon.

If you intend to do more work on dirt, I can add you as a developer on
sourceforge.

Cheers,
-- Bob

Bob McElrath (bob...@mc...)=20
Univ. of Wisconsin at Madison, Department of Physics

    "The purpose of separation of church and state is to keep forever from
    these shores the ceaseless strife that has soaked the soil of Europe in
    blood for centuries." -- James Madison

Sorry, last mail had wrong patch attached.

This one is right.

Well, here's a first attempt at proper telnet/ansi stacks, using proper
state machines.

In addition to cleaning up the code a lot, it adds support for ESC[22m
(bold off), ESC[39m (default fg), ESC[49m (default bg), and telnet
terminal type identification.

I probably lost support for unterminated prompts, but should be easy to
add back in.

-- 
Abi

On Tue, 2002-09-17 at 00:46, Bob McElrath wrote: 
> I have checked your code into CVS and will keep IAC IAC in mind during
> the rewrite...(but will probably discard the goto ;)  I will also be
> nice and use the defines in arpa/telnet.h.  ;)

Cool.  There are a few other things I'd like to see it support (e.g.
TTYPE, NAWS, xterm-titlebar), but that's the only thing I could find
that was actively broken.

> If you feel like working on this, help would be appreciated.  ;)

Alas, I, too, am busy. (writing the mud that wants the above features,
and an experimental client with no bells or whistles, just really good
terminal emulation/telnet protocol support. :)

Abigail Brady [mo...@ev...] wrote:
> The telnet spec says you do 'IAC IAC' to have a literal 0xff.  Dirt (and
> mcl before) doesn't support this.  The patch below fixes this.=20
> Obviously this isn't the most clean way of fixing it, but that code is
> hideously broken anyway and needs a rewrite.  This works as a makeshift.

Ack!  Goto!

Yes this code is hideously broken.  I'm in the midst of a rewrite of
that particular function, with the aim of making prompts work better.
(Lots of complaints about that...)  Unfortunately I'm so...busy...

I have checked your code into CVS and will keep IAC IAC in mind during
the rewrite...(but will probably discard the goto ;)  I will also be
nice and use the defines in arpa/telnet.h.  ;)

If you feel like working on this, help would be appreciated.  ;)

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

The telnet spec says you do 'IAC IAC' to have a literal 0xff.  Dirt (and
mcl before) doesn't support this.  The patch below fixes this. 
Obviously this isn't the most clean way of fixing it, but that code is
hideously broken anyway and needs a rewrite.  This works as a makeshift.

Index: Session.cc
===================================================================
RCS file: /cvsroot/dirt-client/dirt/Session.cc,v
retrieving revision 1.14
diff -u -r1.14 Session.cc
--- Session.cc  4 May 2002 23:36:28 -0000       1.14
+++ Session.cc  16 Sep 2002 22:14:16 -0000
@@ -483,6 +483,9 @@
                     /* Skip the next character if this is an option */
                     else if (input_buffer[i] >= WILL && input_buffer[i]
<= DONT)
                         i++;
+                   else if (input_buffer[i] == IAC) {
+                     goto real;
+                   }
                 }
                 continue;
             }
@@ -496,6 +499,7 @@
                 ::write(STDOUT_FILENO, "\a", 1); // use screen->flash()
here?
             
             else if (code_pos == -1) { // not inside a color code, real
text
+           real:
                 if (input_buffer[i] == '\n')  {
                     int len = out-line_begin;
                     int old_len = len;

Lord_Devi [lor...@co...] wrote:
> > You're running at the linux console?  I get stuff at the linux console.
> > And BTW the '/key kp_8 = n' also works for me at the linux console.
> > 
> > > I tried the snarf and showprompt too btw. with either of them off it completley
> > > doesn't work - like showing any prompts. with them on it works *. I could do
> > > a trigger yeah... but still then character creation in muds is still impossible.
> > > I pretty much have to guess what the mud is asking me by the text prior to the
> > > question. Every last line that's shown to me is hidden for some reason.
> > 
> > It sounds like your mud is sending properly delimited prompts.  Turn
> > snarf_prompt on and it will appear in the blue bar at the bottom.
> > 
> 
> You know.. I just thought that for the hell of it I'd see if it was something
> else... that cat thing made me suspicious - and I know now that it's my keymapping.
> I just need to find out why exactly it seems to think my keypad shouldn't work
> like a keypad. So that problem is tagged as a non-bug issue at least :P Just gotta
> play around with it some more on my end... but that snarf prompt thing
> definatly isn't helping. Perhaps if you wouldn't mind you could have a look
> at the mud I use to see if it works for you?
> 
> materiamagica.com 23

Well it looks like you're going to have to use undelim_prompt since your
mud truly does send undelmited prompts.  All muds should send delmited
prompts.  Maybe complain to your admins and tell them to use either the
TELNET GA/EOR or *^H methods, both of which dirt recognizes.  ;)

It looks like the MCCP v2 implementation in dirt/mcl is hosed.  Though
v1 works fine.  Attached is a small patch that will make dirt use v1
only (disabling v2).

Cheers,
-- Bob

Bob McElrath (rsm...@st...) 
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

Casey [lor...@co...] wrote:
> I am so goddamn pleased that someone has taken up mcl again.
> I love muds and mcl was the best i thought.. but it was
> sooo lagging behind.
>=20
> I do have one small issue so far though, is the keypad.
> One of my favorite features about mcl was how I could macro
> the keypad to directions like north south east and west
> just by pressing 8, 2, 6, 4 and whatnot. Lovely for us really
> lazy people, haha. But I can't seem to find a way to do it.
> I used that /key command and gave it a priority of 5 too
> (using kp_8 for example) and no go. I may as well be using
> arrow keys. I'm not a programer either, otherwise I would
> have just had a shot at the code to remove that binding
> myself - but alas and alak I am not. Is there a way I can
> get my precious keypad bindings back with dirt? Or even
> possibly would you consider removing those bindings in a
> future version as they are kind of redundant anyway, seeing
> as the normal arrow keys do the same thing?
>=20
> Thanx in advance, and totally kick ass :P

Sure: add the below to your .dirt/Saved.pl.  This is generated by /key comm=
ands
(and I am starting to think this is not the best way to store saved
keys/aliases/macros/etc).  Anyway you can also generate these with:
    /key kp_8 =3D n
If this doesn't work then dirt is not properly getting your keypad keys.  T=
ry
toggling numlock on and off.  You can also figure out what keycodes are bei=
ng
generated by just typing 'cat' and then pressing a few keys:

    (1)<mcelrath@draal:/home/mcelrath/mud/dirt> cat
    ^[Ot^[Ou^[Ov^[Ow^[Ox^[Oy^[Oq^[Or^[Os

Unfortunately these keycodes are inherited from mcl and hard-coded in the f=
ile
TTY.cc.  Sometime I would like to replace this with some kind of proper
terminfo interface that can determine the keys from your $term.

Also please make sure you have the most recent CVS version.  It should be v=
ery
stable.  I've fixed many bugs and will make a release soon.

%Keypress::Keypresses =3D (
  'kp_plus' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'u'
  },
  'kp_0' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> '/eval run("kill $ThreeKingdoms::enemy");'
  },
  'kp_1' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'sw'
  },
  'kp_2' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 's'
  },
  'kp_period' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'D' =3D> '',
    'L' =3D> '',
    'action' =3D> 'ga;paip'
  },
  'kp_3' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'se'
  },
  'kp_4' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'w'
  },
  'kp_minus' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'd'
  },
  'kp_5' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'D' =3D> '',
    'L' =3D> '',
    'action' =3D> 'glance;hp'
  },
  'kp_6' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'e'
  },
  'kp_7' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'nw'
  },
  'kp_8' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'n'
  },
  'kp_9' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'L' =3D> '',
    'D' =3D> '',
    'action' =3D> 'ne'
  },
  'kp_divide' =3D> {
    'F' =3D> 0,
    'f' =3D> 0,
    'g' =3D> '',
    'p' =3D> 0,
    'D' =3D> '',
    'L' =3D> '',
    'action' =3D> 'tdf'
  }
);

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

Thomas Jacobsen [tho...@sv...] wrote:
> Thanks alot! - It helped :)
>=20
> I must admit that i am not very familiar with perl, but im more a python
> hacker ;)

You know dirt has a python module?  Configure with --enable-python and
you can use /eval -Lpython, /run -Lpython...

I haven't touched it in a while, the python module probably needs some
work.

> Now we have solved it, so i can toggle if it should eat a plant or not. B=
ut
> before i get the first affliction, i do not get the line "You may eat
> another plant." because that i havn't been eating any.
>=20
> What i was thinking about is to make a variable called $balance, and then=
 do
> something like "Your body stiffens rapidly with paralysis." THEN if $bala=
nce
> is true, then we send the command "outb bloodroot" and "eat bloodroot" +
> that it should change the $balance variable to false. Then we are sure th=
at
> in the next affliction, it doesn't eat a plant before $balance is true
> again. The $balance variable should then become true again in the "You may
> eat another plant."-trigger ;-)

Sounds like a good plan.

> Can you help me to do this ? :)

Awww, you can do it!  ;)

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

Thomas Jacobsen [tho...@sv...] wrote:
> There is also another bug, when i connect to Aetolia.com:23, and enter the
> game, then when I get a room-decription, it makes the white text, the same
> color as(purple) the exits in the description.

It seems that your mud sends the back-to-white color sequence as part of
the prompt.  This is kind of not nice since Dirt attempts to grab the
prompt and put it in the blue bar at the bottom.  As such, any ANSI in
the prompt gets lost.  On Diku's for instance the ANSI prompt just gets
turned to black/white, which isn't really a big deal.  On your mud,
however, the line preceeding the prompt is purple, and the purpleness is
not terminated.

Anyway, you can work around this by setting showprompt=3D1 in your
=2Edirt/dirtrc.

Alternatively, you could do:
    /hook -T PROMPT backtowhite =3D /eval print $off
$off is defined in scripts/sys/color.pl and terminates any leftover
ANSI.  Your mud sends nice properly-terminated prompts, so the PROMPT
hook is properly decoded.  Again, the above hook is good to put in
~/.dirt/Aetolia.pl which will get automatically loaded if you name your
mud Aetolia in .dirt/dirtrc.

Yet another way to do this:
    Mud Aetolia {
      Host aetolia.com 23
      Commands /hook -T PROMPT backtowhite =3D /eval print $off
    }=20
in .dirt/dirtrc

Yet another alternative is to deal with the unterminated ANSI.  The
place to do this is Session.cc:410, in the function
Session::inputReady(), which does the prompt decoding.

Patches happily accepted.  :)
 =20
> But I really like this client, and i hope that i will get it working
> :-)

;)  Thanks for being my guinea pig.

The segfault you discovered has also been fixed in CVS.  The line you
were using had many quotes (") that had to be escaped " -> \" making the
line larger than the buffer I was using!  Anyway, it's fixed.

I also recommend you start putting this in a script.  ;)  That way you
can properly format it, use an editor like vim/emacs that will do perl
syntax highlighting, etc.  Makes writing stuff and debugging a lot
easier.  ;)

Cheers,
-- Bob

> -----Original Message-----
> From: Bob McElrath [mailto:mce...@dr...]
> Sent: den 3 augusti 2002 20:33
> To: ken...@us...
> Subject: Re: [dirt-client - Help] RE: RE: RE: RE: Timer? or?
>=20
>=20
> no...@so... [no...@so...] wrote:
> >=20
> > Read and respond to this message at:=20
> > http://sourceforge.net/forum/message.php?msg_id=3D1637927
> > By: kenzorio
> >=20
> > Ok, i have maked a line, with it all on. But when i try to save the
> trigger
> > i get a Segmentation fault, I also get that, if i paste the line into
> "Saved.pl"
> > - I have checkked the line, and there is nothing wrong with it.
>=20
> Ok well that's a bug.  Send me your Saved.pl, and any command you type
> that generates a segfault.
>=20

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

Some new changes in CVS:

Screen no longer scrolls when in scrollback

Many, many fixes for /hook.  The -f (run embedded-script function) has
been removed in favor of proper implementation for /run and /eval:
    /hook -t'stuff(.*)' mystuff =3D /eval print "I found $1 following stuff=
."
    /hook -t'junk' myjunk =3D /run junkhandler

Priorities should work between C++/perl, and things always run in
priority order (there were many bugs in this).  In addition things get
printed in the right order whether you use report() or /echo or print
from a script.

Last but not least it should compile with gcc 2.96, 3.0 and 3.1.

Here is some sample things to try that (by and large) didn't work
properly before, but now work:

! =3D broken
-- Order of execution perl/C++
/hook -Ft 'shit' -p 1 myshit1 =3D say one
/hook -Ft 'shit' -p 2 myshit2 =3D /eval run("say two")
/hook -Ft 'shit' -p 3 myshit3 =3D say three
    ** Should print 3,2,1

-- Order of printing, perl/C++
/hook -Ft 'shit' -p 1 myshit1 =3D /eval print "found some shit\n"
/hook -Ft 'shit' -p 0 myshit2 =3D /echo found some shit2

-- Deeply nested printings.
/hook -p5 -Ft'shit' myshit5 =3D /echo found some shit (5)
/hook -p4 -Ft'shit' myshit4 =3D /eval run("/echo found some shit (4)")
/hook -p3 -Ft'shit' myshit3 =3D /eval print("found some shit (3)\n")
/hook -p2 -Ft'shit' myshit2 =3D /eval run("/eval run('/echo found some shit=
 (2)')")
/hook -p1 -Ft'shit' myshit1 =3D /eval run("/eval run('/eval run(\\'/echo fo=
und some shit (1)\\')')")
    ** Why are the backslashes required above?

-- Regex groupings
/hook -Ft'shit (.*)' myshit2 =3D /eval print "Found '$1' following shit (2)=
\n"
/hook -Ft'shit (.*)' myshit1 =3D say Found $1 following s-h-i-t (1)

-- Return values of perl functions
/hook -t 'shit' -p4 shitfallthrough4 =3D /eval 0;
/hook -Ft 'shit' -p3 shitfallthrough3 =3D /echo This should print.
/hook -t 'shit' -p2 shitfallthrough2 =3D /eval 1;
/hook -Ft 'shit' -p1 shitfallthrough1 =3D /echo This should not print.

!- Gagging blank lines
/gag -Ft'^\\s*$' blankline

-- Hook deletion
/hook -N MYINIT
/hook -T MYINIT myinit =3D /eval run("/hook -d myinit")
/hook -r MYINIT
    code must not manipulate the hook myinit after it has been deleted.

-- Modifying mud lines
/hook -t 'shit' -p1 shit2 =3D /eval $_ .=3D "& stuff";

-- Perl receiving arguments:
/hook -T COMMAND -C crap crap =3D /eval report("crap got $_\n")
/crap

-- Multi-depth savedmatch'es:
/hook -t'shit' myshit =3D /enable shit
'shit

If you are able to write a series of hooks which don't do what you think
they should do, let me know.

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

I just figured this out:

You can download the nightly CVS tarball here:
    http://cvs.sourceforge.net/cvstarballs/dirt-client-cvsroot.tar.gz

For those behind firewalls and such.

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

HarvCrag [har...@ge...] wrote:
> Bob McElrath wrote:
> > HarvCrag [har...@ge...] wrote:
> >=20
> >>I got the thing compiled before, but when I ran it, I received a=20
> >>Segmentation Fault.  Now I am trying to compile it with g++ 3.1 and so=
=20
> >>far all of the namespaces are different.  I'd like to get it to work=20
> >>though because mcl isn't working very well for me.  mcl's alias=20
> >>interpreter is not good at doing certain aliases and it looks like dirt=
=20
> >>has revised it, but maybe I can do something to mcl until I get dirt to=
=20
> >>work.
> >=20
> >=20
> > I see.  So I installed gcc 3.1 and fixed a few things.  It now compiles,
> > but as you say, doesn't run.  I'm attaching a patch which will make it
> > compile.  I'll try to track down the crash as I have time.
> >=20
> > If you have a chance to run it under a debugger, please let me know your
> > success.  I probably won't have time to look at it for a while.
> >=20
> > The alias interpreter has been totally rewritten.  I'd appreciate input
> > on it.  ;)
> >=20
> > Cheers,
> > -- Bob
> >=20
> > Bob McElrath (rsm...@st...)=20
> > Univ. of Wisconsin at Madison, Department of Physics
> >=20
>=20
> When I put a breakpoint on EmbeddedInterpreter.cc:358, run to that point=
=20
> and print opt.restStr() it tells me I can't access memory.  Can't figure=
=20
> out why I wouldn't be able to print out that variable and it may have to=
=20
> do with the segfault, but I don't know.

The segfault was really simple, but as usual got buried in 8000
libstdc++ templates.  Anyway, cvs should now compile with g++ 3.1 as
well as actually run.

Remember that it is still under development, and not everthing may work
properly.  (But please report any bugs here!)  ;)

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

Bob McElrath wrote:
> HarvCrag [har...@ge...] wrote:
> 
>>I got the thing compiled before, but when I ran it, I received a 
>>Segmentation Fault.  Now I am trying to compile it with g++ 3.1 and so 
>>far all of the namespaces are different.  I'd like to get it to work 
>>though because mcl isn't working very well for me.  mcl's alias 
>>interpreter is not good at doing certain aliases and it looks like dirt 
>>has revised it, but maybe I can do something to mcl until I get dirt to 
>>work.
> 
> 
> I see.  So I installed gcc 3.1 and fixed a few things.  It now compiles,
> but as you say, doesn't run.  I'm attaching a patch which will make it
> compile.  I'll try to track down the crash as I have time.
> 
> If you have a chance to run it under a debugger, please let me know your
> success.  I probably won't have time to look at it for a while.
> 
> The alias interpreter has been totally rewritten.  I'd appreciate input
> on it.  ;)
> 
> Cheers,
> -- Bob
> 
> Bob McElrath (rsm...@st...) 
> Univ. of Wisconsin at Madison, Department of Physics
> 

When I put a breakpoint on EmbeddedInterpreter.cc:358, run to that point 
and print opt.restStr() it tells me I can't access memory.  Can't figure 
out why I wouldn't be able to print out that variable and it may have to 
do with the segfault, but I don't know.

HarvCrag [har...@ge...] wrote:
> I got the thing compiled before, but when I ran it, I received a 
> Segmentation Fault.  Now I am trying to compile it with g++ 3.1 and so 
> far all of the namespaces are different.  I'd like to get it to work 
> though because mcl isn't working very well for me.  mcl's alias 
> interpreter is not good at doing certain aliases and it looks like dirt 
> has revised it, but maybe I can do something to mcl until I get dirt to 
> work.

I see.  So I installed gcc 3.1 and fixed a few things.  It now compiles,
but as you say, doesn't run.  I'm attaching a patch which will make it
compile.  I'll try to track down the crash as I have time.

If you have a chance to run it under a debugger, please let me know your
success.  I probably won't have time to look at it for a while.

The alias interpreter has been totally rewritten.  I'd appreciate input
on it.  ;)

Cheers,
-- Bob

Bob McElrath (rsm...@st...) 
Univ. of Wisconsin at Madison, Department of Physics

I got the thing compiled before, but when I ran it, I received a 
Segmentation Fault.  Now I am trying to compile it with g++ 3.1 and so 
far all of the namespaces are different.  I'd like to get it to work 
though because mcl isn't working very well for me.  mcl's alias 
interpreter is not good at doing certain aliases and it looks like dirt 
has revised it, but maybe I can do something to mcl until I get dirt to 
work.

CVS should be fixed now.

I have changed how hooks behavior slightly, so that in perl when you do
a match:
    /hook -Ft'Joe says: (.*)' joesaid =3D /eval print Joe told me $1
the regex matching variables $1, $2, ... would be available to the /eval
or /run command on the RHS, as true perl vars.  Previously the RHS could
be evaluated in quoted context to insert $1, $2, which caused no end of
confusing escapes (\) to be inserted if you wanted to something other
than trivial.

This new behavior has a somewhat unintended consequence:

    If the RHS modifies the mud string (which used to be allowed),
    nobody will see it.

Previously the RHS could modify the mud string, and all hooks of lower
priority would see the modified string.  However, it was possible to
construct a set of hooks which would fire in a non-obvious order (i.e.
the commands from a lower priority hook getting sent to the mud before
the commands from a higher priority hook -- particularly when SEND hooks
were involved).

There are still some issues of non-determinism and out-of-order
processing that need to be solved.  For instance:
    /hook -Ft 'shit' -p 1 myshit1 =3D say one
    /hook -Ft 'shit' -p 2 myshit2 =3D /eval run("say two")
    /hook -Ft 'shit' -p 3 myshit3 =3D say three
    You say: shit
    You say: three
    You say: one
    You say: two

Anyone want to solve this one?  ;)

Cheers,
-- Bob

Bob McElrath (mce...@bo...)=20

On zondag 5 mei 2002 20:35, Bob wrote:
> No...I was just looking at this again.
>
> That bug occurs with gcc 2.95.4 for me, but not with gcc 3.0.4.

Ok, then I leave it alone. I better put some time in installing gcc 3. :-)

>
> I don't understand why istream is using pthreads in the first place,
> much less what could be causing a mutex lock conflict.

A bug I guess.


> The way I wrote it seems straightforward and obvious...any suggestion?
> I would also like to change this function (and many others) to use
> string objects rather than static buffers.  What caused me to rewrite
> loadHistory in the first place was that I had lines longer than 1024,
> and it was segfaulting.

Yes, I simplified it already:

void HistorySet::loadHistory() {
    if (config->getOption(opt_save_history)) {
        ifstream hin(Sprintf("%s/.dirt/history", getenv("HOME")));

        // untested new code
        int id;
        time_t t;
        std::string buf;
        while(hin >> id >> t >> std::ws)
        {
           getline(hin, buf);
           hist_list[id]->add(buf, t);
        }      
   }
}


But with 2.95 this chokes just like your code. Please try it with 3.04.



-- 
A skilled commander seeks victory from the situation and does not demand it 
of his subordinates.
- Sun Tzu, 500 B.C.