GNU is an operating system and an extensive collection of computer software. GNU is composed wholly of free software, most of which is licensed under the GNU Project's own General Public License / GPL /.
... if some drastic change didn't happen since i heard:
- GPL is 'General Public License',
- GPL is in short a license for free software,
- GPL-licensed tools can be used non-commercially,
- solutions made with GPL-licensed tools are required to use GPL license as well.
... if some drastic change didn't happen since i heard:
- LGPL is 'Lesser General Public License',
- LGPL-licensed tools can be used commercially.
GCC is short for GNU Compiler Collection.
... there's more to GNU as well, more GNU tools, etc.
... composing GPL wasn't a meek achievement, it's one of greatest efforts made for free software producers protection.
The license was originally written by Richard Stallman of the Free Software Foundation for the GNU Project, and grants the recipients of a computer program the rights of the Free Software Definition.
... for many GNU tools, licenses, etc ... are 'holy'.
... i think GNU & FSF / Free Software Foundation / should be given proper respects.
Sunday, 25 August 2019
Saturday, 10 August 2019
'Memory Map'.
... there are abstraction levels, high & low.
High abstraction levels are useful to plan, to experiment, to prototype, to handle complexity, ... to implement as well.
Low abstraction levels are useful foundation, allow to use hardware extremely efficiently, but usually costs are too extreme, costs measured in time, money & other resources.
... years ago a friend borrowed me 'Atari ST Memory Map'. More than list of memory adressess, where to put which digit so certain results can be achieved.
... if i remember correctly, it was a lot of theory and graphical models, not only 'electronic circuits', also theoretical-scientific models, explaining theory that resulted in many electronic circuits, and many other solutions - both hardware and software.
'High abstraction level approach to low abstraction level solutions'.
... why i inform about this on Project Wraithstar?
... it's just an idea to consider - should we - including me, or without me - serve society that way, as well?
High abstraction levels are useful to plan, to experiment, to prototype, to handle complexity, ... to implement as well.
Low abstraction levels are useful foundation, allow to use hardware extremely efficiently, but usually costs are too extreme, costs measured in time, money & other resources.
... years ago a friend borrowed me 'Atari ST Memory Map'. More than list of memory adressess, where to put which digit so certain results can be achieved.
... if i remember correctly, it was a lot of theory and graphical models, not only 'electronic circuits', also theoretical-scientific models, explaining theory that resulted in many electronic circuits, and many other solutions - both hardware and software.
'High abstraction level approach to low abstraction level solutions'.
... why i inform about this on Project Wraithstar?
... it's just an idea to consider - should we - including me, or without me - serve society that way, as well?
Saturday, 3 August 2019
Objects Graph, Complete Model of a Program.
Object Graphs.
Directed Objects Graph / pl: 'Skierowany Graf Obiektów' / can be a complete model of a program, that can be executed. Or it can be a data model as well.
Values of Objects' references/pointers/handles/etc ... are also a part of state, as any variable's value is, as well.
In a Directed Graph / pl: 'Graf Skierowany' / we have 'dots & arrows', 'nodes & arrows'.
In a directed object graph, objects are 'dots/nodes', references/etc are 'arrows'.
Graphs can be either 'directed' or 'undirected', but in this article we don't need to use 'undirected graphs'.
Resources.
Classes are 'objects blueprints', a part of application's static resources.
After Classes are written & ready, objects can be created.
Other resources as graphic image files, dvd iso files, localization text files, etc ... are also a part of application's static configuration, can be used in objects graph as a part/whole of objects graph's initial state.
Graphs, Construction & Program's Execution.
I call objects graph's construction, including initial state's set-up: 'Configuration', 'Application Configuration', 'Object Graph Configuration'.
Different versions of application are just different objects graphs, with different initial state. Different versions sometimes do not need to be backward-compatible, sometimes are wholly different software - more than functionality reductions and new functionality additions. Code should be reusable, usable in many projects.
Objects graph configuration can be done manually - in one of 'entry points' to application, or tools as Java's
'Spring Framework' with it's 'xml configuration' can be used.
After objects graph is configured, we can 'launch' a proper entry point / for example: one of main(...) methods /, so application starts.
We can have many 'entry points', and many 'root objects' ... but eventually we might need to choose which 'entry point' to use at that moment, which 'application/version' to run this time.
Summarizing, object-oriented application's development & launch goes through following phases:
1. Write Classes,
2. Construct Objects Graph, setting-up initial state using 'hardcoded' data and 'static resources' as well.
3. Launch one of Entry Points, providing values to arguments if neccessary.
4. Application starts, can enter 'Dynamic Initialization Phase' - if needed,
5. Applicaion switches to 'Running Phase', starts doing it's job,
6. ...
Directed Objects Graph / pl: 'Skierowany Graf Obiektów' / can be a complete model of a program, that can be executed. Or it can be a data model as well.
Values of Objects' references/pointers/handles/etc ... are also a part of state, as any variable's value is, as well.
In a Directed Graph / pl: 'Graf Skierowany' / we have 'dots & arrows', 'nodes & arrows'.
In a directed object graph, objects are 'dots/nodes', references/etc are 'arrows'.
Graphs can be either 'directed' or 'undirected', but in this article we don't need to use 'undirected graphs'.
Resources.
Classes are 'objects blueprints', a part of application's static resources.
After Classes are written & ready, objects can be created.
Other resources as graphic image files, dvd iso files, localization text files, etc ... are also a part of application's static configuration, can be used in objects graph as a part/whole of objects graph's initial state.
Graphs, Construction & Program's Execution.
I call objects graph's construction, including initial state's set-up: 'Configuration', 'Application Configuration', 'Object Graph Configuration'.
Different versions of application are just different objects graphs, with different initial state. Different versions sometimes do not need to be backward-compatible, sometimes are wholly different software - more than functionality reductions and new functionality additions. Code should be reusable, usable in many projects.
Objects graph configuration can be done manually - in one of 'entry points' to application, or tools as Java's
'Spring Framework' with it's 'xml configuration' can be used.
After objects graph is configured, we can 'launch' a proper entry point / for example: one of main(...) methods /, so application starts.
We can have many 'entry points', and many 'root objects' ... but eventually we might need to choose which 'entry point' to use at that moment, which 'application/version' to run this time.
Summarizing, object-oriented application's development & launch goes through following phases:
1. Write Classes,
2. Construct Objects Graph, setting-up initial state using 'hardcoded' data and 'static resources' as well.
3. Launch one of Entry Points, providing values to arguments if neccessary.
4. Application starts, can enter 'Dynamic Initialization Phase' - if needed,
5. Applicaion switches to 'Running Phase', starts doing it's job,
6. ...
Subscribe to:
Posts (Atom)