freekode-public — Main development list.

Re: [Freekode-public] project status and contribution

[Pedro Â. <pa...@vo...>]

On 17/12/11 04:28, Daniel Kirchner wrote:
> Hi there,
>
> it seems that the last activity here happend years
> ago and even then the last real question on the mailing list was,
> whether the project was still alive or not...
> The question is now, whether there's still somebody at all out there
> taking care of this project who can respond to me - I really want and
> need an open source implementation of OpenKODE and would love to
> contribute to your project - first of all by finishing the linux part. I
> could spare quite some time to invest in this project, so I hope I hear
> from you soon!
>
> Regards,
> Daniel Kirchner

Hello Daniel,

I guess I'm the current maintainer for the project, but nor I nor the 
original devs have any time to work on it. I might pick it up again 
soon-ish for my phd work but I son't know when that will happen.

It's great that you're interested in hacking on this codebase. Let me 
know what I can do to help you out.

Best regards,

Pedro Ângelo

[Freekode-public] project status and contribution

[Daniel K. <da...@ek...>]

Hi there,

it seems that the last activity here happend years
ago and even then the last real question on the mailing list was,
whether the project was still alive or not...
The question is now, whether there's still somebody at all out there
taking care of this project who can respond to me - I really want and
need an open source implementation of OpenKODE and would love to
contribute to your project - first of all by finishing the linux part. I
could spare quite some time to invest in this project, so I hope I hear
from you soon!

Regards,
Daniel Kirchner

Re: [Freekode-public] Where can download freekode

[Ricky 淮 <ri...@ca...>]

Dear Richardo:
Thanks a lot.
I can checked out the sources now.

2009/12/28 Ricardo Sabino <rik...@gm...>

> Hi,
> I think the sources are only available in the SVN repository.
>
>
> On Sun, Dec 27, 2009 at 08:46, Ricky 淮 <ri...@ca...> wrote:
>
>> Hi~everybody~
>> I can't download the sources from sourceforge.
>> Does anyone know where can download it?
>> Thanks.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Freekode-public mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freekode-public
>>
>>
>

Re: [Freekode-public] Where can download freekode

[Ricardo S. <rik...@gm...>]

Hi,
I think the sources are only available in the SVN repository.


On Sun, Dec 27, 2009 at 08:46, Ricky 彣淮 <ri...@ca...> wrote:

> Hi~everybody~
> I can't download the sources from sourceforge.
> Does anyone know where can download it?
> Thanks.
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public
>
>

[Freekode-public] Where can download freekode

[Ricky 淮 <ri...@ca...>]

Hi~everybody~
I can't download the sources from sourceforge.
Does anyone know where can download it?
Thanks.

[Freekode-public] ABOUT FREEKODE

[swapnil s. <swa...@gm...>]

Hello ,

 I have read in khorns group form that..you are currently working on
implementations for Windows, Windows Mobile, MacOS-X and Linux.  I
look this link too   http://sourceforge.net/projects/freekode .. but I
am not able to access files ...please can you help me .........how can
i go through.

Currently I want to take  referrence for Windows and Linux.

Looking forward for your support..........

Hope you will reply me soon


Thanks &Regards
swapnil shrotriya

[Freekode-public] Is the project still alive?

[Савченков В. <i7...@ya...>]

I would like to know whether this project is still alive (because it doesn't look like it is).
It will help me to decide between joining this project and starting a fork (well, if only forks with one tine exist...).

Thank you.

Re: [Freekode-public] Status of the project

[Diogo T. <fo...@gm...>]

Hey Pedro,

I'm glad to see you're still very motivated!

My problem right now is a big load here at work.
I hope that in Feb I'll be a bit more loose and maybe I'll be able help out
a bit.

I've added Balaji to the project. Let's get this thing going.

Regards,

Diogo


On Thu, Jan 29, 2009 at 11:20 PM, Pedro Ângelo <pa...@vi...>wrote:

> On Wed, 28 Jan 2009 22:02:48 +0530
> Balaji Rao <bal...@gm...> wrote:
>
> > Hi all,
> >
> > First I would like to thank those who started this project.
> >
> > It is so unfortunate that the the development is completely stalled.
> > Can anyone please enlighten me why is it so ?
>
> Hello Balaji,
>
> Thanks for checking in about FreeKode. I wouldn't say the project
> is stalled, it's more like it's progressing at a glaciar pace :)
>
> We are still very interested in it, but I'm guessing that lack of time
> and projects using FreeKode to drive it's development has
> taken it's toll on project activity.
>
> > If the project is looking for contributors, that's what I'm here for.
> > So it would be very helpful if someone briefed about the status of the
> > project.
>
> We are always looking for contributors :)
>
> FreeKode started as a way for us to learn about code portability,
> cross-platform development and how to follow a standard.
>
> On the inside, FreeKode is basically a wrapper around libc for
> modern desktop platforms (Win32, Linux, MacOSX), with a few extra bits
> added. It was initially meant as a tool to help desktop developers test
> code for mobile platforms on their favorite development environments.
>
> It also turned out to be an interesting platform for porting OpenKode
> to new platforms, as Fozi's WinCE port can atest.
>
> Our current goal is to reach compatibility with OpenKode 1.0 Core, which
> allows us to defer sorting out all the messy windowing ang EGL issues
> till after we have a solid base going.
>
> All the ports share a lot of common, platform independent code, so if I
> were you I'd start out with the lib init in application.c and move on
> from there. The Win32 and MacOSX ports are the most advanced, with
> Linux lagging a bit behind, but they're still missing some advanced
> features like threading or the virtual file system, although the
> scaffolding for them is all done.
>
> > I'm looking to contribute to the Linux implementation. Can anyone
> > please let me know what I can begin with ?
>
> Sure, your first step will be to build the lib and the test suite. The
> Linux port uses premake 3.x <http://premake.sf.net> to generate the
> Makefiles (you can also generate build files for Code::Blocks, Visual
> Studio, and CodeLite on Win32 and MacOSX with it, but this is
> untested). Go to the premake/ folder and do:
>
> premake --target gnu
> make
>
> To build the tests, copy premake/config/config.lua.sample to
> premake/config/config.lua and set the FK_BUILD_TESTS variable to
> 'true' and then regenerate the makefiles like above.
>
> If all went ok, you can now cd into tests/ and run the run_tests
> executable. Individual tests are defined in a .c source file in
> tests/src and are automagically added to the makefiles when you
> regenerate them.
>
> Once you're comfortable with this, feel free to poke around the
> source and implement any missing features you're interested in, and
> post a patch either here or on the sf patch tracker (but give us a
> heads up on the mailing list if you do).
>
> My current focus is writing tests for the parts of OpenKode already
> implemented, and refactoring the existing tests to use the TAP test
> harness. Fozi is still commited to the Win32 port, but I'm guessing
> anything else you might come up with is OK.
>
> > Hoping to help bring the project back to life again.
>
> Welcome aboard,
>
> Pedro Ângelo
> pa...@vi...
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public
>

Re: [Freekode-public] Status of the project

[Pedro Â. <pa...@vi...>]

On Wed, 28 Jan 2009 22:02:48 +0530
Balaji Rao <bal...@gm...> wrote:

> Hi all,
> 
> First I would like to thank those who started this project.
> 
> It is so unfortunate that the the development is completely stalled.
> Can anyone please enlighten me why is it so ?

Hello Balaji,

Thanks for checking in about FreeKode. I wouldn't say the project
is stalled, it's more like it's progressing at a glaciar pace :)

We are still very interested in it, but I'm guessing that lack of time
and projects using FreeKode to drive it's development has
taken it's toll on project activity.

> If the project is looking for contributors, that's what I'm here for.
> So it would be very helpful if someone briefed about the status of the
> project.

We are always looking for contributors :) 

FreeKode started as a way for us to learn about code portability,
cross-platform development and how to follow a standard. 

On the inside, FreeKode is basically a wrapper around libc for
modern desktop platforms (Win32, Linux, MacOSX), with a few extra bits
added. It was initially meant as a tool to help desktop developers test
code for mobile platforms on their favorite development environments.

It also turned out to be an interesting platform for porting OpenKode
to new platforms, as Fozi's WinCE port can atest.

Our current goal is to reach compatibility with OpenKode 1.0 Core, which
allows us to defer sorting out all the messy windowing ang EGL issues
till after we have a solid base going.

All the ports share a lot of common, platform independent code, so if I
were you I'd start out with the lib init in application.c and move on
from there. The Win32 and MacOSX ports are the most advanced, with
Linux lagging a bit behind, but they're still missing some advanced
features like threading or the virtual file system, although the
scaffolding for them is all done.

> I'm looking to contribute to the Linux implementation. Can anyone
> please let me know what I can begin with ?

Sure, your first step will be to build the lib and the test suite. The
Linux port uses premake 3.x <http://premake.sf.net> to generate the
Makefiles (you can also generate build files for Code::Blocks, Visual
Studio, and CodeLite on Win32 and MacOSX with it, but this is
untested). Go to the premake/ folder and do:

premake --target gnu
make

To build the tests, copy premake/config/config.lua.sample to
premake/config/config.lua and set the FK_BUILD_TESTS variable to
'true' and then regenerate the makefiles like above.

If all went ok, you can now cd into tests/ and run the run_tests
executable. Individual tests are defined in a .c source file in
tests/src and are automagically added to the makefiles when you
regenerate them.

Once you're comfortable with this, feel free to poke around the
source and implement any missing features you're interested in, and
post a patch either here or on the sf patch tracker (but give us a
heads up on the mailing list if you do).

My current focus is writing tests for the parts of OpenKode already
implemented, and refactoring the existing tests to use the TAP test
harness. Fozi is still commited to the Win32 port, but I'm guessing
anything else you might come up with is OK.

> Hoping to help bring the project back to life again.

Welcome aboard,

Pedro Ângelo
pa...@vi...

[Freekode-public] Status of the project

[Balaji R. <bal...@gm...>]

Hi all,

First I would like to thank those who started this project.

It is so unfortunate that the the development is completely stalled. Can
anyone please enlighten me why is it so ?

If the project is looking for contributors, that's what I'm here for. So
it would be very helpful if someone briefed about the status of the
project.

I'm looking to contribute to the Linux implementation. Can anyone please
let me know what I can begin with ?

Hoping to help bring the project back to life again.

Cheers,
Balaji

[Freekode-public] 1.0 roadmap

[Pedro Â. <pa...@vi...>]

Hello all,

I've been slowly getting up to speed again in FreeKode development, and
just got the linux port to compile the platform agnostic portions of
the codebase.

As I was starting to read up on the spec, I noticed that we've been
targeting revision1 while in the meantime Khronos has approved the
final OpenKode 1.0 spec. The 1.0 reference KD/kd.h is a bit different
from the the one we're using now and updating it will break some code,
so I'd just like to ask you guys first if it's ok to update it.

Anyway, Fozi told me a while back that we should perhaps target March
for a 1.0 release of FreeKode, and I agree with him, so I'd like to ask
you what should be the roadmap for the release. Currently I'm working
towards having a full OpenKode Core 1.0 on Linux by the middle of March,
but maybe without windowing as the spec says it can be made optional.

Cheers,

Pedro Ângelo
pa...@vi...

Re: [Freekode-public] Event callbacks

[Diogo T. <fo...@gm...>]

Yeah sure, no problem.

I'm still working on the PocketPC and Smartphone ports where everything is
done except filesys (n0n4m3, I need your help).
Win64 is ready. I should try to port for Xbox360 before switching back to
the event system.

I also took the liberty to implement mutex management to make some functions
like kdSetError thread safe.
I'm using critical section objects (for performance) on windows and pthreads
mutex on the other platforms.

I added some fk_init_ and fk_close_ functions to application.c as we
discussed earlier.

This is going well people!
Keep up the good work :)

Cheers,
Diogo

On 10/6/07, Guilherme Santos <gui...@gm...> wrote:
>
> I was reading about event callbacks and read something that I wasn't
> expecting...
>
> The callbacks are installed accorded a COMBINATION of EventType and
> UserPointer...
>
> Since I have implemented a balanced binary tree only with the key
> EventType,
> I have to change the system to compare the combination of the two keys...
>
> Tomorrow I will see it.
>
>
>
> Regards,
> Guilherme Santos
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public
>

[Freekode-public] Event callbacks

[Guilherme S. <gui...@gm...>]

I was reading about event callbacks and read something that I wasn't
expecting...

The callbacks are installed accorded a COMBINATION of EventType and
UserPointer...

Since I have implemented a balanced binary tree only with the key EventType,
I have to change the system to compare the combination of the two keys...

Tomorrow I will see it.



Regards,
Guilherme Santos

Re: [Freekode-public] Events

[Guilherme S. <gui...@gm...>]

I=B9m working on the event system for mac.
Until now, I have only used Mac functions on three kdFunctions: kdWaitEvent=
,
kdPostEvent and kdPumpEvents (not yet implemented).

One thing I think can be shared by all systems, is the event callback
module.
If we have a function that returns the callback for a given KD_EVENT id, it
would be great :)


By the way. How do you plan to translate the SO events into KD events?
For now, I=B9m using a mega-switch, that translates MAC_EVENT_ID into
KD_EVENT_ID.
I would prefer something more =B3advanced=B2...


Another important subject about events, that I have already discuss with
fozi but not with you, guys.
What is supposed to happen to events sent by the OS that KD doesn=B9t specify=
?

I suggested that we should extend the struct Kdevent (as predicted by the K=
D
specification) to store a void* pointer to the OS event data.
This way we let the user decide what to do.
If he doesn=B9t want to treat specific OS events, he calls the DefaultEvent
function as usual and moves on.
If he wants to be an hero, he can convert to the correct data struct and
treat the event as he want.

For this to work we have to create a new KD_EVENT_ID, such as, FK_EVENT_OS
or something.

What do you think?


Guilherme Santos


On 9/20/07 12:22 AM, "Diogo Teixeira" <fo...@gm...> wrote:

> Let's get the event handling discussion started.
>=20
> -----
>=20
> After some debate we ended up with two options on the table regarding the
> event system implementation.
>=20
> 1) The first one is straightforward, it involves a global event queue. Th=
e
> system and input events are
> captured by a platform event handler and posted to the global queue using
> kdPostEvent. In this case we
> would have to do our own callback handling which would probably require
> another container.
>=20
> 2) An alternative implementation is to use the event system and callback
> handler provided by the operating
> system. In Mac and Windows this implementation would be very straightforw=
ard
> as both are thread safe and
> support events and callbacks. However, this might not be true for all
> platforms so the first implementation
> might still be required as a fall back.
>=20
> Unless we have more options, I think we have no choice but to implement t=
he
> first one. Once it's done,
> supporting new platforms becomes almost trivial.
> The second option, however, might still be useful by saving us  some reso=
urces
> and processing on some
> platforms.
>=20
> Fire away.
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>=20
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public

[Freekode-public] Events

[Diogo T. <fo...@gm...>]

Let's get the event handling discussion started.

-----

After some debate we ended up with two options on the table regarding the
event system implementation.

1) The first one is straightforward, it involves a global event queue. The
system and input events are
captured by a platform event handler and posted to the global queue using
kdPostEvent. In this case we
would have to do our own callback handling which would probably require
another container.

2) An alternative implementation is to use the event system and callback
handler provided by the operating
system. In Mac and Windows this implementation would be very straightforward
as both are thread safe and
support events and callbacks. However, this might not be true for all
platforms so the first implementation
might still be required as a fall back.

Unless we have more options, I think we have no choice but to implement the
first one. Once it's done,
supporting new platforms becomes almost trivial.
The second option, however, might still be useful by saving us some
resources and processing on some
platforms.

Fire away.

[Freekode-public] Constants and Events

[Diogo T. <fo...@gm...>]

-- Constants

I just noticed the Acrodea's version of kd.h has been modified, notably some
math and file system constants/macros.
Also took me a while to notice the headers on kd.h and kdplatform.h:

/* Sample KD/kd.h for OpenKODE Core 1.0 Provisional revision 1 */
and
/* Sample KD/kdplatform.h for OpenKODE Core 1.0 Provisional revision 1 */

I guess we'll have to change the headers ourselves.

-- Events

Just changed source/events.c to top priority in the task list.
We should discuss implementation details as soon as possible.

[Freekode-public] File headers

[Guilherme S. <gui...@gm...>]

People,

Shouldn't we write some headers for each code file?
Something like /* freekode, blah blah blah, opensource, blah blah blah,
license, blah blah blah, copyright and credits */


Guilherme Santos

Re: [Freekode-public] Event system

[Pedro A. <pa...@dc...>]

On Thu, 13 Sep 2007 09:39:18 +0100
"Diogo Teixeira" <fo...@gm...> wrote:

> I guess I should have been more specific.
> 
> Obviously, the first functions I tested were the ones provided by C
> locale. The problem is... you can set those strings to whatever you
> want using setlocale()
> because no convention is mentioned except that the format _should_ be
> something
> like: language[_territory][.codeset]
> 
> For example, your code on my platform results in:
> LC_ALL=Portuguese_Portugal.1252
> LC_CTYPE=Portuguese_Portugal.1252
> 
> Which does not comply with the ISO defined by the spec. I guess it
> makes sense to
> use such a convention, for the sake of kdGetLocale() being anywhere
> near useful.

I can now feel your pain.

After a bit of search on MSDN I found out that setlocale() returns
"human readable" strings for the locale and if you want to get ISO
codes you have to use GetSystemDefaultLocaleName(),
GetUSerDefaultLocaleName() or GetThreadLocale() from <winnls.h>
(included by <windows.h>).

In this case, other than building a translation table for different
meanings of the setlocale() return value for each platform, we're
probably better off providing platform-specific implementations.  

P.

Re: [Freekode-public] Event system

[Pedro A. <pa...@dc...>]

On Thu, 13 Sep 2007 00:34:14 +0100
"Diogo Teixeira" <fo...@gm...> wrote:

> Roger that.
>=20
> I'm doing the locale functions at the moment. We might have to do
> an OS dependent implementation. I can't find ANSI functions to
> retrieve the language and country codes in the formats specified by
> the spec: ISO 639-1 and ISO 3166-1 alpha-2 respectively. Any ideas?

I think what you are looking for is the aptly named setlocale() function
from the standard <locale.h> header:

http://www.cplusplus.com/reference/clibrary/clocale/

On my machine, setlocale (LC_CTYPE, NULL) returns the string
"en_US.UTF-8" which is the ISO 639-1 language code followed by a "_"
followed by the ISO 3166-1 alpha 2 country code followed by a "." and
the default character encoding for the locale.

Here's the sample code I used for testing:

#include <locale.h>
#include <stdio.h>

int main (int argc, char **argv)
{
        /*
         * Set the program environment locale to the "native" locale.=20
         * You need to do this if you care about the platform's locale=20
         * because by default the program environment locale is set to
         * "C".
         */
        setlocale (LC_ALL, "");
        setlocale (LC_CTYPE, "");

        /* Get the locale strings */
        char *locale_all =3D setlocale (LC_ALL, NULL);
        char *locale_ctype =3D setlocale (LC_CTYPE, NULL);

        printf ("LC_ALL=3D%s\nLC_CTYPE=3D%s\n", locale_all, locale_ctype);

        return(0);
}

> We might have to provide initialization and finalization functions
> for the subsystems. Since we have control over the main entry point,
> my suggestion is the following:
>=20
> int main(int argc, char* argv[])
> {
>    init_events();
>    init_locale();
>=20
>    kdMain(argc, argv);
>=20
>    free_locale();
>    free_events();
> }

This seems sensible. I suggest we unify the namespaces for internal
access to freekode subsystems, something like:

fk_events_init();
fk_events_close();
fk_locale_init();
fk_locale_close();
...
fk_<subsystem>_<function>();

Cheers
P.

Re: [Freekode-public] Event system

[Diogo T. <fo...@gm...>]

Roger that.

I'm doing the locale functions at the moment. We might have to do
an OS dependent implementation. I can't find ANSI functions to retrieve
the language and country codes in the formats specified by the spec:
ISO 639-1 and ISO 3166-1 alpha-2 respectively. Any ideas?

We might have to provide initialization and finalization functions for the
subsystems. Since we have control over the main entry point, my
suggestion is the following:

int main(int argc, char* argv[])
{
   init_events();
   init_locale();

   kdMain(argc, argv);

   free_locale();
   free_events();
}


On 9/12/07, Guilherme Santos <gui...@gm...> wrote:
>
> Today I have implemented the time basic wrappers to the ANSI C API.
> I have started to implement the timer functions, but they involve system
> events and perhaps some custom implementation.
> Therefore I will proceed to the abstraction of system events.
>
>
> PS: By the way, I added some tests for cppunit (in C code style) to the
> folder tests/cppunit
>
>
> Guilherme Santos
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public
>

[Freekode-public] Event system

[Guilherme S. <gui...@gm...>]

Today I have implemented the time basic wrappers to the ANSI C API.
I have started to implement the timer functions, but they involve system
events and perhaps some custom implementation.
Therefore I will proceed to the abstraction of system events.


PS: By the way, I added some tests for cppunit (in C code style) to the
folder tests/cppunit


Guilherme Santos

Re: [Freekode-public] Tests (was: Re: Premake)

[Pedro A. <pa...@dc...>]

On Tue, 11 Sep 2007 21:31:53 +0100
Guilherme Santos <gui...@gm...> wrote:

> Any option for me is good!
>=20
> Option a) has the advantage that the test unit is =C2=B3automatic=C2=B2. =
What I
> want to say is that is easy to add or remove tests just by
> adding/removing a file to the folder.
> That looks great for me.
>=20
> Pedro, do you want to be responsible for that, if the others don=C2=B9t
> mind?
>=20
>=20
> Guilherme Santos
>=20

Sure, it's no problem since it's what I was doing anyway to get to know
the source code.

If any of you already have some test code, feel free to commit it to
the tests/ folder. I'll make sure it keeps working while I develop the
test code.=20

Cheers,
P.

Re: [Freekode-public] Tests (was: Re: Premake)

[Guilherme S. <gui...@gm...>]

Any option for me is good!

Option a) has the advantage that the test unit is =B3automatic=B2. What I want
to say is that is easy to add or remove tests just by adding/removing a fil=
e
to the folder.
That looks great for me.

Pedro, do you want to be responsible for that, if the others don=B9t mind?


Guilherme Santos


On 9/11/07 9:17 PM, "Ricardo Sabino" <rik...@gm...> wrote:

> On 9/11/07, Pedro Angelo <pa...@dc...> wrote:
>> On Mon, 10 Sep 2007 23:49:09 +0100
>> Guilherme Santos <gui...@gm...> wrote:
>>=20
>>> > Speaking on tests.
>>> > I'm using CppUnit to keep my tests organized (I have only one at this
>>> > moment). Another advantage is that is easy to add or remove tests and
>>> > keep everything running.
>>> >
>>> > But this approach has several disadvantages too.
>>> > It's implemented in C++ and if we think in (possible) future
>>> > platforms such as mobile, it could be more complicated to get the
>>> > framework compiling for that platforms.
>>> >
>>> > Anyway, it's easy to copy the tests code and use it to build a
>>> > simpler test unit.
>>> >
>>> > What are you planning to test the freekode?
>>> > If you guys think it's better to build another approach, it's easy
>>> > for me to copy the code I have done.
>>> >
>>> > For the moment, I'll continue to use the cppunit to test my stuff :)
>>> >
>>> >
>>> > Cheers,
>>> > Guilherme Santos
>>=20
>> Hi Guilherme,
>>=20
>> I've also been thinking about this, and to make the code as portable as
>> possible we probably should create our own mini test suite in ANSI C
>> and expand it as need arises.
>>=20
>> I've had some experience testing C code with Check and although it's
>> cleverly designed to avoid C's pitfalls in regards to testing code, it
>> falls a bit short on portability for more exotic platforms because it
>> relies on certain UNIX functions like fork() and vsnprintf(). A few
>> years back I tried porting it to a DEC Alpha workstation only to
>> realize that not all UNIX environments have vsnprintf()...
>>=20
>> Since openKode targets embedded platforms I'm expecting that we can't
>> count on much more than a working ANSI C compiler.
>>=20
>> So anyway, back to the idea of a minimalistic test framework what do you
>> guys prefer:
>>=20
>>  a) Each test is an executable in a special "test dir" and a test runner
>> app runs each test it finds via system() and reports the output.
>>=20
>>  b) Each test is a function (usually a macro) and the test runner just
>> calls the functions iteratively (this usually requires a fork() to
>> avoid a bad test crashing the test runner)
>>=20
>> I'm currently leaning towards option a) but I can use whatever
>> alternative you feel more comfortable with.
>>=20
>> Cheers,
>> p.
>>=20
>> ------------------------------------------------------------------------=
-
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>> _______________________________________________
>> Freekode-public mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freekode-public
>=20
> I also agree that tests should be made ANSI C compatible to make sure the=
y run
> in most (if not all) platforms.
> I'd also go for option a).
>=20
> Regards,
> Ricardo.
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>=20
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public

Re: [Freekode-public] Tests (was: Re: Premake)

[Ricardo S. <rik...@gm...>]

On 9/11/07, Pedro Angelo <pa...@dc...> wrote:
>
> On Mon, 10 Sep 2007 23:49:09 +0100
> Guilherme Santos <gui...@gm...> wrote:
>
> > Speaking on tests.
> > I'm using CppUnit to keep my tests organized (I have only one at this
> > moment). Another advantage is that is easy to add or remove tests and
> > keep everything running.
> >
> > But this approach has several disadvantages too.
> > It's implemented in C++ and if we think in (possible) future
> > platforms such as mobile, it could be more complicated to get the
> > framework compiling for that platforms.
> >
> > Anyway, it's easy to copy the tests code and use it to build a
> > simpler test unit.
> >
> > What are you planning to test the freekode?
> > If you guys think it's better to build another approach, it's easy
> > for me to copy the code I have done.
> >
> > For the moment, I'll continue to use the cppunit to test my stuff :)
> >
> >
> > Cheers,
> > Guilherme Santos
>
> Hi Guilherme,
>
> I've also been thinking about this, and to make the code as portable as
> possible we probably should create our own mini test suite in ANSI C
> and expand it as need arises.
>
> I've had some experience testing C code with Check and although it's
> cleverly designed to avoid C's pitfalls in regards to testing code, it
> falls a bit short on portability for more exotic platforms because it
> relies on certain UNIX functions like fork() and vsnprintf(). A few
> years back I tried porting it to a DEC Alpha workstation only to
> realize that not all UNIX environments have vsnprintf()...
>
> Since openKode targets embedded platforms I'm expecting that we can't
> count on much more than a working ANSI C compiler.
>
> So anyway, back to the idea of a minimalistic test framework what do you
> guys prefer:
>
> a) Each test is an executable in a special "test dir" and a test runner
> app runs each test it finds via system() and reports the output.
>
> b) Each test is a function (usually a macro) and the test runner just
> calls the functions iteratively (this usually requires a fork() to
> avoid a bad test crashing the test runner)
>
> I'm currently leaning towards option a) but I can use whatever
> alternative you feel more comfortable with.
>
> Cheers,
> p.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public
>

I also agree that tests should be made ANSI C compatible to make sure they
run in most (if not all) platforms.
I'd also go for option a).

Regards,
Ricardo.

[Freekode-public] Tests (was: Re: Premake)

[Pedro A. <pa...@dc...>]

On Mon, 10 Sep 2007 23:49:09 +0100
Guilherme Santos <gui...@gm...> wrote:

> Speaking on tests.
> I'm using CppUnit to keep my tests organized (I have only one at this
> moment). Another advantage is that is easy to add or remove tests and
> keep everything running.
> 
> But this approach has several disadvantages too.
> It's implemented in C++ and if we think in (possible) future
> platforms such as mobile, it could be more complicated to get the
> framework compiling for that platforms.
> 
> Anyway, it's easy to copy the tests code and use it to build a
> simpler test unit.
> 
> What are you planning to test the freekode?
> If you guys think it's better to build another approach, it's easy
> for me to copy the code I have done.
> 
> For the moment, I'll continue to use the cppunit to test my stuff :)
> 
> 
> Cheers,
> Guilherme Santos 

Hi Guilherme,

I've also been thinking about this, and to make the code as portable as
possible we probably should create our own mini test suite in ANSI C
and expand it as need arises. 

I've had some experience testing C code with Check and although it's
cleverly designed to avoid C's pitfalls in regards to testing code, it
falls a bit short on portability for more exotic platforms because it
relies on certain UNIX functions like fork() and vsnprintf(). A few
years back I tried porting it to a DEC Alpha workstation only to
realize that not all UNIX environments have vsnprintf()...  

Since openKode targets embedded platforms I'm expecting that we can't
count on much more than a working ANSI C compiler.
 
So anyway, back to the idea of a minimalistic test framework what do you
guys prefer:

 a) Each test is an executable in a special "test dir" and a test runner
app runs each test it finds via system() and reports the output.

 b) Each test is a function (usually a macro) and the test runner just
calls the functions iteratively (this usually requires a fork() to
avoid a bad test crashing the test runner)

I'm currently leaning towards option a) but I can use whatever
alternative you feel more comfortable with.

Cheers,
p.