Hi
I'd like to use an underscore character in a string to get a db name... but each time it returns the left arrow :s
How can I do that ? (can we desactivate the conversion ?)
I use the 3.8 6665 version of squeak
Thanks
Cédrick
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
If so, may we preserve the old timestamp information? Since the change is only cosmetic, I think the historical information is more valuable than to know when/who ran global-search-and-replace of the assignment operator.
I have posted an update to Berts FixUnderscores script on Mantis.
http://bugs.impara.de/view.php?id=3511
Thank you.
On 27 avr. 06, at 19:59, Chris Muller wrote:
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
Yes but we have to pay attention since we are using MC and we do not know if we would not get loading order problems if we would recompile everything (may be this is totally wrong what I'm saying since marcus already recompiled several times the image). So I have to check my fears :)
If so, may we preserve the old timestamp information? Since the change is only cosmetic, I think the historical information is more valuable than to know when/who ran global-search-and-replace of the assignment operator.
I have posted an update to Berts FixUnderscores script on Mantis.
(Your update is taking care of the old timestamp information?) ifTrue: [stef saysGreat; askBertForIntegration; andWillUseThatIn39]
http://bugs.impara.de/view.php?id=3511
Thank you.
Am 27.04.2006 um 21:38 schrieb stéphane ducasse:
On 27 avr. 06, at 19:59, Chris Muller wrote:
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
Yes but we have to pay attention since we are using MC and we do not know if we would not get loading order problems if we would recompile everything (may be this is totally wrong what I'm saying since marcus already recompiled several times the image). So I have to check my fears :)
Your fears may well be valid. What's really unpredictable when loading multiple MC packages at once is the order of initialize calls.
This is not really related to this package, but we might want to add the disabling of underscore assignments preference from Croquet, so you notice any missed ones when recompiling.
If so, may we preserve the old timestamp information? Since the change is only cosmetic, I think the historical information is more valuable than to know when/who ran global-search-and-replace of the assignment operator.
I have posted an update to Berts FixUnderscores script on Mantis.
(Your update is taking care of the old timestamp information?) ifTrue: [stef saysGreat; askBertForIntegration; andWillUseThatIn39]
Yes, it does take care of the timestamps. Not tested on old methods without timestamps, though. And it depends on Monticello (uses one method added by Monticello), but that shouldn't really be a problem.
I uploaded it to the impara repository and released on Squeakmap. (Should I add you as co-maintainer, Chris?)
- Bert -
\
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
Yes but we have to pay attention since we are using MC and we do not know if we would not get loading order problems if we would recompile everything (may be this is totally wrong what I'm saying since marcus already recompiled several times the image). So I have to check my fears :)
Your fears may well be valid. What's really unpredictable when loading multiple MC packages at once is the order of initialize calls.
This is not really related to this package, but we might want to add the disabling of underscore assignments preference from Croquet, so you notice any missed ones when recompiling.
Yeap do you have it somewhere?
If so, may we preserve the old timestamp information? Since the change is only cosmetic, I think the historical information is more valuable than to know when/who ran global-search-and-replace of the assignment operator.
I have posted an update to Berts FixUnderscores script on Mantis.
(Your update is taking care of the old timestamp information?) ifTrue: [stef saysGreat; askBertForIntegration; andWillUseThatIn39]
Yes, it does take care of the timestamps. Not tested on old methods without timestamps, though. And it depends on Monticello (uses one method added by Monticello), but that shouldn't really be a problem.
I uploaded it to the impara repository and released on Squeakmap. (Should I add you as co-maintainer, Chris?)
Cool. I'm just moving some stuff to france now. but over the week-end I will do another havresting pass.
Stef
Am 28.04.2006 um 11:47 schrieb stéphane ducasse:
\
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
Yes but we have to pay attention since we are using MC and we do not know if we would not get loading order problems if we would recompile everything (may be this is totally wrong what I'm saying since marcus already recompiled several times the image). So I have to check my fears :)
Your fears may well be valid. What's really unpredictable when loading multiple MC packages at once is the order of initialize calls.
This is not really related to this package, but we might want to add the disabling of underscore assignments preference from Croquet, so you notice any missed ones when recompiling.
Yeap do you have it somewhere?
There is one which actually patches the fonts, but that's not critical and safe to run twice.
I rather meant that if packages are modified by converting underscores and then are loaded together, it may be problematic.
- Bert -
Am 28.04.2006 um 11:51 schrieb Bert Freudenberg:
Am 28.04.2006 um 11:47 schrieb stéphane ducasse:
Did the 3.9 team decide to adopt Berts underscore solution and, if so, is there a plan to run his conversion for 3.9 which converts the code from underscore assignment to :=?
Yes but we have to pay attention since we are using MC and we do not know if we would not get loading order problems if we would recompile everything (may be this is totally wrong what I'm saying since marcus already recompiled several times the image). So I have to check my fears :)
Your fears may well be valid. What's really unpredictable when loading multiple MC packages at once is the order of initialize calls.
This is not really related to this package, but we might want to add the disabling of underscore assignments preference from Croquet, so you notice any missed ones when recompiling.
Yeap do you have it somewhere?
There is one which actually patches the fonts, but that's not critical and safe to run twice.
I rather meant that if packages are modified by converting underscores and then are loaded together, it may be problematic.
Err, I completely misunderstood the question (I thought you were asking if I used an initialize method in my package).
No, I don't have a changeset for that, but it's really like a one- line change in the parser, someone would just have to look.
- Bert -
Not tested on old methods without timestamps, though.
Good catch. Sigh, this is annoying. You compile a method withStamp: nil and then #timeStamp returns an empty String..
This should probably be fixed. Instead of compiling unconditionally with timeStamp, we should check it for empty string and, if so, compile withStamp: nil.
OTOH, Lint barks about methods with no timestamp. Maybe this is an opportunity to "clean up" methods with no timestamp; i.e., since there isn't any reasonable historical information anyway, this may be reason to put in a timestamp of the person running the script (again, only for methods with no timestamp currently).
If the individual (i.e., Stef, Marcus, etc.) doesn't want to be associated with so many old methods, maybe that script could be run under developer-initials something like "3.9 team" or something..
Now that I've talked myself into confusion, someone please tell me there opinion on this matter..
And it depends on Monticello (uses one method added by Monticello), but that shouldn't really be a problem.
Woops. Oh well I sense Monticello is pretty much uibiquitous these days..
(Should I add you as co-maintainer, Chris?)
That would be a bit easier if I could save the above mentioned fix directly to the impara repository..
- Chris
On Fri, Apr 28, 2006 at 10:19:48AM -0700, Chris Muller wrote:
OTOH, Lint barks about methods with no timestamp. Maybe this is an opportunity to "clean up" methods with no timestamp; i.e., since there isn't any reasonable historical information anyway, this may be reason to put in a timestamp of the person running the script (again, only for methods with no timestamp currently).
No.
Any method with a nil timestamp should left that way, or failing this should be attributed to the dawn of time, which appears to have been 1901-01-01 in some unspecified time zone possible rooted in California, or perhaps in Greenwich, England. Personally, I think they should be left as nil, which retains the scope of the original ambiguity.
What should absolutely positively not be done is to attibute the original methods to initials and time stamps other than those of the actual authors. This is not merely confusing, it is disrespectful of the original authors' work.
Dave
On 29 avr. 06, at 03:36, David T. Lewis wrote:
On Fri, Apr 28, 2006 at 10:19:48AM -0700, Chris Muller wrote:
OTOH, Lint barks about methods with no timestamp. Maybe this is an opportunity to "clean up" methods with no timestamp; i.e., since there isn't any reasonable historical information anyway, this may be reason to put in a timestamp of the person running the script (again, only for methods with no timestamp currently).
No.
Any method with a nil timestamp should left that way, or failing this should be attributed to the dawn of time, which appears to have been 1901-01-01 in some unspecified time zone possible rooted in California, or perhaps in Greenwich, England. Personally, I think they should be left as nil, which retains the scope of the original ambiguity.
What should absolutely positively not be done is to attibute the original methods to initials and time stamps other than those of the actual authors. This is not merely confusing, it is disrespectful of the original authors' work.
I agree but we could use SqC this way we could have better code that does not have to check for isNil...
Stef
Am 27.04.2006 um 10:38 schrieb Cédrick Béler:
Hi
I'd like to use an underscore character in a string to get a db name... but each time it returns the left arrow :s
How can I do that ? (can we desactivate the conversion ?)
Install the FixUnderscores package from SqueakMap.
- Bert -
squeak-dev@lists.squeakfoundation.org