Fwd: [ANN] The Go Oracle: a source code comprehension tool for Go programs

Showing 1-36 of 36 messages
Fwd: [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/10/13 12:16 PM
I'm pleased to announce the Go Oracle, a new tool built atop the static analysis libraries under construction in the go.tools repository (https://code.google.com/p/go/source/browse?repo=tools).

The oracle is designed to answer, quickly and precisely, a range of questions about your Go program, such as "where can this dynamic call dispatch to?" or "who sends values on this channel?".

The tool is still in a rough state, but already useful if you're the "early adopter" type.  (I use it all the time.)  The tool has only been tested on linux-amd64 and so far the only editor with which it is integrated is Emacs.  It requires a recent (=tip) version of the GOROOT libraries.

At this stage, the kind of feedback we're most interested in hearing is about the general shape of the tool: its external interfaces and how it should integrate with editors, IDEs and other tools and scripts.  All its interfaces are subject to change---now is your chance to influence that.  Reports of serious bugs are welcome too; send them directly to me.

User manual

Design document

cheers
alan

Re: [go-nuts] Fwd: [ANN] The Go Oracle: a source code comprehension tool for Go programs Kocka 9/10/13 12:20 PM
I think I wanted to find a tool like this last week :D. I have to check it out.

Thanks in advance!


2013/9/10 Alan Donovan <adon...@google.com>

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Name : Kosztka Imre Dávid
E-mail: kosz...@gmail.com
Phone number: +36309213462
Mailing address: H-3700, Hungary Kazincbarcika Szeder utca 2.
Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/10/13 12:21 PM
Re: [go-nuts] Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs atomly 9/10/13 12:25 PM
These were worst than the first.  Before sharing, make sure you give everybody read permission.

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs Kevin P 9/10/13 12:30 PM
Can't access the docs need permission.
Re: [go-nuts] Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/10/13 12:30 PM
On 10 September 2013 15:25, atomly <ato...@gmail.com> wrote:
These were worst than the first.  Before sharing, make sure you give everybody read permission.

Believe me, I tried.

I'll go have a word with the Docs team.  In the meantime, enjoy these PDFs.

*sigh*
Re: [go-nuts] Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs omarsharif...@gmail.com 9/10/13 2:16 PM
This looks awesome! Can't wait to try it out
Re: [go-nuts] Re: [ANN] The Go Oracle: a source code comprehension tool for Go programs Jonathan Pittman 9/10/13 3:30 PM
FWIW, I can open the original links from my personal gmail account by simply clicking "Proceed to open document."  At the top it only says  "Visits to this document are recorded by Google.com" and does not indicate that I do not have access.  The links posted in the followup email, however, are not accessible at all.

And for the PDFs, you attached both the manual and the design doc in your first posting of the PDFs.  I opened them just fine.  Then you posted the design doc twice in the 2nd posting of the PDFs and followed it up with a single posting of the manual.

Awesome tool.  Confusing thread.

Thanks!


On Tue, Sep 10, 2013 at 5:16 PM, <omarsharif...@gmail.com> wrote:
This looks awesome! Can't wait to try it out

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/10/13 8:44 PM
[this time with working links]

I'm pleased to announce the Go Oracle, a new tool built atop the static analysis libraries under construction in the go.tools repository (https://code.google.com/p/go/source/browse?repo=tools).

The oracle is designed to answer, quickly and precisely, a range of questions about your Go program, such as "where can this dynamic call dispatch to?" or "who sends values on this channel?".

The tool is still in a rough state, but already useful if you're the "early adopter" type.  (I use it all the time.)  The tool has only been tested on linux-amd64 and so far the only editor with which it is integrated is Emacs.  It requires a recent (=tip) version of the GOROOT libraries.

At this stage, the kind of feedback we're most interested in hearing is about the general shape of the tool: its external interfaces and how it should integrate with editors, IDEs and other tools and scripts.  All its interfaces are subject to change---now is your chance to influence that.  Reports of serious bugs are welcome too; send them directly to me.

User manual

Design document

cheers
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/10/13 11:01 PM
While reading through the design document I saw a pony. I'm not sure if
it's feasible or necessarily wanted, but thought I'd share.

When refactoring, finding equivalent structures in the code is sometimes
helpful (go fix e.g.). How easy would it be to include the capacity to
find AST subtree matches (structure and type only) to a selection in the
rest of the project?

Dan

Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs Daniel Morsing 9/11/13 5:29 AM
This is great. Did a bit of playing with it and took note of a couple of things:

- Vast majority of unsafe pointer conversion warnings happen in
"syscall". I'd be ok just whitelisting that package.
- Byte offset is a bit tricky to work around in acme. Using byte
offsets also makes it possible to specify a range that's inside a
UTF-8 sequence, but the tool seems to handle that fine. I don't know
how convenient switching to rune offsets would be, but I'd prefer
that.
- implements mode seems to be broken when called from the command
line. It needs a position, but when I give it a dummy one, it notifies
me that it cannot find it, even if the position exists.
- freevars reports each assignment to field selector. You could clean
up the output by just reporting the value.

Regards,
Daniel Morsing
Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/11/13 7:45 AM
On 11 September 2013 08:29, Daniel Morsing <daniel....@gmail.com> wrote:
On Wed, Sep 11, 2013 at 5:44 AM, Alan Donovan <adon...@google.com> wrote:
> [this time with working links]
>
> I'm pleased to announce the Go Oracle, a new tool built atop the static
> analysis libraries under construction in the go.tools repository
> (https://code.google.com/p/go/source/browse?repo=tools).
>
> The oracle is designed to answer, quickly and precisely, a range of
> questions about your Go program, such as "where can this dynamic call
> dispatch to?" or "who sends values on this channel?".
>
> The tool is still in a rough state, but already useful if you're the "early
> adopter" type.  (I use it all the time.)  The tool has only been tested on
> linux-amd64 and so far the only editor with which it is integrated is Emacs.
> It requires a recent (=tip) version of the GOROOT libraries.
>
> At this stage, the kind of feedback we're most interested in hearing is
> about the general shape of the tool: its external interfaces and how it
> should integrate with editors, IDEs and other tools and scripts.  All its
> interfaces are subject to change---now is your chance to influence that.
> Reports of serious bugs are welcome too; send them directly to me.
>
> User manual
> https://docs.google.com/a/golang.org/document/d/1SLk36YRjjMgKqe490mSRzOPYEDe0Y_WQNRv-EiFYUyw/edit
>
> Design document
> https://docs.google.com/a/golang.org/document/d/1WmMHBUjQiuy15JfEnT8YBROQmEv-7K6bV-Y_K53oi5Y/edit#
>
> cheers
>

This is great. Did a bit of playing with it and took note of a couple of things:

Thanks for the feedback.
 

- Vast majority of unsafe pointer conversion warnings happen in
"syscall". I'd be ok just whitelisting that package.


 
- Byte offset is a bit tricky to work around in acme. Using byte
offsets also makes it possible to specify a range that's inside a
UTF-8 sequence, but the tool seems to handle that fine. I don't know
how convenient switching to rune offsets would be, but I'd prefer
that.

We could easily add that as an option.

Rob Pike had a 5-minute hack for oracle+acme.  Though I haven't seen his code, he didn't mention the issue as a problem, so perhaps Acme does provide hooks to access byte offsets?

 
- implements mode seems to be broken when called from the command
line. It needs a position, but when I give it a dummy one, it notifies
me that it cannot find it, even if the position exists.

Thanks; this was a regression I introduced yesterday.

 
- freevars reports each assignment to field selector. You could clean
up the output by just reporting the value.

Actually I went to extra trouble to implement the documented behaviour. :)
The motivation was that if some code references only x.y.a and x.y.b, you wouldn't extract it into a function that takes x as a parameter; you'd just pass x.y.a and x.y.b, or perhaps their common ancestor x.y.  If this is a nuisance we could disable it or make it an option.

I just sent a fix for another bug in freevars: it wasn't suppressing the printing of free identifiers defined in package scope, only those from file scope. https://codereview.appspot.com/13256050

cheers
alan

Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs Daniel Morsing 9/11/13 8:23 AM
I've already done my own little acme hack. Turns out to be not that
big of a problem.

>
>>
>> - implements mode seems to be broken when called from the command
>> line. It needs a position, but when I give it a dummy one, it notifies
>> me that it cannot find it, even if the position exists.
>
>
> Thanks; this was a regression I introduced yesterday.
> Fix pending in https://codereview.appspot.com/13334050
>
>
>>
>> - freevars reports each assignment to field selector. You could clean
>> up the output by just reporting the value.
>
>
> Actually I went to extra trouble to implement the documented behaviour. :)
> The motivation was that if some code references only x.y.a and x.y.b, you
> wouldn't extract it into a function that takes x as a parameter; you'd just
> pass x.y.a and x.y.b, or perhaps their common ancestor x.y.  If this is a
> nuisance we could disable it or make it an option.
>

You're right. The example I used to test this tool was an
initialization procedure where I wrote to several fields on a single
value. In that case it makes sense to hide field accesses, but not so
much in all the others.

After playing with it some more, I think an option that supresses line
numbers for freevars would be useful. Then I could just do a copy of
all the variables to the function that I'm hoisting the statements
into.
Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs rog 9/11/13 8:45 AM
On 11 September 2013 15:45, Alan Donovan <adon...@google.com> wrote:
> On 11 September 2013 08:29, Daniel Morsing <daniel....@gmail.com> wrote:
>> - Byte offset is a bit tricky to work around in acme. Using byte
>> offsets also makes it possible to specify a range that's inside a
>> UTF-8 sequence, but the tool seems to handle that fine. I don't know
>> how convenient switching to rune offsets would be, but I'd prefer
>> that.
>
>
> We could easily add that as an option.
>
> Rob Pike had a 5-minute hack for oracle+acme.  Though I haven't seen his
> code, he didn't mention the issue as a problem, so perhaps Acme does provide
> hooks to access byte offsets?

It doesn't, but it's easy enough to work around. I also have a 5
minute hack for oracle+acme.

It looks like this:
#!/usr/local/plan9/bin/rc
addr=`{acmedot}
oracle -pos $addr $*

where acmedot prints out the address of the current window.
(http://play.golang.org/p/-KSoTt2Q2_- mostly stolen from godef)

I have also had a little play with oracle. It worked pretty well,
although it took a long time to run.

I'm really looking forward to being able to throw away godef at some
point in the future
and replace it with oracle. Things that should help make this possible:

- the ability to take some code from the editor's buffer rather than from disk.
Currently if the file on disk is different from the editor's version, the
byte offset is probably bogus. In godef I solved this by allowing
the current file to be read from stdin, but I wonder if a package
API to oracle could access all files through some kind of filesystem interface,
so a given editor could define an interface that made currently in-buffer
files available to oracle.

- "best effort" mode. It should be possible to find some information
on a program
even if it doesn't fully type check.

-  the ability to find the definition of a symbol even without setting a scope;
the scope is only needed for more sophisticated analysis. This means it
should Perhaps
it might be worth having another mode, "define", which does only the
limited analysis necessary for finding a symbol definition.

- much faster operation - I've seen it take between 5s and 30s to run.
Godef took about 10ms on the same thing (admittedly with much smaller
scope)

- the ability to specify a symbol other than by file offset - for instance, if I
want to find the definition of a function or variable without first finding a
mention of that identifier in the source code, it would be nice to be able
to name it on the oracle command line.

I'll try to file specific issues around the actual oracle output as
they turn up.

This is a marvellous tool - thanks so much for working on it!
Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs freder...@gmail.com 9/15/13 1:15 PM
On Wednesday, September 11, 2013 4:45:48 PM UTC+2, Alan Donovan wrote:
On 11 September 2013 08:29, Daniel Morsing <daniel....@gmail.com> wrote:
- Byte offset is a bit tricky to work around in acme. Using byte
offsets also makes it possible to specify a range that's inside a
UTF-8 sequence, but the tool seems to handle that fine. I don't know
how convenient switching to rune offsets would be, but I'd prefer
that.

We could easily add that as an option.

I wrote a little web front-end for the oracle:


Unfortunately, the browser provides only rune offsets for selection ranges, no byte offsets. Adding rune offsets as an option would help me.
Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/15/13 1:53 PM
Awesome!  I have a few UI suggestions:

1. Have the pane of results persist even as you click on lines in it.  (Currently it disappears when you jump to another file.)

2. Highlight the line when you click on a results line (and the de-highight when you do another action).

3. Only show the menu options appropriate for the selected location.  (A little tricky; the ideal implementation requires me to break up the API into smaller chunks.)  e.g. "peers" would be greyed out unless you select a <- token, and freevars would only appear when the selection is nonempty (not on each click).

4. Specialize the call{ers,ees,graph} queries into the UI: fetch the complete callgraph at startup and cache it.  Use it to mark up the source so that all function declarations have a little "jump to caller(s)" button in the margin that performs the "callers" query (from the cached callgraph), and all call sites have a hyperlink on the '(' token that performs a "callees" query (also from the cache).  If the result is unique, go straight there without showing the results pane.

5. Move the "implements" and "callgraph" query buttons to the top of the screen (since they don't need a source selection).

How much time do you want to put into this project going forward?  I would love to develop this approach (perhaps integrated into godoc, not sure) but my powers of GUI are weak.

This is a really nice demo, and I'm impressed by how quickly you put it together.

cheers
alan

Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs freder...@gmail.com 9/15/13 3:05 PM
On Sunday, September 15, 2013 10:53:47 PM UTC+2, Alan Donovan wrote:
Awesome!  I have a few UI suggestions

Thanks for the positive feedback. All your suggestions make perfect sense and I have added them to the project's issue list.
 
How much time do you want to put into this project going forward?  I would love to develop this approach (perhaps integrated into godoc, not sure) but my powers of GUI are weak.

I can surely spend a couple of hours a week on it.
 
This is a really nice demo, and I'm impressed by how quickly you put it together. 

Go and your oracle API made it really simple.
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Liigo Zhuang 9/15/13 4:32 PM

The go oracle is a bad name , because there is a famous database named this ,

在 2013年9月11日 上午11:44,"Alan Donovan" <adon...@google.com>写道:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/15/13 4:35 PM
On Mon, 2013-09-16 at 07:32 +0800, Liigo Zhuang wrote:
> The go oracle is a bad name , because there is a famous database named
> this

You do understand the basis for the naming?

http://en.wikipedia.org/wiki/Oracle

It is an excellent name.

Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs andrey mirtchovski 9/15/13 5:20 PM
> http://en.wikipedia.org/wiki/Oracle
>
> It is an excellent name.

i thought you were going to link to this one:

http://en.wikipedia.org/wiki/Oracle_v._Google

those googlers sure are cheeky :)
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/15/13 6:12 PM
Amazing though it may seem, not everything is related to either
computers (I know, I know, CRAZY!) or google, as you can see from the
disambiguation page (which gives further lie to the notion that oracle
is somehow specially related to the the previously mentioned database
implementation):

http://en.wikipedia.org/wiki/Oracle_%28disambiguation%29
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Rob 'Commander' Pike 9/15/13 6:21 PM
This is the Oracle of Donovan, not the Oracle of Ellison or the Oracle
of Delphi.

-rob
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/15/13 6:28 PM
Indeed, possibly more fallible than the Delphic Oracle, but certainly
less than the Oracle of Ellison.

Dan

Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Andrew Gerrand 9/15/13 7:10 PM

On 16 September 2013 10:20, andrey mirtchovski <mirtc...@gmail.com> wrote:
those googlers sure are cheeky :)

To be honest, I've known about this project of Alan's for months and the coincidence never occurred to me!
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs andrey mirtchovski 9/15/13 7:25 PM
> To be honest, I've known about this project of Alan's for months and the
> coincidence never occurred to me!

i was only joking, not really suggesting the existence of an insidious
naming scheme. for myself i'm just happy to have 'oracle' be something
closer to its true meaning in my programming life (like that web
frontend!) than just another database :)
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Liigo Zhuang 9/15/13 7:43 PM



2013/9/16 Dan Kortschak <dan.ko...@adelaide.edu.au>
On Mon, 2013-09-16 at 07:32 +0800, Liigo Zhuang wrote:
> The go oracle is a bad name , because there is a famous database named
> this

You do understand the basis for the naming?

http://en.wikipedia.org/wiki/Oracle

It is an excellent name.


Oracle is a good name, but "Go Oracle" not. All developers (gophers) know Oracle is a famous database, they maybe always think "go oracle" is a database tool at first glance. Ambiguity is no that good, should be avoid consciously. ("Rob Pike" is an excellent name too, can you name it as a pkg name?)

http://en.wikipedia.org/wiki/Oracle_(disambiguation)

--
by Liigo, http://blog.csdn.net/liigo/
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Sébastien Douche 9/16/13 8:55 AM
On Mon, Sep 16, 2013 at 4:10 AM, Andrew Gerrand <a...@golang.org> wrote:
> To be honest, I've known about this project of Alan's for months and the
> coincidence never occurred to me!

At first sight, I thought it was a database tool.


--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/16/13 2:29 PM
[-golang-dev]

On 11 September 2013 02:01, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:
When refactoring, finding equivalent structures in the code is sometimes
helpful (go fix e.g.). How easy would it be to include the capacity to
find AST subtree matches (structure and type only) to a selection in the
rest of the project?

That's an interesting question, and I don't know if it's a solved
problem yet.  We're working on refactorings with a research group at
Auburn University; I've passed on this suggestion on to them.

cheers
alan

Re: [golang-dev] [ANN] The Go Oracle: a source code comprehension tool for Go programs Alan Donovan 9/16/13 2:51 PM
[-golang-dev]

Hi Rog, nice to hear from you---and sorry it took so long to get to this point contra my vague promises.

Answering your points in order:

- Would you be prepared to polish up and commit your Acme scripts?  
  There must be at least two other Acme users out there ;-) who would like to use it.

- Running times:  30s?  How big a codebase did you run it on?
  If the code is open-source, please share a link so I can reproduce it.
  (BTW I'm not surprised godef is much faster!)

- Edited code: yes, the current behaviour can be frustrating (particularly if your editor is configured to gofmt-on-save, which messes up the positions).  The code that does the file I/O is relatively decoupled but I think there would be quite a few details to work out to get this to work.  Let me have a think about it.

- "Best effort" mode: I would like to support this.  It requires a fault-tolerant parser that replaces malformed statements by a call to panic(), for example.  It may require similar changes to the type-checker too, to replace ill-typed statements by panics, and improved error reporting to indicate whether the damage was reparable.  (It's unlikely that the SSA construction and pointer analysis could be made safe to attempt on programs that are ill-typed even after repair.)

- A "low configuration" mode.  Yes, for queries that need only typed ASTs (freevars, implements, much of describe) it would be good to make it more robust when you have no scope set (or when you stray out of scope).  Even the callgraph-related queries could be approximated by a type-based callgraph without needing a scope.

- Specifying symbols by name: yes, a number of queries (implements, parts of describe, callers/callees) would benefit from a more flexible way of forming queries.

These are all great suggestions---keep 'em coming.

cheers
alan


On 11 September 2013 11:45, roger peppe <rogp...@gmail.com> wrote:
On 11 September 2013 15:45, Alan Donovan <adon...@google.com> wrote:
> On 11 September 2013 08:29, Daniel Morsing <daniel....@gmail.com> wrote:
>> - Byte offset is a bit tricky to work around in acme. Using byte
>> offsets also makes it possible to specify a range that's inside a
>> UTF-8 sequence, but the tool seems to handle that fine. I don't know
>> how convenient switching to rune offsets would be, but I'd prefer
>> that.
>
>
> We could easily add that as an option.
>
> Rob Pike had a 5-minute hack for oracle+acme.  Though I haven't seen his
> code, he didn't mention the issue as a problem, so perhaps Acme does provide
> hooks to access byte offsets?

It doesn't, but it's easy enough to work around. I also have a 5
minute hack for oracle+acme.

It looks like this:
#!/usr/local/plan9/bin/rc
addr=`{acmedot}
oracle -pos $addr $*

where acmedot prints out the address of the current window.
(http://play.golang.org/p/-KSoTt2Q2_- mostly stolen from godef)

I have also had a little play with oracle. It worked pretty well,
although it took a long time to run.

I'm really looking forward to being able to throw away godef at some
point in the future
and replace it with oracle. Things that should help make this possible:

- the ability to take some code from the editor's buffer rather than from disk.
Currently if the file on disk is different from the editor's version, the
byte offset is probably bogus. In godef I solved this by allowing
the current file to be read from stdin, but I wonder if a package
API to oracle could access all files through some kind of filesystem interface,
so a given editor could define an interface that made currently in-buffer
files available to oracle.

- "best effort" mode. It should be possible to find some information
on a program
even if it doesn't fully type check.

-  the ability to find the definition of a symbol even without setting a scope;
the scope is only needed for more sophisticated analysis. This means it
should Perhaps
it might be worth having another mode, "define", which does only the
limited analysis necessary for finding a symbol definition.

- much faster operation - I've seen it take between 5s and 30s to run.
Godef took about 10ms on the same thing (admittedly with much smaller
scope)

- the ability to specify a symbol other than by file offset - for instance, if I
want to find the definition of a function or variable without first finding a
mention of that identifier in the source code, it would be nice to be able
to name it on the oracle command line.

I'll try to file specific issues around the actual oracle output as
they turn up.

This is a marvellous tool - thanks so much for working on it!

Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/16/13 4:05 PM
Great. Thanks.

Dan
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/16/13 4:15 PM
Just thinking, the search itself should be O(nm) where n is the size of
the corpus AST and m the size of the query AST.

On Mon, 2013-09-16 at 17:29 -0400, Alan Donovan wrote:
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Liigo Zhuang 9/16/13 6:14 PM

2013/9/16 Sebastien Douche <sdo...@gmail.com>

On Mon, Sep 16, 2013 at 4:10 AM, Andrew Gerrand <a...@golang.org> wrote:
> To be honest, I've known about this project of Alan's for months and the
> coincidence never occurred to me!

At first sight, I thought it was a database tool.


+1. Me too. 

--
by Liigo, http://blog.csdn.net/liigo/
Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs kortschak 9/16/13 6:25 PM
Thinking more, it can be reduced to a string search and so O(n) if you
render the ASTs each with a global place-holder for variable names (i.e.
all variable names are replaced with the same identifier), probably with
the exception of '_'.
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Java Pro 10/18/13 8:14 AM
1. This tool is really cool and much needed!

2. Can we have an option to make the oracle output pane on the left or right rather than at the bottom? This way, 1) more vertical space to view the source code 2) less mouse movement to the bottom.

3. "oracle" is what this tool is. I guess a lot of non-native English speaking people first came to know this word by having heard the Oracle database when Oracle heavily marketed its products in the country. Therefore, oracle does stand for a database. Native English speaking people first knew this word when they were very young and had no clue of what a database is and just remembered the true meaning of this word. 
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs freder...@gmail.com 10/18/13 9:26 AM
On Friday, October 18, 2013 5:14:10 PM UTC+2, Java Pro wrote:
2. Can we have an option to make the oracle output pane on the left or right rather than at the bottom?

 In case you are referring to the Pythia web interface: makes sense to me and I've created a ticket: https://github.com/fzipp/pythia/issues/16
Re: [golang-dev] Re: [go-nuts] [ANN] The Go Oracle: a source code comprehension tool for Go programs Java Pro 10/18/13 8:32 PM
A little bit syntax highlighting in Pythia for the go files (github or Sublime style) would make it a better standalone analyzer without an IDE. 



--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/CwdIJZs6Tfc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

More topics »