Before spending significant time on it, I thought I would ask if this would
be acceptable as a debian package
Some possible issues:
1. Its not under GPL but a 'creative licence'
2. It build does not use autotools but make with small edits. I guess I
could try putting it under autotools
3. Its an old project
I still believe that for many students C is still a first language and
therefore having an interpreter to study would greatly help them up their
learning curve
Rustom Mody <rustompm...@gmail.com> writes:
> I use and am interested in packaging the C interpreter
> http://www.linuxbox.com/tiki/node/149 > 1. Its not under GPL but a 'creative licence'
>From the homepage, and the source, this 'creative license' appears to be
the Artistic License, used by, for example, Perl. I do not think that
will be a problem.
> 2. It build does not use autotools but make with small edits. I guess I
> could try putting it under autotools
Please don't do that. There's absolutely nothing wrong with not using
autotools. If minor edits is all the upstream build system needs, doing
that is far less invasive than replacing the whole build system.
Especially as there is no upstream to send the autotoolsification to,
there is absolutely no need to do such an invasive change.
> 3. Its an old project
Now this is a bigger isse: with no upstream, possible bugs are all yours
to fix. Are you willing and capable of acting as if you were the
upstream author?
> I still believe that for many students C is still a first language and
> therefore having an interpreter to study would greatly help them up their
> learning curve
And this is another issue: why would a C interpreter help in any way? We
already have battle-proven C compilers, which students will be exposed
to anyway, since if they work under unix, chances are, they'll use gcc
or clang anyway.
I do not think a C interpreter adds any value, I'm afraid. Granted, it's
code may be easier to understand than any other C compilers, but you
don't need to study a compiler to understand the language. Especially
not if its your first language.
-- |8]
-- To UNSUBSCRIBE, email to debian-mentors-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87394lbp1x....@luthien.mhp
-- To UNSUBSCRIBE, email to debian-mentors-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/CALL-Q8wJfRwjHcFPyy0w4JXww3TJ8Lp5BLNX=jZ0ai6UR=1...@mail.gmail.com
On Sat, Jul 21, 2012 at 11:40:52AM +0530, Rustom Mody wrote:
> I use and am interested in packaging the C interpreter
> http://www.linuxbox.com/tiki/node/149
> Before spending significant time on it, I thought I would ask if this would
> be acceptable as a debian package
> Some possible issues:
> 1. Its not under GPL but a 'creative licence'
> 2. It build does not use autotools but make with small edits. I guess I
> could try putting it under autotools
> 3. Its an old project
> I still believe that for many students C is still a first language and
> therefore having an interpreter to study would greatly help them up their
> learning curve
Gergely Nagy already wrote some smart things about aspects I'm not commenting
on now.
Using an interpreter instead of a compiler usually moves some error checking
from "compile time" to "runtime". This may not be useful for students.
But I don't object against packaging a C interpreter. You may get more
feedback from others on how welcome this software is in Debian on the ITP.
Regards,
Bart Martens
-- To UNSUBSCRIBE, email to debian-mentors-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120721070324.GC21...@master.debian.org
> Before spending significant time on it, I thought I would ask if this would
> be acceptable as a debian package
> Some possible issues:
> 1. Its not under GPL but a 'creative licence'
> 2. It build does not use autotools but make with small edits. I guess I
> could try putting it under autotools
> 3. Its an old project
> I still believe that for many students C is still a first language and
> therefore having an interpreter to study would greatly help them up their
> learning curve
>>From the homepage, and the source, this 'creative license' appears to be
> the Artistic License, used by, for example, Perl. I do not think that
> will be a problem.
>> 2. It build does not use autotools but make with small edits. I guess I
>> could try putting it under autotools
> Please don't do that. There's absolutely nothing wrong with not using
> autotools. If minor edits is all the upstream build system needs, doing
> that is far less invasive than replacing the whole build system.
> Especially as there is no upstream to send the autotoolsification to,
> there is absolutely no need to do such an invasive change.
>> 3. Its an old project
> Now this is a bigger isse: with no upstream, possible bugs are all yours
> to fix. Are you willing and capable of acting as if you were the
> upstream author?
I think this issue is alleviated by the fact that someone seems to have
worked on this interpreter during the last year. Further information can
be found here:
http://eic-howto.wikispaces.com/
> I do not think a C interpreter adds any value,
I think a C interpreter can be useful if it can be embedded and
integrated into applications, as it allows for C scripting and quick
prototyping of functions, which can be both positive.
What are the benefits of EIC with respect to Tiny CC (tcc package) and
CINT (root-system package) that others have suggested?
Bests,
Giulio.
-- To UNSUBSCRIBE, email to debian-mentors-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500C8543.3080...@gmail.com
On Mon, Jul 23, 2012 at 4:27 AM, Giulio Paci <giuliop...@gmail.com> wrote:
> On 21/07/2012 08:34, Gergely Nagy wrote:
> > Rustom Mody <rustompm...@gmail.com> writes:
> >> 1. Its not under GPL but a 'creative licence'
> >>From the homepage, and the source, this 'creative license' appears to be
> > the Artistic License, used by, for example, Perl. I do not think that
> > will be a problem.
> >> 2. It build does not use autotools but make with small edits. I guess I
> >> could try putting it under autotools
> > Please don't do that. There's absolutely nothing wrong with not using
> > autotools. If minor edits is all the upstream build system needs, doing
> > that is far less invasive than replacing the whole build system.
> > Especially as there is no upstream to send the autotoolsification to,
> > there is absolutely no need to do such an invasive change.
> >> 3. Its an old project
> > Now this is a bigger isse: with no upstream, possible bugs are all yours
> > to fix. Are you willing and capable of acting as if you were the
> > upstream author?
> I think this issue is alleviated by the fact that someone seems to have
> worked on this interpreter during the last year. Further information can
> be found here:
> http://eic-howto.wikispaces.com/
> > I do not think a C interpreter adds any value,
> I think a C interpreter can be useful if it can be embedded and
> integrated into applications, as it allows for C scripting and quick
> prototyping of functions, which can be both positive.
> What are the benefits of EIC with respect to Tiny CC (tcc package) and
> CINT (root-system package) that others have suggested?
Interpreter means two different things: scripting engine and something
interactive like 'being-in-a-shell.' tiny cc only seems to be a scripting
interpreter. ie I cant start it up and play around 'inside it' like for
shell/python etc
End of this mail Ive put a few lines from an example interaction with eic
root system seems quite large:
trying to install root-system-bin gives me: 46 packages install, 27 MB to
download
trying to install root-system gives me: 133 packages install, 50 MB to
download
eic source is 500K
> Bests,
> Giulio.
Thanks Guilo for responding.
Rusi
$ eic
*************************************************************************
EiC V4.3.3 - Copyright (c) 1995 to 2000, by Edmond J. Breen
EiC comes `as is' and with ABSOLUTELY NO WARRANTY OF MERCHANTIBILITY AND
FITNESS OF PURPOSE
*************************************************************************
C 1> 1+2;
1+2;
3
C 2> 1 << 3;
1 << 3;
8
C 3> printf("%d << %d is %d\n", 3,4,3<<4)
printf("%d << %d is %d\n", 3,4,3<<4)
Error in ::EiC:: near line 3: Expected ;
Error: clean up forced
C 4> printf("%d << %d is %d\n", 3,4,3<<4);
printf("%d << %d is %d\n", 3,4,3<<4);
3 << 4 is 48
13
C 5> printf("%d << %d is %d\n", 2,4,2<<4);
printf("%d << %d is %d\n", 2,4,2<<4);
2 << 4 is 32
13
