-
-
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
naming of takebuf_string #8575
Comments
Shouldn't the routine be called |
well now, that sent me down quite a rabbit hole of trying to make sphinx work for everyone: 10b64dd |
Yikes, that was some herculean effort you put in there. I was just going to bundle Python with Julia. |
now that would have been an insane rabbit hole. virtualenv made the whole thing quite easy |
Is it time to remove helpdb.jl from the repository yet? (#2501) |
makes sense to me -- just need to check that this actually works everywhere (esp. msys / msvc) |
Worked for me and I've always had one of the setups with extra new lines. |
Unfortunately installing a virtualenv to use sphinx 1.1.3 can only be a stopgap measure; there are additional bugs in the rendering of helpdb.jl like #8276 which have been fixed upstream. |
This is getting way off topic, but only part of the purpose of using virtualenv was to install 1.1.3. I had that working locally without this. Instead, this makes it super easy to give everyone the same, reproducible setup. We could also change it so that everyone has the extra line. |
How about take!(::Type{Array},io) = ...
take!(::Type{String},io) = ... with the right first arg of course (using a parameter perhaps). |
I just spent quite a long time figuring out a bug caused by the fact that
takebuf_array
resets the IOBuffer if it is writeable. This isn't documented in the help string, and I think it would be more consistent with other "dangerous" operators to add a!
to the name (so people think to look for mutation as the source of problems).Also – this seems like a big change in behaviour for such a subtle change in the object (it's not obvious to me that
IOBuffer("...")
andprint(IOBuffer(), "...")
should have different semantics). It might be nice to split intotakebuf_string
andtakebuf_string!
to avoid that.The text was updated successfully, but these errors were encountered: