I forget who suggested this, but I have a Firefox extension named 
Firebug installed on my work PC. This allows me to do several rather 
interesting things. And utterly fails to allow me to do several other 
things.

I mainly use it for looking at the document tree. Firefox itself will 
only show you the text it loaded from disk. If you use the DOM to modify 
the document, there is *no way* to discover what Firefox is actually 
rendering. To my great relief, Firebug offers a way to see what the 
document tree looks like *now*, not when it was first loaded. So I can 
see whether my scripting has built the correct document tree or not.

It also appears to have some facilities related to tracking down 
complicated style cascades, which I shall probably never need to use, ever.

A couple of days ago, I discovered that it has a JavaScript debugging 
feature. Now that sounds quite useful, but unfortunately it doesn't 
appear to actually, you know, *work*.

- There's a button you can press that makes it so that next time a 
script runs, it immediately pops up in the script window. Unfortunately, 
pressing "step into" has the effect of "step over" approximately 85% of 
the time. This is the utter height of uselessness. Click a button and it 
says "this would cause Foo() to run". So you click "step into"... and it 
steps *over* Foo(), without showing you what's happening. Very helpful.

- As far as I can tell, breakpoints don't work. Like, I have a button 
that runs Bar() when you click it. So I put a breakpoint on Bar(), and 
click the button. The script runs, but no breakpoint. Again, very helpful.

- It seems Firebug is unable to handle function calls where the function 
to be called is not statically known. For example, if there's a Foo() 
function defined, and you do

   Foo(5);

then you can step into Foo(). However, if instead you do

   var Bar = Foo;
   Bar(5);

then Firebug apparently has *no clue* what function you just called. 
This is extremely limiting when you consider that my entire application 
is fundamentally based on this type of thing.

I wonder if any of this is likely to be fixed anytime soon?

Post a reply to this message

On 20/10/2010 04:42 PM, Invisible wrote:

> - As far as I can tell, breakpoints don't work. Like, I have a button
> that runs Bar() when you click it. So I put a breakpoint on Bar(), and
> click the button. The script runs, but no breakpoint. Again, very helpful.

OH MY GOD! >_<

It seems breakpoints work, but *only* if the exact line you put the 
breakpoint on contains a line of executable code.

So if you put the breakpoint on the function name, nothing happens. If 
you put the breakpoint on a line within the function that happens to be 
blank, nothing happens. If you put the breakpoint on a line that just 
contains a comment, nothing happens. *Only* if the line contains at 
least one executable statement does the breakpoint fire. WTF?

Post a reply to this message

Invisible wrote:
>  WTF?

This is called "bedding in."  It happens in all software (and, for that 
matter, in every bit of technology you need to practice with to learn). Now 
that you know that, you'll never try to breakpoint a comment again. In a 
year from now, when people bitch about how crappy the debugger is, you'll 
say "works for me! Must be your problem."

That's why you have to take everything people say about how great or how 
crappy some large well-know system is (like an OS or an office suite) with a 
grain of salt, especially when it's primarily a UI discussion.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible escreveu:
> So if you put the breakpoint on the function name, nothing happens. If 
> you put the breakpoint on a line within the function that happens to be 
> blank, nothing happens. If you put the breakpoint on a line that just 
> contains a comment, nothing happens. *Only* if the line contains at 
> least one executable statement does the breakpoint fire. WTF?

as Darren said.  Works the same in Delphi.

regarding var B = Foo; B(), I have no clue.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

> Now that you know that, you'll never try to breakpoint a comment again.

Well, so far this has tripped me over at least 17 times since I 
discovered what the problem was.

> In a year from now, when people bitch about how crappy the debugger is,
> you'll say "works for me! Must be your problem."

I can't believe that such a trivially fixable issue isn't fixed... In 
fact, I can't believe that nobody caught this in testing. When you fire 
up a debugger with support for breakpoints, literally THE FIRST THING 
you're going to do is try to stick breakpoints on top-level functions. 
How did this miss this?!

The next thing, of course, is that if I put a breakpoint on line 137, I 
now have to guess whether that means execution halts *before* line 137 
runs or *after* line 137 runs. In any normal debugger I could just put 
the breakpoint on line 136 or line 138 (assuming they're empty), but nooo...

I really can't believe somebody would go to the extreme lengths required 
to build something as complex as a debugger, and then release it while 
it's trivially broken. I mean, the effort to fix this glitch compared to 
the effort of developing the debugger in the first place...

Anyway, I guess none of this is going to fix my algorithm. I suppose 
it's a miracle that you can debug JavaScript at all. But *damn*!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/20/2010 11:25 AM, nemesis wrote:
>
> as Darren said. Works the same in Delphi.
>

Or, for that matter, the Visual Studio debugger, FWIW. But, Visual 
studio does something "clever": It moves the breakpoint if its not on a 
valid line to the next valid line once it has the debugging info for the 
module the code file belongs to.

-- 
~Mike

Post a reply to this message

Orchid XP v8 wrote:
> I can't believe that nobody caught this in testing. 

I can. That's exactly why the people who write the code should not be the 
people to test the code.  And that's exactly why code without documentation 
is worthless.

> When you fire 
> up a debugger with support for breakpoints, literally THE FIRST THING 
> you're going to do is try to stick breakpoints on top-level functions. 

Not if you wrote the debugger yourself and you know it only breakpoints on 
executable code.

> I really can't believe somebody would go to the extreme lengths required 
> to build something as complex as a debugger, and then release it while 
> it's trivially broken. 

Welcome to Open Source!

> I mean, the effort to fix this glitch compared to 
> the effort of developing the debugger in the first place...

I can completely understand a debugger for an interpreted language only 
being able to stop on executable lines. I can understand it especially if 
the interpreter wasn't written with breakpointing it in mind. If the person 
writing the interpreter for example compiled code into bytecodes and then 
marked each bytecode with what line it came from, and the guy writing the 
debugger stopped as soon as you hit a bytecode with the matching line 
number, and he can't tell what lines are valid to breakpoint on before the 
code is running because that's when the bytecode is generated, I'd think it 
would take a crapload of work to fix that "bug".

> Anyway, I guess none of this is going to fix my algorithm. I suppose 
> it's a miracle that you can debug JavaScript at all. But *damn*!

Actually, I thought it was pretty cool when I could put a breakpoint in code 
invoked by a web request and have it breakpoint. Man, I wish I had that 
capability when I was first writing CGI scripts.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Mike Raiford wrote:
> On 10/20/2010 11:25 AM, nemesis wrote:
>>
>> as Darren said. Works the same in Delphi.
>>
> 
> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual 
> studio does something "clever": It moves the breakpoint if its not on a 
> valid line to the next valid line once it has the debugging info for the 
> module the code file belongs to.
> 

I thought it was kind of funky-clever how they figured out when a statement 
ended.  They analyze the code and count pushes and pops, and a statement 
ends when the evaluation stack pops the last value off.  That's the 
definition of "one statement" in the CIL - the code between the first push 
and the matching pop that empties the data/operand stack.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> I really can't believe somebody would go to the extreme lengths
>> required to build something as complex as a debugger, and then release
>> it while it's trivially broken.
>
> Welcome to Open Source!

The next thing I'll be hearing is "patches welcome"...

> I can completely understand a debugger for an interpreted language only
> being able to stop on executable lines. I can understand it especially
> if the interpreter wasn't written with breakpointing it in mind. If the
> person writing the interpreter for example compiled code into bytecodes
> and then marked each bytecode with what line it came from, and the guy
> writing the debugger stopped as soon as you hit a bytecode with the
> matching line number, and he can't tell what lines are valid to
> breakpoint on before the code is running because that's when the
> bytecode is generated, I'd think it would take a crapload of work to fix
> that "bug".

You realise that the UI already highlights the lines that have code on 
them, right? So the code to figure this out already exists. All you have 
to do is look at where the user put the breakpoint, and select the 
nearest line that's executable. The only possibly-tricky thing is having 
the breakpoint set on line X+N put appear to be set on line X.

Failing that, you could just refuse to set a breakpoint on a line if it 
doesn't contain any executable code. That would be even more trivial to 
implement.

And yet Firebug does neither of these things.

>> Anyway, I guess none of this is going to fix my algorithm. I suppose
>> it's a miracle that you can debug JavaScript at all. But *damn*!
>
> Actually, I thought it was pretty cool when I could put a breakpoint in
> code invoked by a web request and have it breakpoint. Man, I wish I had
> that capability when I was first writing CGI scripts.

I'm still trying to find a way to run CGI binaries (note: binaries, not 
scripts) without having to install and configure Apache or something 
like it.

It seems there are plenty of light-weight HTTP servers, but all of them 
either lack CGI support entirely, or only support CGI *scripts* (usually 
in a single language).

Post a reply to this message

> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
> studio does something "clever": It moves the breakpoint if its not on a
> valid line to the next valid line once it has the debugging info for the
> module the code file belongs to.

I wouldn't have called that "clever". I would have called that "the most 
basic functionality that any non-toy debugger would be expected to 
have". Certainly I've never seen a debugger with this limitation 
before... (Although I can't claim to have used all that many debuggers.)

Post a reply to this message

Invisible wrote:
> You realise that the UI already highlights the lines that have code on 
> them, right? 

No, I haven't used it that much.

*You* should realize that I was speaking in more general terms. The kind of 
statement "This has to be trivial" or "This has to be obvious" is often 
mistaken, just like "this is obviously impossible" has been slowly being 
beaten out of your vocabulary.  ;-)

Now, I will say, when I bought a compiler for a language touting how easy it 
is to write correct programs, and I got it out and pushed the button for 
"make me a Hello World skeleton project to start with", then pushed the 
"Compile" button and got syntax errors, I felt like "how could you release 
such a POS as an expensive compiler?"  So I'm not saying it's never justified.

> So the code to figure this out already exists. All you have 
> to do is look at where the user put the breakpoint, and select the 
> nearest line that's executable. The only possibly-tricky thing is having 
> the breakpoint set on line X+N put appear to be set on line X.

I would just move the breakpoint. What would be tricky is if you click 
between two functions - do you breakpoint the last line of the previous 
function or the first line of the next function?

> I'm still trying to find a way to run CGI binaries (note: binaries, not 
> scripts) without having to install and configure Apache or something 
> like it.

tclhttpd?

> It seems there are plenty of light-weight HTTP servers, but all of them 
> either lack CGI support entirely, or only support CGI *scripts* (usually 
> in a single language).

I'm pretty sure tcl httpd supports CGI and FastCGI.  If not, it's pretty 
trivial to do so. Basically, copy some header crap into environment 
variables, pipe the incoming request to stdin of the CGI, and pipe the 
stdout back to the browser.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible wrote:
>> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
>> studio does something "clever": It moves the breakpoint if its not on a
>> valid line to the next valid line once it has the debugging info for the
>> module the code file belongs to.
> 
> I wouldn't have called that "clever". 

Note he didn't call it clever. He called it "clever".



-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

> *You* should realize that I was speaking in more general terms. The kind
> of statement "This has to be trivial" or "This has to be obvious" is
> often mistaken, just like "this is obviously impossible" has been slowly
> being beaten out of your vocabulary. ;-)

>> So the code to figure this out already exists. All you have to do is
>> look at where the user put the breakpoint, and select the nearest line
>> that's executable. The only possibly-tricky thing is having the
>> breakpoint set on line X+N put appear to be set on line X.
>
> I would just move the breakpoint.

Or you could do that, yes.

> What would be tricky is if you click
> between two functions - do you breakpoint the last line of the previous
> function or the first line of the next function?

Or the first statement outside of a function? Or just refuse to set a 
breakpoint there? There's several possible options.

>> It seems there are plenty of light-weight HTTP servers, but all of
>> them either lack CGI support entirely, or only support CGI *scripts*
>> (usually in a single language).
>
> I'm pretty sure tcl httpd supports CGI and FastCGI. If not, it's pretty
> trivial to do so. Basically, copy some header crap into environment
> variables, pipe the incoming request to stdin of the CGI, and pipe the
> stdout back to the browser.

Constructing and parsing HTTP headers yourself also isn't all that 
hard... and yet it turns out to be unexpectedly non-trivial to do a 
really good job of it yourself. Especially when you're not actually 
trying to write a web server, you just want something to test your CGI with.

Post a reply to this message

Invisible wrote:
> Constructing and parsing HTTP headers yourself also isn't all that 
> hard... 

It didn't *used* to be. Now so much crap has been added to HTTP to support 
everyone using it for something other than hypertext transport that yeah, 
actually parsing the headers and doing the protocol turns out to be pretty 
non-trivial.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 22/10/2010 04:49 PM, Darren New wrote:
> Invisible wrote:
>> Constructing and parsing HTTP headers yourself also isn't all that
>> hard...
>
> It didn't *used* to be. Now so much crap has been added to HTTP to
> support everyone using it for something other than hypertext transport
> that yeah, actually parsing the headers and doing the protocol turns out
> to be pretty non-trivial.

http://www.w3.org/Protocols/HTTP/AsImplemented.html

Woah! That's pretty... um... special, right there.

Hmm, I wonder if any modern software actually handles HTTP 0.9 correctly?

Post a reply to this message

Invisible wrote:
> Woah! That's pretty... um... special, right there.

Yep. Like all good protocols ;-) it doesn't have a version number in the 
first version. That's why the "HTTP/1.0" comes at the end of the request 
instead of the beginning.

*Almost* everything since then has been to deal with the fact that HTTP 
isn't being used for transporting hypertext, or to add all the features that 
all the other data transfer protocols already had.

> Hmm, I wonder if any modern software actually handles HTTP 0.9 correctly?

Most web browsers do, yes. When I want to see if something is actually 
running a web server, I'll often telnet in by hand and just "GET /" to see 
that I get some sort of answer.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible wrote:
> Woah! That's pretty... um... special, right there.

Oh, and it's also the first internet protocol that said you had to be able 
to handle any kind of line terminator.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Wed, 20 Oct 2010 18:55:25 +0100, Orchid XP v8 wrote:

> When you fire
> up a debugger with support for breakpoints, literally THE FIRST THING
> you're going to do is try to stick breakpoints on top-level functions.
> How did this miss this?!

Not me, because it seems obvious that only code that executes can be 
halted by a breakpoint.  I can't think of a debugger I've ever used that 
lets you set a breakpoint on non-executable code.  Or if I have, I've 
never needed to use that functionality.

Jim

Post a reply to this message

On 25/10/2010 04:31 PM, Jim Henderson wrote:
> On Wed, 20 Oct 2010 18:55:25 +0100, Orchid XP v8 wrote:
>
>> When you fire
>> up a debugger with support for breakpoints, literally THE FIRST THING
>> you're going to do is try to stick breakpoints on top-level functions.
>> How did this miss this?!
>
> Not me, because it seems obvious that only code that executes can be
> halted by a breakpoint.  I can't think of a debugger I've ever used that
> lets you set a breakpoint on non-executable code.  Or if I have, I've
> never needed to use that functionality.

It's pretty self-evident that if you put a breakpoint on the name of a 
function, you want it to break every time that function is called.

(It's also pretty self-evident that having some visual feedback about 
where you can and can't put breakpoints would help enourmously.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/25/2010 3:52 PM, Orchid XP v8 wrote:

> It's pretty self-evident that if you put a breakpoint on the name of a
> function, you want it to break every time that function is called.
>
> (It's also pretty self-evident that having some visual feedback about
> where you can and can't put breakpoints would help enourmously.)
>

Remember: The function declaration is just that: A declaration. It has 
no code. Depending on the compiler and execution environment the actual 
code will be the first statement with the potential addition of 
declarations of variables with assignment.

On the second point. Yeah, I agree it would be nice.

-- 
~Mike

Post a reply to this message

On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:

> It's pretty self-evident that if you put a breakpoint on the name of a
> function, you want it to break every time that function is called.

Perhaps, but it's also self-evident that the function *name* isn't 
executed, so it makes no sense to set a breakpoint on a line that 
contains non-executable code, since a breakpoint interrupts the flow of 
*executable* code. ;-)

> (It's also pretty self-evident that having some visual feedback about
> where you can and can't put breakpoints would help enourmously.)

Now *that* I can't argue with. ;-)

Jim

Post a reply to this message

On 26/10/2010 04:27 PM, Jim Henderson wrote:
> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>
>> It's pretty self-evident that if you put a breakpoint on the name of a
>> function, you want it to break every time that function is called.
>
> Perhaps, but it's also self-evident that the function *name* isn't
> executed

Oh really?

> so it makes no sense to set a breakpoint on a line that
> contains non-executable code, since a breakpoint interrupts the flow of
> *executable* code. ;-)

Until now, I haven't seen a debugger that prohibits you putting 
breakpoints on (say) a completely empty line. I mean, hell, isn't the 
debugger's job supposed to be to make your job *easier*? :-P

> Now *that* I can't argue with. ;-)

Heh. All it needs now is for some helpful soul to suggest that I submit 
a source code patch. :-P

Post a reply to this message

On Tue, 26 Oct 2010 16:38:18 +0100, Invisible wrote:

> On 26/10/2010 04:27 PM, Jim Henderson wrote:
>> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>>
>>> It's pretty self-evident that if you put a breakpoint on the name of a
>>> function, you want it to break every time that function is called.
>>
>> Perhaps, but it's also self-evident that the function *name* isn't
>> executed
> 
> Oh really?

Yes, really.  A function name is non-executable code - it's a reference.

>> so it makes no sense to set a breakpoint on a line that contains
>> non-executable code, since a breakpoint interrupts the flow of
>> *executable* code. ;-)
> 
> Until now, I haven't seen a debugger that prohibits you putting
> breakpoints on (say) a completely empty line. I mean, hell, isn't the
> debugger's job supposed to be to make your job *easier*? :-P

You've never used Borland's C compiler then.  Or MASM, or TASM. ;-)

How exactly does it make the job easier if the debugger lets you set 
breakpoints in places that logically make absolutely no sense?

>> Now *that* I can't argue with. ;-)
> 
> Heh. All it needs now is for some helpful soul to suggest that I submit
> a source code patch. :-P

Well, submit a patch. ;-)

You're welcome.

Jim

Post a reply to this message

> Yes, really.  A function name is non-executable code - it's a reference.
>
> How exactly does it make the job easier if the debugger lets you set
> breakpoints in places that logically make absolutely no sense?

I'd argue that setting a breakpoint on a function name means the code breaks 
every time that function is called.  That seems pretty logical to me.

Post a reply to this message

Mike Raiford wrote:
> Remember: The function declaration is just that: A declaration. It has 
> no code. 

That's your inner nerd speaking.

The actual answer is "if he tries to put a breakpoint on the function name, 
he wants to breakpoint when the function is called, so we'll actually put 
the breakpoint on the first executable statement of the function."

This is exactly the way in which open source software tends to suck: written 
by geeks, for geeks, which is great unless you're not a geek. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Tue, 26 Oct 2010 17:05:31 +0100, scott wrote:

>> Yes, really.  A function name is non-executable code - it's a
>> reference.
>>
>> How exactly does it make the job easier if the debugger lets you set
>> breakpoints in places that logically make absolutely no sense?
> 
> I'd argue that setting a breakpoint on a function name means the code
> breaks every time that function is called.  That seems pretty logical to
> me.

If I want to do that, I'll set it up on the first line of executable code 
in the function.  That makes logical sense to me.

If I go into, say, the NetWare kernel debugger (which I have spent many, 
many months in), I can set a breakpoint at a "function", but the function 
is a reference to the first executable line of machine code inside the 
function IIRC (Now I think of it, it might be on the call itself - I may 
need to restart my VM and look again at that).

Jim

Post a reply to this message

On 10/26/2010 12:33 PM, Darren New wrote:
> Mike Raiford wrote:
>> Remember: The function declaration is just that: A declaration. It has
>> no code.
>
> That's your inner nerd speaking.
>

I don't think it's inner :)

>
> This is exactly the way in which open source software tends to suck:
> written by geeks, for geeks, which is great unless you're not a geek. :-)
>

YES! Exactly. Though I do like some OSS projects. But this is a major 
issue with OSS is it tends to be developed with exactly that mindset.

-- 
~Mike

Post a reply to this message

>> This is exactly the way in which open source software tends to suck:
>> written by geeks, for geeks, which is great unless you're not a geek. :-)
>
> YES! Exactly. Though I do like some OSS projects. But this is a major
> issue with OSS is it tends to be developed with exactly that mindset.

"Patches welcome."

Post a reply to this message

Invisible wrote:
>>> This is exactly the way in which open source software tends to suck:
>>> written by geeks, for geeks, which is great unless you're not a geek. 
>>> :-)
>>
>> YES! Exactly. Though I do like some OSS projects. But this is a major
>> issue with OSS is it tends to be developed with exactly that mindset.
> 
> "Patches welcome."

Oh, yes, that works great.

Problem: Only programmers are comfortable with the program.

Solution: Submit code.

Yeah. Think about that one.
-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> "Patches welcome."
>
> Oh, yes, that works great.
>
> Problem: Only programmers are comfortable with the program.
>
> Solution: Submit code.
>
> Yeah. Think about that one.

I suspect that the open source model can work - but only for the 
products that are so popular that there's a crapload of users trying it 
out, and a crapload of developers sufficiently motivated to fix the 
"boring" stuff.

Obligatory XKCD reference: http://xkcd.com/619/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> I suspect that the open source model can work  

Or for software developed for use by developers (i.e., compilers, editors, 
etc) or software developed by companies that sell software-complements, like 
hardware. OpenOffice didn't show up because programmers wanted to write an 
office suite. OpenOffice showed up because Sun wanted to sell SPARCstations 
and couldn't without having MS Office on them.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Wed, 27 Oct 2010 14:41:35 -0700, Darren New wrote:

> OpenOffice showed up because Sun wanted to sell SPARCstations and
> couldn't without having MS Office on them.

Well, OpenOffice was previously StarOffice, made by the company 
StarDivision.  It was originally closed-source and cross-platform.  Sun 
bought StarDivision, but Sun certainly didn't start the OpenOffice 
product.

Jim

Post a reply to this message

On 28/10/2010 06:26 AM, Jim Henderson wrote:
> On Wed, 27 Oct 2010 14:41:35 -0700, Darren New wrote:
>
>> OpenOffice showed up because Sun wanted to sell SPARCstations and
>> couldn't without having MS Office on them.
>
> Well, OpenOffice was previously StarOffice, made by the company
> StarDivision.  It was originally closed-source and cross-platform.  Sun
> bought StarDivision, but Sun certainly didn't start the OpenOffice
> product.

Sun? Heh. I'm still getting used to the fact that now when I install 
OpenOffice, it was Oracle plastered all over it. (I'm pretty sure under 
Sun the corporate branding was much less in-your-face. Also, the colour 
scheme was nicer. Oracle has given it a kind of blank-white look, like 
they didn't finish it or something...)

Post a reply to this message

On 10/27/2010 7:50 AM, Invisible wrote:

> "Patches welcome."

<rips a square of canvas> Here's your patch ;P
-- 
~Mike

Post a reply to this message

On Thu, 28 Oct 2010 09:10:09 +0100, Invisible wrote:

> On 28/10/2010 06:26 AM, Jim Henderson wrote:
>> On Wed, 27 Oct 2010 14:41:35 -0700, Darren New wrote:
>>
>>> OpenOffice showed up because Sun wanted to sell SPARCstations and
>>> couldn't without having MS Office on them.
>>
>> Well, OpenOffice was previously StarOffice, made by the company
>> StarDivision.  It was originally closed-source and cross-platform.  Sun
>> bought StarDivision, but Sun certainly didn't start the OpenOffice
>> product.
> 
> Sun? Heh. I'm still getting used to the fact that now when I install
> OpenOffice, it was Oracle plastered all over it. (I'm pretty sure under
> Sun the corporate branding was much less in-your-face. Also, the colour
> scheme was nicer. Oracle has given it a kind of blank-white look, like
> they didn't finish it or something...)

That's one reason I use the Novell edition. :-)

Jim

Post a reply to this message

>> Sun? Heh. I'm still getting used to the fact that now when I install
>> OpenOffice, it was Oracle plastered all over it. (I'm pretty sure under
>> Sun the corporate branding was much less in-your-face. Also, the colour
>> scheme was nicer. Oracle has given it a kind of blank-white look, like
>> they didn't finish it or something...)
>
> That's one reason I use the Novell edition. :-)

Actually, come to think of it, I'm still getting used to the fact that a 
huge, highly successful company like Sun somehow got bought by a much 
smaller company like Oracle. You wouldn't have thought they could do that...

Post a reply to this message

Jim Henderson wrote:
> Sun bought StarDivision, but Sun certainly didn't start the OpenOffice 
> product.

No, but they open-sourced it.  I.e., it wasn't free software, it was 
commercial software that turned into libre software.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Thu, 28 Oct 2010 10:35:41 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Sun bought StarDivision, but Sun certainly didn't start the OpenOffice
>> product.
> 
> No, but they open-sourced it.  I.e., it wasn't free software, it was
> commercial software that turned into libre software.

True, I had forgotten that part of the process - StarOffice and 
OpenOffice coexisted for a while and it's been 10 years.... :-)

Jim

Post a reply to this message

On Thu, 28 Oct 2010 16:47:54 +0100, Invisible wrote:

>>> Sun? Heh. I'm still getting used to the fact that now when I install
>>> OpenOffice, it was Oracle plastered all over it. (I'm pretty sure
>>> under Sun the corporate branding was much less in-your-face. Also, the
>>> colour scheme was nicer. Oracle has given it a kind of blank-white
>>> look, like they didn't finish it or something...)
>>
>> That's one reason I use the Novell edition. :-)
> 
> Actually, come to think of it, I'm still getting used to the fact that a
> huge, highly successful company like Sun somehow got bought by a much
> smaller company like Oracle. You wouldn't have thought they could do
> that...

It happens all the time.  I worked in the food & drug retail industry 
before coming to Novell, and the company I worked for was acquired by a 
smaller company (both were in the Fortune 50, though).

Jim

Post a reply to this message