On October 11, 2009 01:09, in alt.os.linux, J.O. Aho (user@example.net)
wrote:

> Lew Pitcher wrote:
>
>> BTW, what ever happened to the AMIGA OS? Is it still around?
>
> AmigaOS has been quite dead after Gateway bought the pieces from what was
> left of Commodore.

Yah. I suspected as much :-)

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

On Sun, 2009-10-11 at 07:26 +0200, J.O. Aho wrote:
> Anti Vigilante wrote:
> > On Sat, 2009-10-10 at 18:54 -0400, Lew Pitcher wrote:
>
> >> This gives the OS incredible flexibility: it doesn't care whether a file is
> >> a JPEG or a text because it doesn't need to care. Only the applications
> >> that manipulate the data must care, and even then, most don't. If cp(1)
> >> cared what sort of file it copied, then we'd have a much more complex
> >> cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
> >> help us if someone builds a filetype not yet known to the utility.
> >
> > But so many applications reinvent the wheel. The kernel has an interface
> > for getting the same results no matter what video driver you are using.
> >
> > This would allow you to download format drivers and every application
> > would benefit from improvements. Also because of the use of format
> > drivers or as the AMIGA calls them datatypes every application can
> > access the format without extra work. Everything from the text editor to
> > the presentation app could be able to open the files.
>
> Still datatypes aren't at kernel level, even AmigaOS would have become utterly
> slow if it had been on the kernel level. Don't forget that there was loads of
> different implementation of gif, jpeg, png and sound datatypes, but you can
> only have one of those installed and working at one time and how many
> different image displaying application didn't there exist anyhow
>
> http://uk.aminet.net/gfx/show
> http://uk.aminet.net/util/dtype
>
> >> Indeed, I can write a program that builds and manages it's own data. If the
> >> OS were required to "know" (have a description of the file format) my
> >> filetype, I'd effectively have to build a new OS each time I changed my
> >> program. Multiply that by thousands of unique file formats for thousands of
> >> independantly developed programs, and you have an unmanagable mess on your
> >> hands.
> >
> > I'm suggesting something external to both kernel and app and precisely
> > something not buried in a library for only one language.
>
> You still would need java-datatypes, c-datatypes, php-datatypes,
> python-datatypes. perl-datatypes and so on or else you wouldn't be able to use
> the datatypes in the language you like to code in.

Not if the datatype is a description. This is what I mean about a file
being a potential filesystem at the core in a very generic abstract way.

I don't remember needing C-datatypes and Basic-datatypes on the AMIGA.

> And don't forget that the
> datatypes where a part of the workbench, not the kickstart and there was other
> alternatives to datatypes, like the file association used in dopus which
> allowed you to have multiple actions.

All I'm saying is to bring it full circle. I'll accept that kernel space
might not be the place to do it, but *-datatype that we see so far is a
sad situation in my opinion.

I should be able to call a function from any language as long as one
library is installed.

Anti Vigilante wrote:
> On Sun, 2009-10-11 at 07:26 +0200, J.O. Aho wrote:
>> Anti Vigilante wrote:
>>> On Sat, 2009-10-10 at 18:54 -0400, Lew Pitcher wrote:
>>>> This gives the OS incredible flexibility: it doesn't care whether a file is
>>>> a JPEG or a text because it doesn't need to care. Only the applications
>>>> that manipulate the data must care, and even then, most don't. If cp(1)
>>>> cared what sort of file it copied, then we'd have a much more complex
>>>> cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
>>>> help us if someone builds a filetype not yet known to the utility.
>>> But so many applications reinvent the wheel. The kernel has an interface
>>> for getting the same results no matter what video driver you are using.
>>>
>>> This would allow you to download format drivers and every application
>>> would benefit from improvements. Also because of the use of format
>>> drivers or as the AMIGA calls them datatypes every application can
>>> access the format without extra work. Everything from the text editor to
>>> the presentation app could be able to open the files.
>> Still datatypes aren't at kernel level, even AmigaOS would have become utterly
>> slow if it had been on the kernel level. Don't forget that there was loads of
>> different implementation of gif, jpeg, png and sound datatypes, but you can
>> only have one of those installed and working at one time and how many
>> different image displaying application didn't there exist anyhow
>>
>> http://uk.aminet.net/gfx/show
>> http://uk.aminet.net/util/dtype
>>
>>>> Indeed, I can write a program that builds and manages it's own data. If the
>>>> OS were required to "know" (have a description of the file format) my
>>>> filetype, I'd effectively have to build a new OS each time I changed my
>>>> program. Multiply that by thousands of unique file formats for thousands of
>>>> independantly developed programs, and you have an unmanagable mess on your
>>>> hands.
>>> I'm suggesting something external to both kernel and app and precisely
>>> something not buried in a library for only one language.
>> You still would need java-datatypes, c-datatypes, php-datatypes,
>> python-datatypes. perl-datatypes and so on or else you wouldn't be able to use
>> the datatypes in the language you like to code in.
>
> Not if the datatype is a description. This is what I mean about a file
> being a potential filesystem at the core in a very generic abstract way.

Meta data you can store in file comments, or you can create meta data
containers, like icons in AmigaOS, there is no point in trying to make
something less workable by adding yet another layer to a file which don't give
you anything more than waist of space.

> I don't remember needing C-datatypes and Basic-datatypes on the AMIGA.

If you want some automatic action to be run, like a datatype started gcc, then
you would need a c.datatype.
I did refer to modules for different computer languages, otherwise you can't
really build any datatypes.


>> And don't forget that the
>> datatypes where a part of the workbench, not the kickstart and there was other
>> alternatives to datatypes, like the file association used in dopus which
>> allowed you to have multiple actions.
>
> All I'm saying is to bring it full circle. I'll accept that kernel space
> might not be the place to do it, but *-datatype that we see so far is a
> sad situation in my opinion.
>
> I should be able to call a function from any language as long as one
> library is installed.

Kind of, it's not just straight forward like that, some languages needs a
module which will talk to the library, others you need headers, otherwise the
language you are using won't have any concept of what functionality the
library offers and how to call the functions in the library, this applies to
all languages.


--

//Aho

On Sun, 2009-10-11 at 18:37 +0200, J.O. Aho wrote:
> Anti Vigilante wrote:
> > On Sun, 2009-10-11 at 07:26 +0200, J.O. Aho wrote:
> >> Anti Vigilante wrote:
> >>> On Sat, 2009-10-10 at 18:54 -0400, Lew Pitcher wrote:
> >>>> This gives the OS incredible flexibility: it doesn't care whether a file is
> >>>> a JPEG or a text because it doesn't need to care. Only the applications
> >>>> that manipulate the data must care, and even then, most don't. If cp(1)
> >>>> cared what sort of file it copied, then we'd have a much more complex
> >>>> cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
> >>>> help us if someone builds a filetype not yet known to the utility.
> >>> But so many applications reinvent the wheel. The kernel has an interface
> >>> for getting the same results no matter what video driver you are using.
> >>>
> >>> This would allow you to download format drivers and every application
> >>> would benefit from improvements. Also because of the use of format
> >>> drivers or as the AMIGA calls them datatypes every application can
> >>> access the format without extra work. Everything from the text editorto
> >>> the presentation app could be able to open the files.
> >> Still datatypes aren't at kernel level, even AmigaOS would have becomeutterly
> >> slow if it had been on the kernel level. Don't forget that there was loads of
> >> different implementation of gif, jpeg, png and sound datatypes, but you can
> >> only have one of those installed and working at one time and how many
> >> different image displaying application didn't there exist anyhow
> >>
> >> http://uk.aminet.net/gfx/show
> >> http://uk.aminet.net/util/dtype
> >>
> >>>> Indeed, I can write a program that builds and manages it's own data.If the
> >>>> OS were required to "know" (have a description of the file format) my
> >>>> filetype, I'd effectively have to build a new OS each time I changedmy
> >>>> program. Multiply that by thousands of unique file formats for thousands of
> >>>> independantly developed programs, and you have an unmanagable mess on your
> >>>> hands.
> >>> I'm suggesting something external to both kernel and app and precisely
> >>> something not buried in a library for only one language.
> >> You still would need java-datatypes, c-datatypes, php-datatypes,
> >> python-datatypes. perl-datatypes and so on or else you wouldn't be able to use
> >> the datatypes in the language you like to code in.
> >
> > Not if the datatype is a description. This is what I mean about a file
> > being a potential filesystem at the core in a very generic abstract way..
>
> Meta data you can store in file comments, or you can create meta data
> containers, like icons in AmigaOS, there is no point in trying to make
> something less workable by adding yet another layer to a file which don'tgive
> you anything more than waist of space.
>
> > I don't remember needing C-datatypes and Basic-datatypes on the AMIGA.
>
> If you want some automatic action to be run, like a datatype started gcc,then
> you would need a c.datatype.
> I did refer to modules for different computer languages, otherwise you can't
> really build any datatypes.

Ah yes you would need a way to access these things. Would having a
C.datatype, PHP.datatype, and python.datatype remove the necessity of
libpng, php-png, and python-png as well as libgif, php-gif, and
python-gif?

> >> And don't forget that the
> >> datatypes where a part of the workbench, not the kickstart and there was other
> >> alternatives to datatypes, like the file association used in dopus which
> >> allowed you to have multiple actions.
> >
> > All I'm saying is to bring it full circle. I'll accept that kernel space
> > might not be the place to do it, but *-datatype that we see so far is a
> > sad situation in my opinion.
> >
> > I should be able to call a function from any language as long as one
> > library is installed.
>
> Kind of, it's not just straight forward like that, some languages needs a
> module which will talk to the library, others you need headers, otherwisethe
> language you are using won't have any concept of what functionality the
> library offers and how to call the functions in the library, this appliesto
> all languages.

Functions are just pieces of code with two details: location in the
library, and expected parameters.

That cannot be so hard to nail down.

Anti Vigilante wrote:
> On Sun, 2009-10-11 at 18:37 +0200, J.O. Aho wrote:
>> Anti Vigilante wrote:

>>> I don't remember needing C-datatypes and Basic-datatypes on the AMIGA.
>> If you want some automatic action to be run, like a datatype started gcc, then
>> you would need a c.datatype.
>> I did refer to modules for different computer languages, otherwise you can't
>> really build any datatypes.
>
> Ah yes you would need a way to access these things. Would having a
> C.datatype, PHP.datatype, and python.datatype remove the necessity of
> libpng, php-png, and python-png as well as libgif, php-gif, and
> python-gif?

In theory you could use the png.datatype instead of "php-png", but you would
most likely want to use libpng when you build the png.datatype, or else you
have to reinvent all the functionality from libpng, but relaying completely on
the AmigaOS datatype will limit what you can do with your files, so you still
want to have applications built directly using the library instead of the
datatype.


>>> I should be able to call a function from any language as long as one
>>> library is installed.
>> Kind of, it's not just straight forward like that, some languages needs a
>> module which will talk to the library, others you need headers, otherwise the
>> language you are using won't have any concept of what functionality the
>> library offers and how to call the functions in the library, this applies to
>> all languages.
> Functions are just pieces of code with two details: location in the
> library, and expected parameters.
> That cannot be so hard to nail down.

Python don't use header files, it uses modules, the same apply to all other
script languages and they won't get aware of what a library includes by magic,
it's like you trying to build a C application without using header files and
libraries to link against.

--

//Aho

Anti Vigilante writes:
> Functions are just pieces of code with two details: location in the
> library, and expected parameters.

> That cannot be so hard to nail down.

Heh. <http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B>
--
John Hasler
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

On Sun, 2009-10-11 at 12:57 -0500, John Hasler wrote:
> Anti Vigilante writes:
> > Functions are just pieces of code with two details: location in the
> > library, and expected parameters.
>
> > That cannot be so hard to nail down.
>
> Heh. <http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B>

Name mangling is a problem if you go by the name.

Something to work on.