Bug: UUID nilUUID -> de6309fd-188f-0643-9c90-0edb825f2f46 UUID nilUUID isNilUUID -> false Fixed: UUID nilUUID -> 00000000-0000-0000-0000-000000000000 UUID nilUUID isNilUUID -> true
class UUID, original method:
nilUUID ^self new: 16
class UUID, fixed method:
nilUUID ^self basicNew: 16
Well that sets off all sorts of alarm bell since in my 3.7a image 5707
I get
UUID nilUUID printString '00000000-0000-0000-0000-000000000000'
because
UUID(class) -> nilUUID ^self new: 16
where UUID is defined as
ByteArray variableByteSubclass: #UUID instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Network-UUID'
Now ByteArray new: which inherits from Behavior returns a zeroed byte array. Unless someone has decided to change things so that ByteArrays aren't initialized to zero then you'll need to look deeper why you don't get a proper nil UUID
On Jun 28, 2004, at 1:45 AM, Pavel Křivánek wrote:
Bug: UUID nilUUID -> de6309fd-188f-0643-9c90-0edb825f2f46 UUID nilUUID isNilUUID -> false Fixed: UUID nilUUID -> 00000000-0000-0000-0000-000000000000 UUID nilUUID isNilUUID -> true
class UUID, original method:
nilUUID ^self new: 16
class UUID, fixed method:
nilUUID ^self basicNew: 16
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
The answer is
Behavior>>new "Answer a new initialized instance of the receiver (which is a class) with no indexable variables. Fail if the class is indexable."
^ self basicNew initialize
- A.
----- Original Message ----- From: "John M McIntosh" johnmci@smalltalkconsulting.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, June 28, 2004 3:10 PM Subject: Re: [BUG] [FIX] nilUUID in Squeak 3.7 beta 5963
Well that sets off all sorts of alarm bell since in my 3.7a image 5707
I get
UUID nilUUID printString '00000000-0000-0000-0000-000000000000'
because
UUID(class) -> nilUUID ^self new: 16
where UUID is defined as
ByteArray variableByteSubclass: #UUID instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Network-UUID'
Now ByteArray new: which inherits from Behavior returns a zeroed byte array. Unless someone has decided to change things so that ByteArrays aren't initialized to zero then you'll need to look deeper why you don't get a proper nil UUID
On Jun 28, 2004, at 1:45 AM, Pavel Křivánek wrote:
Bug: UUID nilUUID -> de6309fd-188f-0643-9c90-0edb825f2f46 UUID nilUUID isNilUUID -> false Fixed: UUID nilUUID -> 00000000-0000-0000-0000-000000000000 UUID nilUUID isNilUUID -> true
class UUID, original method:
nilUUID ^self new: 16
class UUID, fixed method:
nilUUID ^self basicNew: 16
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Sure but that was a result of this change set, serves me right for grabbing a handy older image...
"Change Set: KCPFIX initializenew: Date: 20 May 2004 Author: stéphane ducasse
make sure that new: also invoke initialize. Note that for speed gain we could in the future shortcut this call on String, Array, ByteArray...."
and I'll note this caused two UUID SUnit tests to fail, a key positive result of having the SUnit test there Mind I'll wonder why this wasn't discovered until today....
On Jun 28, 2004, at 3:14 PM, Andreas Raab wrote:
The answer is
Behavior>>new "Answer a new initialized instance of the receiver (which is a class) with no indexable variables. Fail if the class is indexable."
^ self basicNew initialize
- A.
----- Original Message ----- From: "John M McIntosh" johnmci@smalltalkconsulting.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, June 28, 2004 3:10 PM Subject: Re: [BUG] [FIX] nilUUID in Squeak 3.7 beta 5963
Well that sets off all sorts of alarm bell since in my 3.7a image 5707
I get
UUID nilUUID printString '00000000-0000-0000-0000-000000000000'
because
UUID(class) -> nilUUID ^self new: 16
where UUID is defined as
ByteArray variableByteSubclass: #UUID instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Network-UUID'
Now ByteArray new: which inherits from Behavior returns a zeroed byte array. Unless someone has decided to change things so that ByteArrays aren't initialized to zero then you'll need to look deeper why you don't get a proper nil UUID
On Jun 28, 2004, at 1:45 AM, Pavel Křivánek wrote:
Bug: UUID nilUUID -> de6309fd-188f-0643-9c90-0edb825f2f46 UUID nilUUID isNilUUID -> false Fixed: UUID nilUUID -> 00000000-0000-0000-0000-000000000000 UUID nilUUID isNilUUID -> true
class UUID, original method:
nilUUID ^self new: 16
class UUID, fixed method:
nilUUID ^self basicNew: 16
--
=
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================= = ===
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
I wonder what it is that Ned does that breaks Safari rule parsing :)
On Jun 28, 2004, at 4:14 PM, ned@squeakland.org wrote:
<nilUUIDFix-pk.cs.gz>
On Monday, June 28, 2004, at 07:34 PM, Steven Riggins wrote:
I wonder what it is that Ned does that breaks Safari rule parsing :)
It's because his reply was through the BFAV tool in Squeak. I've noticed that any BFAV posts to squeak-dev don't make it through Apple Mail rule parsing either... I haven't looked into it too closely but it may be because those posts have multiple "To:" headers, whereas typically you have multiple addresses separated by commas in a single "To:" header.
I don't know if this is actually the problem, and whether it's the fault of BFAV or the Squeak email sender.
- Doug
On Jun 28, 2004, at 4:14 PM, ned@squeakland.org wrote:
<nilUUIDFix-pk.cs.gz>
On Monday 28 June 2004 8:57 pm, Doug Way wrote:
On Monday, June 28, 2004, at 07:34 PM, Steven Riggins wrote:
I wonder what it is that Ned does that breaks Safari rule parsing :)
It's because his reply was through the BFAV tool in Squeak. I've noticed that any BFAV posts to squeak-dev don't make it through Apple Mail rule parsing either... I haven't looked into it too closely but it may be because those posts have multiple "To:" headers, whereas typically you have multiple addresses separated by commas in a single "To:" header.
I don't know if this is actually the problem, and whether it's the fault of BFAV or the Squeak email sender.
I don't know, though RFC-822 appears to explicitly allow it (note that there don't seem to be any more notes about this in the standard). Also, apparently some older versions of sendmail would break if you fed them a header that was more than about 1K in length. I think this is a case where MUAs MUST accept (and coalesce, of course) all To: headers. Of course, there are some headers that must be unique (From: comes to mind).
I think if Safari doesn't do the right thing, it's a Safari bug.
This doesn't mean that the BFAV shouldn't be fixed, though.
4.1. SYNTAX
Header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers. It is recommended that, if present, headers be sent in the order "Return-Path", "Received", "Date", "From", "Subject", "Sender", "To", "cc", etc.
This specification permits multiple occurrences of most fields. Except as noted, their interpretation is not specified here, and their use is discouraged.
message = fields *( CRLF *text ) ; Everything after ; first null line ; is message body
fields = dates ; Creation time, source ; author id & one 1*destination ; address required *optional-field ; others optional
destination = "To" ":" 1#address ; Primary / "Resent-To" ":" 1#address / "cc" ":" 1#address ; Secondary / "Resent-cc" ":" 1#address / "bcc" ":" #address ; Blind carbon / "Resent-bcc" ":" #address
4.5.1. TO / RESENT-TO
This field contains the identity of the primary recipients of the message.
On Monday 28 June 2004 9:27 pm, I wrote:
I don't know if this is actually the problem, and whether it's the fault of BFAV or the Squeak email sender.
I don't know, though RFC-822 appears to explicitly allow it
And apparently this was fixed in RFC-2822, which says that the maximum number of each kind of various fields is 1:
The following table indicates limits on the number of times each field may occur in a message header as well as any special limitations on the use of those fields. An asterisk next to a value in the minimum or maximum column indicates that a special restriction appears in the Notes column.
Field Min number Max number Notes
from 1 1 See sender and 3.6.2 sender 0* 1 MUST occur with multi-address from - see 3.6.2 reply-to 0 1 to 0 1 cc 0 1 bcc 0 1 message-id 0* 1 SHOULD be present - see 3.6.4 in-reply-to 0* 1 SHOULD occur in some replies - see 3.6.4 references 0* 1 SHOULD occur in some replies - see 3.6.4 subject 0 1
"Ned Konz" 06/29/04 05:40 >>>
On Monday 28 June 2004 9:27 pm, I wrote:
I don't know if this is actually the problem, and whether it's the fault of BFAV or the Squeak email sender.
I don't know, though RFC-822 appears to explicitly allow it
And apparently this was fixed in RFC-2822, which says that the maximum number of each kind of various fields is 1:
The following table indicates limits on the number of times each field may occur in a message header as well as any special limitations on the use of those fields. An asterisk next to a value in the minimum or maximum column indicates that a special restriction appears in the Notes column.
Field Min number Max number Notes
from 1 1 See sender and 3.6.2 sender 0* 1 MUST occur with multi-address from - see 3.6.2 reply-to 0 1 to 0 1 cc 0 1 bcc 0 1 message-id 0* 1 SHOULD be present - see 3.6.4 in-reply-to 0* 1 SHOULD occur in some replies - see 3.6.4 references 0* 1 SHOULD occur in some replies - see 3.6.4 subject 0 1
Which means that MailMessage should ensure there's only one To header (and so on), surely? So if you wanted to send a MailMessage to foo, bar and baz, I'd imagine we'd want to do something like
mailmsg addRecipient: 'foo'; addRecipient: 'bar'; addRecipient: 'baz'
or
mailmsg addRecipients: #('foo' 'bar' 'baz').
frank
On Tuesday 29 June 2004 6:08 am, Frank Shearar wrote:
Which means that MailMessage should ensure there's only one To header (and so on), surely? So if you wanted to send a MailMessage to foo, bar and baz, I'd imagine we'd want to do something like
mailmsg addRecipient: 'foo'; addRecipient: 'bar'; addRecipient: 'baz'
or
mailmsg addRecipients: #('foo' 'bar' 'baz').
I think that's right. And it should result in a single To: line.
"Ned Konz" 06/29/04 14:15 >>>
On Tuesday 29 June 2004 6:08 am, Frank Shearar wrote:
Which means that MailMessage should ensure there's only one
To header (and
so on), surely? So if you wanted to send a MailMessage to
foo, bar and baz,
I'd imagine we'd want to do something like
- mailmsg addRecipient: 'foo'; addRecipient: 'bar';
addRecipient: 'baz'
or
- mailmsg addRecipients: #('foo' 'bar' 'baz').
I think that's right. And it should result in a single To: line.
Cool. I'll whip something up quickly and submit it as a ChangeSet.
frank
On Monday 28 June 2004 9:27 pm, I wrote:
I think if Safari doesn't do the right thing, it's a Safari bug.
Also from RFC-2822:
When multiple occurrences of destination address fields occur in a message, they SHOULD be treated as if the address-list in the first occurrence of the field is combined with the address lists of the subsequent occurrences by adding a comma and concatenating.
I've reposted under a different subject to start a new thread on BFAV.
On Mon, 28 Jun 2004 23:57:59 -0400, Doug Way wrote
On Monday, June 28, 2004, at 07:34 PM, Steven Riggins wrote:
I wonder what it is that Ned does that breaks Safari rule parsing :)
It's because his reply was through the BFAV tool in Squeak. I've noticed that any BFAV posts to squeak-dev don't make it through Apple Mail rule parsing either... I haven't looked into it too closely but it may be because those posts have multiple "To:" headers, whereas typically you have multiple addresses separated by commas in a single "To:" header.
I don't know if this is actually the problem, and whether it's the fault of BFAV or the Squeak email sender.
Eeek! According to RFC 2821 section 3.6-ish, To, Cc and Bcc headers may occur at most once. I'll see if I can get BFAV to send the To headers as a comma-separated list today lunchtime-ish (in +0100 time).
frank
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Doug Way -
Frank Shearar -
Frank Shearar -
frank.shearar＠rnid.org.uk
-
John M McIntosh -
Ned Konz -
ned＠squeakland.org -
Pavel Křivánek -
Steven Riggins