What is the difference between the second and third 'make runtest' ?
There doesn't seem to be any except for the results. It seems to be implied that both are for HEAD+patch and that just doing 'make runtest' a second time the results wrong, implying some leakage between session through the file system ?
Note: With the TIP about to be defeated I am putting this on the back-burner. Better spending time understanding dgp's analysis, and drawing up something which addresses the problems he has with the original TIP. Should that be able to reuse code from here, unclear right now, then the problem will have to be investigated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They are just two separate runs of the
same program. The intent is to demonstrate
that the patched HEAD has varying behavior
depending on the order of differing case
attempts.
I haven't dug deeper to see why, or whether
this is a general flaw or one limited to
the particular Tcltest/tcltest example. Just
reporting the empirical discovery.
If/when you get back to this, I'd be curious
if you're unable to duplicate it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah. Now I see it, thank you. Order of the exact names used ... Interesting. Yes, that is likely a flaw in some of the modified search code.
For now I have printed your comments, the one from late yesterday and today's, and will think about them. I should note that even with the ensemble porposal not fully handling all packages, i.e. C-level calls not intercepted and known, it should be possible to use this type of wrapping for basic experimentation with various possibilities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TIP 339 implementation on the 8.6/HEAD branch. Diff -u. Updated 'tm' unknown handler
TIP 339 implementation on the 8.5 branch. Diff -u. Updated 'tm' unknown handler
First implementations now available for 8.5 and 8.6 branches.
Missing: Need additional test cases to show the case-insensitivity.
Tried a little bit of testing to see how
the patches behave in the presence of
name conflicts. In the 8.6a3 release:
$ make runtest
...
% package require Tcltest
8.6a3
% package require tcltest
2.3.0
That's the baseline for how things
used to work. Now in HEAD + this patch:
$ make runtest
...
% package require tcltest
2.3.0
% package require Tcltest
2.3.0
Ok, that seems to be what I would expect.
However...
$ make runtest
...
% package require Tcltest
can't find package Tcltest
% package require tcltest
can't find package tcltest
Something seems wrong with the implementation.
What is the difference between the second and third 'make runtest' ?
There doesn't seem to be any except for the results. It seems to be implied that both are for HEAD+patch and that just doing 'make runtest' a second time the results wrong, implying some leakage between session through the file system ?
Note: With the TIP about to be defeated I am putting this on the back-burner. Better spending time understanding dgp's analysis, and drawing up something which addresses the problems he has with the original TIP. Should that be able to reuse code from here, unclear right now, then the problem will have to be investigated.
They are just two separate runs of the
same program. The intent is to demonstrate
that the patched HEAD has varying behavior
depending on the order of differing case
attempts.
I haven't dug deeper to see why, or whether
this is a general flaw or one limited to
the particular Tcltest/tcltest example. Just
reporting the empirical discovery.
If/when you get back to this, I'd be curious
if you're unable to duplicate it.
Ah. Now I see it, thank you. Order of the exact names used ... Interesting. Yes, that is likely a flaw in some of the modified search code.
For now I have printed your comments, the one from late yesterday and today's, and will think about them. I should note that even with the ensemble porposal not fully handling all packages, i.e. C-level calls not intercepted and known, it should be possible to use this type of wrapping for basic experimentation with various possibilities.
Not a release blocker; dropping prio back