Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 22 2019 16:30
    jcchalte commented #567
  • Jan 15 2019 14:44
    Tigraine commented #564
  • Jan 15 2019 13:45
    CZEMacLeod commented #564
  • Jan 15 2019 11:23
    twenzel commented #564
  • Jan 15 2019 09:32
    Tigraine closed #564
  • Jan 15 2019 09:32
    Tigraine commented #564
  • Dec 28 2018 00:28
  • Dec 19 2018 18:19
    petersmm commented #548
  • Nov 27 2018 08:07

    twenzel on master

    Fix typo in description (compare)

  • Nov 26 2018 11:27

    twenzel on master

    Updated Nuget key (compare)

  • Nov 23 2018 15:38
  • Nov 16 2018 16:56
    rcollette commented #283
  • Nov 12 2018 20:00
    CZEMacLeod commented #283
  • Nov 10 2018 05:12
    rcollette closed #283
  • Nov 04 2018 08:28
  • Oct 30 2018 20:30
    petersmm commented #548
  • Oct 30 2018 20:30
    petersmm commented #548
  • Oct 30 2018 07:56
    twirpx opened #567
  • Oct 24 2018 21:09
    twenzel commented #524
Lauri Kotilainen
@rytmis
For 2.0, I'm thinking about doing a bunch of API reworking.
First, I'd love to get rid of the Expand<Foo> calls by making the Evaluate method return an IEnumerable<Node> and treating the results accordingly.
Second, I think the evaluation stack needs to be re-thought a little bit.
Lauri Kotilainen
@rytmis
Well, now. I reworked the API so that every Evaluate call returns an IEnumerable<Node>. While working through that change, I also eliminated a bunch of weirdness regarding e.g. mixin guards -- now, when a guarded call results in nothing, it no longer produces a spurious empty line.
Lauri Kotilainen
@rytmis
I really dislike the fact that e.g. Ruleset has a lot of conditionals based on the type of the node being evaluated. That stinks.
Ideally, the Node itself should know how to evaluate itself given the current environment.
Lauri Kotilainen
@rytmis
Extend in particular is implemented in a really incongruous way.
Lauri Kotilainen
@rytmis
These weird corner cases keep tripping me up. Ideally, Ruleset.Evaluate should be "return new Ruleset(Selectors, new NodeList(Rules.SelectMany(r => r.Evaluate(env))));", but there's a lot of historical cruft that needs to be sorted out before that can happen.
Lauri Kotilainen
@rytmis
Variable evaluation in particular is tricky. I'm working towards a world where variable definitions are evaluated as the first pass of evaluating a ruleset, and evaluating the value stores it in the current env.
That way, lookups should become noticeably cheaper, and eventually I hope to get rid of Env.Frames entirely.
Lauri Kotilainen
@rytmis
Have I mentioned how much I dislike the regex-based parser already? Having semicolon-separated argument lists in mixin calls is really hard to get right. I spent about an hour on Friday cooking up a regex that would reliably let me detect them. It worked -- except in one case, where the tokenizer has helpfully already recognized the first argument as a quoted string, and hence only matches against that string so it's difficult if not impossible to work with the surrounding context.
Daniel Hoelbling-Inzko
@Tigraine
@rytmis Should I merge this? dotless/dotless#484
Lauri Kotilainen
@rytmis
Yes, if it looks good. Merge it to develop instead of master.
Lauri Kotilainen
@rytmis
Ping @Tigraine
See above :)
Lauri Kotilainen
@rytmis
Oh boy. I done made a bad when I made selectors more flexible.
There's been a nasty threading bug since 1.5.0. :(
It should have been obvious to me, given that I know the parser is stateful. But noooooo.
And it doesn't help that I've let the issue lie unfixed for several months after the first report. In my defense though, I bought a house and have been renovating it. :P
Booster2ooo
@Booster2ooo
Hello there !
I've got a little question, I don't think it's covered by the doc (I don't even know if it's implemented yet): I'm looking to build a mixin where you can pass @property-name and @property-value ( @{property-name}: @{property-value}; ) such as explained in this less.js thread: less/less.js#36
It seems to work when I prefix the property-name variable but not when a line starts with @
Am I doing something wrong ? Is there a proper way to achieve this ? Should I open an issue ticket ?
dimtabu
@taburetkin
just interesting
anybody home? :)
Daniel Hoelbling-Inzko
@Tigraine
@taburetkin hi :)
dimtabu
@taburetkin
wow!
can`t find any news about this project
is it alive?
Lauri Kotilainen
@rytmis
Hello
I try to fix bugs every now and then, but my motivation for that is not very high at the moment -- the reason being that parts of the dotless codebase are hard to work with, and for newer projects, using less.js directly is fairly straightforward.
Lauri Kotilainen
@rytmis
The Regex-based parser is a bit of a pain in my opinion -- adding support for complex constructs is a lot more difficult than it would need to be. I'm sort of tinkering with a potential replacement, but it's still a long way from being complete. It's an ANTLR4 grammar based parser, with an evaluation pipeline that tries very hard to be more straightforward than some of the hairier parts of dotless.
dimtabu
@taburetkin
i use dotless in .net mvc projects (SPA and old school mvc)
because its just 2 packages from nuget
with clean lessjs i have to setup prebuild actions but i am too lazy
Lauri Kotilainen
@rytmis
Yeah, I know.
I have a lot of projects like that as well.
dimtabu
@taburetkin
and you don't need to rebuild css after changinr in less because of filecache dependency in bundles
Lauri Kotilainen
@rytmis
Which is part of the reason I'm still tinkering. :)
dimtabu
@taburetkin
few days ago i wrote SmartLessBundle
i have to
Lauri Kotilainen
@rytmis
But yeah, the compilation step in 1.5 is really slow these days. It's kinda my fault, but fixing it within the current dotless codebase is a decidedly non-trivial task.
And I'd love to support detached rulesets and whatnot, but while not impossible, it's tedious to make work with the current parser.
dimtabu
@taburetkin
can i ask something about bundle compilation process?
Lauri Kotilainen
@rytmis
Of course -- I won't guarantee that I can answer, though.
dimtabu
@taburetkin

ok. today i have to organize my less files like this

//main.less file
@import "one-cool-stuff.less";
@import "another-cool-stuff.less";
@import ....

and my bundle definition looks like

            bundles.Add(new LessBundle("~/bndls/css/").Include(
                      "~/Content/less/main.less"
                      ));

thats only the way if i want share variables and mixins in this separated less files
is this correct?

Lauri Kotilainen
@rytmis
Wee-ell... sorta. I don't remember the specifics of the LessBundle implementation, but if it evaluates each file separately, then yeah, that's about the extent of it.
dimtabu
@taburetkin
few days ago i look at the source and yes, it is
Lauri Kotilainen
@rytmis
I mean, of course you can also import the vars and mixins in each separate file and then include those files in the bundle (so no single entry point), but that's just more verbose.
Of course, that does have the benefit of supporting tooling better (for autocompletes and such).
dimtabu
@taburetkin
thats why i created SmartLEssBundle
Lauri Kotilainen
@rytmis
What does that do, then?
dimtabu
@taburetkin
you know there is bem methodology in development
Lauri Kotilainen
@rytmis
Sure, yeah.