Fedora Linux Support Community & Resources Center
  #46  
Old 18th November 2014, 08:16 AM
sea Offline
"Shells" (of a sub world)
 
Join Date: May 2011
Location: Confoederatio Helvetica (Swissh)
Age: 37
Posts: 4,280
linuxfedorafirefox
Re: VICI: A Software Development Project

Dont get this wrong, but we always seem to struggle with the same things.
I so much see my progress in yours
While neither working at the same thing, nor talking about next steps.

I've just figuerd me need to write manpages, and since they are not very pleasent, wrote a manpage generator, actualy just a template using preset (or assumeed/generated variables) like 'name', license, 'url', webpage,, email, project/app name, etc...

Personaly i think its quite difficult to find the balance between:
  • Split up every functionality, to its lowest reasonable purpose
  • Keep the 'capabilites' together, so one does not do the same thing twice (or functions doing way too similar things) due to too many functions.

Looks promising, keep it up
__________________
EFI Cheatsheet :: http://forums.fedoraforum.org/showthread.php?t=298546
Video Handler Script (VHS) (mass re-encode videos, screenrecorder, console music/webradio player, ...) :: http://forums.fedoraforum.org/showthread.php?t=299182
Windows 8+ & Fedora 20+ Dualboot :: http://forums.fedoraforum.org/showthread.php?t=298161
Reply With Quote
  #47  
Old 18th November 2014, 02:15 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

You raise some good points.

I will need to create a man page for the VICI built-in commands, much as has been done for bash if you do "man cd" for example.

I am rather strongly of the opinion that having duplicate code is a very bad idea. I once had the pleasure (?) of maintaining a quite large system where many of the programs had been written by copying some other similar program and making some changes. When you had to make a change, it often needed to be made in six places - some of which would only be discovered when users complained of inconsistencies.

Getting the balance right for module size is difficult. Modules that are too large take too long to design and build and are more difficult to maintain. If the modules are too small then you end up with a maze of interfaces and it will often be that the modules lose their independence.

In the case of VICI, I think that the interpreter is a bit too large and could have the thread pool functionality split off into a support library. Conversely the symbol and canvas libraries are a bit too interdependent and it might have been better to have them as a single module.

Unfortunately it is often the case that the actual size of a module does not become apparent until well into the detailed design phase. You then need to decide if it is worth going back to the high level design to repartition the modules, or push on into the coding phase with the current design and defer fixing the high level design to a subsequent development cycle.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #48  
Old 18th November 2014, 11:33 PM
sea Offline
"Shells" (of a sub world)
 
Join Date: May 2011
Location: Confoederatio Helvetica (Swissh)
Age: 37
Posts: 4,280
linuxfedorafirefox
Re: VICI: A Software Development Project

What i've figured about modules is, that the most important thing is standardized communication.
Working with loops and arrays gets 'it' somewhere close to.

By that i mean, see modules as classes.
The pictures look promising, though, me have no idea how you achieve it.

But about symbols, i'd thing of a grid, where each item i drag onto the grid, into the 'script', would contain a list of attribues, actions and maybe even triggers.
An example of a module based application i wrote one and a half decade ago. T4C-Desktop.
It was a helper, and offered some calucators for diffrent quests of the game.
Anyway, i had 4 sections, of which 3 were for regular games, and the 4th only visible to game masters (actualy, the module itself caused that 4th section list to be displayed).

Each of the modules was given:
  • a cathegory.
  • a name
  • a version
  • a hwnd
  • a trigger resize

The cathegory was read by the main application, to append the module (an activex.dll) to a given list(box), if the list did not exist, it was created using object indexing.
The name showed what was seen in the list.
The version was used for the external updater to check with the remote available files.
The hwnd wich contained the hwnd of the dll's main void().
The resize, which executed the resize trigger of the dll's hwnd where all the resize was coded.

On that hwnd, usualy a picturebox, i could place everything and anything i wanted, because inside the module/function, its irrelevant.

Now to the 'current' time, script-tools, my former baby, is currently on ice, due to the fact that TUI represents and enables one to do most of the things i wanted to achieve with scripts tools.
Well not exactly, but me can now just use a single script, to manage all the other scripts.
Which enables me to practice linux philosohphy mantra, everything is a file, and a function should just do its single function, but that right!

Everything that interacts with variables that may and probably will be diffrent than what we program, will challenge the mechanism of finding the cause of misunderstandings between the moduels.

I'd use something like a grid for the diffrent code blocks to align.
Seeing each block as an object, which offers points like:
  • description
  • help_id
  • class
  • icon

Where icon could be an int, refering to the index of an image list associated with the object/module.
Descripton needs no explanation, where as the help_id would be something like an index.
Class would define the actualy type of the object, eg. select, while true, if then.., etc..

Want i want to say is, the names might be diffrent, and it might be 3 or 6 rather than 4 or 5 as shown, but once one decides whether its just used to retrieve a variable, to actualy do something, or to display one of the two, the amount of 'interfaces' is massivly reduced.

Once you have define the modules, you can define the diffrent type of classes, which all will be using the same class structure/interfaces, but diffrent funtions where required, but due to class inherit, a template could be resued, simply overwriting non-applying interface-(as in code-wise, not gui-wise)-functions.

Its kind of difficult to write what i wanted to say.
Hope you understand, hope it helps.
__________________
EFI Cheatsheet :: http://forums.fedoraforum.org/showthread.php?t=298546
Video Handler Script (VHS) (mass re-encode videos, screenrecorder, console music/webradio player, ...) :: http://forums.fedoraforum.org/showthread.php?t=299182
Windows 8+ & Fedora 20+ Dualboot :: http://forums.fedoraforum.org/showthread.php?t=298161
Reply With Quote
  #49  
Old 19th November 2014, 04:07 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Quote:
Originally Posted by sea View Post
What i've figured about modules is, that the most important thing is standardized communication.
Working with loops and arrays gets 'it' somewhere close to.

By that i mean, see modules as classes.
Not really. Modules are a higher level building block than classes. A module should have some functional coherence - such as everything to do with reading and writing XML files, or parsing EBNF or displaying a syntax graph.

While having a standardised interface would be nice, on any real world project many of the modules will be third party libraries developed with no knowledge of your intended use. I am putting some ideas together for another project and the modules are not even in the same language (some Java, some C++) and some will use a web interface while others will need to be wrapped in something like CORBA.

Quote:
The pictures look promising, though, me have no idea how you achieve it.
I assume you mean the screen shots on the Source Forge page. My detailed design approach is to do a rough implementation in C++. The code for this is in the proto branch. This allows me prove that the design will work and has the side effect of producing stuff for the design documentation, such as user interface images and collaboration diagrams (via tracing the execution).

Quote:
But about symbols, i'd thing of a grid, where each item i drag onto the grid, into the 'script', would contain a list of attribues, actions and maybe even triggers.
An example of a module based application i wrote one and a half decade ago. T4C-Desktop.
It was a helper, and offered some calucators for diffrent quests of the game.
Anyway, i had 4 sections, of which 3 were for regular games, and the 4th only visible to game masters (actualy, the module itself caused that 4th section list to be displayed).

Each of the modules was given:
  • a cathegory.
  • a name
  • a version
  • a hwnd
  • a trigger resize

The cathegory was read by the main application, to append the module (an activex.dll) to a given list(box), if the list did not exist, it was created using object indexing.
The name showed what was seen in the list.
The version was used for the external updater to check with the remote available files.
The hwnd wich contained the hwnd of the dll's main void().
The resize, which executed the resize trigger of the dll's hwnd where all the resize was coded.

On that hwnd, usualy a picturebox, i could place everything and anything i wanted, because inside the module/function, its irrelevant.
In researching VICI I found quite a few examples of visual programming languages that seem to be similar to what you describe. The difference is that VICI is for scripting the existing Linux command line programs rather than objects that exist within the scope of the program.

Quote:
Now to the 'current' time, script-tools, my former baby, is currently on ice, due to the fact that TUI represents and enables one to do most of the things i wanted to achieve with scripts tools.
Well not exactly, but me can now just use a single script, to manage all the other scripts.
Which enables me to practice linux philosohphy mantra, everything is a file, and a function should just do its single function, but that right!

Everything that interacts with variables that may and probably will be diffrent than what we program, will challenge the mechanism of finding the cause of misunderstandings between the moduels.
That comment is the basis of object oriented programming.
It used to be the style to have a program consisting of a large collection of data items (variables) and a collection of functions that acted on that data. As soon as subtle differences in meanings for a variable crept into the program things would soon go awry.
Wrapping the data in classes isolates the data and hopefully enables it to have a consistent meaning. Modules should have a similar functional interface and protect their data from misguided updates.

Quote:
I'd use something like a grid for the diffrent code blocks to align.
Seeing each block as an object, which offers points like:
  • description
  • help_id
  • class
  • icon

Where icon could be an int, refering to the index of an image list associated with the object/module.
Descripton needs no explanation, where as the help_id would be something like an index.
Class would define the actualy type of the object, eg. select, while true, if then.., etc..

Want i want to say is, the names might be diffrent, and it might be 3 or 6 rather than 4 or 5 as shown, but once one decides whether its just used to retrieve a variable, to actualy do something, or to display one of the two, the amount of 'interfaces' is massivly reduced.

Once you have define the modules, you can define the diffrent type of classes, which all will be using the same class structure/interfaces, but diffrent funtions where required, but due to class inherit, a template could be resued, simply overwriting non-applying interface-(as in code-wise, not gui-wise)-functions.

Its kind of difficult to write what i wanted to say.
Hope you understand, hope it helps.
Having a grid to align the symbols on the flowchart is on my todo list along with quite a few other ideas. First I want to get _something_ working, then the embellishments can get added later.

Unfortunately, I am not sure I am understanding the central point that you are trying to make. I suspect that our differing views on the nature of modules and classes is getting in the way
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #50  
Old 19th November 2014, 12:28 PM
sea Offline
"Shells" (of a sub world)
 
Join Date: May 2011
Location: Confoederatio Helvetica (Swissh)
Age: 37
Posts: 4,280
linuxfedorafirefox
Re: VICI: A Software Development Project

Guess that is because i describe modules and classes the way i actualy used them, rather that with their 'offical technical' description.

I'll try again using an example of my own:
With scripts-tools i wanted so many things, i now have them split up into 3 different projects, with an updated script-tools still to come again.
At first i wanted to have (what now is) TUI available when one 'sources scripts.tools', so it would then provide all functions needed to display the tui. Also i wanted to be able to call each of the functions (scripts within subfolders) of scripts-tools directly. Furthermore i also wanted to include assistant scripts to help compiling, package, build an iso, etc.

So to achieve all this, and since each task (as rpm, or tweak grub) had used the same commands i wrote functions of the re-used code, saved them within an 'include' path, which was read when script-tools were started/-config sourced.
But this increased the problem of resulting too many functions doing very similar things, but with diffrent names.

Bugfixing any error occouring was a horror, because fixing one, raised almost certainly an error somewhere else.

Then i started to split up script-tools into diffrent (sub?) projects, starting with TUI, which now provides tui-browser, which is what script-tools was thought for. Handling diffrent folders as arguments to execute scripts that are stored within them.

Anyway, TUI now beeing an independant tool, i guess this would actualy be an official description of a modul, i can use its commands without fearing to break TUI when fixing the scripts using it, eventough depending on it.
And the developer project management is now seperate as well, called "dev-scripts", which no longer uses 'includeds' providing functions, but config files and each script using the config files, provides everything needed to handle its task.
So rather than sourcing the (previous) 'includes' and the config files, ignoring the actual scripts handling the tasks, i now execute the scripts, which load their required stuff by them self.

All this said, figured i could say it short:
Eventhough you already write an 'editor' (visual anyway) to put together scripts, my suggestion would be:
Write an 'editor' (or just a very simple way) for the 'codeblocks' to be used by the main editor.

As in, if you had a look at Video Handler Script, it uses 'container' files, which could be 'code-blocks', providing the required info so the main programm.
So to support a new target-container (code-block used by the visual editor), all i need to do is to create a file with variables and their settings. The main application will then handle those expected variables, and act accordingly.
The passed arguments/options are then applied where applicable and/or required.

My defintion of a module would be:
A file/function providing functions and variables, maybe default settings. While the functions for each module should follow the very same naming scheme.

So one could call in pseudo code: (since bash is not comparable to C )
Code:
LIST=$(cd /path/to/modules/;ls)
ARGS="${@}"
task="something"
task2="different"

for MODULE in $LIST ;do
	source $MODULE
	$task code $ARGS
	$task2 label $ARGS
done
Maybe it would be more like:
Code:
select MODULE in /path/to/codeblocks;do
source $MODULE
# $task is a functionname within each of the MODULE's
	case $MODULE in
	'case')  	echo 'ask for case-switches' ;;
	'if') 		read -p 'check if elif is req' INFO
			$task code $INFO
			;;
	*)	$task code ;;
	# ....
	esac
	break
done
Where each MODULE would be a 'configfile' for a certain 'codeblock'.
Each of its functions, 'something' and 'different' are available in all modules, but generate the output required for itself.

I merley try to share the idea, the code is just an attempt to illustrate it.
Hope this helps
__________________
EFI Cheatsheet :: http://forums.fedoraforum.org/showthread.php?t=298546
Video Handler Script (VHS) (mass re-encode videos, screenrecorder, console music/webradio player, ...) :: http://forums.fedoraforum.org/showthread.php?t=299182
Windows 8+ & Fedora 20+ Dualboot :: http://forums.fedoraforum.org/showthread.php?t=298161
Reply With Quote
  #51  
Old 4th December 2014, 12:59 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

OK, I will be taking a break from Vici for a short while until next year.
I would like to thank those that have been reading this thread - it has been encouraging.

I had decided to refrain from updating the system while the design work was being undertaken so that the entire design would be consistent. As a result the system is now well and truly out-of-date at F17. Before I start on the coding phase I think it is about time to upgrade. Since the programming is also likely to take a while, I am thinking that the rapid upgrade cycle of Fedora will be an inconvenience, and that Scientific Linux will be a more stable development environment.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #52  
Old 8th January 2016, 08:03 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
VICI: A Software Development Project - Continued

This is a continuation of the thread I started previously: http://forums.fedoraforum.org/showthread.php?t=298342

It's been a while since I wrote anything on this project, so, now that development work is finally underway again I thought I would continue the thread to describe what is happening.

Over the last year or so I have been experimenting with some other programming ideas. During the course of that work my infrastructure library has been enhanced and I have some better ideas for doing testing. So the first round of development has been to update the infrastructure library and test harness.

There has been a rather annoying complication to the project. I use Eclipse as my IDE since this project is just complicated enough for it to be more of a help than a hindrance. However I updated my machine from Fedora17 to Scientific Linux 7.1 and this means that I have jumped a couple of versions of Eclipse and the new version has a Subversion implementation that is incompatible with the old version. This means that I have had to use a new check-out of the code rather than continue with my existing code base.

I have split the original infrastructure library(libcfi) into two parts, separating out the test harness and tracing into a new library (libcdi) for development infrastructure since this library would not normally be used in the production code, but just during development and testing. However, libcfi has gained a few additional modules initially for supporting testing, but also potentially generally useful for other purposes. The plug-in module is one of these - it allows us to run tests on completed programs, but can be used for other dynamically loaded libraries.

The tracing module has undergone an extensive overhaul. It can now handle multi-threaded programs and gather trace messages from several interacting programs. The program for creating diagrams from this has also been enhanced so that it produces much clearer diagrams by filtering out repeated processing.

The design for the test harness has been reconsidered. It now uses TestCase objects where the constructor sets up the conditions for the test and the destructor returns the system to its original state. The test harness now creates and executes these TestCase objects. Originally I had a separate test harness for handling asynchronous events, but this is now just another type of TestCase so the asynchronous tests can be mixed in with the more conventional tests.

The plug-in module has a mode where the dynamically loaded library is executed immediately. This is used to enable us to run the test harness inside a completed program without having the test harness as part of the delivered program. (Test code should not be left in programs as it can easily be the source of bugs or security issues.)

I have a added a new sub-project to VICI for testing GUI programs. It extends the test harness plug-in idea to include a simple scripting mechanism for GUI widgets. The only cost for the GUI program is that it needs to provide a function that associates names with the widgets of interest - and this is not even called unless the test plug-in is loaded. I did this as a separate project since it introduces a dependency on the Graphics toolkit (Qt in this case) and the build Makefile needs some additions that are not required for the other infrastructure libraries.

I have still to update the documentation for this phase, and I want to add a lot more test cases, but you can see the code on the SourceForge project.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #53  
Old 14th January 2016, 04:23 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project - Continued

Notes on Testing

I am quite happy with my GUI test harness. Its fun to watch a GUI program pop up, and get animated through its stuff all by itself.

Most of the test cases so far have been for simple (and some not so simple) functions in libraries. The test harness handles these quite well. The first complication came with a class where the complexity that needs to be tested is in the constructor. It was not possible to just make many instances of the class as it is a singleton and actually an integral part of the test harness itself.

This brings me to the point of this note - sometimes your code needs to explicitly support the ability to test it.

In this case I refactored the complex code out of the constructor into another private function that is called by the constructor. By including the TestCase class as a friend we can then run tests on this function.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #54  
Old 23rd January 2016, 12:32 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project - Continued

Testing the Stubs Framework

The first phase of development is now done. If VICI was a building, the first phase would be clearing the site and building an access road - necessary stuff, but almost entirely independent of the design.

The second phase is like pouring the foundations and putting up some scaffolding.
One of the goals of VICI is to demonstrate that a large project can be better done as a collection of smaller projects. This only works if the projects are independent of each other, otherwise each project spends most of its time waiting for the other projects to get stuff done. To allow each one to keep moving you need a stable API for all the modules and a stub version of each module. Defining the module interfaces as part of the system architecture allows this to be undertaken at an early point in the development.

So, I have created a header file that defines all the interfaces between modules - vici.h and have created a library containing the stub version of each module. Later, during the development of each module, the stubs that the module interacts with will be replaced by stubs that can test the module.

Now I want to test the stubs library. The problem is that the stubs (almost by definition) have almost no state data. This makes it rather difficult for the test harness to try to do its usual state checks. I need some way to test that some sequence of function calls was made as expected. I suppose I will need to instrument the stubs with something that sends a trace message and then test that the trace messages are as expected.

This turned out to be a lot easier than I expected. I redefined a macro that was in the code to do tracing and captured the trace messages and then tested that the expected trace messages arrived in the correct order.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 24th January 2016 at 07:18 AM.
Reply With Quote
  #55  
Old 26th January 2016, 12:28 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project - Continued

Creating the top Project

As mentioned in my previous post, one of the goals of Vici is to show that a large project can be broken up into smaller projects.

Of course the user will need a single distribution - it would be unfriendly to have them install 15 separate projects. So, we need a super project (I've called it "top") that will bind them all together into a single distribution that can be installed with the usual configure, make. (Later there will be rpms, but let's get it working first.)

I built a prototype of this during the original design work and all seemed to work as necessary - autotools handles nested projects quite well. However, now the new version of Eclipse is having a hissy fit at the soft links to the sub-projects - it puts big red exclamation points (!) on each link indicating something is wrong with the build path (as far as my Googling can discern).

The basic problem is a mismatch between autotools and Eclipse. Eclipse puts each project at the top level of the workspace directory, but autotools expects the sub-projects to be in sub-directories. The simple answer was to put soft links from the top project to the others so that autotools would see them as sub-projects. However, now Eclipse thinks this is an error. Interestingly Eclipse can also set up linked resources, but these are virtual links internal to Eclipse - there is nothing in the file system for autotools to use.

Given that it still works as required, and that the top project will only be used when creating a distribution I think I will just ignore these warnings. The worst case scenario is that the build is done from the command line rather than through Eclipse, so it's no big deal.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #56  
Old 26th January 2016, 01:56 PM
bob Online
Administrator (yeah, back again)
 
Join Date: Jul 2004
Location: Colton, NY; Junction of Heaven & Earth (also Routes 56 & 68).
Age: 71
Posts: 23,061
linuxubuntufirefox
Re: VICI: A Software Development Project

Threads merged. Only one thread per topic, please.
__________________
Linux & Beer - That TOTALLY Computes!
Registered Linux User #362651


Don't use any of my solutions on working computers or near small children.
Reply With Quote
  #57  
Old 26th January 2016, 02:23 PM
lsatenstein Offline
Registered User
 
Join Date: Jun 2005
Location: Montreal, Que, Canada
Posts: 3,826
linuxfedorafirefox
Re: VICI: A Software Development Project

Can't download the PDF files. Just hangs with black screen waiting. (refer to earlier postings from April)
__________________
Leslie in Montreal

Interesting web sites list
http://forums.fedoraforum.org/showth...40#post1697840
Reply With Quote
  #58  
Old 26th January 2016, 09:34 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Quote:
Originally Posted by lsatenstein View Post
Can't download the PDF files. Just hangs with black screen waiting. (refer to earlier postings from April)
Looks like the attachments got broken when bob merged the threads.

I am a bit confused - when an old thread gets a new post we are told to just reference the old thread, but when I do they get merged

The docs can be downloaded from http://sourceforge.net/projects/ocra...files/devdocs/
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #59  
Old 30th January 2016, 03:55 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Building a Distribution

First I should point out that by distribution I am referring to the infrastructure and test framework - there is nothing of Vici's functional code in the build yet.
This is just to confirm that my processes are workable before I spend a lot of time on the actual development.

After fixing a few things I have got the top project to build and successfully run the make check.
A few more fixes to make sure everything necessary gets into the distribution I have also been able to run make distcheck. This attempts to verify that a distribution will build and run when its installed on the target. Unfortunately its not entirely reliable as I found after installing and building the distribution vici.tar.gz file. The problem is that the installed location for some of the test files is different to the development environment which causes the tests to fail. I can resolve this by using a path like search for files.

My concern is that I can never be sure that what is in the development environment will work when its installed on the target without actually doing a trial installation. I find this to be a little troubling.
And this is before we get to installing on a variety of target systems.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #60  
Old 31st January 2016, 05:12 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Phase Two Completed

This is just to announce that the second phase has now been completed.

While its probably fairly useless for the normal user, it might be a good basis for other moderately large C++ projects so I will probably leave it on SourceForge as the starting point for future projects.

Next I'll begin on some real functionality. I am going to start with a couple of simple sub-projects that can be used to create syntax charts for EBNF language descriptions.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
Reply

Tags
continued, development, project, software, vici

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Development Software Pepperonie Using Fedora 2 5th May 2007 10:56 PM
Development software for Linux jo3 Using Fedora 9 15th June 2006 03:28 PM
Software Development handshakeit Using Fedora 0 5th October 2005 08:40 AM


Current GMT-time: 20:21 (Thursday, 30-03-2017)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat