Euphoria Ticket #841: search.dat

Allow people to search for things programatically from EUPHORIA. search.dat is generated by the newest creole.ex. Re-translate and compile to get one.

The best location for this is $INSTALL_DIR/include on Windows and /usr/include on other OSes.

Details

Type: Feature Request Severity: Normal Category: Distribution
Assigned To: SDPringle Status: Fixed Reported Release: 4.0.5
Fixed in SVN #: View VCS: none Milestone: 4.0.6

1. Comment by jimcbrown Jan 28, 2013

Why would it be include? This is a piece of generated documentation (well, sort of), not a header file or a library.

2. Comment by SDPringle Feb 07, 2013

On Windows we can find out what EUDIR would have been with locate_file and backing off the bin directory. So defining EUDIR this way, it could be put into EUDIR/doc on Windows and /usr/share/doc/euphoria on other OSes.

3. Comment by jimcbrown Feb 07, 2013

That sounds reasonable to me.

4. Comment by mattlewis Feb 07, 2013

locate_file() seems excessive. Why not just look at the command line to see where the interpreter is? If you're running something translated, you probably shouldn't be assuming that euphoria is installed at all.

How about putting it into include/euphoria? This seems actually relevant. We could also put it in a format so that you simply need to include it. Maybe just a giant heredoc that you could use to generate the map or whatever other structure you want to use.

5. Comment by ne1uno Feb 07, 2013

>> we can find out what EUDIR would have been with locate_file that would be easily broken if you have multiple eui. better to use command[0] and fall back to locate if translated but really have to do more than exit at the first found eui

6. Comment by jimcbrown Feb 07, 2013

I'm ok with include/euphoria if it's in a format that you can use it as an include file. Otherwise, I'd question why it should go in there (if it is not an include).

I agree that using command_line() is probably better.

7. Comment by mattlewis Feb 07, 2013

Putting this file in some place in the filesystem seems like it's making things more difficult than it needs to be. Perhaps the right thing is to have it all in a public constant sequence with a public enum that tells us what each element means. That would be a lot easier to put into a map or whatever, or just searching manually (which you would need to do somehow to do partial matches).

The more I think about it, the more I like an include file and the less I like a raw text file as part of the distribution.

8. Comment by SDPringle Feb 07, 2013

After really looking at this again. I think it should go into EUDIR/docs/html and /usr/share/doc/euphoria/html respectively since they are only related to the HTML documentation and wont be useful for the PDF or any other kind of documentation.

9. Comment by SDPringle Feb 07, 2013

Using argv[0] to find out where the EUDIR would have been assumes your program is interpreted. This assumption is wrong in a translated program.

10. Comment by SDPringle Feb 07, 2013

I don't think having this dat file in a location where one can find it and having an API for retrieving where functions are documented are mutually exclusive. In fact, I'd say you could easily write an API once you could rely on this file being in some location.

Sometimes waiting for things to be done just right mean they never get done at all.

11. Comment by SDPringle Feb 14, 2013

See: hg:euphoria/rev/1b089be3a220

changeset: 5982:1b089be3a220 branch: 4.0 tag: tip user: Shawn Pringle <shawn.pringle@gmail.com> date: Thu Feb 14 13:41:00 2013 -0300 files: source/Makefile.gnu description:

  • adds search.dat to the docs to be installed by Makefile.gnu
  • for ticket 841

Search



Quick Links

User menu

Not signed in.

Misc Menu