Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C-derived OO Prog Language, Cross Platform GUI Toolkit, 2D/3D Graphics Engine Project

Reply
Thread Tools

C-derived OO Prog Language, Cross Platform GUI Toolkit, 2D/3D Graphics Engine Project

 
 
jerstlouis@gmail.com
Guest
Posts: n/a
 
      10-26-2007
I'm hoping to generate some interest in the Ecere SDK which is the
result of many years of software development.

With the Ecere SDK, you can:

Build Cross Platform GUI Applications:

Develop applications once, deploy them on all platforms alongside a
lightweight runtime environment.

Use Powerful Object Oriented Programming:

Ecere introduces eC, an object oriented language derived from and
fully compatible with C, compromising neither runtime performance nor
ease of use.

Easily Integrate Real-time 3D Graphics:

Writing 3D graphics applications has never been this easy. A builtin
3D engine supporting both Direct3D and OpenGL is fully integrated in
the Ecere runtime environment.

Please read more about it at www.ecere.com

http://www.ecere.com/technologies.html#eC describes the eC language.

 
Reply With Quote
 
 
 
 
cr88192
Guest
Posts: n/a
 
      10-26-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ps.com...
> I'm hoping to generate some interest in the Ecere SDK which is the
> result of many years of software development.
>


<snip>

>
> Please read more about it at www.ecere.com
>
> http://www.ecere.com/technologies.html#eC describes the eC language.
>


spam, or actually intended to make conversation?...
also looks commercial (a detractor in my book).

well, maybe I can make something useful out of this.


if I wanted, I could probably spam off that I dumped most of GLSL's
functionality on top of C (to a lesser extent, some of its syntax as well),
but I have more features than does GLSL itself...

but, my lang is still C, after all, a header is still needed to add most of
this, and in a less fancy form, a subset of this can also be emulated in
normal C (allowing traditional compilers to still work).

I also have a dynamic type system, garbage collection, and a dynamic
prototype-based object system (library, not compiler features, though
potentially addable as optional extensions at some point...).

and, by extension (part of my 'main' project, and not my compiler
subproject), a mass of custom 3D code, a custom GUI framework, ...


but, if I post, my goal is mostly conversation, not simply to flog off my
stuff (which is IMO far from something probably most anyone else would want
to use at this point...).


and my lang, at its core, is still C, IMO, and not some completely different
language.
the extensions are, after all, optional, and generally require special
headers before they add any potentially clashable stuff...


some are not, but are not likely to clash:
int __proxy foo()
{
stuff...
}

where the __proxy keyword indicates that a function can be replaced
dynamically (it is a much 'softer' option than dynamicly relinking parts of
the all, since it still works for statically compiled/linked code, and does
not break code using function pointers).

unlike a function pointer, it otherwise looks and behaves like an ordinary
function (and is still callable just the same as well).

however, internally, the mechanics are a little more complicated than a
traditional function pointer. the concept is simple, that what is called is
actually a jump, that jumps through the pointer and into the current version
of the function, but the fun is in dealing with the linker mechanics (the
actual wrapping, pointer, and jump, has to be done at the linker level,
rather than at the assembler level).


actually, I can partly credit some of the LLVM people for giving me this
idea, partly by pointing out that forcibly dynamically relinking things as I
was doing would break function pointers, and this is a less brittle option.

(well, I will give them credit for what all they have done, though at
present I am doing my own thing here...).


but, since this, for the most part does not matter at the C level (I could
have made all functions proxy, although this would hurt performance), one
can make this portable very easily (just has to be in one of the headers
somewhere):
#ifndef __BSCC
#ifndef __proxy
#define __proxy
#endif
#endif

but, then again, I am mostly using proxies for dealing with my compiler
anyways, so this isn't really all that needed.


or something...



 
Reply With Quote
 
 
 
 
jerstlouis@gmail.com
Guest
Posts: n/a
 
      10-26-2007
As I said, I am trying to generate interest in this SDK which I am
announcing and offering to the world

As you can see on the first page, the SDK is available free for
download.

If you actually spend a bit of time learning about it, I will be happy
to discuss it more with you

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      10-27-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
> As I said, I am trying to generate interest in this SDK which I am
> announcing and offering to the world
>
> As you can see on the first page, the SDK is available free for
> download.
>
> If you actually spend a bit of time learning about it, I will be
> happy to discuss it more with you


You haven't been plonked here yet as a spammer, but you came very
near when I discovered the same post in comp.programming, without a
cross-post and follow-up. This is either ignorance or a spammer
move.

The lack of proper quoting and attribution encourages the ignorance
explanation. So far.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      10-27-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> As I said, I am trying to generate interest in this SDK which I am
> announcing and offering to the world
>


that is one way to term it...

sorry if I am a bit confrontational here, I am saying things as I see them.
hell, you did give a response, at least giving some points...


> As you can see on the first page, the SDK is available free for
> download.
>


well, you say it is free, but do you say it is not commercial?...
well, as can be noted, I have not much investigated the site, but it does
look commercial.

some of us like that are compilers are open source, and that our standards
are open and more or less communally accepted. to some extent, it is a
standard of agreement, rather than of dictation.

to some people, "come and use my free-although-commerial non-standard
technologies" is not necessarily all that well taken.


for example, would you regard it as a good or a bad thing if someone else
completely cloned your whole effort, and gained popularity and success at
it?...

for some of us, that would be a good thing, after all, it is good ideas that
are reused.
other people would feel annoyed and ripped off, because it was someone else,
and not themselves...


> If you actually spend a bit of time learning about it, I will be happy
> to discuss it more with you
>


or you can tell, for example, is it actually C?...
the examples make me think, it is not.
some of the variations you mention, similarly point out its non-C-ness...
(though, admittedly, it is a different language...).

so, compiler extensions vs language differences.

this group, at least in a general sense (not going into specifics, like
whether or not said API feature is standard, and so on...), is still about C
proper, and not "vaguely C-ish languages".

note that to a large degree, this group is also a gathering place of newbs,
where it is IMO better to start off newbs with standard technologies and
practices, and let them mess with more divergent possibilities as they see
fit...

for example, comp.lang.misc could be a better place, for all it matters (if
only, sadly, there were more people on comp.lang.misc...).

comp.object may also be a worthwhile place, and others...


now, one could argue, I am "a pot calling a kettle black", maybe...
after all, I have my own funky non-standard (and largely, barely working and
crap) framework, oh well.

of course, to what extent I operate, it is realization of certain goals
(say, a partial destruction of the compile/link/run cycle distinction,
allowing C to be loaded like scripts, or, in part, using C like python,
lisp, or smalltalk...), it does not matter as much to me if I realize these
goals, or someone else (say, for example, the LLVM community, which may well
have a better footing at least, or at least a far more developed project).

as a result, talking about technologies matters more important, and flogging
it off is slightly less important (well, assuming all my stuff were actually
all that usable). just, one has to talk about specific technologies and
efforts often to describe more general technologies...


so, one can ask, what is the goal?...



 
Reply With Quote
 
jerstlouis@gmail.com
Guest
Posts: n/a
 
      10-27-2007
As for being commercial, it really depends on what you define as being
commercial...

It is being developed by Ecere Corporation ( which is basically me ),
a corporate entity hoping to make enough money to further support the
development of the technologies and allow me to make a living focusing
my own time on the project.

I am considering making it open source (thinking about BSD license),
especially if I feel it will help the adoption of the language and
SDK.

As for open standards, I will be happy to make the Ecere technologies
open standards as well.

Regarding CBFalconer's comment, I will have to plead for the
ignorance, as I don't usually post on news groups... I also duplicated
the post on comp.lang.c++ as well... Sorry. I should have linked to
one main post to focus the conversation together, what is the usual
way to do so?

As for my technology, it is a new object-oriented language, based on C
(but distinct), although 99.9% compatible with C. Therefore I believe
it is of value for developers currently programming in C, because they
have everything to gain and nothing to lose. Hence why I was posting
it on comp.lang.c. It might also be of interest to many C++
programmers who will find in eC many of the advantages brought to more
recent languages such as Java and C#, but staying closer to
traditional C programming.

 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      10-27-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> As for being commercial, it really depends on what you define as being
> commercial...
>
> It is being developed by Ecere Corporation ( which is basically me ),
> a corporate entity hoping to make enough money to further support the
> development of the technologies and allow me to make a living focusing
> my own time on the project.
>


my case, I am a lone hobbyist, currently a college student stuck (by
parents' will) studying theology (would much rather be doing CS or
something, or at least math, but oh well...).


> I am considering making it open source (thinking about BSD license),
> especially if I feel it will help the adoption of the language and
> SDK.
>


ok, that is better.

a lot of people take up the closed source ideal of "make stuff, spam stuff,
get people to use it, force them to give money later on...".


> As for open standards, I will be happy to make the Ecere technologies
> open standards as well.
>


ok.


> Regarding CBFalconer's comment, I will have to plead for the
> ignorance, as I don't usually post on news groups... I also duplicated
> the post on comp.lang.c++ as well... Sorry. I should have linked to
> one main post to focus the conversation together, what is the usual
> way to do so?
>


usually, one will cross-post (including the various groups they are posting
to).

usually, there will also hopefully be something worth responding to, and not
something simply resembling spam...


> As for my technology, it is a new object-oriented language, based on C
> (but distinct), although 99.9% compatible with C. Therefore I believe
> it is of value for developers currently programming in C, because they
> have everything to gain and nothing to lose. Hence why I was posting
> it on comp.lang.c. It might also be of interest to many C++
> programmers who will find in eC many of the advantages brought to more
> recent languages such as Java and C#, but staying closer to
> traditional C programming.
>


maybe.
mine, at least cosmetically, is still much closer to traditional C...

I say cosmetically, primarily making provision that the language is actually
validly backwards compatible. this is the major goal in my case, though
there are still points where my compiler lapses, so it does not fully
implement standard functionality.

for the most part, I have been going off the C99 standard, including many of
its restrictions, such as the general requirement for prototypes (I forget
if I made this a warning or error), ...


now, of course, if I added compiler extensions for dynamic typing, or an
object system, it would be a little less like traditional C (or, maybe, its
own language), but oh well.


here is an example (a test, utilizing one of the more drastic sets of
compiler extensions, well, in my compiler at present):
----
#include <stdio.h>
#include <complex.h>
#include <vecnf.h>

int main()
{
double _Complex ci, cj;
quat p, q, r;
vec3 u, v, w;
vec3 a, b, c;
float x, y, z;

#if 1
u=vec3(1,0,0);
v=vec3(0,1,0);
w=u%v;

printf("I %f %f %f %f\n", u.x, u.y, u.z, u.w);
printf("J %f %f %f %f\n", v.x, v.y, v.z, v.w);
printf("K %f %f %f %f\n", w.x, w.y, w.z, w.w);

a=vec3(3,4,5);

printf("A %f %f %f %f\n", a.x, a.y, a.z, a.w);

x=1; y=2; z=3;

x=a^u;
y=a^v;
z=a^w;

printf("%f %f %f\n", x, y, z);

ci=1+2i;
cj=ci*ci;
printf("%f %f\n", creal(ci), cimag(ci));
printf("%f %f\n", creal(cj), cimag(cj));

#endif

p=quat(3,1,0,0);
q=quat(0,5,1,-2);
r=p*q;
// r=q*p;

// p=quat(1,2,0,0);
// q=quat(1,2,0,0);
// r=p*q;

// r=qlerp(p, q, 0.5);

printf("P %g%+gi%+gj%+gk\n", p.w, p.x, p.y, p.z);
printf("Q %g%+gi%+gj%+gk\n", q.w, q.x, q.y, q.z);
printf("R %g%+gi%+gj%+gk\n", r.w, r.x, r.y, r.z);

return(0);
}


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Pythonic cross-platform GUI desingers la Interface Builder (Re: what gui designer is everyone using) Dietmar Schwertberger Python 5 06-25-2012 10:15 PM
Re: Pythonic cross-platform GUI desingers la Interface Builder (Re: what gui designer is everyone using) Dietmar Schwertberger Python 5 06-15-2012 11:35 PM
Re: Pythonic cross-platform GUI desingers la Interface Builder (Re: what gui designer is everyone using) Chris Angelico Python 1 06-14-2012 06:43 PM
C-derived OO Prog Language, Cross Platform GUI Toolkit, 2D/3D Graphics Engine Project jerstlouis@gmail.com C++ 0 10-26-2007 07:54 PM
Starting and stopping a prog. from another prog. andoni.oconchubhair@ie.fid-intl.com Java 1 10-22-2006 10:43 PM



Advertisments