![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 01/03/2011 08:58, Invisible wrote:
> On 01/03/2011 08:39 AM, scott wrote:
>
>> I couldn't live without two monitors at work. The left screen is for
>> Outlook (which is usually the source of all work I have to do and where
>> the work goes after I'm done), the right screen is for whatever I'm
>> currently working on (3D CAD, powerpoint, excel etc).
>
> Wouldn't it be simpler and easier to just buy one larger monitor?
Apart from the fact that I like to have both monitors directed towards
me (so they are not in the same plane), I don't think anyone makes a
3840x1200 resolution monitor anyway. It's actually very simple to get 2
monitors, you just write "2" in the quantity box, and connect up 2
monitors instead of 1.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> The guy told him he just used the
> default combination, because it hadn't been changed.
OK. I've never heard of a safe leaving the factory with a default
combination. Maybe they've gotten smarter since then or something. :-)
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > I still find it scary that people have written C programs that take
> > longer than 0.003 seconds to compile. How huge would they have to be?
> Last one I worked on took about 45 minutes to compile, and it included tons
> of already-compiled stuff for which we didn't have the source.
It depends on the compiler too. For example gcc is notoriously *slow*
to compile big projects (but at least it's a top-tier on the quality of
the result).
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Last one I worked on took about 45 minutes to compile, and it included
> tons of already-compiled stuff for which we didn't have the source.
Plus, considering #include, the number of lines of source in the project is
not the number of lines you have to compile to compile the project. This
project had include files with tens of thousands of lines (hell, 4000-line
individual macros) that got included in pretty much every source file, as
well as all kinds of nested hierarchies of include files that included who
knows how much extraneous stuff by the time you were done. I've written
serious programs shorter than some of the compiler command lines in that
project.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 01/03/2011 05:30 PM, Darren New wrote:
> Invisible wrote:
>> The guy told him he just used the default combination, because it
>> hadn't been changed.
>
> OK. I've never heard of a safe leaving the factory with a default
> combination. Maybe they've gotten smarter since then or something. :-)
Or maybe they just assume that if you're paying all this money, you'll
read the instructions and choose a new combination. IDK.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Plus, considering #include, the number of lines of source in the project is
> not the number of lines you have to compile to compile the project. This
> project had include files with tens of thousands of lines (hell, 4000-line
> individual macros) that got included in pretty much every source file, as
> well as all kinds of nested hierarchies of include files that included who
> knows how much extraneous stuff by the time you were done. I've written
> serious programs shorter than some of the compiler command lines in that
> project.
If you are going to deliberately make compilation times longer, then
you could just use template metaprogramming and have the compilation take
hours for a simple 50-line source file.
Just because badly designed programs can take long to compile doesn't
mean it's necessarily so.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Or maybe they just assume that if you're paying all this money, you'll
> read the instructions and choose a new combination. IDK.
Maybe. I don't think changing the combination on a safe of that era was a
trivial operation. You needed a locksmith to open up the door and take apart
the lock. It certainly wasn't any easier than re-keying a lock is today.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> If you are going to deliberately make compilation times longer,
Nobody wanted the compilation times to be longer.
> Just because badly designed programs can take long to compile doesn't
> mean it's necessarily so.
I know that. I was just pointing out that #include means some files get
compiled many times, so a line count doesn't really tell you how many lines
were compiled to make a complex system. You don't need to get defensive
about the fact.
I remember reading where one customer had called up an Ada compiler
manufacturer to complain their compiler was slow. The manufacturer asked to
see the code and it was tremendously convoluted in terms of what library
generics it instantiated and so on. The vendor asked why they were doing it
this way, and the customer says "I modeled it on your sample XYZ." The
vendor informs them that sample XYZ is a compiler stress-test designed to
make the compiler run out of resources to ensure the compiler handles it right.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> I remember reading where one customer had called up an Ada compiler
> manufacturer to complain their compiler was slow. The manufacturer asked to
> see the code and it was tremendously convoluted in terms of what library
> generics it instantiated and so on. The vendor asked why they were doing it
> this way, and the customer says "I modeled it on your sample XYZ." The
> vendor informs them that sample XYZ is a compiler stress-test designed to
> make the compiler run out of resources to ensure the compiler handles it right.
I have heard of projects which use extensively C++ template metaprogramming
to optimize things at runtime (I think at least some of those projects are
related to matrix manipulation). The programs take ages to compile, but the
resulting binaries are significantly faster than equivalent programs made
in more traditional ways. (I suppose it could be summarized as tons of
things being precalculated at compile time.)
(What makes these projects interesting is that template metaprogramming
is not just a curiosity, but it's actually being in some cases used for
great benefit.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> (What makes these projects interesting is that template metaprogramming
> is not just a curiosity, but it's actually being in some cases used for
> great benefit.)
Yeah. I don't think Ada computes stuff like that at compile time. The C++
template system is definitely the most powerful mechanism I've seen on a
language of that class, with FORTH really being a close second. But stuff
like LISP and Tcl just can't get the sort of efficiency you can with a
language that really targets the bare metal like that.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |