February 1998
- OT: Following in the footsteps of JCL Alex Oren
- OT: Following in the footsteps of JCL Nathan Yospe
- OT: Following in the footsteps of JCL Richard Woolcock
- OT: Following in the footsteps of JCL Chris Gray
- OT: Following in the footsteps of JCL coder@ibm.net
- OT: Following in the footsteps of JCL Marc Eyrignoux
- Ada? Andrew C.M. McClintock
- Monthly FAQ posting Koster, Raph
- Monthly FAQ posting Adam Wiggins
- Monthly FAQ posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Chris Gray
- Monthly FAQ Posting Ling
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting Alex Oren
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting s001gmu@nova.wright.edu
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Koster, Raph
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Marian Griffith
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Ling Lo
- Databases Shawn Halpenny
- OT: This is a test coder@ibm.net
- OT: This is a test Alex Oren
- Clients and things [Was: OT: This is a test] Matt Chatterley
- Clients and things [Was: OT: This is a test] coder@ibm.net
- Clients and things [Was: OT: This is a test] Matt Chatterley
- MUD Development Digest Dr. Cat
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
On Tue, 10 Feb 1998, Greg Munt wrote:
:On Tue, 10 Feb 1998, Nathan Yospe wrote:
:> On Tue, 10 Feb 1998, Greg Munt wrote:
:> :Also, any references to caches?
:> Again, can't help you. I've done caches, but not for my mud... and there
:> is such a broad spectrum of things that qualify as cache. Do you want to
:> know more about cached in-memory storage for a disk-based DB?
:Yes.
The best sources for this would be J C, any of the Cold people, or, if a
member of the DGD development team is still around... was that the LPmud
disk-based project? All I can tell you is, you don't want to be doing it
in the form of frequent access to the disk, so if you can find a way for
the data to reside in memory for a while after any read, and for data to
be held for writing until a significant chunk of contiguous memory is in
the cache, you're better off. Hopefully others can advise better than I.
:> Or bottleneck spot caching?
:What's that?
An element of assembly coding and RISC compiler design. It might also be
significant for VM construction. It has to do with the repeated register
loading of the same data over and over. Essentially means finding where,
when, and how information can be loaded onto the stack/into registers to
minimize the number of loads (This opposed to operational instructions.)
:> :Any references to Event Management? Is there any alternative to using a
:> :pointer to a function, to store the Event->function()? (This has the
:> :disadvantage of every Event->function() needing to have the same number
:> :and type of parameters being passed to it.)
:> Here we go. This I can help you with. Events don't have to be functions,
:> for a start. An event could be stored as anything, from a script on down
:> to a held thread. I store mine as classes... any action is executed from
:> an event class, which grabs the nearest available execution thread, sets
:> it to the event's references, and frees it to go. Events are, by design,
:> only actually capable of grabbing one specific thread, such that any set
:> of events cannot execute asynchronously on the same resources. Functions
:> are actually pulled up _after_ execution begins... Event.Process() is at
:> its basis a normalization check, which tries to match a list of objects,
:> and upon success, changes the values of the objects to a new norm, then,
:> with its still-active thread, allows those objects to update. The object
:> update methods are the actual functions involved, and once each object's
:> updates are complete (and affected objects with zero delay complete such
:> updates as the modified objects have made available) the thread is wiped
:> clear of variables, set to sleep, and returned to the pool.
:I'm not sure I understand this too well. Are you suggesting this?
:class Event
: {
: private:
: DataType1 *a;
: DataType2 *b;
: ...
:
: public:
: ...
: process();
: };
class Event{
SortedList<ObjectReference<BaseObject>, PrioriList<AttributeType,
AttributeValue> > objectList;
TimeValue timeCheck; // for purpose of sanity checks
public:
process(); // set values... for each object in objectList, call
// BaseObject::update();
};
:I still can't see how the event isn't a function. The tasks that the
:event does have to be stored in a function?
Well, yes and no. I operate entirely on the principal of creation, value
modification, full instantiation, partial destantiation, and deletion. I
don't tolerate the sort of procedural functions that most languages use.
:Am I wrong in thinking that the data that an Event needs (eg pointer to a
:Player) are stored in the class, with a function - which takes no
:parameters - calling class methods to do whatever it is that the Event is
:trying to achieve? Also, it looks like Event would need to be a template.
:Forget that, am using Linux g++ :(
I'm using g++ too... so far, the templates haven't bit me. Not Linux, if
that makes a difference, but still. I know that some of the advanced and
esoteric template functionalities, g++ won't work. Nevertheless, there's
no reason I couldn't have done without, aside from my pointer and Lists.
:I feel like I have totally gotten the wrong end of the stick here...
Nah. You'll learn. Give it some time. Use Java for a while, if you want.
It is crippled, but you learn a lot from programming with it. Seriously.
:> This is just
:> one approach to events that doesn't actually require a function pointer,
:> and a good number of others can be found in deja news archives of thread
:> and event related newsgroups.
:Could you lead me in the right direction here? Searches on dejanews
:revealed not very much (read: nothing)...
Can't remember the ngs right now myself, but... I'll take a look Friday.
Got work and school until then, so I'll be a bit too busy. Can you hold?
:> Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
:> Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
:> (Temporarily on Hold) Physics student, University of Hawaii dept of Physics
:> yospe@hawaii.edu nyospe@premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/
:I'll use this opportunity to keep you updated on my work activities: I
:finally got a job, C++/Unix, using such tools as Rational Rose, etc. I'll
:be maintaining and developing planning and scheduling software for the
:steel industry. Will post a FAQ update soon.
Congratulations. Rational Rose, eh? I have misery in my company. I mean,
company in my misery. No the first time was right. We use Rose too. Dang
piece of ill concieved code. Powerful, though. But... how can a tool for
object oriented design be so... inconsistant? It seems to have spaghetti
for innards, and the user interface changes from one tool to the next so
radically that the keys for _copy_ and _paste_ are never the same, and I
don't even want to go into the deletion and selection procedures. Bleah!
:I'm free of Cobol now! Hurrah!
That must be a relief. Congratulations again, and here's hoping it stays
good. BTW, sounds similar to myself, except mine was Fortran. C++ RULES!
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe@hawaii.edu nyospe@premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/ - DBs and Events Felix A. Croes
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- DBs and Events s001gmu@nova.wright.edu
- DBs and Events Nathan Yospe
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- (subject missing) Ben Greear
- META: Unsubscribed users dur to bounces coder@ibm.net
- META: Unsubscribed users dur to bounces Adam Wiggins
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Richard Woolcock
- Source Code Release Ben Greear
- Source Code Release Chris Gray
- Source Code Release Greg Munt
- Source Code Release coder@ibm.net
- Source Code Release Richard Woolcock
- Source Code Release Stephen Zepp
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Travis Casey
- Source Code Release Jon A. Lambert
- Source Code Release Jon A. Lambert
- [RESEARCH]MUD articles archive (fwd) Greg Munt
- Socket programming (Was: The impact of the web on muds) Jon Leonard
- Socket programming (was: The impact of the web on muds) Vadim Tkachenko
- Socket programming (was: The impact of the web on muds) Richard Woolcock
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- user-centered design (was Clients) Mike Sellers
- OT: Linux g++ Greg Munt
- OT: Linux g++ Ben Greear
- OT: Linux g++ coder@ibm.net
- OT: Linux g++ Shawn Halpenny
- OT: Linux g++ Chris Gray
- OT: Clients Vadim Tkachenko
- OT: Clients Adam Wiggins
- OT: Clients coder@ibm.net
- META: OS wars coder@ibm.net
- META: OS wars Mike Sellers
- Clients Stephen Zepp
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Adam Wiggins
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Mike Sellers
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) Ben Greear
- Moore's Law sucks (was: 3D graphics) Ling
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Alex Oren
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Jon A. Lambert
- Version Control (was: DBs and Events) s001gmu@nova.wright.edu
- Version Control (was: DBs and Events) Raph & Kristen Koster
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Felix A. Croes
- Net protocols for MUDing (was: Moore's Law sucks) Jon Leonard
- Net protocols for MUDing (was: Moore's Law sucks) coder@ibm.net
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Caliban Tiresias Darklock
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Ben Greear
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Jon A. Lambert
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- VEIL (was: Clients) Brandon Gillespie
- LDMs (large dynamic maps) was Unique items Mike Sellers
- Describing the environment Stephen Zepp
- Describing the environment Richard Woolcock
- Back on the list Niklas Elmqvist
- Back on the list Chris Gray
- Back on the list coder@ibm.net
- Unique items The Eternal City
- Unique items coder@ibm.net
- Position sorting Adam Wiggins
- Position sorting coder@ibm.net
- Unique items coder@ibm.net
- Unique items Nathan F Yospe
- BOOK: Myer's Silverlock coder@ibm.net
- BOOK: Myer's Silverlock Chris Gray
- BOOK: Myer's Silverlock Adam Wiggins
- Dynamic Loading of Modules (was: Back on the list) Niklas Elmqvist
- Dynamic Loading of Modules (was: Back on the list) Vadim Tkachenko
- Dynamic Loading of Modules (was: Back on the list) J C Lawrence
- Dynamic Loading of Modules (was: Back on the list Jon A. Lambert
- Net protocols for MUDing s001gmu@nova.wright.edu
- Net protocols for MUDing Stephen Zepp
- Net protocols for MUDing Chris Gray
- Net protocols for MUDing Adam Wiggins
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Shawn Halpenny
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Chris Gray
- Dynamic Loading of Modules Niklas Elmqvist
- Senses (was: The MLI Project) s001gmu@nova.wright.edu
- bar-time (was The MLI Project) Mike Sellers
- 3D engines for MUDs (was: The MLI Project) Niklas Elmqvist
- 3D engines for MUDs (was: The MLI Project) J C Lawrence
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- 3D engines for MUDs (was: The MLI Project) Miroslav Silovic
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Cynbe ru Taren
- Why not compile java into object code? Caliban Tiresias Darklock
- Why not compile java into object code? Nathan F Yospe
- Why not compile java into object code? Niklas Elmqvist
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Jon A. Lambert
- Why not compile java into object code? Travis Casey
- Why not compile java into object code? Chris Gray
- Tutorial: Comments on Hand-crafting a compiler Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introduction Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part II: Expression Parsing Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introductio Chris Gray
- Tutorial: Let's build a Compiler! - Part I: Introductio s001gmu@nova.wright.edu
- Tutorial: Let's build a Compiler! - Part I: Introductio coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Koster, Raph
- MUD Development Digest Mike Sellers
- Tutorial: Let's build a Compiler! - Part III: More Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IV: Interpreters Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part V: Control Constructs Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VI: Boolean Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Comments Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VII: Lexical Scanning Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VIII: A Little Philosophy Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IX: A Top View Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part X: Introducing TINY Jon A. Lambert
- Compilers: Toy available for ftp Chris Gray