Printable View
Hi,
Just shooting an idea around. I was thinking it would be cool if perhaps the community here had a project to work on together, just in their spare-spare-time. Seeing as most of us seem to get along :)
Thoughts? And yes I understand there are 999^999 open source projects, but it isn't the same :)
-Z
We would need a leader, or decide democratically what to do together.
I know, I know... We'll make some application, like... Something that someone comes up with, make it an open SVN, and then all the CBoard people will work on it... I suggest some admin takes the position as leader... Or we can make a voting ;)
Sure, but my question was more so about if the general idea of it is good / will work?
It'd be fantastic if it perhaps had a C & C++ side of things. And perhaps a few other things.
But since you've already started talking about organisation, I presume you do think it's a good idea? :D
Some random idea I just thought of (just now) is say, the C++ STL for C :). Or more complex things, although not sure how this is different to say Boost or glib. But would allow multiple authors pretty easily.
I suppose so. After all, there is already some minor collaboration going on stemming from the Converting MINI-BASIC in MASM over to C++? thread.Quote:
Originally Posted by zacs7
I fear that that would require pretty extensive use of macros, and there would be aspects that will probably be very difficult to emulate :(Quote:
Originally Posted by zacs7
Or maybe you are thinking of something like CCAN.
I think it's a cool idea. The difficulty is the huge range of skill level and experience.
On open source projects I've looked at, the skill level of the contributers seems mostly consistent. When somebody with less experience tries to contribute, what usually seems to happen is a big argument, perhaps some name calling, and the eventual rejection of the contribution.
If we can somehow avoid that, then I don't think it's a bad idea.
(I offer to be the keeper of the build system :) )
We could use a review system (e.g., Launchpad's review system) with more weight given to those who are old timers in this community. In a way, it would be the same idea as what got the Programming Book and Product Reviews forum going.Quote:
Originally Posted by brewbuck
No, please use Accelerate your team with online workspaces | Home | Assembla as it works way better than launchpad, atleast for peeps like me D: Since launchpad demanded SSH passwords or something bad...
Also, since i'm more Game Development oriented, we could make an RTS or RPG, but since that would require OpenGL (As in, cross-platform) it'd be very problematic between both sides (DirectX vs. OpenGL) so lets just skip that xP
So, lets make an IDE that supports easy SVN, like you just configure it to a SVN 'server', and it wins over all other IDEs...
Or a new graphics API! (I jest xP)
Or maybe an pwnage Linux Distro ...
Ideas are just svimming through my head xD
I'd be far more in favor of a homebrew review system. The goal here is to work on a project. I don't see why we should introduce a dependency on some web service.Quote:
Originally Posted by Akkernight
In fact, to get this thing off the ground, we could design the review system as the first project.
SSH keys are required in some places, yes, but what is so hard about that? I note that encrypted access to one's Git repository in Assembla requires SSH as well. Speaking of Git, Github and Google Code hosting also allow for reviews; does Assembla allow for reviews?Quote:
Originally Posted by Akkernight
Well, you cannot please everybody, so I do not see why having to choose between two commonly used libraries would be a problem :)Quote:
Originally Posted by Akkernight
Not so easy to win since SVN plugins are available for a number of IDEs.Quote:
Originally Posted by Akkernight
EDIT:
That is certainly an option, but wouldn't it be a chicken and egg scenario?Quote:
Originally Posted by brewbuck
SSH keys wouldn't work, that's why they were problematic...
Anyways, what is needed? Like, think about something that'd be new ;)
Something that would benefit cboard, perhaps? Along those lines... I presume that we would want to limit the scope of the project to something involving development in C and/or C++?Quote:
Originally Posted by Akkernight
ok, what has been whined about lots on these boards?
Students asking for solutions to homework?
How about a project that prints funny notes to the teacher when you run it the next day?
What about making a free version of Flash? I need that..
Or a... Game Maker of some type...
Or a new language...
Exactly, why not make a game maker that supports C++ code aswell as its WYSIWYG editor?
And which build system is that? :). Something portable would probably be fantastic (*cough* bakefile).Quote:
Originally Posted by brewbuck
That's happened to me once or twice. But sort of vice-versa, you could put it down to the fact that if person A is a maths student and writes a compiler and interpreter over 5 years (say project P). Then a design for project P, or at least a language specification (yes, he was designing a language) is essential, but it didn't exist. Plus the code is full ofQuote:
Originally Posted by brewbuck
Yes, that's what a typical function call looks like :\Code:(void)foo((void *) NULL, (int) 5);
Now the answer is "perhaps" for this project, the question is what and how? Also who? :)
As much as I *really* love cross-platform build systems (e.g. cmake, jam, bakefile), they suck for the end user who now has to install something just to do a build.Quote:
Originally Posted by zacs7
It's awesome for a gang who is coding and releasing binary product, but for an open source project I really, really want to be able to build it with the build system that came with my environment. It sucks for the developer, it's easier for the user.
What makes it somewhat easier to deal with is if the build system itself is included with the project. That's really only feasible if it's simple enough to fit into a single (or possibly a few) source files.
While we're looking for project ideas... How about a simple, portable build system that can be compiled from a single source module?
Sounds like a great first idea, pretty sure nothing of that nature really exists?
How would configuration work? ie, say the user wants to define "debug" would that be done at compile time of the build system or runtime?
And this build system would be limited to C/C++?
awesome :D
and yes C/C++ only and it's extension should be cbo or cboard ...
I think this is a great idea! But I may be a "someone" with less experience brewbuck is talking about :rolleyes:. I could take care of translation to dutch if necessary :p.
perhaps a trendy name, or at least codename. "cbmake" (for C Binary make -- or cboard make). Or since make is overused, and it could conflict with cmake, "cbm".
Flex is open source - unless you really want the GUI...Quote:
free version of Flash?
A game maker actually is a really good idea. Lots of newer users would love that. I mean, it wouldn't teach them good programming, per se, but those kind of noobs don't really want to learn programming anyway - they just want to be l33t h4x0rs and make a game.
A game maker, something like this: Game Maker - Wikipedia, the free encyclopedia ?
That is a good idea (but as you see, not new).
Ideswa, I used the Game Maker one some time ago... It had its own scripting language tho, which was annoying xP I hate learning new languages...
> A game maker actually is a really good idea
Sure, but it's a rather large one to start with.
Perhaps some smaller projects that would ultimately lead to that, i.e. a build system, a small scripting language, etc.
I presume you mean an interpreted scripting language, like perl or python and a whole bunch of others. (It seems to me a compiled language would be more of an asm project, but most interpreters are written in C or C++.)Quote:
Originally Posted by Akkernight
This might be a really good idea since really the "goal" is unlikely to be something someone really wants*, or at least I think that would be better since no one seems to have any serious requests (yet, I mean I would like a better email client for linux that is not part of a DE, but I am not suggesting that). Also, this keeps the project open to everyone (it would not depend on using a choice of other non standard libraries or API's) and very focussed in a theoretical way on computer programming concepts.
Of course, there is already this:
http://cboard.cprogramming.com/proje...tml#post854978
However, I'd prefer a less serious, experiment and learn approach which might not be appropriate if someone is very serious about the product. Also, it would be nice to start from scratch.
There's a lot of potential separate elements to this that could involve people with different skill levels, and various programming realms.
- For example, Akkernight also mentioned a flash replacement, which could be one role for such a scripting language, but would require integrating an interpreter into web browsers (difficult C++ stuff methinks). Laying the browser aside, certainly a networked interpreter would be easy and perhaps interesting considering the nature of the collaboration (and would require platform specific work).
- different interpreters for different OS's means more people could be involved, but would not be required
- in fact, such a project can very easily be scaled to reflect the amount of time put into it. It could be a very small simple language, and on from there...
- the language could have non-essential branches and extensions for doing specific things on specific platforms. Eg, along the "game maker" line, it should be possible to do an app building script language that can be implimented using DX or GL (meaning people would have to write parallel functions so the same script could be applied using either API; I don't think that will be as difficult as it might sound)
Anyway, I would definitely want to contribute to something like that.
* or better yet, it could easily adapt itself to satisfy a broad range of goals
An operating system. I've seen a load of single-post users talking about writing one.
Yeah, I like that idea even more (almost), if by OS you mean the kernel (since the OS might as well use standard C libraries).Quote:
Originally Posted by twomers
I've never tried so I might as well ask: can you use C to create an executable that will boot? There is the issue of using a boot loader vs. something with a custom boot sector, which would mean something that works off a floppy or flash drive, etc. In the latter case I would assume the boot process has to be written directly in asm.
On the other end of being low-level, it seems that a large trend is moving towards thin-clients using the browser as interface. It might be interesting to develop something to enhance that sort of experience -- Perhaps something like client-side compiled code, like a JavaScript byte-code of some sort.
Probably not. Something of that nature would most likely require access to internal registers, which means you'll need to write some parts in assembly.Quote:
Originally Posted by 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. Sure, we have ICU, but after using it for more than a year, I can't help but think it's somewhat bloated, while lacking in some crucial areas (I/O), and besides, relying on a single library for something so important doesn't sound quite right to me. It can start out relatively simple: Pick up a transformation format and implement basic string functionality, then incorporate more complex concepts like collation, normalization, codepage conversion, etc.
Otherwise, I'm quite fond of the scripting language suggestion; it's something I've always wanted to make but never got around.
scratch my previous idea. let's make a dooms-day device instead.
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.Quote:
Originally Posted by Ronix
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...
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.Quote:
Originally Posted by MK27
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.Quote:
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...
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:Quote:
Originally Posted by zacs7
* 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...
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?
I may know the syntax of C, but I do not program in C. So, you win some, you lose some.Quote:
Originally Posted by zacs7
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
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.Quote:
Originally Posted by Snafuist
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?
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.
With such reasoning, a GPL compatible license would suffice.Quote:
Originally Posted by MK27
I do not see why a C program would require that the build system be limited to a single process.Quote:
Originally Posted by MK27
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.Quote:
Originally Posted by laserlight
Greets,
Philip
Ah, I confused the decision making and the actual logistic aspect of creating and giving out accounts and their details.Quote:
Originally Posted by Snafuist
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.
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.Quote:
Originally Posted by 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
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.
Me too. :-)Quote:
Originally Posted by Brafil
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.Quote:
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.
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
When I first read this I thought it was a neat idea, however, if you think about it a little more deeply you might recognize it is almost oxymoronic: the most the "independent core" might hope to be is a conceptual framework and not an actual coded interface (a back end for the user-interface front-end).Quote:
Originally Posted by Snafuist
In other words, you cannot write an integrated "text editor engine" or something that could be implimented this way. You could write a limited set of functions that could be used, but many of the "conceptual connections" between such functions would have to be just that, because they would be implemented completely in the front-end; there will be no place for them beyond the programming of the actual interface, whether it is Qt or ncurses, etc. So you could create an independent library of features as applicable, and then an abstract which describes the functioning of the front-end, but I am sure you will quickly find that is impossible or pointless to try creating a functional process that will "interact" with an independently coded GUI. "Quickly", as in the day you start actually coding.
Not to ixnay the whole idea, just to provide some perpective.
What about functions like substitute(this, that) or refresh()? I agree, it would be difficult.
We need a project that's very versatile. What about a new standard C Library? ;-p
Sure, as I said you could have a library of functions for use in text editors. My point is that some features would lend themselves to the concept (working on text independent of the interface) but many would be have to be implemented directly using an API (be it Qt or ncurses or whatever) and you will have a problem trying to create two layers where, logically, only one can have any meaningful significance.Quote:
Originally Posted by Brafil
Also, I guarantee that Snafuist has it backward:
The time consuming complicated part will be writing a front-end user-interface (client) to work with the back-end conceptual engine (which will be orders of magnitude simpler, just as with a web server/client relationship, conceived of on a one-to-one basis, would mean the server is much, much simpler than the client). I'm sure anyone familiar with GUI programming will concur*, and console text interfaces (eg ncurses) are much the same story. So, once again, you are looking at a library (which is not at all a bad idea, but lets call a car a car).Quote:
Originally Posted by Snafuist
*if you want my longer winded technical explanation of why, you can ask...
No need, I believe you're right.
Snafuist, your concept sounds a lot like what is in Emacs called a "buffer." A dynamic data structure whose sole purpose is to maintain line-based text and allow arbitrary operations on it. In Emacs, these operations are described in a Lisp-like language called Emacs Lisp.
Not that reinventing the wheel is bad. It's just that I've heard this before. Everybody always wants to make a game, the world's best text editor, or a compiler. The problem is in finishing the project...
I don't have a strong opinion what people decide they want to do. I'll just act as coordinator. Actually writing code is kind of an iffy proposition for me since I have some "interesting" employment contracts.
In GUI programming (well, I know gtk) the text buffer is also a distinct entity from the "text view" (or presentation), but this is trivial. You can, of course, perform any operation you want on the buffer -- w/ my last project you can eg, process the buffer on view with an external command (which could be a script, etc.) but this is not to say that writing an editor independent of the interface would be a useful undertaking. You can already write scripts to process text -- that's normative.Quote:
Originally Posted by brewbuck
I think you & zacs7 should step up then with the "build thing" and start coordinating/organizing! Otherwise I will just play pundit 'til the cows come home ;)Quote:
Originally Posted by brewbuck
Yeah, agree. Maybe you could give some more proposals and/or work the given ones out. We should make a poll. Really. Explaining what needs to be done for what.
I'll post a poll a bit later today. Snafuist is working on getting a server set up for source code hosting. I'll keep you folks updated.Quote:
Originally Posted by Brafil
Great Idea! What will we use? SVN? CVS? git? Bazaar? Maybe poll again
At this point it looks like SVN, but I wouldn't mind git either. It would take a loaded gun to convince me to use CVS :)Quote:
Originally Posted by Brafil
I think many people use SVN. I'm starting to learn.
The server (2GHz, 1GB, 20GB, ~6MB/s into the internet) is already running, but it isn't reachable from the internet yet. The guys at our computing center expressed a certain hope that it will work tomorrow, but we'll see... So far, it is running SSH, Apache and an SVN server. brewbuck, laserlight and me will take care of the administration.Quote:
Snafuist is working on getting a server set up for source code hosting.
Funny story: yesterday, I called the responsible guy at the computing center and explained the situation (i.e. I have a server running WWW, SSH, SVN and need an IP reachable from the internet), and he said "write me an email". So I wrote him an email, again explaining everything which might be of interest to him. An hour later, he replied: "call me". At this point, I was a bit concerned that we're entering some kind of an infinite loop, but when I called him today, I had the impression that they're now finally starting to do their job.
Let's see what happens tomorrow.
Greets,
Philip
Personally, I don't think yet-another-editor is a good idea. Everyone seems to already have their preference, why would I use anything other than vim? And emacs when I'm _really_ forced to :)
A native build system is rather useful, especially for small projects.
> It would take a loaded gun to convince me to use CVS
What about RCS? :)
Ugggh... Talk about pain. For nine years I worked on a 1.5 million line application that was source controlled entirely with RCS. And that was by choice (not my choice). I don't even want to describe the horror of branching to do a release, the terrors of compulsory locking, the absolutely fear-inducing way that RCS stores the repository files in the same source tree with the active codebase...Quote:
Originally Posted by zacs7
Over time I came up with a several-thousand line bash script just to lessen the pain.
Yeah... I see how terribly some programs can be. But what about the poll? [/impatiency]
Should we just skip the pole and go with the "build system" concept (speak now or forever hold your peace)?Quote:
Originally Posted by Brafil
I don't know. I'm happy with make/autoconf. And there are so many great ideas out there, we just don't know where.
Just tell what you're thinking about.
I think one main problem is that few people are looking further than Linux Programming.
I don't really like make and I hate autoconf, so personally I'd be happy to come up with something "better". In this case, it won't even be very hard. The build system has many advantages apart from its actual purpose: there are large parts that can be implemented by beginners, we can have an in-depth design discussion as the basic concepts are known to everyone in advance, and we have a large user base (the programmers working on it) that can test the software while it is being built.Quote:
Originally Posted by Brafil
Well, what are your ideas? :-PQuote:
And there are so many great ideas out there, we just don't know where.
The build system is surely not Linux specific by its very nature.Quote:
I think one main problem is that few people are looking further than Linux Programming.
But I'm open to just about everything that is related to programming.
Maybe we should start a more brainstorming-like approach. Just throwing in random ideas without immediately starting a discussion about it. What do you think?
- C library of standard data structures (graphs, trees (AVL, binary, (a,b), splash, red-black, balanced, ...), hashes (with all those funny hash functions), lists (single, double), dynamic arrays, circular arrays, heaps (Fibonacci, Min, Max, ...), treaps)
- C library of standard algorithms (shortest paths, tree traversal, finding min/max, min cut in graphs, hamiltonian, eulerian, searching (linear, binary, ...), sorting (heap, quick, merge, bubble, ...))
- C library to encapsulate the networking functions. I especially envy the Plan9 dial() system call, which altogether replaces socket(), bind(), listen()/accept(), ...
- some kind of networking client functionality, e.g. a good IRC protocol API (there are exactly 0 available)
- yet another distributed file sharing system
- yet another suite of exploits
- a microkernel (which is probably a nasty idea... kernels are hard to debug)
Greets,
Philip
I think your examples are fine, while not necessarily good. A Library on data structures? Anyone can follow some tutorials, and the point is in learning to determine when to use what, not how. Algorithms are the same. Networking is a bit too boring (IMO). Microkernel? That seems hard.
PS: My ideas are found in this thread <-
My vision of the build system would be a simple program (only several source files, if that) which could be distributed as part of a larger project, and could itself be built by a standard build tool (GNU make on Linux, nmake on Windows), which could then be used to build the enclosing project.
Maintaining two small build scripts (to build the build system itself) is far easier than maintaining two huge build scripts to build the surrounding project.
For inspiration, look at something like Jam/Boost.Build, but that system is enormous. I'm thinking something simpler but along those lines.
Like I said, I have no strong opinion on the project. I do like the build system. Brafil, if you want, go ahead and do a poll yourself with some of the options that have been presented here. Just make sure the build system is on the list.
Nothing needs to be set in stone. We have a server now (I'll be poking around on it this evening I hope), so we could host as many projects as we'd like (within reason -- the point is to work on something together as a group).
As far as SCCS, I think the decision is already made that we'll be using SVN for now.
Looks like we need a poll then. How's this idea:
Everyone interested has until noon tomorrow (GMT) to submit an idea to this thread. ONE IDEA PER PERSON, MAX. Then we throw all the ideas into a open poll and that lasts another 24 hrs. "Open" meaning your vote will *NOT* be anonymous, and you cannot vote for your own idea, and your vote does not count if you did not indicate a previous interest*. Then, if there is a tie, the people who voted for non-candidate projects resolve the tie. This will ensure we maximize the degree of consent and approval.
Or, we can just keep brainstorming...
*so, you don't have an idea, you just have to tell us you are interested before noon tomorrow (GMT). I'm willing to stand up right now and say my idea is a 1st person "shooter" perspective animated 3D filebrowser -- but I cannot vote for my own idea...
I'm not sure why we shouldn't be able to vote for our own idea -- is it because the voting pool is so small?
What is this about not indicating a previous interest? I've been sharking this topic the whole time - I've just not had any useful input to give yet. (Though I'm interested in this project, and wouldn't mind contributing. Consider my previous interests indicated.)
The build system sounds interesting... there's really quite a lot lacking in make, cmake is better but still has some issues.
I don't really know how build systems work at all.
I think their main purpose is to annoy users concerned with portability.Quote:
Originally Posted by whiteflags
I also don't know much about build systems. Either the stuff I do only requires a single call to gcc, or I generate the necessary scripts automatically. A few months ago, I've been reading the GNU autoconf manual, but I didn't do the examples so I'm about as clueless as before. I see this as an opportunity to gain experience in different build systems, possibly including our own.
Good morning from Germany,
Philip
There's not much too build systems, but there can be, that's the beauty of the idea.
Oh and autoconf and friends suck :-)
Did I say GMT? Anyway, from the looks of things, we REALLY don't need a pole. Glad to see there's more people poking their head up too.
I totally empathize with Snafuist on this; as a programmer, I don't really "like" build systems and use them as little as possible. But as a linux user, I appreciate GNU make, since I prefer to build software from source and linux stuff generally comes nicely packaged in an autotools tarball with an autoconf'd "configure" script.*
So I see this as a great learning opportunity. I think next, the people who are most informed and interested in the build process need come up with a clear statement about what the goal is, and perhaps give the rest of us something to think about.
No one came forward and claimed the idea for the pole, so I'm gonna stick it on zacs7 and brewbuck. What's up guys?
*That system works tremendously well, and there is exactly ZERO chance of anyone providing a serious alternative IMO, b/t/w. But I don't think that is what brewbuck had in mind.
Just haven't had time...Quote:
Originally Posted by MK27
I hate configure scripts. I have seen projects where the configure script was over 10 times as long as the source code of the actual project, even if the project had no special dependencies.Quote:
*That system works tremendously well, and there is exactly ZERO chance of anyone providing a serious alternative IMO, b/t/w. But I don't think that is what brewbuck had in mind.
A build system should not require configuration except to point at dependencies. We don't need a program which reads a meta-template which generates a Makefile template which is variable-substituted by a 10,000 shell script to become a makefile which then becomes the input to make... No, we don't need that. :P
Perhaps this is why "as a programmer" I don't like the looks of it. You have to use GNU make with kernel modules (but not autotools et al), and a 2 line make file to compile 50 lines of code into a single, stand-alone 6k module binary also produces about 50k of other files -- seven or eight of them and a directory.Quote:
Originally Posted by brewbuck
I have absolutely no idea what is going on with that, but it looks like I'm about to learn...
I really like the idea of a smart, portable build system that doesn't have more dependencies than the target project.
Edit: Even thought I may not be "invited", I have to say, a mix of C/C++ seems the way to go if only because you'll lose some talent if you stick to either language exclusively.
Soma
I don't care that much what the project is (still think MVC style editor = silly), but I'm with phantomotop here and would very much like to see a mix of C and C++. I don't know C++ but almost certainly intend to learn it, just not now/not for this. Since this is my first collaborative experience, I'd like to see what gets done how and with what, and I will be using C.Quote:
Originally Posted by phantomotap