DIY - KeK

[knc1]

Originally Posted by twobob

I concur with this thought. something that is x-system and free does indeed provide the facilities you mention, also opens the door for IDE level kindle-ising modifications that could be shared.

Resource pool now has 32bit/64bit; MacOSx, Windows, and Linux Eclipse-CDT included.
Top post and the partial, draft documentation updated at:
http://knetconnect.com/KeK/KeK_reference.xhtml

[geekmaster]

I have linux codesourcery linked into my linux code:blocks IDE, and I have win32 codesourcery linked into my win32 code:blocks IDE. It works quite nicely, but I find in linux I still mostly do make at the command line (or just gcc for my monolithic demos).

I have never used Eclipse -- how is it better than code:blocks?

[knc1]

Originally Posted by geekmaster

I have never used Eclipse -- how is it better than code:blocks?

No comparison implied.
As I posted, the choice is a matter of personal preference.
The only two active members agreed on Eclipse-CDT, so that is what is in our resource pool.
But we did leave the entire Internet open for those who want something else.

[knc1]

Originally Posted by geekmaster

Regarding the possible pachinko filter patent, I have had success finding prior art.

Link(s)?
A total waste of ego boosting red ink without references or citations.

[geekmaster]

Originally Posted by knc1

Link(s)?
A total waste of ego boosting red ink without references or citations.

I did not mean prior art for THIS patent (sorry for the confusion). I meant I have had success finding prior art for compression indexing algorithms I was working on (which I think I mentioned somewhere). I said that to suggest such success may be achievable with the pachinko filter thingy with sufficient research.

[knc1]

Originally Posted by geekmaster

I did not mean prior art for THIS patent (sorry for the confusion).

Prior Art searches can become very time (or money) consuming.
For the non-USA readers, a "PriorArt" search is a requirement here.

There are also the basic requirements of "Novel and Non-Obvious" (to an expert in the field).
So in this instance, I thought I would start with those two points by asking someone "who should know" as an "expert in the field".

There are also the filings of "Trivial Patents" in the software field, same as in the mechanical field. Ones that are the software equivalent of patenting Fire or the Wheel.

- - - -

Hmm...
I had better make a position statement for the followers of this thread:

I personally oppose the concept of "Software Patents" but I also know that there are also those who avidly support them.

I hope to find a path that will satisfy both sides here -
Where those who support SP will not feel they are "giving away trade secrets"; and:
Where those who oppose SP will not feel their contribution will become part of any SP.

The issue of Copyright in a community supported project is (relatively) easy to handle - the policy statement here is: "The Author Retains any Copyright" - the author wrote it, it is theirs.
And the project uses that authorship work under the terms of whatever license the author might grant.

Note to non-USA readers: Just attaching your name as author to any work of authorship is usually sufficient in the USA (the country of publication in this case) to establish a copyright interest.

Too bad our patent laws aren't that simple.

Just in case any reader has gotten lost in this thread -
The subject of the moment is "rights" associated with any contributed filter configuration. (The filter configuration file itself that is contributed is a "work of authorship" - subject to copyright here.)

[knc1]

This movement might be worth looking into:
http://www.openinventionnetwork.com/..._agreement.php
Everyone agrees to play nice, no food fights allowed, no hair pulling, etc.

[knc1]

Draft of the first two technical appendices done.
Hyperlinks added to the descriptions of the most commonly used resources.
Rough draft of the Legal section.
Top post of thread updated and on-line rough draft updated.
- - -
Next, put some words in the end-user, HowTo parts of the outline.

[twobob]

bash-4.1$ pwd
~/REPOS/kek.hg

bash-4.1$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Am I doing something wrong?

[knc1]

Originally Posted by twobob

bash-4.1$ pwd
~/REPOS/kek.hg

bash-4.1$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Am I doing something wrong?

hg pull
hg update
hg log | less
and find:

changeset:   16:fe24a0c9883a
tag:         tip
user:        knc1 <knc1@knetconnect.com>
date:        Wed Jul 04 12:38:32 2012 -0500
summary:     Completed appendix A, added initial license terms.

as the most recent change.

[twobob]

I really am a (insert choice here), Clearly need to get a bit more sleep.

Am pulling it down now. thanks knc1

[knc1]

Originally Posted by knc1

The Windows binaries of the most recent CodeSorcery/MentorGraphics public tool-chain seem to be the popular download.
With the Linux binaries running in second place.

Hope that means somebody is getting some use out of this pool of resources.

Those archives of the most recent CS/MG public tool-chain release are remaining the most popular download.
Running 75:25, Win32:Linux32
This project is still short on user directions but as a resource pool, it is being useful to some people.

[twobob]

I concur. I use it as my first reference now.

Essential

[twobob]

Hi Knc1

I'm having some difficulty with my X-compiler toolchain.

I'll post the grisly details here

Spoiler:

bash-4.1$ arm-linux-gcc --static -o testie Balsamic.c -lasound -lpthread -lm -lrt

/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/usr/lib/libasound.a(pcm_dmix.o): In function `snd_pcm_dmix_sync_ptr':
pcm_dmix.c.text+0x245c): warning: Warning: snd_pcm_hwsync() is deprecated, consider to use snd_pcm_avail()

/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/usr/lib/libasound.a(pcm_direct.o): In function `snd1_pcm_direct_parse_open_conf':
pcm_direct.c.text+0x5184): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/usr/lib/libasound.a(control_shm.o): In function `_snd_ctl_shm_open':
control_shm.c.text+0x1ad8): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

now as it goes I don't use those methods directly but the underbelly of ALSA might so I'm trying to get rid of it.

There is a reasonable article here that Indicates seemingly a similar issue?
http://stevehanov.ca/blog/index.php?id=97

And also a reference to bugs in busybox and other seemingly unrelated information.
I understand what the warning means, I am just unsure why I seem to have a never version that I should - or something. thanks.

So I thought I should go for the Kek standard advised version of the Code sourcery ones.

I currently have arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2012.03-57) 4.6.3

You reference : arm-2012.03-57-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
as the latest one so do I have the right one already?

GM appears to use CodeSourcery 2010q1-202 - is why I ask, I'm just looking for some guidance I guess, thanks again.

[geekmaster]

@twobob: I was getting those errors too on static builds at first. For static compiles, before compiling the alsa lib you need to run alsa configure with " --enable-static --disable-shared" (and I used a few more too as suggested by NiLuJe). You can read what I used here: https://www.mobileread.com/forums/sho....php?p=2146686

I upgraded to CS 2010q1-202 because it fixed some little documented compiler bug that had bitten me on a previous build. I do not remember what now, but I am pretty sure that it is documented somewhere in one of my almost 3K posts somewhere in this forum.