On July 8, 2018 5:24:53 PM PDT, don fisher
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in
levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk
On 07/08/2018 09:52 AM, Anton Aylward wrote: the low packages for
most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any projects that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must
admit that when I first met linux it was before kernel version 1.x, and
the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane.
Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run directory, or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was
trying to do was get a picture of the system so I would have a chance with my debugging task.
I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series.
When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets.
So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-)
Thanks again, Don
Sorry to inform you that John died on Friday. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org