Contestcen@aol.com wrote:
Not again please!!! Peter himself made it explicitly clear that he asked for runtime storage (which was clear to all of us except you from the beginning).
I suggested the macros once, at the very beginning of this thread. As soon as it became clear that he wanted run-time macros, I made suggestions for that case. I never again suggested the static solution. However, it keeps coming up because people keep claiming that I am off the topic.
Are you lying intentionally, or don't you even know what you wrote? Below are several mails of yours that all talk about static storage, as late as two weeks after the initial question. Note that in the last and 4th-last of these quoted excerpts, you actively try to bring the subject "back" to static storage.
Actually, these mails mention the "Pascal Macro Compiler" so often, even after it was clear (as you say) it's off-topic, it's close to spamming!
Sure, some of these mails are to answer questions and criticism by others, but if it really was clear to you it was off-topic, you could have said: "Sorry, I misunderstood the question. The Pascal Macro Compiler is not useful for this purpose.", instead of carrying on a pointless discussion and annoying everybody.
: Date: Thu, 7 Jul 2005 02:46:38 EDT : The Pascal Macro Compiler has a set of macros that will pack character : strings without any wasted space between them The macros can be downloaded directly : from the webpage http://www.contestcen.com/paskey.htm which has both the : source code and a detailed description.
: Date: Fri, 8 Jul 2005 02:51:10 EDT : I assumed that the strings were being stored at runtime because storing them : end-to-end at compile time was too tedious. If there is a static set of : strings, then the Pascal Macro Compiler can store them without any wasted space.
: Date: Mon, 11 Jul 2005 13:37:35 EDT : Conclusion: If the strings are known at compile time, the most efficient way : to store them without gaps is to use the Pascal Macro Compiler.
: Date: Wed, 13 Jul 2005 02:57:37 EDT : Whether you choose to align the length field on an integer-size boundary or : not is a decision you could make based on a time versus space trade-off. The : macros that I have written happen to store the strings with no gaps at all, and : do not do any alignment. If you decided that for your application and : platform aligning the strings was better, then you would not use my macros, you : would write your own macros, or modify my macros to align the strings. The Pascal : Macro Compiler is a general-purpose preprocessor, and can align or not align : as the user wishes.
: Date: Wed, 13 Jul 2005 03:07:05 EDT : Using the Pascal Macro Compiler you can store the strings with no gaps and no : wasted space whatsoever. I don't see how you can improve on that. : Moreover, the method requires no code, makes no calls, and takes no time at : run time. I don't see how you can improve on that.
: Date: Thu, 14 Jul 2005 02:07:45 EDT : This may be true for executable code generated by the Pascal Macro Compiler, : but it is not true for the data declarations that are generated for the packed : strings. There is no executable code involved, so the compiler has nothing : to optimize. : There is no wasted space, so there is nothing that can be improved.
: Date: Thu, 14 Jul 2005 03:18:40 EDT : The prologue of these macros says, "This version is intended mainly as a : demonstration." It is an example designed to illustrate some of the features and : capabilities of the Pascal Macro Compiler. Users who do not need alignment : can use the macros as provided. Users who need alignment can easily add that : feature to the macros. : If there are any requests from bona fide users of the Pascal Macro Compiler : for an alignment feature, then I will be glad to add it.
: Date: Sun, 17 Jul 2005 02:16:49 EDT : That's very nice. However, please recall that I said the main reason for : using a character array instead of a string is because I needed more than 255 : characters. So, having a better way to initialize a character array of up to 255 : characters doesn't help me. If I only wanted 255 characters I would have : used a string in the first place.
: Date: Mon, 18 Jul 2005 02:13:55 EDT : My understanding from the original post is that he wanted the strings stored : as given, not compressed. The macros simply store the strings end-to-end : without any gaps. However, the macros would work equally for compressed strings, : assuming they have the same form, namely length field and data string. : If you want the entire body of strings compressed as a unit, then you could : use the macros to create the concatenation of all the individual strings, and : compress the result. It would be up to you to devise methods for accessing the : strings within the compressed mass.
: Date: Tue, 19 Jul 2005 02:47:42 EDT : In any case, we are getting off the subject, which was how to store a set of : varying-length strings with minimal wasted space. The method that I : suggested, using the Pascal Macro Compiler, uses no wasted space at all.
: Date: Tue, 19 Jul 2005 03:12:02 EDT : The Pascal Macro Compiler could certainly generate code for accessing the : strings, however the Keyword String macros do not generate access code; they : generate data structures.
: Date: Thu, 21 Jul 2005 00:55:11 EDT : If you need to initialize a character array greater than 255 chars in BP, you : can resort to using absolute.
: Date: Thu, 21 Jul 2005 16:23:31 EDT : The subject of this thread in the GPC mailing list is how to store : character strings without wasted space. Notive that the subject of this thread is : "Packing strings ()" That was the subject of the original posting that : started the thread. : I have mentioned the Pascal Macro Compiler because it comes with macros : that have the ability to pack strings without wasted space. That is the : original question, and this is an appropriate answer to the question. I have not : discussed the Pascal Macro Compiler in any other context except to answer the : question in this thread.
My answer about compile-time storage was long ago. This thread has moved beyond that into other aspects of storage management and data access. I have since suggested allocating storage as a set of extension blocks, and as a single block that gets copied when it overflows. I have moved on from compile-time storage.
See above. Your mails speak a different language.
So let me remind you of another topic that got raised, namely perfect hashing. You suggested the use of gperf, a program which I read about many years ago, but had forgotten. The reason I ignored gperf is that I think it can work only for very easy sets of keywords, and it will fail badly for hard sets, even if they are fairly small. I proposed that you and I test gperf on some harder keyword sets. Are you willing to try this?
There's one thing you're really good at -- causing other people work. First you make us explain you how email works and basic netiquette rules again and again and again, now you want *us* to test gperf. Can't you do it yourself? Create those data sets you're concerned with, produce gperf output, look at applicable gperf options, and comment on the results, perhaps comparing them with other programs, then present us your results. As this is a bit off-topic on this list, better put them on your web site and post a pointer to the site here.
Really not. Unfortunately, the main archives are still offline (but you might be able to find mirrors through Google). There you'll see that few, if anyone, had so many initial problems. Some did an HTML posting or strange quoting in their initial mail, but after a friendly reminder, they changed it. You're probably the first one who seems to need a majority vote of all list subscribers to convince you (would 2/3 of all who ever posted to the list be enough for you, counting abstentions as negative votes? ;-), and constantly ignores all pointers to standard netiquette (including numerous ones in private mail, I must add).
I am not trying to ignore or flout the requests for non-HTML postings. In fact, I have gone to a good deal of effort to try to find ways of minimizing or eliminating the HTML in my postings.
The net result is that I have been unable to find any control that will turn off the HTML,
So, if you apparently realized by now that non-HTML mail is common practice, and your can't find a way to do this simple thing in your mailer, what does this tell you about your mailer? Either it's crap or it's poorly documented so even basic settings are hard to find. (You did read the documentation, didn't you?)
and I have not yet found another mailer that has that ability. None of the people who have been corresponding with me offline have been able to tell me what mailer could work.
What twisted form of argument is this? After people online (such as Emil Jerabek and me) have repeatedly pointed you to alternatives, your excuse now is that people you correspond with *offline* don't know better answers!? (Perhaps that's why they correspond offline. ;-) What's next? If some of them happens to send you a postcard naming another mailer, are you going to claim your cat and dog couldn't tell you one???
I don't know the features of other mailers, and the descriptions I have seen on the Internet never mention an HTML-free option.
Perhaps because it's so obvious they don't bother to mention? When you're buying a car, do you only look at advertisements that point out that is has several wheels and an engine???
To repeat, plain text mail is the default. MIME is an EXTENSION (the E in MIME really stands for extensions!) to encode other formats into plain text. So every mailer that sends MIME must ultimately be able to send plain text mails. And all except perhaps a few extremely perverse ones don't hide this fact from the user.
Frank