| View previous topic :: View next topic |
| Author |
Message |
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
 Posted: Thu Dec 22, 2005 10:01 pm Post subject: |
 |
|
| kris wrote: | | teqdruid wrote: | | The question is, what do I replace them with- keeping in mind that I want it to be encoding neutral and I'd rather not template the interface. With the current String.d, I'd have to use a ConvertingString, but, honestly, that's a rather useless class. |
It's value is in the encoding-neutrality alone.
With one exception, I strongly suspect the other String methods would prove to be of little value for this scenario. For example, as a SAX client, I can't see myself ever using append(), format(), truncate(), remove(), or seek() ~ there's just no clear value in them within that use-case. But let's find out ... you can always extend the basic class as necessary.
The exception: If the client is processing CDATA (or something like that) then they may want the string functionality. At that point, the client will be encoding-specific, so it could leverage the relevant String template as desired. |
Actually, I thought that using the seek() method would be rather nice, as I can use it to look for the relevant character. This was the inspiration for the Pointer class. Say I've just looked at a > to close a tag, and Pointer pa is on that tag.
| Code: | Pointer pa;
Pointer pb;
pb.moveTo(pa);
pb.seek('<');
Slice CDATA = pa.sliceTo(pb); |
And this would be well optimized due to seek using the assembly instruction, instead of iterating through each character in a loop. (I'm assuming that the x86 instruction is faster for this purpose)
But again, I'm actually a lot more worried about the client in the String class' usefulness. And by client, I mean me. In neuralNexus, after I get the data out of the XML-RPC request, I have to do more text processing. Most noticable, I have to convert a string of numbers and symbols into (essentially) an array of integers. Currently, the class that does this only supports Utf8, but I'd rather it just use a generic String class, so no virtually transcoding gets done in the neuralNexus server, even if it wants to talk in different Utfs. I'd prefer to make all of my code encoding-neutral to cut down on transcodings.
Even if the client is going to work in a specifc encoding, the Converting string has to have methods that return the TypedString, so they don't have to new the TypedString themselves- then one outta three times there's not actually a new being done.
~John |
|
| Back to top |
|
 |
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Thu Dec 22, 2005 10:04 pm Post subject: |
|
|
| teqdruid wrote: | | But again, I'm actually a lot more worried about the client in the String class' usefulness. And by client, I mean me. In neuralNexus, after I get the data out of the XML-RPC request, I have to do more text processing. Most noticable, I have to convert a string of numbers and symbols into (essentially) an array of integers. Currently, the class that does this only supports Utf8, but I'd rather it just use a generic String class, so no virtually transcoding gets done in the neuralNexus server, even if it wants to talk in different Utfs. I'd prefer to make all of my code encoding-neutral to cut down on transcodings. |
I should probably also note that in addition to my crazy programming methods, I've seen other people's code that do CDATA text processing. The more we can let those programs use an encoding-neutral string to do that text processing, the less transcoding is gonna get done. But that was the whole point with the universal string in the first place.
~John |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Fri Dec 23, 2005 12:45 pm Post subject: |
|
|
| teqdruid wrote: | | Even if the client is going to work in a specifc encoding, the Converting string has to have methods that return the TypedString, so they don't have to new the TypedString themselves- then one outta three times there's not actually a new being done. |
Better yet: a thoughtfully constructed client would maintain an appropriate MutableString as part of the enclosing class instance, so it could simply setTo() the incoming text  |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Thu Dec 29, 2005 2:39 am Post subject: No Heap Transport Mechanism |
|
|
Kris,
Somwhere in this pile of posts you mentioned something about a transport mechanism that doesn't require any heap allocations. This would be immensly useful to me in my SAX parser infrastructure. I'm considering moving back to (|w|d)char arrays in the API simply to avoid heap allocations, and since the current String provides little or no value to a stream-based processor, I'd have no reason to use it. This isn't necessarily a bad thing, but I'm failing to see it's usefulness at all, since most of the text processing that I see people doing with Mango is text based.
I'm going to work on a second revision of my StreamString (currently called ReaderString in both my parsers) and I'd like to integrate it into a transport object- whether it's something you had in mind or not.
~John |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Fri Dec 30, 2005 12:37 pm Post subject: Re: No Heap Transport Mechanism |
|
|
| teqdruid wrote: | | I'm going to work on a second revision of my StreamString (currently called ReaderString in both my parsers) and I'd like to integrate it into a transport object- whether it's something you had in mind or not. |
Glad to hear you're re-considering. I figured it might not be particularly efficient for an XML parser to operate without knowing what encoding the content was in. As to a transport-object ~ would that not be somewhat application specific? I can think of a number of ways to do it, but I'd have to look at your code to suggest anything of value.
Just for the sake of an example: in a scenario whereby the client needs a String, one could maintain a single String instance and just change the content as required before passing it to the client. Then it becomes an issue of ownership: does the engine own the String or does the client? What about the content itself? This is an application-specific concern, and thus is hard to generalize. The same concern arises with a StreamingString: if the content can be switched under the covers, who owns the StreamingString itself? If it's meant to be read-only, then more issues arise. These can all be resolved but, again, it can be tough to generalize such things across application usage. I'm sure you'll come up with something ... |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Fri Dec 30, 2005 4:17 pm Post subject: Re: No Heap Transport Mechanism |
|
|
| kris wrote: | | teqdruid wrote: | | I'm going to work on a second revision of my StreamString (currently called ReaderString in both my parsers) and I'd like to integrate it into a transport object- whether it's something you had in mind or not. |
Glad to hear you're re-considering. I figured it might not be particularly efficient for an XML parser to operate without knowing what encoding the content was in. As to a transport-object ~ would that not be somewhat application specific? I can think of a number of ways to do it, but I'd have to look at your code to suggest anything of value.
Just for the sake of an example: in a scenario whereby the client needs a String, one could maintain a single String instance and just change the content as required before passing it to the client. Then it becomes an issue of ownership: does the engine own the String or does the client? What about the content itself? This is an application-specific concern, and thus is hard to generalize. The same concern arises with a StreamingString: if the content can be switched under the covers, who owns the StreamingString itself? If it's meant to be read-only, then more issues arise. These can all be resolved but, again, it can be tough to generalize such things across application usage. I'm sure you'll come up with something ... |
I'm not conceding that an anonymous string is useless in an XML parser. I still think that templating the entire parser library (handler interface and all) is a hack, but it's what's supported by the current String library, and it is, I must admit, much easier.
As for the transport mechanism being application specific- yes, it is, but it also can't be. In the ISAXHandler interface, I need to pass the handler some sort of text, and I want a container that doesn't require one or more heap allocations per call. I'm extradinarily tempted to use a MutableString in the parser, and just change the text it points to for each call- give the parser ownership, that is, but I can't think of a clear way to show that the parser owns the string. That is, there's nothing to stop the client from copying the reference and using it, expecting the content to stay the same. I could just document it, but who actually reads documentation?! It'd be a nice D 2.0 feature to include some notion of ownership in parameters. A parameter transport attribute that doesn't allow the callee to copy a reference out of a function would be nice. Either that or just make a struct that supports inheritance, but keeps it's stack allocation and copying as is.
How do you deal with alerting the programmer of ownership? Or is there a better way to do this?
Thoughts?
~John[/code] |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Fri Dec 30, 2005 4:46 pm Post subject: |
|
|
I'll give you my 2 cents on the topics:
If I were writing an XML parser, I'd make it either Utf8 or Utf16 throughout depending on whom I thought my primary audience was, pay the potential cost of transcoding at the I/O barrier only, pray for the existence of read-only arrays (per the ownership issue), eliminate all heap activity if at all possible, and make sure the parsing aspect alone were as fast as I could make it. I'm not writing a parser though.
Ownership of parameters is a sticky problem. D does not yet have access-permission on array parameters, though it almost does for simple scalar types like int using "in" and "out". Personally, I think those keywords provide something less than useful; even "inout" is somewhat bogus since it doesn't operate with const structs (instead, one has to use pointer semantics). Thus, praying for language support of "ownership" permission at the object level is a measure of one's faith
The best one can do is attempt to provide read-only versions of whatever classes one has ~ this is expected to at least protect the content. Then, provide a clone() method in a vague attempt to guide a user. It comes as no surprise there's precious little compiler-support in the way of "software contract adherance and protection". For confirmation, one need only recall the fiasco over Interface in the first place.
In summary, there is no good answer at this time. It's likely we'll have to wait until D is successful (enough to leave the nest) for such a thing to happen ~ catch 22? Maybe. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Fri Dec 30, 2005 5:02 pm Post subject: |
|
|
| kris wrote: | | If I were writing an XML parser, I'd make it either Utf8 or Utf16 throughout depending on whom I thought my primary audience was, pay the potential cost of transcoding at the I/O barrier only, |
Transcoding at the I/O barrier only? Won't happen- it's the problem I'm having now with the DOM parser. I selected wchar[], and all my incoming stuff is utf8. Not a big deal, there's an incoming and outgoing conversion.... The problem is doing all of the small conversions. Whenever the client is given a wchar[], it has to do a conversion to char[] because the other library it talks to only works with utf8, which is why I want an anonymous string. That way, everyone can program using AnonymousString and they automatically talk in any encoding, instead of being bound to a particular one. (The only way to do this with templated strings is to template the entire library!) Most programs won't ever have any conversions that way as well, assuming that all of the inputs and outputs are of the same encoding- and if they're not, transcoding can still be done at the I/O border to force it.
Maybe it's better to just make one string class with the encoding determined by an alias so the programmer can choose the entire program's encoding at compile time.
I should really stop ranting about this.
~John |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Fri Dec 30, 2005 6:10 pm Post subject: |
|
|
| teqdruid wrote: | | kris wrote: | | If I were writing an XML parser, I'd make it either Utf8 or Utf16 throughout depending on whom I thought my primary audience was, pay the potential cost of transcoding at the I/O barrier only, |
Transcoding at the I/O barrier only? Won't happen- it's the problem I'm having now with the DOM parser. I selected wchar[], and all my incoming stuff is utf8. Not a big deal, there's an incoming and outgoing conversion.... The problem is doing all of the small conversions. Whenever the client is given a wchar[], it has to do a conversion to char[] because the other library it talks to only works with utf8, which is why I want an anonymous string. That way, everyone can program using AnonymousString and they automatically talk in any encoding, instead of being bound to a particular one. (The only way to do this with templated strings is to template the entire library!) Most programs won't ever have any conversions that way as well, assuming that all of the inputs and outputs are of the same encoding- and if they're not, transcoding can still be done at the I/O border to force it.
Maybe it's better to just make one string class with the encoding determined by an alias so the programmer can choose the entire program's encoding at compile time.
I should really stop ranting about this. |
Yes, you should 
But seriously, there's some flaws in the above logic. I'm gonna' be a jackass and point some of them out (hope you're not offended).
First: you're talking about the very worst case ~ many XML clients do surprisingly little with the content they are passed for each callback. CDATA is sometimes an exception, but even that gets little more than a cursory glance in many applications. The point is that calls out to other libraries at such times are perhaps not as prevelant as you'd seem to indicate. And less so with D than other languages.
Second: you talk about the "other" library that would have to be templated: under your proposal it would have to be designed around AnonymousString instead ~ which is not necessarily to everyone's liking. The "fan-out" problem is arguably no better there than it is with templates. I'd like to see an acceptable solution as much as the next person, so I won't argue further with you about it
Third: you're ignoring all known issues with the AnonymousString you speak of. There's plenty of concern there, and the fact that you're not using one of your own designs lends fuel to that fire. This does not mean a truly universal String class cannot be written and adopted. Instead, we just don't have one that's currently workable or acceptable.
Fourth: contrary to the above claim, transcoding can and will happen at the I/O boundary layer only; for many, many applications or implementations thereof. If one particular scenario can't handle that, it does not stand to reason that all other will follow suit. You describe a problem with one specific XML client, using some specific additional library ~ that limits the scope quite considerably, don't you think?
Fifth: you might consider whether Utf16 is actually the best choice or not. That's only partly tongue-in-cheek, because an XML client that worries about performance (such as a web-server) will likely avoid doing the kinds of things that utf16 might help with. On the other hand, an XML client that does not have to worry so much about such things (such as a file loader, or converter), and needs to perform advanced Utf16 or Utf32 processing (and I do mean advanced), will be content to pay a price for those parts that require transcoding for such purposes. I mention this simply because some may not be aware of how UTF is essentially interchangeable for many kinds of processing without any actual transcoding. That is, many internationalized applications (and servers) can happily get by in Utf8 without performance degradation. I've written a few. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Dec 31, 2005 5:06 am Post subject: |
|
|
edit: Delete accidental double post.
Last edited by teqdruid on Sat Dec 31, 2005 5:43 am; edited 1 time in total |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Dec 31, 2005 5:21 am Post subject: |
|
|
| kris wrote: | | But seriously, there's some flaws in the above logic. I'm gonna' be a jackass and point some of them out (hope you're not offended). |
Finally! Of course I'm not offended. This is what I've been trying to get you to do since I started talking about this. Seriously, you're not being a jackass, you're just arguing against me. I'm not going to understand your view on the topic unless you delinate your points like this. If you feel you're being a jackass, please, be a jackass more often!
| kris wrote: | | First: you're talking about the very worst case ~ many XML clients do surprisingly little with the content they are passed for each callback. CDATA is sometimes an exception, but even that gets little more than a cursory glance in many applications. The point is that calls out to other libraries at such times are perhaps not as prevelant as you'd seem to indicate. And less so with D than other languages. |
This is all true... But what's wrong with designing for the worst case?... Especially since the worst case happens to be my project 
| kris wrote: | | Second: you talk about the "other" library that would have to be templated: under your proposal it would have to be designed around AnonymousString instead ~ which is not necessarily to everyone's liking. The "fan-out" problem is arguably no better there than it is with templates. I'd like to see an acceptable solution as much as the next person, so I won't argue further with you about it |
Well that's true, but the anonymous string provides a method to be encoding-neutral without using templates, so it's something that other libraries and/or programs can use to achieve this.
| kris wrote: | | Third: you're ignoring all known issues with the AnonymousString you speak of. There's plenty of concern there, and the fact that you're not using one of your own designs lends fuel to that fire. This does not mean a truly universal String class cannot be written and adopted. Instead, we just don't have one that's currently workable or acceptable. |
True again. I've already admitted that it's hard, and I'm not certain it's technically feasible with some fo the current specs. It's probably feasible without some of those specs (like MutableUtf8String inheriting directly from Utf8String). I haven't put much time into making it work since if I can't even convince you that it's good in theory (ignoring the problems in implementation) then what's the point of working out the implementation bugs?
| kris wrote: | | Fourth: contrary to the above claim, transcoding can and will happen at the I/O boundary layer only; for many, many applications or implementations thereof. If one particular scenario can't handle that, it does not stand to reason that all other will follow suit. You describe a problem with one specific XML client, using some specific additional library ~ that limits the scope quite considerably, don't you think? |
Yes. You're right- I'm talking about a worst case, and most applications are not going to be a worst case. I keep using this worst case, however, because I think that it's indicitive of an inherient problem to having multiple encoding types strongly typed in the library/language: that anybody can arbitrarly choose any one of the three (there are good reasons to use any of the three) and when I try to interface my code with the other guy's code, we'll quite possibly end up with transcodings at the code border. Will this happen in all code bases? No, not at all. However, I think you underestimate the extent to which this could be a problem. In any application that uses Mango's strings AND another library, there's only a 1 in 3 chance that both are using the same encoding type (obviously), and it, of course, only gets worse with the number of libraries that you involve. Giving the programmer the freedom to choose the encoding that Mango (and any libraries that use Mango use) greately reduces this problem.
| kris wrote: | | Fifth: you might consider whether Utf16 is actually the best choice or not. That's only partly tongue-in-cheek, because an XML client that worries about performance (such as a web-server) will likely avoid doing the kinds of things that utf16 might help with. On the other hand, an XML client that does not have to worry so much about such things (such as a file loader, or converter), and needs to perform advanced Utf16 or Utf32 processing (and I do mean advanced), will be content to pay a price for those parts that require transcoding for such purposes. I mention this simply because some may not be aware of how UTF is essentially interchangeable for many kinds of processing without any actual transcoding. That is, many internationalized applications (and servers) can happily get by in Utf8 without performance degradation. I've written a few. |
True. The bottom line is that I don't think any library should have the right to choose what encoding a client application should have to use. No matter what the reasoning, it's always going to be a somewhat arbitrary choice. In any application I'm programming, I'd like to choose the encoding based on what my inputs tend to be, what my outputs need to be, and (more importantly) what encodings the libraries I'm using are using.
While I still think a true anonymous string would be nice, it's not of the utmost importance to me. What I want is unification. I don't want to have to choose what encoding type is being used unless I'm providing the main() function because I don't like dictating to other people, and they don't like being dictated to.
You mentioned earlier in this discussion that there's some merit to having a unified string that just chooses an encoding and sticks with it. I agree. What do you think about having this in Mango, wherein the encoding is choosen at compile time. That is, insert something like the following at the bottom of your String.d instead of what's currently there:
| Code: | version(Utf8) {
public alias char character;
} else version (Utf16) {
public alias wchar character;
} else version (Utf32) {
public alias dchar character;
} else {
static assert(false); //You must choose an encoding!
}
typedef StringTemplate!(character) String;
typedef MutableStringTemplate!(character) MutableString; |
This way, I can use the symbol "String" all over the place, and my clients can still choose what encoding it's in. It's probably also acceptable to let it default to Utf8. Since everyone's using build now, it should work right. For anyone still using the pre-compiled library- they probably don't care about customization as much, so let Utf8 be pre-prescribed to them.
Thoughts?
~John |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Dec 31, 2005 6:00 am Post subject: |
|
|
| kris wrote: | Ownership of parameters is a sticky problem. D does not yet have access-permission on array parameters, though it almost does for simple scalar types like int using "in" and "out". Personally, I think those keywords provide something less than useful; even "inout" is somewhat bogus since it doesn't operate with const structs (instead, one has to use pointer semantics). Thus, praying for language support of "ownership" permission at the object level is a measure of one's faith
The best one can do is attempt to provide read-only versions of whatever classes one has ~ this is expected to at least protect the content. Then, provide a clone() method in a vague attempt to guide a user. It comes as no surprise there's precious little compiler-support in the way of "software contract adherance and protection". For confirmation, one need only recall the fiasco over Interface in the first place.
In summary, there is no good answer at this time. It's likely we'll have to wait until D is successful (enough to leave the nest) for such a thing to happen ~ catch 22? Maybe. |
So it sounds like the solution for now is to pass a String object to the handler, and to point out in big bold lettering everywhere that the parser owns the string, and it is not immutable. I'll make sure the string has a .clone() method and then use a MutableString in the parser. I've actually been thinking about allocating a new String every time, but allocating it on the stack using a manual memory allocator. This way, if the client copies the reference, it won't be a valid reference, so (hopefull) their code will outright crash when it's run, instead of every other string being the same. I'm not sure, however, which behavior is preferable, and if the crashing behavior is preferable, I'm not certain that it's worth it since class stack allocation is still slower than using mutable strings, and is most definately a hack.
I'm doing my best to write a parser that doesn't do any heap allocations. It's not too hard, actually, what with D's array slicing, to not directly do any heap allocations. It's ensuring that none of the code I'm calling is doing any that's tricky/impossible. I'm planning on letting mango.io handle all of the transcodings that I need, but I'm not certain if it'll be making heap allocations. What's the correct way to do this to eliminate/minimize allocations? I was going to use the stuff in mango.io.BufferCodec and attach it to a Reader, since this seems the straight forward way to do it. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Dec 31, 2005 11:30 am Post subject: |
|
|
The following changes make a few things in my SAX parser and encoder easier and more elegant. For the textEncoder type, this may not be the best way to do it, but I figured there was a reason you didn't just store a reference to the AbstractEncoder object.
| Code: | Index: mango/io/Writer.d
===================================================================
--- mango/io/Writer.d (revision 732)
+++ mango/io/Writer.d (working copy)
@@ -136,6 +136,7 @@
protected IBuffer buffer;
private bool prefixArray;
private IBuffer.Converter textEncoder;
+ private uint textEncoderType = Type.Raw;
/***********************************************************************
@@ -209,8 +210,22 @@
{
e.bind (buffer);
this.textEncoder = &e.encoder;
+ this.textEncoderType = e.type();
}
+
+ /***********************************************************************
+
+ Gives the output encoding of an attached AbstractEncoder.
+
+ Returns Type.Raw if no encoder is attached.
+ ***********************************************************************/
+
+ uint getEncoderType ()
+ {
+ return textEncoderType;
+ }
+
/***********************************************************************
Is this Writer text oriented?
Index: mango/io/model/IWriter.d
===================================================================
--- mango/io/model/IWriter.d (revision 732)
+++ mango/io/model/IWriter.d (working copy)
@@ -150,7 +150,16 @@
***********************************************************************/
abstract void setEncoder (AbstractEncoder);
+
+ /***********************************************************************
+
+ Gives the output encoding of an attached AbstractEncoder.
+
+ Returns Type.Raw if no encoder is attached.
+ ***********************************************************************/
+ abstract uint getEncoderType ();
+
/***********************************************************************
Output a newline. Do this indirectly so that it can be
Index: mango/text/String.d
===================================================================
--- mango/text/String.d (revision 732)
+++ mango/text/String.d (working copy)
@@ -143,6 +143,8 @@
private import mango.text.model.UniString;
+private import mango.io.model.IWriter;
+
/*******************************************************************************
*******************************************************************************/
@@ -1330,6 +1332,11 @@
return a.length - b.length;
}
+
+ public void write (IWriter input)
+ {
+ input.put(content);
+ }
}
Index: mango/text/model/UniString.d
===================================================================
--- mango/text/model/UniString.d (revision 732)
+++ mango/text/model/UniString.d (working copy)
@@ -37,13 +37,15 @@
module mango.text.model.UniString;
+private import mango.io.model.IWriter;
+
/*******************************************************************************
A string abstraction that converts to anything
*******************************************************************************/
-abstract class UniString
+abstract class UniString: IWritable
{
abstract char[] utf8 (char[] dst = null);
|
Do you mind if I commit it?
~John |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Dec 31, 2005 12:18 pm Post subject: |
|
|
Please don't commit that at this time.
I fully appreciate why it's useful to have UniString implement IWritable, but it creates a dependency between mango.Text and Mango.io; one that I'm not at all comfortable with. Yes, I want to see it happen ~ but it needs some thought on organization first. Module interdependencies are often just as important as the functionality therein |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Dec 31, 2005 12:27 pm Post subject: |
|
|
| kris wrote: | Please don't commit that at this time.
I fully appreciate why it's useful to have UniString implement IWritable, but it creates a dependency between mango.Text and Mango.io; one that I'm not at all comfortable with. Yes, I want to see it happen ~ but it needs some thought on organization first. Module interdependencies are often just as important as the functionality therein |
Are you concerned with module interdependancies, or package interdependancies? If the latter, then a version(Isolated) can be used like you do in other places. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
