Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 19 Oct 2017, 00:03
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Unbloated coding resources
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 3 [38 Posts]   Goto page: Previous 1, 2, 3
Author Message
technosaurus


Joined: 18 May 2008
Posts: 4745

PostPosted: Wed 05 Nov 2014, 17:22    Post subject:  

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
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson

PostPosted: Thu 06 Nov 2014, 00:45    Post subject:  

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.
Back to top
View user's profile Send private message 
vovchik


Joined: 23 Oct 2006
Posts: 1441
Location: Ukraine

PostPosted: Thu 06 Nov 2014, 02:55    Post subject:  

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
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson

PostPosted: Thu 06 Nov 2014, 16:27    Post subject:  

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?
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4745

PostPosted: Thu 06 Nov 2014, 20:59    Post subject:  

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
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson

PostPosted: Mon 10 Nov 2014, 19:13    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4745

PostPosted: Mon 10 Nov 2014, 23:29    Post subject:  

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/bugreport.cgi?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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
minux


Joined: 10 Jan 2016
Posts: 7
Location: Jakarta

PostPosted: Mon 07 Mar 2016, 18:17    Post subject:  

technosaurus wrote:


smaller alternative to tinyX
http://galos.no-ip.org/siX



Good morning ,do you have the file ?
I think galos is offline.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 3 of 3 [38 Posts]   Goto page: Previous 1, 2, 3
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0756s ][ Queries: 14 (0.0079s) ][ GZIP on ]