March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 2012-03-10 00:04, Nick Sabalausky wrote: > Freezing things against breaking changes is all fine and good, but NOT > before they're reached a point where they're good enough to be frozen. > Premature freezing is how you create cruft and other such shit. Let's not go > jumping any guns here. > > I completely aggree. -- /Jacob Carlborg |
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jérôme M. Berger | On Sat, Mar 10, 2012 at 04:35:26PM +0100, "Jérôme M. Berger" wrote: > Adam D. Ruppe wrote: > > On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote: > >> Since when is mouse movement a stop-the-world event on Linux? > > > > It's a hardware interrupt. They all work that way. You have > > to give a lot of care to handling them very quickly and > > not letting them stack up (lest the whole system freeze). > > So? It's not stop-the-world. While one core is handling the > interrupt, the other(s) is(are) still running. A stop-the-world GC > would need to block all threads on all cores while running. > > Jerome > > PS: This is nothing restricted to Linux. Windows, MacOS X and the *BSDs have the same behaviour. [...] OK, clearly I wasn't understanding what the OP was talking about. It *seemed* to imply that Linux had stop-the-world problems with mouse movement, but this isn't the case. A hardware interrupt is a hardware interrupt. Whatever OS you're using, it's got to stop to handle this somehow. I don't see how else you can do this. When the hardware needs to signal the OS about something, it's gotta do it somehow. And hardware often requires top-priority stop-the-world handling, because it may not be able to wait a few milliseconds before it's handled. It's not like software that generally can afford to wait for a period of time. As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either. T -- Lottery: tax on the stupid. -- Slashdotter |
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 03/10/2012 05:35 AM, Walter Bright wrote:
> On 3/9/2012 3:14 PM, bearophile wrote:
>> D will naturally progressively slow down the rhythm of its new breaking
>> changes, but even very old languages introduce some breaking changes (see
>> some of the changes in C++11),
>
> What breaking changes are there in C++11, other than dumping export?
I am only aware of those, but I don't use C++ a lot. So there might be more:
- introduction of constexpr messed with the overload resolution rules.
- '>>' can no longer be used inside a template argument expression.
|
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
>> On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
>> >Since when is mouse movement a stop-the-world event on Linux?
>>
>> It's a hardware interrupt. They all work that way. You have
>> to give a lot of care to handling them very quickly and
>> not letting them stack up (lest the whole system freeze).
>
> Sure, but I've never seen a problem with that.
Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors.
|
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:
> OK, clearly I wasn't understanding what the OP was talking about. It
> *seemed* to imply that Linux had stop-the-world problems with mouse
> movement, but this isn't the case.
>
> A hardware interrupt is a hardware interrupt. Whatever OS you're using,
> it's got to stop to handle this somehow. I don't see how else you can do
> this. When the hardware needs to signal the OS about something, it's
> gotta do it somehow. And hardware often requires top-priority
> stop-the-world handling, because it may not be able to wait a few
> milliseconds before it's handled. It's not like software that generally
> can afford to wait for a period of time.
>
> As for Win95 being unable to keep up with mouse movement... well, to be
> honest I hated Win95 so much that 90% of the time I was in the DOS
> prompt anyway, so I didn't even notice this. If it were truly a problem,
> it's probably a sign of poor hardware interrupt handling (interrupt
> handler is taking too long to process events). But I haven't seen this
> myself either.
Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.
|
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | On Sat, Mar 10, 2012 at 06:41:24PM +0100, so wrote: > On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote: > >On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote: > >>On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote: > >>>Since when is mouse movement a stop-the-world event on Linux? > >> > >>It's a hardware interrupt. They all work that way. You have > >>to give a lot of care to handling them very quickly and > >>not letting them stack up (lest the whole system freeze). > > > >Sure, but I've never seen a problem with that. > > Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors. [...] Um... before my recent upgrade (about a year ago), I had been using a 500MB (or was it 100MB?) RAM machine running a 10-year-old processor. And before *that*, it was a 64MB (or 32MB?) machine running a 15-year-old processor... Then again, I never believed in the desktop metaphor, and have never seriously used Gnome or KDE or any of that fluffy stuff. I was on VTWM until I decided ratpoison (a mouseless WM) better suited the way I worked. T -- Who told you to swim in Crocodile Lake without life insurance?? |
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote: > On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote: [...] > >As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either. > > Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input. Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy. (Then again, I don't use graphics-heavy UIs... on Linux you can turn most of it off, and I do, but on Windows you have no choice. So perhaps it's more a measure of how I configured my system than anything else. I tried doing this in Windows once, and let's just say that I'll never, ever, even _dream_ of attempting it again, it was that painful.) T -- I'm still trying to find a pun for "punishment"... |
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Saturday, 10 March 2012 at 17:51:28 UTC, H. S. Teoh wrote:
> Um... before my recent upgrade (about a year ago), I had been using a
> 500MB (or was it 100MB?) RAM machine running a 10-year-old processor.
> And before *that*, it was a 64MB (or 32MB?) machine running a
> 15-year-old processor...
>
> Then again, I never believed in the desktop metaphor, and have never
> seriously used Gnome or KDE or any of that fluffy stuff. I was on VTWM
> until I decided ratpoison (a mouseless WM) better suited the way I
> worked.
I am also using light window managers. Most of the time only tmux and gvim running. I tried many WMs but if you are using it frequently and don't like falling back to windows and such, you need a WM working seamlessly with GUIs. Gimp is one. (You might not believe in desktop but how would you use a program like Gimp?) Now most of the tiling WMs suck at handling that kind of thing. Using xmonad now, at least it has a little better support.
|
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 10-03-2012 18:58, H. S. Teoh wrote: > On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote: >> On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote: > [...] >>> As for Win95 being unable to keep up with mouse movement... well, to >>> be honest I hated Win95 so much that 90% of the time I was in the DOS >>> prompt anyway, so I didn't even notice this. If it were truly a >>> problem, it's probably a sign of poor hardware interrupt handling >>> (interrupt handler is taking too long to process events). But I >>> haven't seen this myself either. >> >> Design of input handling, the theoretical part is irrelevant. I was >> solely talking about how they do it in practice. OSs are simply >> unresponsive and in linux it is more severe. If i am having this issue >> in practice it doesn't matter if it was the GC lock or an another >> failure to handle input. > > Then you must be running a very different Linux from the one I use. In > my experience, it's Windows that's an order of magnitude less responsive > due to constant HD thrashing (esp. on bootup, and then periodically > thereafter) and too much eye-candy. This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;) > > (Then again, I don't use graphics-heavy UIs... on Linux you can turn > most of it off, and I do, but on Windows you have no choice. So perhaps > it's more a measure of how I configured my system than anything else. I > tried doing this in Windows once, and let's just say that I'll never, > ever, even _dream_ of attempting it again, it was that painful.) > > > T > -- - Alex |
March 10, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 3/9/2012 10:44 PM, Nick Sabalausky wrote:
> If we start freezing things now, we're going to be Windows 9x.
Win9x was incredibly successful (!) We can only hope to be so successful.
|
Copyright © 1999-2021 by the D Language Foundation