Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Jeamland 1.4 (RC16) released

0 views
Skip to first unread message

Andy Fiddaman

unread,
Apr 20, 2003, 1:17:18 PM4/20/03
to
I've just posted the latest release candidate for JeamLand 1.4.

I think this is pretty much ready for release as 1.4, but I'd appreciate it
if people could download it and check that it compiles ok on their setup and
any feedback is very much appreciated to
bugs(at)jeamland.org

For those of you who don't know, JeamLand is a talker system in the same
vein as EW2 and NUTSv3 and like NUTS was written from scratch. It has been
in development since 1993 (although there were a few years when not much was
done!)

The source code can be downloaded by FTP at:

ftp://ftp.jeamland.org/jeamland/1.4/jeamland.1.4.0rc16.tar.bz2
ftp://ftp.jeamland.org/jeamland/1.4/jeamland.1.4.0rc16.tar.gz
ftp://ftp.jeamland.org/jeamland/1.4/jeamland.1.4.0rc16.tar.Z

or over HTTP at:

http://www.jeamland.org/files/jeamland.1.4.0rc16.tar.bz2
http://www.jeamland.org/files/jeamland.1.4.0rc16.tar.gz
http://www.jeamland.org/files/jeamland.1.4.0rc16.tar.Z

Thanks,

Andy

Boltar

unread,
Apr 22, 2003, 11:19:16 AM4/22/03
to
"Andy Fiddaman" <ne...@fiddaman.net> wrote in message news:<105085818...@iris.uk.clara.net>...

> I think this is pretty much ready for release as 1.4, but I'd appreciate it
> if people could download it and check that it compiles ok on their setup and
> any feedback is very much appreciated to
> bugs(at)jeamland.org

Couple of things spring to mind. One is you shouldn't make gcc the
default compiler on Solaris as 99% of solaris setups don't have it.
They either have
the Sun Workshop compiler or the Forte compiler both of which are
called using
"cc" and use different optimisation flags.

Anyway , switched GCCBASE to CCBASE in the make file , compiled and
ran it
under both compilers and it seemed fine. Didn't do any major tests
though.

The other thing is , umm , isnt 5 megs minimum rather a lot for just a
talker?? :) I've seen fully fledged muds that used less space.

B2003

Boltar

unread,
Apr 22, 2003, 11:31:49 AM4/22/03
to
Ok , something a teensy bit more serious happened. It tried to connect
to
a router , hung for 5 minutes (the log times are incorrect , it hung
at the
"Connecting to 198..." for 5 mins before printing the next log
message)
where nothing worked then things all went a bit wibbly wobbly. It
couldn't
connect to the router cos we're behind a firewall btw. Heres the log
cut-n-paste:

:
:
:
* You may now log in as 'root' with no password *
*************************************************

Running Jeamland Talker v.1.4.0rc16 (20/04/2003)
(c) Andy Fiddaman 1993-2003.
Enter your name: inetd_host: Tue Apr 22 16:20:08 2003: New host
Hell: 147.201.65.113 4241
secure/whois: Tue Apr 22 16:20:14 2003: -> 127.0.0.1
secure/connect: Tue Apr 22 16:20:14 2003: 127.0.0.1 (Searching)
secure/connect: Tue Apr 22 16:20:27 2003: 127.0.0.1 (Searching)
new_user: Tue Apr 22 16:20:34 2003: Root (from localhost)
enter: Tue Apr 22 16:20:49 2003: Root (6) from localhost.
secure/enter: Tue Apr 22 16:20:49 2003: Root (6) from
unknown@localhost.
syslog: Tue Apr 22 16:21:07 2003: I3: Contacting router *gjs.
syslog: Tue Apr 22 16:21:07 2003: I3: Connecting to
198.144.203.194:9000
perror: Tue Apr 22 16:21:07 2003: connect_tcpsock connect: Transport
endpoint is not connected
perror: Tue Apr 22 16:21:07 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:21:07 2003: write_to_socket: Broken pipe
tcp: Tue Apr 22 16:21:07 2003: Error writing to Root: %(16:21)
error: Tue Apr 22 16:21:07 2003: disconnect_user double call
perror: Tue Apr 22 16:21:07 2003: write_to_socket: Broken pipe
tcp: Tue Apr 22 16:21:07 2003: Error writing to Root: %(16:21)
syslog: Tue Apr 22 16:21:07 2003: I3: Connection failed.
syslog: Tue Apr 22 16:21:07 2003: I3: No router found.
secure/last: Tue Apr 22 16:24:47 2003: 16:20-16:24 (00:04)
Root@localhost
secure/connect: Tue Apr 22 16:24:47 2003: localhost
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
secure/connect: Tue Apr 22 16:24:47 2003: localhost
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
secure/connect: Tue Apr 22 16:24:47 2003: localhost
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_tcpsock, write(): Broken pipe
perror: Tue Apr 22 16:24:47 2003: write_to_socket: Broken pipe

Login timed out after 120 seconds.
syslog: Tue Apr 22 16:24:48 2003: I3: Contacting router *gjs.
syslog: Tue Apr 22 16:24:48 2003: I3: Connecting to
198.144.203.194:9000
^Csyslog: Tue Apr 22 16:24:48 2003: JLM erqd (4692) died from signal 2
[Interrupt].

Andy Fiddaman

unread,
Apr 23, 2003, 6:27:46 AM4/23/03
to
> Couple of things spring to mind. One is you shouldn't make gcc the
> default compiler on Solaris as 99% of solaris setups don't have it.
> They either have the Sun Workshop compiler or the Forte compiler both of
which are
> called using "cc" and use different optimisation flags.

I suppose it depends on where you've come across Solaris systems.. nearly
all of the ones I've seen have gcc rather than either of the other two! Sun
even supply gcc on the software supplement CD now (although that version
can't produce 64-bit binaries...) My main development platform is Solaris 9
with 64-bit gcc - it's amazing the number of applications that don't like
being in a 64-bit environment (I test compiled NUTS 4 btw and it seemed to
work fine with that setup)

There is a make option 'solcc' which is solaris with cc.. I'll change
solaris to solgcc then and make 'solaris' print a help message which should
keep everyone happy! :-)

> Ok , something a teensy bit more serious happened. It tried to connect
> to
> a router , hung for 5 minutes (the log times are incorrect , it hung
> at the
> "Connecting to 198..." for 5 mins before printing the next log
> message)
> where nothing worked then things all went a bit wibbly wobbly. It
> couldn't
> connect to the router cos we're behind a firewall btw. Heres the log
> cut-n-paste:

Ok, it shouldn't throw quite such a wobbler so I'll look at it. You can boot
with the -3 flag which doesn't start the Intermud-3 stuff. As JL doesn't use
threads (yet) this connect() is unfortunately in the main thread although
it's the only thing that is that can hang the talker, everything else is
implemented as a JLM.

> The other thing is , umm , isnt 5 megs minimum rather a lot for just a
> talker?? :) I've seen fully fledged muds that used less space.

*pah* ! ;-)
JL needs around 8Mb for compilation (not including the jlm libraries which
aren't essential), but once stripped and the object files are removed (make
aclean) it only needs 2.5Mb to run.
It is possible to compile in 5Mb by compressing the lib during the
compilation but it's not exactly fun!

Thanks for trying it out,

Andy


Boltar

unread,
Apr 23, 2003, 9:55:41 AM4/23/03
to
"Andy Fiddaman" <ne...@fiddaman.net> wrote in message news:<105109280...@dyke.uk.clara.net>...

> I suppose it depends on where you've come across Solaris systems.. nearly

Probably true. I've worked for financial institutions and financial software
houses for years now and theres about as much chance of them using open source
stuff is their is of them giving Nick Leesom a job in the accounts dept. :)

> being in a 64-bit environment (I test compiled NUTS 4 btw and it seemed to
> work fine with that setup)

Cheers.

>
> There is a make option 'solcc' which is solaris with cc.. I'll change

Oops , didn't spot that.

> Ok, it shouldn't throw quite such a wobbler so I'll look at it. You can boot
> with the -3 flag which doesn't start the Intermud-3 stuff. As JL doesn't use
> threads (yet) this connect() is unfortunately in the main thread although
> it's the only thing that is that can hang the talker, everything else is
> implemented as a JLM.

Ugh , don't talk to me about threads. They were the worst part about doing
NUTS4 and the things that caused 99% of the "what the f*ck is going wrong??"
type bugs. You have linux with its 1 thread = 1 process model which means
all signals go to all threads , solaris with its "lets try and run the new
child thread to completion before we've even returned from the
pthread_create() call or set the child thread id variable in the parent thread"
and FreeBSD with its "quirky" thread-id-is-a-memory-address approach.
Argh!

I'll play around with jeamland a bit more in the future. I've got to ask
though , release candidate *sixteen* ??!! I'd have just said sod it and
released it by now. Thats what patch numbers are for :)

B2003

Athanasius

unread,
Apr 23, 2003, 11:33:03 AM4/23/03
to
-----BEGIN PGP SIGNED MESSAGE-----

In article <105109280...@dyke.uk.clara.net>, on Wed, 23 Apr 2003 11:27:46 +0100,


Andy Fiddaman<ne...@fiddaman.net> wrote:
>There is a make option 'solcc' which is solaris with cc.. I'll change
>solaris to solgcc then and make 'solaris' print a help message which should
>keep everyone happy! :-)

Bah, I'd just leave it as is personally.

>> Ok , something a teensy bit more serious happened. It tried to connect
>> to
>> a router , hung for 5 minutes (the log times are incorrect , it hung
>> at the
>> "Connecting to 198..." for 5 mins before printing the next log
>> message)
>> where nothing worked then things all went a bit wibbly wobbly. It
>> couldn't
>> connect to the router cos we're behind a firewall btw. Heres the log
>> cut-n-paste:
>
>Ok, it shouldn't throw quite such a wobbler so I'll look at it. You can boot
>with the -3 flag which doesn't start the Intermud-3 stuff. As JL doesn't use
>threads (yet) this connect() is unfortunately in the main thread although
>it's the only thing that is that can hang the talker, everything else is
>implemented as a JLM.

How about just using a non-blocking socket for the connect() ? Then
all you do is check it for write()ability in a select() call, which I'm
assuming you have one of for all the client connections anyway. If
you're using poll(2) instead, then the same still applies, just slightly
different code to detect when the socket has actually connect()'d. Prod me
here or in email if you need any more pointers on how to do this.

- -Ath

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPqayLtV9lW5ORr7VAQHg+gP/Qz1GWagamKxyINRXSsKqlscmwEyWjUaN
FTsmYWX7HW8fJF5xg1i5+ZBGJFfuHG7/5K/BE/NR92KMrL8RMuyPCf5qO/tF83XE
DngC59EtDGFI1+ku7BTMDfuPKFgwsh2ufH54Xz9XFU9i1k4KHL2rMpKcbedy2q/F
+4cAzIbONCY=
=VyZR
-----END PGP SIGNATURE-----
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

Boltar

unread,
Apr 24, 2003, 4:27:56 AM4/24/03
to
25$42$rbr...@miggy.org (Athanasius) wrote in message news:<b86bnf$hak$1...@bowl.fysh.org>...

> How about just using a non-blocking socket for the connect() ? Then
> all you do is check it for write()ability in a select() call, which I'm
> assuming you have one of for all the client connections anyway. If
> you're using poll(2) instead, then the same still applies, just slightly
> different code to detect when the socket has actually connect()'d. Prod me
> here or in email if you need any more pointers on how to do this.

I'm a bit foggy on that method myself (i've seen code that used it but never
used it in my own) but I vaguely remember there being an issue with finding
out if and why a connect has failed.

B2003

Andy Fiddaman

unread,
Apr 24, 2003, 11:35:44 AM4/24/03
to
"Athanasius" <25$42$rbr...@miggy.org> wrote in message
news:b86bnf$hak$1...@bowl.fysh.org...

> How about just using a non-blocking socket for the connect() ? Then
> all you do is check it for write()ability in a select() call, which I'm
> assuming you have one of for all the client connections anyway. If
> you're using poll(2) instead, then the same still applies, just slightly
> different code to detect when the socket has actually connect()'d. Prod me
> here or in email if you need any more pointers on how to do this.

Yeah, that's what I've done now and it seems to work ok. The tcpsock stuff
already handled output buffering so it was a pretty easy change - I have no
idea
why I didn't write it that way originally, but it's a while back now!

A.


Athanasius

unread,
Apr 24, 2003, 12:39:46 PM4/24/03
to
-----BEGIN PGP SIGNED MESSAGE-----

In article <71f9a8b1.03042...@posting.google.com>, on 24 Apr 2003 01:27:56 -0700,

You can definitely tell if a connect() fails this way. It *may* still
return immediately with appropriate error, depending on implementation.
If it doesn't then you're looking at using the exceptfds FDSET to detect
errors in a select(2) implementation, or a POLLERR if using poll(2).

How much distinction do you need? From connect(2) you can at most
get one of: ECONNREFUSED, ETIMEDOUT, ENETUNREACH. I'm ignoring errors
here that mean something wrong locally, as you'd still get those anyway
with a non-blocking socket.
Sure, if you 100% need to know the precise, as far as connect(2) can
tell you, reason for the failure, you may need to go multi-threaded and
use a blocking connect(2) call.

- -Ath

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPqgTUNV9lW5ORr7VAQFG+gP9FSCpfilCT9/1ktLgqJgert9Y/rq02b5a
IPGWJZxPI2mXP7yM3rW4IeD7jE3/oN096Buul3eIOIXSViFGNK06r6WqMepA/Eef
NW/rPQ41C8CMs6fyEALFLhvLOIEclr+TTp8eFC54AwMVBAPQdoeDoZ7iffQHXTg2
cMishNKab4E=
=HF5K

Andy Fiddaman

unread,
Apr 24, 2003, 1:05:08 PM4/24/03
to
> I'm a bit foggy on that method myself (i've seen code that used it but
never
> used it in my own) but I vaguely remember there being an issue with
finding
> out if and why a connect has failed.

Three things can happen (AFAIK!) with a non-blocking connect().

- connect() returns 0 (success) - if the connection is immediately
successful (I think to loopback is the only way this happens)
- connect() returns -1 and errno is EINPROGRESS - the normal response!
- connect() returns -1 and some other error.

When the connection succeeds, the socket will select() as writable and off
you go.
If the connection fails, I the socket selects as both readable and writable
and either a read or a write returns the error code from connect().. such as
ETIMEDOUT.

I just modified my connect_tcpsock() function to use a non-blocking connect
and only had to make a couple of minor tweaks to the other methods since
they use select() and buffer data on blocked sockets in any case. If you're
doing error checking on your sockets anyway, you're most likely doing 99% of
what you need - you just need to add some logic to detect the connect()
failure if you're bothered, or just let the read()/write() detect the error
and assume the connection was closed unexpectedly.

A.


bolta...@yahoo.co.uk

unread,
Apr 24, 2003, 4:44:23 PM4/24/03
to
25$42$rbr...@miggy.org (Athanasius) wrote:
>You can definitely tell if a connect() fails this way. It *may* still
>return immediately with appropriate error, depending on implementation.
>If it doesn't then you're looking at using the exceptfds FDSET to detect
>errors in a select(2) implementation, or a POLLERR if using poll(2).

I had an RTFM moment tonight and found this in the linux man page for
connect:

EINPROGRESS
The socket is non-blocking and the connection can-
not be completed immediately. It is possible to
select(2) or poll(2) for completion by selecting
the socket for writing. After select indicates
writability, use getsockopt(2) to read the SO_ERROR
option at level SOL_SOCKET to determine whether
connect completed successfully (SO_ERROR is zero)
or unsuccessfully (SO_ERROR is one of the usual
error codes listed here, explaining the reason for
the failure).

Seems useful.

B2003

Boltar

unread,
Apr 29, 2003, 6:13:58 AM4/29/03
to
"Andy Fiddaman" <ne...@fiddaman.net> wrote in message news:<105085818...@iris.uk.clara.net>...

> any feedback is very much appreciated to
> bugs(at)jeamland.org

Another minor bug. If it can't find its config file when it boots
it errors then crashes with a segmentation fault (on Solaris).
Not a big deal but it looks ugly.

B2003

Andy Fiddaman

unread,
Apr 29, 2003, 8:07:18 AM4/29/03
to
"Boltar" <bolta...@yahoo.co.uk> wrote in message
news:71f9a8b1.03042...@posting.google.com...

Thanks - I'll fix that.
It would still generate core dump with IOT because my fatal() function
deliberately calls abort() to generate a core dump... I suppose I should
turn that off in the release version though as it doesn't look too good ;)


0 new messages