Unbloated coding resources

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#31 Post by technosaurus »

vovchik wrote:Dear guys,

I had some success recently getting void* work on 32 and 64-bit machines by changing that void to intptr_t. Anybody want to try that and report the results?

With kind regards,
vovchik
void * should cast properly to any pointer type (technically function pointers have slightly different rules though), that is why it should not be changed to simply int (instead of int* which is the same as intptr_t) because int is not always the same size as void* ... if you want an integer type that is the same size as void*, use size_t for unsigned and ptrdiff_t for signed... Even if size_t is larger than you need, it will simplify the assembly code because smaller types require a superfluous MOV{*} operation and it will be portable across 32/64 bit systems
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#32 Post by Ibidem »

technosaurus wrote:
vovchik wrote:Dear guys,

I had some success recently getting void* work on 32 and 64-bit machines by changing that void to intptr_t. Anybody want to try that and report the results?

With kind regards,
vovchik
void * should cast properly to any pointer type (technically function pointers have slightly different rules though), that is why it should not be changed to simply int (instead of int* which is the same as intptr_t) because int is not always the same size as void* ... if you want an integer type that is the same size as void*, use size_t for unsigned and ptrdiff_t for signed... Even if size_t is larger than you need, it will simplify the assembly code because smaller types require a superfluous MOV{*} operation and it will be portable across 32/64 bit systems
If you're using a POSIX-like system, it's certain to follow ILP32/LP64: sizeof(int)==4; sizeof(long)==sizeof(void *);
sizeof(char)==1; sizeof(short)==2; sizeof(long long)==8; are also true on semi-recent POSIX-like systems.

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#33 Post by vovchik »

Dear technosaurus and Ibidem,

Thanks guys...I will experiment, since I have run into little problems with my own code running properly under 64-bit when written originally under 32-bit...and the problems seem to be related to my casting of pointers.

With kind regards,
vovchik

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#34 Post by Ibidem »

More stuff...
Dropbear is a small ssh package; it can be built with ssh, sshd, scp, and key generator/convertor in one binary.
Uses libtom* for crypto; sqlite and wpa_supplicant can also be configured to use libtom*.

Toybox includes a dhcp client, dhcp server, syslogd/klogd, tftpd, and crond/crontab. Bootchartd, inotifyd, and telnetd might also be interesting. Haven't tested if toybox mount works right with fstab yet.

Lots of neat stuff over at litcave, especially neatroff and fbvnc.
fbvis is a tiny framebuffer image viewer (132 kb linked static against musl); supports JPEG PNG PPM TGA BMP PSD GIF(partial) HDR PIC, using lodepng, stb_image, and a builtin ppm loader.

Keys: vi keys for scrolling (hjkl), J/n for next image, K/p for previous, f for zoom to height, w is zoom to width.
See README for more.

Thinking it would be handy to have a thermald/powerd or such (monitors temperature, load, and battery; controls cpu frequency/governor and fan; can run arbitrary commands).

Is there an update for libc.h, or was 0.1 the last release?

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#35 Post by technosaurus »

Yeah I like the litcave frame buffer tools as well ... Fbvis can be modified to only use stb_image with only a couple of modifications... Can't believe I didn't already mention dropbear but yeah... I wonder if we could add audio forwarding capability to dropbear? Maybe by capturing/dev/dsp and putting it on a udp or tcp socket
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#36 Post by Ibidem »

technosaurus wrote:Can't believe I didn't already mention dropbear but yeah... I wonder if we could add audio forwarding capability to dropbear? Maybe by capturing/dev/dsp and putting it on a udp or tcp socket
Probably not reliably; AFAICT, that would only work for OSS3 dynamically linked stuff, we'd need to handle ioctls, etc...
(OSS4 uses a slightly different set of ioctls; Pulse and ALSA are pretty different.)

I'm still wondering whether libc.h has been upgraded since 0.1, if the string.h replacements ever happened, and what the status of all that is.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#37 Post by technosaurus »

Ibidem wrote:
technosaurus wrote:Can't believe I didn't already mention dropbear but yeah... I wonder if we could add audio forwarding capability to dropbear? Maybe by capturing/dev/dsp and putting it on a udp or tcp socket
Probably not reliably; AFAICT, that would only work for OSS3 dynamically linked stuff, we'd need to handle ioctls, etc...
(OSS4 uses a slightly different set of ioctls; Pulse and ALSA are pretty different.)
The reason I ask, is that I am trying to figure out a way to use linux containers to allow up to 65k users to run applications on the same system. X apps can use ssh -X -C, but so far pulse audio is the only thing in use ... well, there is NAS (which I would prefer due to licensing and less general suck-ness) _but_ according to https://bugs.debian.org/cgi-bin/bugrepo ... bug=655361, it will take some patching. ... but that is probably a topic for another thread, especially since (IMHO) this is an area where systemd can be useful and any mention of it tends to awaken all the rabble-rousers.
Ibidem wrote:I'm still wondering whether libc.h has been upgraded since 0.1, if the string.h replacements ever happened, and what the status of all that is.
I don't know about upgraded, so much as changed. I did a lot of testing and compilers had difficulty eliminating unused code without the --*-sections flags. Adding static to the functions helped, but made programs built from multiple *.c files larger due to duplicated functions.
After a lot of experimentation I started separating each function into its own file and using an awk script to detect usage of functions and build a stripped down libc.h adding static to functions if only a single c file (main.c) is used or the function is only used once.

Part of this was also preparing for a future version where shared libraries are allowed (my current _start function does not handle shared libraries), so that we are capable of building a single shared library with only functions needed by multiple programs (others will be built in to the single program that uses it) similar to http://libraryopt.sourceforge.net/ but only requiring awk (even the busybox version) and a C toolchain. The resulting library should also be significantly smaller than the libraryopt rebuild, but with the requirement of a busybox/toybox (more like buildroot) style build system.

If having a single libc.h is desirable, I could probably add a build script or make file target to generate it.... possibly even a target to build it into the standard *.h files like string.h, stdio.h, etc... In the mean time musl-libc is what I normally use unless I am trying to squeeze an app into CPU cache.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
minux
Posts: 7
Joined: Sun 10 Jan 2016, 18:56
Location: Jakarta
Contact:

#38 Post by minux »

technosaurus wrote:
smaller alternative to tinyX
http://galos.no-ip.org/siX
Good morning ,do you have the file ?
I think galos is offline.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#39 Post by technosaurus »

minux wrote:
technosaurus wrote:
smaller alternative to tinyX
http://galos.no-ip.org/siX
Good morning ,do you have the file ?
I think galos is offline.
Sorry for the late reply. The copy of siX that I had, does not include a license, so I can' repost it, but I did find some info here:
http://betteros.org/tut/graphics1.php
Its actually the best tutorial I have found on low level Linux graphics.

I've been meaning to do some experiments with replacing X11/xcb with a C99+structs based alternative - total "library" size should be minimal (<32kb) but designed for static builds as a single file header library. My initial experiments actually decreased the size of the binary because only 1 struct is created per request and no extraneous data needs to be saved between function calls (such as data saved in callee clobbered registers that would need to be pushed and popped from the stack) It was also faster because data doesn't need to be copied to a new struct for each request (nearly every X function) ... it also shrinks the code a bit too because it doesn't have to do a memcpy and because of this, allows the compiler to fully optimize and inline many functions into "leaf" functions that can also be easily be inlined (thus eliminating most of the function call overhead).
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#40 Post by technosaurus »

Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#41 Post by technosaurus »

Here are github projects to replace larger versions:
pulseaudio
systemd
logind
udev
libevent
alsa
x11
xserver
glibc over musl
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
RetroTechGuy
Posts: 2947
Joined: Tue 15 Dec 2009, 17:20
Location: USA

#42 Post by RetroTechGuy »

technosaurus wrote:Here are github projects to replace larger versions:
[...]
Thanks Techno... Gonna reply just so I can "pin" this to my list... ;-)
[url=http://murga-linux.com/puppy/viewtopic.php?t=58615]Add swapfile[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#43 Post by musher0 »

Interesting.

But
1) how up-to-date are those projects?

2) how compatible are they with any Puppy?

3) how do you integrate them with any Puppy? One of those authors mention a
way to do a debian install of his project. That is neither fun nor funny. :(

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#44 Post by wiak »

musher0 wrote: 3) how do you integrate them with any Puppy? One of those authors mention a
way to do a debian install of his project. That is neither fun nor funny. :(

BFN.
One of the good things about the DebianDogs being on Puppy forum is that they contain simple tools for extracting and creating debs. Nowadays I normally create my own packages in deb format, since it is so universal (and easy to change to dotpet format as explained next).

However, in most any DebianDog I can extract the deb (a simple filemanager right-click option) and then, once booted back into a Puppy system, run dir2pet, or similar on it, to produce a dotpet. Works fine for simple packages/programs anyway. For more complicated cases you may need to check you have all the correct package dependencies in Puppy prior to producing the dotpet, but that is usually not a difficult task.

I suspect there is a simple deb2pet package available on Pups too (though I can't remember) but sometimes it is better to extract and examine deb package first, to see if you need anything extra to make desired dotpet creation work. Of course, I realise many Pups will install debs anyway, but again success or failure may vary if the deb contents aren't extracted and checked first.

wiak

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#45 Post by technosaurus »

I've been working on a next generation version of puppy for a while that will incorporate many of the lightweight libraries but I am so unsatisfied with the X and C libraries, that I got sidetracked on reimplementing those first. Both will be single header libraries designed for static builds of multi call binaries. Once those are complete, I will put together the MCB with an Xserver, window manager, terminal, editor, browser, web server (for slitaz style configuration) and a few basic utilities. Each program will be a single c file that doesn't share any function names with the others so that all compilers will be able to do whole program optimization for the entire MCB. I haven't made most of the work public yet, but check out the github repositories that I have starred to get an idea... mostly single header libraries if there is one and only permissive licenses.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#46 Post by vovchik »

Dear technosaurus,

You are always doing useful and interesting things. Thanks. I learn from your code...

With kind regards,
vovchik

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#47 Post by technosaurus »

Many of the projects I have linked are single header C libraries, while others are one header file and one .c file. These work a bit different than the traditional C project.

Normally a compiler command line would look something like

$CC main.c -lmylib

For the 2-file projects (1 *.h and *.c file), the header is used just as in any other context, but it its possible to use the *.c file (or even its compiled object file) where one would normally link in a library. (Let me know if this description isn't clear enough)

Ex. $CC main.c mylib.c

The single header libraries are slightly different. You still use it as a regular header file, but it contains a conditionally compiled section that is the equivalent of the *.c file. This must be compiled once and only once by defining the appropriate macro in an appropriate place. You can either define the macro before its #include in the source or use the command line.

Ex. $CC -DMYLIB_IMPLEMENTATION main.c

Here is a basic template for single header c libraries

Code: Select all

//filename.h
//author, copyright
//license
//description, etc...

#ifndef FILENAME_H
#define FILENAME_H

//Define feature test macros
#define _GNU_SOURCE 1

//local includes
#include "my_other_header.h"

//global includes
#include <stdio.h>

//Define config macros
#define Y(...) __VA_ARGS__
#define N(...)
//Followed by config by config options
#define USE_FOO Y
#define USE_BAR N

//Pragmas?

//Constant macros
#define PI 3.14f

//function-like macros
#define X(...) __VA_ARGS__

//enums
enum {A,B,C};

//forward struct declarations
struct G;

//forward typedef declarations;
typedef struct G G;

//typedefs
typedef unsigned char u8;

//struct definitions
struct G {int a,b,c;};

//external variables
extern int extern_global_int;

//function prototypes

//externally visible static inline functions

#endif //FILENAME_H

///above here would go in header (*.h) file, below in C (*.c) file.

#ifdef FILENAME_IMPLEMENTATION
#ifndef FILENAME_IMPLEMENTED
#define  FILENAME_IMPLEMENTED

//Anything above that you don't want to be externally visible can  be here instead

//exported globals: To access, should have corresponding extern in *.h
int global_int; // Are you really sure you need this?

//static (local) variables
static int static_int;

//local function implementations
static inline int get0(void){return 0;}

//exported function implementations
int main_like(int argc, char **argv){
	int x=get0();
	return x;
}
#endif FILENAME_IMPLEMENTED
#endif //FILENAME_IMPLEMENTATION
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

lmemsm
Posts: 51
Joined: Wed 27 Jun 2012, 15:01

picogl

#48 Post by lmemsm »

technosaurus wrote:FWIW I never tracked down the (proprietary?) MorphOS sources either; however, there are a couple of forks with some improvements tinysdgl and picogl IIRC
Some members of the Syllable forum did a comparison of the various forks of tinygl and recommended picogl. I started with the source for it and added some features from other forks. I've been working on adding new features to the code to improve OpenGL compatibility as time allows. I can get Emilia pinball working with it. If anyone's interested, I'd love to compare notes on updating picogl and improving it.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

Re: picogl

#49 Post by technosaurus »

lmemsm wrote:If anyone's interested, I'd love to compare notes on updating picogl and improving it.
Do you have a github project page?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

lmemsm
Posts: 51
Joined: Wed 27 Jun 2012, 15:01

Re: picogl

#50 Post by lmemsm »

technosaurus wrote:Do you have a github project page?
I do, but I really don't use it much. You'll find links to what I'm working on here for now:
http://www.distasis.com/cpp/lmports.htm

Haven't uploaded my picogl modifications yet, because I'm in the middle of making some further changes.

I'm trying to see if I can do anything to improve texture-mapping, but haven't had much luck so far. I did add some basic support for color blending. I'm also using it with GL_FEATURE_RENDER_BITS = 32 so that alpha blending works. I have SDL 2.x back-end support (as well as the SDL 1.x support which was already available) so I can use it with any systems that work with either version of SDL. Was just investigating an issue with RGB settings. If I run the gears demo program with picogl the colors look similar to white/yellow/cyan. The OpenGL glxgears demo has colors red/green/blue. I tried running the picogl gears example program with an OpenGL backend instead of picogl and the colors are still white/yellow/cyan. Am wondering if it's some kind of endian issue with color conversion. With all the different projects and lightweight operating systems that experimented with tinygl or picogl, I'm finding it hard to believe no one would have noticed an issue like that before. Has anyone else ever noticed this? Going to see if I can make the colors better match what I see with OpenGL and then will try to upload what I have to date.

Post Reply