[WIP] add some junk #24400

Sacha0 · 2017-10-29T23:57:14Z

Per triage, base needs more junk. This pull request adds some junk. Specifically, this pull request explores #11557 (comment) / #16029 (comment) by replacing the existing primitive Array constructors with junk equivalents, e.g. Array{T,N}(d::Vararg{Int,N}) -> Array{T,N}(junk, d::Vararg{Int,N}), and reimplementing the existing constructors in terms of those junk equivalents. The next step would be deprecating the existing constructors in favor of those junk equivalents. Best!

kmsquire · 2017-10-30T02:54:31Z

Despite triage liking this, and despite the name being somewhat descriptive of what's actually in the array, I'm not a huge fan of the word `junk` here. Were any other terms discussed? (I don't actually have any better ideas...)

…

On Sun, Oct 29, 2017 at 4:57 PM, Sacha Verweij ***@***.***> wrote: Per triage, base needs more junk. This pull request adds some junk. Specifically, this pull request explores #11557 (comment) <#11557 (comment)> by replacing the existing primitive Array constructors with junk equivalents, e.g. Array{T,N}(d::Vararg{Int,N}) -> Array{T,N}(junk, d::Vararg{Int,N}), and reimplementing the existing constructors in terms of those junk equivalents. The next step would be deprecating the existing constructors in favor of those junk equivalents. Best! ------------------------------ You can view, comment on, or merge this pull request online at: #24400 Commit Summary - Replace primitive Array{...}(dims...) constructors with Array{...}(junk, dims...). File Changes - *M* base/boot.jl <https://github.com/JuliaLang/julia/pull/24400/files#diff-0> (53) - *M* base/sysimg.jl <https://github.com/JuliaLang/julia/pull/24400/files#diff-1> (32) Patch Links: - https://github.com/JuliaLang/julia/pull/24400.patch - https://github.com/JuliaLang/julia/pull/24400.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24400>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANoEgX2IhC3jQsRLO_pKFYkl8_5QQUWks5sxRDbgaJpZM4QKiMJ> .

Sacha0 · 2017-10-30T03:36:58Z

Despite triage liking this, and despite the name being somewhat descriptive of what's actually in the array, I'm not a huge fan of the word junk here. Were any other terms discussed? (I don't actually have any better ideas...)

Alas I do not recall whether and if so what other possibilities were discussed. Descriptiveness was the primary argument in favor of junk IIRC. And possibly precedent.

Having wrung an adequate volume of groanworthy humor from the name, I have no further attachment to it :). Best!

Sacha0 · 2017-10-30T03:43:43Z

Reducing the CI failure to the following test provided a good laugh:

# issue #14878
mutable struct A14878
    ext
end
A14878() = A14878(Dict())
mutable struct B14878
end
B14878(ng) = B14878()
function trigger14878()
    w = A14878()
    w.ext[:14878] = B14878(junk)  # junk not defined!
    return w
end
@test_throws UndefVarError trigger14878()

Someone (quite reasonably) did not anticipate introduction of the name junk to the language 😄.

…nk, dims...).

JeffBezanson · 2017-10-30T05:00:59Z

junk would be the short and cute choice; the dry and businesslike choice would probably be uninitialized.

Sacha0 · 2017-10-30T17:05:06Z

uninitialized is wonderfully descriptive, if verbose. I recalled another possibility suggested (by Jeff?) during triage: blank. empty might also work, though both blank and empty are less descriptive than uninitialized and junk. Others? Best!

Sacha0 · 2017-11-02T19:57:16Z

Triage would like a better sense of the scope of objection to junk. Thumbs up, thumbs down? :)

(Edit by Stefan:) To clarify: thumbs up is "yeah, I like junk"; thumbs down is "no, I do not like junk".

martinholters · 2017-11-03T14:57:51Z

I have no opinion pro or contra junk, but blank and empty sound like there some specific initialization going on, which at least for isbits element types is not the case, so 👎 from me to those two.

StefanKarpinski · 2017-11-09T20:21:06Z

The current candidates seem to be uninitialized and junk. Here's a pro-junk argument (or an anti-uninitialized argument, depending on how you look at it): we probably want a mode, e.g. for testing, where junk gives you arrays that are actively filled with random values, rather than the array actually being uninitialized; in that case the name uninitialized would actively be wrong, whereas junk remains completely accurate – it's just a question of how much effort you put into generating junk.

Everyone on the triage call is pro-junk or as Jeff said, "I'm not a junk hater". The vote is currently tied 5 to 5. It would be helpful if the junk haters could explain what their objection to the name is.

KristofferC · 2017-11-09T20:24:43Z

I don't think having a debug possibility of filling uninitialized memory with a known pattern should influence the naming.

StefanKarpinski · 2017-11-09T20:44:38Z

It doesn't influence the naming so much as it highlights the nature of the operation. It doesn't actually mean "give me an uninitialized array" – it means "give me an array full of junk".

vchuravy · 2017-11-09T21:03:35Z

But the point is I don't actually want junk, I just don't care what is currently in the array and whatever it is I am fine with that. So if uninitialized is to long (a feature in my opinion), I would propose a third option `whatever, highlighting the fact that the runtime can give me whatever, junk, random, zeros..., whatever is fastest I want that. For NUMA aware programming I particularly don't want the memory to be touched before I do something to it.

…

On Thu, 9 Nov 2017 at 15:44 Stefan Karpinski ***@***.***> wrote: It doesn't influence the naming, so much as it highlights the nature of the operation. It doesn't actually *mean* "give me an uninitialized array" – it means "give me an array full of junk". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24400 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI3atKq2UNtvzPrYl0xd-x79RbbrkHiks5s02Q3gaJpZM4QKiMJ> .

iamed2 · 2017-11-10T03:23:41Z

whatever (maybe anything?) sounds more descriptive than junk to me. It took me a minute or two to figure out what was going on from the code. Perhaps because junk is not as common a word, so I assumed it had some special domain-specific meaning here.

At the same time, a comment in each file where junk is used could have cleared that up.

Sacha0 · 2017-11-10T21:34:18Z

I appreciate the argument for anything/whatever, and favor anything between those two. any seems like a reasonable, concise choice as well. (Given the constructor context in which any would appear, collision with the any function might be fine.) That said, junk doesn't imply "random" per se, and so can be understood as anything as well. Best!

StefanKarpinski · 2017-11-10T21:39:32Z

If we're not going to do junk I think that uninitialized is the best option.

nalimilan · 2017-11-11T15:30:05Z

uninitialized sounds good. Maybe also blank or unfilled (as opposed to fill)?

StefanKarpinski · 2017-11-16T20:03:20Z

Despite the anti-junk contingent taking the lead early on in this nail-biting vote, team junk seems to have pulled ahead with 9 versus 7. So let's go with junk.

StefanKarpinski · 2017-11-16T20:08:31Z

@malmaud has made the case that uninitialized has "more dignity" and @JeffBezanson noted that this will be all over our standard library code. The collective feeling is that the anti-junkers have a strong feeling of antipathy towards "junk" while the pro-junkers are at best, mildly amused by the word. So team junk concedes the fight and we can go with uninitialized – for dignity.

StefanKarpinski · 2017-11-16T20:12:36Z

Actual pro-uninitialized argument: a = uninitialized(T, m, n) is pretty much self-explanatory while a = junk(T, m, n) could be a head-scratcher until someone explains to you that it gives you an array with uninitialized memory.

kmsquire · 2017-11-16T22:07:12Z

As with most things Julia, I don't always agree with the decisions, but I'm very happy that the language exists and that people are both cordial and sometimes humorous in their responses. I'm happy with the decision here, and also would have been fine if it had gone the other way. Thanks for the discussion!

rfourquet · 2017-11-17T03:43:31Z

Also uninitialized seems more descriptive of what is requested (the intent), i.e. not spending resources on initialization (Which will happen manually in a subsequent step) rather than actively wanting junk (the side effect).

Sacha0 · 2017-11-21T04:42:17Z

Closing in favor of #24652. Thanks all!

Sacha0 added arrays [a, r, r, a, y, s] triage This should be discussed on a triage call labels Oct 29, 2017

Replace primitive Array{...}(dims...) constructors with Array{...}(ju…

0745434

…nk, dims...).

Sacha0 force-pushed the morejunk branch from df7d352 to 0745434 Compare October 30, 2017 03:45

Sacha0 mentioned this pull request Nov 13, 2017

design of array constructors #24595

Open

StefanKarpinski removed the triage This should be discussed on a triage call label Nov 16, 2017

StefanKarpinski added this to the 1.0 milestone Nov 16, 2017

Sacha0 mentioned this pull request Nov 19, 2017

initialize Arrays with great dignity #24652

Merged

Sacha0 closed this Nov 21, 2017

Sacha0 deleted the morejunk branch November 21, 2017 04:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] add some junk #24400

[WIP] add some junk #24400

Sacha0 commented Oct 29, 2017 •

edited

Loading

kmsquire commented Oct 30, 2017 via email

Sacha0 commented Oct 30, 2017 •

edited

Loading

Sacha0 commented Oct 30, 2017

JeffBezanson commented Oct 30, 2017

Sacha0 commented Oct 30, 2017

Sacha0 commented Nov 2, 2017 •

edited

Loading

martinholters commented Nov 3, 2017

StefanKarpinski commented Nov 9, 2017

KristofferC commented Nov 9, 2017

StefanKarpinski commented Nov 9, 2017 •

edited

Loading

vchuravy commented Nov 9, 2017 via email

iamed2 commented Nov 10, 2017

Sacha0 commented Nov 10, 2017

StefanKarpinski commented Nov 10, 2017

nalimilan commented Nov 11, 2017

StefanKarpinski commented Nov 16, 2017

StefanKarpinski commented Nov 16, 2017

StefanKarpinski commented Nov 16, 2017 •

edited

Loading

kmsquire commented Nov 16, 2017

rfourquet commented Nov 17, 2017

Sacha0 commented Nov 21, 2017

[WIP] add some junk #24400

[WIP] add some junk #24400

Conversation

Sacha0 commented Oct 29, 2017 • edited Loading

kmsquire commented Oct 30, 2017 via email

Sacha0 commented Oct 30, 2017 • edited Loading

Sacha0 commented Oct 30, 2017

JeffBezanson commented Oct 30, 2017

Sacha0 commented Oct 30, 2017

Sacha0 commented Nov 2, 2017 • edited Loading

martinholters commented Nov 3, 2017

StefanKarpinski commented Nov 9, 2017

KristofferC commented Nov 9, 2017

StefanKarpinski commented Nov 9, 2017 • edited Loading

vchuravy commented Nov 9, 2017 via email

iamed2 commented Nov 10, 2017

Sacha0 commented Nov 10, 2017

StefanKarpinski commented Nov 10, 2017

nalimilan commented Nov 11, 2017

StefanKarpinski commented Nov 16, 2017

StefanKarpinski commented Nov 16, 2017

StefanKarpinski commented Nov 16, 2017 • edited Loading

kmsquire commented Nov 16, 2017

rfourquet commented Nov 17, 2017

Sacha0 commented Nov 21, 2017

Sacha0 commented Oct 29, 2017 •

edited

Loading

Sacha0 commented Oct 30, 2017 •

edited

Loading

Sacha0 commented Nov 2, 2017 •

edited

Loading

StefanKarpinski commented Nov 9, 2017 •

edited

Loading

StefanKarpinski commented Nov 16, 2017 •

edited

Loading