jahboater
Posts: 5636
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:49 pm

ejolson,
ejolson wrote:
Wed Jan 15, 2020 5:24 pm
Though I'm not sure it makes the best teaching language for introducing parallel processing into the beginning curriculum for students at early levels, do you have a link to the C18 standard?
Search for

ISO/IEC 9899:2018(E)

I purchased it as a large PDF file from here I think:
https://www.iso.org/obp/ui/#iso:std:iso ... ed-4:v1:en

Section 7.26 is about threads specifically but they are mentioned everywhere.

Code: Select all

7.26 Threads <threads.h>
7.26.1 Introduction
7.26.2 Initialization functions
7.26.3 Condition variable functions
7.26.4 Mutex functions
7.26.5 Thread functions
7.26.6 Thread-specific storage functions
As noted above, C18 is supposed to be mostly bug fixes for C11. However I don't remember all the thread stuff being in C11 other than some basic atomics. I am probably wrong.

Daniel Gessel
Posts: 120
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:57 pm

jamesh wrote:
Wed Jan 15, 2020 5:37 pm
Others have commented on the text UI, but with regard to Raspbian and GUI's on the lower power devices, it's difficult to see where they can be sped up. The browser is clearly slow, but that in all likelihood is because its just badly written in places and there is not much we can do to rewrite Chromium, or reduce its RAM requirements! As for the desktop itself, it's based on LXDE which is a pretty low end with regard to power requirement already. I guess all these things COULD be improved and sped up, but at colossal cost. If something is running slow it usually requires a LOT of work to improve, and I think that probably that dev time (not that we would have enough people to do it!) would be better spent in other areas. We've already grabbed all the low hanging fruit.
As for a TUI, I used to do everything in Emacs! I’m sure there are many reasons people do/would dislike it, but it might work for some.

After hearing that a lot of the improvements people might like are not in the domain/expertise/resource reach of RPi, I wonder if some kind of bounty website could be created, where issues get posted (like “Chromium is a resource hog!”) and programmers can address them and win the adoration of the greater RPi community! On the other hand, when somebody posts a nice fix here, the do get some pretty good recognition...

Heater
Posts: 15795
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 7:58 pm

I don't buy this oft' touted idea that browser are badly written.

For years we have had Apple, Google, Mozilla, MS, Opera all competing in the browser space. They each have reasons to invest a lot of time and effort into making them optimal.

Rather I think the web standards are insanely huge and complex, which reflects in all the code you need to create browsers. A modern browser has most of an operating system in it.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15795
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:04 pm

jahboater,
C does have threads natively.
See the C18 ISO standard.
Wow, things move so fast in the C world, I missed the memo on that one.

I'm busy reading the C18 final draft here:
https://web.archive.org/web/20181230041 ... d_fdis.pdf

Loads of nice thready stuff in section "7.26.5 Thread functions"
Memory in C++ is a leaky abstraction .

ejolson
Posts: 5128
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:15 pm

paddyg wrote:
Wed Jan 15, 2020 5:46 pm
Harking back a few posts to the "why not invent a new language that beginners can use (like python) but takes advantage of multithreading." That's already been invented and it's... python. Libraries such as numpy, tensorflow, numba and others spot opportunities for parallel processing and "just do it" (often using GPU cores if possible (yes that's a vote from me for CUDA on the pi)).
That achieves the end result, but is similar to finding the answer to a homework problem by looking in the back of the book. You get the answer indeed, but don't learn very much.

My goal is for students to learn parallel programming. For that it is not enough to call subroutine libraries wrapped up for Python that other people wrote using parallel techniques in C. In fact, the unsuitability of Python for implementing a parallel algorithm only perpetuates the misconception that such things are nearly impossible. The problem, when comparing education to real work, is that almost all programming exercises have answers that can be looked up if necessary. While getting good at looking up answers is an important skill, it is distinctly different than learning how to design and write your own subroutines.
Last edited by ejolson on Wed Jan 15, 2020 10:46 pm, edited 3 times in total.

jahboater
Posts: 5636
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:16 pm

Heater wrote:
Wed Jan 15, 2020 8:04 pm
Loads of nice thready stuff in section "7.26.5 Thread functions"
How complete is it do you think, compared to pthreads?
There is also

Code: Select all

7.26 Threads <threads.h>
7.26.1 Introduction
7.26.2 Initialization functions
7.26.3 Condition variable functions
7.26.4 Mutex functions
7.26.5 Thread functions
7.26.6 Thread-specific storage functions

ejolson
Posts: 5128
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:18 pm

Heater wrote:
Wed Jan 15, 2020 7:58 pm
I don't buy this oft' touted idea that browser are badly written.

For years we have had Apple, Google, Mozilla, MS, Opera all competing in the browser space. They each have reasons to invest a lot of time and effort into making them optimal.

Rather I think the web standards are insanely huge and complex, which reflects in all the code you need to create browsers. A modern browser has most of an operating system in it.
I fully agree. It appears, however, that one of the optimization goals is to create patented standards so complex that only the established companies can compete. This, of course, works to the disadvantage of smaller companies and computers such as the Raspberry Pi.

W. H. Heydt
Posts: 12357
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:26 pm

ejolson wrote:
Wed Jan 15, 2020 8:18 pm
Heater wrote:
Wed Jan 15, 2020 7:58 pm
I don't buy this oft' touted idea that browser are badly written.

For years we have had Apple, Google, Mozilla, MS, Opera all competing in the browser space. They each have reasons to invest a lot of time and effort into making them optimal.

Rather I think the web standards are insanely huge and complex, which reflects in all the code you need to create browsers. A modern browser has most of an operating system in it.
I fully agree. It appears, however, that one of the optimization goals is to create patented standards so complex that only the established companies can compete. This, of course, works to the disadvantage of smaller companies and computers such as the Raspberry Pi.
I think it's rather more of a "kitchen sink" problem in that every requested feature--including the kitchen sink--is put in and the result is huge and ungainly. It's a common, if not quite so extreme, problem with other programs, including OSes. The early unix kernel, for instance was some 9K lines of C and about 1K lines of assembly language to take care of requirements specific to particular hardware. That makes it less surprising that unix of that period would run quite well on relatively small, slow (by modern standards) systems.

Heater
Posts: 15795
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:35 pm

What patented standards?

I don't find many : http://www.cptech.org/ip/business/webst ... index.html
Memory in C++ is a leaky abstraction .

Heater
Posts: 15795
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:46 pm

jahboater,
How complete is it do you think, compared to pthreads?
Not sure yet. It's all pthreads under the hood anyway as far as I an tell. At least in GCC/Clang.

Amazingly google finds me remarkably little discussion of C11 threads around then net. Like only this:
https://nanxiao.me/en/first-taste-of-c-thread-apis/
https://riptutorial.com/c/example/31557 ... le-example

No wonder I did not get the memo.

Anyway it seems unlikely I will ever be writing anything in C again. Except possibly for 8 bit AVRs and the like. Rust and Javascript will do just fine.
Memory in C++ is a leaky abstraction .

ejolson
Posts: 5128
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 10:52 pm

Heater wrote:
Wed Jan 15, 2020 8:35 pm
What patented standards?

I don't find many : http://www.cptech.org/ip/business/webst ... index.html
I was thinking H.264 video. This is why Google bought VP8 and created VP9. If there weren't such open alternatives the mpeg consortium would likely monetise online video in a major way.

emma1997
Posts: 762
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 11:17 pm

ejolson wrote:
Wed Jan 15, 2020 3:06 am
Develop a new programming language for beginners to learn
Yeah!!! It's been MONTHS since anything completely new for the sake of new has come along. That old stuff is getting almost useful by now. We obviously need something with additional levels of complexity and obfuscation:
Attachments
LEANING_TOWER_OF_BABEL_4.JPG
LEANING_TOWER_OF_BABEL_4.JPG (104.95 KiB) Viewed 1336 times

X-Gen
Posts: 91
Joined: Fri Dec 06, 2019 12:08 pm

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 12:19 am

ShiftPlusOne wrote:
Wed Jan 15, 2020 4:40 pm
X-Gen wrote: Raspbian is great, but not tuned for this low end hardware. Mainly the browser. But it would be nice to have a text based GUI (believe it or not, but it used to exist, an ultra low memory asci/terminal based GUI and programs).
There's no shortage of TUI applications still.

I haven't tried it, but twin should work:
https://github.com/cosmos72/twin/

If that's what you're into there are plenty of browsers you can use - like elinks. Throw in a file manager like midnight commander and you should be covered.
NICE!!
Too bad there's no package maintainer to develop a desktop around this! :)

X-Gen
Posts: 91
Joined: Fri Dec 06, 2019 12:08 pm

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 12:59 am

emma1997 wrote:
Thu Jan 16, 2020 12:49 am
drgeoff wrote:
Thu Jan 16, 2020 12:28 am
Oxymoron.
Hey, no personal attacks! Against forum rules!
Lolz!

It's not an oxymoron though.
A text based GUI is a Graphical interface based on Text. Can happen in X11 or in terminal.
The difference is, that with such a GUI, you have (text based) icons, a text based start bar, etc....
Ultra low on resources (a few MB of RAM).
Perfect for people who're running ultra low hardware (like the Zero), and want a working GUI.
Raspbian works, but there needs to be a browser alternative.
And once you start cutting down on browser alternatives, one can trim down all the other programs as well, and create an entirely new desktop.

Image
Last edited by X-Gen on Thu Jan 16, 2020 1:01 am, edited 1 time in total.

emma1997
Posts: 762
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 1:28 am

Hah... I think I see a tiny forth in there too.

BTW speaking of text protocols all my recent Pi installs complain when reading regular text files from PC. I have to click options to clear it up. I don't have access to details right now but wonder if anybody else ran into this?

If I eventually save it next time it's ok and looks same on the PC but wonder what I can do to stop this.

Daniel Gessel
Posts: 120
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 1:33 am

emma1997 wrote:
Thu Jan 16, 2020 1:28 am
Hah... I think I see a tiny forth in there too.
But Lisp and Prolog are just floating in the clouds above...

W. H. Heydt
Posts: 12357
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 1:35 am

X-Gen wrote:
Thu Jan 16, 2020 12:59 am
Perfect for people who're running ultra low hardware (like the Zero), and want a working GUI.
1GHz and 512MB RAM is "ultralow" hardware? Who knew?

(For what it's worth, I've run a full Raspbian GUI on a 256MB Pi Model B.)

hippy
Posts: 7368
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Future of raspberry pi

Thu Jan 16, 2020 1:49 am

TimG wrote:
Tue Jan 14, 2020 9:58 pm
It would be fantastic to see somebody pick up development of the WiringPi library. Of all the various GPIO libraries, WiringPi was especially easy to use -- even in shell scripts.
I don't know if it should be WiringPi but I think it would be great if there were a single recommended GPIO utility interfacing to something doing GPIO marshalling with a standardised API, with wrappers and libraries for the common languages, at least C, C++, Python, Scratch and perhaps even Assembler, with an equivalent available for Bare Metal use too.

Something comprehensive which has higher level support for specific hardware devices, extensible so devices can be easily created and added to that.

That may be something based on libgpio or wrapped around that, but, whatever it is, as easily usable and user friendly as the current libraries are.

It will face resistance, probably quite a lot, but removal of /dev/gpiomem would force access through a common API to the marshalling handler, allowing programs to be able to claim and use GPIO, while preventing programs using what other programs or OS are already using, accessing things they really shouldn't.

Not having that GPIO marshalling has always seemed a weak spot that goes against the philosophy of protecting the OS and programs from what anything else is doing. I can understand how and why it is, but I think it's time to do it better, and it's probably better to get a grip on that sooner rather than later.

I wouldn't want to lose WiringPi, RPI.GPIO, Zero.GPIO, gpio, raspi-gpio, pigpio and all the rest, because if people want to use those then so be it, but I think it would be better if they could all call the common API rather than doing it themselves.

And I know it's a big, fundamental change, but I believe it would be worth doing.

ejolson
Posts: 5128
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 1:55 am

Another wish-list software item might be a set of cross compilers for the Pi included as a standard package on the x86 version of Raspberry Pi desktop for personal computers.

In line with this suggestion, if a standard GPIO library were supported, it would be nice to have a virtual GPIO emulation library available, again for the x86 version of Raspberry Pi desktop.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26398
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 10:15 am

Deleted a load of off topic posts. When I come back to this thread to note down any interesting suggestions, I have no desire to read through a load of unrelated stuff, so please keep on topic. Plenty of other topics you can talk about line endings on.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26398
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi

Thu Jan 16, 2020 10:21 am

hippy wrote:
Thu Jan 16, 2020 1:49 am
TimG wrote:
Tue Jan 14, 2020 9:58 pm
It would be fantastic to see somebody pick up development of the WiringPi library. Of all the various GPIO libraries, WiringPi was especially easy to use -- even in shell scripts.
I don't know if it should be WiringPi but I think it would be great if there were a single recommended GPIO utility interfacing to something doing GPIO marshalling with a standardised API, with wrappers and libraries for the common languages, at least C, C++, Python, Scratch and perhaps even Assembler, with an equivalent available for Bare Metal use too.

Something comprehensive which has higher level support for specific hardware devices, extensible so devices can be easily created and added to that.

That may be something based on libgpio or wrapped around that, but, whatever it is, as easily usable and user friendly as the current libraries are.

It will face resistance, probably quite a lot, but removal of /dev/gpiomem would force access through a common API to the marshalling handler, allowing programs to be able to claim and use GPIO, while preventing programs using what other programs or OS are already using, accessing things they really shouldn't.

Not having that GPIO marshalling has always seemed a weak spot that goes against the philosophy of protecting the OS and programs from what anything else is doing. I can understand how and why it is, but I think it's time to do it better, and it's probably better to get a grip on that sooner rather than later.

I wouldn't want to lose WiringPi, RPI.GPIO, Zero.GPIO, gpio, raspi-gpio, pigpio and all the rest, because if people want to use those then so be it, but I think it would be better if they could all call the common API rather than doing it themselves.

And I know it's a big, fundamental change, but I believe it would be worth doing.
Interesting. We want to move away from anything accessing the HW directly, so from C would recommend libgio (package gpiod). pigpio we install by default, but not sure how that access the pins - if it's not via libgpio then we should probably consider moving away from that. There is a python binding for libgoio, called gpio-next which is probably the best approach.

But this is the sort of thing that this thread is now aimed towards, so thanks for keeping on topic!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jahboater
Posts: 5636
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 10:32 am

ejolson wrote:
Thu Jan 16, 2020 1:55 am
Another wish-list software item might be a set of cross compilers for the Pi included as a standard package on the x86 version of Raspberry Pi desktop for personal computers.

In line with this suggestion, if a standard GPIO library were supported, it would be nice to have a virtual GPIO emulation library available, again for the x86 version of Raspberry Pi desktop.
Both of these are very good idea's.

My only thought is that as Pi models progress, the perceived need for cross compilation will reduce.
For me the Pi4 4GB is plenty fast enough to build absolutely anything. I have not built the kernel recently, but I bet the Pi4 could do it with ease. The 16GB octa core Cortex-A77 Pi5 will be faster than most PC's :).

Users should be encouraged to exploit the rich software development environment on the Pi, and specifically, learn the effective use of make.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26398
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 10:50 am

jahboater wrote:
Thu Jan 16, 2020 10:32 am
ejolson wrote:
Thu Jan 16, 2020 1:55 am
Another wish-list software item might be a set of cross compilers for the Pi included as a standard package on the x86 version of Raspberry Pi desktop for personal computers.

In line with this suggestion, if a standard GPIO library were supported, it would be nice to have a virtual GPIO emulation library available, again for the x86 version of Raspberry Pi desktop.
Both of these are very good idea's.

My only thought is that as Pi models progress, the perceived need for cross compilation will reduce.
For me the Pi4 4GB is plenty fast enough to build absolutely anything. I have not built the kernel recently, but I bet the Pi4 could do it with ease. The 16GB octa core Cortex-A77 Pi5 will be faster than most PC's :).

Users should be encouraged to exploit the rich software development environment on the Pi, and specifically, learn the effective use of make.
Not done a kernel compile on a Pi4 to compare, still cross compile from a i7 with 16GB RAM and a SSD, and that still takes over 1/2hr. (That's in a Linux VM, I should probably allocate more cores to it!). I think the SD card is probably quite a bottle neck for a kernel build, so an SSD on a Pi would make it a lot faster.

But I like the idea.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

User avatar
rpdom
Posts: 16980
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 11:21 am

A more standard GPIO library would be good.

I tend to use my own code to poke things via /dev/gpiomem but that won't let me access PWM and other functions. If that could be extended, or some other /dev/ interface created that would be nice.
Unreadable squiggle

ankith26
Posts: 240
Joined: Mon Mar 25, 2019 11:08 am
Location: /home/pi/pythonprojects/test.py
Contact: Website

Re: Future of raspberry pi - software related

Thu Jan 16, 2020 11:23 am

This is a nice to have feature(may be very difficult to implement), but how about a forum app that comes pre-installed on the raspberry pi. This way, pi users get exposed to the forum automatically and they get their questions cleared. The interface should be fairly easy to use, just like browser version and users must be encouraged to sign up on the forum. Even the moderating job should be easy for you guys on this platform.
I sat thinking for 5 minutes on what to put here. Finally I put something like this.
Check out my github page @ https://github.com/ankith26

Return to “General discussion”