Squeak-dev May 2014

squeak-dev@lists.squeakfoundation.org

43 participants
219 discussions

Daily Commit Log
by commits＠source.squeak.org 28 May '14

28 May '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-May/007062.html Name: TraitsTests-nice.14 Ancestors: TraitsTests-fbs.13 Some Traits test do timeout. Relax the constraints. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-May/007063.html Name: Kernel-eem.854 Ancestors: Kernel-nice.853 Fix the regression caused by Kernel-eem.847. Instead of installing teh correct binding in compileAllFrom: add behavior>>updateMethodBindingsTo: and invoke it from ClassBuilder>>update:to:. This restores the failing PureBehaviorTests>>testReshapeClass. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-May/007064.html Name: Files-eem.136 Ancestors: Files-eem.135 Fix the regression introduced in Files-eem.133 by implementing peekLast more directly. Add a lastWritten inst var to StandardFileStream. Change the definition of isBinary so that e.g. WideString could be used as a buffer1 and the file is still considered not binary. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-May/007065.html Name: Collections-eem.571 Ancestors: Collections-nice.570 Speed up testing different sized strings for equality by adding a size text to String>>#=. Tis speeds up e.g. comparing the first 10,000 ByteString instances to each other by -67%. =============================================

1 0

OS/2 Smalltalks
by blake 27 May '14

27 May '14

Cleaning out the garage I came across copies of Digitalk's, IBM's and (I think) ParcPlace's Smalltalks for OS/2. If there's any interest in these dinosaurs, let me know, else they will be recycled.... ===Blake===

1 0

The Trunk: Collections-eem.571.mcz
by commits＠source.squeak.org 27 May '14

27 May '14

Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.571.mcz ==================== Summary ==================== Name: Collections-eem.571 Author: eem Time: 27 May 2014, 11:49:16.946 am UUID: 5610c761-96af-422f-bb1d-63bc87a1cc7a Ancestors: Collections-nice.570 Speed up testing different sized strings for equality by adding a size text to String>>#=. Tis speeds up e.g. comparing the first 10,000 ByteString instances to each other by -67%. =============== Diff against Collections-nice.570 =============== Item was changed: ----- Method: String>>= (in category 'comparing') ----- = aString "Answer whether the receiver sorts equally as aString. The collation order is simple ascii (with case differences)." + (aString isString + and: [self size = aString size]) ifFalse: [^ false]. - aString isString ifFalse: [ ^ false ]. ^ (self compare: self with: aString collated: AsciiOrder) = 2!

1 0

The Trunk: Files-eem.136.mcz
by commits＠source.squeak.org 27 May '14

27 May '14

Eliot Miranda uploaded a new version of Files to project The Trunk: http://source.squeak.org/trunk/Files-eem.136.mcz ==================== Summary ==================== Name: Files-eem.136 Author: eem Time: 27 May 2014, 11:47:15.952 am UUID: 83fc1540-4b6b-4ff7-b18d-e864e9e7fb16 Ancestors: Files-eem.135 Fix the regression introduced in Files-eem.133 by implementing peekLast more directly. Add a lastWritten inst var to StandardFileStream. Change the definition of isBinary so that e.g. WideString could be used as a buffer1 and the file is still considered not binary. =============== Diff against Files-eem.135 =============== Item was changed: FileStream subclass: #StandardFileStream + instanceVariableNames: 'name fileID buffer1 lastWritten' - instanceVariableNames: 'name fileID buffer1' classVariableNames: 'Registry' poolDictionaries: '' category: 'Files-Kernel'! !StandardFileStream commentStamp: 'ul 12/6/2009 05:13' prior: 0! Provides a simple, platform-independent, interface to a file system. The instance variable rwmode, inherited from class PositionableStream, here is used to hold a Boolean -- true means opened for read-write, false means opened for read-only. 2/12/96 sw I implement a simple read buffering scheme with the variables defined in PositionableStream (which are unused in me otherwise) in the following way: collection <ByteString> or <ByteArray> This is the buffer. position <Integer> The relative position in the buffer. Greater or equal to zero. readLimit <Integer> The number of bytes buffered. Greater or equal to zero. Read buffering is enabled with #enableReadBuffering, disabled with #disableReadBuffering and it is enabled by default. The buffer is filled when a read attempt of an unbuffered absolute position is requested, or when a negative repositioning is made (with #position: with an argument < than the current absolute position) to an absolute position which is not buffered. In the first case, the buffer is positioned to the given absolute position. In the latter case the repositioning is made to the requested absolute position minus fourth of the buffer size. This means that further small negative repositionings won't result in buffer flushing. This is really useful when filing in code. The read buffer is flushed (#flushReadBuffer) whenever a write attempt is made. The buffer state is valid if and only if collection is not nil and position < readLimit.! Item was changed: ----- Method: StandardFileStream>>ascii (in category 'properties-setting') ----- ascii "opposite of binary" + buffer1 := ByteString new: 1. + collection ifNotNil: [collection := collection asString]. + lastWritten ifNotNil: [lastWritten isInteger ifTrue: [lastWritten := lastWritten asCharacter]]! - buffer1 := String new: 1. - collection ifNotNil: [ collection := collection asString ]! Item was changed: ----- Method: StandardFileStream>>binary (in category 'properties-setting') ----- binary buffer1 := ByteArray new: 1. + collection ifNotNil: [collection := collection asByteArray]. + lastWritten ifNotNil: [lastWritten isCharacter ifTrue: [lastWritten := lastWritten asInteger]]! - collection ifNotNil: [ collection := collection asByteArray ]! Item was changed: ----- Method: StandardFileStream>>isBinary (in category 'properties-setting') ----- isBinary + ^buffer1 isString not! - ^ buffer1 class == ByteArray! Item was changed: ----- Method: StandardFileStream>>nextPut: (in category 'read, write, position') ----- + nextPut: element + "Write the given element (character or integer) to this file." - nextPut: char - "Write the given character to this file." rwmode ifFalse: [^ self error: 'Cannot write a read-only file']. + collection ifNotNil: + [position < readLimit ifTrue: [ self flushReadBuffer ] ]. + buffer1 at: 1 put: element. - collection ifNotNil: [ - position < readLimit ifTrue: [ self flushReadBuffer ] ]. - buffer1 at: 1 put: char. self primWrite: fileID from: buffer1 startingAt: 1 count: 1. + lastWritten := element. + ^ element - ^ char ! Item was changed: ----- Method: StandardFileStream>>nextPutAll: (in category 'read, write, position') ----- + nextPutAll: aCollection + "Write all the elements of the given collection (a String or IntegerArray of some kind) to this file." - nextPutAll: aString - "Write all the characters of the given string to this file." | size | rwmode ifFalse: [^ self error: 'Cannot write a read-only file']. + collection ifNotNil: + [position < readLimit ifTrue: [ self flushReadBuffer]]. + (size := aCollection basicSize) > 0 ifTrue: + [self primWrite: fileID from: aCollection startingAt: 1 count: size. + lastWritten := aCollection at: size]. + ^ aCollection! - collection ifNotNil: [ - position < readLimit ifTrue: [ self flushReadBuffer ] ]. - (size := aString size) > 0 ifTrue: - [buffer1 - at: 1 - put: ((buffer1 at: 1) isCharacter - ifTrue: [(aString at: size) asCharacter] - ifFalse: [(aString at: size) asInteger]). - self primWrite: fileID from: aString startingAt: 1 count: aString basicSize]. - ^ aString - ! Item was changed: ----- Method: StandardFileStream>>peekLast (in category 'read, write, position') ----- peekLast + "Answer the item just put at the end of the stream, if any." - "Return that item just put at the end of the stream" + ^lastWritten! - ^ buffer1 size > 0 - ifTrue: [buffer1 last] - ifFalse: [nil] - !

1 0

Re: [squeak-dev] The Trunk: Kernel-eem.847.mcz
by Nicolas Cellier 27 May '14

27 May '14

2014-05-03 2:46 GMT+02:00 <commits(a)source.squeak.org>: > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-eem.847.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.847 > Author: eem > Time: 2 May 2014, 5:45:56.76 pm > UUID: 61cf122b-e7e3-4c10-9d8b-17df1509d656 > Ancestors: Kernel-eem.846 > > Fix class reshaping losing the correct methodClassAssociation > in instance side methods. > > =============== Diff against Kernel-eem.846 =============== > > Item was changed: > ----- Method: Behavior>>compileAllFrom: (in category 'compiling') ----- > compileAllFrom: oldClass > "Compile all the methods in the receiver's method dictionary. > This validates sourceCode and variable references and forces > all methods to use the current bytecode set" > + | envBinding binding | > - | binding | > "ar 7/10/1999: Use oldClass selectors not self selectors" > oldClass selectorsDo: [:sel | self recompile: sel from: oldClass]. > > "Ensure that we share a common binding after recompilation. > + This is so that ClassBuilder reshapes avoid creating new bindings > + for every method when recompiling a large class hierarchy. > + eem 5/2/2014 17:43: Further, if we're not yet in the environment > + (because we're about to be mutated into oldClass), use oldClass's > + binding, so as not to end up with the wrong binding post > recompile." > - This is so that ClassBuilder reshapes avoid creating new bindings > - for every method when recompiling a large class hierarchy." > binding := self binding. > + (self name = oldClass name > + and: [(envBinding := self environment bindingOf: self name) ~= > binding > + and: [envBinding = oldClass binding]]) ifTrue: > + [binding := envBinding]. > Hi Eliot, this is breaking Traits as shown by PureBehaviorTests>>testReshapeClass We must look into ClassBuilder>>newSubclassOf: newSuper type: type instanceVariables: instVars from: oldClass, After this instruction: [newClass compileAllFrom: oldClass] newClass methodDictionary has bindings that points to oldClass instead of newClass (the bindings are #C2 -> oldClass) Then what happens in newClass setTraitComposition: -> uses: -> installTraitsFrom: -> assembleTraitMethodsFrom: ??? The methods are not recognized as local methods (isLocalMethod:) because the binding points to the oldClass, not the newClass... As a consequence, the local methods #(foo bar) are not re-installed in newClass, but lost. What do you think? Should we revert this? Or hack isLocalMethod: to rely on name rather than identity? > self methodsDo:[:m| > m methodClassAssociation == binding > ifFalse:[m methodClassAssociation: binding]]. > ! > > >

2 1

The Trunk: Kernel-eem.854.mcz
by commits＠source.squeak.org 27 May '14

27 May '14

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.854.mcz ==================== Summary ==================== Name: Kernel-eem.854 Author: eem Time: 27 May 2014, 11:17:11.701 am UUID: 354e7db1-1a1c-426c-ae87-018e33f29c69 Ancestors: Kernel-nice.853 Fix the regression caused by Kernel-eem.847. Instead of installing teh correct binding in compileAllFrom: add behavior>>updateMethodBindingsTo: and invoke it from ClassBuilder>>update:to:. This restores the failing PureBehaviorTests>>testReshapeClass. =============== Diff against Kernel-nice.853 =============== Item was changed: ----- Method: Behavior>>compileAllFrom: (in category 'compiling') ----- compileAllFrom: oldClass "Compile all the methods in the receiver's method dictionary. + This validates sourceCode and variable references and forces + all methods to use the current bytecode set" + - This validates sourceCode and variable references and forces - all methods to use the current bytecode set" - | envBinding binding | "ar 7/10/1999: Use oldClass selectors not self selectors" + oldClass selectorsDo: [:sel | self recompile: sel from: oldClass]! - oldClass selectorsDo: [:sel | self recompile: sel from: oldClass]. - - "Ensure that we share a common binding after recompilation. - This is so that ClassBuilder reshapes avoid creating new bindings - for every method when recompiling a large class hierarchy. - eem 5/2/2014 17:43: Further, if we're not yet in the environment - (because we're about to be mutated into oldClass), use oldClass's - binding, so as not to end up with the wrong binding post recompile." - binding := self binding. - (self name = oldClass name - and: [(envBinding := self environment bindingOf: self name) ~= binding - and: [envBinding = oldClass binding]]) ifTrue: - [binding := envBinding]. - self methodsDo:[:m| - m methodClassAssociation == binding - ifFalse:[m methodClassAssociation: binding]]. - ! Item was changed: ----- Method: ClassBuilder>>update:to: (in category 'class mutation') ----- update: oldClass to: newClass "Convert oldClass, all its instances and possibly its meta class into newClass, instances of newClass and possibly its meta class. The process is surprisingly simple in its implementation and surprisingly complex in its nuances and potentially bad side effects. We can rely on two assumptions (which are critical): #1: The method #updateInstancesFrom: will not create any lasting pointers to 'old' instances ('old' is quote on quote since #updateInstancesFrom: will do a become of the old vs. the new instances and therefore it will not create pointers to *new* instances before the #become: which are *old* afterwards) #2: The non-preemptive execution of the critical piece of code guarantees that nobody can get a hold by 'other means' (such as process interruption and reflection) on the old instances. Given the above two, we know that after #updateInstancesFrom: there are no pointer to any old instances. After the forwarding become there will be no pointers to the old class or meta class either. Meaning that if we throw in a nice fat GC at the end of the critical block, everything will be gone (but see the comment right there). There's no need to worry. " | meta | meta := oldClass isMeta. "Note: Everything from here on will run without the ability to get interrupted to prevent any other process to create new instances of the old class." [ "Note: The following removal may look somewhat obscure and needs an explanation. When we mutate the class hierarchy we create new classes for any existing subclass. So it may look as if we don't have to remove the old class from its superclass. However, at the top of the hierarchy (the first class we reshape) that superclass itself is not newly created so therefore it will hold both the oldClass and newClass in its (obsolete or not) subclasses. Since the #become: below will transparently replace the pointers to oldClass with newClass the superclass would have newClass in its subclasses TWICE. With rather unclear effects if we consider that we may convert the meta-class hierarchy itself (which is derived from the non-meta class hierarchy). Due to this problem ALL classes are removed from their superclass just prior to converting them. Here, breaking the superclass/subclass invariant really doesn't matter since we will effectively remove the oldClass (become+GC) just a few lines below." oldClass superclass removeSubclass: oldClass. oldClass superclass removeObsoleteSubclass: oldClass. "make sure that the VM cache is clean" oldClass methodDict do: [:cm | cm flushCache]. "Convert the instances of oldClass into instances of newClass" newClass updateInstancesFrom: oldClass. meta + ifTrue: + [oldClass becomeForward: newClass. + oldClass updateMethodBindingsTo: oldClass binding] + ifFalse: + [{oldClass. oldClass class} elementsForwardIdentityTo: {newClass. newClass class}. + oldClass updateMethodBindingsTo: oldClass binding. + oldClass class updateMethodBindingsTo: oldClass class binding]. - ifTrue:[oldClass becomeForward: newClass] - ifFalse:[(Array with: oldClass with: oldClass class) - elementsForwardIdentityTo: - (Array with: newClass with: newClass class)]. Smalltalk garbageCollect. "Warning: Read this before you even think about removing the GC. Yes, it slows us down. Quite heavily if you have a large image. However, there's no good and simple alternative here, since unfortunately, #become: does change class pointers. What happens is that after the above become all of the instances of the old class will have a class pointer identifying them as instances of newClass. If we get our hands on any of these instances we will break immediately since their expected instance layout (that of its class, e.g., newClass) will not match their actual instance layout (that of oldClass). And getting your hands on any of those instances is really simple - just reshaping one class two times in rapid succession will do it. Reflection techniques, interrupts, etc. will only add to this problem. In the case of Metaclass things get even worse since when we recompile the entire class hierarchy we will recompile both, Metaclass and its instances (and some of its instances will have the old and some the new layout). The only easy solution to this problem would be to 'fix up' the class pointers of the old instances to point to the old class (using primitiveChangeClassTo:). But this won't work either - as we do a one-way become we would have to search the entire object memory for the oldClass and couldn't even clearly identify it unless we give it some 'special token' which sounds quite error-prone. If you really need to get rid of the GC here are some alternatives: On the image level, one could create a copy of the oldClass before becoming it into the new class and, after becoming it, 'fix up' the old instances. That would certainly work but it sounds quite complex, as we need to make sure we're not breaking any of the superclass/subclass meta/non-meta class variants. Alternatively, fix up #becomeForward on the VM-level to 'dump the source objects' of #become. This would be quite doable (just 'convert' them into a well known special class such as bitmap) yet it has problems if (accidentally or not) one of the objects in #become: appears on 'both sides of the fence' (right now, this will work ... in a way ... even though the consequences are unclear). Another alternative is to provide a dedicated primitive for this (instead of using it implicitly in become) which would allow us to dump all the existing instances right here. This is equivalent to a more general primitiveChangeClassTo: and might be worthwhile but it would likely have to keep in mind the differences between bits and pointer thingies etc. Since all of the alternatives seem rather complex and magical compared to a straight-forward GC it seems best to stick with the GC solution for now. If someone has a real need to fix this problem, that person will likely be motivated enough to check out the alternatives. Personally I'd probably go for #1 (copy the old class and remap the instances to it) since it's a solution that could be easily reverted from within the image if there's any problem with it." ] valueUnpreemptively. ! Item was added: + ----- Method: ClassDescription>>updateMethodBindingsTo: (in category 'initialize-release') ----- + updateMethodBindingsTo: aBinding + "ClassBuilder support for maintaining valid method bindings." + methodDict do: [:method| method methodClassAssociation: aBinding]!

1 0

Re: [Pharo-dev] String >> #=
by Marcus Denker 27 May '14

27 May '14

On 27 May 2014, at 09:44, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 27.05.14 06:45, Eliot Miranda wrote: >> >> >> >> >> Hi Phillipe, >> >> >> On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall >> <philippe.marschall(a)netcetera.ch >> <mailto:philippe.marschall@netcetera.ch>> wrote: >> >> Hi >> >> I have been investigating why Dictionary look up performance with >> String keys is not as good as I would expected. Something I noted is >> that String >> #= is implemented in terms of >> #compare:with:collated:. There is no short circuit if Strings are >> not the same size. In my case some Strings have the same prefix but >> a different length eg 'Content-Type' and 'Content-Length'. In that >> case a #compare:with:collated: is performed even though we know in >> advance the answer will be false because they have different sizes. >> >> >> Why not rewrite > > Yes, that would be my proposal as well. > Ok, I have added an issue: https://pharo.fogbugz.com/f/cases/13277/Speed-up-String Marcus

1 0

The Trunk: TraitsTests-nice.14.mcz
by commits＠source.squeak.org 27 May '14

27 May '14

Nicolas Cellier uploaded a new version of TraitsTests to project The Trunk: http://source.squeak.org/trunk/TraitsTests-nice.14.mcz ==================== Summary ==================== Name: TraitsTests-nice.14 Author: nice Time: 27 May 2014, 2:28:14.935 am UUID: 44c0f5be-a415-4f22-a8b6-856fd0bf7e79 Ancestors: TraitsTests-fbs.13 Some Traits test do timeout. Relax the constraints. =============== Diff against TraitsTests-fbs.13 =============== Item was changed: ----- Method: TraitCompositionTest>>testAliasCompositions (in category 'testing-basic') ----- testAliasCompositions + <timeout: 30> + "unary" - self shouldnt: [self t2 uses: self t1 @ { (#aliasM11 -> #m11) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#alias: -> #m11) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#alias:x:y: -> #m11) }] raise: TraitCompositionException. "binary" self t1 compile: '= anObject'. self shouldnt: [self t2 uses: self t1 @ { (#equals: -> #=) }] raise: TraitCompositionException. self shouldnt: [self t2 uses: self t1 @ { (#% -> #=) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#equals -> #=) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#equals:x: -> #=) }] raise: TraitCompositionException. "keyword" self t1 compile: 'x: a y: b z: c'. self should: [self t2 uses: self t1 @ { (#'==' -> #x:y:z:) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#x -> #x:y:z:) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#x: -> #x:y:z:) }] raise: TraitCompositionException. self should: [self t2 uses: self t1 @ { (#x:y: -> #x:y:z:) }] raise: TraitCompositionException. self shouldnt: [self t2 uses: self t1 @ { (#myX:y:z: -> #x:y:z:) }] raise: TraitCompositionException. "alias same as selector" self should: [self t2 uses: self t1 @ { (#m11 -> #m11) }] raise: TraitCompositionException. "same alias name used twice" self should: [self t2 uses: self t1 @ { (#alias -> #m11). (#alias -> #m12) }] raise: TraitCompositionException. "aliasing an alias" self should: [self t2 uses: self t1 @ { (#alias -> #m11). (#alias2 -> #alias) }] raise: TraitCompositionException! Item was changed: ----- Method: TraitMethodDescriptionTest>>testConflictMethodCreation (in category 'running') ----- testConflictMethodCreation "Generate conflicting methods between t1 and t2 and check the resulting method in Trait t5 (or c2). Also test selectors like foo:x (without space) or selectors with CRs." + <timeout: 30> + - "unary" - self t2 compile: 'm12 ^false'. self assert: ((self t5 sourceCodeAt: #m12) asString beginsWith: 'm12'). self should: [self c2 new m12] raise: Error. "binary" self t1 compile: '@ myArgument ^true'. self t2 compile: '@myArgument ^false'. self assert: ((self t5 sourceCodeAt: #@) asString beginsWith: '@ arg1'). self should: [self c2 new @ 17] raise: Error. "keyword" self t1 compile: 'zork: myArgument ^true'. self t2 compile: 'zork: myArgument ^false'. self assert: ((self t5 sourceCodeAt: #zork:) asString beginsWith: 'zork: arg1'). self should: [self c2 new zork: 17] raise: Error. self t1 compile: 'zork:myArgument ^true'. self t2 compile: 'zork:myArgument ^false'. self assert: ((self t5 sourceCodeAt: #zork:) asString beginsWith: 'zork: arg1'). self should: [self c2 new zork: 17] raise: Error. self t1 compile: 'zork1: myArgument zork2: mySecondArgument ^true'. self t2 compile: 'zork1: anObject zork2: anotherObject ^false'. self assert: ((self t5 sourceCodeAt: #zork1:zork2:) asString beginsWith: 'zork1: arg1 zork2: arg2'). self should: [self c2 new zork1: 1 zork2: 2] raise: Error!

1 0

Daily Commit Log
by commits＠source.squeak.org 27 May '14

27 May '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-May/007061.html Name: Tests-nice.298 Ancestors: Tests-nice.297 Fix MCEnvironmentLoadTest 1) its environment failed to import itself, thus #bindingOf: failed to find #MCMockClassA, making testLoadIntoEnvironment fail (fixed in setUp) 2) its environment failed to import binding of #MCMockAPoolDictionary, and this was triggering a UI action - not good for automated tests (fixed in setUp) 3) the imported classes where not deleted, making further MCPackageTest testUnload fail (fixed in tearDown) =============================================

1 0

re: Please use new threads for new threads.
by Chris Muller 27 May '14

27 May '14

Hi Craig, one solution to your question (below). Also, a counterpart rule to "Please use new threads for new threads" is, "Please don't start new threads for the same thread". :-) e.g., by changing the subject twice there are now three separate "threads" which are really the same thread. (see screenshot) (As an experiment, I've composed this "reply" anew, but C&P'd the subject-line from Craigs last post because I want to see whether Gmail renders this as a new thread or whether it collates it by the subject line). > Short: Yeesh, I'm deleting this thread for sure. :) > > Long: > > This matters to me, because I want to be informed while having > limited time to spend. > > Naturally, I wondered how I might fix this myself, leaving the > delicate sensibilities of my fellow raconteurs untrodden. I'm not sure > what fix would work. A separate Gmail account dedicated to mailing-list reading and responding. It lets the tail wag the dog and still presents threads collated by subject-line.. > Sometimes a reply has nothing to do with the > message to which the responder is replying, and the subject line is > totally different. Sometimes a reply is actually a response, and the > subject line might be the same ("hyperbole is great!"), somewhat > different ("perhaps communication is better [was: 'hyperbole is > great!']"), or totally different. Using simple message ID references and > the conventions of normal conversation, without turning it into an AI > project, seems the best we can manage. I totally agree, in principle! If there's a graph of message id's, the mail clients ought to make use of it over Stringy matching! Just like I wish Eliot and Bert would use the graph of ancestry in Monticello rather than stringy name matching for "branches".. :)

2 2

← Newer
1
2
3
4
5
6
7
8
...
22
Older →

Jump to page: