Opened 6 years ago

Last modified 6 years ago

#2403 new feature request

caching for runghc (runhaskell)

Reported by: jsnx Owned by: jsnx
Priority: normal Milestone:
Component: Compiler Version:
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

I'd like runghc to compile and cache scripts, so they will run fast after the first shot. This could be available via a command line option, special name (runhaskello), or be governed by a config file -- I'm open to suggestions here.

I still haven't quite worked out how to do this -- I'll have more ideas about the layout of the cache in a few days.

I'm making a feature request of it not because I want someone else to do it, but rather because I'd like it to be accepted once I finish it and I wouldn't want to invest all the time and trouble in reworking runghc if it's just going to be rejected.

Change History (8)

comment:1 follow-up: Changed 6 years ago by duncan

How the -fobject-code flag. In fact it may work already, I don't know. In ghci it means to compile all the .hs files to .o and to load them instead. I see no reason it could not do the same for runghc.

No need for a complex cache, just use the ordinary --make behaviour along with the -hidir and related flags for changing where the generated files go and are looked for.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 6 years ago by jsnx

Replying to duncan:

How the -fobject-code flag. In fact it may work already, I don't know. In ghci it means to compile all the .hs files to .o and to load them instead. I see no reason it could not do the same for runghc.

No need for a complex cache, just use the ordinary --make behaviour along with the -hidir and related flags for changing where the generated files go and are looked for.

Well, sure, I can do it with a shell script instead. What I'm offering is integrated, system-wide caching for scripts with #!/usr/bin/env runhaskell in their first line.

If it's not seen to be of value, there's no point in my writing -- as you suggest, I can just make a shell script for it if it's going to be a private thing.

comment:3 in reply to: ↑ 2 Changed 6 years ago by jsnx

Replying to jsnx:

Replying to duncan:

...

...

I realize now that I may have misinterpreted your message. I was actually planning to use --make to do the caching, but I wanted to be sure that the cache was shared across users and respected differences in GHC versions. This might lead to a cache like /tmp/runghc/<runghc version here>/<actual cache here>. It's also worth examining the security dangers of a system wide cache. They may be severe -- evil object files could be substituted for correct ones if all users have write access to the cache. So maybe we need to spawn a separate process that calls a setuid program to do the compilation?

comment:4 follow-up: Changed 6 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to _|_

Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc.

comment:5 in reply to: ↑ 4 Changed 6 years ago by jsnx

Replying to igloo:

Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc.

How much of this will --make actually handle?

comment:6 Changed 6 years ago by jsnx

  • Owner set to jsnx

comment:7 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:8 Changed 6 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple
Note: See TracTickets for help on using tickets.