On 07/01/2016 08:39 PM, FRIGN wrote:
> On Fri, 1 Jul 2016 14:49:34 -0700
> Ben Woolley wrote:
>
> [...]
>> Remember, git was originally created to solve the problem of concurrently
>> managing many large patch sets from distributed sources. Isn't that the
>> problem here?
>
> it's always the s
On 05/03/2016 01:57 AM, Sylvain BERTRAND wrote:
> On Mon, May 02, 2016 at 04:29:11PM -0700, Andrew Gwozdziewycz wrote:
>> Given this effort, and the fact that they've gotten pretty damn far
>> towards being usable, I'd say you can't *possibly* argue that "they
>> all *epic-ly* [sic] fail at the ker
On 04/30/2016 03:04 PM, ra...@openmailbox.org wrote:
> On 2016-04-30 11:47, Kajetan Jasztal wrote:
>> how about servo[1]? aims for memory security and fast parallel rendering
>>
>> [1] https://servo.org/
>
> There is a lot of hype about rust being 'memory safe' but where is the
> proof?
AFAICT, P
On 05/02/2016 04:40 AM, Sylvain BERTRAND wrote:
> On Mon, May 02, 2016 at 11:12:08AM +1000, Timothy Rice wrote:
>>> [...]
>
>
> When you want to promote a new language:
> 1 - write a boostrap compiler (for kernel profile and other profiles)
> in the current "system language" (I gue
On 02/15/2016 02:55 AM, Sylvain BERTRAND wrote:
> On Sat, Feb 13, 2016 at 08:03:13PM +0100, Leo Gaspard wrote:
>> https://git.ekleog.org/dtext/
>
> Hi,
>
> What is the scope of dtext in perspective of harfbuzz? Do you plan to support
> unicode for a maximum of languag
Hi,
I'm happy to announce the first prerelease of dtext, a font rendering
library that tries to suck less:
https://git.ekleog.org/dtext/
What it does:
* Render a string to the screen, using any TTF or OTF font
* Use any color
* Fallback between configured fonts
What it does not (yet) do:
