Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

toplevel should provide an option to limit recursion when printing nested modules #5377

Closed
vicuna opened this issue Oct 17, 2011 · 16 comments
Closed
Assignees

Comments

@vicuna
Copy link

vicuna commented Oct 17, 2011

Original bug ID: 5377
Reporter: @ygrek
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2015-12-11T18:26:36Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 3.11.2
Fixed in version: 4.02.0+dev
Category: ~DO NOT USE (was: OCaml general)
Tags: patch
Related to: #5430
Monitored by: @lpw25 @ygrek

Bug description

This would make exploring libraries from toplevel much easier. For each package one can get the list of modules (with findlib), but the only way to explore modules is to include them (or alias) - and for big libraries this can produce lots and lots of output, while one usually wants to see only the first level and explore deeper as needed. This should probably be a directive similar to #print_depth

Example:

#use "topfind";;

  • : unit = ()

#require "camomile";;

/usr/lib/ocaml/unix.cma: loaded
/usr/lib/ocaml/bigarray.cma: loaded
/usr/local/lib/ocaml/3.11.2/camomile: added to search path
/usr/local/lib/ocaml/3.11.2/camomile/camomile.cma: loaded

include CamomileLibraryDefault;;

[~1000 lines of output]

File attachments

@vicuna
Copy link
Author

vicuna commented Oct 23, 2011

Comment author: @garrigue

You were lucky: I have reports of messages of more than 1MB...

This is now fixed in trunk: long traces are omitted, replaced by logical and physical locations for the error. (commits 11225-11230)

@vicuna
Copy link
Author

vicuna commented Oct 24, 2011

Comment author: @ygrek

The patch affects printing of error locations, but I am talking here about toplevel's normal way to display the contents of module.

Sorry, if I am mistaken - current trunk doesn't build - http://build.ygrek.org.ua/jenkins/job/ocaml/label=master/66/console - so I can't verify it.

@vicuna
Copy link
Author

vicuna commented Oct 25, 2011

Comment author: @garrigue

OK, it seems that I misunderstood what you wanted.
Indeed, there is no support for exploring modules in the toplevel,
other than printing the full signature by aliasing a module.
However, a pragma for changing the logical print depth of
modules seems a rather hacky way to go; one would rather
use a real cli library browser...
This might be nice if we can find a minimal language to do that.
Something like
#show value
#show type
#show module []
#show module type []
...
And also
#search value ""
....

Note that there are also GUI tools to do that, like ocamlbrowser
(which works with just .cmi), or ocamldoc.

By the way, at least for me trunk compiles perfectly.
But don't forget 'make clean' before you start.

@vicuna
Copy link
Author

vicuna commented Oct 25, 2011

Comment author: @ygrek

I definitely like the #show pragma :)
Exploring with external tools is fine, but an ability to do this directly from toplevel, in ad-hoc manner, is invaluable.

PS I did check the build failure with clean svn checkout

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: @garrigue

A simple patch is now available in trunk/experimental/garrigue/show_types.diffs
It defines directives

#show_value
#show_type
#show_exception
#show_module
#show_module_type
#show_class
#show_class_type

There is no depth option at this point (they all only take a path).

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: @garrigue

Concerning the depth, printing uses the standard formatter, so you can just do
Format.set_max_boxes 6 to get only in the immediate contents of a module.

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: @ygrek

Here is an updated patch that sticks to single #show directive.

Thanks for the trick with Format - it helps, but is not a proper solution - e.g. it works for CamomileLibrary (this module consists of only other modules) but not for say CamomileLibrary.UChar (types are not displayed).

@vicuna
Copy link
Author

vicuna commented Jul 31, 2013

Comment author: @garrigue

I updated show_types.diff, based on show_types2.diff
Sorry for the long delay.
It looks like a good addition.

@vicuna
Copy link
Author

vicuna commented Apr 11, 2014

Comment author: @lpw25

I think we should probably merge this #show directive in 4.02, since module aliases remove the usual method people use for exploring APIs (i.e. module F = Foo to print the contents of Foo).

@vicuna
Copy link
Author

vicuna commented Apr 14, 2014

Comment author: @alainfrisch

The patch seems very useful to me as well (actually I was just in the middle of writing an email to complain about our broken "module F = Foo" idiom in the toplevel -- call me old school -- when I remembered about this ticket).

I'm a bit concerned by the implementation which extends the parsetree with a quite ad hoc construction. Wouldn't it work to change Ptop_dir's argument from directive_argument to "directive_argument list" (and remove Pdir_none)?

@vicuna
Copy link
Author

vicuna commented Apr 16, 2014

Comment author: @alainfrisch

I've committed to trunk (rev 14616) a change corresponding to my previous note.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2014

Comment author: @alainfrisch

I've further extended the notion of directive arguments in commit 14617 to allow keywords and capitalized longidents. Commit 14618 adds the "#show" directive, mostly following the show_types2.diff patch.

Given the flexible syntax for directive arguments, it would be simple to give a meaning to "#show bla" (either equivalent to "#show val bla" or showing all components of name bla). Opinions? It's also possible to add support for showing constructors and labels, for instance.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2014

Comment author: @alainfrisch

Note that the original request (bounding the depth of the printed result) is not addressed yet.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2014

Comment author: @garrigue

Note that the original request (bounding the depth of the printed result) is not addressed yet.

It is: when using #show on modules, you only get one level (for modules).
See for instance the difference between #show module Hashtbl and #show module Hashtbl.Make.
A further question is whether it would not be better to also omit module types, since they can be quite long too.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2014

Comment author: @alainfrisch

Ah yes, sorry.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2014

Comment author: @alainfrisch

Marking this as resolved. If anyone wants to discuss improvements to #show, please open a new ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants