From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: struct.el -- a package to encode/decode binary data Date: 19 Mar 2002 15:34:25 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xadt4d3ta.fsf@kfs2.cua.dk> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016548597 4708 127.0.0.1 (19 Mar 2002 14:36:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 14:36:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16nKj6-0001Dq-00 for ; Tue, 19 Mar 2002 15:36:36 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16nKoQ-0006f7-00 for ; Tue, 19 Mar 2002 15:42:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16nKio-0006sA-00; Tue, 19 Mar 2002 09:36:18 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16nKg4-0006Mq-00 for ; Tue, 19 Mar 2002 09:33:28 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id D63C77C035; Tue, 19 Mar 2002 14:33:26 +0000 (GMT) Original-To: Eli Zaretskii In-Reply-To: Original-Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2041 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2041 Eli Zaretskii writes: > [I think we should conduct this discussion on emacs-devel: it might be > useful for others.] I've CC:ed the list. > > On 19 Mar 2002, Kim F. Storm wrote: > > > I used string-make-unibyte because I was having a great many > > difficulties with "struct-pack" generating what seems to be a bogus > > string, i.e. if I used `length' on the result, it didn't even have the > > expected length. So it didn't DTRT for me in this case. > > You would have to show fragments of Lisp for me to see what could be the > problem. > > > I did manage to control that via the current buffer's coding system, > > but that seemed to make pretty random results, depending on what > > buffer I happened to eval the function in (e.g. my source buffer > > vs. *scratch* vs. a process buffer). > > This seems to indicate that you forced Emacs to convert from unibyte to > multibyte and back. When you do that, it uses the current defaults to > guess what you mean as TRT. That's why I said we shouldn't stress this > ad-hoc'ery too much--it's too fragile. The problem probably was that I took some binary data from one buffer, put it into a (multibyte) string, and then tried to unpack that string in another buffer. It didn't work - probably because those buffers had different coding systems. Since I really wanted this to work on binary, byte-oriented data, I thought unibyte would be the correct mantra for me to use (and it does work for this purpose). > > > So I probably just have to warn users that this package will only work > > on binary data if the current buffer's coding system is raw-text-unix. > > I don't understand this--when you read binary data, what other decoding > can you possibly use in the buffer into which the data is read? True. It just puzzles me why I always seem to run into problems when emacs DTRT with this coding stuff. It *was* easier in the old days, and my mind probably just can't cope with this "new" coding stuff :-) > Why > should users bother about what kind of buffer are you using behind the > scenes to convert binary garbage into human-readable description? What > am I missing? In this scope, the `users' I was talking about are really `programmers'. So `real users' definitely shouldn't bother -- and they will probably be unaware of the existence of the struct.el package too. > > > To me it would make sense to have a coding system named `binary' which > > would work across all platforms. > > `binary' _does_ work this way. My problem was not with the coding system > you used, it was with the fact that you used unibyte strings. That's a > different issue. > > > Besides setting the buffer's coding system, is there some other way to > > ensure that I'll always *use* a coding system which ensures that > > `(substring ... 4 5)' really does only take one *byte* from the > > string? > > `substring' is a string operation. Your data is not text, so you > should avoid string operations, I think. Again, it's hard to give > specific advice without a specific example. In general, functions like > char-after are much better. My code is typically used in a network process filter, and in that scope, the received (binary) data is delivered in a string, so yes, my data isn't text, but it stored in a string... In any case, I'll follow your advice and rely on using the proper coding systems for the buffers and processes involved (and keep my fingers crossed :-). -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel