Thanks Nathan, 3.0.18 works fine using that option! --bb
On Aug 22, 11:28 pm, Nathan Weizenbaum <[email protected]> wrote: > I've just pushed a change that adds a --stop-on-error flag. It'll probably > go out sometime today as part of Sass 3.0.18. > > > > > > > > On Mon, Aug 16, 2010 at 3:32 AM, bitbowl <[email protected]> wrote: > > I'd say the latter option (not to emit CSS files on an error) is the > > right one (keeping the update-only-if-newer optimization is really > > useful to save cycles on larger trees). I'd assume that option to be a > > default, but if you don't want to change the current mimic, e.g. call > > it "--break-on-errors". > > Unfortunately I am not a ruby guy, so could not help out, sorry. > > > --bb > > > On Aug 16, 10:56 am, Nathan Weizenbaum <[email protected]> wrote: > > > I wouldn't be opposed to adding another flag that either causes --update > > to > > > update all files regardless of whether the CSS is newer than the source > > > (--force? --update-all?), or a flag that causes it not to emit CSS files > > on > > > an error (I'm not sure what this one would be called). Are you > > comfortable > > > enough coding Ruby that you think you could make a patch for that? > > > > On Sun, Aug 15, 2010 at 12:47 PM, bitbowl <[email protected]> wrote: > > > > It's a larger webapp being built by hudson build bots. There are > > > > several people working on the tree and if there's wrong scss, it's > > > > quite handy to immediately get to know of it and what check-in broke > > > > it -- like for any other portions of code, if possible. > > > > > --bb > > > > > On Aug 15, 9:20 pm, Nathan Weizenbaum <[email protected]> wrote: > > > > > Many people completely ignore the output of the compiler itself, and > > only > > > > > look at the page. This is especially true when using --watch, but can > > > > also > > > > > happen with --update (e.g. when it's hooked up to a text editor's > > > > "compile" > > > > > button, or when using something like live-refresh). In this case, > > it's > > > > very > > > > > useful to have error reporting in the webpage that the user is > > viewing. > > > > > > What's your use case for having sass --update be idempotent? > > > > > > On Sun, Aug 15, 2010 at 12:14 PM, bitbowl <[email protected]> wrote: > > > > > > Excuse my ignorance, but what's the benefit of having compilation > > > > > > errors in the generated css? > > > > > > > IMHO idempotent behavior is an essential requirement of compilers > > to > > > > > > assert clean builds. Even if haml/sass have been designed > > differently > > > > > > -- how hard would it be to enforce strict error handling for this > > > > > > great tool? > > > > > > > thanks, > > > > > > --bb > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Haml" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]<haml%[email protected]>< > > haml%[email protected]<haml%[email protected]> > > >. > > > > For more options, visit this group at > > > >http://groups.google.com/group/haml?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Haml" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected] <haml%[email protected]>. > > For more options, visit this group at > >http://groups.google.com/group/haml?hl=en. -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
