Re: Different behavior in ghci 7.8.3 vs 7.10.1?
It turns out the problem was due to a very old Setup.hs that I was working with. After replacing it with the version recommended by the latest cabal docs the undefined reference issues disappeared. Sorry! I also added 'buildable: True' to the buildinfo file, following the latest docs. On Sat, Jun 27, 2015 at 2:53 PM, Dominick Samperi wrote: > After much trial-and-error and web searching I found a work-around for > ghci 7.10.1. > > It appears that BOTH extra-libraries and extra-lib-dirs must be > specified in the cabal file. Previously the link parameters were > specified using a .buildinfo file. It appears that with ghci > 7.10.1 this information is no longer used? Specifically, the > ld-options setting in that file is ignored. > > This work-around is not satisfactory because I do not want to > hard-code the path to the exra lib in the cabal file for obvious > reasons. > > It appears that some changes were made recently to the way cabal > handles external linkage, and this is probably related to the problems > reported here. > > On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi wrote: >> In case this is not obvious, I should also note that this is a ghci >> problem. When >> compiled using ghc 7.10.1 there are no probelms with unresolved references. >> >> On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi >> wrote: >>> I've attached the output of ghc --info. Will have to work on >>> crafting a small example... >>> >>> On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich >>> wrote: On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote: > To test ghci 7.10.1 I compiled from source and simply placed the > resulting bin in my PATH. Perhaps this is not enough? Sounds right. What does 'ghc --info' show? > On the second suggestion, I tried ldd and found that the undefined > symbol is flagged 'B' in the nm output (.bss section). > > This symbol is defined in the shared library, and the output of ghc > -v2 shows that this shared library is > linked without problems on startup of ghci. When the Haskell/FFI > function is run the symbol is undefined. Can you craft a complete small example with a build script that shows the error? -- Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
After much trial-and-error and web searching I found a work-around for ghci 7.10.1. It appears that BOTH extra-libraries and extra-lib-dirs must be specified in the cabal file. Previously the link parameters were specified using a .buildinfo file. It appears that with ghci 7.10.1 this information is no longer used? Specifically, the ld-options setting in that file is ignored. This work-around is not satisfactory because I do not want to hard-code the path to the exra lib in the cabal file for obvious reasons. It appears that some changes were made recently to the way cabal handles external linkage, and this is probably related to the problems reported here. On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi wrote: > In case this is not obvious, I should also note that this is a ghci > problem. When > compiled using ghc 7.10.1 there are no probelms with unresolved references. > > On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi wrote: >> I've attached the output of ghc --info. Will have to work on >> crafting a small example... >> >> On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote: >>> On Sat, 27 Jun 2015 07:59:33 -0400 >>> Dominick Samperi wrote: >>> To test ghci 7.10.1 I compiled from source and simply placed the resulting bin in my PATH. Perhaps this is not enough? >>> >>> Sounds right. What does 'ghc --info' show? >>> On the second suggestion, I tried ldd and found that the undefined symbol is flagged 'B' in the nm output (.bss section). This symbol is defined in the shared library, and the output of ghc -v2 shows that this shared library is linked without problems on startup of ghci. When the Haskell/FFI function is run the symbol is undefined. >>> >>> Can you craft a complete small example with a build script that shows the >>> error? >>> >>> -- >>> >>> Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
help with recognizing symbolic identifiers
Hi devs, I've just posted #10583 (http://ghc.haskell.org/trac/ghc/ticket/10583) about fixing up basicTypes/Lexeme.hs. As stated in the ticket, I'm happy to do the hacking, but I need some advice. My most pressing question is this: Examine the following functions, which all should do the same thing * isVarSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L102 * okSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L215 * notFollowedBySymbol: https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L904 These functions intend to identify characters that can appear in symbolic identifiers. They all have different implementations. Which one is right? Or is there a better way to do this operation? There are other questions in the ticket, but I can probably sort those out on my own. If you can help, ideally you will respond in the ticket itself. Many thanks! Richard___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Abstract FilePath Proposal
On Sat, Jun 27, 2015 at 6:37 AM, Herbert Valerio Riedel wrote: > On 2015-06-27 at 14:56:33 +0200, David Fox wrote: > > [...] > > > I've had success with a slightly different "How": > > What was your concrete use-case btw? > > > Phase 1: Replace FilePath with a type class, with instances for the old > > FilePath (i.e. String) and the new implementation. > > what would that comprise in the FilePath case? > > I assume adding a transitional class whose methods are not exposed (and > whose typeclass name is exported from some GHC-specific internal-marked > module)? i.e. > > class IsFilePath a where > privateToFilePath :: a -> FilePath > privateFromFilePath :: FilePath -> a > > instance IsFilePath FilePath where > privateToFilePath = id > privateFromFilePath = id > > instance IsFilePath [Char] where > privateToFilePath = System.IO.toFilePath > privateFromFilePath = System.IO.fromFilePath > > ? > > as well as changing a lot of type-sigs in base & filepath from > e.g. > > writeFile :: FilePath -> String -> IO () > openTempFile :: FilePath -> String -> IO (FilePath, Handle) > > to > > writeFile:: IsFilePath a => a -> String -> IO () > openTempFile :: IsFilePath a => a -> String -> IO (a, Handle) > > > ? > > > Phase 2: Wait until a suitable amount of hackage builds without the > string > > instance. > > I can see Stackage helping with that by using a custom GHC which lacks > the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 > could be > accomplished within one year for the Stackage-subset of Hackage. > > > Phase 3: Deprecate the String instance - move it to an old-filepath > package. > > > > Phase 4: Replace the type class with the new implementation > > I assume this means getting rid again of the typeclass, and changing the > type-sigs back to i.e. > > writeFile :: FilePath -> String -> IO () > openTempFile :: FilePath -> String -> IO (FilePath, Handle) > > (but now with with the new opaque `FilePath`)? > > > This way the new implementation is available immediately, packages can > > begin converting at once, benefits can be assessed. > > This scheme seems feasible at first glance, as long as the typeclass > doesn't start spreading across packages and find its way into type-sigs > (in which case it'd become more disruptive to get rid of it > again). Otoh, I'm not sure (assuming I understood how your scheme works) > it can be avoided to have the typeclass spread, since if not every API > that now has `FilePath` arguments in their type-sigs gets generalised to > have `IsFilePath a => a` arguments instead, we can't reach the goal of > "Phase 2". > > But I suspect that I didn't fully understand how your proposed > transition scheme works exactly... so please correct me where I got it > wrong! > You are right, your approach is more appropriate for use by a community. I missed some of the problems that would arise. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Abstract FilePath Proposal
On 2015-06-27 at 14:56:33 +0200, David Fox wrote: [...] > I've had success with a slightly different "How": What was your concrete use-case btw? > Phase 1: Replace FilePath with a type class, with instances for the old > FilePath (i.e. String) and the new implementation. what would that comprise in the FilePath case? I assume adding a transitional class whose methods are not exposed (and whose typeclass name is exported from some GHC-specific internal-marked module)? i.e. class IsFilePath a where privateToFilePath :: a -> FilePath privateFromFilePath :: FilePath -> a instance IsFilePath FilePath where privateToFilePath = id privateFromFilePath = id instance IsFilePath [Char] where privateToFilePath = System.IO.toFilePath privateFromFilePath = System.IO.fromFilePath ? as well as changing a lot of type-sigs in base & filepath from e.g. writeFile :: FilePath -> String -> IO () openTempFile :: FilePath -> String -> IO (FilePath, Handle) to writeFile:: IsFilePath a => a -> String -> IO () openTempFile :: IsFilePath a => a -> String -> IO (a, Handle) ? > Phase 2: Wait until a suitable amount of hackage builds without the string > instance. I can see Stackage helping with that by using a custom GHC which lacks the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 could be accomplished within one year for the Stackage-subset of Hackage. > Phase 3: Deprecate the String instance - move it to an old-filepath package. > > Phase 4: Replace the type class with the new implementation I assume this means getting rid again of the typeclass, and changing the type-sigs back to i.e. writeFile :: FilePath -> String -> IO () openTempFile :: FilePath -> String -> IO (FilePath, Handle) (but now with with the new opaque `FilePath`)? > This way the new implementation is available immediately, packages can > begin converting at once, benefits can be assessed. This scheme seems feasible at first glance, as long as the typeclass doesn't start spreading across packages and find its way into type-sigs (in which case it'd become more disruptive to get rid of it again). Otoh, I'm not sure (assuming I understood how your scheme works) it can be avoided to have the typeclass spread, since if not every API that now has `FilePath` arguments in their type-sigs gets generalised to have `IsFilePath a => a` arguments instead, we can't reach the goal of "Phase 2". But I suspect that I didn't fully understand how your proposed transition scheme works exactly... so please correct me where I got it wrong! Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
In case this is not obvious, I should also note that this is a ghci problem. When compiled using ghc 7.10.1 there are no probelms with unresolved references. On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi wrote: > I've attached the output of ghc --info. Will have to work on > crafting a small example... > > On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote: >> On Sat, 27 Jun 2015 07:59:33 -0400 >> Dominick Samperi wrote: >> >>> To test ghci 7.10.1 I compiled from source and simply placed the >>> resulting bin in my PATH. Perhaps this is not enough? >> >> Sounds right. What does 'ghc --info' show? >> >>> On the second suggestion, I tried ldd and found that the undefined >>> symbol is flagged 'B' in the nm output (.bss section). >>> >>> This symbol is defined in the shared library, and the output of ghc >>> -v2 shows that this shared library is >>> linked without problems on startup of ghci. When the Haskell/FFI >>> function is run the symbol is undefined. >> >> Can you craft a complete small example with a build script that shows the >> error? >> >> -- >> >> Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
I've attached the output of ghc --info. Will have to work on
crafting a small example...
On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote:
> On Sat, 27 Jun 2015 07:59:33 -0400
> Dominick Samperi wrote:
>
>> To test ghci 7.10.1 I compiled from source and simply placed the
>> resulting bin in my PATH. Perhaps this is not enough?
>
> Sounds right. What does 'ghc --info' show?
>
>> On the second suggestion, I tried ldd and found that the undefined
>> symbol is flagged 'B' in the nm output (.bss section).
>>
>> This symbol is defined in the shared library, and the output of ghc
>> -v2 shows that this shared library is
>> linked without problems on startup of ghci. When the Haskell/FFI
>> function is run the symbol is undefined.
>
> Can you craft a complete small example with a build script that shows the
> error?
>
> --
>
> Sergei
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/gcc")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags","")
,("Haskell CPP command","/usr/bin/gcc")
,("Haskell CPP flags","-E -undef -traditional ")
,("ld command","/usr/bin/ld")
,("ld flags","")
,("ld supports compact unwind","YES")
,("ld supports build-id","YES")
,("ld supports filelist","NO")
,("ld is GNU ld","YES")
,("ar command","/usr/bin/ar")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/bin/perl")
,("target os","OSLinux")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","True")
,("target has .ident directive","True")
,("target has subsections via symbols","False")
,("Unregisterised","NO")
,("LLVM llc command","llc")
,("LLVM opt command","opt")
,("Project version","7.10.1")
,("Project Git commit id","ca00def1d7093d6b5b2a937ddfc8a01c152038eb")
,("Booter version","7.8.3")
,("Stage","2")
,("Build platform","x86_64-unknown-linux")
,("Host platform","x86_64-unknown-linux")
,("Target platform","x86_64-unknown-linux")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn l_dyn thr_l_dyn")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Uses package keys","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","YES")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/home/dsamperi/bin/ghc-7.10.1/lib/ghc-7.10.1")
,("Global Package
DB","/home/dsamperi/bin/ghc-7.10.1/lib/ghc-7.10.1/package.conf.d")
]
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Abstract FilePath Proposal
On Fri, Jun 26, 2015 at 9:08 AM, Herbert Valerio Riedel wrote: > > > We (see From: & CC: headers) propose, plain and simple, to turn the > currently defined type-synonym > > type FilePath = String > > into an abstract/opaque data type instead. > > Why/How/When? I've had success with a slightly different "How": Phase 1: Replace FilePath with a type class, with instances for the old FilePath (i.e. String) and the new implementation. Phase 2: Wait until a suitable amount of hackage builds without the string instance. Phase 3: Deprecate the String instance - move it to an old-filepath package. Phase 4: Replace the type class with the new implementation This way the new implementation is available immediately, packages can begin converting at once, benefits can be assessed. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote: > To test ghci 7.10.1 I compiled from source and simply placed the > resulting bin in my PATH. Perhaps this is not enough? Sounds right. What does 'ghc --info' show? > On the second suggestion, I tried ldd and found that the undefined > symbol is flagged 'B' in the nm output (.bss section). > > This symbol is defined in the shared library, and the output of ghc > -v2 shows that this shared library is > linked without problems on startup of ghci. When the Haskell/FFI > function is run the symbol is undefined. Can you craft a complete small example with a build script that shows the error? -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
On the second suggestion, I tried ldd and found that the undefined symbol is flagged 'B' in the nm output (.bss section). This symbol is defined in the shared library, and the output of ghc -v2 shows that this shared library is linked without problems on startup of ghci. When the Haskell/FFI function is run the symbol is undefined. On Sat, Jun 27, 2015 at 7:26 AM, Dominick Samperi wrote: > Thank you, the 'ghci -v2' suggestion was helpful. I now see the > expected link steps. > > But when I try to run there are unresolved symbols (with ghci 7.10.1; > everything works fine > with ghci 7.8.3). This may be due to the fact that > I have not installed the Haskell Platform with ghci 7.10.1 under > Fedora 21. I'm using > the latest released HP with ghci 7.8.3. > > To test ghci 7.10.1 I compiled from source and simply placed the > resulting bin in > my PATH. Perhaps this is not enough? > > > On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich wrote: >> On Fri, 26 Jun 2015 23:05:55 -0400 >> Dominick Samperi wrote: >> >>> Hello, >>> >>> I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 >>> but this fails. >>> >>> Under 7.8.3, when I run from the shell: >>> export LD_LIBRARY_PATH=thepath >>> ghci -lmylib -fno-ghci-sandbox mydriver.hs >>> >>> I see the usual startup diagnostics along with >>> Loading object (dynamic) mylib ... done >>> final link ... done >>> [1 of 1] Compiling Main >>> Main> >>> >>> But under 7.10.1, when I do the same, there is no indication that >>> linking happens, and when I try to run the program there are >>> undefined references. >>> >>> I probably missed the post that explains this behavior. Can somebody >>> provide a pointer to a work-around? >> >> There is two separate issues: >> >> 1. ghc-7.10 became less chatty when loads libraries. >> 'ghci -v2' gets it back with a bit of noise >> >> 2. looks more like actual problem. is your mylib >> fully linked against it's depends? >> LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so >> LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so >> you can also try to inspect LD_DEBUG=help ghci ... >> >> -- >> >> Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: Abstract FilePath Proposal
On 06/27/2015 11:33 AM, Niklas Larsson wrote: > Hi! > > Instead of trying to minimally patch the existing API and still > breaking loads of code, why not make a new API that doesn't have > to compromise and depreciate the old one? > This is a good idea in theory, but it's how we end up in situations like https://xkcd.com/927/ :) Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
Thank you, the 'ghci -v2' suggestion was helpful. I now see the expected link steps. But when I try to run there are unresolved symbols (with ghci 7.10.1; everything works fine with ghci 7.8.3). This may be due to the fact that I have not installed the Haskell Platform with ghci 7.10.1 under Fedora 21. I'm using the latest released HP with ghci 7.8.3. To test ghci 7.10.1 I compiled from source and simply placed the resulting bin in my PATH. Perhaps this is not enough? On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich wrote: > On Fri, 26 Jun 2015 23:05:55 -0400 > Dominick Samperi wrote: > >> Hello, >> >> I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 >> but this fails. >> >> Under 7.8.3, when I run from the shell: >> export LD_LIBRARY_PATH=thepath >> ghci -lmylib -fno-ghci-sandbox mydriver.hs >> >> I see the usual startup diagnostics along with >> Loading object (dynamic) mylib ... done >> final link ... done >> [1 of 1] Compiling Main >> Main> >> >> But under 7.10.1, when I do the same, there is no indication that >> linking happens, and when I try to run the program there are >> undefined references. >> >> I probably missed the post that explains this behavior. Can somebody >> provide a pointer to a work-around? > > There is two separate issues: > > 1. ghc-7.10 became less chatty when loads libraries. > 'ghci -v2' gets it back with a bit of noise > > 2. looks more like actual problem. is your mylib > fully linked against it's depends? > LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so > LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so > you can also try to inspect LD_DEBUG=help ghci ... > > -- > > Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Abstract FilePath Proposal
Hi Niklas, The function writeFile takes a FilePath. We could fork base or tell everyone to use writeFile2, but in practice everyone will keep using writeFile, and this String for FilePath. This approach is the only thing we could figure that made sense. Henning: we do not propose normalisation on initialisation. For ASCII strings fromFilePath . toFilePath will be id. It might also be for unicode on some/all platforms. Of course, you can write your own FilePath creator that does normalisation on construction. Thanks, Neil On Saturday, 27 June 2015, Niklas Larsson > wrote: > Hi! > > Instead of trying to minimally patch the existing API and still breaking > loads of code, why not make a new API that doesn't have to compromise and > depreciate the old one? > > Niklas > -- > Från: Herbert Valerio Riedel > Skickat: 2015-06-26 18:09 > Till: librar...@haskell.org; ghc-devs@haskell.org > Ämne: Abstract FilePath Proposal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello *, > > What? > = > > We (see From: & CC: headers) propose, plain and simple, to turn the > currently defined type-synonym > > type FilePath = String > > into an abstract/opaque data type instead. > > Why/How/When? > = > > For details (including motivation and a suggested transition scheme) > please consult > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath > > > > Suggested discussion period: 4 weeks > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb > HjIPRrJbVK9AABo4AZ/Y > =lg0o > -END PGP SIGNATURE- > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: Abstract FilePath Proposal
Because new api already exists in libraries, but FilePath from base is still being used, which makes things worse (now your programs have all those conversions all over). I like the idea with gradual deprecation warning, but it's not clear if it's feasible to implement. 27 черв. 2015 12:33 "Niklas Larsson" пише: > Hi! > > Instead of trying to minimally patch the existing API and still breaking > loads of code, why not make a new API that doesn't have to compromise and > depreciate the old one? > > Niklas > -- > Från: Herbert Valerio Riedel > Skickat: 2015-06-26 18:09 > Till: librar...@haskell.org; ghc-devs@haskell.org > Ämne: Abstract FilePath Proposal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello *, > > What? > = > > We (see From: & CC: headers) propose, plain and simple, to turn the > currently defined type-synonym > > type FilePath = String > > into an abstract/opaque data type instead. > > Why/How/When? > = > > For details (including motivation and a suggested transition scheme) > please consult > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath > > > > Suggested discussion period: 4 weeks > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb > HjIPRrJbVK9AABo4AZ/Y > =lg0o > -END PGP SIGNATURE- > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
On Fri, 26 Jun 2015 23:05:55 -0400 Dominick Samperi wrote: > Hello, > > I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 > but this fails. > > Under 7.8.3, when I run from the shell: > export LD_LIBRARY_PATH=thepath > ghci -lmylib -fno-ghci-sandbox mydriver.hs > > I see the usual startup diagnostics along with > Loading object (dynamic) mylib ... done > final link ... done > [1 of 1] Compiling Main > Main> > > But under 7.10.1, when I do the same, there is no indication that > linking happens, and when I try to run the program there are > undefined references. > > I probably missed the post that explains this behavior. Can somebody > provide a pointer to a work-around? There is two separate issues: 1. ghc-7.10 became less chatty when loads libraries. 'ghci -v2' gets it back with a bit of noise 2. looks more like actual problem. is your mylib fully linked against it's depends? LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so you can also try to inspect LD_DEBUG=help ghci ... -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
SV: Abstract FilePath Proposal
Hi! Instead of trying to minimally patch the existing API and still breaking loads of code, why not make a new API that doesn't have to compromise and depreciate the old one? Niklas - Ursprungligt meddelande - Från: "Herbert Valerio Riedel" Skickat: 2015-06-26 18:09 Till: "librar...@haskell.org" ; "ghc-devs@haskell.org" Ämne: Abstract FilePath Proposal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello *, What? = We (see From: & CC: headers) propose, plain and simple, to turn the currently defined type-synonym type FilePath = String into an abstract/opaque data type instead. Why/How/When? = For details (including motivation and a suggested transition scheme) please consult https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Suggested discussion period: 4 weeks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb HjIPRrJbVK9AABo4AZ/Y =lg0o -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Abstract FilePath Proposal
On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:
[...]
> I am *entirely* behind this in priciple and if it doesn't break too much
> of Hackage, also in practice, but...
>
> ... how much of Hackage *does* this break?
This won't be for free: I expect most packages which currently do more
than just opaquely pass around FilePaths to require fixes.
Some examples:
- `writeFile "doo/foo.bar" ...`
`_ <- readFile ("doo" "foo" <.> "bar")`
This will break unless -XOverloadedStrings happens to be enabled
- Unless we generalise (++) to (<>), all cases where `FilePath`s are
concatenated via (++) will break.
- Code that uses Data.List rather than the `filepath` package for
FilePath manipulation will need fixups (simplest fix: explicitly
convert to/from String for the manipulation)
- Some code, like e.g.
fnames <- System.Environment.getArgs
forM fnames $ \fn -> print =<< readFile fn
will inevitably need to insert explicit conversions to/from FilePaths
I tried to simulate the effect on Hackage, but this turned out to be
more time-demanding than I hoped for and I had to abort. But the above
is what I encountered in my attempt.
> The reason that I'm in favor in principle is that paths really *are*
> opaque things -- platforms have entirely different conventions. AFAICT
> the only thing that they seem to agree on is that there is a "hierarchy"
> of some sort. (And not much else, including such things as case
> (in-)sensivity or character sets.).
> For example, in POSIX they're just strings of bytes without any
> specified encoding, and I'd love if they could be make to work like
> that when dealing with files in Haskell.
Yes, if you look e.g. at
http://hackage.haskell.org/package/unix
you see a lot of API duplication, which wouldn't have been needed if
FilePath was an opaque type w/ lossless conversion to/from
ByteString.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
