cboard community project

[neandrake]

scratch my previous idea. let's make a dooms-day device instead.

[MK27]

Anyway, I quite like this idea, and since everyone seems to be proposing stuff, I guess I'll do that too: I think an internationalization library would be great in my opinion since the C and C++ standard libraries don't offer much in this regard.

But do you think that would make a good cboard project? Maybe I should explain a little better why I *don't* think a serious project is a good idea -- by serious I mean one which is intended to fill an unoccupied niche perceived by someone like that. Something where the real use value (the final product) would be the primary concern.

Mostly I mean this because I know for a fact that there are plenty of (quite serious) volunteer driven projects around that could use more serious c programming help. And if you have a serious project you want to see done, it would probably be better done in that context than as a c board project.

On the other hand, it would seem a good opportunity to do something that otherwise you would probably only have to do as an educational experience (eg, a kernel or a language). Not to say that it should not be taken seriously. Maybe I mean something essentially self-indulgent? If anyone one has followed me on this...

[Ronix]

But do you think that would make a good cboard project? Maybe I should explain a little better why I *don't* think a serious project is a good idea -- by serious I mean one which is intended to fill an unoccupied niche perceived by someone like that. Something where the real use value (the final product) would be the primary concern.

Well, I guess I'm in the minority when I say I use i18n features a lot, which would make the final product of great use to me. But otherwise, I see your point.

On the other hand, it would seem a good opportunity to do something that otherwise you would probably only have to do as an educational experience (eg, a kernel or a language). Not to say that it should not be taken seriously. Maybe I mean something essentially self-indulgent? If anyone one has followed me on this...

Yeah. I think those 2 ideas (OS and language) hold a lot of merit because, aside from being ends in themselves, they can also act as means to other goals.

[zacs7]

I think that the build system is a better idea

Being smaller in scope, and largely useful by this community.

[brewbuck]

I think that the build system is a better idea

Being smaller in scope, and largely useful by this community.

I think we could set some goals for that:

* Cross platform between Windows, Linux, and Mac OS X
* Simple to use: an explicit makefile is only needed if the default behavior isn't what you want
* Good set of built-in rules for C/C++ development
* Automatic support of projects organized into subdirectories/libraries

No matter what project, there are some open questions to consider:

* Language: C, C++, or a mixture?
* If C++, will the project use STL and/or Boost?
* Who architects it? Will it even be designed up front?
* Which SCCS? I've seen SVN mentioned but there are other choices.
* Where will the SCCS be hosted?
* Who doles out SCCS accounts?
* Who owns it? Will it have a license?

etc...

[zacs7]

My own opinions:

> Language: C, C++, or a mixture?
C :-). It means for the few of us who don't dable in C++ can contribute.

> If C++, will the project use STL and/or Boost?
Boost is another dependancy, which kind of eliminates the point.

> Who architects it? Will it even be designed up front?
Not sure . And yes, some sort of "design" would probably be required.

> Which SCCS? I've seen SVN mentioned but there are other choices.
SVN

> Where will the SCCS be hosted?
Google code, simple and easy to use. Or sf.net.

> Who doles out SCCS accounts?
Not sure, I suppose we need a leader? You seem fit

> Who owns it? Will it have a license?
Just chuck it in the public domain? Or a GPL2/3 style licence?

[laserlight]

C :-). It means for the few of us who don't dable in C++ can contribute.

I may know the syntax of C, but I do not program in C. So, you win some, you lose some.

[Snafuist]

I like the idea of a board community project. Designing and implementing a build system (or something similarly related to programming) is certainly good, because every participant can put it to direct use, in contrast to e.g. games, GUIs, special purpose libraries, ...

One way of handling the problem of diverse skill levels is to set up two stages of development: the "unexperienced" guys come up with the initial version of a function/class/functionality, and the "experienced" guys either do some kind of code audit or merely accept the proposal or reject it and tell how it should be done in order to get accepted (I prefer the code audit scenario). This way, everyone can learn from each other and there's additionally some kind of competition: the programmers try to beat the QA-team (hey, my random number generator hasn't been fixed for three weeks now), and the QA-team tries to find as many bugs/flaws/bad design decisions as possible and fixes them. As we're all intimate friends around here, this can be a lot of fun.


> Language: C, C++, or a mixture?
C.

> Who architects it? Will it even be designed up front?
Let's agree on a goal, start a design discussion and see what happens.

> Which SCCS? I've seen SVN mentioned but there are other choices.
I like SVN. It integrates extremely well with all the common operating systems and is already used in a large number of projects, so getting used to it may be beneficial for the future.

> Where will the SCCS be hosted?
If code.google and sf.net are the only options, I'd vote for code.google. Sometimes it's a bit slow, but still a lot faster than sf. But it also wouldn't be a problem for me to set up a 24/7 web/sccs/whatever server at work if someone's willing to help me with administration and maintenance; if I'm not mistaken, we have a 2GBit internet connection, and digging up some unused hardware shouldn't be too hard. This way, we are free to set up and change whatever we want, and we could give SSH accounts to everyone who's interested.

> Who doles out SCCS accounts?
You.

> Who owns it? Will it have a license?
I don't care for ownership, but I refrain from a public domain license model. As a German citizen, I'm not able to put anything into public domain, so I suggest the 2-clause BSD license.

Greets,
Philip

[MK27]

> Who owns it? Will it have a license?
I don't care for ownership, but I refrain from a public domain license model. As a German citizen, I'm not able to put anything into public domain, so I suggest the 2-clause BSD license.

Wow, is that some kind of uber-mentality?? I like most of what Snafuist has to say except I think the GPL 3 license is the way to go, since the GPL has probably done more great things for the computing world than any other.

Anyway, since this is looking to be a C project*, I'll want to get involved. Since I have exactly zero interest in build systems, this will motivate me to learn some (necessary) stuff without having any strong feelings about how it should be done. I'm also not interested in organizing people around the concept, so I will have to leave that up to others.

Re: server administration I do do web programming and am always interested in gaining more experience with it so would be willing to collaborate with Snafuist on that if desired.

*does it have to be exclusively so? Ie, is a build system limited to a single process?

[laserlight]

It might be simpler for the person in charge of the development server to be the same person who hands out source control and shell accounts.

I think the GPL 3 license is the way to go, since the GPL has probably done more great things for the computing world than any other.

With such reasoning, a GPL compatible license would suffice.

*does it have to be exclusively so? Ie, is a build system limited to a single process?

I do not see why a C program would require that the build system be limited to a single process.

[Snafuist]

It might be simpler for the person in charge of the development server to be the same person who hands out source control and shell accounts.

If it's me who is the person in charge of the development server, I'll happily grant root access to everyone who is considered "worthy" by the already existing root users. While I'd enjoy setting up a nice project environment, I actually don't want to be the guy who makes decisions about who may join and who may not. In my opinion, this is decided best by the existing user base.

Greets,
Philip

[laserlight]

If it's me who is the person in charge of the development server, I'll happily grant root access to everyone who is considered "worthy" by the already existing root users. While I'd enjoy setting up a nice project environment, I actually don't want to be the guy who makes decisions about who may join and who may not. In my opinion, this is decided best by the existing user base.

Ah, I confused the decision making and the actual logistic aspect of creating and giving out accounts and their details.

I am also in favour of a permissive license, and Google Code would be fine with me. I prefer Bazaar for version control, but seeing that Google Code only supports Mercurial and Subversion, Mercurial would be the next best for me, though Subversion is fine.

As stated, I would strongly prefer C++ to C as the implementation language, should only one be used.

One way of handling the problem of diverse skill levels is to set up two stages of development: the "unexperienced" guys come up with the initial version of a function/class/functionality, and the "experienced" guys either do some kind of code audit or merely accept the proposal or reject it and tell how it should be done in order to get accepted (I prefer the code audit scenario).

Google Code's code review feature can be used should this scenario be used. I am not sure if, like Launchpad, we will be able to publish code into a personal Mercurial repository, and then have the code reviewed, and finally merge into the main repository when the review passes. However, this should not be a significant factor with respect to this scenario.

[Snafuist]

What about writing a modern editor? I don't really like any of the existing ones, but I think it's too hard a task (in terms of development time) to come up with a good editor myself. Nevertheless, I have spent some spare time thinking about a good design, which mostly resembles the model-view-controller pattern: a core unit which does all the processing, with I/O clients connecting to it via pipes (maybe sockets?) using a standardized protocol and an interactive interface (like e.g. ed, but maybe more userfriendly). The core unit can be implemented portably in C, while the clients may make use of OS features (Windows, X11, Max OS X, Linux console). I especially like the idea of extending the core functionality through shared objects instead of some obscure scripting language (think of Emacs Lisp here), making it easy for developers to add substantial functionality without having to learn yet another scripting language. This way, the editor will be able to read mail far sooner than vim. ;-)

This kind of project would allow us to use a large set of different languages, and implementing the core and the clients will get us in touch with just about everything there is, ranging from data structures and algorithms (ever implemented search+replace with regular expressions?) and working with a pre-defined API (core modules) to GUI programming with Windows, Qt, GTK, ncurses, whatever.

Don't get me wrong, I'm completely happy with the build system. This is just to bring in some more ideas...

Greets,
Philip

[Brafil]

I kinda like Snafuist's idea. And my own :-) A new editor would be useful, a new build system maybe not so, free flash can rock, a new programming language can, a new C compiler (gotta post into an assembler forum, GCC is getting old).

But: We are trying to make things better. A new editor should be powerful yet not as unintuitive as vim. A new programming language should be innovative and comfortable, maybe not only in its syntax. A new build system should be very portable and handle many different compilers/languages. Free flash should be good enough and not suck in playing animations or so. A new C Compiler should be fast and produce fast code.

If some want to work on a new programming language, check out Ascent. I have changed many things since my first post.

[Snafuist]

I kinda like Snafuist's idea.

Me too. :-)

But: We are trying to make things better. A new editor should be powerful yet not as unintuitive as vim. A new programming language should be innovative and comfortable, maybe not only in its syntax. A new build system should be very portable and handle many different compilers/languages. Free flash should be good enough and not suck in playing animations or so. A new C Compiler should be fast and produce fast code.

You are right. That's why I hesitate to come up with a new language: what makes a language "better"? What is "better"? Besides, most of the participants won't know what a type is, let alone the difference between parsers and lexers. Furthermore, optimization is still a highly active field of research, which we cannot compete with. We should choose our goals such that we have a certain chance of producing one of the best alternatives that will be available. Hence, everyone should have a rough idea about key functionality and features in advance, which holds true for build systems and editors (since we're using them on a daily basis), but is not true for things like flashy flash, languages, compilers, operating systems.


Talking about "unintuitive as vim": that's exactly what I like about my idea. With an independant core, the user is free to choose whatever client interface he wants to use (think of blinking OpenGL GUIs and conservative ncurses-like console interfaces). AFAIK all our current editors don't separate the view/control from their respective core unit, which makes it hard to modify things, let alone porting the software to a new environment, e.g. cell phones/toasters. With an interactive core, it will be easy to come up with new clients for different platforms and different needs. My guess is that any decent Perl programmer should be able to build a full-featured client in less than a week (add another week for C).

But as I said, I'm just gathering ideas. Anyone else?

Greets,
Philip