I think we already decided that the two branches will not have to parallel the changes. The main reason we're splitting the branches is because of the amount of people wanting to keep a version C only.

As far as I'm concerned I'm going to be only contributing the C++ branch project. If someone else wants to try to implement the same features in C they can go for it. :)

Having worked in production environments, I can say that early on there will be quite a bit more cross-talk between the two. There are still those nice fat lists of bugs to go through, and any bugs that haven't been stomped upon by all the mucking about I did are still there. Those will want fixing on both sides.

As for features, I think the initial C++ work won't really be adding many features, but it will be obsoleting things like the shared string code and the recycle code. I suspect using std::map and multimap to replace the arrays of rooms/mobs/objects and their corresponding linked lists will also happen.

When features (such as OLC, colour, etc) gets implemented, if the above mechanical changes haven't taken place yet, I'm sure that will get shared as well. If the C++ side has already changed the data strucutures, they'll have to be implemented in parallel. Even though the UI should be the same, the imlementation might be quite different.

That's absolutely not what I'm talking about.

The idea that something is going to have to be implementing in both places or not is what I'm talking about.

Just because something happens to be implemented in both is separate from if the two projects must parallel each other.

An example of this would be having to implement a similar library to std::string in C. Which we're probably not going to do.

Or implementing std::map in C.

Quix didn't say that they must parallel each other. He said that they are likely to want to parallel each other on many changes, e.g. bug fixes.

You and I are using different meanings for "parallel", I think. :)

There is no doubt in my mind that both parties want to build a better ROM codebase. The features that everyone (more or less) wants to see added to "stock" are the same. When you look at the RaM driver, you should see the same features – at least from the builder/player perspective – regardless of the use of C, C++, assembly, or perl.

Thus, the project branches are in parallel. If one side implements OLC, it becomes necessary for the other side to also implement OLC. They won't use the same implementation, thus they have to be done in parallel. They should share the same UI, and the same on-disk data format. Beyond that, it doesn't matter.

Will every feature that gets done in one, get done in both? THAT depends on how much manpower we have devoted to each branch. If it turns out there's only one or two people who really want to do the work on the C side, it will probably fall behind. If it turns out there are a dozen C lurkers out there and only 3 or 4 C++ folk, that side may well fall behind. We'll see.

These aren't yet two different projects… I don't see our goals being divergent yet, only our choice of tools.

And I didn't say that they must not share things in the first place. So I guess you made my argument for me when I said "that's absolutely not what I'm talking about."

I sincerely apologize, but I have no idea what point you are trying to make.

Here's a link to my current list O bugs to investigate… I hope it's the combination of the ones listed waaaaaay up at the top of this topic.

As usual, sorry for the snakeoil certificate you have to accept… talk to Charter Communications and ask them to stop blocking http if it bugs you. :)

Also, I used a small amount of javascript, so if the page looks super messy, it probably doesn't work for you.

Hmpf… is there an html tag that's MORE aggressive about NOT messing with what's inside it than <pre>? I though that one did no formatting on html, but apparently it still mucks with angle-bracketed things inside it.

Oh well, it's only a 10 minute perl script to generate that anyways…. can't be perfect. :)

<pre> doesn't do any formatting, but it will still process HTML tags (it kind of has to, if you think about it). I don't think that there is a "<verbatim>" mode that is only disabled on "</verbatim>".

Bother. I guess they expect you to search/replace < and > with &lt; and &gt;

Boooo… another committee developed standard for the fail.

I went over the list and checked it against 27.

Key:
Verified– I was able to verify the bug exists.
Unverified– It may or may not exist. For whatever reason I wasn't able to immediately reproduce the bug.
No bug– No actual bug. Either it has been fixed or more likely–It is a bug from a snippet.

1. Verified.
2. Verified. 3. No bug.
4. No bug.
5. No bug. 6. Verified.
7. Verified.
8. Verified. 9. No bug.
10. No bug. 11. Verified. 12. No bugs.
13. No bug.
14. No bug. 15. Unverified. 16. Verified.
17. Verified. 18. No bug.19. Verified.20. No bug.21. Verified.
22. Verified.23. No bug.24. Unverified.25. Verified.
26. Verified.
27. Verified.
28. Verified.29. Unverified.30. Verified.31. Unverified.32. No bug.33. Verified.
34. Verified.
35. Verified.
36. Verified.
37. Verified.
38. Verified.
39. Verified.
40. Verified.41. No bug.42. Verified.
43. Verified.44. Unverified.45. Verified.46. Unverified.47. Verified.
48. Verified.
49. Verified.
50. Verified.
51. Verified.52. Unverified.53. No bug.54. Unverified.55. Verified.
56. Repeater.57. Verified.
58. Repeater.59. Verified.60. Unverified.61. Verified.
62. Verified.
63. Verified.
64. Verified.
65. Verified.
66. Verified.67. Unverified.68. Verified.
69. Verified.
70. Verified.
71. Verified.
72. Verified.
73. Verified.
74. Verified.75. Unverified.76. No bug.77. Unverified.78. Verified.
79. Verified.80. No bug.81. Verified.

pre won't mess with whitespace and the like, but still parses contents. you must sanitize your output through a cleaning function.

i know php has htmlspecialchars im sure perl has a similar counterpart in one of the html libs.

Can you say "Taste the rainbow?" Reminds me of a Skittles commercial. :tongue:

Taste teh rainbow.

Wow, why'd the text get so huge there?

EDIT: and what's with the sig image? :thinking:

First they stifled free speech.

Now they're water boarding people. ;)

Ohhh… waterboarding. I thought it looked a little like somebody was strapped down and being zapped with a brainwashing machine. :lol:

I cheated and just regex-replaced angle brackets. I know perl has a module for that, I just didn't feel like looking it up. :)

Waterboarding? Hmmmm, just because the board background is blue?

Oh yes, the bug list is now RAINBOW coloured, courtesy of Runter! :)

I opened a new port for plain http on port 8088, so let me know if it works (I don't have an external site to try it from myself).

Yes, that would also be what Samson does to trolls.