-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Branch for 0.2.0 #84
Conversation
But it's not related to node stream. If you set an interval sufficiently low for setInterval, the same thing happen. Meanwhile, I noticed there's a new released version of npm that doesn't support node 4 anymore, so I lowered the version used on AppVeyor to 5.7 |
Did you have that error on Windows as well?
|
examples/event-loop.js
Outdated
@@ -57,7 +57,7 @@ libui.startLoop(); | |||
const linebreak = process.platform === "win32" ? '\r\n' : '\n'; |
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.
We can use require('path').sep
to get the correct line break for the platform.
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.
Yes, but actually, it's require('os').EOL
.
require('path').sep
is slash or backslash for filepaths.
It's also interesting that textarea.getText()
returns the text with "\n" (also on windows), but setText()
requires the platform specific type.
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.
Oh yes, sorry...
It's also interesting that textarea.getText() returns the text with "\n" (also on windows), but setText() requires the platform specific type.
That's strange, we should investigate if it's intentional or not.
Err, I didn't yet configure clang-format on Windows, I just skip the check 🤨 |
event-loop.js with Node 10: Started the server and did
|
This is somehow fixed in the uitimer branch (which uses the libui timer, #92). |
It seems they are using global clearTimeout (that we patched) to cancel a timer not create by our version of setTimeout: We should check other similar usage in node source code to prevent other bugs... |
I thought of a solution for some days, but still now I can think of a valid one. So I'll just for now comment the lines that clean up events callbacks, to avoid the segmentation fault. This cause some memory to leak on every registered callback, but so we can go ahead with 0_2_0 release and work in parallel to other features |
The TypeError there is gone because clearTimeout is implemented in JavaScript without checking the type of the argument. And in that function, you just set a property on the argument, so it work with whatever argument type is passed: Lines 66 to 68 in 136856c
But I guess that the clearTimeout in node |
@mischnic, can you confirm the last commit solve the callback problem on Sierra? My VM stop working for some obscure reason 😢
|
Yes, now I'm get something regarding |
Fine, thank you, that will be fixed in 0_3_0. So I'll go ahead and publish a pre-release version on npm. But first I have to bump some dep version on libui-download in order to solve an issue warning regarding hoek package. |
What about the clearTimeout problem? |
I plan to solve that too in 0_3_0. My last thought (hopes) on regards are that by limiting the time we wait for GUI events in main thread, timers works without patching them. Otherwise, we'll probably need to patch internal node Timeout class, that is the base for all the various timers |
Hey it seems you solved it? This imply that node is passing a null timeout handle to clear? |
This is one half of the fix, the Timeout object still get's through and it still crashes. |
…interval is created by us. If not, calls the original node functions.
With my last commit, we are now checking if the timeout given as argument is an instance of our TimeoutHandle class. If not, it calls the original clearTimeout or clearInterval functions. The crash now does not happens, but there is still some problem to solve, because the timers that node use internally still expires only if there are GUI events (since they are not pached) |
Still now, we have:
Am I forgotting somethings?