Frank Gevaerts wrote:
> Thoughts?
I agree with your plan. Ask for one ID per target, make use of whatever we get.
As for buying our own ID space, I'm not sure I think that is the best use of
donations.
--
Björn
Am 29.05.2012 18:34, schrieb Rafaël Carré:
Without -g:
make -j8 293,60s user 17,61s system 690% cpu 45,075 total
$ du -chs .
34M .
With -g:
make -j8 321,22s user 19,88s system 688% cpu 49,556 total
$ du -chs .
99M .
My SSD will not like this :'( I'm also suprised compile time is imp
Am 29.05.2012 22:11, schrieb Frank Gevaerts:
* Do we want one id per target (I think ideally we do)? Or even one id
per "main" protocol (so we'd use e.g. a different id for MSC than for
MTP (whenever we get MTP support)) (this would mosy probably be asking
too much from the openmoko folk
On Tue, May 29, 2012 at 9:40 PM, Frank Gevaerts wrote:
> On Tue, May 29, 2012 at 08:48:42PM +0200, Lorenzo Miori wrote:
>> Yes. Atomic tests. Not just saying playback, you're right, it's too wide.
>
> Yes, but that wasn't really my point :) What I mean is that we should
> have a *small* basic test
On Tue, May 29, 2012 at 3:27 PM, Michael Sparmann wrote:
> +1, and I think 256 IDs are not all that much. They probably have a
> block of 65536 addresses, and acquiring such a block only costs a
> one-time fee of $2000. So we'd basically be asking them for about $10
> worth of IDs.
$2000 doesn't
> * Do we want one id per target (I think ideally we do)? Or even one id
> per "main" protocol (so we'd use e.g. a different id for MSC than for
> MTP (whenever we get MTP support)) (this would mosy probably be asking
> too much from the openmoko folks)
+1, and I think 256 IDs are not all th
Am 29.05.2012 20:49, schrieb Frank Gevaerts:
> On Tue, May 29, 2012 at 06:20:48PM +0200, Bertrik Sikken wrote:
>> How about enabling option -g by default?
>
> I'm in favour.
>
> Frank
>
+1
signature.asc
Description: OpenPGP digital signature
2012/5/29 Frank Gevaerts
> Hi,
>
> Apparently the Openmoko people distribute USB ids to selected projects
> and communities that ask for them.
> (see http://wiki.openmoko.org/wiki/USB_Product_IDs#Conditions
> and
> http://laforge.gnumonks.org/weblog/2012/05/21/#20120521-open_registry_for_usb_and_
Hi,
Apparently the Openmoko people distribute USB ids to selected projects
and communities that ask for them.
(see http://wiki.openmoko.org/wiki/USB_Product_IDs#Conditions
and
http://laforge.gnumonks.org/weblog/2012/05/21/#20120521-open_registry_for_usb_and_mac_addrs)
I think we should seriously
On Tue, May 29, 2012 at 08:48:42PM +0200, Lorenzo Miori wrote:
> Yes. Atomic tests. Not just saying playback, you're right, it's too wide.
Yes, but that wasn't really my point :) What I mean is that we should
have a *small* basic test suite (which, yes, consists of clear
unambiguous and simple tes
On Tue, May 29, 2012 at 06:20:48PM +0200, Bertrik Sikken wrote:
> How about enabling option -g by default?
I'm in favour.
Frank
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enou
Yes. Atomic tests. Not just saying playback, you're right, it's too wide.
And yes, plugin or other high level functionalities have to be
debugged later: it's a music player after all :D
Lorenzo
2012/5/29 Frank Gevaerts :
> On Tue, May 29, 2012 at 06:58:53PM +0200, Bertrik Sikken wrote:
>> With re
On Tue, May 29, 2012 at 06:58:53PM +0200, Bertrik Sikken wrote:
> With respect to test strategy: In my opinion, we can start with
> a set of rather basic tests to verify high-level behaviour, rather
> than to go for test completeness. A test suite taking about (say)
> one hour should keep the barri
I just read the email about the test cases: well it is a very good
idea. I completely agree this and actually doing a project with a
methodology can help quite a lot.
I don't know if you guys are aware of the "agile" methodologies, well
look for "user stories" and "acceptance tests" (XP/Scrum and A
Hi all,
Last week at devcon euro 2012 we talked about pre-release testing and
I'm volunteering to help things forward w.r.t. testing.
One of the problems we've seen with the last release was that really
basic functionality like audio file playback and radio playback did
not work on some targets a
Le 29/05/2012 12:20, Bertrik Sikken a écrit :
> Hi all,
>
> While debugging a problem using our shiny new ARM backtrace feature,
> I noticed that by default, we're not building with -g (= include
> debugging information in the binary). This means that with the
> default build, I can't get the sour
Hi all,
While debugging a problem using our shiny new ARM backtrace feature,
I noticed that by default, we're not building with -g (= include
debugging information in the binary). This means that with the
default build, I can't get the source code line from the backtrace
addresses (with arm-elf-ea
17 matches
Mail list logo
