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
It's very raw at the moment, and it's proably not very performant because I use generated enumerators everywhere
andersnm
@andersnm
ah sweet
Lauri Kotilainen
@rytmis
My aim was to have a sane, uniform API and evaluation model, and in particular to reduce the need for evaluating selectors again and again everywhere
andersnm
@andersnm
Looks clean
Lauri Kotilainen
@rytmis
Although I did intentionally make it less powerful than dotless in one regard: in dotless, when generating dynamic selectors, I re-parse the generated CSS to be able to invoke them as mixins. But that doesn't really make sense for things like .foo ~".bar .baz" -- you wouldn't actually expect that to be invokable as less, yet in dotless 1.5 it is. I did it back then because it was the only simple way to make generated selectors to work at all.
I mean, the case I had in mind when doing that was actually extending Bootstrap's generated column classes. But you couldn't do that, because they were generated, so the extenders never matched during the evaluation phase.
andersnm
@andersnm
How does antlr work, does it run as a tool at compile time, or do you need the dependency on runtime too?
Lauri Kotilainen
@rytmis
A bit of both.
At compile-time, it generates the lexer and parser. At runtime, it does have a runtime support library. I expect it's due to having to support things like generating sane errors and so on -- I dunno.
Anyway, back to selectors: in my new parser/evaluator, you can invoke generated selectors as long as the generated selector bits make sense. So if you have a quoted thing like ~".foo .bar", you won't match it with ":extend(.foo .bar)" but if you have .foo-@{bar} and bar is, say, 42, you will be able to :extend(.foo-42).
Lauri Kotilainen
@rytmis
Eventually I'm hoping to get to the point where I already have feature parity with dotless' compiler, after which I can focus on getting the performance to a more sane level. I know from profiling the dotless implementation that selector generation is a big part of the problem. Output is likely another, what with the continuous allocation of StringBuilders...
andersnm
@andersnm
Ah, I see. Sounds tricky =)
Lauri Kotilainen
@rytmis
If you mean the selectors, then sorta. IIRC less.js doesn't yet even try to do that.
The biggest issue here is that I get bored with side projects so easily. I then end up abandoning them for months on end.
andersnm
@andersnm
Yes, meant the selectors
me too!
Lauri Kotilainen
@rytmis
That's one of the reasons I started out with lesson.net instead of just fixing Dotless. The latter just didn't inspire me at the time. :(
Luckily I've gotten past that problem at work, at least. Ten years ago, I'd sometimes spend two weeks at work mostly staring at the screen, and then finally in a panic squeeze everything together. These days, my work output is far more predictable. :D
andersnm
@andersnm
lol
Lauri Kotilainen
@rytmis
So, anything interesting going on at work?
andersnm
@andersnm
Typing up a spec for a potential new project for a client. It's for a new feature in a legacy app my team maintains, so I'd say it qualifies as "not interesting" ;)
Lauri Kotilainen
@rytmis
I dunno. I've always found legacy work very interesting, given the liberty to actually do something meaningful.

Then again, I've got this one POS where the only interesting work was migrating an ancient VB.NET web Web Forms site to a C#/VB.NET combo MVC app -- so as to provide an incremental migration path -- and recently all they want from me is minor tweaks here and there. Which is all well and good, except it's grunt work.

And I don't mind grunt work! It's fine, really. The problem is, there are other projects and other customers that need me for enabling work -- something that's a force multiplier for the whole team. So facing those choices, the grunt work seems a bit depressing, especially since there's no clear path towards a brighter future for that particular feature.

POS is not point of sale in this context, btw. :P
andersnm
@andersnm
netstandard2 / netcore 2 is out now
guess dotless clientonly should work well on netstandard2
Toni Wenzel
@twenzel
Hi @andersnm , the current master branch is ready for netstandard2 . Stay tuned, a new nuget package will be out soon.
Daniel Hoelbling-Inzko
@Tigraine
@twenzel Do you need me help in releasing the nuget packages?
I can add you to the nuget package maintainers so you can release it youself
andersnm
@andersnm
looking forward to it!
btw develop and master branches are out of sync
Daniel Hoelbling-Inzko
@Tigraine
yes - @twenzel based his PR on the master branch..
Toni Wenzel
@twenzel
Will update the dev branch soon.
@Tigraine Yes I need help releasing the nuget packages. At the moment I have to access (or link) to the appveyor project in order to view the build output. Does the build succeed?
Daniel Hoelbling-Inzko
@Tigraine
@twenzel When did we switch to a Appveyor build? ;)
I usually ran the build locally on my machine using the psake script
@twenzel Btw thanks so much for helping out with the project - you might have seen I gave you commit access to the repo.
Welcome to the team :) :clap:
Toni Wenzel
@twenzel
@Tigraine I thought you're using Appveyor because of the appveyor.yml and its nuget api key. Should be switch to Appveyor. (It's free for OpenSource projects)
Daniel Hoelbling-Inzko
@Tigraine
Maybe @rytmis added appveyor :D
Lauri Kotilainen
@rytmis
I did!
The notion of having to publish manually didn't appeal to me.
Ah, right. Now I remember. The Appveyor account is my own, and it's linked to my fork.
There, it's building now, @twenzel
Lauri Kotilainen
@rytmis
Team Dotless should now also have access to https://ci.appveyor.com/project/rytmis/dotless/ -- but if someone wants to register a dotless account in AppVeyor, I think you can fairly easily just use the appveyor.yml I created way back when, and run with that.
So yeah, builds from Master trigger a publish, but it only succeeds if the latest reachable tag is of a version that has not yet been published. So the way to publish a new Nuget is to merge to master, then tag that with the appropriate version spec (e.g. 1.6.0-beta01), and if it's a heretofore unknown version, the build will push it to nuget.org.
Lauri Kotilainen
@rytmis
Build failed, but if you're targeting netstandard now, it's probably because the build agent was VS2015. Imma try changing to VS2017
Lauri Kotilainen
@rytmis
I'd investigate, but it appears that I'm having connectivity issues with Github. :/
Toni Wenzel
@twenzel
@rytmis to create a team/organisation account in appveyor they need an email.
either we create a new mail account (or use any existing) and create an appveyor account. Or we use the appveyor project from @rytmis (when it's possible to target to another github repository). Or I'm creating a new appveyor project.