jakubfijalkowski / hsass Goto Github PK

When libsass outputs UTF-8 characters outside of the ASCII range, it prefixes its output with encoding information. Depending on the level of compression, this is either in the form of @charset "UTF-8" or a Byte-Order Mark. For the unwary (me), the BOM inclusion can cause problems.

As an example, naively concatenating CSS causes styling bugs:

> let sass = "h1:before {\n    content: \"\9660\";\n}\n\n"
> let opts = def { sassOutputStyle = SassStyleCompressed }
> compileString sass opts >>= \(Right x) -> print @String (x ++ x)
"\65279h1:before{content:\"\9660\"}\n\65279h1:before{content:\"\9660\"}\n"
> --                                 ^ pesky BOM ends up in the middle of CSS

According to sass/sass#1395 this is not configurable; it's the up to the CSS concatenater to handle this correctly. Fine. But we're using Haskell, we have expressive types, and I think we can be more user-friendly.

In my opinion, encoding information does not belong in text (e.g. in String, Text). Not only is the in-memory encoding an implementation detail, but the encoding only matters when converting to a Bytestring, or when performing IO. Having encoding information in-line is therefore error-prone and inconsistent (a BOM gets automatically converted -- obviously @charset "UTF-8" does not).

For backwards compatibility, I think it's better not to change any existing behaviour. But a new instance of SassResult could be added that's equivalent to (Bool, String). This would strip encoding information from the String if needed, and indicate whether it had done so. Using this new feature would make CSS concatenation straightforward.

If this sounds sensible, I'm willing to implement it (or something similar, suggestions are welcome).

The link in the cabal description to libsass currently pooints to http://libsass.org/ which seems to have been taken over by another owner. I believe a more appropriate destination would be https://sass-lang.com/libsass

I've spent a lot of time fiddling with compileFile and makePathImport and still don't understand what paths need to be passed where.

Sass.compileFile (stylesheetRoot </> "app.scss") sassOpts
  where
    sassOpts = Default.def
      { sassHeaders = Just
                      [ SassImporter
                        { importerPriority = 1.0
                        , importerFunction = (\_ -> pure $
                                                    [ makeSourceImport settingOverrides
                                                    , makePathImport (stylesheetRoot </> "settings") "."
                                                    , makePathImport (stylesheetRoot </> "zurb-foundation/foundation-emails")  "."
                                                    ])

                        }
                      ]
      }

The only way I have gotten this to work is if stylesheetRoot is set to the absolute path of the directory that contains all the stylesheets. However, I cannot explain the following behaviours:

• if I set stylesheetRoot to the relative path containing all stylesheets (relative to current-working-directory of the Haskell process), Sass.compileFile is able to locate the file, BUT makePathImport is no longer able to locate the imports.
• Further, if instead of passing "." as importBase to makePathPort, I pass absolute path of the folder containing stylesheets, it has no impact. makePathImport is still unable to locate the file.

How is this supposed to work and how are all these paths related to each other:

• current working directory
• paths relative to the file passed to compileFile
• importPath
• importBase

My binary builds just fine on arch linux and debian, however on windows 7 x64, I tried resolvers lts-8.17, 8.5, 7.20 and they all give the same error:

from hlibsass-0.1.x.0.log:

[1 of 2] Compiling Main             ( C:\Users\test\AppData\Local\Temp\stack4536\hlibsass-0.1.5.0\Setup.hs, C:\Users\test\AppData\Local\Temp\stack4536\hlibsass-0.1.5.0\.stack-work\dist\b7fec021\setup\Main.o )
[2 of 2] Compiling StackSetupShim   ( C:\sr\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\Users\test\AppData\Local\Temp\stack4536\hlibsass-0.1.5.0\.stack-work\dist\b7fec021\setup\StackSetupShim.o )
Linking C:\Users\test\AppData\Local\Temp\stack4536\hlibsass-0.1.5.0\.stack-work\dist\b7fec021\setup\setup.exe ...

env: make: No such file or directory

Do I need to explicitly install 'make' or something?

Say that I have the function foo and the following sass

h1::before {
    content: foo()
}

What might I want foo to return? I either want what libsass considers to be an unquoted string, e.g. open-quote, or a quoted string, e.g. 'foo'.

Similarly, if a function takes a string as a parameter, it should be able to distinguish between foo(foo) and foo('foo').

Mirroring how libsass works (where quoted is a boolean field of Sass_String), I'm thinking of adding a parameter to the SassString data constructor like so

data SassValue = SassString Quoted String
    ...
    
data Quoted = Quoted | Unquoted

and adding support for this in hlibsass.

When I load GHCi, and try to use hsass, I get an error:

λ :m + Text.Sass
λ compileFile "./stylesheets/default.scss" (def { sassIncludePaths = Just ["stylesheets/"] }) :: IO (Either SassError String)
<interactive>:
lookupSymbol failed in relocateSection (RELOC_GOT)
/Users/ian/Code/iankduncan/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/hlibs_HR5edJE2XT1IuQkKGmjCv9/libsass.a: unknown symbol `___dso_handle'
ghc: unable to load package `hlibsass-0.1.2.0'

Do you have any idea what's wrong?

I'm trying to build hsass as part of a cross-platform app. It works great on Linux, but on Mac I'm getting some linker errors:

    lookupSymbol failed in relocateSection (RELOC_GOT)
    /Users/tom/.stack/snapshots/x86_64-osx/lts-7.14/8.0.1/lib/x86_64-osx-ghc-8.0.1/hlibsass-0.1.5.0-A2JAkaXM35zEGvz8eJSuVp/libsass.a: unknown symbol `___dso_handle'
    ghc: Could not on-demand load symbol '__ZN4Sass10Expression11set_delayedEb'

    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       __ZN4Sass10Expression11set_delayedEb
    whilst processing object file
       /Users/tom/.stack/snapshots/x86_64-osx/lts-7.14/8.0.1/lib/x86_64-osx-ghc-8.0.1/hlibsass-0.1.5.0-A2JAkaXM35zEGvz8eJSuVp/libsass.a
    The symbol was previously defined in
       /Users/tom/.stack/snapshots/x86_64-osx/lts-7.14/8.0.1/lib/x86_64-osx-ghc-8.0.1/hlibsass-0.1.5.0-A2JAkaXM35zEGvz8eJSuVp/libsass.a(ast.o)
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc: Could not on-demand load symbol '__ZN4Sass8Argument4hashEv'

    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       __ZN4Sass8Argument4hashEv
    whilst processing object file
       /Users/tom/.stack/snapshots/x86_64-osx/lts-7.14/8.0.1/lib/x86_64-osx-ghc-8.0.1/hlibsass-0.1.5.0-A2JAkaXM35zEGvz8eJSuVp/libsass.a
    The symbol was previously defined in
       /Users/tom/.stack/snapshots/x86_64-osx/lts-7.14/8.0.1/lib/x86_64-osx-ghc-8.0.1/hlibsass-0.1.5.0-A2JAkaXM35zEGvz8eJSuVp/libsass.a(bind.o)
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.

There are a couple more similar symbol errors below, but you get the idea. Thanks in advance for any help!

Citing from http://hydra.cryp.to/build/915696/nixlog/1/raw:

Running 1 test suites...
Test suite tests: RUNNING...

Libsass
  should correctly compile simple expression
  should report correct version FAILED [1]
  should support quoted strings

Failures:

  1) Libsass should report correct version
       expected: "3.2.4-18-g3672"
        but got: "[NA]"

Randomized with seed 1272682604

Finished in 0.0057 seconds
3 examples, 1 failure
Test suite tests: FAIL

The functions peekCString etc. used for communication with libsass determine the encoding used in the c string from the environment's locale settings. This is similar to what beware of readFile warns of, but I think it's especially applicable here because we know that libsass accepts and produces only UTF-8. Locale settings should not be relevant.

I discovered this by using Stack's Nix integration, which clobbers most environment variables. As an example, if you use hsass in an environment where LC_CTYPE=POSIX, non-ASCII characters get dropped.

It should be possible to replace peekCString etc. with the corresponding functions from GHC.IO, which would allow for specifying the encoding. One tricky issue is what to do with filepaths, since I suppose their encoding should be determined by the environment. There is getFilesystemEncoding — which comes with a warning that it shouldn't be used on Windows — but without a better understanding and a reproducible test case I'm inclined to leave filepaths alone.