Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
On 17-04-2014, at 11:59 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
I’m not keen on it as a default either. Fortunately we had a rant about it just the other day so I know how to rurn it off - dig out the Auto enclose option in ‘Morphic’. Not, by the way, in ‘morphic’. How did we end up with two categories differing only in capitalisation?
You might want to turn off ‘Multi-window browsers’ and ‘Reuse windos’ in ‘browsing too. Drives me nuts.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Thesaurus: Ancient reptile with a truly extensive vocabulary
On 17-04-2014, at 12:20 PM, tim Rowledge tim@rowledge.org wrote:
You might want to turn off ‘Multi-window browsers’ and ‘Reuse windos’ in ‘browsing too. Drives me nuts.
Oh, and also ‘Shout styling in Workspace’. And ‘swapMouseButtons’ in ‘general’. And ‘block argument assignment’, ‘menuAppearance3d’, ‘gradientMenu’, ‘menuWithIcons’, anything to do with roundedBlahCorners, ‘scrollBarsOnRIght’.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All the simple programs have been written, and all the good names taken.
You might want to turn off ‘Multi-window browsers’ and ‘Reuse windos’ in ‘browsing too. Drives me nuts.
Wow, that Multi-window browsers option is UI-evil incarnate! I really don't understand why people just LOVE _modal_ UI's and modal browsing. :) Modal browsing is so cumbersome and impossible to follow anything.
Just curious why don't you like Reuse Windows? That saves me from accidentally accumulating 15 windows opened on the same class, without stopping me from easily duplicating a window if I need to..
On Thu, Apr 17, 2014 at 1:59 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
Amen, brother.
The preference is called 'Auto Enclose' and you can find it under the Morphic category.
Colin
See the 'How do I convince a Workspace to stop "helping" me?' thread for previous rants and rationalizations ;-)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-April/177810.htm...
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
-- unhappily, Eliot
Ok found it!
World Menu > open... > Preferences Browser >
Select Morphic (No not the morphic with lower case m)
Disable "Auto Enclose"
Woo hoo. You can now go about your business in your once again serene world!
All the best,
Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron@3dicc.com Follow Me On Twitter: @RonTeitelbaum www.3dicc.com https://www.google.com/+3dicc
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak- dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Thursday, April 17, 2014 4:11 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] open paren/brace/bracket...
See the 'How do I convince a Workspace to stop "helping" me?' thread for previous rants and rationalizations ;-)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014- April/177810.html
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this
really
an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
-- unhappily, Eliot
On Thu, Apr 17, 2014 at 1:59 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
Calm down, won't you? If you need to add an exception handler around some phrase, why not just highlight the phrase and press Command+[ to surround it with brackets.
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious..
On Thu, Apr 17, 2014 at 1:12 PM, Chris Muller asqueaker@gmail.com wrote:
On Thu, Apr 17, 2014 at 1:59 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the
"always
type a matching open/close pair" when typing any of ( [ { etc on us?
Would
that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this
really
an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a
single
one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is
defensible.
Doing it always IS F*&^%$*G BROKEN.
Calm down, won't you? If you need to add an exception handler around some phrase, why not just highlight the phrase and press Command+[ to surround it with brackets.
So do it *when there's an expression to enclose*, not every time you type the character.
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious..
You know, one can type non-Smalltalk in SMalltalk (class comments, snippets of HTML, angry messages to Squeak-dev), not just platonic Smalltalk. And the Auto-enclose crap doesn't help there.
Anyway, I can turn it off. Hope no noobs will be equally irritated...
On Thu, Apr 17, 2014 at 3:39 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 17, 2014 at 1:12 PM, Chris Muller asqueaker@gmail.com wrote:
On Thu, Apr 17, 2014 at 1:59 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the "always type a matching open/close pair" when typing any of ( [ { etc on us? Would that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this really an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a single one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is defensible. Doing it always IS F*&^%$*G BROKEN.
Calm down, won't you? If you need to add an exception handler around some phrase, why not just highlight the phrase and press Command+[ to surround it with brackets.
So do it *when there's an expression to enclose*, not every time you type the character.
Because, by doing the above, there are no cases left to need an open paren / bracket / quote without the corresponding close.
But when I'm typing multiple nested levels of parentheses and blocks, I don't like to have to tediously match them up when the machine can do it for me.
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious..
You know, one can type non-Smalltalk in SMalltalk (class comments, snippets of HTML, angry messages to Squeak-dev), not just platonic Smalltalk. And the Auto-enclose crap doesn't help there.
Well it does, for the same reason. Whether typing code, prose, comments, snippets or HTML, a close-parenthesis is sure to need to follow an open..
I thought Alejandro's argument was somewhat entertaining, "if you need to be typing so many nested levels it speaks about your bad code.." Maybe, but sometimes you have to balance against number of tiny methods and the language needs to support it no matter what, so may as well make it easy. :)
On 17-04-2014, at 1:54 PM, Chris Muller asqueaker@gmail.com wrote:
Well it does, for the same reason. Whether typing code, prose, comments, snippets or HTML, a close-parenthesis is sure to need to follow an open..
Really? What if the close is already there because you’re edit text? Oh, wait, we’re supposed to be too cool to edit text these days…
I claim that the reasonable position is that simple typing simply types. Clever extras ought to involve a tiny bit of extra work, such as alt-( or alt-CR etc.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SG: Show Garbage
On Thu, Apr 17, 2014 at 1:12 PM, Chris Muller asqueaker@gmail.com wrote:
On Thu, Apr 17, 2014 at 1:59 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
first, excuse the venting. Who the %*&^$# decided to inflict the
"always
type a matching open/close pair" when typing any of ( [ { etc on us?
Would
that person please consider commiting hara kiri?
OK, now slightly calmer, I find it /exceedingly/ annoying. Is this
really
an appropriate default? How does one turn it off?
The cases that send me up my *&%$^# tree are when I intend to add a
single
one in front of some string when I go back to edit some text (e.g. add an exception handler around some phrase). Here, typing the pair *is just broken*. Doing it at the end of a text or at the end of line is
defensible.
Doing it always IS F*&^%$*G BROKEN.
Calm down, won't you? If you need to add an exception handler around some phrase, why not just highlight the phrase and press Command+[ to surround it with brackets.
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious...
You do know about alt-enclose don't you?
On Thu, Apr 17, 2014 at 3:12 PM, Chris Muller asqueaker@gmail.com wrote:
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious.
You know, I bet this boils down to a simple cost-benefit analysis. For me, the effort required to type a character at the cursor position is negligible, so saving that effort is of little benefit. Even in cases where I will need to put a $) after the expression I'm typing now, sometimes I'll have to type right-arrow to get past it. So the benefit is very small and often offset by a small loss.
Similarly, deleting an unwanted character is cheap, but deciding whether to do so is a huge cost. I have to stop thinking about what I'm doing, and think ahead to what I'm going to do next. Even if I know I'm going to need the closing character, it stays in my field of view and takes up cycles as a pending thing that I have to worry about until I complete the encoded expression.
So, the benefit is small and unreliable, while the cost is large and inevitable. It forces me to think about typing, which normally I don't have to do. Thus, it's infuriating.
However, that calculus is very personal. If typing a character took, say, 10x longer, or I had to look at the keyboard to find the character, the benefit would be much more significant. Also, if I had to think about where the keys are, then deciding whether or not to delete the character wouldn't be an interruption; it would just get folded into the "thinking about typing" that I'd do.
So it probably has more to do with how fast we type than how we think about coding or "editing text" or even familiarity.
Colin
2014-04-18 0:56 GMT+02:00 Colin Putney colin@wiresong.com:
On Thu, Apr 17, 2014 at 3:12 PM, Chris Muller asqueaker@gmail.com wrote:
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious.
You know, I bet this boils down to a simple cost-benefit analysis. For me, the effort required to type a character at the cursor position is negligible, so saving that effort is of little benefit. Even in cases where I will need to put a $) after the expression I'm typing now, sometimes I'll have to type right-arrow to get past it. So the benefit is very small and often offset by a small loss.
Similarly, deleting an unwanted character is cheap, but deciding whether to do so is a huge cost. I have to stop thinking about what I'm doing, and think ahead to what I'm going to do next. Even if I know I'm going to need the closing character, it stays in my field of view and takes up cycles as a pending thing that I have to worry about until I complete the encoded expression.
So, the benefit is small and unreliable, while the cost is large and inevitable. It forces me to think about typing, which normally I don't have to do. Thus, it's infuriating.
However, that calculus is very personal. If typing a character took, say, 10x longer, or I had to look at the keyboard to find the character, the benefit would be much more significant. Also, if I had to think about where the keys are, then deciding whether or not to delete the character wouldn't be an interruption; it would just get folded into the "thinking about typing" that I'd do.
So it probably has more to do with how fast we type than how we think about coding or "editing text" or even familiarity.
Colin
Very well said.
Typing text is not only pretty old-school, it can be pretty low level too. Forcing us to think (high level) during a low level activity is pretty disrupting, upsetting and inefficient. That's precisely why I got exactly the same repulsion to these automated help that constantly break my own automated flow... Maybe we could train ourselves and adapt to these auto-enclose, but this will then break our flow anywhere outside Squeak, so I simply do not wish to.
Nicolas
Thanks for that great explanation -- (my interest in in man-machine interfaces has always made this an interesting topic for me).
I've got to say, I totally get you. I know exactly how you feel because its exactly how I feel about "Auto Indent". I drives me nuts in exactly the ways you've described about Auto Enclose, and for the same exact reasons. It totally intrudes on my typing, disrupting my train of thought because its guessing wrong half the time and forcing me into a bunch of little "decisions" whether I need to press Tab or Backspace. I know what I want to type, I just want to let-it-flow.
This made me pause to ask, "so why do I like Auto Enclose so much, but not Auto Indent?"
It's because of Squeak's amazing little collection of 2 or 3 editing features turn it into like a poor-mans Scratch. You know, the ones we've been talking about: 1) selecting innards, 2) hot-key adding/removing of surrounding enclosures, 3) auto format. Once using those, Auto Enclose rounds it out nicely, (and disabling selectionMayShrink boosts it even one more notch).
You know, I bet this boils down to a simple cost-benefit analysis. For me, the effort required to type a character at the cursor position is negligible, so saving that effort is of little benefit. Even in cases where I will need to put a $) after the expression I'm typing now, sometimes I'll have to type right-arrow to get past it. So the benefit is very small and often offset by a small loss.
It's not about saving keystrokes. It's about automatic closure of multiple nested expressions. Query's like this are almost impossible to "type" without Auto Enclose:
^ (cube plot: [ : dim | dim date month ] measures: [ : meas | (meas mean score plotNumber: 1) , ((meas define: #fractionOfWinners as: [ : cell | cell total winnerCount / cell total count ]) plotNumber: 2) , (meas mean gainFactor plotNumber: 3; colorizer: [ : val | val > 0 ifTrue: [Color green twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ] where: [ : cell | (cell dimension date year equalTo: Date today asYear) | (cell dimension date year equalTo: Date today asYear previous) ]) open
It'd be much more easily "assembled", expression by expression, but Auto Enclose gives typing it at least a chance of success. :)
Similarly, deleting an unwanted character is cheap, but deciding whether to do so is a huge cost. I have to stop thinking about what I'm doing, and think ahead to what I'm going to do next. Even if I know I'm going to need the closing character, it stays in my field of view and takes up cycles as a pending thing that I have to worry about until I complete the encoded expression.
So I'm surprised you don't better appreciate the atomicity of expression-editing. Deleting a paren/brace/quote character breaks the code and even breaks the formatter so you can get really stuck on complex expressions. Taking an approach of expression-editing, one is determined not to let the code ever be broken even for a short period of time.
So, the benefit is small and unreliable, while the cost is large and inevitable. It forces me to think about typing, which normally I don't have to do. Thus, it's infuriating.
Yep, I totally get you. But if you ever decide to try committing to Squeak's very capable expression-editing functions, I hope it'll work out as well for you as for me.
On Thu, Apr 17, 2014 at 10:11 PM, Chris Muller asqueaker@gmail.com wrote:
Yep, I totally get you. But if you ever decide to try committing to Squeak's very capable expression-editing functions, I hope it'll work out as well for you as for me.
Wow. The condescension here is breathtaking. I tried really hard to explain why some of us have such a strong reaction to this feature. But you don't seem to care, and refuse to accept "to each his own" as an answer.
I'm not going to post further on this topic, except to help people find the preference.
Colin
Yep, I totally get you. But if you ever decide to try committing to Squeak's very capable expression-editing functions, I hope it'll work out as well for you as for me.
Wow. The condescension here is breathtaking. I tried really hard to explain why some of us have such a strong reaction to this feature. But you don't seem to care, and refuse to accept "to each his own" as an answer.
I'm not going to post further on this topic, except to help people find the preference.
Whoa whoa there! Sheesh, I made extra effort to write that whole note with "love" man! There is NO condescension at all here! I told you I "get you" and even explained how I relate to your strong reaction via Auto Indent. I do!
I'm reading it and not getting why you're insulted. :( You feel I'm saying you're stupid for not using it? No, I never would, because that's not what I think about you. Your cost-benefit was based on keystrokes, so I'm simply saying, from another angle, there's a gold nugget there. Discovering Squeak gold is a great experience I hope you, myself and others will enjoy again.
On 18 April 2014 05:11, Chris Muller asqueaker@gmail.com wrote:
Thanks for that great explanation -- (my interest in in man-machine interfaces has always made this an interesting topic for me).
I've got to say, I totally get you. I know exactly how you feel because its exactly how I feel about "Auto Indent". I drives me nuts in exactly the ways you've described about Auto Enclose, and for the same exact reasons. It totally intrudes on my typing, disrupting my train of thought because its guessing wrong half the time and forcing me into a bunch of little "decisions" whether I need to press Tab or Backspace. I know what I want to type, I just want to let-it-flow.
This made me pause to ask, "so why do I like Auto Enclose so much, but not Auto Indent?"
It's because of Squeak's amazing little collection of 2 or 3 editing features turn it into like a poor-mans Scratch. You know, the ones we've been talking about: 1) selecting innards, 2) hot-key adding/removing of surrounding enclosures, 3) auto format. Once using those, Auto Enclose rounds it out nicely, (and disabling selectionMayShrink boosts it even one more notch).
You know, I bet this boils down to a simple cost-benefit analysis. For
me,
the effort required to type a character at the cursor position is negligible, so saving that effort is of little benefit. Even in cases where I will need to put a $) after the expression I'm typing now, sometimes I'll have to type right-arrow to get past it. So the benefit is very small and often offset by a small loss.
It's not about saving keystrokes. It's about automatic closure of multiple nested expressions. Query's like this are almost impossible to "type" without Auto Enclose:
Usually, when this happens, this is a good sign that your code needs refactoring.
^ (cube plot: [ : dim | dim date month ] measures: [ : meas | (meas mean score plotNumber: 1) , ((meas define: #fractionOfWinners as: [ : cell | cell total winnerCount / cell totalcount ]) plotNumber: 2) , (meas mean gainFactor plotNumber: 3; colorizer: [ : val | val > 0 ifTrue: [Color green twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ] where: [ : cell | (cell dimension date year equalTo: Date today asYear) | (cell dimension date year equalTo: Date today asYear previous) ]) open
It'd be much more easily "assembled", expression by expression, but Auto Enclose gives typing it at least a chance of success. :)
Similarly, deleting an unwanted character is cheap, but deciding whether to do so is a huge cost. I have to stop thinking about what I'm doing, and think ahead to what
I'm
going to do next. Even if I know I'm going to need the closing character, it stays in my field
of
view and takes up cycles as a pending thing that I have to worry about until I complete the
encoded
expression.
So I'm surprised you don't better appreciate the atomicity of expression-editing. Deleting a paren/brace/quote character breaks the code and even breaks the formatter so you can get really stuck on complex expressions. Taking an approach of expression-editing, one is determined not to let the code ever be broken even for a short period of time.
So, the benefit is small and unreliable, while the cost is large and inevitable. It forces me to think about typing, which normally I don't have to do. Thus, it's infuriating.
Yep, I totally get you. But if you ever decide to try committing to Squeak's very capable expression-editing functions, I hope it'll work out as well for you as for me.
I have been experimenting with a new implementation of DateAndTime based on a UTC magnitude. In this implementation, the instance variables jdn, seconds, and nanos are replaced with a single utcMicroseconds, and the offset (a Duration) is replaced by localOffsetSeconds (an integer). The UTC magnitude and offset are provided directly by primitiveUtcWithOffset when doing DateAndTime now.
I had hoped to achieve a sigificant performance advantage with this implementation, and while it does improve performance, I am only seeing about a 10% improvement overall, which is considerably less than I had hoped. Nevertheless, it is indeed faster, and implemention does have some interesting characteristics.
The utcMicroseconds magnitude is in units of microseconds, but it is not required to be an integer and may represent time to any precision. In practice, values are integral unless the instance is explicitly created with a nanosecond value.
New instances created by "DateAndTime now" will have the correct time zone offset as provided by the operating system platform, and their magnitude is set to a UTC value the precision provided by the platform.
New instances created by other constructors use TimeZone default, which is problematic given that the time zone in Squeak may or may not match the (presumably correct) values provided by the operating system.
Instances of DateAndTime are (at the moment) considered equal if their magnitudes are the same, independent of the time zone offset. This makes sense when thinking of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances with different local offsets are equal might be wrong in other contexts.
The localOffsetSeconds is used for displaying the date and time, and is not related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a formatter (use the offset to show the magnitude in the context of a local time zone).
Dave
Hi Dave, did you lurk at the work in Pharo? I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively. It would be interesting to compare the timings vs latest Pharo (3.0).
A single variable is interesting for simplifying implementation. I wonder about the required precision though... There are about 2^20 microseconds in a second, and about 2^31 seconds in about 68 years. So with a Double, you can span about 4*68 years, in the future of epoch (same in the past), while keeping the microsecond precision. That seems well enough, considering that second precision for an event several centuries ago is sufficient. And with the avent of SmallDouble in 64 bits Spur, that would be certainly more efficient than now.
But nanos would cost 10 more bits and be rapidly out of reach (with a span of +/- 3 month around the epoch)... I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer, but I didn't measure anything...
Nicolas
2014-04-19 4:42 GMT+02:00 David T. Lewis lewis@mail.msen.com:
I have been experimenting with a new implementation of DateAndTime based on a UTC magnitude. In this implementation, the instance variables jdn, seconds, and nanos are replaced with a single utcMicroseconds, and the offset (a Duration) is replaced by localOffsetSeconds (an integer). The UTC magnitude and offset are provided directly by primitiveUtcWithOffset when doing DateAndTime now.
I had hoped to achieve a sigificant performance advantage with this implementation, and while it does improve performance, I am only seeing about a 10% improvement overall, which is considerably less than I had hoped. Nevertheless, it is indeed faster, and implemention does have some interesting characteristics.
The utcMicroseconds magnitude is in units of microseconds, but it is not required to be an integer and may represent time to any precision. In practice, values are integral unless the instance is explicitly created with a nanosecond value.
New instances created by "DateAndTime now" will have the correct time zone offset as provided by the operating system platform, and their magnitude is set to a UTC value the precision provided by the platform.
New instances created by other constructors use TimeZone default, which is problematic given that the time zone in Squeak may or may not match the (presumably correct) values provided by the operating system.
Instances of DateAndTime are (at the moment) considered equal if their magnitudes are the same, independent of the time zone offset. This makes sense when thinking of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances with different local offsets are equal might be wrong in other contexts.
The localOffsetSeconds is used for displaying the date and time, and is not related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a formatter (use the offset to show the magnitude in the context of a local time zone).
Dave
On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
Hi Dave, did you lurk at the work in Pharo? I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively. It would be interesting to compare the timings vs latest Pharo (3.0).
Hi Nicolas,
Yes, I'm aware of the Pharo work.
The approach that I am trying now is based on my earlier work with the Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase. In order to make that work with DateAndTime, I use a class called PointInTime that is a magnitude representing UTC time in seconds. This makes the time zone table lookups simple, and it makes the conversions to and from DateAndTime easier to test and to understand.
I always thought that it would be interesting to "eliminate the middle man" in this scheme by making DateAndTime be clearly based on a UTC time scale. So that is what I am trying now.
A single variable is interesting for simplifying implementation. I wonder about the required precision though... There are about 2^20 microseconds in a second, and about 2^31 seconds in about 68 years. So with a Double, you can span about 4*68 years, in the future of epoch (same in the past), while keeping the microsecond precision. That seems well enough, considering that second precision for an event several centuries ago is sufficient. And with the avent of SmallDouble in 64 bits Spur, that would be certainly more efficient than now.
Interesting that you should say that. In the PointInTime class, I originally used Float (double) to represent UTC seconds for exactly the reason you say. It works well, but I tried some other representations and found that ScaledDecimal provided the best results overall, with good performance and very nice charactistics for displaying the UTC seconds in an inspector.
But overall, the best approach seems to be just let it be a Number and don't worry about it. In actual practice, if the UTC time is represented in units of microsecond, this results in integer values in all practical cases. In the rare case of specifying nanosecond precision, you get fractions, which are reasonably efficient also.
But nanos would cost 10 more bits and be rapidly out of reach (with a span of +/- 3 month around the epoch)... I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer, but I didn't measure anything...
ScaledDecimal turns out be be surprisingly good in performance. Despite its instance variable names ("fraction"), it actually uses integers when fractions are not required, so it is quite efficient. If I wanted to explicitly control the type of number used to represent UTC time, I would use ScaledDecimal.
Dave
Nicolas
2014-04-19 4:42 GMT+02:00 David T. Lewis lewis@mail.msen.com:
I have been experimenting with a new implementation of DateAndTime based on a UTC magnitude. In this implementation, the instance variables jdn, seconds, and nanos are replaced with a single utcMicroseconds, and the offset (a Duration) is replaced by localOffsetSeconds (an integer). The UTC magnitude and offset are provided directly by primitiveUtcWithOffset when doing DateAndTime now.
I had hoped to achieve a sigificant performance advantage with this implementation, and while it does improve performance, I am only seeing about a 10% improvement overall, which is considerably less than I had hoped. Nevertheless, it is indeed faster, and implemention does have some interesting characteristics.
The utcMicroseconds magnitude is in units of microseconds, but it is not required to be an integer and may represent time to any precision. In practice, values are integral unless the instance is explicitly created with a nanosecond value.
New instances created by "DateAndTime now" will have the correct time zone offset as provided by the operating system platform, and their magnitude is set to a UTC value the precision provided by the platform.
New instances created by other constructors use TimeZone default, which is problematic given that the time zone in Squeak may or may not match the (presumably correct) values provided by the operating system.
Instances of DateAndTime are (at the moment) considered equal if their magnitudes are the same, independent of the time zone offset. This makes sense when thinking of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances with different local offsets are equal might be wrong in other contexts.
The localOffsetSeconds is used for displaying the date and time, and is not related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a formatter (use the offset to show the magnitude in the context of a local time zone).
Dave
On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:
On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
Hi Dave, did you lurk at the work in Pharo? I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively. It would be interesting to compare the timings vs latest Pharo (3.0).
Hi Nicolas,
Yes, I'm aware of the Pharo work.
The approach that I am trying now is based on my earlier work with the Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.
<OT> Well, what do you know, it seems that I just got my first link from Wikipedia. On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there is a link for "The Squeak Smalltalk time package" that points to the Olson time zone database for Squeak. </OT>
Dave
2014-04-19 15:29 GMT+02:00 David T. Lewis lewis@mail.msen.com:
On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:
On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
Hi Dave, did you lurk at the work in Pharo? I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively. It would be interesting to compare the timings vs latest Pharo (3.0).
Hi Nicolas,
Yes, I'm aware of the Pharo work.
The approach that I am trying now is based on my earlier work with the Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.
<OT> Well, what do you know, it seems that I just got my first link from Wikipedia. On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there is a link for "The Squeak Smalltalk time package" that points to the Olson time zone database for Squeak. </OT>
Dave
Congrats for the fame ;) And thanks for reporting your observations about Integer and Fraction efficiency. A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can completely change the figures anyway.
On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-19 15:29 GMT+02:00 David T. Lewis lewis@mail.msen.com:
On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:
On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
Hi Dave, did you lurk at the work in Pharo? I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively. It would be interesting to compare the timings vs latest Pharo (3.0).
Hi Nicolas,
Yes, I'm aware of the Pharo work.
The approach that I am trying now is based on my earlier work with the Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.
<OT> Well, what do you know, it seems that I just got my first link from Wikipedia. On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there is a link for "The Squeak Smalltalk time package" that points to the Olson time zone database for Squeak. </OT>
Dave
Congrats for the fame ;) And thanks for reporting your observations about Integer and Fraction efficiency. A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can completely change the figures anyway.
Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal = (2^60) - 1 , which is 36,000 years into the future :-)
DateAndTime fromSeconds: (1 << 60) - 1 // 1000000 38435-08-17T21:30:06-07:00
On Sat, Apr 19, 2014 at 11:44:34AM -0700, Eliot Miranda wrote:
On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can completely change the figures anyway.
Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal = (2^60) - 1 , which is 36,000 years into the future :-)
DateAndTime fromSeconds: (1 << 60) - 1 // 1000000 38435-08-17T21:30:06-07:00
Ha! Reminds me of the guy who thought 640k was going to be enough ;-)
Dave
On Sat, Apr 19, 2014 at 11:50 AM, David T. Lewis lewis@mail.msen.comwrote:
On Sat, Apr 19, 2014 at 11:44:34AM -0700, Eliot Miranda wrote:
On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
A 64 bits Spur should also scale our SmallIntegers up to 2^62, which
can
completely change the figures anyway.
Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal
=
(2^60) - 1 , which is 36,000 years into the future :-)
DateAndTime fromSeconds: (1 << 60) - 1 // 1000000
38435-08-17T21:30:06-07:00
Ha! Reminds me of the guy who thought 640k was going to be enough ;-)
Upload your consciousness today ;-)
e
You probably looked at this but Chronos, in the unadulterated Squeak 4.4 all-in-one, is ~2.5x faster than DateAndTime. E.g.
[100000 timesRepeat: [Timepoint now]] timeToRun 387
[100000 timesRepeat: [DateAndTime now]] timeToRun 971
Maybe there are some ideas worth taking in there.
The Chronos repo is here:
MCHttpRepository location: 'http://smalltalkhub.com/mc/Chronos/Chronos/main' user: '' password: ''
You can load it in a workspace with
ConfigurationOfChronos load
Assuming you have metacello loaded.
David T. Lewis wrote
I have been experimenting with a new implementation of DateAndTime based on a UTC magnitude. In this implementation, the instance variables jdn, seconds, and nanos are replaced with a single utcMicroseconds, and the offset (a Duration) is replaced by localOffsetSeconds (an integer). The UTC magnitude and offset are provided directly by primitiveUtcWithOffset when doing DateAndTime now.
I had hoped to achieve a sigificant performance advantage with this implementation, and while it does improve performance, I am only seeing about a 10% improvement overall, which is considerably less than I had hoped. Nevertheless, it is indeed faster, and implemention does have some interesting characteristics.
The utcMicroseconds magnitude is in units of microseconds, but it is not required to be an integer and may represent time to any precision. In practice, values are integral unless the instance is explicitly created with a nanosecond value.
New instances created by "DateAndTime now" will have the correct time zone offset as provided by the operating system platform, and their magnitude is set to a UTC value the precision provided by the platform.
New instances created by other constructors use TimeZone default, which is problematic given that the time zone in Squeak may or may not match the (presumably correct) values provided by the operating system.
Instances of DateAndTime are (at the moment) considered equal if their magnitudes are the same, independent of the time zone offset. This makes sense when thinking of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances with different local offsets are equal might be wrong in other contexts.
The localOffsetSeconds is used for displaying the date and time, and is not related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a formatter (use the offset to show the magnitude in the context of a local time zone).
Dave
-- View this message in context: http://forum.world.st/open-paren-brace-bracket-tp4755162p4755475.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Sat, Apr 19, 2014 at 01:31:43PM -0700, Paul DeBruicker wrote:
You probably looked at this but Chronos, in the unadulterated Squeak 4.4 all-in-one, is ~2.5x faster than DateAndTime. E.g.
[100000 timesRepeat: [Timepoint now]] timeToRun 387
[100000 timesRepeat: [DateAndTime now]] timeToRun 971
Actually, this is one area where the experimental DateAndTime version gives a substantial improvement.
Squeak trunk: [1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 2448
Modified version with UTC based DateAndTime: [1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 1264
But it turns out that most uses of DateAndTime involve conversion to and from strings, so in practice most the time time gets eaten up in parsing and in numeric conversions, regardless of the underlyingkrepresentation of the time magnitude.
The single UTC variable approach has some advantage in overall simplicity, but that seems to be partly offset by efficiencies of small integer computation in the current DateAndTime approach.
Dave
Maybe there are some ideas worth taking in there.
The Chronos repo is here:
MCHttpRepository location: 'http://smalltalkhub.com/mc/Chronos/Chronos/main' user: '' password: ''
You can load it in a workspace with
ConfigurationOfChronos load
Assuming you have metacello loaded.
David T. Lewis wrote
I have been experimenting with a new implementation of DateAndTime based on a UTC magnitude. In this implementation, the instance variables jdn, seconds, and nanos are replaced with a single utcMicroseconds, and the offset (a Duration) is replaced by localOffsetSeconds (an integer). The UTC magnitude and offset are provided directly by primitiveUtcWithOffset when doing DateAndTime now.
I had hoped to achieve a sigificant performance advantage with this implementation, and while it does improve performance, I am only seeing about a 10% improvement overall, which is considerably less than I had hoped. Nevertheless, it is indeed faster, and implemention does have some interesting characteristics.
The utcMicroseconds magnitude is in units of microseconds, but it is not required to be an integer and may represent time to any precision. In practice, values are integral unless the instance is explicitly created with a nanosecond value.
New instances created by "DateAndTime now" will have the correct time zone offset as provided by the operating system platform, and their magnitude is set to a UTC value the precision provided by the platform.
New instances created by other constructors use TimeZone default, which is problematic given that the time zone in Squeak may or may not match the (presumably correct) values provided by the operating system.
Instances of DateAndTime are (at the moment) considered equal if their magnitudes are the same, independent of the time zone offset. This makes sense when thinking of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances with different local offsets are equal might be wrong in other contexts.
The localOffsetSeconds is used for displaying the date and time, and is not related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a formatter (use the offset to show the magnitude in the context of a local time zone).
Dave
-- View this message in context: http://forum.world.st/open-paren-brace-bracket-tp4755162p4755475.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
It's not about saving keystrokes. It's about automatic closure of multiple nested expressions. Query's like this are almost impossible to "type" without Auto Enclose:
Usually, when this happens, this is a good sign that your code needs refactoring.
Yes, that's why I gave the example of an ad-hoc query, because in practice they're short "throw-away" workspace expressions rather than factored methods.
^ (cube plot: [ : dim | dim date month ] measures: [ : meas | (meas mean score plotNumber: 1) , ((meas define: #fractionOfWinners as: [ : cell | cell total winnerCount / cell totalcount ]) plotNumber: 2) , (meas mean gainFactor plotNumber: 3; colorizer: [ : val | val > 0 ifTrue: [Color green twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ] where: [ : cell | (cell dimension date year equalTo: Date today asYear) | (cell dimension date year equalTo: Date today asYear previous) ]) open
It'd be much more easily "assembled", expression by expression, but Auto Enclose gives typing it at least a chance of success. :)
Similarly, deleting an unwanted character is cheap, but deciding whether to do so is a huge cost. I have to stop thinking about what I'm doing, and think ahead to what I'm going to do next. Even if I know I'm going to need the closing character, it stays in my field of view and takes up cycles as a pending thing that I have to worry about until I complete the encoded expression.
So I'm surprised you don't better appreciate the atomicity of expression-editing. Deleting a paren/brace/quote character breaks the code and even breaks the formatter so you can get really stuck on complex expressions. Taking an approach of expression-editing, one is determined not to let the code ever be broken even for a short period of time.
So, the benefit is small and unreliable, while the cost is large and inevitable. It forces me to think about typing, which normally I don't have to do. Thus, it's infuriating.
Yep, I totally get you. But if you ever decide to try committing to Squeak's very capable expression-editing functions, I hope it'll work out as well for you as for me.
-- Best regards, Igor Stasenko.
On Thu, Apr 17, 2014 at 03:12:04PM -0500, Chris Muller wrote:
Some people like to "edit text" and some people like to "edit expressions". Personally, I find "editing text" pretty old-school, and a lot more tedious..
I like to edit my shopping list in a workspace. It would be great if this could consist of executable expressions that produced groceries on my doorstep, but alas that feature remains unimplemented. Meanwhile, having a syntax assistant interfering with my typing is an annoyance, rather like that little paper clip assistant that Microsoft decided that we were all going to love a few years ago.
On second thought, maybe it's not such a bad idea ... I bet Tim could do an animated squeaky mouse morph (after all, the eyes are already working). We could have it detect typing activity, then scurry around the insertion cursor leaving little mouse droppings that turn into syntax suggestions. We might need to make it a preference though ;-)
Dave
On 17-04-2014, at 4:27 PM, David T. Lewis lewis@mail.msen.com wrote:
On second thought, maybe it's not such a bad idea ... I bet Tim could do an animated squeaky mouse morph (after all, the eyes are already working). We could have it detect typing activity, then scurry around the insertion cursor leaving little mouse droppings that turn into syntax suggestions. We might need to make it a preference though ;-)
Sadly I can’t claim great expertise in making animate morphy-things. Getting the damn things to just lay out where I want them and stay there is *quite* exciting enough, thank you.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SD: Self Destruct
On Thu, Apr 17, 2014 at 04:42:19PM -0700, tim Rowledge wrote:
On 17-04-2014, at 4:27 PM, David T. Lewis lewis@mail.msen.com wrote:
On second thought, maybe it's not such a bad idea ... I bet Tim could do an animated squeaky mouse morph (after all, the eyes are already working). We could have it detect typing activity, then scurry around the insertion cursor leaving little mouse droppings that turn into syntax suggestions. We might need to make it a preference though ;-)
Sadly I can?t claim great expertise in making animate morphy-things. Getting the damn things to just lay out where I want them and stay there is *quite* exciting enough, thank you.
That's not a show stopper. Having the animated thing hop around and position itself unexpectedly is exactly the behaviour I had in mind. We will want sound effects of course, particularly in the case of keyboard input that triggers a lint rule exception.
Dave
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Colin Putney -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Nicolas Cellier -
Paul DeBruicker -
Ron Teitelbaum -
tim Rowledge