Greetings.
On Wed, 25 Dec 2013 09:54:51 +0100 Markus Teich
wrote:
> Heyho,
>
> I noticed many CLOSE_WAIT connections from surf in the output of `lsof -i -an`
> after browsing some websites with surf. Before blaming someone or trying to
> fix
> it: Is this expected behaviour? Or should it be fi
On Tue, Dec 24, 2013 at 10:31:37PM +, Thorsten Glaser wrote:
> Strake dixit:
>
> >Use wchar.h functions and a sane libc, e.g. musl, which has a pure
> >UTF-8 C locale, which ISO C explicitly allows [1].
> >
> >The 8-bit clarity what POSIX wants [1] seems nonsense to me, as one
> >can use byte
https://github.com/strake/l9fb
Future goals:
* make a terminal emulator
* make a tiling window organizer with same interface
* make the X window system my ex-window system
Good day,
I was finally able to set up my musl cross-compiler and spent the
evening working on compiling 9base with it.
It has come to my attention, that there seems to be unreachable code
within lib9 at four places silently scourging our efforts to port
9base to musl.
Those places are:
(1) lib9
Hey,
Neat although maybe not so practical. There would be lots of latency
over a remote network, but locally I can see this being ok. rio on
plan 9 serves How could you make it so that you can compress the
out-going video? Just curious!
Regards,
Lee
On Wed, Dec 25, 2013 at 1:36 PM, Strake wrot
On 25/12/2013, Lee Fallat wrote:
> Neat although maybe not so practical. There would be lots of latency
> over a remote network, but locally I can see this being ok.
Yes, this is meant to be local. Remote graphics likely ought to be
vector rather than raster.
> How could you make it so that you
Silvan Jegen dixit:
>Wouldn't a 16-bit wchar_t be non-standard-conform when using a UTF-8
>locale?
Nope. UTF-8 is just an encoding for Unicode, and as long as I take
care to #define __STDC_ISO_10646__ 29L (and no later date) this
is perfectly permissible.
(And please do not language-lawyer m
On Wed, Dec 25, 2013 at 11:01:13PM +, Thorsten Glaser wrote:
> Silvan Jegen dixit:
>
> >Wouldn't a 16-bit wchar_t be non-standard-conform when using a UTF-8
> >locale?
>
> Nope. UTF-8 is just an encoding for Unicode, and as long as I take
> care to #define __STDC_ISO_10646__ 29L (and no l
Rich Felker dixit:
>> >Wouldn't a 16-bit wchar_t be non-standard-conform when using a UTF-8
>> >locale?
>>
>> Nope. UTF-8 is just an encoding for Unicode, and as long as I take
>> care to #define __STDC_ISO_10646__ 29L (and no later date) this
>> is perfectly permissible.
>This is only a poss
