I'd prefer Make / MakeUnsafe as well.
Regards
Antoine.
Le 11/03/2019 à 15:15, Francois Saint-Jacques a écrit :
> I can settle with Micah's proposal of `MakeValidate`, though I'd prefer
> that Make is safe by default and responsible users use MakeUnsafe :), I'll
> settle with the pragmatic cho
+1 on Make and MakeUnsafe
On Mon, Mar 11, 2019 at 3:15 PM Francois Saint-Jacques <
fsaintjacq...@gmail.com> wrote:
> I can settle with Micah's proposal of `MakeValidate`, though I'd prefer
> that Make is safe by default and responsible users use MakeUnsafe :), I'll
> settle with the pragmatic cho
I can settle with Micah's proposal of `MakeValidate`, though I'd prefer
that Make is safe by default and responsible users use MakeUnsafe :), I'll
settle with the pragmatic choice of backward compatibility.
François
On Sun, Mar 10, 2019 at 5:45 PM Wes McKinney wrote:
> I think having consisten
Thanks, Wes.
"By the way, we need more help with systematic and automated
benchmarking so we can use commit-by-commit numbers to assist in our
decision making."
I can certainly help with that.
Pretty stretched right now, but I will start thinking about it, maybe
adding some design thoughts.
I w
hi Edmon,
Here's an example of a function that does some schema validation:
https://github.com/apache/arrow/blob/master/cpp/src/arrow/table.cc#L450
The issue is less about the magnitude of the cost and more of a
software engineering question about layering of concerns. Consider two
code paths:
Do you guys have an example somewhere of this validated vs. unvalidated
code, and suspected performance impacts, and has anyone benchmarked any of
this?
On Sun, Mar 10, 2019 at 5:45 PM Wes McKinney wrote:
> I think having consistent methods for both validated and unvalidated
> construction is
I think having consistent methods for both validated and unvalidated
construction is a good idea. Being fairly passionate about
microperformance, I don't think we should penalize responsible users
of unsafe/unvalidated APIs (e.g. by taking them away and replacing
them with variants featuring unavoi
I agree there should always be a path to avoid the validation but I think
there should also be an easy way to have validation included and a clear
way to tell the difference. IMO, having strong naming convention so
callers can tell the difference, and code reviewers can focus more on less
safe met
hi folks,
I think some issues are being conflated here, so let me try to dig
through them. Let's first look at the two cited bugs that were fixed,
if I have this right:
* ARROW-4766: root cause dereferencing a null pointer
* ARROW-4774: root cause unsanitized Python user input
None of the 4 reme
HI François,
This sounds great. I would hope that as part of this we document the
invariants (and possible sharp edges like zero length/all null and no null
Arrays).
Is your intent to allow languages binding to the C++ library go through the
new API or will they still be able to use the "dangerou
Greetings,
I noted that the current C++ API permits constructing core objects breaking
said classes invariants. The following recent issues were affected by this:
- ARROW-4766: segfault due to invalid ArrayData with nullptr buffer
- ARROW-4774: segfault due to invalid Table with columns of differ
11 matches
Mail list logo
