[ANN] GSL Shell new beta release with anti-gran graphics module

classic Classic list List threaded Threaded
126 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

[ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
Hi all,

I'm glad to announce an exciting new beta release of GSL Shell that
include a module to produce beautiful anti-grain graphics. This new
module use the AGG library to provides graphics primitives for
producing beautiful plotting. For the moment the API is not complete
but I have already all the functions to cover 90% of typical user
needs for plotting functions. I'm planning also to develop an
higher-level module entirely written in Lua to provide more simple and
higher level plotting functions.

The graphics modules are available for Windows and Linux. Here the
link to download the source files and also windows binaries (it is the
0.9beta1 release):

https://savannah.nongnu.org/files/?group=gsl-shell

and the link to GSL Shell project:

https://savannah.nongnu.org/projects/gsl-shell/.

You can test the plot module by charging the file 'examples/plot.lua'.

>From the technical point of view I was surprised to discover how
*good* is the AGG library, it is one on the most remarkable piece of
software I've ever seen. It is written in C++ and heavily uses
templates. The strong point of the library are:
- very elegant and clear code
- very clever interface design
- excellent performances in term of speed and quality
- it works flawless, out of the box, both on Windows and on linux (with g++)
- it does includes some excellent modules to provide platform abstraction for
  displaying graphs with X11 or Windows with exactly the same interface

At the beginning I was thinking to use "the GNU plotting utilities"
but I've abandoned this idea because
- this package does not provide any support to display graphics on Windows
- the project is not evolving since a long time
- no anti-grain support available
- the source code of the "graph" utility is really awful and can be
considered as a
  reference for "bad software design" (I've begun to work on this code
to adapt it
  but I soon abandoned the idea).

Otherwise, I'm using also the pthread library. While this is almost
trivial on linux I was surprised to discover that a good
implementation also exists on windows and it works out of the box:
http://sourceware.org/pthreads-win32/ .

I hope you will try the software and give me some feedback before the
official release.

Thank you very much in any case.

Best regards,
Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Miles Bader-2
Francesco Abbate <[hidden email]> writes:
> I'm glad to announce an exciting new beta release of GSL Shell that
> include a module to produce beautiful anti-grain graphics.

What is "anti-grain graphics"?

Thanks,

-Miles

--
Accordion, n. An instrument in harmony with the sentiments of an assassin.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Robert Raschke
On Thu, Dec 3, 2009 at 9:21 AM, Miles Bader <[hidden email]> wrote:

What is "anti-grain graphics"?



http://en.wikipedia.org/wiki/Anti-Grain_Geometry :

(Unfortunately, the main site, http://www.antigrain.com/, appears to be down just now.)

Robby

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Miles Bader-2
In reply to this post by Francesco Abbate-2
build problems:

[my system is an "x86_64" system]

(1) the following error:

    make[3]: ディレクトリ `/usr/local/src/gsl-shell-0.9beta1/lua/src' に入ります
    gcc --std=c99 -march=i586 -g -DGSL_SHELL -DLNUM_COMPLEX -DLUA_USE_LINUX   -c -o lapi.o lapi.c
    lapi.c:1: error: CPU you selected does not support x86-64 instruction set

solution:  remove the "-march=i586" from lua/src/Makefile

(2)

    make DEFS='"-DGSL_SHELL -DLNUM_COMPLEX"' PLATFORM=linux -C agg-plot
    make[1]: Entering directory `/usr/local/src/gsl-shell-0.9beta1/agg-plot'
    g++ -O2 -DGSL_SHELL -DLNUM_COMPLEX -I.. -I../lua/src -I../lua/etc -I/usr/include/agg2 -c utils.cpp
    In file included from utils.cpp:8:
    utils.h:5:30: error: agg_trans_affine.h: No such file or directory
    ...

solution: ???

(did you forget that file?)

Thanks,

-Miles

--
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Robert Raschke
In reply to this post by Robert Raschke
On Thu, Dec 3, 2009 at 9:24 AM, Robert Raschke <[hidden email]> wrote:
On Thu, Dec 3, 2009 at 9:21 AM, Miles Bader <[hidden email]> wrote:

What is "anti-grain graphics"?



http://en.wikipedia.org/wiki/Anti-Grain_Geometry :

(Unfortunately, the main site, http://www.antigrain.com/, appears to be down just now.)



Ah, http://www.antigrain.com is now reachable, must have been my side of the network.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Miles Bader-2
In reply to this post by Miles Bader-2
Miles Bader <[hidden email]> writes:
>     In file included from utils.cpp:8:
>     utils.h:5:30: error: agg_trans_affine.h: No such file or directory
>     ...
>
> solution: ???

Ah, now that I know what anti-grain graphics is, I figured out the
solution: install libagg-dev

(and install libgsl0-dev for other stuff)

After those changes, it builds!

Now to figure out how it actually works... :)

Thanks

-Miles

--
Resign, v. A good thing to do when you are going to be kicked out.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
In reply to this post by Francesco Abbate-2
On Thu, Dec 3, 2009 at 11:09 AM, Francesco Abbate <[hidden email]> wrote:
> module use the AGG library to provides graphics primitives for
> producing beautiful plotting. For the moment the API is not complete
> but I have already all the functions to cover 90% of typical user
> needs for plotting functions. I'm planning also to develop an
> higher-level module entirely written in Lua to provide more simple and
> higher level plotting functions.

Well done, Francesco!  The plots are indeed good looking, and I'm glad
that you avoided the old Gnuplot mess.

Being lazy and overworked, I took the easy way out, tried out the
Windows binaries.  To get the plot demos working, I had to open a
command shell in the examples directory, run ..\gsl-shell and then use
dofile 'plot.lua'.

..\gsl_shell plot.lua

Does not work directly, but does if you put 'io.read()' as the last
line to prevent the process from just dying.

steve d.

PS the more I play with things like |x| x*(x-1), I wish that this
syntax was supported in vanilla Lua. A very convenient bit of
syntactical sugar if you are fond of the functional style.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
steve donovan <[hidden email]> writes:

> PS the more I play with things like |x| x*(x-1), I wish that this
> syntax was supported in vanilla Lua. A very convenient bit of
> syntactical sugar if you are fond of the functional style.

function(x) return x*(x-1) end

is terse enough not to pine for shortcuts looking like line noise.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
On Thu, Dec 3, 2009 at 11:50 AM, David Kastrup <[hidden email]> wrote:
> function(x) return x*(x-1) end
>
> is terse enough not to pine for shortcuts looking like line noise.

Fair enough, the usual notation does not read badly.  But the shortcut
notation is not harder to read _if_ not abused - that may be the
problem.

Of course, most mathematics looks like line noise at some point...
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by David Kastrup
2009/12/3 David Kastrup <[hidden email]>:
> function(x) return x*(x-1) end
>
> is terse enough not to pine for shortcuts looking like line noise.

Hi David,

I've introduced the notation |x| x*(x-1) because
- I was writing a *lot* of times "function(args) return expr end" and
I was feeling
  a come compact notation was useful
- I've seen this notation adopted in metalua
- it is very close the the mathematical notation.

I'm in correspondance with many peoples and almost all of them likes
this kind of notation. I believe its adoption is a matter of taste and
it also depends on the kind of code you write usually but I feel it is
a usuful clean notation that could have its place in Lua.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
In reply to this post by David Kastrup
On Thu, Dec 3, 2009 at 11:50 AM, David Kastrup <[hidden email]> wrote:
> function(x) return x*(x-1) end

The notation really shines when you start doing functional things like currying:

> div = |x| |y| x/y
> = div(1)(10)
0.1

But the real motivation is that it makes using functions like 'map' a
little more pleasing:

squares = map(|x| x*x, values)

Also, for 'quoting' an expression so that it can be called in another context:

timer(1000,|| print 'timer finished')

Perhaps the issue here is that those two little lines are easy to get
lost in the otherwise keyword-driven syntax of Lua?

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Miles Bader-2
steve donovan <[hidden email]> writes:
> Perhaps the issue here is that those two little lines are easy to get
> lost in the otherwise keyword-driven syntax of Lua?

I think that's the _point_ -- "function (..) return ... end" is _too_
noticeable, and so obscures the actual important bits in situations
which the || notation is intended for.

Compare

   some_fun (foo, function (x) return x*x end)

with

   some_fun (foo, |x| x*x)

the latter is far more readable because the important parts aren't
obscured by the heavyweight syntax of the normal function syntax.

Of course, good style would probably indicate that you should use the
normal syntax in cases where the body of the function is large.

-miles

--
I'd rather be consing.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
In reply to this post by Francesco Abbate-2
On Thu, Dec 3, 2009 at 12:27 PM, Francesco Abbate <[hidden email]> wrote:
> a usuful clean notation that could have its place in Lua.

Exactly, an alternative, not compulsory.

While dealing with Lua syntax extensions, it would occaisionally be
very useful to be able to drop the parentheses when calling functions
with a single argument which is an anonymous function, in the same way
as with string literals and table constructors.

E.g. Orbit's htmlify trick involves changing the function environment
so that unknown functions are assumed to represent HTML tags:

render = htmlify (function(web)
  return html {
    head { },
    body { h2 'hello there' }
   }
end)

That 'end)' is a little awkward, but this could be written so:

render = htmlify function(web)
  return html {
    head { },
    body { h2 'hello there' }
   }
end

Then together with 'short lambda' we get:

render = htmlify |web| html {
  head { },
  body { h2 'hello there' }
}

I'm not particularly attached to this notation, but it is consistent
(Lua already allows leaving out of parens in some cases; why not
another?)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
In reply to this post by steve donovan
steve donovan <[hidden email]> writes:

> On Thu, Dec 3, 2009 at 11:50 AM, David Kastrup <[hidden email]> wrote:
>> function(x) return x*(x-1) end
>
> The notation really shines when you start doing functional things like
> currying:
>
>> div = |x| |y| x/y
>> = div(1)(10)
> 0.1

function div(x) return function(y) return x/y end end
print div(1)(10)

Sorry, but I don't see the point in a notation that saves hardly any
token, but obfuscates what is happening.

> But the real motivation is that it makes using functions like 'map' a
> little more pleasing:
>
> squares = map(|x| x*x, values)

squares = map(function(x) return x*x end, values)

The "little" here is just hiding a closure.

> Also, for 'quoting' an expression so that it can be called in another context:
>
> timer(1000,|| print 'timer finished')

timer(1000,function() print 'timer finished' end)

> Perhaps the issue here is that those two little lines are easy to get
> lost in the otherwise keyword-driven syntax of Lua?

It's just not the Lua style.  It does not tell the tale.  Lua does not
have the C obsession (worse in perl) with having an operator for
everything, requiring priorities in the vast maze of their ilk and
making things undecipherable unless you generously parenthesize, in
which case there is even less amount of saved source code.

This notation is more or less used in Ruby, but it is unclear when you
can use it, what effects it has on scoping, how to nest and so on.

The Lua syntax fits on a single small page.  And that's a very large
benefit not to be thrown away lightly.

"|list| expr" may be well definable as pure syntactic sugar for
function(list) return expr end, but it still needs operator priorities
to establish where expr ends.  Foreigners to the language will not know
how to read this construct, whereas reading the equivalent in current
Lua syntax is immediately comprehensible.

It does not reorder the linear reading order of list and expr, it does
not avoid reevaluation.  It saves very few tokens.  So it has much less
raison d'être than, say, C's ?: operator.

And it can't even sensibly deal with multiple return values.

local x=3
fun2(|x| x*x,x)

Is this
fun2(function(x) return x*x end, x)
or
fun2(function(x) return x*x, x end)
?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
In reply to this post by steve donovan
steve donovan <[hidden email]> writes:

> On Thu, Dec 3, 2009 at 12:27 PM, Francesco Abbate <[hidden email]> wrote:
>> a usuful clean notation that could have its place in Lua.
>
> Exactly, an alternative, not compulsory.

Every alternative occupies a compulsory place in the syntax definition
and the amount of material a newcomer has to absorb before being able to
read others' programs.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Paul Hudson-2
In reply to this post by David Kastrup
> It's just not the Lua style.  It does not tell the tale


+1

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
In reply to this post by David Kastrup
On Thu, Dec 3, 2009 at 1:00 PM, David Kastrup <[hidden email]> wrote:
> Is this
> fun2(function(x) return x*x end, x)
> or
> fun2(function(x) return x*x, x end)
> ?

Well, that did shut me up briefly, I'll grant you that.

But I still think that Miles had a valid point when he said that small
expressions can be overwhelmed by the function...return..end
machinery.  Perhaps we are simply so used to anonymous functions that
we have learned to skim over them, much as C etc programmers see that
old nastiness 'for(i = 0; i < n; i++)' as one blob of information?

In Penlight we went to some trouble to introduce placeholder
expressions, so that _1*_1 would resolve as something that could be
_compiled_ to function(x) return x*x end.  But it cannot cover all of
Lua's expression syntax, since 'or' is not an operator, '==' insists
that both arguments are the same type, etc.

It's possible that a relative newbie to Lua would be more comfortable
with the short notation (especially one with mathematical needs),
which modifies one line of the syntax:

   function ::= function funcbody | `|` [parlist] `|` exp

Which BTW, means that it's the first meaning ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Christof Schardt
In reply to this post by Francesco Abbate-2
> link to download the source files and also windows binaries (it is the
> 0.9beta1 release):
> https://savannah.nongnu.org/files/?group=gsl-shell

When I follow that link, I see archives p to v0.7, but
no v0.9 and no binaries. What am I doeing wrong?



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Andreas Krinke
Christof Schardt wrote:
> When I follow that link, I see archives p to v0.7, but
> no v0.9 and no binaries. What am I doeing wrong?

The mirrors are not up to date. Try this direct link:

http://ftp.cc.uoc.gr/mirrors/nongnu.org/gsl-shell/gsl-shell-0.9beta1-src.tar.gz
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Given
In reply to this post by Francesco Abbate-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Francesco Abbate wrote:
[...]
>>From the technical point of view I was surprised to discover how
> *good* is the AGG library, it is one on the most remarkable piece of
> software I've ever seen. It is written in C++ and heavily uses
> templates. The strong point of the library are:

Yes, it's fantastic! Well worth a look if you want to draw graphics ---
it produces *the* nicest vector graphic output I've ever seen.

Incidentally, people should be aware there are three versions:

- - v2.5, which is GPL'd (not LGPL'd!)
- - v2.4, which is most MITish/BSDish, but also contains a restricted
license component
- - the 'lightweight rasterizer', which is MITish

So you need to be careful depending on what you're using it for.

We're using the lightweight rasterizer. This is a scarily tiny library
consisting of two whole source files that will draw closed polygons onto
a variety of surfaces. It doesn't do anything else, but it supports
polygons of arbitrary complexity, alpha blending, subpixel antialiasing,
is extraordinarily clear and easy to adapt (once you've got your head
around the weird template constructions), and has an MITish license ---
it's an ideal starting point for more complex things. I did do some Lua
bindings, but it's so trivial to interface to that they're not worth
distributing.

Which version are you using? Do you have Lua bindings for the more
exotic bits, such as the AGG widget set?

- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksXrAsACgkQf9E0noFvlzht6wCdHRnnQnxnfDRc4O+NcjnKglgK
wW4AmwVzqlC7qKBQ6pV4+TJrVVhp90Wr
=vzNu
-----END PGP SIGNATURE-----
1234 ... 7