-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
upgrade to libuv1.9.0-fork #12266
upgrade to libuv1.9.0-fork #12266
Conversation
@kpamnany Would we get the uv fixes you needed for threading with this update? |
@@ -960,7 +960,9 @@ static void jl_resolve_sysimg_location(JL_IMAGE_SEARCH rel) | |||
if (path_size >= PATH_MAX) { | |||
jl_error("fatal error: jl_options.julia_bin path too long"); | |||
} | |||
jl_options.julia_bin = strdup(free_path); | |||
jl_options.julia_bin = malloc(path_size+1); |
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.
(char*) malloc
Nice work here, didn't notice you went and did this. Still need to eventually figure out how to upstream what we need pipe-wise so we won't always need a fork, but this is a great start. Thread affinity and detach are still open - libuv/libuv#280 |
damn, this isn't starting under mintty at all |
hm, worked for me? |
win10 vs win7? |
If I hit enter a few times, I end up getting this:
|
attaching gdb to julia-debug:
|
Yeah, as @tkelman pointed out, the PR for thread affinity and detach is still open on upstream |
Worth noting, I can reproduce the freeze on this branch using the Windows Server 2012 R2 image from |
Looks like we may need to revert libuv/libuv@1e59ab1. That unfortunately doesn't fix the mintty freeze for me though, so there are probably other changes needed either in libuv or Julia. Ref libuv/libuv#264 |
5ded40d
to
e762b94
Compare
i've bumped this and included a possible fix for the pty detection issue. can you check whether |
No change, still broken in mintty. The test failures are new I think. |
"switch our flag to use enum value 2." JuliaLang/libuv#27 |
e762b94
to
2f41870
Compare
updated to v1.7.5 now |
LIBUV_BRANCH=julia-uv0.11.26 | ||
LIBUV_SHA1=28f5f06b5ff6f010d666ec26552e0badaca5cdcd | ||
LIBUV_BRANCH=julia-v1.7.5 | ||
LIBUV_SHA1=80fe49af0f19f82da811129220c9bdeb13b99ebb |
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.
checksum filename doesnt match sha
Still doesn't start in mintty, though underlying cause might be the same as the test failures?
|
@vtjnash did you have any idea what the problem was? |
2f41870
to
4f153dc
Compare
I've rebased this PR on the current master (with the original commit backed up at yyc/libuv1.6.1-bak) and fixed a few easy failing tests due to rearrangement on master. Apart from the failing tests, the output at the REPL also seems strange. The frist line is aligned with the end of the input line on this branch. julia> []
0-element Array{Any,1}
julia> [[]]
WARNING: [a] concatenation is deprecated; use collect(a) instead
in depwarn at ./deprecated.jl:73
in oldstyle_vcat_warning at ./abstractarray.jl:29
in vect at ./abstractarray.jl:32
in eval at ./boot.jl:265
while loading no file, in expression starting on line 0
0-element Array{Any,1}
julia> println(1)
1 |
@@ -769,6 +769,8 @@ UV_OBJ_TARGET := $(build_libdir)/libuv.la | |||
UV_CFLAGS := | |||
ifeq ($(USEMSVC), 1) | |||
UV_CFLAGS += -DBUILDING_UV_SHARED | |||
else | |||
UV_CFLAGS += -std=gnu99 | |||
endif |
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.
I have a more recent commit on the main branch we use that may make this unnecessary
LIBUV_BRANCH=julia-uv0.11.26 | ||
LIBUV_SHA1=030481e9d659fd46702ab747caf2cbbe19d537ba | ||
LIBUV_BRANCH=julia-v1.7.5 | ||
LIBUV_SHA1=80fe49af0f19f82da811129220c9bdeb13b99ebb |
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.
still does not match checksum file name
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.
Should this be the commit SHA?
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.
Right. But you need to do make NO_GIT=1 -C deps configure-libuv
to generate the right checksums for no-git builds.
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.
Like this?
yuyichao% cat deps/checksums/libuv-80fe49af0f19f82da811129220c9bdeb13b99ebb.tar.gz/md5
8fa6ed4dc950d3f4445a42c4b28724f9
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.
yeah, the sha1 in the checksum filename should match the git commit sha1
4f153dc
to
7de33a6
Compare
The alignment is probably the change to the raw mode to be really unmodifying (previously, we probably set the ONLCR flag to fix \n on output and replace with \r) |
ef48b47
to
0c0b641
Compare
still no dice inside mintty (that why you cancelled?)
|
yeah, git made a rebase error and changed the meaning of one of the libuv commits. it only mattered if you can type faster than the OS can context switch to its thread pool though :P |
Ah, much better now. Basics seem to work so far. Something during (p.s. is any of libuv/libuv#852 relevant for things that are dealt with on our fork?) |
i'm not sure anyone has been giving cmd.exe usage much testing since mintty is so much better, so that issue wouldn't apply |
Only for building and working with source builds. #7267 still had some open issues with BinDeps having trouble, so users of binaries generally use the native console. Windows 10's native console isn't that bad, but we'll need to support Windows 7 for some time. I should probably keep my Windows 7 laptop around and test with it more often. |
like the title says. we've been sitting on libuv-0.11.26 for awhile now, while libuv 1.x has some nice toys (in no particular order):
https://github.com/libuv/libuv/blob/v1.x/ChangeLog
uv_os_homedir
uv_fs_scandir_next
additional work on threading
improved uv_timer_t precision on windows
uv_fileno
uv_fs_mkdtemp
ability to replace the memory allocator
uv_fs_access