-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Conversation
Looks like i got some eslint errors, will circle back shortly and fix. |
668499e
to
fb79165
Compare
Looks good to me, only need to wade through white space changes.... |
sorry about that, I can likely split the whitespace stuff into a separate commit tonight if you need. |
FYI the |
Thanks @stefanpenner, this all looks great to me. I'll investigate what's up with CI, it failure looks to be transient. |
I see. We test against latest which has since been updates to Node 9 before we were ready. We're definitely open to talking more about the binding code. Most of it predates myself, and possibly all the active currently team. You can join our Slack to chat (timezones permitting). |
* boolean * function-bridge * map * string
Nan::ObjectWrap Docs: https://github.com/nodejs/nan/blob/master/doc/object_wrappers.md#api_nan_object_wrap Prior to this, all wrapper Objects would never be deleted, allowing memory to grow unbounded. Example: The following, would leak WrapperObjects, and never ``` while (true) { new sass.types.String(‘I LEAK’); } ```
rebased \w node 9 appveyor fix... let's see if CI agrees 🤞 |
@xzyfer if this is green, do you think we can get a release out soon? If I can help at all with that, please don't hesitate to reach out. |
We'll have to rebuild our binaries once this is merged which can take a
while. We'll do a release with node 9 support first because that only
requires building a binary for one version of node. This will fast follow.
…On 3 Nov. 2017 7:39 am, "Stefan Penner" ***@***.***> wrote:
@xzyfer <https://github.com/xzyfer> if this is green, do you think we can
get a release out soon? If I can help at all with that, please don't
hesitate to reach out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2128 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWEs817uMjAPEEvvKaWAK7dl-2wJ8ks5syihqgaJpZM4QNMa1>
.
|
@xzyfer can you guestimate an ETA (1 day, after the weekend, 1 week, 1 month etc). I have to coordinate some stuff on my end of the world if this is a ways out yet. Knowing the above would help me plan :) 🍻 |
Either in the next 12hrs or when I get back from holidays in a week.
…On 3 Nov. 2017 8:19 am, "Stefan Penner" ***@***.***> wrote:
@xzyfer <https://github.com/xzyfer> can you guestimate an ETA (1 day,
after the weekend, 1 week, 1 month etc). I have to coordinate some stuff on
my end of the world if this is a ways out yet. This would help me out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2128 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWEOKK1qswADizhA-8aD1Pnl92m6lks5syjHQgaJpZM4QNMa1>
.
|
@xzyfer awesome, thanks for the heads-up! |
its green! |
Sass_Value* x = static_cast<Sass_Value*>(value); | ||
SassTypes::Value* y = SassTypes::Factory::create(x); | ||
|
||
argv.push_back(y->get_js_object()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this only cosmetic change or is there some deeper reason behind it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cosmetic
Merged with 734c7c8, thank you very much! |
I agree with @nschonni. I'm also away atm so we can't build the new binaries. |
Temporarily reopened |
Shall we cut v4.6.1 now with #2147 ? |
I have some questions about #2147. I'm not sure it's ready. |
Sorry for the error on my part, but I think #2147 is good to go now. (also sorry, I'm in Europe, so we aren't in front of our screens at the same time!) |
Some of us are in Europe, too :) thanks |
Just sharing some positive test results: We have been running with ^ for a few days now, Thousands of builds, across various node versions and MacOS Sierra, RHEL 6, RHEL 7. No issues and just (as predicted) a nice drop in RAM usage. We have seen as much as 22gb reduction in memory usage... |
I'm aiming to land this in the next 48hrs.
I'm actually hanging out with Chris this weekend. He says you have ideas
on how to improve the binding layer. Feel free to join us our slack to
discuss further. There's a slack badge in the read me.
…On 11 Nov. 2017 3:22 am, "Stefan Penner" ***@***.***> wrote:
Just sharing some positive test results:
We have been running with ^ for a few days now, Thousands of builds,
across various node versions and MacOS Sierra, RHEL 6, RHEL 7. No issues
and just (as predicted) a nice drop in RAM usage. We have seen as much as
22gb reduction in memory usage...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2128 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWPIUet53Q2EuOcoa0geNzbfVKdIRks5s1HhcgaJpZM4QNMa1>
.
|
Since we need to rebuild binaries for this I'm also going to bump libsass to that latest 3.5 release to fix a couple other outstanding issues. |
Great. TIL: using |
Cool! I'll tag a new libsass release in the next 24hrs. We'll jump straight
to that version.
…On 12 Nov. 2017 10:40 am, "Marcin Cieślak" ***@***.***> wrote:
Great. TIL: using git commit ----cleanup=whitespace to add release notes
in Markdown to the release commit
<6b7b679>
- this will be picked up
<https://github.com/sass/node-sass/blob/6b7b67901bc7c1f803073089ad93b95ec5fc61d4/appveyor.yml#L80>
by @appveyor <https://github.com/appveyor> and added to the release tag
on GitHub.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2128 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWPmphJiv-mgA4ZRQrjB4Zh8oxrH3ks5s1jBOgaJpZM4QNMa1>
.
|
[FIXES #2098]
We noticed our ember-cli builds for linkedin.com were consuming ~10gb of memory, after some investigation node-sass (via eyeglass) was identified as the primary culprit. With this PR, memory usage dropped by from ~10gb -> ~1gb (saving about 9gb of ram)
NOTE: This does not fix all the leaks, more PR's to come
Fixes so far:
create_string
must be paired with a free (this catches a few of the easy ones)sass_make_number
copies the unit)sass_make_string
also copies the string)ExtractOptions
function signature (sass_make_function
copies thesignature
)SassTypes::Value
are now subclasses ofNan::ObjectWrap
, and we utilize its machinery for memory management. This ensures our wrapper objects no longer leak Nan::ObjectWrap docsTests:
sass.types.*
Notes:
I realize this PR is quite large, the only drastic change was utilizing Nan::ObjectWrap memory management machinery. The rest is a mixture of tests, and cleanup to simplify the memory issues.
I look forward to you code reviews!