www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DerelictSASS

reply "Lodin" <lodin forum.dlang.org> writes:
Hello,

I've made a smaill binding to libsass - a C/C++ implementation of
popular CSS preprocessor SASS. Binding is dynamic and based on
Derelict Project.

You can find it here: https://github.com/Lodin/DerelictSASS

It is my first attempt to make something like this, so if I did
something wrong, please tell.
Nov 22 2014
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Saturday, 22 November 2014 at 12:32:50 UTC, Lodin wrote:

 Hello,

 I've made a smaill binding to libsass - a C/C++ implementation 
 of
 popular CSS preprocessor SASS. Binding is dynamic and based on
 Derelict Project.

 You can find it here: https://github.com/Lodin/DerelictSASS

 It is my first attempt to make something like this, so if I did
 something wrong, please tell.


Nothing bad jumps out on a cursory look. However, I do recommend
you combine all the files into one -- sass.d. When I first
started Derelict, I separated everything out into multiple
modules for every binding. Over time, I found it makes
maintenance easier to implement a binding in one module if it is
feasible. For large libraries like OpenGL and SDL, it's not going
to help. For something like SASS, with so few functions and
types, it should be the first choice. Granted, the real benefit
probably only shows when maintaining several bindings like I do,
but I still recommend it as I think it also improves readability.
Nov 22 2014
next sibling parent "Lodin" <lodin forum.dlang.org> writes:
On Saturday, 22 November 2014 at 13:15:47 UTC, Mike Parker wrote:

 Nothing bad jumps out on a cursory look. However, I do recommend
 you combine all the files into one -- sass.d. When I first
 started Derelict, I separated everything out into multiple
 modules for every binding. Over time, I found it makes
 maintenance easier to implement a binding in one module if it is
 feasible. For large libraries like OpenGL and SDL, it's not 
 going
 to help. For something like SASS, with so few functions and
 types, it should be the first choice. Granted, the real benefit
 probably only shows when maintaining several bindings like I do,
 but I still recommend it as I think it also improves 
 readability.


Thank you. I've combined it, and it really looks simpler now.
Nov 22 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
A tip to keep in mind when translating C/C++ headers:

---
enum Sass_Tag {
     SASS_BOOLEAN,
     SASS_NUMBER,
     SASS_COLOR
};
---

is best translated as

---

alias Sass_Tag = int;
enum : Sass_Tag {
     SASS_BOOLEAN,
     SASS_NUMBER,
     SASS_COLOR
}
---

That way your enum isn't namespaced.



On Saturday, 22 November 2014 at 13:15:47 UTC, Mike Parker wrote:

 However, I do recommend
 you combine all the files into one -- sass.d. When I first
 started Derelict, I separated everything out into multiple
 modules for every binding. Over time, I found it makes
 maintenance easier to implement a binding in one module if it is
 feasible.


Going to keep that in mind.
Nov 22 2014
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 11/23/2014 1:44 AM, ponce wrote:

 A tip to keep in mind when translating C/C++ headers:

 ---
 enum Sass_Tag {
      SASS_BOOLEAN,
      SASS_NUMBER,
      SASS_COLOR
 };
 ---

 is best translated as

 ---

 alias Sass_Tag = int;
 enum : Sass_Tag {
      SASS_BOOLEAN,
      SASS_NUMBER,
      SASS_COLOR
 }
 ---

 That way your enum isn't namespaced.


I completely missed that.

 Lodin The reason ponce suggests this is that when using the binding in 
D, it's a good idea to for it to look as close to the C code as 
possible. That way, existing C code (especially examples from 
documentation and tutorials) can more easily be ported to D. Since C 
enums aren't namespaced, they shouldn't be in the binding, either.

Some people may prefer the bindings to include more D features, but IMO 
if you're going to put something out there for everyone and anyone to 
use, particularly if you want to be consistent with other Derelict 
bindings, it's better to avoid them.
Nov 22 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-23 01:26, Mike Parker wrote:


 Some people may prefer the bindings to include more D features, but IMO
 if you're going to put something out there for everyone and anyone to
 use, particularly if you want to be consistent with other Derelict
 bindings, it's better to avoid them.


For more D features I would add a thin layer on top of the raw bindings. 
Like creating wrappers for functions accepting C strings and have them 
accept D strings instead.

In this particular case I would probably have created the enum as one 
would do in D and the alias the enum members to make them accessible at 
module scope.

-- 
/Jacob Carlborg
Nov 23 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 23 November 2014 at 19:36:16 UTC, Jacob Carlborg wrote:

 On 2014-11-23 01:26, Mike Parker wrote:


 Some people may prefer the bindings to include more D 
 features, but IMO
 if you're going to put something out there for everyone and 
 anyone to
 use, particularly if you want to be consistent with other 
 Derelict
 bindings, it's better to avoid them.


 For more D features I would add a thin layer on top of the raw 
 bindings. Like creating wrappers for functions accepting C 
 strings and have them accept D strings instead.

 In this particular case I would probably have created the enum 
 as one would do in D and the alias the enum members to make 
 them accessible at module scope.


While I like language-friendly wrappers, they do tend to make 
some choices. They require additional documentation since new 
names and usage are introduced.

Sticking to the C API is choice-agnostic, existing documentation 
can be reused.
Nov 23 2014
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 11/24/2014 4:36 AM, Jacob Carlborg wrote:

 For more D features I would add a thin layer on top of the raw bindings.
 Like creating wrappers for functions accepting C strings and have them
 accept D strings instead.


Right, that's how a wrapper should be written. But I don't think it 
should be distributed with the binding.


 In this particular case I would probably have created the enum as one
 would do in D and the alias the enum members to make them accessible at
 module scope.


That's a valid approach, but I made the decision long ago not to do that 
in Derelict.
Nov 23 2014
prev sibling parent reply "Lodin" <lodin forum.dlang.org> writes:
On Sunday, 23 November 2014 at 19:36:16 UTC, Jacob Carlborg wrote:

 For more D features I would add a thin layer on top of the raw 
 bindings. Like creating wrappers for functions accepting C 
 strings and have them accept D strings instead.


Yes, I think, there should be more layers, more D-ish 
constructions, but on top of binding, not inside it. I think, it 
could be more useful for someone who is not satisfied by existing 
wrappers.

On Monday, 24 November 2014 at 00:40:39 UTC, Colden Cullen wrote:

 On Saturday, 22 November 2014 at 12:32:50 UTC, Lodin wrote:

 This looks great! I plan on using it to build a diet plugin, 
 just like Martin's coffee-script plugin[1]. Any chance you 
 could register it on the Dub Registry[2] though? It would make 
 using this a lot easier.

 [1] https://github.com/MartinNowak/diet-coffee
 [2] http://code.dlang.org/


Of course, I want to register it, but I think it should be a part 
of Derelict Project, not unofficial binding. What should I do to 
realize it?

And one thing about the diet plugin. I plan to make thin wrapper 
around binding to simplify using. Something like `sassc` which 
allows using libsass from console with options. Of course, it 
should be useful like a library too. Is the diet plugin a same 
thing? Or should it be the next layer around wrapper?
Nov 24 2014
parent reply "Colden Cullen" <ColdenCullen gmail.com> writes:
On Monday, 24 November 2014 at 17:32:36 UTC, Lodin wrote:

 Of course, I want to register it, but I think it should be a 
 part of Derelict Project, not unofficial binding. What should I 
 do to realize it?

 And one thing about the diet plugin. I plan to make thin 
 wrapper around binding to simplify using. Something like 
 `sassc` which allows using libsass from console with options. 
 Of course, it should be useful like a library too. Is the diet 
 plugin a same thing? Or should it be the next layer around 
 wrapper?


I can't help you with getting it included in Derelict, but I 
think Mike Parker[0] is probably the one to talk to.

I think the diet plugin would serve best as a layer on top of 
your wrapper. It's scope is limited to taking inline sass, as 
well as paths to sass files, compiling them, and including the 
result on the HTML page. If you could make that process easier 
with a wrapper, it would make the plugin much simpler.

[0] https://github.com/aldacron
Nov 24 2014
next sibling parent "Lodin" <lodin forum.dlang.org> writes:
So I did it. Sorry for make you waiting for such a long time.

Short info:
- Git: https://github.com/Lodin/sassed
- Tested on: Ubuntu 14.04, DMD 2.066.1.
- Known bugs: segfault after program ends. It does not happen in 
all cases, and as I know does not affect compilation result. 
Trying to catch it.
- Documentation: DDOC and Git Readme.md

P.S. As before, if I done something wrong (including bad 
interface or not effective code) please tell. I'll be happy to 
learn doing it in the right way.
Jan 21 2015
prev sibling parent "Lodin" <lodin forum.dlang.org> writes:
Major update for DerelictSASS and Sassed due to C API change in 
libsass.

DerelictSASS - v2.0.0
https://github.com/Lodin/DerelictSASS
There are complete interface change: as I know, previous libsass 
C API does not work anymore, and new API was written.

Sassed - v0.2.0
https://github.com/Lodin/sassed
It is updated to new DerelictSASS version and has some new 
features such as sass compile error and success handlers. Also 
segfault bug was fixed.
Jan 29 2015
prev sibling parent "Lodin" <lodin forum.dlang.org> writes:
On Saturday, 22 November 2014 at 16:44:11 UTC, ponce wrote:

 A tip to keep in mind when translating C/C++ headers:

 ---
 enum Sass_Tag {
     SASS_BOOLEAN,
     SASS_NUMBER,
     SASS_COLOR
 };
 ---

 is best translated as

 ---

 alias Sass_Tag = int;
 enum : Sass_Tag {
     SASS_BOOLEAN,
     SASS_NUMBER,
     SASS_COLOR
 }
 ---

 That way your enum isn't namespaced.


 ponce,  Mike Parker, thanks for information. Fixed it.
Nov 23 2014
prev sibling parent "Colden Cullen" <ColdenCullen gmail.com> writes:
On Saturday, 22 November 2014 at 12:32:50 UTC, Lodin wrote:

 Hello,

 I've made a smaill binding to libsass - a C/C++ implementation 
 of
 popular CSS preprocessor SASS. Binding is dynamic and based on
 Derelict Project.

 You can find it here: https://github.com/Lodin/DerelictSASS

 It is my first attempt to make something like this, so if I did
 something wrong, please tell.


This looks great! I plan on using it to build a diet plugin, just 
like Martin's coffee-script plugin[1]. Any chance you could 
register it on the Dub Registry[2] though? It would make using 
this a lot easier.

[1] https://github.com/MartinNowak/diet-coffee
[2] http://code.dlang.org/
Nov 23 2014