Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ebanite]

...About translation from pascal to c/c++ can be my duty, i prefer Pascal syntax just for one reason (it's more readable then C), but i'm not scary about programming in c++...

[SamuraiCrow]

@ebanite

Ok.  That sounds good.  I look forward to seeing it. 

[Sidewinder]

But still some differences, the program style, anyone code in a self way, may be should be a big problem. Each of us start in different time and different way to porting amos to a new life. that for me sounds like a waste of time in the begining. Of course if i'm gonna join with your project. most of my work become obsolete and useless.

Certainly, programming style is a unique aspect to each coder.  Sam and I have different styles, but we also check eachother's work so that we are less likely to miss something.  I don't believe that most of your work will become obsolete and useless.  First of all, your runtime code appears to work quite well, and much of it can almos certainly be used.  And secondly, I don't believe there is ever any wasted code.  I can't count how many times I've restarted the Mattathias project and each time it become better and closer to being done.

It's not properly simple, may be we can share information and cooperate to the same project, but i think i still to envelope my private project. I have to look about your framework, how your project is structured, and what style are you using inside code.

You're more than welcome to continue with your private project.  Our framework is structured into 3 parts:

1.  The Grammar - a unique grammar is created by combining the extensions with the core language.  Currently the grammar is an ASCII text file and combining grammars is a manual process, but the goal is to have this automated whenever the user adds or removed extensions.  The grammar contains actions written in LLVM assembly language that output code which calls the runtime library.

2.  The Parser - The grammar is compiled into a parser.  This parser accepts the input file and parses it, executing the actions after each instruction is matched.  It's the core of the compiler and it is what generates the code.

3.  The Runtime - This is basically a library (static for now, but will probably be dynamic) that contains the code necessary for emulating the AMOS instructions.  This is currently the least developed part of the project.

[ebanite]

You said that you had started again different time, like me. in the early time, my interpreter was so close to the original amos, but that means no kind of expansion in the grammar was possible.
The new Project (still in beta as well)
i start again, i split like your project in 3 part my source :
the grammar/parser (it can apcet ascii or original amos source), it check the sintax and transform the source in a internal structured tokenized format (it can be run with interpreter immediactly).
the complire for the moment is missing, due to optmization on  the interpreter, and i'm coding in same tyme a runtime library for original AGA amiga.
I'm coding an efficent and rich in option IDE for amos, so close to the modern IDE (like Delphi/borland c/c++ or visual family)
multieditor, monitor (debugger) included, and a lot of editor for graphics, music and other things.
My opinion is the new amos not only must have a good interpreter/compiler, it need a great IDE, the new programmer have to find comfortable the new Amos, and they don't become crazy about editor, compiler and linker, the great thing about amos was not only the huge istrusctions set, but the total integration.
My IDE is to close to become complete (when it become so stable i'll upload to show it).
let me how can hel you in your project..

[Sidewinder]

Before we go much further, there are the few additional things to consider:

1.  The Mattathias project is open source and uses the LGPL 3.0 license.  In a nutshell, the liscence means that the code from the Mattathias project can be used freely by anyone in their own projects.  The LGPL allows closed source projects to also use the code as long as the changes to the LGPL source code are made available.  This means that you can use the Mattathias runtime library in your own project even if you do not make your own project open source.  But any changes you make to the Mattathias runtime library must be released as open source.

2.  What C++ compiler and environment do you use?  Currently we are using GCC with the Code::Blocks IDE but we've also compiled the code with Visual Studio.

[Sidewinder]

@ebanite

Your project certainly sounds a lot like my earlier attempts.  May I ask, how does the extension system work in your latest beta?

Right now, perhaps we should take the discussion over to the Mattathias group at Yahoo.  Please join and we can discuss what is needed.

Also, please check your PMs.  I sent you one earlier today.

[ebanite]

@Sidewinder

i'm already joined with mattathias group, my yahoo Id is stefano.troncia
About how my extension system work:
The interpreter/(future compiler) had 2 way to take the sources
For native amos sources, the interpreter load a standard configuration file, where inside it, there is a complete list of amos token, the program try to match wich extension comes from original amos it has to use.
All original extension are splitted in many different dynamic library, and when the interepreter need one of those, simply load it.
The extended version (the new project) give to the programmer a new comand (uses like pascal /include like c)..
it's a examples
//
Uses Bobs,sprites,Music
//
in this way the user doesn't configure the "extension file configuration" by himself, this kind of job is done by the precompiler
Now the project can't compile and only the interpreter work just enough, it load at the begin all libraries definition are loaded, but not the code of the libraries.
When the program is tested, and it's free of error, the interpreter collect any call to the external library and load the code that it need.
The managment of extension is not properly done, because for the moment only the amos main library is supported, and all code are loaded when the interpreter is runnig. The plan is to reduce the memory usage, split any library in a series of micro routine, and make the smaller executable.

My c/c++ compiler is Borland C/C++ builder, for the simple reason it's share the same framework of delphi

[SamuraiCrow]

@ebanite

I've removed the "moderated" tag on your account on the Mattathias mailing list so you can post without prior authorization.  (Normally we require approval of the first post before allowing it to send in order to block spammers from getting in.)

Hopefully we'll be able to fix the parser to be able to accept extensions without requiring the "Uses" directive.  What we planned to do was merge the partial parser pieces together to make the extensions part of the language transparently by using a PEG parser generator to rebuild the parser every time an extension is added.  That way we can make the inclusion of libraries transparent to the programmer in much the same way as Amos does but without the problems of tokens clashing if they are defined twice in the code.  Also static linking shouldn't be a problem if we use an IDE because under LGPL 3.0 statically linked libraries are independent of the license of the host application or any other libraries included.

[ebanite]

After a long silence, i'm proud to show the very first picture of the new concept about Amos ( Amos for Windows), it still in beta version, but i reach those goal:

it can emulate old/fashion hardware to run any original amos program like was in a real amiga...
added aga support an rtg.
Extended syntax, OO extensions
new powerfull multieditor, class container and more
it can manage and load any amos file (configuration included)

what's is missing !!!!
a compiler (it's work but need optmization)

...for now i upload just a picture showing Amos for Windows runnig....

[asymetrix]

Hi

Great work, its looking great ! I cannot wait to test out Amos for Windows :-)

We only need an IDE, similar to this Java one, http://alvyn.sourceforge.net/

As a last resort, I had been thinking that if no updates to Amos occur soon, that we should look at the possibility of using Hollywood as the future language.

We would only need add functions that Hollywood is missing to make it 100% source code compatible.

If your Windows version works as you say, then this is a great achievement indeed !.

seriously, well done ! do you have a link to download ?

I am willing to do testing if need be.
 
cheers

[ebanite]

@asymetrix
thanks a lot, but i'm so sorry about a beta version to download.
it's early to have one, i'm planning to make a demo version for tester not before the end of summer, there is lot things to do before.
I'm planning as well to uplopad some release before the pubblic 1.0 ( should be the first pubbilc version dated Later summer).
Because the project i managed only by me, that could be meaning some late on the final version.
Later on the windows version will be followed by other OS (AROS in primis,linux e macosx e 0s3.1), i'm not planning any version for morphos or amigaos4.0 due for the simple reason i don't like this flavour of amigaOs.
cross finger..

[asymetrix]

Its OK I understand :-)

Keep up the great work, we really do appreciate your efforts.

keep us posted

cheers,