Re: [Potassco-users] Lonsdaleite lightweight visualization utility / Lua hacks

[Joerg P. <pu...@kr...>]

Dear all,

I'd like to draw your attention also to our visualisation tool Kara
which is a plugin of our eclipse-based IDE for ASP called SeaLion.
Kara is also greatly inspired by ASPViz - and idpdraw - the
visusalisation tool
by the group in Leuven.
We had a paper on kara at this years' WLP:
http://arxiv.org/abs/1109.4095

Amongst other features, Kara also provides  graph layouting (but with a
fixed layouting algorithm).
We also plan a command-line version for the future.

We want to have our beta release of SeaLion soon,
but if you are interested you can also already have a look at the
development version
that is available from update site
'http://mmdasp.sourceforge.net/sealion/update'
using eclipse's internal software management system.

best wishes,
Joerg

Martin wrote:
> On Sat, 2011-10-01 at 04:44 -0700, Adam Smith wrote:
>   
>> Hi All,
>>
>> I wanted to share a visualization utility I just put online and some
>> related tricks you can use with the Lua scripting interface.
>>
>> %% Visualization
>>
>> As a community, we've rolled our own visualization code several times,
>> mapping the output of Clasp into ascii-art, Graphviz, or some other
>> representation in a slightly different way for each project. Taking
>> time out to develop diagram generators distracts from the otherwise
>> high-velocity process of iterative modeling with ASP. This friction
>> makes us want to either put off visualization for later or to attempt
>> to solve the visualization problem Once And For All.
>>     
>
> I'd agree with the first sentence, not so sure about the second.
>
> <snip>
>   
>> Lonsdaleite (https://github.com/rndmcnlly/Lonsdaleite) is a 136-line
>> Python script designed to allow purely declarative access to nearly
>> all of the visualization capabilities of Graphviz. Just as in the
>> ASPViz tool, you use it by writing only AnsProlog and piping the
>> solver output into an domain-independent generator. Lonsdaleite
>> requires only a vanilla Python installation with no additional
>> libraries. It is not required to have the Graphviz binaries installed
>> on the local system -- the tool can emit a URL that uses Google's
>> chart API for final rendering, even automatically opening the URL in a
>> browser for you (to optimize away the two seconds it would have taken
>> you to copy/paste it yourself). Because Lonsdaleite is simply a
>> transparent-as-possible interface between ASP and Graphviz, users
>> familiar with Graphviz will be able to use advanced features directly,
>> without consulting references.
>>
>> Example input:
>> https://github.com/rndmcnlly/Lonsdaleite/blob/master/example.lp
>> Example command: clingo example.lp | lonsdaleite -cu
>> Example output: http://bit.ly/omhomC
>>     
>
> Cool!  Thanks for this.
>
>   
>> Because Lonsdaleite is tiny, has minimal dependencies, and does
>> exactly one thing (prepare-but-not-render Graphviz files), I've been
>> able to apply it to multiple exploratory projects without encountering
>> a lack of or burdensome overabundance of functionality. Having
>> recently discovered that you can optionally specify a "pos" node
>> attribute to control their exact location in a diagram, I've used it
>> for simple map drawing as well by calculating vertex positions in
>> logic.
>>
>> So, while I haven't solved the visualization problem once and for all
>> (actually, I hope I've convinced you that you wouldn't actually want
>> that anyway), I have solved the problem of preparing graphviz files.
>> If your current project has a big pile of binary relations (which map
>> well to edges) or you are reasoning over the layout of two-dimensional
>> objects (which maps well to precisely placed nodes), consider
>> Lonsdaleite. If your home-grown visualization scripts have nothing to
>> do with graph layout, consider sharing what it is they do. Maybe
>> someone can make a general-but-not-too-general tool for generating
>> that type of diagram.
>>     
>
> I guess it would also work with dot2tikz et al.
>
>   
>> %% Lua tricks
>>
>> Have use used Gringo's Lua integration yet? I have, and it's
>> dramatically changed the way I go about answer set programming. Have
>> another look at that example.lp file
>> (https://github.com/rndmcnlly/Lonsdaleite/blob/master/example.lp) for
>> a good example of where it's really convenient to sprinkle an
>> imperative, interpreted function into the mix of otherwise purely
>> uninterpreted functions of ASP. The ability to build new, raw
>> identifiers is what allows Lonsdaleite's modeling interface (api?) to
>> be so simple and comprehensive. Using Lua, you can actually construct
>> identifiers that would never parse (due to embedded punctuation or
>> other forbidden symbols). This doesn't help your logical reasoning at
>> all, but it can make a big difference in simplifying the systems that
>> consume your answer sets in a larger application.
>>
>> Lua can expand your reasoning/modeling abilities as well. You know how
>> in practically every logic programming language, the construction F(A)
>> is forbidden? (That is, the functor of a term can't be a variable, it
>> needs to be a symbolic atom.) There are times, for modeling purposes,
>> where you really want to either build or constrain terms by their
>> functor (one was previously mentioned on this list), but there's no
>> way in stock-Gringo code to express the idea that you want to quantify
>> over functors. If you were in traditional Prolog, you'd be using the
>> =.. (univ) operator to deconstruct a term and perhaps use call/1 to
>> check the property you desired. Surely there is no univ-like operator
>> for ASP...
>>
>> #begin_lua
>>   function make(f,...)
>>     arg.n = nil
>>     return Val.new(Val.FUNC,tostring(f),arg)
>>   end
>> #end_lua.
>>
>> a(99).
>> f(odd).
>> p(@make(F,A)) :- f(F), a(A). % grounds to p(odd(99)).
>>
>> Ok, it was always possible to express the same idea by invention a
>> helper function to bundle the two arguments together (e.g.
>> bundle(odd,99)). However this requires the introduction of a nuisance
>> identifier throughout your program and refactoring every time you find
>> a new term whose head you want to constrain. With an interpreted
>> function like "make" in you library, you can opportunistically
>> constrain head wherever you like without even thinking about the
>> refactoring it would have required.
>>
>> Want some more? (format: {function expression} --> {what it grounds
>> to}) None of these are supported by default, but each can be
>> implemented in just a few lines of Lua.
>>
>> @forge(eth,"_",1) --> eth1
>> @get_arg(f(a,b,c),2) --> b
>> @replace_arg(f(a,b,c),2,z) --> f(a,z,b)
>> @apply(get_arg,f(a,b,c),2) --> b -- higher-order functions!
>> @map(max,list(1,2,3),list(3,2,1)) --> f(3,2,1) -- operations on
>> collections!
>> @make_array(f,3,0) --> f(0,0,0)
>> id(a,@assign_id(a)), id(b(z),@assign_id(b)). --> id(a,1), id(b,2). --
>> heterogeneous counting
>> @roll(1,6,die(1))+@roll(1,6,die(2)) --> 9 -- repeatable ground-time
>> randomization (to model dice that don't cooperate with the player)
>>     
>
> It's possibly worth me mentioning that Riposte uses nested functions to
> refer to expression trees (making the unique addressing of the
> expression 'x+a*7' trivial as it's name is the expression).  I guess
> with this we could probably compact some of the code.
>
>   
>> You can read this as "abusing the grounder for scientific
>> computation" (and yes, you can roll some pretty interesting
>> ground-time modeling checking software with these), but this is really
>> all about accelerating incremental, exploratory modeling (particularly
>> you trying to reason over inductively-constructed spaces). When you
>> are just getting the idea for something, you want to try it out right
>> away by editing your one AnsProlog file. Taking time out to develop
>> instance builders, instance expanders, table generators, syntactic
>> transformers, etc. drags on you (at least in my estimation) right
>> where ASP has the biggest potential for impact: rapid prototyping. The
>> more you can do in a single page of a single file, the better.
>>
>> Once I've tried them in the context of other projects, I'll likely
>> release my collections datastructures and higher-order functions
>> libraries as open source as well. (Can anyone suggest a good
>> publication venue for the specifically software engineering and/or
>> applications side of ASP?)
>>     
>
> ICLP and LPNMR are the likely conference choices and have published this
> kind of thing before.  In the past the SEA and ASP workshops would have
> been good but I don't know if they will be running again.  ASPOCP is a
> bit more theoretically focused.  (As PC members / organisers for these
> may well be present, please do correct me if I am wrong).
>
>   
>> I'm interested in all of the things people usually build Around their
>> answer set programs. I feel like I'm inventing a lot of stuff for
>> myself that must be being reinvented all of the time due to lack of
>> coverage in the literature. What do you folks think of this?
>>     
>
> I don't think it is lack of coverage.  I've seen several such systems
> proposed.  Unfortunately they all tend to be slanted towards one way of
> using the tools, one kind of application or one approach, thus their
> developers tend to feel they are the whole solution but they don't get
> much adoption as they don't fit other people's way of working.  In my
> case the 'common' bits of code I copy between projects is just a parser
> for solver output; everything after that is custom.  That said, I'm
> always interested in these kind of tools, so, go for it :-)
>
> Cheers,
>  - Martin
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Potassco-users mailing list
> Pot...@li...
> https://lists.sourceforge.net/lists/listinfo/potassco-users
>
>   


-- 
Joerg Puehrer
Institute of Information Systems, Vienna University of Technology
Favoritenstrasse 9-11/1843, A-1040 Vienna, Austria
T: +43 (1) 58801-18466   E: puehrer AT kr DOT tuwien DOT ac DOT at
http://www.kr.tuwien.ac.at/staff/puehrer/

TU-Wien, DVR-Nummer 0005886