From: BlueChip <cs_bluechip_at_webtribe.net>
Date: Wed, 17 Dec 2003 15:33:00 +0000

> > >If you can build it yourself, why use the 2.1 release code?
> > Do you really need/want an answer to the above question?
>Even if you can't use CVS for whatever reason, you can still get a daily
>tarball that has newer code than 2.1.

Is that a yes or a no?
fwiw, your guess (if that is what it is) is waaaaay off mark!

> > > > 4 warnings during compile:
> > >These warnings showed up in the build table for months before we fixed
> them,
> > >*after* the 2.1 release...
> > I didn't realise that the official release of v2.1 had known bugs that
> > stopped a successful compile. How ironic (qv. 1st question)
>Compiler warnings don't stop "a successful compile". They are just warnings.

I'm glad YOU don't work on critical systems.

> > >Hm. Why do you get problems with this when others have not seen them? I'm
> > >just curious so that fixing this with your proposal don't break it for
> > >others.
> > Can you name users that have seen this feature working correctly so that I
> > may discuss it with them?
>
>Back off.

OKAY ...I'VE BACKED OFF ...BUT NOW I AM SO FAR AWAY, I WILL HAVE TO SHOUT
TO YOU
Come on dude ...You made it up ...I called you on it.
Learn to lose with dignity ;)

>No, I don't generally write down the names of people that do things or that
>say things that I afterwards believe I remember. I may even be mistaking.

The word is "mistaken", and aside of the irony ...yes, when you make stuff
up, you will OFTEN be mistaken.

So are you gonna offer ANY credibility to your words, or shall we just
realise that you are (as they say in UK) "full of it"

>Can't you at all understand my hesitation here?

Clearly not. Can you explain it?

>This code has been like this since the very first win32 simulator (brought
>by edx).

Strangely enough, it worked back then!
It was broken back around June of this year, as I recall.

>It just have to have worked for some people at some point, and I want to
>understand why it works
>for some and don't work for some before we go ahead and change it as you
>described.

So to help, you make a bunch of stuff up and get upset when you get caught
out.
Hmmmmmmmm, wouldn't have been my first approach.

> > >When you run the tools/configure it creates a define in the makefile for
> > >what target model you build for. In the source code, the
> > >firmware/export/config.h is included and that checks what model you build
> > >for and include the proper config-*.h header file, in which those defines
> > >are defined.
> >
> > Yes, I thought that too - but it doesn't ...for either me or earHertz. I
> > wonder why it works for you?
>
>I'd rather reverse the question, why doesn't it work for you? What parts
>of my description above fails for you?

The _description_ is fine. But when you actually try this, you too wil
understand that it fails.
If I knew precisely why it fails, I would have included the fix in my email
...then you would have had to make up different imaginary facts to start an
argument :)

> > Can/Will you supply more accurate information about your development
> > environment?
>I don't think that is necessary to track down the problem you experience. Lots
>of people build Rockbox just fine, on both windows and Linux/unix.

You really are scared of me, aren't you?
Don't be afraid, little dude, I'm not gonna stamp on you :(

>I build Rockbox for all models/targets on several different linux machines,
>using different versions of the sh-elf compilers as well as the native
>compilers.

So you don't even have access to the right kit to test my observations.
Perhaps you should only reply to posts when you can be helpful?

I look forward to HELPFUL comments ONLY from you in future :)
...unless that is too hard for you? ...go on, prove me wrong :)

((Don't you hate those double binds ...the only way to prove me wrong is
not to reply - LOL))

> > > > main_menu options Plugins and Firmware do not work that is, selecting
> > > > those options does nothing, it just leaves you on the main_menu screen
> > > > this means that plugins cannot be used or tested in the simulator
> > >No clue.
> > Which O.S. did you test it on?
>I haven't tested that in a long while, but I only develop Rockbox (and run the
>simulator) on Linux.

Righty, so you are commenting on something that you know nothing about!
I wish I'd known that when I read your last reply ...and there was me
thinking you knew what you were talking about, when all you wanted to do
was start a new argument on the list ...D'OH! One would think I should
know you better by now.

>The win32 version often lags behind in functionality, so perhaps there's a
>flaw in there.

woo hoo - you mean there is a chance that I could be right? WOW! Who'd've
guessed it?

> > ????? ...You don't know what type of bullets I use ;)
>I'm sorry, but I don't understand. Why is the above quote not a good
>description of how to make a patch? What else do we need to explain?

The answer to that question was in my last email ...see below:

> > >-N "treat absent files as empty"
> > bingo! diff file which includes objects, makefiles, .deps, .rocks, etc.
> > etc. etc.
>
>Yes, you can do that if you want.

Can you advise something more helpful? <- see question mark :)

>You can also exclude files, or just edit the
>patch file after having generated it in your favourite text editor.

I missed that bit on the URL, whoops.

So how does one exclude these files easily?

Is there an easy way to text edit these files?
(this is how I did it last time, and it was a sh!tty job)

> > Anyway, I am sure I can work it out one way or another. As you said at the
> > top, it is good to repeat other peoples work, it makes you bored :)
>
>That's not what I said.

/me looks you square in the eyes so you can detect the utter embafflement

You said repeating the work of others is what you want me to do, and that
is good because it is boring! no?

BC

PS. You know I am relentless, so why not stop now, rather than give up
after 10 emails like you did last time?
Received on 2003-12-17