Have you read the whole thing? Have you ever seen a complete
implementation? Hell, have you ever seen a standard that doesn't suck?
Pthreads, locales, mmap, sockets, ioctl, select/poll, ... and that is
without going into all the hideous api details that even saner parts
of the spec are full of.
On May 26, 2009, at 8:50 PM, Szabolcs Nagy wrote:
On 5/26/09, Kris Maglione wrote:
That's exactly what I said. The basic system calls are defined
great, then i misunderstood you (or you misunderstood me)
There's no reason that signal(2) and raise(2) can't be
implemented in pure C, aside
On Tue, May 26, 2009 at 08:50:35PM +0200, Szabolcs Nagy wrote:
There's no reason that signal(2) and raise(2) can't be
implemented in pure C, aside from the usual syscall machinery.
They're usually implemented as system calls.
um i don't understand your point
they cannot be implemented except wit
I see people saying this all of the time, but never an explanation.
Could you elaborate why posix is a piece of shit?
On Tue, May 26, 2009 at 08:28:49PM +0200, Uriel wrote:
> The only problem is that PoSix is a piece of shit.
>
> uriel
>
> On Mon, May 25, 2009 at 4:25 PM, Kurt H Maier wrote:
>
On 5/26/09, Kris Maglione wrote:
> That's exactly what I said. The basic system calls are defined
great, then i misunderstood you (or you misunderstood me)
> There's no reason that signal(2) and raise(2) can't be
> implemented in pure C, aside from the usual syscall machinery.
> They're usually i
The only problem is that PoSix is a piece of shit.
uriel
On Mon, May 25, 2009 at 4:25 PM, Kurt H Maier wrote:
> http://libposix.sourceforge.net/
>
> It's an implementation of POSIX 2008 -- and nothing else! This is the
> sort of thing we can use to build a suckless coreutils package, in my
> op
On Tue, May 26, 2009 at 06:56:14PM +0200, Szabolcs Nagy wrote:
It's possible to write portable code that utilizes platform (or
architecture) specific code. You need to segregate the portable
portions from the unportable portions, so that porting only
requires writing some system call stubs for ea
On 5/26/09, Kris Maglione wrote:
> On Tue, May 26, 2009 at 05:13:23PM +0200, Szabolcs Nagy wrote:
>>posix syscalls cannot be implemented in a cross platform way, they
>>depend on system internals
> It's possible to write portable code that utilizes platform (or
> architecture) specific code. You n
On Tue, May 26, 2009 at 05:13:23PM +0200, Szabolcs Nagy wrote:
"A cross platform implementation, that should replace existing
implementations of the system core libraries"
posix syscalls cannot be implemented in a cross platform way, they
depend on system internals
It's possible to write portab
On 5/25/09, Kurt H Maier wrote:
> http://libposix.sourceforge.net/
>
> It's an implementation of POSIX 2008 -- and nothing else! This is the
"A full implementation of the POSIX 2008 standard"
that means an entire operating system (including shell, commands, etc)
"A cross platform implementation
2009/5/26 Jeremy Jay :
> I guess I should have been more explicit:
>
> { NULL, NULL, "R Graphics", 0, True },
>
Then,
{ NULL, NULL, "R", 0,True },
should have worked. It probably didn't because the window title is set
after rules have bee
I guess I should have been more explicit:
{ NULL, NULL, "R Graphics", 0,True },
On Tue 26 May 2009 - 08:10PM, Wu, Yue wrote:
> On Mon, May 25, 2009 at 03:39:11PM -0400, Jeremy Jay wrote:
> >
> > use "R Graphics" instead of "R*". it's only substrings, not pattern ma
On Mon, May 25, 2009 at 03:39:11PM -0400, Jeremy Jay wrote:
>
> use "R Graphics" instead of "R*". it's only substrings, not pattern matching
>
Unfortunitely it doesn't work:
{ "R Graphics", NULL, NULL, 0,True },
maybe I need to use "R Graphics: Device 2 (ACTIVE)"?
> I have gtk+-2.16.1 from ~x86.
I use the latest slackware release (12.2) even with slackware current you
get gtk+2-2.14 or something so I wonder for what they need such a recent
gtk version ...
compiling webkit from svn doesn't hurt, but if I want to upgrade to
gtk+2-2.16 I have to solve a lot o
14 matches
Mail list logo
