Page 33 of 44
Posted: Mon 07 May 2012, 18:54
by goingnuts
I wonder...if I stripped goingnuts...would it be the going or the nuts that got smaller..?
Posted: Mon 07 May 2012, 20:24
by starhawk
Probably it would just take out the vowels and you'd be gngnts
Posted: Tue 08 May 2012, 03:30
by technosaurus
goingnuts wrote: I wonder...if I stripped goingnuts...would it be the going or the nuts that got smaller..?
before you do, you should set up a paypal account for tips
Posted: Tue 08 May 2012, 04:45
by RetroTechGuy
goingnuts wrote: I wonder...if I stripped goingnuts...would it be the going or the nuts that got smaller..?
From coconuts, down to pine nuts...
Posted: Sun 13 May 2012, 20:23
by goingnuts
Thank you for your support for the above strictly hypothetic question about stripping and goingnuts...
Hard to pickup with some boring stuff but I will give it a try:
Some time ago I made a mcb holding the following programs
Code: Select all
cdrecord genisoimage growisofs mkisofs mksquashfs3.0 mksquashfs4.0 wodim
(the cdrecord and mkisofs being symlinks to wodim and genisoimage)
I later found that mksquashfs4.0 is not needed if you have mksquashfs3.0.
When trying to rebuild it failed - as I have later changed my uclibc - from buildroot environment to standalone uclibc.
The problem is the cdrkit which is a pain to build. So looked at alternatives and got an interesting tour in history with the cdrkit versus cdrtool. Found an early source of mkisofs (mkisofs-1.12b5) giving a clear build with uclibc only 78K static. But it misses some functions. So looked at the cdrtools (cdrtools-1.10) but as with cdrkit the build is a pain. I guess those build systems that seems to haunt the cd-packages has a purpose but I wish they also was shipped with an ordinary configure&make opportunity. Btw. cdrtools-1.10 gave me a 180K cdrecord and a 286K mkisofs static build (versus cdrkits wodim 322K and genisoimage 618K). No doubt some newer features is missing but I only need it for the save-pup-to-cd/dvd...
Update: I was a little to quick above: The 1.10 cdrecord wont support my writer and a build from the 2.01 version only supports cdrw and not dvd. But at least the mkisofs works and saves some 300K...
Posted: Wed 23 May 2012, 18:17
by goingnuts
Need a small CD-player? Attached two different:
*
cdtool-2.1.8 which also include tools for getting cddb output.
*
dcd-0.99.2 - a more simple player.
Both need the hardware cabling from your CD/dvd-drive to your soundcard/motherboard being present...and remember to un-mute CD in audio mixer and turn up the volume as well...
Both might be handy back ends for
a gtkdialog gui-frontend
Posted: Fri 01 Jun 2012, 19:37
by goingnuts
After making the
gtkman for gktdialog1 I tried to run it in pupngo. But found that although man-bin is static build it wont work. Turns out that man depends on at least tbl and nroff which in turn depends on different auxiliary macro-files.
All that just to view a man page that is "readable" by command "cat"...
tbl is quite easy to build static but nroff did not turn out easy. They belong to GNU groff-package which I did not manage to do a normal build of. Another source is
The Heirloom Documentation Tools - all c-code and state that build with diet libc can be done. I tried diet but my version is 0.31 and I think it needs at least version 0.32 of diet libc (needs wctomb). But I managed to hack my way to a final static build of tbl and nroff - just to realize that although working they seems not to work well with man-expectations - some demand of -mandoc that I was not able to fullfill.
Btw. busybox man also needs tbl and nroff/troff/groff (it needs gtbl which is a symlink to tbl).
Another solution
here. awf is a man-page formatter based on awk-macros and it does a decent job!
A third solution is to use the man2html - which is a standalone app with no need for auxiliary progs - and then use sed to remove the HTML-tags. man2html is part of the original man page.
The forth solution is to use sed on the raw man-page as well (guess awk would work too).
So ended up with a draft for gtkman version 0.2 where at least the sed-only and the man2html method gives reasonable output in pupngo - but with a lot of room for improvement...Maybe a project target for some sed -or awk-sharks?
The present draft code below:
Code: Select all
#!/bin/ash
#simple demo for gtkdialog1 to view text formated man pages
#May 2012 goingnuts
#v0.1 needs original man - will not work with busybox man
#v0.2 liberate it from the man bin/use other ways...
#depending on the system one of the below will be used:
VIEW_ME=4 #simple sed - improve it please!
[ $(which awf) ] && VIEW_ME=3 #view http://awk.info/?tools/awf
[ $(which man2html) ] && VIEW_ME=2 #part of org man pkg
[ $(which man) ] && [ $(which tbl) ] && [ $(which nroff) ] && VIEW_ME=1 #for systems with all it takes for man to work
echo "Using methode $VIEW_ME" #just to know what is going on...
#hardcode mandirs...
MANDIRS="/usr/share/man /usr/man /usr/local/man"
echo > /tmp/gtkman
#create list of man-files present in system
COMBOLIST="<item>Select page to view</item>"
#v0.2
mandirs=$(find ${MANDIRS} -type f)
for file in $mandirs; do
name=$(basename ${file})
name=$(echo ${name%.*}) #for .gz
name=$(echo ${name%.*}) #for .1
COMBOLIST="$COMBOLIST<item>$name</item>"
done
#ash function file
echo '
view_me1 () {
man -P cat ${1} 2> /dev/null | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
}
macro_2 () {
sed -e "s/<[^>]*>//g" | \
sed -e "s/\</</g" | \
sed -e "s/\ / /g" | \
sed -e "s/\>/>/g" | \
sed "/^$/d"
}
view_me2 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | man2html | grep -v "Content-type: text/html" | macro_2 > /tmp/gtkman
else
man2html $manfile2view | grep -v "Content-type: text/html" | macro_2 > /tmp/gtkman
fi
fi
}
view_me3 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | awf -man | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
else
awf -man $manfile2view | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
fi
fi
}
macro_4 () {
sed "s/.B //g" | \
sed "s/.I //g" | \
sed "s/.TP//g" | \
sed "s/.PP//g" | \
sed "s/.LP//g" | \
sed "s/.TH //g" | \
sed "s/.SH //g" | \
sed "s/.BR //g" | \
sed "s/.RI //g" | \
sed "s/.BI //g" | \
sed "s/.RI \[\\\| \\\//g" | \
sed "s/.I \\\//g" | \
sed "s/.br/\n/g" | \
sed "s/fI//g"
}
view_me4 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | macro_4 > /tmp/gtkman
else
cat $manfile2view | macro_4 > /tmp/gtkman
fi
fi
}
' > /tmp/ashfunc
export MAIN_DIALOG='
<wtitle>gtkman</wtitle>
<vbox>
<hbox>
<button>
<label>Quit</label>
<input file>exit.png</input>
</button>
</hbox>
<combobox>
<variable>MAN_LIST</variable>
'${COMBOLIST}'
<action>view_me'${VIEW_ME}' ${MAN_LIST}</action>
<action>clear:EDIT</action>
<action>refresh:EDIT</action>
</combobox>
<frame manpage view>
<edit>
<width>500</width>
<height>300</height>
<input file>/tmp/gtkman</input>
<variable>EDIT</variable>
</edit>
</frame>
</vbox>
'
gtkdialog1 --center --wmclass gtkman --program=MAIN_DIALOG -i /tmp/ashfunc
#clean up
rm -f /tmp/gtkman
rm -f /tmp/ashfunc
Posted: Fri 01 Jun 2012, 20:43
by technosaurus
Nice, we have needed a decent manpage viewer for a while.
As per our previous discussion on reducing xpm images I finally got around to patching mtpaint to support saving xpm images with 92 colors per character vs 64. It makes for a bit nicer looking reduced images, and also bumps support for over 8000 colors vs. ~4000.
the patch is here:
http://www.murga-linux.com/puppy/viewto ... 164#631164
Posted: Sat 02 Jun 2012, 16:57
by PANZERKOPF
Another small tools for mentioned above purposes:
Rman - standalone man page converter (converts man to html or plain text)
asm-toys - multicall tool, includes simple cdplayer
asmutils - coreutils,util-linux, netutils, shell and some other tools including cda2raw
Posted: Mon 04 Jun 2012, 00:19
by Ibidem
Busybox had an nroff patch once which I dug up and updated...
I'll have to see if I can find it again
Posted: Mon 04 Jun 2012, 20:25
by technosaurus
I've been working with musl ind tinyx11 to see what I could build. It looks pretty promising so far. These are the uncompressed sizes:
jwm579 with xpm,png & jpg -448kb (earlier versions may be smaller?)
(Edit: jwm is only 274kb without png/jpg - only xpm)
desklaunch-104kb
rxvt-157kb
meh-270kb
9menu-94kb
mupdf-1182kb
wmix-138kb
calctool-124kb
pupslock-127kb
how does that compare with the uclibc toolchain?
Posted: Tue 05 Jun 2012, 08:48
by goingnuts
PANZERKOPF: Thank you - that are some nice findings! The cdplayer from asm-toys compile to less than 5k and have all functions to control and report status
Wish assembler was easier to learn...as most assembler progs for linux I have seen are a factor 5-10 smaller than the normal...
some examples
technosaurus: I havent tried newer jwm (tried 562 but could not compile it) so below jwm is the usual patched jwm-2.0.1-pe-beta-1:
Code: Select all
-rwxr-xr-x 1 root root 101596 2012-06-05 10:36 9menu*
-rwxr-xr-x 1 root root 140052 2012-06-05 10:36 calctool*
-rwxr-xr-x 1 root root 126960 2012-06-05 10:36 desklaunch*
-rwxr-xr-x 1 root root 437644 2012-06-05 10:36 jwm*
-rwxr-xr-x 1 root root 261600 2012-06-05 10:36 meh*
-rwxr-xr-x 1 root root 136688 2012-06-05 10:36 pupslock*
-rwxr-xr-x 1 root root 187532 2012-06-05 10:36 rxvt*
-rwxr-xr-x 1 root root 180808 2012-06-05 10:36 wmix*
so your builds looks very promising! The size might depend on how much your tinyX is modified - above is build with a tinyX that I also use to build the gtk-apps with.
From amigos repo a file manager with drag&drop:
uxplor.
It also work with older kernels where ROX and emelfm tends to fail.
Posted: Wed 06 Jun 2012, 01:38
by Ibidem
I've dug up the nroff patch. Not bothering to attach the original, since it's hopelessly ancient...
And yes, it does have bad formatting.
Posted: Thu 07 Jun 2012, 15:44
by PANZERKOPF
goingnuts wrote:PANZERKOPFas most assembler progs for linux I have seen are a factor 5-10 smaller than the normal
Not only for linux. Assembler progs are always faster and smaller than same written in other language but have one big disadvantage: they are not portable.
Also, If you like assembler, play with KolibriOS. Really cool
Posted: Fri 08 Jun 2012, 03:21
by technosaurus
PANZERKOPF wrote: Assembler progs are always faster and smaller than same written in other language.
assuming the coders are equally competent ...
So, I have been doing static compiles with my musl toolchain and I have gotten to some stuff that uses gdk-pixbuf-1.0.
@goingnuts - How did you grok the static compile of gtkdialog1 so that the gdkpixbuf stuff worked?
Edit: nevermind the configure script improperly set:
#define USE_GMODULE 1
... commented it out and works fine
Posted: Fri 08 Jun 2012, 04:44
by goingnuts
Ibidem: Thanks for the patch - I try it out.
PANZERKOPF: Yea - its quite impressive - this Kolebri!
technosaurus; Ok - glad you made it! Have you plans to post your tool-chain/build-script/sources at some time?
Posted: Fri 08 Jun 2012, 08:33
by technosaurus
doing a static toolchain, you find a lot of bugs that go unseen otherwise... I am just trying to narrow down the issues to the appropriate place - usually it is autoconf
for gdk-pixbuf --disable-modules _should_ undef, not #define USE_GMODULE 1
(removed support for libtiff while I was at it - its just larger than it is useful)
I am trying to set up things as much as possible to allow people to use the toolchain without having to learn the intricacies of gcc ( I'm adding appropriate flags in a wrapper script - the included one has a couple of issues that require constant patching of makefiles ... sometimes libtool or autotools ignore CC=musl-gcc and CPP="musl-gcc -E" amongst other things and I figured I may as well hard code in all of the safe optimizations and necessary defines while I was at it)
I have also patched tinyX11 to some extent, but if you have your patched sources still, it would help (right now I have threads and NLS disabled and minimal utf8 in order to build - it seems that the sources from xfree86-4.8 work fine - just a lot of cut and paste)
I also got a cutdown freetype, openjpeg, jpeg, jbig2dec and z libs from mupdf (they have a nice build script for them) ... only read support so it worked well with gdkpixbuf and failed on mtpaint (so i built with only xpm and png) anyhow gtkdialog1 is working with jpeg support now.
Posted: Fri 08 Jun 2012, 16:25
by goingnuts
Sound really cool! I still have some gtk-apps that build fine dynamic and static but wont run in the static version (gtksee-0.6.0b-1) or run and fail at some point (chbg-1.4) that would be nice to have...
PM-ed link for dl of my current sources.
Posted: Sat 09 Jun 2012, 05:37
by Ibidem
technosaurus wrote:doing a static toolchain, you find a lot of bugs that go unseen otherwise... I am just trying to narrow down the issues to the appropriate place - usually it is autoconf
for gdk-pixbuf --disable-modules _should_ undef, not #define USE_GMODULE 1
(removed support for libtiff while I was at it - its just larger than it is useful)
I am trying to set up things as much as possible to allow people to use the toolchain without having to learn the intricacies of gcc ( I'm adding appropriate flags in a wrapper script - the included one has a couple of issues that require constant patching of makefiles ... sometimes libtool or autotools ignore CC=musl-gcc and CPP="musl-gcc -E" amongst other things and I figured I may as well hard code in all of the safe optimizations and necessary defines while I was at it)
I have also patched tinyX11 to some extent, but if you have your patched sources still, it would help (right now I have threads and NLS disabled and minimal utf8 in order to build - it seems that the sources from xfree86-4.8 work fine
If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads
should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.
Posted: Sat 09 Jun 2012, 15:22
by technosaurus
Ibidem wrote:If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.
CPP is the preprocessor (the thing that handles all of the macros/includes/etc...) - in a gcc tool chain usually this is just gcc -E, but in order to force it to look in my musl toolchain and not the standard directories I tell it to use my make shift wrapper built on the musl wrapper (just a script named gcc that calls gcc-real with appropriate defines and flags, yes I renamed gcc and called the wrapper gcc to save a helluvalotta editing) that prevents most of these broken scripts from doing the wrong thing. The issues aren't necessarily with musl, but I am having to add a few includes here and there or add -D_GNU_SOURCE or similar, but I am just going to add those to my wrapper script and maybe every once in a while add a symlink for a missing include like io.h (but most are kernel headers that just got missed or were overwritten by glibc)
After I have done a run through all of the useful C libraries on this toolchain without threads and locales, I will do a try with a native toolchain and try them out. (I just wanted to minimize my patching on the first run - its less overwhelming that way)
*question???
What is the best way to get a disk image onto a really low resource computer using minimal ram/cpu, but also not really long or complicated. I was thinking of piping an xz compressed tarball of a filesystem image through dd. However I am hesitant to do it that way due to the possibility of broken pipes (the plumbing is not always in good in these old beasts)