Re: DerelictSASS
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.
Re: DerelictSASS
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.
Re: DerelictSASS
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
Re: DerelictSASS
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?
Re: DerelictSASS
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.
Re: DerelictSASS
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/
Re: DerelictSASS
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.
Re: DerelictSASS
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
Re: DerelictSASS
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.
Re: DerelictSASS
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.
Re: DerelictSASS
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.
Re: DerelictSASS
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.
Re: DerelictSASS
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.
DerelictSASS
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.
