Re: [swift-dev] Combining Skin Tone Emoji Into Single Extended Grapheme Clusters

After reading through the ICU sources, if I understand them correctly, ICU uses the Aho–Corasick algorithm to determine grapheme breaks, word breaks and line breaks, and then does some post-processing after matching using the algorithm. This allows ICU to solve the regional indicator problem by in

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

> On Dec 20, 2015, at 1:01 PM, Daniel Dunbar wrote: > > Hi Nadav, Hi Daniel, > > One thing you didn't call out here was any connection to visibility. This is a great point! Apps usually don’t export too many symbols, but they do import symbols from external shared objects and need to kee

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

Hi Steve, > On Dec 20, 2015, at 7:35 AM, Stephen Canon wrote: > > Nadav, can you clarify what we’re really trying to accomplish here? "Smaller > binaries” isn’t too important of a goal in and of itself. > > Are we trying to: > – reduce storage used on disk > – reduce load time > – reduce loa

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

On Sun, Dec 20, 2015 at 9:43 PM, Nadav Rotem wrote: > > On Dec 20, 2015, at 2:17 AM, Dmitri Gribenko wrote: > > + Stephen Canon, because he probably has good ideas in this domain. > > On Fri, Dec 18, 2015 at 3:42 PM, Nadav Rotem via swift-dev > wrote: >> >> >> What’s next? >> >> The small experi

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

> On Dec 20, 2015, at 2:17 AM, Dmitri Gribenko wrote: > > + Stephen Canon, because he probably has good ideas in this domain. > > On Fri, Dec 18, 2015 at 3:42 PM, Nadav Rotem via swift-dev > mailto:swift-dev@swift.org>> wrote: > > What’s next? > > The small experiment I described above showe

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

Though it might sound a little silly (because why not run linux), but starting with a beagle bone black would not be a terrible way to begin with bare metal work. It has plenty of RAM, you know that LLVM writes good machine code for it, it has JTAG accessible, it’s inexpensive, etc... This wou

[swift-dev] Clang importer: enabling Swift name lookup tables

Hi all, I’ve been working on the Clang importer’s Swift name lookup tables for the last few weeks, and they’re now at a point where I’d like to turn them on by default. Essentially, this replaces the ad hoc mechanism we are currently using in the Clang importer to find entities by name with a m

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

I would love to add that uploading iOS apps is much bigger with swift Sent from my iPhone > On 20 Dec 2015, at 15:35, Stephen Canon via swift-dev > wrote: > > Nadav, can you clarify what we’re really trying to accomplish here? "Smaller > binaries” isn’t too important of a goal in and of its

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

Hi Nadav, One thing you didn't call out here was any connection to visibility. I would expect that in practice it is quite common for most of the symbols to not be visible outside the linkage unit. Inside the linkage unit, the compiler can already rename many of the symbols in any way it likes.

Re: [swift-dev] Breaking change in lexing operators next to comments

> On Dec 17, 2015, at 10:41 PM, Jesse Rusak wrote: > > >> On Dec 17, 2015, at 1:08 PM, Chris Lattner > > wrote: >> >>> >>> On Dec 17, 2015, at 6:32 AM, Jesse Rusak via swift-dev >> > wrote: >>> >>> Any other comments about this? Can some

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

Nadav, can you clarify what we’re really trying to accomplish here? "Smaller binaries” isn’t too important of a goal in and of itself. Are we trying to: – reduce storage used on disk – reduce load time – reduce loaded memory footprint – make emitting swift binaries more efficient – something els

Re: [swift-dev] Building Foundation on FreeBSD

On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano wrote: > On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose wrote: >> >> On Dec 19, 2015, at 7:14 , Davide Italiano wrote: >> >> On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano >> wrote: >> >> On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose wrote: >> >

Re: [swift-dev] [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

+ swift-dev, Jordan On Sun, Dec 20, 2015 at 2:21 AM, Dan Stenmark via swift-corelibs-dev wrote: > I'm trying to invoke Linux's unshare() system call from Swift, but without > much success. From C, it requires _GNU_SOURCE to be #define'd before the > #include . The Glibc module map does indeed

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

+ Stephen Canon, because he probably has good ideas in this domain. On Fri, Dec 18, 2015 at 3:42 PM, Nadav Rotem via swift-dev < swift-dev@swift.org> wrote: > > *What’s next?* > > The small experiment I described above showed that compressing the names > in the string table has a huge potential f

Re: [swift-dev] Building Foundation on FreeBSD

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose wrote: > > On Dec 19, 2015, at 7:14 , Davide Italiano wrote: > > On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano > wrote: > > On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose wrote: > > > On Dec 16, 2015, at 11:21 , Davide Italiano wrote: > > On Wed,

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

On Sat, Dec 19, 2015 at 6:53 PM, Chaitanya Mannem via swift-users < swift-us...@swift.org> wrote: > Hi, > > > I wanted to know if it is possible to compile swift code for bare metal. I > know there is a runtime but does swift depend on it to execute even if I > don't use those features?, can I dis