Ken | 4 Feb 20:07 2011
Picon

Questions about hacking scaladoc...

I'm looking at adding a feature to ScalaDoc. I've been in touch with
Gilles Dubochet and have read the http://lampsvn.epfl.ch/trac/scala/wiki/Scaladoc/Contribute
page.

Question 1: The file compiler/scala/tools/nsc/ScalaDoc.scala would
seem to be an appropriate entry point for understanding ScalaDoc--I
just want to check that this is correct.

Question 2: What is the best way to generate or access the source code
docs for scaladoc itself? I checked out 2.8.1 and did a build, but
that did not seem to generate scaladoc, and in any case I would expect
that a standard doc build would generate documentation for the main
distribution, not the internals.

Question 3: Looking for any pointers on understanding/hacking Scaladoc
that aren't linked to by the Contribute page that you think might be
useful.

Thanks!
Ken

Ken | 4 Feb 20:40 2011
Picon

Looking for feedback on feature I'd like to add to Scaladoc

Hi All,

I'm looking at the possibility of adding discrete graphs to Scaladoc
pages, similar to d'Oxygen. I'd like to solicit people's opinions on
how best to do this. I present the list below as a non-exhaustive and
overlapping set of possibilities.

1) Use the graphviz package. It's very well-supported, unlikely to go
away, and is in some ways a de facto standard for this sort of thing.
Also, from what little I know, input into the graphviz tools is pretty
simple (at least for simple things) so there wouldn't be a huge
learning curve. The biggest downside is that scaladoc users would have
to install it separately, which can be a challenge at times.

2) Use an existing Java library (Prefuse seems like a good candidate)
and embed a Java applet in the doc pages. This is very flexible,
allows the implementation to be done entirely in Scala/Java, and may
have some other nice properties. I've never done web page applets
before, so don't know enough to comment more than this--please feel
free to provide feedback.

3) Draw the graphs using SVG. This has the advantages of providing the
viewing solution entirely in the browser, and of possibly not
requiring external tools such as graphviz. (My understanding is that
Prefuse provides some type of SVG output, but I'm not sure how
powerful that is--comments on this are welcome.) What little I know of
SVG also suggests this would give a lot of flexibility in the "look"
of the output. The biggest disadvantage is that browsers may provide
incomplete or poor support for SVG--I believe that IE was very much
behind on this, but am not sure of the current state of its support as
(Continue reading)

David Bernard | 4 Feb 20:58 2011
Picon

Re: Looking for feedback on feature I'd like to add to Scaladoc

Hi,


In the vscaladoc2's Todo list, there is similar feature.
The idea is to made this type of display at render time (by a skin or by the webserver) (see below)
I bookmark to try to implement the same features in javascript with :


( FYI

VScaladoc2 split doc generation in 2 steps :
* api generation in json done by vscaladoc2_genjson
* display of api done by vscaladoc2_www + laf plugin, so display can be enhanced without requiement to regenerate API

Contribution are welcomes 
online displayer : http://vscaladoc.alchim31.net/
)

cheers,

/davidB

On Fri, Feb 4, 2011 at 20:40, Ken <ykkenmcd <at> gmail.com> wrote:
Hi All,

I'm looking at the possibility of adding discrete graphs to Scaladoc
pages, similar to d'Oxygen. I'd like to solicit people's opinions on
how best to do this. I present the list below as a non-exhaustive and
overlapping set of possibilities.


1) Use the graphviz package. It's very well-supported, unlikely to go
away, and is in some ways a de facto standard for this sort of thing.
Also, from what little I know, input into the graphviz tools is pretty
simple (at least for simple things) so there wouldn't be a huge
learning curve. The biggest downside is that scaladoc users would have
to install it separately, which can be a challenge at times.

2) Use an existing Java library (Prefuse seems like a good candidate)
and embed a Java applet in the doc pages. This is very flexible,
allows the implementation to be done entirely in Scala/Java, and may
have some other nice properties. I've never done web page applets
before, so don't know enough to comment more than this--please feel
free to provide feedback.

3) Draw the graphs using SVG. This has the advantages of providing the
viewing solution entirely in the browser, and of possibly not
requiring external tools such as graphviz. (My understanding is that
Prefuse provides some type of SVG output, but I'm not sure how
powerful that is--comments on this are welcome.) What little I know of
SVG also suggests this would give a lot of flexibility in the "look"
of the output. The biggest disadvantage is that browsers may provide
incomplete or poor support for SVG--I believe that IE was very much
behind on this, but am not sure of the current state of its support as
it has been years since I've used a Windows system.

4) Implement a viewer in JavaScript. The big advantage here is
flexibility and power. The big disadvantage (and it's very big) is
that I'm a lot less likely to actually implement a discrete graph
feature in Scaladoc if too much JS coding is involved.


At the moment I'm leaning (not by much) towards a "first cut" solution
that would:


1) Define a minimal API to wrap an underlying graph layout tool, with
the hope that doing so would make it easier to later swap to a
different tool if desired.

2) Use graphviz as the underlying tool; it can generate both PNG and
SVG output (including PNG image maps), so output could be used in
browsers that don't support SVG.

3) Focus on SVG as the "primary" output and PNG as "secondary". This
would allow for nice-looking graphs (hey, that's important :-) ), and
would set the stage for potential manipulation of the SVG DOM via
JavaScript if anyone every wants to do so in the future.

But this is still very much in the planning stages.


Thanks for your feedback,
Ken

John Nestor | 4 Feb 22:44 2011
Picon

Re: Map Extractors

Thanks for pointing out unapplySeq.
So now I can write just

map(a,b)

but I still really want to write something much more like

("bar"->a,"foo"->b)

On Feb 3, 12:04 pm, Daniel Sobral <dcsob... <at> gmail.com> wrote:
> What about unapplySeq?
>
>
>
>
>
> On Thu, Feb 3, 2011 at 16:56, John Nestor <nestorpers... <at> gmail.com> wrote:
> > I am new to Scala and trying to figure out how to use extractors for
> > pattern matching of maps (my actual use case is somewhat more complex
> > and involves matching Json objects from Jackson).
>
> > So consider the following code
>
> >  object MAP {
> >        def apply(ss:String*) = new MAP(ss:_*);
> >    }
> >    class MAP(ss:String*) {
> >        def unapply(m:Map[String,String]): Option[(Seq[String])] = {
> >                var gf = (s:String)=>m(s)
> >                var v:Seq[String] =ss map gf
> >                Some(v)
> >        }
> >    }
>
> >    def testmap = {
> >        val m = Map("foo"->"3","bar"->"7","zzz"->"123")
> >        val map = MAP("bar","foo")
> >        m match {
> >            case map(Seq(a,b)) => println(a+":"+b)
> >            case _ => println("other")
> >        }
> >    }
>
> > Running testmap outputs 7:3 My problem is with the following pattern
>
> > map(Seq(a,b))
>
> > The following alternatives represent successively better ways of
> > writing this line (if there is some way to get them to work)
>
> > map(a,b)
> > MAP("bar","foo")(a,b)
> > ("bar"->a,"foo"->b)
>
> > Can I get closer to that ideal last form?
>
> > Also this seems like a really useful case, so perhaps an extension to
> > patterns in a future version of the language might make sense.
>
> > Any help or ideas would be appreciated.
>
> > Thanks,
> > John
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

Erik Post | 4 Feb 23:22 2011
Picon

Re: Looking for feedback on feature I'd like to add to Scaladoc

Hi Ken,

On Feb 4, 8:40 pm, Ken <ykken... <at> gmail.com> wrote:
> I'm looking at the possibility of adding discrete graphs to Scaladoc
> pages, similar to d'Oxygen. I'd like to solicit people's opinions on
> how best to do this. I present the list below as a non-exhaustive and
> overlapping set of possibilities.
>
> 1) Use the graphviz package. It's very well-supported, unlikely to go
> away, and is in some ways a de facto standard for this sort of thing.
> Also, from what little I know, input into the graphviz tools is pretty
> simple (at least for simple things) so there wouldn't be a huge
> learning curve. The biggest downside is that scaladoc users would have
> to install it separately, which can be a challenge at times.

On the upside, the _viewers_ of the documentation wouldn't need to.

> 2) Use an existing Java library (Prefuse seems like a good candidate)
> and embed a Java applet in the doc pages. This is very flexible,
> allows the implementation to be done entirely in Scala/Java, and may
> have some other nice properties. I've never done web page applets
> before, so don't know enough to comment more than this--please feel
> free to provide feedback.

I've played with Prefuse a couple of years ago, and it's quite cool,
but I think it's pretty much dead in the water. The last news update
on the site is from January 2009. On top of that, the thought of Java
applets in my ScalaDoc pages makes me want to cry. Have you looked at
ProtoVis? It's Javascript, generates SVG and is being developed by
some of the folks behind Prefuse.

> 3) Draw the graphs using SVG. This has the advantages of providing the
> viewing solution entirely in the browser, and of possibly not
> requiring external tools such as graphviz.

I've been working with ProtoVis (using Chrome and Firefox) and I have
to say I'm quite taken with it. You can marvel at some nice examples
with code on their website. [1] Incidentally, I've been reading here
and there about how IE 9 will supposedly be implementing SVG properly
[2], so that's good news, one supposes.

Cheers,
Erik

[1] http://vis.stanford.edu/protovis/ex
[2] http://msdn.microsoft.com/en-us/ie/ff468705#_Scaling_Vector_Graphics

Stefan Zeiger | 4 Feb 23:22 2011

Re: Looking for feedback on feature I'd like to add to Scaladoc

On 2011-02-04 20:40, Ken wrote:
> 4) Implement a viewer in JavaScript. The big advantage here is
> flexibility and power. The big disadvantage (and it's very big) is
> that I'm a lot less likely to actually implement a discrete graph
> feature in Scaladoc if too much JS coding is involved.

5) Use an existing viewer in JavaScript. For the class diagrams in 
Extradoc (e.g. expand the diagram section here 
http://novocode.com/tmp/extradoc/#t=scala.collection.SeqLike for a demo) 
I'm using InfoVis: http://thejit.org/. Maybe it's powerful enough for 
your purpose. I was unable to find a more graphviz-like tool with good 
layout algorithms in JavaScript.

-sz

Daniel Sobral | 5 Feb 04:20 2011
Picon

Re: Re: Map Extractors

On Fri, Feb 4, 2011 at 19:44, John Nestor <nestorpersist <at> gmail.com> wrote:
Thanks for pointing out unapplySeq.
So now I can write just

map(a,b)

but I still really want to write something much more like

("bar"->a,"foo"->b)

You can do it, within limitations. First, understand that you cannot pass parameters to an extractor, so it cannot return the value for "bar" in a, return the value for "foo" in b. Scala pattern matching is not Prolog. If you want to get "bar" and "foo" in a and b, the way to do it is:

(map.get("bar"), map.get("foo")) match {
    case (Some(a), Some(b)) => ...
    case _ => // something else
}

But let's say you'll return all elements of the map in alphabetical order. Then you can do this:

object -> {
    def unapply[A, B](t: (A, B)) = Some(t)
}

object MAP {
  def unapplySeq(m:Map[String,String]): Option[Seq[(String, String)]] = {
    Some(m.toSeq.sorted)
  }
}

scala> m match {
     |     case MAP("bar" -> a, "foo" -> b, "zzz" -> c) => println("%s %s" format (a,b))
     |     case other => println(other)
     | }
7 3

If you ommit "zzz", it won't match.

 

On Feb 3, 12:04 pm, Daniel Sobral <dcsob... <at> gmail.com> wrote:
> What about unapplySeq?
>
>
>
>
>
> On Thu, Feb 3, 2011 at 16:56, John Nestor <nestorpers... <at> gmail.com> wrote:
> > I am new to Scala and trying to figure out how to use extractors for
> > pattern matching of maps (my actual use case is somewhat more complex
> > and involves matching Json objects from Jackson).
>
> > So consider the following code
>
> >  object MAP {
> >        def apply(ss:String*) = new MAP(ss:_*);
> >    }
> >    class MAP(ss:String*) {
> >        def unapply(m:Map[String,String]): Option[(Seq[String])] = {
> >                var gf = (s:String)=>m(s)
> >                var v:Seq[String] =ss map gf
> >                Some(v)
> >        }
> >    }
>
> >    def testmap = {
> >        val m = Map("foo"->"3","bar"->"7","zzz"->"123")
> >        val map = MAP("bar","foo")
> >        m match {
> >            case map(Seq(a,b)) => println(a+":"+b)
> >            case _ => println("other")
> >        }
> >    }
>
> > Running testmap outputs 7:3 My problem is with the following pattern
>
> > map(Seq(a,b))
>
> > The following alternatives represent successively better ways of
> > writing this line (if there is some way to get them to work)
>
> > map(a,b)
> > MAP("bar","foo")(a,b)
> > ("bar"->a,"foo"->b)
>
> > Can I get closer to that ideal last form?
>
> > Also this seems like a really useful case, so perhaps an extension to
> > patterns in a future version of the language might make sense.
>
> > Any help or ideas would be appreciated.
>
> > Thanks,
> > John
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.



--
Daniel C. Sobral

I travel to the future all the time.
Olivier Pernet | 5 Feb 11:48 2011
Picon
Picon

Compiler plugins: storing extra data in class files

Hi everyone,

I'm working on a compiler plugin which add another typechecking layer
to Scala (session types).
I would like the plugin to work even with separately compiled files,
so that libraries can use session typed operations too.

Do you know of any other plugin that does this? (Maybe the
continuations plugin?)
How hard could it be to store and retrieve data in attributes
(http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#43817)?
I think the Scala compiler itself does this already.

By the way, does anyone know of a good class file viewer that would
display attributes (along with bytecode, etc)?

Cheers,

Olivier

Johannes Rudolph | 5 Feb 13:54 2011

Re: Compiler plugins: storing extra data in class files

On Sat, Feb 5, 2011 at 11:48 AM, Olivier Pernet <omp08 <at> doc.ic.ac.uk> wrote:
> By the way, does anyone know of a good class file viewer that would
> display attributes (along with bytecode, etc)?

I just found http://www.codeproject.com/KB/java/javaclassviewer.aspx
which seems quite interesting. IIRC one of the popular profilers had
quite a good class file viewer as well.

Aside from that, javap works good enough if you like command line
interfaces. Source code is available so you could extend it for your
needs anyways.

--

-- 
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Olivier Pernet | 5 Feb 18:31 2011
Picon
Picon

Re: Compiler plugins: storing extra data in class files

On Sat, Feb 5, 2011 at 12:54, Johannes Rudolph
<johannes.rudolph <at> googlemail.com> wrote:
> On Sat, Feb 5, 2011 at 11:48 AM, Olivier Pernet <omp08 <at> doc.ic.ac.uk> wrote:
>> By the way, does anyone know of a good class file viewer that would
>> display attributes (along with bytecode, etc)?
>
> I just found http://www.codeproject.com/KB/java/javaclassviewer.aspx
> which seems quite interesting.

Thanks, this one looks just like what I wanted.

Are you working on something related yourself?

Olivier


Gmane