
I'm trying to run yi. More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev. yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database. Has anyone gotten a similar setup to work, or does anyone have any suggestions? -- Alex R

I've not tried this myself, but you could look at the -fhacking flag. It's documented in the README.md file, which claims it compiles yi without dynamic reconfiguration, and instead uses HackerMain.hs as your (static) configuration file. Reiner On 22/06/11 11:55, Alex Rozenshteyn wrote:
I'm trying to run yi.
More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev.
yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database.
Has anyone gotten a similar setup to work, or does anyone have any suggestions?
-- Alex R
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn
More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev.
yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database.
I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db). --Rogan
Has anyone gotten a similar setup to work, or does anyone have any suggestions?
-- Alex R
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

From looking at Yi's code, there seems to be a hard-coded list of arguments to pass to ghc. A hack would be to recompile Yi with the arguments to use a different package database...
On Wed, Jun 22, 2011 at 2:32 AM, Rogan Creswick
On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn
wrote: More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev.
yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database.
I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db).
--Rogan
Has anyone gotten a similar setup to work, or does anyone have any suggestions?
-- Alex R
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alex R

On Tue, Jun 21, 2011 at 11:59 PM, Alex Rozenshteyn
From looking at Yi's code, there seems to be a hard-coded list of arguments to pass to ghc. A hack would be to recompile Yi with the arguments to use a different package database...
You may be able to create a 'ghc' shell script that invokes (the real) ghc with the correct --package-conf for Yi, then make a Yi script that sets up a custom path so that it finds your ghc script first. Lots of "ifs", but at least you wouldn't have to maintain a Yi fork :) --Rogan
On Wed, Jun 22, 2011 at 2:32 AM, Rogan Creswick
wrote: On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn
wrote: More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev.
yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database.
I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db).
--Rogan
Has anyone gotten a similar setup to work, or does anyone have any suggestions?
-- Alex R
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alex R

Experimentation with that idea and the use of the "strings" command suggest
that the full path to the ghc binary is used and is stored in the compiled
Yi executable.
I'd rather not replace the ghc binary with a shell script that determines if
it's being called by Yi or not and then behaves differently. While amusing,
I'd rather not.
On Wed, Jun 22, 2011 at 3:42 AM, Rogan Creswick
On Tue, Jun 21, 2011 at 11:59 PM, Alex Rozenshteyn
wrote: From looking at Yi's code, there seems to be a hard-coded list of arguments to pass to ghc. A hack would be to recompile Yi with the arguments to use a different package database...
You may be able to create a 'ghc' shell script that invokes (the real) ghc with the correct --package-conf for Yi, then make a Yi script that sets up a custom path so that it finds your ghc script first. Lots of "ifs", but at least you wouldn't have to maintain a Yi fork :)
--Rogan
On Wed, Jun 22, 2011 at 2:32 AM, Rogan Creswick
wrote:
On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn
wrote:
More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev.
yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database.
I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db).
--Rogan
Has anyone gotten a similar setup to work, or does anyone have any suggestions?
-- Alex R
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alex R
-- Alex R
participants (3)
-
Alex Rozenshteyn
-
Reiner Pope
-
Rogan Creswick