Kris Maglione | 1 Aug 01:19 2010
Picon

Re: [wmii] Between tiling and floating

On Sun, Aug 01, 2010 at 12:06:18AM +0200, LuX wrote:
>I tried right this without success. For example the single command:
>    wmiir read /tag/sel/index | awk '$2 == ENVIRON["area"] { print $4; exit }'
>answers nothing (empty string) which is not good, I suppose. 
>Thank you very much for the hint anyway. I get the idea, so now I
>should find a way. 

That's strange. I haven't tested it, but that much, at least 
works for me. Well, at least it does from my shell with 
'export area=1'

>By the way, is there a documentation available for the wi_* functions? 
>I didn't find them in /usr/share/doc/wmii/wmii.pdf. 

No, they're defined in wmii.sh and are generally simple enough 
to be clear without documentation (with a few exceptions like 
wi_events and wi_fnmenu). I'll add documentation to wmii.sh in 
the near future, though.

>> Can't say that I like the idea much myself, but to each his own.
>
>His own… screen, you mean? On the 15" screen I had during my
>hollidays, I can swear that such a feature would have been very
>convenient. 

Perhaps, but I've used 15" monitors in the past and have never 
seen the need, though I've tended to avoid using multiple 
columns in that case.

--

-- 
(Continue reading)

pancake | 1 Aug 09:30 2010

Re: How about sta.li ?

Cant this be done with a wraper shellscript ? Messing with gnu ld is  
like a near death experience.

Using r2libs can also be possible.. But would be more complex than a  
few loc shellscript.

That's what libtool does ( between many other silly things) which we  
dont need, and certainly i would prefer to be cmpiler agnostic and be  
able to use tcc or llvm.

Inthe other side u can do this by specifying --enable-static and -- 
dudable-shared in any prj using autofools (webkit, X11 ..)

I dont get the point with the 'tee like'

On Jul 31, 2010, at 10:12 PM, Anselm R Garbe <garbeam <at> gmail.com> wrote:

> Hi Krankkatze,
>
> On 31 July 2010 19:43, Krankkatze <krankkatze <at> gmail.com> wrote:
>> I'm very interested in the sta.li project and would like to know if  
>> the
>> project is still active or not, and if any help could be brought.  
>> Thanks!
>
> It's inactive atm, but I did plenty work in the sta.li area that is
> still unpublished, also because I did some sort of it at work.
> I plan to resolve the issues during the next weeks and will provide an
> update by then.
>
(Continue reading)

pancake | 1 Aug 09:43 2010

Re: How about sta.li ?

I want to say that in latest glibc (see archlinux) many 9base programs  
cant be executed because of being static.

Compiling bionic would be great but I was unAble to workaround their  
makefiles to do it without the android sdk.

Glibc must be avoided as much as possible. Anybody working w bionic  
here?

I wrote slpm which can be used as template for binary and src packages  
and it supports static compilation. A repo of bins for it can be good.  
Packages aré pretty similar to slackware (mere tarballs)

I know that stali aims to not have package system, but. Imho slpm can  
be a good start to generate chroots or manage binary packages in a  
simple way. It needs more work coz bindeps are not supported, etc..

So imho binpkgs for stali should just be tarballs u uncompress or you  
remove. But pkgsystem is a complex topic because many progrMs require  
postinstall scripts and others which really suck by nature and I would  
love to erradicate all this innecesary complexity or just avoid using  
them.

On Jul 31, 2010, at 11:10 PM, Jens Staal <staal1978 <at> gmail.com> wrote:

> Another, sort of related question: how has it worked out with the
> static binaries of 9base etc built with bionic?
>
> I was thinking, perhaps a "static binary repository" could be a good  
> start :)
(Continue reading)

Ethan Grammatikidis | 1 Aug 12:38 2010

Re: How about sta.li ?


On 1 Aug 2010, at 8:43, pancake wrote:

> I want to say that in latest glibc (see archlinux) many 9base  
> programs cant be executed because of being static.
>
> Compiling bionic would be great but I was unAble to workaround their  
> makefiles to do it without the android sdk.
>
> Glibc must be avoided as much as possible. Anybody working w bionic  
> here?

Agreed, but what about other libcs? I'm astonished glibc has come up  
at all. Is dietlibc really that inadequate? Or uclibc? I brought up  
dietlibc first because as far as I know it doesn't even have dynamic  
linking. If it is missing necessary features, perhaps it might even be  
easier to add those features than to bring glibc to heel.

>
> I wrote slpm which can be used as template for binary and src  
> packages and it supports static compilation. A repo of bins for it  
> can be good. Packages aré pretty similar to slackware (mere tarballs)
>
> I know that stali aims to not have package system, but. Imho slpm  
> can be a good start to generate chroots or manage binary packages in  
> a simple way. It needs more work coz bindeps are not supported, etc..

Bindeps as such won't be relevant to a statically linked distro,  
although there will be a few run-time deps here and there, which will  
typically be looser than binary library deps need to be.
(Continue reading)

Ethan Grammatikidis | 1 Aug 13:35 2010

Re: How about sta.li ? - libc tangent


On 1 Aug 2010, at 8:43, pancake wrote:

> I want to say that in latest glibc (see archlinux) many 9base  
> programs cant be executed because of being static.

I sent the other mail off & then I thought, are you talking about  
finding a sane libc for any linux, not just sta.li? I've been thinking  
about it lately, needing to avoid glibc, OS X's libc, and gcc for  
various reasons including the dynamic linking issue. There are C  
compilers with the Go distribution which will produce Linux and OS X  
executables, but no libc, and that started me thinking, specifically  
with the goal of getting a statically linked p9p on one machine and a  
completely glibc-free p9p/9base and inferno on another.

Perhaps it's a mad thought, but what about building a p9p-alike on top  
of a modified, ported Plan 9 libc? I expect most of the system calls  
would pose no more trouble than in p9p. It's work to be done over  
again, borrowing methods from p9p, but some parts will actually be  
easier. For example, the Linux kernel's clone system call is far  
closer to plan 9's fork() than posix threads clone() interface is.

I figure it could go one of two ways. One way some functionality would  
be disabled, giving a very p9p-like result. I called this 9libc. The  
other way, a 9p multiplexer server could be made. Along with support  
servers this could ultimately give a very complete Plan 9 experience  
without any of the performance issues of virtualisation or the other  
issues of 9vx. I called this Under9. Under9 is distinct from Glendix  
in that Glendix is Linux-specific, which doesn't make me happy and  
appears make more work for the maintainers. Under9 ought to work with  
(Continue reading)

Josh Rickmar | 1 Aug 14:35 2010
Picon

Re: How about sta.li ?

On Sun, Aug 01, 2010 at 11:38:14AM +0100, Ethan Grammatikidis wrote:
> Agreed, but what about other libcs? I'm astonished glibc has come up
> at all. Is dietlibc really that inadequate? Or uclibc? I brought up
> dietlibc first because as far as I know it doesn't even have dynamic
> linking. If it is missing necessary features, perhaps it might even
> be easier to add those features than to bring glibc to heel.

Isn't dietlibc GPL'd?  Wouldn't this require that any binary
distributions of statically linked programs also be distributed under
the terms of the GPL?

Josh Rickmar

Anselm R Garbe | 1 Aug 20:00 2010
Picon

Re: How about sta.li ? - libc tangent

On 1 August 2010 12:35, Ethan Grammatikidis <eekee57 <at> fastmail.fm> wrote:
> On 1 Aug 2010, at 8:43, pancake wrote:
>
>> I want to say that in latest glibc (see archlinux) many 9base programs
>> cant be executed because of being static.
>
> I sent the other mail off & then I thought, are you talking about finding a
> sane libc for any linux, not just sta.li? I've been thinking about it
> lately, needing to avoid glibc, OS X's libc, and gcc for various reasons
> including the dynamic linking issue. There are C compilers with the Go
> distribution which will produce Linux and OS X executables, but no libc, and
> that started me thinking, specifically with the goal of getting a statically
> linked p9p on one machine and a completely glibc-free p9p/9base and inferno
> on another.
>
> Perhaps it's a mad thought, but what about building a p9p-alike on top of a
> modified, ported Plan 9 libc? I expect most of the system calls would pose
> no more trouble than in p9p. It's work to be done over again, borrowing
> methods from p9p, but some parts will actually be easier. For example, the
> Linux kernel's clone system call is far closer to plan 9's fork() than posix
> threads clone() interface is.

I think one decision in p9p was to provide something considerable
portable, not just Linux-tight. This decision wasn't bad at all and
allows to run it on Darwin, many BSDs and some other Unices.

Anyways I see the point in migrating to a more suitable libc base.
bionic seems nice and shouldn't be too limited, but it won't be as
portable as uclibc for instance, which is still my favorite and fairly
feature complete for what exists.
(Continue reading)

Anselm R Garbe | 1 Aug 20:01 2010
Picon

Re: How about sta.li ?

On 31 July 2010 22:10, Jens Staal <staal1978 <at> gmail.com> wrote:
> Another, sort of related question: how has it worked out with the
> static binaries of 9base etc built with bionic?
>
> I was thinking, perhaps a "static binary repository" could be a good start :)

This sounds fairly simple and straightforward as long as it's
Linux-only on x86 or arm.

-Anselm

Kris Maglione | 1 Aug 20:02 2010
Picon

Re: [wmii] tagging Thunderbird windows

On Tue, Jul 27, 2010 at 03:05:41PM +0200, Thomas Dahms wrote:
>Hi,
>
>I have a rule for Thunderbird "/Thunderbird/ tags=netz". I composed a
>message, which opens a new window. Then I tagged this new window
>"+something" to have it also on another tag. Later I sent the mail,
>which closed that window.
>Now, when composing another new message, these new windows still get
>tagged "netz+something", although Thunderbirds main window is still
>"netz" only.
>Is this expected behavior?

Sorry, I forgot to mention: this should be fixed in tip.

--

-- 
Kris Maglione

Science is interesting, and if you don't agree you can fuck off.
	--Nigel Calder, former editor of New Scientist

Anselm R Garbe | 1 Aug 20:15 2010
Picon

Re: How about sta.li ?

On 1 August 2010 08:30, pancake <pancake <at> youterm.com> wrote:
> Cant this be done with a wraper shellscript ? Messing with gnu ld is like a
> near death experience.

Indeed, it can be done using some shell scripts but it'll be quite
slow. My initial efforts were gold related, though that's written in
C++ which is a bit annoying.

> Using r2libs can also be possible.. But would be more complex than a few loc
> shellscript.
>
> That's what libtool does ( between many other silly things) which we dont
> need, and certainly i would prefer to be cmpiler agnostic and be able to use
> tcc or llvm.

Afaik gold is compiler agnostic as long as ELF is involved.

> Inthe other side u can do this by specifying --enable-static and
> --dudable-shared in any prj using autofools (webkit, X11 ..)
>
> I dont get the point with the 'tee like'

With tee-like I mean that the static libraries are created in a
different place for later linking lookups, but also to support the
normal behavior in order that vanilla builds run through smoothly,
since they usually check for libsomething.so's to carry on.

A simplified example, imagine:

  ld -o libsomething.so foo.o bar.o baz.o
(Continue reading)


Gmane