Do we support Android on ARMv7 without NEON?
Does the answer differ for our different API level builds?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org
Are there any plans to support Aarch64 as a tier higher than tier-3?
For Android or the upcoming Aarch64 flavor of Windows 10 maybe?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Mon, Jan 23, 2017 at 8:03 PM, Nicholas Alexander
wrote:
> On Mon, Jan 23, 2017 at 9:58 AM, Henri Sivonen wrote:
>>
>> Do we support Android on ARMv7 without NEON?
>
>
> Ralph Giles told me just a few days ago that yes, we support ARMv7 with and
> without NEON.
OK
we
might have higher than tier-3 configs that have NEON available
unconditionally.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
A search like https://searchfox.org/mozilla-central/search?q=EncodingRef
finds a bunch of stuff that is under servo/components/script/. I gather we
don't use that part of Servo in Quantum. Correct? How does one see which
parts of servo/ are actually in use in Quantum? Is there a way to filter
out t
Is there some kind of tool, similar to ./mach clang-format for
whitespace, that changes identifies from C++ standard library style to
Gecko style?
I.e. foo becomes Foo, foo_bar becomes FooBar and arguments and members
get prefixed with a and m respectively?
--
Henri Sivonen
hsivo...@hsivonen.fi
names aren't constrained by standard
interop, should the remaining methods follow Mozilla naming or
standard library naming?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla
On Feb 16, 2017 9:09 PM, "Botond Ballo" wrote:
On Thu, Feb 16, 2017 at 1:05 PM, smaug wrote:
> AFAIK, uncapitalized method names in MFBT are the old style, and new code
> should just
> use Mozilla coding style.
> This was discussed in some other thread in dev.platform, but I can't find
it
> righ
ming for iterator interop and Mozilla naming
for other stuff in the same class.
On Thu, Feb 16, 2017 at 7:24 PM, Henri Sivonen wrote:
> It seems that even size() and empty() should be lower-case if one
> wants a type to quack like a Container:
> http://en.cppreference.com/w/cpp/concept/Con
/ is 404 these days.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tue, Feb 21, 2017 at 12:42 AM, wrote:
> My short (<2yr) experience of the code gave me the impression that only a
> small amount of it has proper doxygen comments.
> We must be frequenting different circles; or I'm somehow blind to them. :-)
I get to look at stuff like:
/**
* Cause
I should follow with encoding_rs?
See also:
https://users.rust-lang.org/t/how-to-retrieve-h-files-from-dependencies-into-top-level-crates-target/9488
(unanswered at the moment)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform
id it that DIST itself isn't being passed to the build.rs
process. Right?)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Fri, Feb 17, 2017 at 8:54 PM, Birunthan Mohanathas
wrote:
> On 16 February 2017 at 13:41, Henri Sivonen wrote:
>> Is there some kind of tool, similar to ./mach clang-format for
>> whitespace, that changes identifies from C++ standard library style to
>> Gecko style?
&g
On Thu, Feb 23, 2017 at 4:37 PM, Ted Mielczarek wrote:
> On Thu, Feb 23, 2017, at 06:40 AM, Emilio Cobos Álvarez wrote:
>> On Thu, Feb 23, 2017 at 08:25:30AM +0200, Henri Sivonen wrote:
>> > On Wed, Feb 22, 2017 at 5:49 PM, Ted Mielczarek
>> > wrote:
>> > &
r adding paths = [ "third-party/rust" ]
to .cargo/config.in don't make Cargo happy.
What's the right way to build with edited crates under
third-party/rust? (I think we should have an easy way to do so.)
--
Henri Sivonen
hsivo
lla.org/show_bug.cgi?id=1342815
Thank you. I think it should be possible to stick a diagnostic
println!() or panic!() in the vendored code with zero or minimal
ceremony.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
.
I take it that I should check in the header, then.
Is there some way to disable build.rs for a vendored crate (without
making cargo unhappy about the hashes)? (If the header is checked in,
compiling cheddar in order to generate it at build time is useless.)
--
Henri Si
On Mon, Feb 27, 2017 at 2:38 PM, Henri Sivonen wrote:
> Is there some way to disable build.rs for a vendored crate (without
> making cargo unhappy about the hashes)? (If the header is checked in,
> compiling cheddar in order to generate it at build time is useless.)
This seems not only
On Mon, Feb 27, 2017 at 7:04 PM, Ralph Giles wrote:
> On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen wrote:
>
>> I find this level of difficulty (self-inflicted quasi-Tivoization
>> practically) an unreasonable impediment to practicing trivial Software
>> Freedom with
On Mon, Feb 27, 2017 at 7:47 PM, Ted Mielczarek wrote:
> On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote:
>> We don't seem to need such change control beyond hg logs for e.g. the
>> in-tree ICU or Skia, though.
>
> As someone who has maintained a vendored upst
encoding_rs" step is done.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
nce to avoid having both in the build. At the moment I’m prioritizing other
> Stylo-related work, but I’m confident it’ll happen before we start shipping
> Stylo.
Nice! Works for me. :-)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
__
On Mon, Feb 27, 2017 at 5:57 PM, Henri Sivonen wrote:
> Maybe having the header generation as part of build.rs is more trouble
> than it's worth in the first place...
Now that the build.rs in commented out in the crates.io crate and the
generated header is shipped in the crat
Do we have a tracking bug for all the stuff that we can and should
remove once we no longer support XPCOM extensions?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd wrote:
> We do not.
OK. I filed one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1347507
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platf
terOutputStream sooner than later and let chrome JS use
TextDecoder like Web JS.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Do we need to keep caring about
https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM
extensions are no more?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
On Thu, Mar 16, 2017 at 7:34 AM, Boris Zbarsky wrote:
> On 3/15/17 5:35 PM, Henri Sivonen wrote:
>>
>> What's the current outlook on letting chrome JS read ArrayBuffers as
>> opposed to JS strings where the high 8 bits are zero and the low 8
>> bits are the byte va
On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione wrote:
> On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote:
>>
>> What's the current outlook on letting chrome JS read ArrayBuffers as
>> opposed to JS strings where the high 8 bits are zero and the low 8
>&g
rejecting non-characters.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
It seems that our Rust bindings for nsresult are part of Stylo, but
Stylo isn't yet a guaranteed part of the build.
Until Stylo becomes a mandatory part of the build, what's the proper
way to return nsresult from Rust such that it works with or without
Stylo enabled?
--
Henri Siv
On Fri, Mar 17, 2017 at 12:12 PM, Anne van Kesteren wrote:
> On Fri, Mar 17, 2017 at 11:00 AM, Henri Sivonen wrote:
>> Our IsUTF8() by default rejects strings that contain code points whose
>> lowest 16 bits are 0xFFFE or 0x.
>>
>> Do we actually have use cases fo
a non-GPL
configuration, could we put C++ glue code in-tree and dlopen libvoikko
if found?
[1] http://voikko.puimula.org/
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.m
On Wed, Mar 22, 2017 at 11:18 AM, Henri Sivonen wrote:
> Without XPCOM extensions, what's the story for out-of-tree spell checkers?
>
> Finnish spell checking in Firefox (and Thunderbird) has so far been
> accomplished using the mozvoikko extension, which implements
> mozISp
On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron
wrote:
> On 03/22/2017 09:18 AM, Henri Sivonen wrote:
>>
>> Without XPCOM extensions, what's the story for out-of-tree spell checkers?
>>
>> […], which implements
>> mozISpellCheckingEngine in JS and connec
On Wed, Mar 22, 2017 at 4:45 PM, Axel Hecht wrote:
> Am 22.03.17 um 15:39 schrieb Jorge Villalobos:
>>
>> On 3/22/17 8:10 AM, Henri Sivonen wrote:
>>>
>>> On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron
>>> wrote:
>>>
e Software alternative, install Ubuntu 16.04.1, stick to 2D
graphics from nouveau with llvmpipe for 3D and be sure never to roll
the HWE stack forward.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platfo
On Fri, Mar 24, 2017 at 2:38 AM, Ehsan Akhgari wrote:
> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar
> wrote:
>>
>> On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen
>> wrote:
>> >
>> > dlopening libvoikko, if installed, and having thin C++ glue co
On Fri, Mar 24, 2017 at 3:20 PM, Ehsan Akhgari wrote:
> On 2017-03-24 4:20 AM, Henri Sivonen wrote:
>> On Fri, Mar 24, 2017 at 2:38 AM, Ehsan Akhgari
>> wrote:
>>> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar
>>> wrote:
>>>>
>>>> On
o/2017-March/000896.html
(Not about anyone writing any code yet.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
't do this or that without additional work
that's already done by Pulse or by cubeb on top of Pulse".
> But maybe pulseaudio makes certain things easier, I don't know.
That PulseAudio makes things easier has been a key point that has been made.
--
Henri Sivon
oduce mozilla::Span when mozilla::Range already exits?
1) Span's storage (pointer and length as opposed to pointer and
pointer) matches Rust's slices without arithmetic, so they
decompose and recompose as the other on the other side of
the FFI without arithmetic.
2) An earlier dev-pl
On Mar 31, 2017 4:49 PM, "Chris Coulson"
wrote:
The Firefox package in Ubuntu is maintained by 1 contributor in his
spare time and myself who is only able to do the minimum in order to
provide updates,
Does today’s announcement of Ubuntu’s change in direction affect resourcing
for Firefox packa
peer.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Sat, Apr 15, 2017 at 8:06 PM, Ehsan Akhgari wrote:
> On 2017-03-27 3:30 AM, Henri Sivonen wrote:
>> 2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there
>> was a crasher bug in the library. (I'd expect the distros to take care
>> of pushing an
On Wed, Apr 19, 2017 at 4:43 AM, Ehsan Akhgari wrote:
> On 2017-04-18 2:38 AM, Henri Sivonen wrote:
>> On Sat, Apr 15, 2017 at 8:06 PM, Ehsan Akhgari
>> wrote:
>>> On 2017-03-27 3:30 AM, Henri Sivonen wrote:
>>>> 2) We couldn't trigger a libvoikko auto
On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey wrote:
> On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen wrote:
>>
>> What problem did you mean to address by code signing?
>
> The reason I suggested code signing is because loading libvoikko would
> provide an easy way f
uch a
method somewhere?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Wed, Apr 26, 2017 at 9:49 PM, Ehsan Akhgari wrote:
> On 04/26/2017 07:02 AM, Henri Sivonen wrote:
>>
>> On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey
>> wrote:
>>>
>>> On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen
>>> wrote:
>>>&g
?id=1360138 .
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
since they were vendored.
Other than manually merging lock files and unstaging unrelated crate
changes, how do I scope the re-vendoring to encoding_rs only?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
de
h vendor rust
Thank you. This works.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1361734 to get mach
vendor to perform those steps.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform
rams) in XPIDL methods that are
exposed to JS, too.
Is it feasible (with reasonably low effort) to introduce a new XPIDL
type that is a pointer to a non-refcounted immutable static object in
C++ and still gets bridged to JS?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
__
On Thu, May 4, 2017 at 10:08 AM, Henri Sivonen wrote:
> Is it feasible (with reasonably low effort) to introduce a new XPIDL
> type that is a pointer to a non-refcounted immutable static object in
> C++ and still gets bridged to JS?
My question was underspecified. At minimum, the JS
On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd wrote:
> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
>> Is it feasible (with reasonably low effort) to introduce a new XPIDL
>> type that is a pointer to a non-refcounted immutable static object in
>> C++ and still gets b
On Thu, May 4, 2017 at 7:39 PM, Nathan Froyd wrote:
> On Thu, May 4, 2017 at 12:32 PM, Henri Sivonen wrote:
>> On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd wrote:
>>> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
>>>> Is it feasible (with reasonably low ef
rloads that deal with encoding names as strings for chrome JS.
After all, Web Platform JS represents encodings as strings, too.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
For example, for encoding_rs, I was
thinking of testing mainly the C++ integration as an
mozilla-central-specific gtest and leaving the testing of the crate
internals to the crate's standalone "cargo test".
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
hen one is logically
thinking of passing a pointer still, but then, again, &*foo seems like
common pattern on the Rust side of FFI to make a reference out of a
pointer and effectively asserting to the human reader that the pointer
is null.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsiv
UTF-8 is so widely deployed that no one in the Taipei office needs
to submit forms in Big5 anymore, that would be good to know, too.
Context:
I need to decide if I should make Big5 encode faster or if I should
trade off speed for smaller footprint for the legacy Simplified
Chinese and Japanese *encod
On Fri, May 12, 2017 at 4:28 AM, Kan-Ru Chen wrote:
> On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote:
>> In Firefox 43, I rewrote our Big5 support and, among other things, I
>> optimized the *encoder* for footprint rather than speed on the theory
>> that users won&
hat are intentionally never freed
(i.e. process termination is what "frees" them)? Is valgrind's message
suppression mechanism granular enough to suppress three allocations
from a particular Rust crate statically linked into libxul?
--
Henri Sivonen
hsivo...@hsivonen.fi
https:/
> handle cases like this.
The comment there is encouraging, since it suggests that Cairo doesn't
attempt to deal with cairo_debug_reset_static_data() getting called
too early.
On Fri, May 19, 2017 at 9:58 PM, Kris Maglione wrote:
> On Fri, May 19, 2017 at 08:44:58AM +0300, Henri Sivonen
On Sun, May 21, 2017 at 3:46 PM, Henri Sivonen wrote:
> I guess instead of looking at the relative slowness and pondering
> acceleration tables, I should measure how much Chinese or Japanese
> text a Raspberry Pi 3 (the underpowered ARM device I have access to
> and that has predic
watch
out for the detector's possible guess space containing very rarely
used encodings that you really don't want content detected as by
mistake.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
(If the outcome here is to do XML5, we should make sure the spec is
polished enough at the WHATWG in order not to a unilateral thing in
relative secret.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-pl
Figured out the email address of the XML5 editor / xml5ever developer,
so adding to CC.
On Tue, May 23, 2017 at 9:43 AM, Henri Sivonen wrote:
> In reference to: https://twitter.com/nnethercote/status/866792097101238272
>
> Is the rewrite meant to replace expat only or also some of our o
fining a coercion to an XML 1.0 4th ed. Infoset, too, for
non-browser use cases.) That would include the processing of
Namespaces.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.or
an be fast for ASCII, which is what attribute values
mostly are.
Furthermore, the main Web XML case is SVG, which has relatively little
natural-language text, so it's almost entirely ASCII. Looking at the
ratio markup and natural-language text in XUL, it seems fair to guess
th
On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen wrote:
> It seems to me that attribute values would be the only case where a
> conversion from UTF-8 to UTF-16 would be needed all the time, and that
> conversion can be fast for ASCII, which is what attribute values
> mostly are.
Mo
ation doesn't seem to align with either
> the 4th or 5th edition of XML 1.0.
OK, if Chrome has shipped 1.0 5th ed., we should, too. :-(
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lis
On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen wrote:
>> Our current interface is UTF-16, so that's my target for now. I think
>> whatever cache-friendliness would be lost converting from UTF-16 -> UTF-8 ->
>> UTF-16.
>
> I hope this can be reconsidered, b
s necessary
>
> WDYT?
Seems good to me with the note that doing the direct UTF-8 to nsIAtom
lookup would probably be a pretty immediate thing rather a true
follow-up.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
propriate to run heuristic
detection for XML.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
son membership, please let me know.
(My understanding is that a reversal of the decision is quite
possible, but actually making the above-contemplated submission is a
process prerequisite for a reversal to take place.)
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
in weaker terms than so far. Letting it be this way
wouldn't invite objections from non-Web-oriented implementors who
implement something else that's currently within Unicode compliance
and who don't want to change any code.
> --Jet
>
> On Wed, Jun 7, 2017 at 2:11 AM, Henri Sivo
r rust-encoding-dependent crates arises.
https://github.com/hsivonen/encoding_rs_compat
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Mon, Nov 30, 2015 at 5:38 PM, Henri Sivonen wrote:
> Japanese *email* is often encoded as ISO-2022-JP, and Web browsers
> also support ISO-2022-JP even though Shift_JIS and EUC-JP are the more
> common Japanese legacy encodings on the *Web*. The two UTF-16 variants
> and ISO-202
On Thu, Jun 15, 2017 at 3:58 PM, Nathan Froyd wrote:
> Can you file a bug so `mach vendor rust` complains about vendoring
> rust-encoding?
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1373554
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivo
the advantage, which is also suggestive of this not being
a matter of how GC happens relative to the timed runs.)
Do we know why?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.or
nterfering with the test, right?
(Interfering meaning making the test reflect something other that the
performance of the back end used by TextDecoder.)
On Fri, Jun 16, 2017 at 11:19 PM, Boris Zbarsky wrote:
> On 6/16/17 7:22 AM, Henri Sivonen wrote:
>>
>> My hypothesis is that the JSC/WebKit
ly one benchmark and 2) it
does the setup first and then waits for the user to click a button,
which hopefully makes it easier to omit the setup from examination.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing li
Do we have a gtest analog for local performance testing? That is,
something that makes it easy to microbenchmark libxul methods?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Wed, Jul 5, 2017 at 3:36 PM, Emilio Cobos Álvarez wrote:
> On 07/05/2017 10:19 AM, Henri Sivonen wrote:
>> Do we have a gtest analog for local performance testing? That is,
>> something that makes it easy to microbenchmark libxul methods?
>
> For CSS parsing there
>> Regards,
>> _______
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
her stuff to do and then
https://github.com/google/gumbo-parser showed up and ended the demand
for a standalone C++ translation.
The core of the XML parser is expat, which, of course, is available as
an independent piece of software.
--
Henri Sivonen
hsivo...@h
lves more boilerplate than scenarios that stay
completely within C++ or that stay completely within Rust, but in the
case of encoding_rs, the work needed to create the boilerplate was
trivial compared to the overall effort of implementing the bulk of the
library itself.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I guess I buried my questions in too long a post, so extracting them:
On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote:
> Naïvely, one would think that it should be possible to do that with
> clang producing "object files" holding LLVM IR and rustc producing
> "objec
ing
another C++ to C++ call, so it's easier to notice when a call to C++
that might release the C++ object that holds the UniquePtr is
introduced. For example, mozilla::Decoder and mozilla::Encoder never
call to C++ code, so it's easy to reason that such le
t least one isindex form
submission.
The removal corresponding to this intent is in 56.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
ash
> during the build: https://bugs.llvm.org/show_bug.cgi?id=33997
I'm guessing using a very new clang was what allowed Chrome to switch
from MSVC to clang? (Chrome accepted a binary size increase on 32-bit
Windows as a result of switching to clang.)
--
Henri Sivonen
hsi
t want to remove or refactor
ASAP?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
What's the correct way to take an action right before a JS-implemented
XPCOM object that acts as the implementation for a WebIDL interface
gets garbage collected?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing
On Tue, Aug 8, 2017 at 1:26 PM, Henri Sivonen wrote:
> What's the correct way to take an action right before a JS-implemented
> XPCOM object that acts as the implementation for a WebIDL interface
> gets garbage collected?
Taking action soon after GC would work for me as well.
I
On Wed, Aug 9, 2017 at 9:39 PM, Boris Zbarsky wrote:
> On 8/9/17 1:55 PM, Henri Sivonen wrote:
>>
>> I'm thinking of introducing a C++-implemented XPCOM object that the
>> JS-implemented XPCOM object can hold a reference to and that has a C++
>> destructor that d
to ingest object files that contain LLVM bitcode
instead of target machine code and to perform cross-compilation-unit
optimization? How far are we from cross-compilation-unit optimization
when some compilation units come from clang and some from rustc?
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hs
ould be to make sure the base revision
is already clang-formatted.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Wed, Aug 30, 2017 at 10:21 AM, Sylvestre Ledru wrote:
>
> Le 30/08/2017 à 08:53, Henri Sivonen a écrit :
>
> Regardless of the outcome of this particular style issue, where are we
> in terms of clang-formatting all the non-third-party C++ in the tree?
>
> We have been w
1 - 100 of 538 matches
Mail list logo
