Re: Interpreted language(s) in the base
Gabor PALI p...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea Could you be more specific on your concerns? I am just curious. If we want compiled code, we already have C and C++. What we need is an interpreted language with good libraries so people can write scripts and one-liners without having to jump through too many hoops and worry about quoting. The result may not be as fast as a compiled program, but it will be much faster than a shell script and take less time to write than either C or shell. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Am 22.08.2010 13:21, schrieb Dag-Erling Smørgrav: Gabor PALI p...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea Could you be more specific on your concerns? I am just curious. If we want compiled code, we already have C and C++. What we need is an interpreted language with good libraries so people can write scripts and one-liners without having to jump through too many hoops and worry about quoting. The result may not be as fast as a compiled program, but it will be much faster than a shell script and take less time to write than either C or shell. Looks a bit like a swing. First we remove Perl from the base system (years ago) and move to sed/awk, now we discuss using a scripting language in the base system... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Matthias Andree mand...@freebsd.org writes: Looks a bit like a swing. First we remove Perl from the base system (years ago) and move to sed/awk, now we discuss using a scripting language in the base system... Read the discussion from the beginning. We are discussing introducing a domain-specific scripting language, not a general-purpose one. BTW, most of the Perl scripts we had were rewritten in C, not sed / awk. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Hello, Doug. You wrote 16 августа 2010 г., 10:15:55: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility To be honest, lua is used in TONS of (commercial and, often, console) games as scripting engine, without any issues with stability or speed. Console games are very special world, where stability is holy cow, BTW. some JavaScript engines probably fit the description. Yikes! Sorry I asked. :) Best scripting language ever :) Mixup of Lisp and Self, disguised to looks like traditional language. And, yes, I'm serious here. But JavaScript have one problem: both good open-source engines (SpiderMonkey and V8) don't have good system library for file/io/process operations. They are too-browser specific. They can be easily stipped down to bare engines (very small, very efficient), but in such case here is huge amount of work by writing all native objects and operations needed for system scripting. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
C. P. Ghost cpgh...@cordula.ws writes: After all LISP-like syntax is *still* more common and prevalent than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps that use it as a small language. So we can expect more users to be at least partially familiar with it. And there *are* lightweight MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
2010/8/20 Dag-Erling Smørgrav d...@des.no: Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea Could you be more specific on your concerns? I am just curious. I don't understand why this thread seems stuck in that rut. Perhaps because people want to write more reliable code faster? :g ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On 8/20/2010 12:35 PM, Dag-Erling Smørgrav wrote: Gabor PALIp...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. If your only tool is a hammer, all your problems look like nails. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Thu, 19 Aug 2010 20:35:59 +0200 C. P. Ghost cpgh...@cordula.ws wrote:
But seriously, the point isn't so much which specific interpreter
we use (if we go down this road), it's about libraries: most
sysadmin tasks require some basic networking and I/O,
and a FFI to seamlessly call out C functions from .so libs.
And, of course, instead of writing 1,001 sysadmin scripts
with endless code duplication and reinventing of the wheel,
common sysadmin tasks should also be made into reusable
functions, grouped into modules.
Exactly what I had in mind.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort. =A0I will
certainly help out with Scheme.
Funny idea. I only hope we won't end up with a typical
post-dot-com young developer distribution, a la:
60% PHP (yuck!)
25% Java (and XML-everywhere)
15% ${OTHERS}
;-)
If that is what people want then so be it :-)
But I think only little languages like forth, lua, sh, rc,
es scheme have small footprint interpreters that start up
fast and are reasonably efficient.
Anyway, system programming in Scheme is what interests me and
something I already tinker with on and off. If anyone is
interested (in helping or just playing with it), let me know
privately (but *not* on this mailing list).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Fri, Aug 20, 2010 at 10:35 PM, Bakul Shah ba...@bitblocks.com wrote: Anyway, system programming in Scheme is what interests me and something I already tinker with on and off. If anyone is interested (in helping or just playing with it), let me know privately (but *not* on this mailing list). Not Scheme but still FP, and it is about little languages (called domain-specific languages these days) that you may find interesting: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ :g ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Fri, 20 Aug 2010 21:33:08 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no wrote: C. P. Ghost cpgh...@cordula.ws writes: After all LISP-like syntax is *still* more common and prevalent than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps that use it as a small language. So we can expect more users to be at least partially familiar with it. And there *are* lightweight MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. [Couldn't resist responding but my last message on this tangent] If you are open to learning a C like language, one can provide a C like frontend syntax to most of Scheme to a degreee similar to lua. Like C/Lua etc. Scheme is also a block structured language. Apart from syntax, the key differences are: - everything is an expression. - variables are not typed (anything can be assigned to a var) - functions can be anonymous, nested and returned from other functions - symbols lists are built-in unlike in C - no built-in structs, unions or ptrs - a very powerful macro facility - support for continuations ksm for instance implements a C like syntax. See http://square.umin.ac.jp/hchang/ksm/ref/ksm_13.html [Yes, I am aware of Dylan and what happened to it but still think this can be a useful effort] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Luigi Rizzo ri...@iet.unipi.it writes: Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) Actually, the GPL requires that you provide the source in a buildable condition (even if you only ship patches), and most mid-to-high-end AV equipment these days will load and run (or flash) software from a USB mass storage device or CD / DVD. That's certainly the case for my Sony Bravia TV (http://products.sel.sony.com/opensource/source_bivl.shtml) and my NAD Bluray player (not Linux, AFAIK). Furthermore, the GPLv3 forbids the use of GPLv3 software on devices that can't be flashed by the user (the TiVo clause), although the bits that are most commonly used in embedded devices (Linux itself and busybox) are still under GPLv2. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly arei...@bigpond.net.au wrote:
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
got any other suggestions?
This is very much a sorry I asked question, but is none-the
less quite a good one, given the size of the hole to be plugged.
I think that a reasonable answer for this sort of thing might be
one of the dynamic languages that compiles to C, like (perhaps)
one of the schemes (chicken, gambit-C, bigloo, etc). You get
the benefit of flexibility and dynamism with good regexp and
data structure ability, good performance, and only requiring the
build tools available in the base system, as long as you don't
want to be the developer: just ship the C code (as well as the
source, of course).
Unfortunately it seems that quite a lot of people have issues
with lisp syntax these days.
+1 for a scheme shell, but not for the heavy-weight variety that
compiles to C, as that would tie them to a subset of ${ARCH}es.
After all LISP-like syntax is *still* more common and prevalent
than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
that use it as a small language. So we can expect more users
to be at least partially familiar with it. And there *are* lightweight
MIT- or BSD-licensed scheme interpreters out there too:
http://community.schemewiki.org/?scheme-faq-standards#implementations
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On 19/08/2010, C. P. Ghost cpgh...@cordula.ws wrote:
On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly arei...@bigpond.net.au
wrote:
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
got any other suggestions?
This is very much a sorry I asked question, but is none-the
less quite a good one, given the size of the hole to be plugged.
I think that a reasonable answer for this sort of thing might be
one of the dynamic languages that compiles to C, like (perhaps)
one of the schemes (chicken, gambit-C, bigloo, etc). You get
the benefit of flexibility and dynamism with good regexp and
data structure ability, good performance, and only requiring the
build tools available in the base system, as long as you don't
want to be the developer: just ship the C code (as well as the
source, of course).
Unfortunately it seems that quite a lot of people have issues
with lisp syntax these days.
+1 for a scheme shell, but not for the heavy-weight variety that
compiles to C, as that would tie them to a subset of ${ARCH}es.
After all LISP-like syntax is *still* more common and prevalent
than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
that use it as a small language. So we can expect more users
to be at least partially familiar with it. And there *are* lightweight
MIT- or BSD-licensed scheme interpreters out there too:
http://community.schemewiki.org/?scheme-faq-standards#implementations
Will have to disagree on that - part of the point of having such a
thing would be to attract young developers, and while the CS crowd
will be happy with LISP, anyone starting programming after the first
.com bubble will probably be repulsed by non-Algol-like syntaxes.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Folks, Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, it might be worth to take look at Feldspar [1]. It is about defining a domain-specific language for a given domain (Digital Signal Processing) that compiles to standard ISO C99. It is an embedded language in Haskell (*), it requires some research work from the side of implementation, but it looks interesting to me. :g [1] http://feldspar.inf.elte.hu/feldspar/ (*) A domain-specific language for writing compilers. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Thu, 19 Aug 2010 18:00:54 +0200 C. P. Ghost cpgh...@cordula.ws wrote:
On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly arei...@bigpond.net.au wro=
te:
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
got any other suggestions?
This is very much a sorry I asked question, but is none-the
less quite a good one, given the size of the hole to be plugged.
I think that a reasonable answer for this sort of thing might be
one of the dynamic languages that compiles to C, like (perhaps)
one of the schemes (chicken, gambit-C, bigloo, etc). =A0You get
the benefit of flexibility and dynamism with good regexp and
data structure ability, good performance, and only requiring the
build tools available in the base system, as long as you don't
want to be the developer: just ship the C code (as well as the
source, of course).
Unfortunately it seems that quite a lot of people have issues
with lisp syntax these days.
+1 for a scheme shell, but not for the heavy-weight variety that
compiles to C, as that would tie them to a subset of ${ARCH}es.
+1 for Scheme! It has a lot in its favor (see below).
But this is an abstract discussion. Until there are plenty of
useful system scripts (in one of these languages) that people
really want, nothing is going to change.
There is no reason to wait until something is in the base.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort. I will
certainly help out with Scheme.
-- bakul
Scheme has many interpreters compilers so you can write
Scheme scripts to be interpreted and at some point compile
them for better performance if necessary. Scheme has some
excellent text books, a precise definition for a given
standard, it changes slowly, has IDEs and so on. If you stick
to the R4RS subset, almost every scheme interprpter/compiler
will handle it. It has a very powerful macro facility. Its
interpreters can be very small. s9fes and tinyscheme for
example are about 5K lines of C code each. Stalin compiles
Scheme to some extremely tight C code by doing global program
analysis. And there are many other systems in between. slib
is a library of a lot of useful packages that can be used
with most Schemes. Many of these interpreters can be used
from C/C++. Many provide a C-FFI to call C functions.
Tinyscheme packages all of Scheme state in a single structure
so one can easily create a separate Scheme interpreter per
thread. There is even a vi clone written in 4K lines s9fes
Scheme! Still beta but already useful.
These many choices can be very confusing but we can pick one
and stick to writing R4RS portable Scheme code.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Thu, Aug 19, 2010 at 7:22 PM, Bakul Shah ba...@bitblocks.com wrote:
+1 for Scheme! It has a lot in its favor (see below).
But this is an abstract discussion. Until there are plenty of
useful system scripts (in one of these languages) that people
really want, nothing is going to change.
Yes, it's abstract: I want my bikeshed named Gauche (lang/gauche): ;-)
http://practical-scheme.net/gauche/
But seriously, the point isn't so much which specific interpreter
we use (if we go down this road), it's about libraries: most
sysadmin tasks require some basic networking and I/O,
and a FFI to seamlessly call out C functions from .so libs.
Ideally a shell with a REPL loop, but even that isn't strictly
necessary for the scripts.
And, of course, instead of writing 1,001 sysadmin scripts
with endless code duplication and reinventing of the wheel,
common sysadmin tasks should also be made into reusable
functions, grouped into modules.
We're talking about a major task here, and no matter if it
will be in the base or as a port, it's something that will take
some time to emerge, so it's not a realistic option in the
short (or even middle) term.
There is no reason to wait until something is in the base.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort. I will
certainly help out with Scheme.
Funny idea. I only hope we won't end up with a typical
post-dot-com young developer distribution, a la:
60% PHP (yuck!)
25% Java (and XML-everywhere)
15% ${OTHERS}
;-)
Scheme has many interpreters compilers so you can write
Scheme scripts to be interpreted and at some point compile
them for better performance if necessary. Scheme has some
excellent text books, a precise definition for a given
standard, it changes slowly, has IDEs and so on. If you stick
to the R4RS subset, almost every scheme interprpter/compiler
will handle it. It has a very powerful macro facility. Its
interpreters can be very small. s9fes and tinyscheme for
example are about 5K lines of C code each. Stalin compiles
Scheme to some extremely tight C code by doing global program
analysis. And there are many other systems in between. slib
is a library of a lot of useful packages that can be used
with most Schemes. Many of these interpreters can be used
from C/C++. Many provide a C-FFI to call C functions.
Tinyscheme packages all of Scheme state in a single structure
so one can easily create a separate Scheme interpreter per
thread. There is even a vi clone written in 4K lines s9fes
Scheme! Still beta but already useful.
These many choices can be very confusing but we can pick one
and stick to writing R4RS portable Scheme code.
Yes, but see above w.r.t. the needed library. And, again, it's
an academic discussion, as much as I'd love to do sysadmin
scripts in Scheme myself.
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
I didn't want to prolong this now mostly off-topic discussion
too much, but:
On Thu, Aug 19, 2010 at 06:00:54PM +0200, C. P. Ghost wrote:
+1 for a scheme shell, but not for the heavy-weight variety that
compiles to C, as that would tie them to a subset of ${ARCH}es.
Why do you say that? Most of the C-generators that I know of
produce fairly standards-compliant C code that should just work
anywhere. Sure there are some (with sophisticated memory
managers, mostly) that get intimate with the platform, but
presumably we would have to stay away from those for this sort
of exercise...
Cheers,
--
Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote: Will have to disagree on that - part of the point of having such a thing would be to attract young developers, and while the CS crowd will be happy with LISP, anyone starting programming after the first .com bubble will probably be repulsed by non-Algol-like syntaxes. I suspect that you're right, though that disappoints me somewhat. The only other language that I'm aware of that does a reasonable compiles-to-C and has an algol-like syntax is Eiffel (specifically SmartEiffel), but I haven't used it for years, and don't know how it's travelling. It's also nowhere near as dynamic and fun a programming experience, IMO. Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Fri, Aug 20, 2010 at 10:47:39AM +1000, Andrew Reilly wrote: On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote: Will have to disagree on that - part of the point of having such a thing would be to attract young developers, and while the CS crowd will be happy with LISP, anyone starting programming after the first .com bubble will probably be repulsed by non-Algol-like syntaxes. I suspect that you're right, though that disappoints me somewhat. The only other language that I'm aware of that does a reasonable compiles-to-C and has an algol-like syntax is Eiffel (specifically SmartEiffel), but I haven't used it for years, and don't know how it's travelling. It's also nowhere near as dynamic and fun a programming experience, IMO. Don't assume that the CS crowd are LISP or FP sycophants or that having to program in C is unattractive to new blood (a term I prefer over young developers). FWIW, I use Perl to prototype all sorts of algorithms and data structures - and most recently, Qore (I maintain the lang/qore port). But I don't believe either should be in base when it's so dead simple to install them from ports. Cheers, Brett Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- B. Estrade estr...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: got any other suggestions? This is very much a sorry I asked question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). Unfortunately it seems that quite a lot of people have issues with lisp syntax these days. There are some other compile-to-C languages that might work too. [Aside: I think that the answer to this question might get a *lot* more interesting once we have llvm in the base system (it comes along with clang). There are (and I'm sure will be more) languages that compile down to llvm byte-code without the contortions required in going through C.] Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: got any other suggestions? This is very much a sorry I asked question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). slightly off topic but I disagree on the latter part. The whole point of having source code is to be able to make modifications, small or large, private or ones to be contributed back. As a teacher, i am very concerned about the ease-of-use for non-developer types: it is important to make it easy for people to experiments, as this is one of the ways people learn things. Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
+---[ Luigi Rizzo ]-- | On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: | On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: | got any other suggestions? | | This is very much a sorry I asked question, but is none-the | less quite a good one, given the size of the hole to be plugged. | | I think that a reasonable answer for this sort of thing might be | one of the dynamic languages that compiles to C, like (perhaps) | one of the schemes (chicken, gambit-C, bigloo, etc). You get | the benefit of flexibility and dynamism with good regexp and | data structure ability, good performance, and only requiring the | build tools available in the base system, as long as you don't | want to be the developer: just ship the C code (as well as the | source, of course). | | slightly off topic but I disagree on the latter part. | | The whole point of having source code is to be able to make | modifications, small or large, private or ones to be contributed | back. As a teacher, i am very concerned about the ease-of-use for | non-developer types: it is important to make it easy for people to | experiments, as this is one of the ways people learn things. I have to agree with Luigi. You have to work out your target audience, and that should be your first constraint to choosing the language. If the language has a syntax structure that's going to be hard to parse by non-developers at first glance (like forth or perl), then you're really limiting the userbase. C is scriptable and embeddable these days from a variety of projects, but, I wouldn't recommend that either necessarily (since C doesn't have dynamic typing), even if we could get 100% architecture coverage. -- Andrew Milton a...@theinternet.com.au ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Hi Luigi, On 19/08/2010, at 00:28 , Luigi Rizzo wrote: slightly off topic but I disagree on the latter part. I didn't expect everyone to agree. Not sure that I do, necessarily, either. (A neat, small language like TCL or Lua is probably better for most of the uses we're discussing here.) Just making a low-impact suggestion to the problem of making use of a higher-level language than C while not dragging large lumps of code into core, or accumulating maintenance issues. The whole point of having source code is to be able to make modifications, small or large, private or ones to be contributed back. As a teacher, i am very concerned about the ease-of-use for non-developer types: it is important to make it easy for people to experiments, as this is one of the ways people learn things. I'm not making any suggestion about preventing or discouraging tinkering. After all, we used to carry f2c around in the base, in order to support Fortran code. There's no particular reason *not* to provide the front-end for (whatever language), but so long as it's readily available in ports, and build-able form a base config, I don't see that being in base is essential. Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source. This is an opinion I certainly don't share. There are many languages that I don't like but that doesn't make them useful, or even best-for-purpose in their niche. (a) I'm not suggesting that we don't provide source, and (b) learning a new language is an excellent excellent exercise for students, and one that they're going to have to go through often, for the rest of their careers. (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) It's nothing of the sort, of course. In the scenario I suggested, the task of updating the putative program would involve the editors available in base, to edit the source shipped with the system. Only the compilation of the edited source might or might not be gated by installing the port for the putative compiler. Several of the examples I gave originally come with an interpreter and debugging environment, so even that potential argument need not be a blocker. Not a high bar to entry, I suggest. Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
2010/8/16 Dag-Erling Smørgrav des at des.no: Doug Barton dougb at FreeBSD.org writes: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. It looks like this is rearing its head again elsewhere: http://mail-index.netbsd.org/tech-userlevel/2009/10/24/msg002827.html http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748 Student Name: Lourival Vieira Organization: The NetBSD Foundation Organization Home Page: http://www.netbsd.org/ Mentor Name: Marc Balmer Title: Provide support for dynamic NetBSD kernel extensions using the Lua language - Lunatik/NetBSD Abstract: This project has the goal to develop a framework to provide support for dynamically extending the NetBSD kernel using the Lua programming language. I intend to allow adaptation of the kernel and its subsystems for different purposes at runtime, through download of Lua scripts and exposure of kernel internals to Lua. Moreover, this framework will provide support for rapid prototyping and experimentation with new algorithms and mechanisms inside the kernel. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Interpreted language(s) in the base
On Sun, 15 Aug 2010, Ivan Voras wrote: This is my long-term point - it really would be beneficial to have an alternative, richer language in base which would fall between the categories of a good system language but far too complex for simple string-parsing stuff which is C and a good glue language for system utilities but lacking more evolved concepts which is shell. I sort of agree with you here, but I don't. :) ONE of the reasons that perl was axed from the base was that it was very very hard to keep the bmake glue up to date. However, a bigger reason was that it was impossible to marry our concept of a stable branch with the ever-evolving world that was perl. We often had a situation where a long-lived stable branch would have a VERY stale version of perl in it, to the point that the only rational course of action was to disable the perl build and install a usable version from ports. We do not want to go back down that road. (And I'm not speculating here, I lived through it.) Personally, I think the whole base and ports thing is an artificial divide that is rapidly losing utility. I think we're past due for stripping the FreeBSD base down to a much more bare minimum, and having a lot more of the bells and whistles live in the ports tree. Aside from the usual suspects (BIND, sendmail, etc.) I also would dearly like to see the ports tools themselves move into the ports tree. This would make it TONS easier to introduce new features and bug fixes to the ports infrastructure. There are many other such examples. That said, I know it's useless to simply import something in the hope it will be useful in the future. Not only useless, but certain to be vigorously opposed by many, including me. My best bet is that I (or someone else) would write something useful enough to be imported in base in such a language, which would warrant importing the language itself. 13 years ago I very nearly wrote mergemaster in bash for this exact reason (and believe me, many is the time that I wish I had possessed the courage to be that devious back in the day, but I was new to the community and still idealistic). 6 years ago when I started working on portmaster I had the same internal debate, but my better angels won out. Short version of my tortuous internal struggle, you can't win this argument, even if I though you should be able to. **IF** this were a good idea, the only rational choice would be one of the more sophisticated yet still POSIX-compliant shells because they offer you significantly more features, without the dramatic churn problem that the cooler languages do. So let me give you the reader's digest version of the debate, then ask yourself again if you want to keep proposing this: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility rubytoo much churn, weird/zealotrous user community, more utility but still feels to new for some of our graybeards python possible, but you still have the churn problem, not to mention actually pulling this trigger massively inflames the communities for all the other interpreted languages ksh arguably most POSIX-compliant, has a lot of good features, but but (also arguably) sort of a klunky shell which reduces the value in the '2 birds for 1 stone' department zsh less POSIX-compliant, oddly deviant from standard bourne-derived shells which makes graybeards break out in hives also, see ruby under user community bashprobably the best candidate in the 3 most important categories, POSIX compliance, good feature set (although not as feature full as even zsh is), and is a less klunky shell. HOWEVER, it's too establishment to make the kids happy, and isn't as clean in the license category as we'd like. (And yeah, I purposely omitted that question from all the other candidates as well.) got any other suggestions? some JavaScript engines probably fit the description. Yikes! Sorry I asked. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On 16/08/2010, at 4:15 PM, Doug Barton wrote: On Sun, 15 Aug 2010, Ivan Voras wrote: This is my long-term point - it really would be beneficial to have an alternative, richer language in base which would fall between the categories of a good system language but far too complex for simple string-parsing stuff which is C and a good glue language for system utilities but lacking more evolved concepts which is shell. I sort of agree with you here, but I don't. :) ONE of the reasons that perl was axed from the base was that it was very very hard to keep the bmake glue up to date. However, a bigger reason was that it was impossible to marry our concept of a stable branch with the ever-evolving world that was perl. We often had a situation where a long-lived stable branch would have a VERY stale version of perl in it, to the point that the only rational course of action was to disable the perl build and install a usable version from ports. We do not want to go back down that road. (And I'm not speculating here, I lived through it.) And lest anyone think that's just perl, look at the history of TCL in the base system as well. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Sun, Aug 15, 2010 at 11:15:55PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: However, a bigger reason was that it was impossible to marry our concept of a stable branch with the ever-evolving world that was perl. This one at least is conceptually pretty easy to solve. We don't have any worries about how old or new the version of expat in base is; since it's not called libexpat, nothing but the stuff in base written specifically against it has to worry about it getting old, and upgrading it requires only checking against those things in base. So we could go right ahead and import perl, just renamed to 'bsdscript' 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
In message alpine.bsf.2.00.1008152240370.66...@qbhto.arg, Doug Barton writes: On Sun, 15 Aug 2010, Ivan Voras wrote: This is my long-term point - [...] Some of use were 12 years ahead of you :-) I sort of agree with you here, but I don't. :) ONE of the reasons that perl was axed [...] Actually, let me put that stuff on the record, as one of the prime convicted suspects of that entire ordeal. Tcl, a very small language, specifically designed to be embeddable in other programs, was imported into FreeBSD because we had a dream. The intent of the Tcl import was that it would be embedded into other programs, and thus open them up to customization at a net reduction in C-code lines. Inetd(8) is an example: Rather than exec this file you would get to examine IP#'s and other context before you made up your mind about what to do, all in a friendly script language. Other obvious candidates: ampd(8), ppp(8), config(8) and so on. In other words, the Intent behind Tcl was architectural: To improve the base system, eliminated duplication of structural code giving an overall stream-lining of the system. We probably did not manage to sell that vision back then, and I will forego conclusions on the advisability of our vision in hindsight. Tcl was soon axed again, because people did not see the value of having a high-level language, if it were not THEIR high-level language, which was missing the point by the width of the horizon. Next we tried Perl. The thing we probably did not realize and certainly not appreciate the importance of, is that pretty much all other languages than Tcl, are languages you add things to, not languages you add to things. This has two implications: The first is that the only thing you gain by including such a language, is the ability to run scripts in it. That might improve (or not!) the readability of the rc.d scripts. The second is that such languages really do not want to be treated as house-guests in a software distribution. Maintaining them is a major hazzle and they all have fuzzy boundaries, in the sense that calls along the lines of We should really import the P-FOO package/module/library also because it is so much more convenient... will never cease. With Perl we found conclusively that the benefits did not even get close to balance the hazzle. And thus perl was also removed again. Based on what we learned, My advice would be: The window of opportunity for an embeddable language is long since closed. Nobody uses the base-system any more to an extent where it makes sense to bother about, for that concept to have been long term viable, it would have had to cross-fertilize into desktops (KDE, Gnome etc) and Apache. Adding any of the big languages (perl, python, ruby, ...) will not _ever_ pay off the costs, even if we exclude from the bill the friendly fire involved in determining which we pick. If it is the /bin/sh syntax that bothers you, set your eyes on gettung us a zsh or ksh upgrade, that may be feasible and would be sensible, considering what a new language can do for the base system. But otherwise: Forget it. Poul-Henning PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Personally, I think the whole base and ports thing is an artificial divide that is rapidly losing utility. I think we're past due for stripping the FreeBSD base down to a much more bare minimum, and having a lot more of the bells and whistles live in the ports tree. Strongly disagree. One of the reasons I've been using FreeBSD for many years is precisely the fact that the base system is very good, and contains most of what I need without installing a lot of extra ports/ packages. (Yes, I always end up installing perl, but that is one of a select few.) If I only wanted a kernel and everything else as installable packages, I might as well use one of the Linux distributions. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Mon, 16 Aug 2010, Poul-Henning Kamp wrote: ... PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. Besides the syntax FORTH ist the only embeddable high level language which has both intepreter and compiler built in. It has a small form factor too. One alternative could be something like WABA (http://waba.sourceforge.net/). Besides the wrong license it would mean to have pre-compiled byte code on the FS and no chance to recompile on the fly... Or ECMAScript as a pure interpreted language. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Mon, Aug 16, 2010 at 09:47:40AM +0200, sth...@nethelp.no wrote: Personally, I think the whole base and ports thing is an artificial divide that is rapidly losing utility. I think we're past due for stripping the FreeBSD base down to a much more bare minimum, and having a lot more of the bells and whistles live in the ports tree. Strongly disagree. One of the reasons I've been using FreeBSD for many years is precisely the fact that the base system is very good, and contains most of what I need without installing a lot of extra ports/ packages. I can agree to this argument. While it is easy to install required tools on your system it is a hassle if you are doing support for systems installed by someone else. With FreeBSD you can expect a great set of tools already available. I remember the old days when I was doing embedded systems on tiny CF media and thought I only stripped the tools I really don't need, but in the end I often missed something. But I also never missed something with a complete base. Perl is a fancy tool, but when you really need it you don't have a problem in installing it. It is not that long time ago that a friend with his Linux couldn't even check the negotiated ethernet link without installing an additional tool - easy if you have network, but isn't this a tool to debug network problems? The last thing I've missed was something to script in single-user-mode. In loader we have FICL and in single-user-mode we have /bin/sh, while the shell is reasonable to write scripts it also requires external helpers which sits in non-mounted /usr - e.g.: grep, sed, lock, ... With todays disk and partition sizes however I don't split /usr - I split /usr/local (often don't even this), so this isn't a problem anymore. Having an embeddable lanmguage is another story - no matter if it is TCL, FICL, Lua or whatever. There is a possible benefit for extending our tools, but after reading PHKs history description I'm not that sure about it anymore. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
Doug Barton do...@freebsd.org writes: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
zsh less POSIX-compliant, oddly deviant from standard bourne-derived shells which makes graybeards break out in hives also, see ruby under user community ZSH has a POSIX-compliant interface through emulate -L sh or by naming (linking) zsh binary sh. even if the man page says that the posix compliance isn't complete from my own tests it is at least as compliant as bash. For example I'm able to run portmaster using zsh instead of sh. (by the way it is a lot faster using zsh :) but that is another storry) -- Bapt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
2010/8/16 Dag-Erling Smørgrav d...@des.no: Doug Barton do...@freebsd.org writes: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. Replying randomly to this post but also to phk's, dougb's and others' points specifically about lua: 1. churn / version stability / language of the day History of lua's recent releases is: - 5.2 : TBD, new yet unfinished release, will be done when it is done - 5.1 : 2006. - 5.0 : 2003. - 4.0 : 2000. ... - 1.0 : 1993. [source: http://www.lua.org/versions.html] If anything, it's much slower than the hip languages. 2. Future compatibility / ports dependancies, etc. If anything gets imported, lua or something else, I will loudly support renaming it to something like bsdscript, binaries and libraries and all. 3. Size of language Lua *is* 32 C files (and as many C headers) in a single directory, totalling (with headers) a bit over 17,000 lines. The interpreter can be compiled with gcc -o bsdscript *.c. Libraries can be built similarly. There are no other libraries or modules which make lua, Among the mentioned above are equivalents of stdio, libm, libz, etc. 4. Embeddability Here's the documentation: http://www.lua.org/pil/24.1.html Personally, I'm more interested in the opposite direction: writing FreeBSD-specific lua libraries (which would wrap, as an obvious example coming from me, libgeom) making it possible to script complex system scripts in lua. 5. License Released under MIT license: http://www.lua.org/license.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On 08/16/2010 00:47, sth...@nethelp.no wrote: If I only wanted a kernel and everything else as installable packages, I might as well use one of the Linux distributions. That wasn't at all what I said, or what I was suggesting. There is a middle ground between everything is a package and the status quo. The fact that people keep asking for more things to be in the base that clearly don't/can't belong there is evidence of this. Meanwhile, to respond more or less generally to some of the specific responses I received: 1. My descriptions of the various possible things to import were meant to be tongue-in-cheek, not exhaustive technical reviews of the alternatives. The fact that some people bit on those, particularly the ones that described rabid user communities, is, well, funny. :) 2. phk's description of the the situation with tcl is both more eloquent and more complete than I could have come up with, which is why I didn't mention it in my previous post. Although the situation with perl is more vivid for me since I was directly affected by it my recollections of the tcl thing match his description, and more importantly I agree with him that it should be viewed as a cautionary tale. 3. In case I wasn't clear in my last post the correct answer at this time is neither import more stuff into the base nor turn more things into packages. It's write good apps using the tool(s) of your own choosing and we'll find a way to make it work. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
