osfree.org

#1393 Re: [osFree] Development Project
Expand Messages

Frank Griffin
Jun 29, 2006
John P Baker wrote:

Hide message history
>
>
>
> If I proceed to that step, I would not be looking for OS/2 binary compatibility, but rather a WPS-like graphical interface built on top of a robust multi-tasking and multi-threaded kernel.
>
>
You might want to check out the Voyager effort at Netlabs.

#1394 Re: [osFree] Development Project
Expand Messages

Lynn H. Maxson
Jun 29, 2006
Frank,

What do I need to do to locate the Voyager effort at Netlabs?
I can't seem to find it.

It's good to see the lurkers who remain on this mailing list.

#1395 [osFree] Not dead but sleeping
Expand Messages

Sascha Schmidt
Jun 29, 2006
Hello to all of you!

I am one of those developers, which published the first screen shot in
last november. I don't know, what happened to the homepage, I think it
must be for technical reasons.

I don't know, whether that's really better news, but be sure, osFree is
NOT dead, "just" sleeping. During the development of the bootprocess we
encountered a problem, we couldn't solve, concerning function calls of
functions, which were written in the memory before. None of us knew
enough of memory programming or had enough time to solve this.

By the time the forum is online again, you will be able to find exact
explantations of the problem there.


wbr,
Sascha Schmidt

#1396 Re: [osFree] Development Project
Expand Messages

Frank Griffin
Jun 30, 2006
Start at http://wiki.netlabs.org/index.php/Voyager_FAQ

There are others if you google +voyager +netlabs

I agree, they are not particularly easy to find. But the project
appears to match the goal of not necessarily binarily compatible but
retaining the WPS.

#1397 Re: [osFree] So, is O/S Free finally dead?
Expand Messages

Kenn Yuill
Jun 30, 2006
On 29/06/06 at 21:04, Lynn H. Maxson wrote about the subject of
"[osFree] So, is O/S Free finally dead?"

>That's as much an update as I need to offer at the moment.
>OS/2 lives.

-oOo-

Thank you very much for the clarification & I wish you & the teams
future success in all of your efforts.

--

Chimo,
Kenn
_________________________________________________________

Always act as if life is a joyous journey. - K.A. Yuill

_________________________________________________________

#1398 Re: [osFree] So, is O/S Free finally dead?
Expand Messages

Lynn H. Maxson
Jun 30, 2006
Kenn,

I make no secret of wanting everyone in the OS/2/eCS
community to think of themselves as members of the team,
the same team. Increasingly our survival turns on our ability
to support ourselves in terms of software development and
maintenance. The closer we bring that support to
self-sufficiency the better the prospects for our community.

It has never been the lack of software talent, the skill set
necessary, holding us back. You don't have to go far in the
mailing lists, newsgroups, or web sites to understand the
depth of that talent. We are quite capable of focused action
once we set our minds to it. The problem lies in getting the
focus to come to one mind on the issue.

OSFree and FreeOS offered two different approaches to
achieve the same result. It's interesting that the Voyager
project on Netlabs eliminates any such confusion by in effect
saying its our way or the highway.

However, OS/2 or eCS is a software package well beyond
without extra help the capacity of Serenity Systems. I don't
want to give the impression that we are hanging by a thread.
I do want to give the impression that for the most part we are
hanging separately. That and not acquiring skill levels
through skill transfer offers our greatest challenge.

We need to come together. More of us with skills need
somehow to better communicate their acquisition through a
skills transfer process. Too often we focus on what we need
to bring to the table in terms of skills and not on how we can
broaden the numbers with those skills. If you take a look at
any "dormant" open source project, not having replacements
on the ready lies at their core.

In SCOUG and VOICE projects in which I have a leadership role I
continually seek to find a means of easing the entry of those
who want to increase their skill levels. That means bringing a
broader perspective to a software project other than simply
getting it out the door. That means we do what we do, we
document what we do, and we communicate what we do in a
manner in which others can more easily join in, if not on this
project then certainly on another.

The community has the talent and the experience. Like
anything else it needs to have it distributed more widely. It
makes no sense to talk about the ability to customize an open
source program without somehow insuring that you enable
that ability.

#1399 Re: [osFree] Development Project
Expand Messages

MikeG
Jul 1, 2006
John P Baker wrote:

>
> I am currently working on the design of a commercial grade compiler
> which could, upon completion, provide the development foundation for a
> new operating system development effort.
>
>
>
> If I proceed to that step, I would not be looking for OS/2 binary
> compatibility, but rather a WPS-like graphical interface built on top
> of a robust multi-tasking and multi-threaded kernel.
>
>
>
> However, at the moment the only thing I am expending time on is the
> compiler.
>
>
>
> If anyone is interested in participating, please drop me a note.
>
>
>
> I am looking for people who are familiar with object technologies,
> with CICS (an IBM transaction processing system), SQL (IBM, Microsoft,
> and Oracle), and with Pascal-derivative languages.
>
>
>
> John P Baker
>
> Software Engineer
>
>
>

Why a new compiler? Wouldn't it be easier to build on existing compiler
like Open Watcom?

MikeG

#1400 RE: [osFree] Development Project
Expand Messages

John P Baker
Jul 1, 2006

There are several reasons for designing a new compiler.



First, I want a Pascal-like language, but I do not find that Delphi or any of the other Pascal-derivatives provide the specific implementation characteristics that I am looking for.



I want to provide an implementation that supports multiple-inheritance, but with rules that are more deterministic than the implementations that are prevalent today.



Second, I want to provide integrated support for the EXEC CICS transaction language, which is the norm for transaction processing in the IBM world.



This will make the compiler attractive to that segment of the computer industry.



The use of integrated EXEC CICS command language recognition as opposed to a preprocessor approach provides all sorts of opportunities for code optimization.



Third, I want to provide integrated support for the EXEC SQL database language, which is the norm for relational database access throughout the industry.



I want to look at the big three (IBM DB2 Universal Database, Microsoft SQL Server, and Oracle), and in conjunction with a review of the current SQL standard, specify in detail the commands which will be recognized.



Again, the use of integrated EXEC SQL command language recognition as opposed to a preprocessor approach provides all sorts of opportunities for code optimization.



John P Baker

Software Engineer

From: osFree@yahoogroups.com [mailto:osFree@yahoogroups.com] On Behalf Of MikeG
Sent: Saturday, July 01, 2006 12:52
To: osFree@yahoogroups.com
Subject: Re: [osFree] Development Project



Why a new compiler? Wouldn't it be easier to build on existing compiler
like Open Watcom?

MikeG

#1401 Re: [osFree] So, is O/S Free finally dead?
Expand Messages

MikeG
Jul 1, 2006
Lynn H. Maxson wrote:

> Kenn,
>
> I make no secret of wanting everyone in the OS/2/eCS
> community to think of themselves as members of the team,
> the same team. Increasingly our survival turns on our ability
> to support ourselves in terms of software development and
> maintenance. The closer we bring that support to
> self-sufficiency the better the prospects for our community.

I don't think it is any secret that their are a number of people who
want to contribute and be part of the team.

> It has never been the lack of software talent, the skill set
> necessary, holding us back. You don't have to go far in the
> mailing lists, newsgroups, or web sites to understand the
> depth of that talent. We are quite capable of focused action
> once we set our minds to it. The problem lies in getting the
> focus to come to one mind on the issue.
>
> OSFree and FreeOS offered two different approaches to
> achieve the same result. It's interesting that the Voyager
> project on Netlabs eliminates any such confusion by in effect
> saying its our way or the highway.

Yes. From what I understand, Netlabs *is* saying our way or the highway.
However, can't this end in the same way as the other projects? By this I
mean, couldn't saying "you follow our vision or go away" alienate
people? What's worse is to say this and then ask for monetary support.

Also, as mentioned in a previous post, if one or two key players depart
from the Voyager project (I believe) it could or would go the way of
OSFree or FreeOS.

---- snip

> In SCOUG and VOICE projects in which I have a leadership role I
> continually seek to find a means of easing the entry of those
> who want to increase their skill levels. That means bringing a
> broader perspective to a software project other than simply
> getting it out the door. That means we do what we do, we
> document what we do, and we communicate what we do in a
> manner in which others can more easily join in, if not on this
> project then certainly on another.

Another good point! I find the gcc compiler great but no good doc to
setup for beginners. I learned and still use Open Watcom which seems to
not be within the vision. In my opinion most OS/2 project these days are
poorly documented.

> The community has the talent and the experience. Like
> anything else it needs to have it distributed more widely. It
> makes no sense to talk about the ability to customize an open
> source program without somehow insuring that you enable
> that ability.

I think there is a lot of talent and potential talent in the OS/2-ECS
community. But, there is no central coming together point.

I'm not a programmer by profession, instead for me it is a hobby. Some
people enjoy crossword puzzles or brain teasers (I suck at both), I
enjoy learning and doing C coding. For example, I started 2 months ago
building the PCRE lib, next APR, and now am working APR-UTIL (EXPAT and
APR-ICONV already done) with Open Watcom. A lot of work and I might
never doing anything with it, but I sure learned alot. Now I would have
much rather have put that effort into, for example, a project like
OSFree. I think all I would need is a person to direct what is needed
and answer questions if I got stuck.


MikeG

#1402 RE: [osFree] Development Project
Expand Messages

Lynn H. Maxson
Jul 1, 2006
John,

I really didn't want to get into this argument, but where did
you ever get the idea that you had any PASCAL language
derivative for the two areas, EXEC CICS and EXEC SQL, you
mentioned that would ever offer more than the current PL/I
or COBOL compilers, more specifically than PL/I. As one who
began with CICS at its announcement in 1965 and remained a
regional specialist in the product through the remainder of my
IBM career and the same with PL/I, Wirth in his wildest dreams
in his language evolution never ever got to that level.

I sit here on my OS/2 workstation. In front of me is the
VisualAge PL/I, VisualAge COBOL, IBM DB2, and CICS for OS/2
icons. Thus having begun with CICS prior to entry of the
command-level interface and in fact having to customize the
TCP (Terminal Control Program) source to make an audio
response device correspond to the customer's use, I don't
know how you expect to make a dent with something as
puerile as a PASCAL clone against legacy programming
languages with a complete variable precision, fixed-point
decimal repertoire, i.e. packed and picture decimal format.

As to direct recognition of the EXEC CICS within the compiler
instead of the preprocessor I would think it offers more as a
possible convenience than as a performance enhancement.
Obviously as CICS is an guest operating system functioning in a
host operating system what consideration have you given to
offering the same level of multi-platform support with your
compiler. I doubt if you have more than one platform in mind.
Otherwise you would not ignore what the pre-processor
option offers in terms of reduced support over the compiler
option.

Then finally EXEC SQL where many of the previous
considerations apply as well you have the situation that SQL is
a fourth generation language which has a two-stage proof
engine. The first stage is a completeness proof which verifies
and optimizes the SQL inquiry with a full syntax and semantic
analysis along with code generation. The second stage is an
exhaustive true/false proof, which "tests" the "assertions" of
the query language, returning zero (false) if no "true"
instances found, otherwise a "list" of one or more true
instances.

Now the keyword here is "list". The key performance issue
here is the "one at a time" passing of true instances to the
invoking program which is the curse of all first (actual),
second (symbolic assembly), and third (HLL) generation,
imperative languages: their lack of native list processing
support. There is a reason why LISP has managed to evolve
and remain on top of its game.

So if I was going to define a language which interfaced
"natively" with a relational database manager it would have
native list processing support, receiving and processing the list
of true instances without the stutterstep of "one true instance
at a time" or the other programming "awkwardness" of third
generation languages.

As luck would have it I have defined such a language which I
introduced as part of the Warpicity Proposal at Warpstock 98:
SL/I (Specification Language/One). It wasn't that difficult to
define due to the fact that three pre-1970 "legacy" languages
(APL, LISP, and PL/I) contained everything and more of all
other programming languages since. So if you take the syntax
and data types of PL/I, the operators of APL, and the list
aggregate of LISP, add the ability of both the assignment
statement of third generation HLLs and the assertion
statement (which accepts list variables on input and output)
of fourth generation HLLs you end up with a single fourth
generation language that incorporates all the language
capabilities of previous generations.

Thus your relational database manager can drop the
performance-draining fluff of the "one true instance at a
time" processing and become a seamless fit within an
executable.

Of course I was there when Wirth produce PASCAL as an
academic exercise, when he attempted to overcome its
limitations with MODULA, and then when he went out in a
frensy because by then most were wise to his game by the
time Oberon came along. You are most welcome to pursue a
false prophet and engage in yet another academic exercise. I
will continue to shake my head in disbelief.