Re: [dev] Re: sta.li progress
In my simple mind it might be easier to modify bionic to become 'a port of *BSD libc' (adding missing syscalls and whatnot) than to port it all to Linux from scratch? 2010/10/28 finkler : > On 10/12/10 07:58, Wolf Tivy wrote: >>> 2. Demonstrate stand-alone static binaries that have been linked >>> against bionic/x86. >> >> This assumes we have bionic itself working. Has anyone actually built it >> without building all of android? I got the source, but I can't make it >> build. I've tried a few things, but I hate makefiles. Especially when >> they're called Android.mk. >> >> > Have there ever been any efforts to create a suckless libc ? I mean > instead of porting bionic, which is based on the OpenBSD libc, one could > start with the OpenBSD libc to begin with. > Remove all the macro crap and just support c99 and POSIX, which is one > of the few cases where it might actually be worth the hassle to follow > such a standard. > Then again it seems backward to put so much effort in an outdated > standard. I don't really know, any thoughts on this? > > regards, > finkler > > >
Re: [dev] Re: sta.li progress
On a related note. Has anyone tried to compile APE on p9p? Would the APE libc compiled under p9p be possible to use as a POSIX libc on linux? (I might try compiling APE under p9p tonight when I get home if nobody has tried this yet) A second issue is: Does p9p libc get (L)GPL contaminated by the host libc during compilation and would this potential contamination carry over to the APE libc compiled with the p9p libc? If this is the case, it would still be good/prudent to (at least initially, as a "primer") compile p9p with a permissive libc (for example bionic). 2010/10/28 finkler : > On 10/28/10 01:16, Jacob Todd wrote: >> If someone was going to create a "suckless" libc, they shouldn't support >> posix. start with the plan 9 libraries instead of the obsd while you're at >> it. >> > I understand that the idea is to compile other shit, not suckless > software, or else we could just use the plan9 libc. > Why is it no one (besides some niche projects and p9p) itself actually > uses the p9p libc? > > >
[dev] Re: sta.li progress
On 10/28/10 01:39, Jacob Todd wrote: > Go uses the plan 9 libs. > While I really like Go, it is still a niche project, and a 2MB+ basename executable is not really suckless.
Re: [dev] Re: sta.li progress
I think p9p libc is a big wrapper around glib. There is no plan9 libc for unix (only some stuff that comes with go but It can not be used with an ansi c compiler). On Thu, Oct 28, 2010 at 9:34 AM, Jens Staal wrote: > On a related note. Has anyone tried to compile APE on p9p? Would the > APE libc compiled under p9p be possible to use as a POSIX libc on > linux? (I might try compiling APE under p9p tonight when I get home if > nobody has tried this yet) > > A second issue is: Does p9p libc get (L)GPL contaminated by the host > libc during compilation and would this potential contamination carry > over to the APE libc compiled with the p9p libc? If this is the case, > it would still be good/prudent to (at least initially, as a "primer") > compile p9p with a permissive libc (for example bionic). > > 2010/10/28 finkler : >> On 10/28/10 01:16, Jacob Todd wrote: >>> If someone was going to create a "suckless" libc, they shouldn't support >>> posix. start with the plan 9 libraries instead of the obsd while you're at >>> it. >>> >> I understand that the idea is to compile other shit, not suckless >> software, or else we could just use the plan9 libc. >> Why is it no one (besides some niche projects and p9p) itself actually >> uses the p9p libc? >> >> >> > >
Re: [dev] Re: sta.li progress
I mean glibc On Thu, Oct 28, 2010 at 1:40 PM, pmarin wrote: > I think p9p libc is a big wrapper around glib. There is no plan9 libc > for unix (only some stuff that comes with go but It can not be used > with an ansi c compiler). > > On Thu, Oct 28, 2010 at 9:34 AM, Jens Staal wrote: >> On a related note. Has anyone tried to compile APE on p9p? Would the >> APE libc compiled under p9p be possible to use as a POSIX libc on >> linux? (I might try compiling APE under p9p tonight when I get home if >> nobody has tried this yet) >> >> A second issue is: Does p9p libc get (L)GPL contaminated by the host >> libc during compilation and would this potential contamination carry >> over to the APE libc compiled with the p9p libc? If this is the case, >> it would still be good/prudent to (at least initially, as a "primer") >> compile p9p with a permissive libc (for example bionic). >> >> 2010/10/28 finkler : >>> On 10/28/10 01:16, Jacob Todd wrote: If someone was going to create a "suckless" libc, they shouldn't support posix. start with the plan 9 libraries instead of the obsd while you're at it. >>> I understand that the idea is to compile other shit, not suckless >>> software, or else we could just use the plan9 libc. >>> Why is it no one (besides some niche projects and p9p) itself actually >>> uses the p9p libc? >>> >>> >>> >> >> >
[dev] [wmii] grow command does not work on floating mplayer
Hi, mplayer windows keeps a fixed aspect ratio when floating. Growing such windows via wmiir does not seem to work, because one can only grow either horizontally or vertically, but not both at the same time. (Shrinking works, the other direction gets shrunk accordingly.) Is there any way to still grow floating mplayer windows without the mouse? Thanks and best, Thomas
Re: [dev] Re: sta.li progress
How? It's statically linked iirc against the systems libs. On Oct 28, 2010 5:24 AM, "finkler" wrote: > On 10/28/10 01:39, Jacob Todd wrote: >> Go uses the plan 9 libs. >> > While I really like Go, it is still a niche project, and a 2MB+ basename > executable is not really suckless. > >
Re: [dev] [wmii] grow command does not work on floating mplayer
On Thu, Oct 28, 2010 at 02:14:06PM +0200, Thomas Dean wrote: mplayer windows keeps a fixed aspect ratio when floating. Growing such windows via wmiir does not seem to work, because one can only grow either horizontally or vertically, but not both at the same time. (Shrinking works, the other direction gets shrunk accordingly.) Is there any way to still grow floating mplayer windows without the mouse? That's an interesting problem. The aspect ratio algorithm always fits the window to the largest size possible in the given rectangle, which works fine for the mouse, but is clearly problematic with the keyboard. I guess I'll have take the aspect ratio hint into account for keyboard resizes. -- Kris Maglione ...the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. ... If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important. --Donald Knuth
Re: [dev] [wmii] grow command does not work on floating mplayer
On Thu, Oct 28, 2010 at 02:14:06PM +0200, Thomas Dean wrote: mplayer windows keeps a fixed aspect ratio when floating. Growing such windows via wmiir does not seem to work, because one can only grow either horizontally or vertically, but not both at the same time. (Shrinking works, the other direction gets shrunk accordingly.) Is there any way to still grow floating mplayer windows without the mouse? Fixed in tip. -- Kris Maglione A program is portable to the extent that it can be easily moved to a new computing environment with much less effort than would be required to write it afresh. --W. Stan Brown
Re: [dev] [wmii] grow command does not work on floating mplayer
On Thu, Oct 28, 2010 at 09:56:13 -0400, Kris Maglione wrote: > Fixed in tip. Thanks, that was fast, works great! I noticed another problem introduced in hg2782: In rc/wmiirc.sh, local_events | wi_events needs to be replaced by wi_events local_events in order for the local events to work.
