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.

CBoard Community Project: Poll #1

This is a discussion on CBoard Community Project: Poll #1 within the Projects and Job Recruitment forums, part of the Community Boards category; Originally Posted by brewbuck one thing I had considered was a scripting language that was identical to C -- i.e., ...

  1. #106
    Complete Beginner
    Join Date
    Feb 2009
    Posts
    312
    Quote Originally Posted by brewbuck View Post
    one thing I had considered was a scripting language that was identical to C -- i.e., interpreted C.
    Valgrind on steroids sounds a like a great idea. We may even implement array bounds checking.

    Greets,
    Philip

    PS: I suggest that we move the whole discussion to our new forum.
    All things begin as source code.
    Source code begins with an empty file.
    -- Tao Te Chip

  2. #107
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Sorry, I'd like to join, but I can't see the verification image. It's a fault of my computer, I almost never see them. Could the admin please create an account for me? Thx.

    Besides, Technically there is no difference between a scripting and programming language. But IMO scripting is more using OS utilities, file manipulation, makefiles etc. while programming is to do more complex tasks as kernel, GUI or game programming. There is no clean border, but I think you know what you mean. Maybe we could use a C-like syntax, but please not statically-typed.
    Last edited by Brafil; 05-22-2009 at 06:25 AM.

  3. #108
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    "It's a fault of my computer, I almost never see them. Could the admin please create an account for me?"

    Depending on what the problem ultimately is and the software used you could try loading the file in a window of its own.

    Soma

  4. #109
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    I can't see this registration image. You know, where you enter five or six digits or letters. It doesn't work on another computer here, nor on windows nor on linux. I can't load it because I can't see it, even if I mark the text around the place it had to be.

    PS: I'm not a robot! I can see the verification image of this forum.

  5. #110
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Re: brainstorming, here is my thought du (yester)jour, which is just a suggestion about *how* we could be brainstorming:
    CCP • View topic - brainstorming methodology

    I like brewbuck's idea, if we could still put a little OO in. Which does not necessarily mean an interpreted C++. "Eval" sometimes seems like a potentially lazy sloppy thing but it is also a very quick solution for (eg) preventing a user from invoking a runtime error -- this might make the build system *much* more user friendly. Perhaps I or brewbuck or someone else can come up with a little "description" of the concept for those who are not familiar with it. Again I am busy today with other things, unfortunately, but I will actually try to do exactly this over the weekend.

    So here's another idea: if people have concepts (like eval) that they know from an (or a number of) existing languages that they think are worth including, put them on the table. But first go read my post on the other forum about *how* to put them on the table...seriously.

    ps. I hope someone helped brafil out?
    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

  6. #111
    Complete Beginner
    Join Date
    Feb 2009
    Posts
    312
    Quote Originally Posted by Brafil View Post
    Sorry, I'd like to join, but I can't see the verification image. It's a fault of my computer, I almost never see them. Could the admin please create an account for me? Thx.
    Send me a PM containing your email address.

    Does anybody else have the same problem?

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

  7. #112
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Brafil View Post
    But IMO scripting is more using OS utilities, file manipulation, makefiles etc. while programming is to do more complex tasks as kernel, GUI or game programming. There is no clean border, but I think you know what you mean.
    I'll give it to you right now Brafil: IMO this is an irrational prejudice (perhaps you meant "shell scripting"?). The term "script" simply indicates that an interpreter is involved; ie, the program does not run as a process of it's own (the way a binary executable would, because it has been compiled into asm), it runs as a "script" for an interpreter. The reason you will never see a kernel written in a scripting language has nothing to do with limitations of syntax, et al. -- it is because you cannot run an interpreter without a binary executable kernel. In that sense, bytecode interpreted languages like Java use scripts, with an added level of indirection. There will be no Java kernels either.

    Consider: this site, which is for the openGL perl bindings, claims that "Due to Perl's strength in string manipulation, there are cases where Perl can even outperform C when loading/manipulating shader programs." Of course, the perl interpreter is written in C. There's a trip.

    Conversely, the popularity of interpreted scripting languages is because of the compressed syntax enabled by the interpreter. I have done GUI stuff in perl and C, and my jury is very much still out on the issue of "which is better", ultimately. For sure, you can get more complex much faster/easier with perl, *because* perl is more complex, syntactically, than C.

    A moral: Don't bother contrasting "scripting" languages with "non-scripting" languages in terms of performance or usefulness.
    Last edited by MK27; 05-25-2009 at 02:58 PM.
    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. #113
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    O_o

    Yog Sothoth!

    The things you see when you don't have your elephant gun.

    Soma

  9. #114
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,237
    So... I've been busy with other things lately, but I'm still around.

    Anybody, please let me know if you need something facilitated or otherwise managed, or some kind of impediment removed. I'm here as a resource. It sounds like we're still hashing out our ideas.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  10. #115
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    For whatever reason, the forum software kept claiming my post was source so I gave up and added code tags around everything.

    Code:
    I have an urge to put on a red hat, gesture wildly at
    my enemies, and scream "I choose you brewbuck!". ^_^;
    
    The "C as an interpreted language" thing sounds good,
    but honestly the choice between '{'/'}', '('/')', or 'BEGIN'/'END'
    and other such things don't really make a difference to me.
    
    I'd like to vote to add parametric polymorphisms to that,
    but that isn't exactly a necessity I suppose. And that does
    kind of kill part of your offerings for wanting C in the first place. 
    
    Where would we go with the include model? Abandon the
    actual C model using the `include' directive as an instruction
    to the interpreter to load the interfaces if they are available?
    Or keep the C model and maybe use `progma' for such things?
    
    I don't know where everyone went... it seems that interest
    peeked and died rather quickly. So what's the verdict here?
    Did everyone lose interest or am I just over-reading the silence?
    Soma
    Last edited by phantomotap; 05-26-2009 at 01:34 AM. Reason: broke lines

  11. #116
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,237
    Quote Originally Posted by phantomotap View Post
    I'd like to vote to add parametric polymorphisms to that,
    but that isn't exactly a necessity I suppose. And that does
    kind of kill part of your offerings for wanting C in the first place.

    Where would we go with the include model? Abandon the
    actual C model using the `include' directive as an instruction
    to the interpreter to load the interfaces if they are available?
    Or keep the C model and maybe use `progma' for such things?[/Code]
    I would have it work identically (or at least seem so) to compiled C. The idea being you could take a pre-existing C program and execute it in the virtual environment for dynamic analysis. Making the language even a little bit backward-incompatible with C would defeat a large part of the purpose, in my mind.

    There are, obviously, difficulties here, like headers which change their behavior if a particular preprocessor symbol is defined. But that doesn't seem insurmountable -- each unique instance of a header can be identified by the file path itself plus information on all the preprocessor state that was in effect at the moment that header was included.

    These preprocessed units could be written to disk, somewhat like object files, but not exactly, since in compiled C, an object file corresponds to a "translation unit" and in this case it would correspond to an actual source file plus all preprocessor state. But I think most, if not all of this, could be hidden from the user.

    I'd like to see some object oriented features as well, but we're going to need an interpreter base first, anyway, so getting something like that working is a long way out.

    Thoughts?
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #117
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    "I would have it work [...] purpose, in my mind."

    *shrug*

    I get what your saying... vanilla C is just such a painful language. Of course, the "OO", functional, and generics facilities I envisioned truly expand C without the difficulties of C++ so we could certainly start at the ground floor adding those facilities as an option later. And since, or at least it seems, that one of your goals in "sandboxing" C is to catch bad uses of the poor type system it is very likely that the base source will have good support for a strong type system before we get to that point.

    "There are, obviously, difficulties [...] moment that header was included."

    I wasn't even talking about third party headers included from the interpret context. I was talking about the standard C headers and environment headers of the platform (the interpreter itself).

    All standard compliant platforms have the `string.h' header, how do we handle that? My suggestion would be to assume conformance of outside standard headers built on "advance knowledge" of how these headers should behave while falsifying the include process for these files (possibly with a fake include directory passed to the interpreter with the same precedence rules as you may find with compilers). Other headers could then be interpreted in the same "sandbox" fashion as the source itself.

    Then there are environment headers like "our_make_utility.h"--which would probably be useless in the non-interpreted context--, how do we handle that? I figured we would expose an API to potential consumers, other developers building on the work of the interpreter, that would be used to "fake" such headers as part of interpreting a given translation unit.

    I guess I'm asking, within the C inclusion model, how do you envision hooking the API(s) provided by a given build of the interpreter to the real source files? And for structures and functions beyond the standard? And for those compiled into a given build of the interpreter?

    Your original offering, or at least one of the original ones, noted a desire for a "single source" tool. With that in mind, I can imagine no way that such things could not be faked, but you probably have something different in mind.

    "These preprocessed units [...] hidden from the user."

    This seems a reasonable approach for intermediate files... possibly storing prototypes, type information, and that sort of thing in a reasonable table/format instead of the traditional inclusion model (which would then to be parsed as C every time) allowing us to bypass additional passes? (Is this something like modern pre-compiled headers?) Yet another file format would be annoying, but at the same time, parsing/building common files formats with that kind of potential only adds another layer of difficulty. (Thinking specifically of stream-ready formats or plain text files with markup like XML.) I've used SQLite for that kind of thing; the license will certainly not be an issue. Or would you'd rather just stick to a "home grown" file format"?

    "I'd like to see some [...] is a long way out."

    As it seems that we've dwindled to three or four... never?! >_<

    Soma

  13. #118
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,237
    Quote Originally Posted by phantomotap View Post
    I wasn't even talking about third party headers included from the interpret context. I was talking about the standard C headers and environment headers of the platform (the interpreter itself).

    All standard compliant platforms have the `string.h' header, how do we handle that? My suggestion would be to assume conformance of outside standard headers built on "advance knowledge" of how these headers should behave while falsifying the include process for these files (possibly with a fake include directory passed to the interpreter with the same precedence rules as you may find with compilers). Other headers could then be interpreted in the same "sandbox" fashion as the source itself.
    We could have a "virtual standard library" like you are suggesting (I think), but if the virtual environment provides enough base functionality, I don't see why we couldn't actually compile a "for real" C standard library like uClibc. At some point any C library has to call out to platform-dependent routines provided by the OS. This would "just" be another port of one of the existing C libraries to the new platform.

    I'm not sure yet whether I think that's less work than implementing a virtual C library. Could go either way, I guess.

    "These preprocessed units [...] hidden from the user."

    This seems a reasonable approach for intermediate files... possibly storing prototypes, type information, and that sort of thing in a reasonable table/format instead of the traditional inclusion model (which would then to be parsed as C every time) allowing us to bypass additional passes? (Is this something like modern pre-compiled headers?) Yet another file format would be annoying, but at the same time, parsing/building common files formats with that kind of potential only adds another layer of difficulty. (Thinking specifically of stream-ready formats or plain text files with markup like XML.) I've used SQLite for that kind of thing; the license will certainly not be an issue. Or would you'd rather just stick to a "home grown" file format"?
    The basic need, it seems, is a way of serializing/deserializing the interpreter's internal representation of the compiled source. As far as how that's done, I don't really care as long as whatever method we choose is not a nightmare from an extensibility/backward compatibility standpoint.

    As it seems that we've dwindled to three or four... never?! >_<
    With summer coming on in the northern hemisphere I expect we'll probably see people shifting back and forth. Some people want to go outside in the summer, for others its the best time to write code.

    I admit I haven't even been over to our website lately. I'll try to get some time on this tonight.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  14. #119
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    I'd never considered something like uclibc, and from a cursory glance... it looks like the build environment would suffer from the dependency. I'll look more when I get the chance.

    Soma

  15. #120
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    @MK27: Yes, I was meaning _shell_ scripting languages. I didn't say shell, cuz for me it's nod interpreted-vs-compiled rather than the things the language was designed for.

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21