how to get an underscore character

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

> 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

Don't trust your eyes ;)
It's an underscore, it's just displayed as an arrow. This will be fixed in 3.9.

Cheers
Philippe

>
>Don't trust your eyes ;)
>It's an underscore, it's just displayed as an arrow. This will be fixed in 3.9.
>  
>
cool thanks ;)

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 -

> Install the FixUnderscores package from SqueakMap.
>
didn't find it in SqueakMap... but in ImparaSource and that works  thanks ;)

Am 27.04.2006 um 16:58 schrieb Cédrick Béler:

>
>> Install the FixUnderscores package from SqueakMap.
>>
> didn't find it in SqueakMap... but in ImparaSource and that works  
> thanks ;)

You need to update your local map - I did only register it today.

- 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 :=?
 
 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:

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 -

Yeap
do you have it somewhere?

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:

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:

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:

I agree but we could use SqC this way we could have better code that  
does not have to check
for isNil...

Stef