You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(33) |
Jun
|
Jul
|
Aug
(31) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph P. <fir...@we...> - 2004-10-06 06:15:58
|
Hi guys, I made up my mind about the Story of Craft, so I've written a short draft for proposal. Please read it and correct me or help me in any other form. cya Fire |
From: Christoph P. <fir...@we...> - 2004-10-05 18:57:03
|
Hi guys, I've recently commited the changes to unitmanager.[ch]pp and unit.[ch]pp, but I cannot test it properly because of glibc-Problems. Maybe one of ya guys can test it and inform me about the result. cya Fire |
From: Martin W. <meh...@we...> - 2004-08-23 14:30:45
|
Hey, Arne Rempke wrote: >> - Function CZip::isSupportedImage() moved to CFileAccess > > So please adapt zipwrapper.cpp (e.i. line 87) to call CFileAccess's > function. Corrected. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-23 13:44:24
|
Hi, > - Function CZip::isSupportedImage() moved to CFileAccess So please adapt zipwrapper.cpp (e.i. line 87) to call CFileAccess's function. cya arne |
From: Martin W. <meh...@we...> - 2004-08-22 12:47:52
|
Hello, some months ago I turned on Reply-To-Munging for this list (i. e. that the Reply-To-Header is set to the list for each mail). Due to the reasons against it provided by the page [1] and due to the SF police against it [2] I will turn it off again within the next week. Therefore you will have to look closely where answers to emails from this list will be sent to. [1] http://www.unicom.com/pw/reply-to-harmful.html [2] http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1 Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-20 07:21:10
|
Hey, Arne Rempke wrote: >> [...] >> What exactly is not right? I'm quite sure that the FTP description is >> correct. >> References (German): [1], [2] >> And sure I've heard of keep-alive on HTTP connections. But I do not >> know how it >> exactly works. >> >> [1] http://www.uni-erfurt.de/rechenzentrum/anleitungen/ftp.html >> [2] http://www.elektronik-kompendium.de/sites/net/0902241.htm > > FTP is correct, I never claimed it was wrong (you brought this example up). > In HTTP/1.1 the client can add the header "Connection: Keep-alive". If > the server agrees, it won't close the connection after the body but > keeps it open for the next request. OK, but the server knows that if it has the whole body sent it has to listen to new headers. > [...] > Ok, I just saw that the cvs implementation is another that you described > here, so that should work. Oh, dit I forget to mention that I implemented escaping? But that version had also a bug. So I implemented not only masking of \[separator] but of all \ . Here an example: Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\nfoo bar\n Parsed to: Packet 1: \nfoo bar With the old implementation the first \\n would not be recognized as separator but as masked separator. So with masking all \ : Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\\nfoo bar\n Parsed to: Packet 1: \ Packet 2: foo bar So this should work now at all events. > [...] > I could say, that it was just not documented and perhaps also not easy > to find in the code, but it was implemented by SDL_net. You only made > your own functions to call the ones of SDL_net (which is of course not > necessaryly a direct mapping of one function wnetwork to one function > SDL_net). But it would probably be hairsplitting and it is not really > important. ACK Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-20 05:01:15
|
Hey, Arne Rempke wrote: >> [...] >> What exactly is not right? I'm quite sure that the FTP description is >> correct. >> References (German): [1], [2] >> And sure I've heard of keep-alive on HTTP connections. But I do not >> know how it >> exactly works. >> >> [1] http://www.uni-erfurt.de/rechenzentrum/anleitungen/ftp.html >> [2] http://www.elektronik-kompendium.de/sites/net/0902241.htm > > FTP is correct, I never claimed it was wrong (you brought this example up). > In HTTP/1.1 the client can add the header "Connection: Keep-alive". If > the server agrees, it won't close the connection after the body but > keeps it open for the next request. OK, but the server knows that if it has the whole body sent it has to listen to new headers. > [...] > Ok, I just saw that the cvs implementation is another that you described > here, so that should work. Oh, dit I forget to mention that I implemented escaping? But that version had also a bug. So I implemented not only masking of \[separator] but of all \ . Here an example: Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\nfoo bar\n Parsed to: Packet 1: \nfoo bar With the old implementation the first \\n would not be recognized as separator but as masked separator. So with masking all \ : Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\\nfoo bar\n Parsed to: Packet 1: \ Packet 2: foo bar So this should work now at all events. > [...] > I could say, that it was just not documented and perhaps also not easy > to find in the code, but it was implemented by SDL_net. You only made > your own functions to call the ones of SDL_net (which is of course not > necessaryly a direct mapping of one function wnetwork to one function > SDL_net). But it would probably be hairsplitting and it is not really > important. ACK Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-19 20:46:28
|
Hey, on June, 9th, we got a support request and nobody noticed that. I'v just assigned it to me. Due to this dereliction I'm suggesting to auto-assign all requests to me first as a kind of wrapper and I will assign it to the "affected person". Do you think this would be ok? Or not? Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-19 20:09:12
|
Hey, I've just adapted my sources to use the configure results. This involved the following changes: - CZip should not be used in other modules than CFileAccess now. - Made use of zziplib optional - Function CZip::isSupportedImage() moved to CFileAccess - Added functions.[hc]pp where functions that a particular system does not offer can be defined if configure says so (currently floor() is implemented there if HAVE_FLOOR is not set by configure). - dir.[hc]pp has become obsolete since CFileAccess handles all files now. (Still used in kernel.cpp, use CFileAccess::list() instead). Please also adapt your sources to use the configure results (some more have to be evaluated by the unit manager). Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-19 17:34:28
|
Hi, >>>>That sounds better. But did you ever think of any protocols that do not >>>>have a static seperator? A simple example is HTTP, where you have the >>>>header which is seperated by \r\n, but then comes the body which has no >>>>seperators. Logically all the data in the body belong together, but with >>>>your seperating feature it would be splitted into several "commands", as >>>>it was correctly done for the header. >>> >>>Yes, but HTTP need not to be able to receive data after the body since >>>the >>>connection ends then. And FTP has two data channels, one for the >>>commands and >>>one for the data since you can never be sure that a separator or a >>>command is >>>unique when transmitting files. >>> >> >>No, that's not right. Have you ever heard of "keep-alive"? > > > What exactly is not right? I'm quite sure that the FTP description is correct. > References (German): [1], [2] > And sure I've heard of keep-alive on HTTP connections. But I do not know how it > exactly works. > > [1] http://www.uni-erfurt.de/rechenzentrum/anleitungen/ftp.html > [2] http://www.elektronik-kompendium.de/sites/net/0902241.htm FTP is correct, I never claimed it was wrong (you brought this example up). In HTTP/1.1 the client can add the header "Connection: Keep-alive". If the server agrees, it won't close the connection after the body but keeps it open for the next request. >>>>The better way for masking is not to add some >>>>characters, but to dublicate all occurences of one masking character in >>>>the content so that you can use combinations of one of this character, >>>>as it is done with the backspace: \\ is the original \ and several >>>>combinations like \n \r \t \" represent the data that you are not able >>>>to express with a single char. >>> >>>You are right. Before, I already thought about duplicating the >>>separator. But >>>this also has disadvantages / bugs. For example: >>> >>>Separator is \n >> >>If you dublicate the orriginal occurence so that it is two bytes long, >>the seperator has to be the same length. For example \n is the mask, >>than \n\n means that it is a _real_ \n and for example \n\0 means that >>it is the end of our symbolic packet. > > > Didn't understand that. > > >>>Sending \n\n >>>Real sent is \n\n\n\n\n >> >>Real sent would be \n\n\n\n\n\0 >> > > > Are you sure that we get a \0? And what if a binary file contains \n\0? I think we will get a \0. AFAIK the SDL_net receive function adds a \0 to the received data, but the actual length is given to the send function with an extra parameter and is returned by the receive function. >>>Received is \n\n as first packet. OK. That works I thought. >>> >>>But: >>>Packet 1: test >>>Packet 2: \n\n >>>Sending packets >>>Real sent and received is test\n\n\n\n\n\n >> >>Real sent and received would be test\n\0\n\n\n\n > > > Same as above. > > >>(I think you did a \n too much, but that doesn't matter) > > > No, I did not. You fogot the separator of the \n\n packet. Oh, that's right, and my correction was wrong. It would be test\n\0\n\n\n\n\n\0 >>>Parsed to: >>>Packet 1: test\n\n\n >> >> >>Would be parsed to (split at \n\0, then convert all \n\n into \n) >>Packet 1: test >>Packet 2: \n\n > > > See above. > > However, this discussion is somehow obsolete since now with the escaping I > explained it works fine. Ok, I just saw that the cvs implementation is another that you described here, so that should work. >>>[...] >>>Of course, it had! What about connection management and the workaround >>>since >>>original calls to receiving are blocking? >> >>That are all features which are not completely new, but which existed in >>another form. Even without wnetwork, you could establish several >>connections over SDL_net. And blocking in receiving is default, but >>SDL_net offered the possibility to change this. > > > No. In the docs nowhere was mentioned that you could get non-blocking calls for > single connections with SocketSets. They are even described to be used only for > multiple connections. I could say, that it was just not documented and perhaps also not easy to find in the code, but it was implemented by SDL_net. You only made your own functions to call the ones of SDL_net (which is of course not necessaryly a direct mapping of one function wnetwork to one function SDL_net). But it would probably be hairsplitting and it is not really important. cya arne |
From: Martin W. <meh...@we...> - 2004-08-19 13:43:23
|
Hey, Arne Rempke wrote: >>> That sounds better. But did you ever think of any protocols that do not >>> have a static seperator? A simple example is HTTP, where you have the >>> header which is seperated by \r\n, but then comes the body which has no >>> seperators. Logically all the data in the body belong together, but with >>> your seperating feature it would be splitted into several "commands", as >>> it was correctly done for the header. >> >> Yes, but HTTP need not to be able to receive data after the body since >> the >> connection ends then. And FTP has two data channels, one for the >> commands and >> one for the data since you can never be sure that a separator or a >> command is >> unique when transmitting files. >> > > No, that's not right. Have you ever heard of "keep-alive"? What exactly is not right? I'm quite sure that the FTP description is correct. References (German): [1], [2] And sure I've heard of keep-alive on HTTP connections. But I do not know how it exactly works. [1] http://www.uni-erfurt.de/rechenzentrum/anleitungen/ftp.html [2] http://www.elektronik-kompendium.de/sites/net/0902241.htm >>> The better way for masking is not to add some >>> characters, but to dublicate all occurences of one masking character in >>> the content so that you can use combinations of one of this character, >>> as it is done with the backspace: \\ is the original \ and several >>> combinations like \n \r \t \" represent the data that you are not able >>> to express with a single char. >> >> You are right. Before, I already thought about duplicating the >> separator. But >> this also has disadvantages / bugs. For example: >> >> Separator is \n > > If you dublicate the orriginal occurence so that it is two bytes long, > the seperator has to be the same length. For example \n is the mask, > than \n\n means that it is a _real_ \n and for example \n\0 means that > it is the end of our symbolic packet. Didn't understand that. >> Sending \n\n >> Real sent is \n\n\n\n\n > > Real sent would be \n\n\n\n\n\0 > Are you sure that we get a \0? And what if a binary file contains \n\0? >> Received is \n\n as first packet. OK. That works I thought. >> >> But: >> Packet 1: test >> Packet 2: \n\n >> Sending packets >> Real sent and received is test\n\n\n\n\n\n > > Real sent and received would be test\n\0\n\n\n\n Same as above. > (I think you did a \n too much, but that doesn't matter) No, I did not. You fogot the separator of the \n\n packet. > >> Parsed to: >> Packet 1: test\n\n\n > > > Would be parsed to (split at \n\0, then convert all \n\n into \n) > Packet 1: test > Packet 2: \n\n See above. However, this discussion is somehow obsolete since now with the escaping I explained it works fine. >> [...] >> Of course, it had! What about connection management and the workaround >> since >> original calls to receiving are blocking? > > That are all features which are not completely new, but which existed in > another form. Even without wnetwork, you could establish several > connections over SDL_net. And blocking in receiving is default, but > SDL_net offered the possibility to change this. No. In the docs nowhere was mentioned that you could get non-blocking calls for single connections with SocketSets. They are even described to be used only for multiple connections. > [...] Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-19 10:15:01
|
Hi, >>That sounds better. But did you ever think of any protocols that do not >>have a static seperator? A simple example is HTTP, where you have the >>header which is seperated by \r\n, but then comes the body which has no >>seperators. Logically all the data in the body belong together, but with >>your seperating feature it would be splitted into several "commands", as >>it was correctly done for the header. > > > Yes, but HTTP need not to be able to receive data after the body since the > connection ends then. And FTP has two data channels, one for the commands and > one for the data since you can never be sure that a separator or a command is > unique when transmitting files. > No, that's not right. Have you ever heard of "keep-alive"? >>The better way for masking is not to add some >>characters, but to dublicate all occurences of one masking character in >>the content so that you can use combinations of one of this character, >>as it is done with the backspace: \\ is the original \ and several >>combinations like \n \r \t \" represent the data that you are not able >>to express with a single char. > > > You are right. Before, I already thought about duplicating the separator. But > this also has disadvantages / bugs. For example: > > Separator is \n If you dublicate the orriginal occurence so that it is two bytes long, the seperator has to be the same length. For example \n is the mask, than \n\n means that it is a _real_ \n and for example \n\0 means that it is the end of our symbolic packet. > Sending \n\n > Real sent is \n\n\n\n\n Real sent would be \n\n\n\n\n\0 > Received is \n\n as first packet. OK. That works I thought. > > But: > Packet 1: test > Packet 2: \n\n > Sending packets > Real sent and received is test\n\n\n\n\n\n Real sent and received would be test\n\0\n\n\n\n (I think you did a \n too much, but that doesn't matter) > Parsed to: > Packet 1: test\n\n\n Would be parsed to (split at \n\0, then convert all \n\n into \n) Packet 1: test Packet 2: \n\n >>>>I think, your wnetwork class is the wrong place to put this seperating >>>>feature. These seperating feature is part of the syntax of all data over >>>>network. So the only instance that is allowed to produce this seperator >>>>is the same that is responsible for the rest of the syntax - and that is >>>>not your wrapping class. >>> >>>OK, now the instance that is responsible for the syntax is also able >>>to set the >>>separator. But I do not think that this separating is in a wrong place >>>since >>>(almost) all derived classes need it and therefore it would be >>>nonsense that >>>every derived class implements its own separating. WNetwork is not be >>>intended >>>for only being a wrapper class to SDL_net but also for adopting such >>>things for >>>derived classes so that those implementations are easier. >> >>Ok, I thought it was supposed to be only a wrapper since it had ne such >>additional features till now. > > > Of course, it had! What about connection management and the workaround since > original calls to receiving are blocking? That are all features which are not completely new, but which existed in another form. Even without wnetwork, you could establish several connections over SDL_net. And blocking in receiving is default, but SDL_net offered the possibility to change this. AFAIK SDL_net has no feature for this seperating, so that is a really new thing. cya arne |
From: Martin W. <meh...@we...> - 2004-08-18 21:08:10
|
Hey, Arne Rempke wrote: >> [...] >> It was. If I send a packet, I want to receive this packet and not all >> packets >> that were received since the last call. > > With a call for send() you can't be sure that all passed data are sent > in exactly one packet. On a lower level (somewhere in you os' network > tcp-network-implementation), the data is buffered. So if you call send() > several times in a row, the data you passed in different calls is sent > together in one packet. Or if you call send() with a vera long string, > the data will be probably splitted into many packets. What you > implemented is no packet seperator, but a "function call seperator". OK, or you call it "logical packets" or so ;) >> [...] >> Implemented masking and a variable separator. You have to call the >> constructor >> WNetwork(separator, separator_mask) or setSeparator() (same arguments) >> while >> separator is the desired separator (for craft \n, I think) and >> separator_mask is >> a 2-character-string whose first char is prepended and whose second >> one is >> appended for masking. This could be °°, for example. > This changed now. separator_mask is abolished. Call simply WNetwork(separator) . > > That sounds better. But did you ever think of any protocols that do not > have a static seperator? A simple example is HTTP, where you have the > header which is seperated by \r\n, but then comes the body which has no > seperators. Logically all the data in the body belong together, but with > your seperating feature it would be splitted into several "commands", as > it was correctly done for the header. Yes, but HTTP need not to be able to receive data after the body since the connection ends then. And FTP has two data channels, one for the commands and one for the data since you can never be sure that a separator or a command is unique when transmitting files. > [...] > And another thing: Do you mask the seperator_mask? In your example with > \n as seperator and °° as seperator_mask, will °\n° be masked? Ok, it's > is not really supposable, that data will contain this (similar > possibility as \n\r\t), but we send binary files and I won't assure that > it's impossible. ACK > The better way for masking is not to add some > characters, but to dublicate all occurences of one masking character in > the content so that you can use combinations of one of this character, > as it is done with the backspace: \\ is the original \ and several > combinations like \n \r \t \" represent the data that you are not able > to express with a single char. You are right. Before, I already thought about duplicating the separator. But this also has disadvantages / bugs. For example: Separator is \n Sending \n\n Real sent is \n\n\n\n\n Received is \n\n as first packet. OK. That works I thought. But: Packet 1: test Packet 2: \n\n Sending packets Real sent and received is test\n\n\n\n\n\n Parsed to: Packet 1: test\n\n\n So this did not solve this issue. So I thought about implementing escaping and I did it. I've just committed the update to WNetwork. >>> But... did you ever think of other clients? For example a telnet client >>> for testing would have no chance to send anything to the server (or do >>> you have a key on your keyboard that produces \n\r?). >> >> This is fixed with the new opportunity to set the separator to any >> desired >> value. Each application can decide whether it uses a telnet-compatible >> separator >> or not. > > Yes, I think we should be (and stay) "telnet compatible" ;) > Sure, that's OK. I just didn't consider that in the first version of separating. >>> I think, your wnetwork class is the wrong place to put this seperating >>> feature. These seperating feature is part of the syntax of all data over >>> network. So the only instance that is allowed to produce this seperator >>> is the same that is responsible for the rest of the syntax - and that is >>> not your wrapping class. >> >> OK, now the instance that is responsible for the syntax is also able >> to set the >> separator. But I do not think that this separating is in a wrong place >> since >> (almost) all derived classes need it and therefore it would be >> nonsense that >> every derived class implements its own separating. WNetwork is not be >> intended >> for only being a wrapper class to SDL_net but also for adopting such >> things for >> derived classes so that those implementations are easier. > > Ok, I thought it was supposed to be only a wrapper since it had ne such > additional features till now. Of course, it had! What about connection management and the workaround since original calls to receiving are blocking? >>> In CNetwork, this is already implemented. The seperating character is a >>> simple \n, which is part of the syntax and which can be produced by >>> every telnet client. >> >> Yes, I knew that. But WNetwork is a separate library that develops >> further and >> this feature was needed for an other project of mine and a project of >> a friend. >> I'm sorry about that, but I think you can remove your implementation of >> separating. Imagine, SDL has a new feature which we implemented on our >> own >> before, we would also use the new SDL feature, wouldn't we? > > Probably, we would (in case it is stable and widely-used). Of course, and I think the separating with escaping now is stable ;) Kind regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-18 11:14:29
|
Hi, >>>due to a severe bug in the WNetwork I released a new version that has >>>some >>>changes. The bug was that if more than one packet was sent to the >>>server, for >>>example, it received them as if they were one packet. >> >> >>Well, uh, I don't think, that was a bug. > > > It was. If I send a packet, I want to receive this packet and not all packets > that were received since the last call. With a call for send() you can't be sure that all passed data are sent in exactly one packet. On a lower level (somewhere in you os' network tcp-network-implementation), the data is buffered. So if you call send() several times in a row, the data you passed in different calls is sent together in one packet. Or if you call send() with a vera long string, the data will be probably splitted into many packets. What you implemented is no packet seperator, but a "function call seperator". >>>Therefore WNetwork now >> >>>implements a packet separator (which is \n\r\t , but that's only >>>internally >>>important) and splits the received data into the original packets. >>>Incomplete >>>packets are stored and concantenated. >> >> >>Ok, you add this seperator, but you don't mask this sequence. If a >>client (or server) wants to send this sequence, it will never reach its >>destination because it's filtered out and the data around this sequence >>is splitted into two packets which can cause more problems than with out >>this splitting. >> > > > Implemented masking and a variable separator. You have to call the constructor > WNetwork(separator, separator_mask) or setSeparator() (same arguments) while > separator is the desired separator (for craft \n, I think) and separator_mask is > a 2-character-string whose first char is prepended and whose second one is > appended for masking. This could be °°, for example. That sounds better. But did you ever think of any protocols that do not have a static seperator? A simple example is HTTP, where you have the header which is seperated by \r\n, but then comes the body which has no seperators. Logically all the data in the body belong together, but with your seperating feature it would be splitted into several "commands", as it was correctly done for the header. A similar thing is in craft during the syncronization: Files are passed, that contain newlines (binary files even more difficult characters), but all the lines of one file belong to one command. And another thing: Do you mask the seperator_mask? In your example with \n as seperator and °° as seperator_mask, will °\n° be masked? Ok, it's is not really supposable, that data will contain this (similar possibility as \n\r\t), but we send binary files and I won't assure that it's impossible. The better way for masking is not to add some characters, but to dublicate all occurences of one masking character in the content so that you can use combinations of one of this character, as it is done with the backspace: \\ is the original \ and several combinations like \n \r \t \" represent the data that you are not able to express with a single char. >>But... did you ever think of other clients? For example a telnet client >>for testing would have no chance to send anything to the server (or do >>you have a key on your keyboard that produces \n\r?). > > > This is fixed with the new opportunity to set the separator to any desired > value. Each application can decide whether it uses a telnet-compatible separator > or not. Yes, I think we should be (and stay) "telnet compatible" ;) >>I think, your wnetwork class is the wrong place to put this seperating >>feature. These seperating feature is part of the syntax of all data over >>network. So the only instance that is allowed to produce this seperator >>is the same that is responsible for the rest of the syntax - and that is >>not your wrapping class. > > > OK, now the instance that is responsible for the syntax is also able to set the > separator. But I do not think that this separating is in a wrong place since > (almost) all derived classes need it and therefore it would be nonsense that > every derived class implements its own separating. WNetwork is not be intended > for only being a wrapper class to SDL_net but also for adopting such things for > derived classes so that those implementations are easier. Ok, I thought it was supposed to be only a wrapper since it had ne such additional features till now. >>In CNetwork, this is already implemented. The seperating character is a >>simple \n, which is part of the syntax and which can be produced by >>every telnet client. > > > Yes, I knew that. But WNetwork is a separate library that develops further and > this feature was needed for an other project of mine and a project of a friend. > I'm sorry about that, but I think you can remove your implementation of > separating. Imagine, SDL has a new feature which we implemented on our own > before, we would also use the new SDL feature, wouldn't we? Probably, we would (in case it is stable and widely-used). cya arne |
From: Martin W. <meh...@we...> - 2004-08-18 10:17:42
|
Hey, first of all, thank you for your feedback. Just committed a new version of WNetwork. See below. Arne Rempke wrote: >> due to a severe bug in the WNetwork I released a new version that has >> some >> changes. The bug was that if more than one packet was sent to the >> server, for >> example, it received them as if they were one packet. > > > Well, uh, I don't think, that was a bug. It was. If I send a packet, I want to receive this packet and not all packets that were received since the last call. > >> Therefore WNetwork now > >> implements a packet separator (which is \n\r\t , but that's only >> internally >> important) and splits the received data into the original packets. >> Incomplete >> packets are stored and concantenated. > > > Ok, you add this seperator, but you don't mask this sequence. If a > client (or server) wants to send this sequence, it will never reach its > destination because it's filtered out and the data around this sequence > is splitted into two packets which can cause more problems than with out > this splitting. > Implemented masking and a variable separator. You have to call the constructor WNetwork(separator, separator_mask) or setSeparator() (same arguments) while separator is the desired separator (for craft \n, I think) and separator_mask is a 2-character-string whose first char is prepended and whose second one is appended for masking. This could be °°, for example. >> This involves changes in the interface of >> WNetwork: >> >> - ClientParse() and ServerParse() must take a packet (string) as >> second argument. This packet is now a reference. > That is quite ok, even without this new mechanism. Fine. > But... did you ever think of other clients? For example a telnet client > for testing would have no chance to send anything to the server (or do > you have a key on your keyboard that produces \n\r?). This is fixed with the new opportunity to set the separator to any desired value. Each application can decide whether it uses a telnet-compatible separator or not. > I think, your wnetwork class is the wrong place to put this seperating > feature. These seperating feature is part of the syntax of all data over > network. So the only instance that is allowed to produce this seperator > is the same that is responsible for the rest of the syntax - and that is > not your wrapping class. OK, now the instance that is responsible for the syntax is also able to set the separator. But I do not think that this separating is in a wrong place since (almost) all derived classes need it and therefore it would be nonsense that every derived class implements its own separating. WNetwork is not be intended for only being a wrapper class to SDL_net but also for adopting such things for derived classes so that those implementations are easier. > > In CNetwork, this is already implemented. The seperating character is a > simple \n, which is part of the syntax and which can be produced by > every telnet client. Yes, I knew that. But WNetwork is a separate library that develops further and this feature was needed for an other project of mine and a project of a friend. I'm sorry about that, but I think you can remove your implementation of separating. Imagine, SDL has a new feature which we implemented on our own before, we would also use the new SDL feature, wouldn't we? Kind regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-17 23:01:41
|
Hi, > due to a severe bug in the WNetwork I released a new version that has some > changes. The bug was that if more than one packet was sent to the server, for > example, it received them as if they were one packet. Well, uh, I don't think, that was a bug. > Therefore WNetwork now > implements a packet separator (which is \n\r\t , but that's only internally > important) and splits the received data into the original packets. Incomplete > packets are stored and concantenated. Ok, you add this seperator, but you don't mask this sequence. If a client (or server) wants to send this sequence, it will never reach its destination because it's filtered out and the data around this sequence is splitted into two packets which can cause more problems than with out this splitting. > This involves changes in the interface of > WNetwork: > > - ClientParse() and ServerParse() must take a packet (string) as second argument. That is quite ok, even without this new mechanism. But... did you ever think of other clients? For example a telnet client for testing would have no chance to send anything to the server (or do you have a key on your keyboard that produces \n\r?). I think, your wnetwork class is the wrong place to put this seperating feature. These seperating feature is part of the syntax of all data over network. So the only instance that is allowed to produce this seperator is the same that is responsible for the rest of the syntax - and that is not your wrapping class. In CNetwork, this is already implemented. The seperating character is a simple \n, which is part of the syntax and which can be produced by every telnet client. cya arne |
From: Martin W. <meh...@we...> - 2004-08-17 08:34:01
|
Hey, due to a severe bug in the WNetwork I released a new version that has some changes. The bug was that if more than one packet was sent to the server, for example, it received them as if they were one packet. Therefore WNetwork now implements a packet separator (which is \n\r\t , but that's only internally important) and splits the received data into the original packets. Incomplete packets are stored and concantenated. This involves changes in the interface of WNetwork: - ClientParse() and ServerParse() must take a packet (string) as second argument. - The base class for the connections is now stored in wnetconnbase.hpp and should no longer be modified. The WServerConnection and WClientConnection classes are now declared in wnetconn.hpp as derived from WBaseConnection and custom elements should only be placed here. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-14 22:30:41
|
Hey, Arne Rempke wrote: > [...] >> At last allow me one annotation: we should only use one config lib in >> craft. > > Yes, definitly we should. Perhaps we should combine the simple format of > my cfglib with the speed of Kris' implementation and the error detection > of your version? That's simple: the only big difference between ours and your versions is that we parse line by line and you char by char. This makes IMO the difference. I don't think that it is possible to "copy" my error detection into a new cfglib since it is partly based on the format I described earlier here. Maybe it is possible with some adaptions ... but that's not my decision. CfgLib is your territory ... > [...] Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-14 22:09:00
|
Hi, > My implementation does not abort parsing the file but the line. I did not look into the sources to determine that. But I think that would be ok. > It's just an addition. Since most of the configuration is almost always done > using some kind of GUI, the user won't even see it at all. You mentioned the > disadvantage with the # - that was my main reason for that. The masking is a > thing I have on my TODO list. As I said, quoting and masking is irreplacable in complex structures like a c++ source file. But IMHO it is overkill for this simple format. And for this problem with # - if it is really one, at least I had no desire to use # as part of a value - I already proposed a simple solution. > I have to apologize if this sounded like I wanted to diminish your efforts > invested in your config libs. You know, it was just like I had a new config lib > written for my purposes on another project, and I saw that it had some more > advantages to the config libs used in craft. So I set up an email containing > some of the advantages I saw and suggesting to use it. It was only a > _suggestion_, so I will not insist of it. I have not programmed it with the aim > to include it in craft, so that I would be angry or so. Let's say, it was just a > BTW ... ;) It's ok. > At last allow me one annotation: we should only use one config lib in craft. Yes, definitly we should. Perhaps we should combine the simple format of my cfglib with the speed of Kris' implementation and the error detection of your version? > PS: @arne: Can you please post the characters that did not work for you in the menu? Did it already yesterday ;) |
From: Martin W. <meh...@we...> - 2004-08-14 21:59:19
|
Hey, Arne Rempke wrote: > [...] > °, §, ´, ², ³, €, µ > They are not really important as most of them are really special. > That's right and I have the same thing here. I also think that we can waive them. The important ones are []-_ ... in any case. > I'm not sure, but it seems that both , and . are displayed as . and ; > and : are shown as :. I don't know if that is a bug in detecting typed > chars or just in displaying it. (Perhaps a font problem?) I noticed that, too. It is a problem of the font. Look at the bitmap and you'll see a :: and .. where :; and ., should be. Maybe I find an other, better font. But ATM it is not that fatal ;) Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-14 21:43:57
|
Hi, >>>I've added the following features to the menu: >>> >>>- is able to receive all types of characters like []/_#'+* ... and the >>>german >>>umlauts äöüß >> >>Works for most common characters but not for all (at least here). > > > Please post which do not work. °, §, ´, ², ³, €, µ They are not really important as most of them are really special. I'm not sure, but it seems that both , and . are displayed as . and ; and : are shown as :. I don't know if that is a bug in detecting typed chars or just in displaying it. (Perhaps a font problem?) cya arne |
From: Martin W. <meh...@we...> - 2004-08-14 21:03:21
|
Hey, Arne Rempke wrote: > Hi Martin, > >> I've just written my own config lib WConfig for another project of >> mine and I >> think that it could be very usefully for craft. It is almost as fast >> as Kris' >> config lib and provides some more features than the config libs in >> /lib/ and /src/: >> >> - Gives detailled error messages to stderr when a parsing error occurs >> with >> exact position in file so that the user can correct errors easily. > > > That's a nice bonus, but I don't think it's that necessary as it is in > file formats which are more complex. My src/cfglib.?pp is not that > strict and raises an error, but tries to parse the rest of the file. If > you have one "bad" character in your config, the worst case is, that one > option has a wrong value, but all the other values are correct. That's > because of the simple format: each entry can stand alone and no option > is based on another (perhaps they are based on each other in a logical > way, but at least not from the syntax of the configfile). > I'm not sure if it is better to abort parsing when there is an error or > if it is even worse than to try to continue in the best possible way. > For example, if this error message is printed to stderr, a windows user > won't even know that there is an error in his configuration, as long as > he does not look into the stderr.txt file. If the program starts normal, > but does not act as the user putatively told in the configuration, there > is a good chance that he will look into the file at the exactly right > line (where he defined the option that is ignored) and find the "bad" > character. My implementation does not abort parsing the file but the line. For example, if you have str = foo bar then the pair str -> foo will be stored but bar will be ignored. > >> - Recognizes some more formats, I think. For example: >> str = "test test" > > > Of course, that would be quite nice for all coders, because they > (normally) are used to this syntax. But for a non-coder it is probably > not the obvious syntax. And I don't think these quotes are necessary, > since there is no new option or something after a blank. The value > string has a natural end, that is the newline or carriage return. And > you have to implement masking for at least the " and the masking char > (perhaps '\'). > Of course, the unmasked format hast also disadvantages: It is not > possible to have an option with an whitechar at the begining or end > since they are ignored (at least in my implementation). And it is not > possible to have an value containing a '#', since this is the comment > char. If that is a real problem, it would be possible to disable > comments in a line with a definition but only accept lines with a '#' as > first character as a comment. > I don't think this limitation with whitechars at the beginning or end of > the value is that grave that it is really necessary to adopt quoted > strings. > It's just an addition. Since most of the configuration is almost always done using some kind of GUI, the user won't even see it at all. You mentioned the disadvantage with the # - that was my main reason for that. The masking is a thing I have on my TODO list. >> and also any and any number of whitespaces between lines, keys, equal >> signs and >> values. (lib/cfglib.?pp has troubles with this, even it does not >> recognize any >> whitespace within a value) >> - These whitespaces are "corrected" to default (one space) when saving >> the config. > > IIRC, my implementation handles this in a similar way as yours. I know. It was more an advantage to the lib/ version. And at least the unitmanager uses it although it is an important thing that the unit loading is more fault tolerant. > >> In some ways this config lib might be more strict than the "old" ones: >> for >> example is >> str = foo bar >> wrong since the string was not embedded into double quotes although it >> contains >> whitespaces. >> >> What's your opinion? Shall we use it for craft? Code as attachment. > > Sorry, but the only _real_ advantage I see, is the speed. But (at least > now) I don't think speed is that important, since the configurations are > very small and are typically parsed once in a not really speed critical > situation. I can't imagine, that a change of the configuration library > would speed up craft radically. Of course, due to the one-time-loading, this isn't as much important as it sounds. I have to apologize if this sounded like I wanted to diminish your efforts invested in your config libs. You know, it was just like I had a new config lib written for my purposes on another project, and I saw that it had some more advantages to the config libs used in craft. So I set up an email containing some of the advantages I saw and suggesting to use it. It was only a _suggestion_, so I will not insist of it. I have not programmed it with the aim to include it in craft, so that I would be angry or so. Let's say, it was just a BTW ... ;) At last allow me one annotation: we should only use one config lib in craft. Regards, martin PS: @arne: Can you please post the characters that did not work for you in the menu? -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-14 17:56:36
|
Hi Martin, > I've just written my own config lib WConfig for another project of mine and I > think that it could be very usefully for craft. It is almost as fast as Kris' > config lib and provides some more features than the config libs in /lib/ and /src/: > > - Gives detailled error messages to stderr when a parsing error occurs with > exact position in file so that the user can correct errors easily. That's a nice bonus, but I don't think it's that necessary as it is in file formats which are more complex. My src/cfglib.?pp is not that strict and raises an error, but tries to parse the rest of the file. If you have one "bad" character in your config, the worst case is, that one option has a wrong value, but all the other values are correct. That's because of the simple format: each entry can stand alone and no option is based on another (perhaps they are based on each other in a logical way, but at least not from the syntax of the configfile). I'm not sure if it is better to abort parsing when there is an error or if it is even worse than to try to continue in the best possible way. For example, if this error message is printed to stderr, a windows user won't even know that there is an error in his configuration, as long as he does not look into the stderr.txt file. If the program starts normal, but does not act as the user putatively told in the configuration, there is a good chance that he will look into the file at the exactly right line (where he defined the option that is ignored) and find the "bad" character. > - Recognizes some more formats, I think. For example: > str = "test test" Of course, that would be quite nice for all coders, because they (normally) are used to this syntax. But for a non-coder it is probably not the obvious syntax. And I don't think these quotes are necessary, since there is no new option or something after a blank. The value string has a natural end, that is the newline or carriage return. And you have to implement masking for at least the " and the masking char (perhaps '\'). Of course, the unmasked format hast also disadvantages: It is not possible to have an option with an whitechar at the begining or end since they are ignored (at least in my implementation). And it is not possible to have an value containing a '#', since this is the comment char. If that is a real problem, it would be possible to disable comments in a line with a definition but only accept lines with a '#' as first character as a comment. I don't think this limitation with whitechars at the beginning or end of the value is that grave that it is really necessary to adopt quoted strings. > and also any and any number of whitespaces between lines, keys, equal signs and > values. (lib/cfglib.?pp has troubles with this, even it does not recognize any > whitespace within a value) > - These whitespaces are "corrected" to default (one space) when saving the config. IIRC, my implementation handles this in a similar way as yours. > In some ways this config lib might be more strict than the "old" ones: for > example is > str = foo bar > wrong since the string was not embedded into double quotes although it contains > whitespaces. > > What's your opinion? Shall we use it for craft? Code as attachment. Sorry, but the only _real_ advantage I see, is the speed. But (at least now) I don't think speed is that important, since the configurations are very small and are typically parsed once in a not really speed critical situation. I can't imagine, that a change of the configuration library would speed up craft radically. cya arne |
From: Martin W. <meh...@we...> - 2004-08-14 15:13:16
|
Hey, just forgotten: WB, arne ;) Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-14 15:08:31
|
Hey, Arne, Arne Rempke wrote: > Hi, > > I zipped all tiles into zipfiles. So there are no .bmp or .tiles files > in share/tiles. When I run make, I get > > make[2]: *** Keine Regel vorhanden, um das Target »tiles/*.bmp«, > benötigt von »all-am«, zu erstellen. Schluss. > > (which means, that there is no rule for the target "tiles/*.bmp", which > is needed by "all-am", and so it aborts). > > Did I forget to run an automake/-conf/...? Or is it just not possible to > have no such files in share/tiles and such an entry in > share/Makefile.am? If I unzip an archive, so that I have a bmp and a > tile, make does everything without repining. This is a problem which I have encountered, too. It's because you have a target for *.bmp files but no *.bmp files in your directory. I do not know how to tell automake or make that if no *.bmp files exist it is also ok. Just silly behavior ... Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |