View Poll Results: Choice of project

Voters
24. You may not vote on this poll
  • A small scripting language, possible using bytecode.

    11 45.83%
  • A C compiler.

    6 25.00%
  • An internationalization (i18n) library.

    4 16.67%
  • An implementation of the C++ STL for C.

    5 20.83%
  • An operating system.

    7 29.17%
  • A portable build system.

    9 37.50%
  • A "modern" editor (MVC pattern).

    4 16.67%
  • A game maker.

    2 8.33%
  • An RPG.

    2 8.33%
  • An IDE with integrated SVN support.

    4 16.67%
Multiple Choice Poll.

Thread: CBoard Community Project: Poll #1

  1. #31
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    "From a timeline standpoint, what I'm seeing here is that we should first design and implement a simple scripting language, then leverage that language to implement a build system."

    ++

    Even a simple imperative language with a few domain specific primitives (added as an extension or something) would be a heck of a lot more useful than... whatever insane hybrid you'd call a "makefile".

    "Let's open up the floor to general commentary on the scripting language idea for 24 hours."

    Here or elsewhere? Eh, how about a "friendly" Ada2k7? ^_^

    A more serious offering/suggestion, build tools are usually (always?) built from one aspect of parallel processing or the other so I'd say you'd need to support automic operations for objects directly. (As opposed to simply exposing an API for read/write locks and letting the use deal with it themselves.)

    Soma

  2. #32
    Complete Beginner
    Join Date
    Feb 2009
    Posts
    312
    Quote Originally Posted by brewbuck View Post
    The top three vote-winners are:

    #1: A small scripting language, possibly using bytecode.
    #2: A portable build system.
    #3: An operating system.

    How do folks feel about this layout?
    I think we should do another poll (24h?) based solely on these three items, but this time a voter may only choose one item. Poll #1 told us about the preferences, and a poll #2 can tell us about the priorities.

    I would appreciate to see the build system appear in the first place, because it doesn't make sense to start some other project first if we intend to do the build system anyway. By starting with the build system, we can use succeeding projects as beta tests for the build system.

    From a timeline standpoint, what I'm seeing here is that we should first design and implement a simple scripting language, then leverage that language to implement a build system.
    The language for the build system will be pretty simple, and probably won't even be Turing-complete. Hence it's a bad idea to come up with a build system language on its own, i.e. without the surrounding build system.

    I'm not trying to just keep "my" project idea in the running -- honestly. But it did score #2, and I think there are so many good ideas here that we should try to tie them together with a common thread.
    I'd like to see us first implement the build system and then discuss plans for succeeding projects. Operating systems (as well as bytecode interpreters) are better left to professionals, which probably doesn't characterize well our current team as a whole. I'm somewhat amused of some people's attitude here to watch the "gurus" do their magic work. Either everyone dances or nobody dances.


    I prefer a project where we actually have a fair chance of establishing some competition with regard to already existing solutions. Maybe I'm too much in favor of the build system...

    Greets,
    Philip
    All things begin as source code.
    Source code begins with an empty file.
    -- Tao Te Chip

  3. #33
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    I'm not trying to just keep "my" project idea in the running -- honestly. But it did score #2, and I think there are so many good ideas here that we should try to tie them together with a common thread.
    If there are really 24 people going to be involved (which I don't know why you would vote if you aren't), then I think in fact we have enough to get going on at least two projects simultaneously, especially if they could be related in the way which has been suggested. It should be possible for the build project group to come up with specs for the language group, and on that basis proceed. This will help to give the language group an initial focus, but of course need not be limiting either.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #34
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Anyway, I had another last minute idea. What about a binary editor? (Not just a hex editor), i.e. interpreting sets of bits/bytes as IEEE 754, or other things, writing, grouping bits, etc. Even the scripting language idea could be used to implement "macros" .

    Just something I've been looking for an doesn't seem to exist.

    Other than that, you idea for a Scripting language -> Build system -> ... Sounds good.

  5. #35
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    From a timeline standpoint, what I'm seeing here is that we should first design and implement a simple scripting language, then leverage that language to implement a build system. (Then use that build system to compile an operating system?)
    good one ;-p looks like a good idea. Maybe we could build that language with the build system, then use it for the build system and build the build system in the build system itself?

  6. #36
    Registered User
    Join Date
    Dec 2008
    Location
    Black River
    Posts
    128
    Quote Originally Posted by brewbuck View Post
    From a timeline standpoint, what I'm seeing here is that we should first design and implement a simple scripting language, then leverage that language to implement a build system.
    I agree. I think if a small scripting language is done first, then whatever the next project is will become much easier to deal with using it as a base (OK, so maybe it won't help much with the operating system but a scripting language would be needed at some point).

  7. #37
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Suprised "a shell" didn't make it in here. I don't see why you couldn't have a simple, portable shell (that includes basic scripting) that was also a simple, portable build app. It would probably satisfy a lot of the OS curious too.

    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #38
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Ronix View Post
    I agree. I think if a small scripting language is done first, then whatever the next project is will become much easier to deal with using it as a base (OK, so maybe it won't help much with the operating system but a scripting language would be needed at some point).
    So here's my suggestion. Let's design a basic scripting language syntax that provides variables, functions, lexical scope, and flow control. The language will be general-purpose, but might be extended in the future with more features that are specific to its use within a build system.

    Look at your typical Makefile -- it has sections which are "make-y" and sections which are "script-y". Yet these are melded into a single language. I want that, but something that doesn't suck as much. Make's rules for variable expansion are archaic, and the syntax is limited in arbitrary ways.

    Having a complete scripting language also guarantees that anything can be accomplished by the build system, if you're willing to write script functions to do it.

    The scripting language itself should be simple enough to design and implement. The real work I think is in providing a small "standard library" to do things like string manipulation and I/O.

    Rather than having me dictatorially spec it out, we should have a brainstorming thread.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #39
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    We should analyse the pros and cons of existing languages. Then we should decide the paradigms (procedural, functional, object-oriented, imperative etc.), after that we can move on to syntax. Later on, will it be bytecode-compiled or not? Extensions? Garbage-collector? At last we should bring everything together with a standard library. Voila, a basic language. Then we could add libraries to extend it into a build-system language.

    Note: If we want a portable build system, we should also focus on flag syntax (MSVC uses /*, while most others use -*) and use things like Optimize(level) instead of "CFLAGS = "$CFLAGS -O<level>"".

  10. #40
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Brafil View Post
    Note: If we want a portable build system, we should also focus on flag syntax (MSVC uses /*, while most others use -*) and use things like Optimize(level) instead of "CFLAGS = "$CFLAGS -O<level>"".
    Actually, MSVC works just fine with - instead of / for compiler/linker options. The options aren't necessarily CALLED the same thing, but then they aren't always for other compilers either.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #41
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    That's what I meant. Try to build an app using MSVC and autoconf. Good luck

  12. #42
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Brafil View Post
    That's what I meant. Try to build an app using MSVC and autoconf. Good luck
    Are you trying to say that autoconf can not handle compilers that use different options than what gcc uses? I doubt it, but I expect that people who USE autoconf tends to be likely to have hard-coded gcc options into the autoconf script, perhaps.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  13. #43
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Yes. My idea was to prevent this. e.g. You can't easily compile gcc with MSVC (at least not the autoconf sources)

  14. #44
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Brafil View Post
    Yes. My idea was to prevent this. e.g. You can't easily compile gcc with MSVC (at least not the autoconf sources)
    Well, I doubt that is part of the language/build system specification itself - this would have to be part of the BUILD SPECIFICATION, where it should be possible to specify that "If we use compiler X, use option A, else if compiler = Y, use option B".

    It has little to do with whether the compiler requires / or - to indicate the option, and a lot to do with providing multiple compiler options.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  15. #45
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Ok, you're right - but we should support this automatically for common things like debugging symbols, optimization and profiling.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. cboard community project
    By zacs7 in forum Projects and Job Recruitment
    Replies: 76
    Last Post: 05-16-2009, 08:30 PM
  2. Problem Displaying a Struct
    By rockstarpirate in forum C++ Programming
    Replies: 16
    Last Post: 05-05-2008, 09:05 AM
  3. CBoard Project?
    By jverkoey in forum A Brief History of Cprogramming.com
    Replies: 40
    Last Post: 06-21-2004, 03:15 PM
  4. POLL! What was your first C project?
    By webguy899 in forum C Programming
    Replies: 8
    Last Post: 05-02-2002, 11:15 PM