www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D, so it happend...

reply Baas <hacker webmail.co.za> writes:


Motivations:
- LOVE THE D LANGUAGE!!
- To be fully able to develop in a VS.NET like environment using D, with no
limmitations.

Cons:
- Requires Windows platforms (XP and above).
- Requires P4+ CPU.
- 2-4 times slower compiler (still need to be optimized).

- Removed "auto" types.
- Removed some data types.
- No documentation available :(

Pros:
- Faster overall application execution speed.
   - Tested against existing benchmarks.
- Implemented full debug functionality. 
   - No more creapy asm stuff.
   - View/Modify ALL datatypes without any limitations or hassles.
- Complete 128 bit ints/reals
   - Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
- Dynamic keywords:
   - For example:
      - Can rename "else if" to ElseIf etc.
      - Can rename "{}" code block indicators to Begin/End etc.
   - Remain compatible with any older/newer "keyword set".
   - Can basically change keywords to adopt your style.
- Includes "event handler" functionality
- Includes dynamic binary modules (.ddbm)
   - Can automaticaly optimize itself on a target environment.
      - Can restructure its own code pattern (32/64/Multi-CPU)
      - Can physically relocate itself.
      - Can defrag itself in memory/disk.
   - Magnitudes faster then normal DLLs.
   - Can bind/execute across networks.
   - Can be initiated from a remote machine.
   - Includes full security features.
- Includes pre-set configuration templates:
   - Custom Mode
   - Console Mode (exe)
   - Windows Mode (exe)
   - GL Mode (exe)
   - Library Mode (dll)
   - Dynamic Binary Module Mode (ddbm)
   - Windows Service Mode (exe)
   - Device Driver Mode (drv/sys)

   
Tech info:
- Parse the code into XML using Regular Expressions.
   - More code optimization is now possible.
- Replaced the backend with HLA.
   - Code > HLA > OBJ > EXE/DLL
- Removed GC, ...don't need it.
   - Variables allocate/deallocate themselfs.
   - Manual allocation/deallocation still possible.
- Package/Module now require code block indicators
   - package somepackage.somewhere
     {
        module somemodule
        {
           ....
           module deep.beneath
           {
              ....
           }
           ....
        }

        module another.module
        {
           ....
        }
     }
   - More than one module per file is now possible.
- Added inline HLA
   - Can now use asm{} or hla{}

   - int something
     {
        get { return somevariable; }
        set { somevariable = value; }
     }
- Renamed "mixin" to "macro"
- Removed "imaginary" and "complex" types.
- Changed/Added Types
   * ubyte > byte
   * byte > sbyte
   * char > compiler options determine which type to use (1/2/4 bytes)
   * short > short/int16
   * ushort > ushort/uint16
   * int > int/int32
   * uint > uint/uint32
   * long > long/int63
   * ulong > ulong/uint64
   * float > float/single/real32
   * double > double/real64
   + int128/decimal
   + uint128/udecimal
   + int256
   + uint256
   + real128
   + real256
   + string > compiler options determine which type to use (1/2 bytes)
   + date/time/datetime

In Progress:
- "native" .NET framework.

Plan for the Future:
- "VS.NET-like" IDE.
- "true" Generic functionality.

Sorry...
NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)

Baas
Apr 06 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Any plans for release?

It looks like you made many language changes according to personal style
preferences...

Baas Wrote:


 
 Motivations:
 - LOVE THE D LANGUAGE!!
 - To be fully able to develop in a VS.NET like environment using D, with no
limmitations.
 
 Cons:
 - Requires Windows platforms (XP and above).
 - Requires P4+ CPU.
 - 2-4 times slower compiler (still need to be optimized).

 - Removed "auto" types.
 - Removed some data types.
 - No documentation available :(
 
 Pros:
 - Faster overall application execution speed.
    - Tested against existing benchmarks.
 - Implemented full debug functionality. 
    - No more creapy asm stuff.
    - View/Modify ALL datatypes without any limitations or hassles.
 - Complete 128 bit ints/reals
    - Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
 - Dynamic keywords:
    - For example:
       - Can rename "else if" to ElseIf etc.
       - Can rename "{}" code block indicators to Begin/End etc.
    - Remain compatible with any older/newer "keyword set".
    - Can basically change keywords to adopt your style.
 - Includes "event handler" functionality
 - Includes dynamic binary modules (.ddbm)
    - Can automaticaly optimize itself on a target environment.
       - Can restructure its own code pattern (32/64/Multi-CPU)
       - Can physically relocate itself.
       - Can defrag itself in memory/disk.
    - Magnitudes faster then normal DLLs.
    - Can bind/execute across networks.
    - Can be initiated from a remote machine.
    - Includes full security features.
 - Includes pre-set configuration templates:
    - Custom Mode
    - Console Mode (exe)
    - Windows Mode (exe)
    - GL Mode (exe)
    - Library Mode (dll)
    - Dynamic Binary Module Mode (ddbm)
    - Windows Service Mode (exe)
    - Device Driver Mode (drv/sys)

    
 Tech info:
 - Parse the code into XML using Regular Expressions.
    - More code optimization is now possible.
 - Replaced the backend with HLA.
    - Code > HLA > OBJ > EXE/DLL
 - Removed GC, ...don't need it.
    - Variables allocate/deallocate themselfs.
    - Manual allocation/deallocation still possible.
 - Package/Module now require code block indicators
    - package somepackage.somewhere
      {
         module somemodule
         {
            ....
            module deep.beneath
            {
               ....
            }
            ....
         }
 
         module another.module
         {
            ....
         }
      }
    - More than one module per file is now possible.
 - Added inline HLA
    - Can now use asm{} or hla{}

    - int something
      {
         get { return somevariable; }
         set { somevariable = value; }
      }
 - Renamed "mixin" to "macro"
 - Removed "imaginary" and "complex" types.
 - Changed/Added Types
    * ubyte > byte
    * byte > sbyte
    * char > compiler options determine which type to use (1/2/4 bytes)
    * short > short/int16
    * ushort > ushort/uint16
    * int > int/int32
    * uint > uint/uint32
    * long > long/int63
    * ulong > ulong/uint64
    * float > float/single/real32
    * double > double/real64
    + int128/decimal
    + uint128/udecimal
    + int256
    + uint256
    + real128
    + real256
    + string > compiler options determine which type to use (1/2 bytes)
    + date/time/datetime
 
 In Progress:
 - "native" .NET framework.
 
 Plan for the Future:
 - "VS.NET-like" IDE.
 - "true" Generic functionality.
 
 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
 
 Baas
 
Apr 06 2009
next sibling parent Baas <hacker webmail.co.za> writes:
Jason House Wrote:

 Any plans for release?
 
 It looks like you made many language changes according to personal style
preferences...
As I've mentioned, it's possoble for the developer to change it back to his/her style. - Release? I'm busy finalizing the release version and will drop it in GNU/sourceforge or somewhere. (about end of May) I'm still clearing a few (minor) agreement issues with my ex-employer regarding intellectual property etc.
Apr 06 2009
prev sibling parent BCS <none anon.com> writes:
Hello Jason,

 Any plans for release?
 
 It looks like you made many language changes according to personal
 style preferences...
My thought exactly. It's not sounding like D anymore...
Apr 06 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Apr 6, 2009 at 10:29 AM, Baas <hacker webmail.co.za> wrote:


 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
Why, because it's complete vaporware? language to something completely different in the process - and never mention it until now?
Apr 06 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

For fun, I guess :-) Or maybe as a programming exercise, etc. So there are already four D compilers, (and no one of them is "high quality").
- Faster overall application execution speed. - Tested against existing
benchmarks.<
I'd like to know what benchmarks are used, and against what compiler, etc. Bye, bearophile
Apr 06 2009
parent Bass <hacker webmail.co.za> writes:
bearophile Wrote:

 Jarrett Billingsley:

For fun, I guess :-) Or maybe as a programming exercise, etc. So there are already four D compilers, (and no one of them is "high quality").
- Faster overall application execution speed. - Tested against existing
benchmarks.<
I'd like to know what benchmarks are used, and against what compiler, etc. Bye, bearophile
Follow the reference ... <http://www.digitalmars.com/d/archives/digitalmars/D/Re_D_compiler_benchmarks_85657.html>
Apr 06 2009
prev sibling parent Bass <hacker webmail.co.za> writes:
Jarrett Billingsley Wrote:

 On Mon, Apr 6, 2009 at 10:29 AM, Baas <hacker webmail.co.za> wrote:


 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
Why, because it's complete vaporware? language to something completely different in the process - and never mention it until now?
...cause it wasn't worth mentioning until now... have a great day!
Apr 06 2009
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
Apr 06 2009
parent reply downs <default_357-line yahoo.de> writes:
Ellery Newcomer wrote:
 Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
It's all about the better optimizations that are now possible!
Apr 06 2009
parent reply Bass <hacker webmail.co.za> writes:
downs Wrote:

 Ellery Newcomer wrote:
 Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
It's all about the better optimizations that are now possible!
I've only provide a brief description upfront. It basically is now more "dynamic" to do optimization since you're working with straight XML content, which is easier to analyze, manipulate, etc.
Apr 06 2009
parent reply downs <default_357-line yahoo.de> writes:
Bass wrote:
 downs Wrote:
 
 Ellery Newcomer wrote:
 Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
It's all about the better optimizations that are now possible!
I've only provide a brief description upfront. It basically is now more "dynamic" to do optimization since you're working with straight XML content, which is easier to analyze, manipulate, etc.
No. Just .. no. On the off chance that you're serious about that - XML is a data format that encodes tree-like hierarchical information. But if your parser isn't already using a tree-like structure internally, you're doing something wrong. And if it is, there's absolutely no reason to use XML as some weird sort of intermediary stage.
Apr 06 2009
parent reply Baas <hacker webmail.co.za> writes:
 No. Just .. no.
 
 On the off chance that you're serious about that - XML is a data format that
encodes tree-like hierarchical information.
 
 But if your parser isn't already using a tree-like structure internally,
you're doing something wrong.
 
 And if it is, there's absolutely no reason to use XML as some weird sort of
intermediary stage.
I've used the "Analysis-Synthesis Model" for the overall design (to "re-invent the wheel" :) ), as I've done lots of times in the past. The Analysis-Synthesis Model is clearly based on a tree-structure. - Lexical Analysis - Parsing/Syntax Analysis - Semantic Analysis - Intermediate Code Generator - Code Optimizer - Code Generator Lexical- and Syntax Analysis is handled in a single pass. (just a reminder) Instead of writing a lot of additional code to work with and to identify the source/tokens, I simply dump all the tokens into a xml format using Regular Expressions search/replace. This takes up to 30 passes for completion and, yes, this is where most of the time is used. From there on it's straight forward to do any kind of analysis with the code/tokens. The key is when it gets to the phase of optimization. In this case, the compiler (or should I be fair and call it "the converter"), has a complete "engine" behind it which takes care of all the information in a proper manner. Cutting, moving, merging, passing referenses and occasionally adding additional code is done with ease. It's already possible at that stage to systematically assign (and measure) a "Unit of Fitness" (Genetic Analysis), if I may call it that, to the individual code blocks. By measuring the fitness, the converter knows where to focus to improve performance. After optimization, converting it to HLA obviously opens a Pandora's box of a different kind. You know the rest... To summarize, optimization is taken care of even before convertion to HLA takes place, and that's why I use xml (it's a matter of preference). Technically, thats the basic overview of the operation, and yes, I AM SERIOUS ABOUT THIS! So, be positive... :)
Apr 06 2009
next sibling parent BCS <ao pathlink.com> writes:
Reply to Baas,

 But if your parser isn't already using a tree-like structure
 internally, you're doing something wrong.
 
 And if it is, there's absolutely no reason to use XML as some weird
 sort of intermediary stage.
[...] I saw nothing in your description that in any way would be made simpler by using XML. A properly done tree structure can do (or be used to do) everything you described with ease. If you are mucking with XML as text, they you are just flat crazy and if you are not then you are using a tree structure anyway and even one that is not specialized for your cases at that.
Apr 06 2009
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Baas wrote:
 No. Just .. no.

 On the off chance that you're serious about that - XML is a data format that
encodes tree-like hierarchical information.

 But if your parser isn't already using a tree-like structure internally,
you're doing something wrong.

 And if it is, there's absolutely no reason to use XML as some weird sort of
intermediary stage.
I've used the "Analysis-Synthesis Model" for the overall design (to "re-invent the wheel" :) ), as I've done lots of times in the past. The Analysis-Synthesis Model is clearly based on a tree-structure. - Lexical Analysis - Parsing/Syntax Analysis - Semantic Analysis - Intermediate Code Generator - Code Optimizer - Code Generator Lexical- and Syntax Analysis is handled in a single pass. (just a reminder) Instead of writing a lot of additional code to work with and to identify the source/tokens, I simply dump all the tokens into a xml format using Regular Expressions search/replace. This takes up to 30 passes for completion and, yes, this is where most of the time is used. From there on it's straight forward to do any kind of analysis with the code/tokens. The key is when it gets to the phase of optimization. In this case, the compiler (or should I be fair and call it "the converter"), has a complete "engine" behind it which takes care of all the information in a proper manner. Cutting, moving, merging, passing referenses and occasionally adding additional code is done with ease. It's already possible at that stage to systematically assign (and measure) a "Unit of Fitness" (Genetic Analysis), if I may call it that, to the individual code blocks. By measuring the fitness, the converter knows where to focus to improve performance. After optimization, converting it to HLA obviously opens a Pandora's box of a different kind. You know the rest... To summarize, optimization is taken care of even before convertion to HLA takes place, and that's why I use xml (it's a matter of preference). Technically, thats the basic overview of the operation, and yes, I AM SERIOUS ABOUT THIS! So, be positive... :)
I'll be positive, but only if you promise you didn't sacrifice nesting comments in the process. Also, if you haven't already, you should trash D's cyclic dependency policy.
Apr 06 2009
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
How is compilar formed? How is compilar formed? How executable get maked?
Apr 06 2009
next sibling parent reply Bass <hacker webmail.co.za> writes:
Tom S Wrote:

 How is compilar formed? How is compilar formed? How executable get maked?
Well, it (the D code) is simply converted to HLA (High Level Assembler) files. HLA take it from there and compile it into .obj files. From there you can bassically choose your favourite linker to create exe etc.
Apr 06 2009
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Bass schrieb:
 Tom S Wrote:
 
 How is compilar formed? How is compilar formed? How executable get maked?
Well, it (the D code) is simply converted to HLA (High Level Assembler) files. HLA take it from there and compile it into .obj files. From there you can bassically choose your favourite linker to create exe etc.
optimizable anymore - or do you mean CLI?
Apr 06 2009
parent Baas <hacker webmail.co.za> writes:

 optimizable anymore - or do you mean CLI?
"D" code gets optimized first then converted to HLA...
Apr 06 2009
prev sibling parent BLS <windevguy hotmail.de> writes:
Bass wrote:
 Tom S Wrote:
 
 How is compilar formed? How is compilar formed? How executable get maked?
Well, it (the D code) is simply converted to HLA (High Level Assembler) files. HLA take it from there and compile it into .obj files. From there you can bassically choose your favourite linker to create exe etc.
..and HLA uses NASM,FASM,... to create the obj files, right ? I would call it Managed D. Bj鰎n
Apr 06 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
Apr 06 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Apr 6, 2009 at 10:13 PM, Christopher Wright <dhasenan gmail.com> wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
I am gobsmacked that I didn't think to do this earlier. Thank you so much. :D
Apr 06 2009
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Christopher Wright wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
LOL, awesome! I love it! :D
Apr 07 2009
prev sibling parent reply grauzone <none example.net> writes:
Christopher Wright wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
I don't understand this.
Apr 07 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
grauzone wrote:
 Christopher Wright wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get 
 maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
I don't understand this.
Ask the web search engine of your choice about "HOW IS BABBY FORMED".
Apr 07 2009
parent reply grauzone <none example.net> writes:
Alexander P谩nek wrote:
 grauzone wrote:
 Christopher Wright wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get 
 maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
I don't understand this.
Ask the web search engine of your choice about "HOW IS BABBY FORMED".
I know about this phrase, but I don't understand Christopher's posting. Yeah, some joke about internet memes, but...?
Apr 07 2009
parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
grauzone wrote:
 Alexander P谩nek wrote:
 grauzone wrote:
 Christopher Wright wrote:
 Tom S wrote:
 How is compilar formed? How is compilar formed? How executable get 
 maked?
They need to do way> instain programer, who wriet thier compilars, just becuase these compilars cant get debuged? It was on the newsgroup this mroing, a programer in d.D who had rewrite D compilar. They are taking the compilar back to teh net, too vapour too warez. My pary are with the programers who use compilar, I am truley sorry for your lots
I don't understand this.
Ask the web search engine of your choice about "HOW IS BABBY FORMED".
I know about this phrase, but I don't understand Christopher's posting. Yeah, some joke about internet memes, but...?
Christopher changed the response鈥檚 sense to match with Tom鈥檚 question. http://www.youtube.com/watch?v=Ll-lia-FEIY
Apr 07 2009
prev sibling next sibling parent Clay Smith <clayasaurus gmail.com> writes:
Baas wrote:

 
 Motivations:
 - LOVE THE D LANGUAGE!!
 - To be fully able to develop in a VS.NET like environment using D, with no
limmitations.
 
 Cons:
 - Requires Windows platforms (XP and above).
 - Requires P4+ CPU.
 - 2-4 times slower compiler (still need to be optimized).

 - Removed "auto" types.
 - Removed some data types.
 - No documentation available :(
 
 Pros:
 - Faster overall application execution speed.
    - Tested against existing benchmarks.
 - Implemented full debug functionality. 
    - No more creapy asm stuff.
    - View/Modify ALL datatypes without any limitations or hassles.
 - Complete 128 bit ints/reals
    - Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
 - Dynamic keywords:
    - For example:
       - Can rename "else if" to ElseIf etc.
       - Can rename "{}" code block indicators to Begin/End etc.
    - Remain compatible with any older/newer "keyword set".
    - Can basically change keywords to adopt your style.
 - Includes "event handler" functionality
 - Includes dynamic binary modules (.ddbm)
    - Can automaticaly optimize itself on a target environment.
       - Can restructure its own code pattern (32/64/Multi-CPU)
       - Can physically relocate itself.
       - Can defrag itself in memory/disk.
    - Magnitudes faster then normal DLLs.
    - Can bind/execute across networks.
    - Can be initiated from a remote machine.
    - Includes full security features.
 - Includes pre-set configuration templates:
    - Custom Mode
    - Console Mode (exe)
    - Windows Mode (exe)
    - GL Mode (exe)
    - Library Mode (dll)
    - Dynamic Binary Module Mode (ddbm)
    - Windows Service Mode (exe)
    - Device Driver Mode (drv/sys)

    
 Tech info:
 - Parse the code into XML using Regular Expressions.
    - More code optimization is now possible.
 - Replaced the backend with HLA.
    - Code > HLA > OBJ > EXE/DLL
 - Removed GC, ...don't need it.
    - Variables allocate/deallocate themselfs.
    - Manual allocation/deallocation still possible.
 - Package/Module now require code block indicators
    - package somepackage.somewhere
      {
         module somemodule
         {
            ....
            module deep.beneath
            {
               ....
            }
            ....
         }
 
         module another.module
         {
            ....
         }
      }
    - More than one module per file is now possible.
 - Added inline HLA
    - Can now use asm{} or hla{}

    - int something
      {
         get { return somevariable; }
         set { somevariable = value; }
      }
 - Renamed "mixin" to "macro"
 - Removed "imaginary" and "complex" types.
 - Changed/Added Types
    * ubyte > byte
    * byte > sbyte
    * char > compiler options determine which type to use (1/2/4 bytes)
    * short > short/int16
    * ushort > ushort/uint16
    * int > int/int32
    * uint > uint/uint32
    * long > long/int63
    * ulong > ulong/uint64
    * float > float/single/real32
    * double > double/real64
    + int128/decimal
    + uint128/udecimal
    + int256
    + uint256
    + real128
    + real256
    + string > compiler options determine which type to use (1/2 bytes)
    + date/time/datetime
 
 In Progress:
 - "native" .NET framework.
 
 Plan for the Future:
 - "VS.NET-like" IDE.
 - "true" Generic functionality.
 
 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
 
 Baas
 
Technically cool, but I'm not sure it can be considered 'D' if you won't be able to compile D 1.0 code with it. Sounds like a language fork.
Apr 06 2009
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Baas wrote:

Wtf. No you didn't.
Apr 06 2009
prev sibling next sibling parent davidl <davidl nospam.org> writes:
在 Mon, 06 Apr 2009 22:29:26 +0800,Baas <hacker webmail.co.za> 写道:



 Motivations:
 - LOVE THE D LANGUAGE!!
 - To be fully able to develop in a VS.NET like environment using D, with  
 no limmitations.

 Cons:
 - Requires Windows platforms (XP and above).
 - Requires P4+ CPU.
 - 2-4 times slower compiler (still need to be optimized).

 - Removed "auto" types.
 - Removed some data types.
 - No documentation available :(

 Pros:
 - Faster overall application execution speed.
    - Tested against existing benchmarks.
 - Implemented full debug functionality.
    - No more creapy asm stuff.
    - View/Modify ALL datatypes without any limitations or hassles.
 - Complete 128 bit ints/reals
    - Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
 - Dynamic keywords:
    - For example:
       - Can rename "else if" to ElseIf etc.
       - Can rename "{}" code block indicators to Begin/End etc.
    - Remain compatible with any older/newer "keyword set".
    - Can basically change keywords to adopt your style.
 - Includes "event handler" functionality
 - Includes dynamic binary modules (.ddbm)
    - Can automaticaly optimize itself on a target environment.
       - Can restructure its own code pattern (32/64/Multi-CPU)
       - Can physically relocate itself.
       - Can defrag itself in memory/disk.
    - Magnitudes faster then normal DLLs.
    - Can bind/execute across networks.
    - Can be initiated from a remote machine.
    - Includes full security features.
 - Includes pre-set configuration templates:
    - Custom Mode
    - Console Mode (exe)
    - Windows Mode (exe)
    - GL Mode (exe)
    - Library Mode (dll)
    - Dynamic Binary Module Mode (ddbm)
    - Windows Service Mode (exe)
    - Device Driver Mode (drv/sys)

 Tech info:
 - Parse the code into XML using Regular Expressions.
    - More code optimization is now possible.
 - Replaced the backend with HLA.
    - Code > HLA > OBJ > EXE/DLL
 - Removed GC, ...don't need it.
    - Variables allocate/deallocate themselfs.
    - Manual allocation/deallocation still possible.
 - Package/Module now require code block indicators
    - package somepackage.somewhere
      {
         module somemodule
         {
            ....
            module deep.beneath
            {
               ....
            }
            ....
         }

         module another.module
         {
            ....
         }
      }
    - More than one module per file is now possible.
 - Added inline HLA
    - Can now use asm{} or hla{}

    - int something
      {
         get { return somevariable; }
         set { somevariable = value; }
      }
 - Renamed "mixin" to "macro"
 - Removed "imaginary" and "complex" types.
 - Changed/Added Types
    * ubyte > byte
    * byte > sbyte
    * char > compiler options determine which type to use (1/2/4 bytes)
    * short > short/int16
    * ushort > ushort/uint16
    * int > int/int32
    * uint > uint/uint32
    * long > long/int63
    * ulong > ulong/uint64
    * float > float/single/real32
    * double > double/real64
    + int128/decimal
    + uint128/udecimal
    + int256
    + uint256
    + real128
    + real256
    + string > compiler options determine which type to use (1/2 bytes)
    + date/time/datetime

 In Progress:
 - "native" .NET framework.

 Plan for the Future:
 - "VS.NET-like" IDE.
 - "true" Generic functionality.

 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)

 Baas
I hope the final release won't disappoint many peope. Though, the property change is a good thing. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Apr 06 2009
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Baas Wrote:


 
 Motivations:
 - LOVE THE D LANGUAGE!!
 - To be fully able to develop in a VS.NET like environment using D, with no
limmitations.
 
 Cons:
 - Requires Windows platforms (XP and above).
 - Requires P4+ CPU.
 - 2-4 times slower compiler (still need to be optimized).

 - Removed "auto" types.
 - Removed some data types.
 - No documentation available :(
 
 Pros:
 - Faster overall application execution speed.
    - Tested against existing benchmarks.
 - Implemented full debug functionality. 
    - No more creapy asm stuff.
    - View/Modify ALL datatypes without any limitations or hassles.
 - Complete 128 bit ints/reals
    - Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
 - Dynamic keywords:
    - For example:
       - Can rename "else if" to ElseIf etc.
       - Can rename "{}" code block indicators to Begin/End etc.
    - Remain compatible with any older/newer "keyword set".
    - Can basically change keywords to adopt your style.
 - Includes "event handler" functionality
 - Includes dynamic binary modules (.ddbm)
    - Can automaticaly optimize itself on a target environment.
       - Can restructure its own code pattern (32/64/Multi-CPU)
       - Can physically relocate itself.
       - Can defrag itself in memory/disk.
    - Magnitudes faster then normal DLLs.
    - Can bind/execute across networks.
    - Can be initiated from a remote machine.
    - Includes full security features.
 - Includes pre-set configuration templates:
    - Custom Mode
    - Console Mode (exe)
    - Windows Mode (exe)
    - GL Mode (exe)
    - Library Mode (dll)
    - Dynamic Binary Module Mode (ddbm)
    - Windows Service Mode (exe)
    - Device Driver Mode (drv/sys)

    
 Tech info:
 - Parse the code into XML using Regular Expressions.
    - More code optimization is now possible.
 - Replaced the backend with HLA.
    - Code > HLA > OBJ > EXE/DLL
 - Removed GC, ...don't need it.
    - Variables allocate/deallocate themselfs.
    - Manual allocation/deallocation still possible.
 - Package/Module now require code block indicators
    - package somepackage.somewhere
      {
         module somemodule
         {
            ....
            module deep.beneath
            {
               ....
            }
            ....
         }
 
         module another.module
         {
            ....
         }
      }
    - More than one module per file is now possible.
 - Added inline HLA
    - Can now use asm{} or hla{}

    - int something
      {
         get { return somevariable; }
         set { somevariable = value; }
      }
 - Renamed "mixin" to "macro"
 - Removed "imaginary" and "complex" types.
 - Changed/Added Types
    * ubyte > byte
    * byte > sbyte
    * char > compiler options determine which type to use (1/2/4 bytes)
    * short > short/int16
    * ushort > ushort/uint16
    * int > int/int32
    * uint > uint/uint32
    * long > long/int63
    * ulong > ulong/uint64
    * float > float/single/real32
    * double > double/real64
    + int128/decimal
    + uint128/udecimal
    + int256
    + uint256
    + real128
    + real256
    + string > compiler options determine which type to use (1/2 bytes)
    + date/time/datetime
 
 In Progress:
 - "native" .NET framework.
 
 Plan for the Future:
 - "VS.NET-like" IDE.
 - "true" Generic functionality.
 
 Sorry...
 NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
 
 Baas
 
up with the alternative later?
Apr 06 2009
prev sibling parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
 downs Wrote:
 
 Ellery Newcomer wrote:
 Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
It's all about the better optimizations that are now possible!
I know of a pumping lemma or two that would disagree with you: http://en.wikipedia.org/wiki/Pumping_lemma_for_regular_languages
Apr 07 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Mikola Lysenko wrote:
 downs Wrote:

 Ellery Newcomer wrote:
 Baas wrote:
 Tech info:
 - Parse the code into XML using Regular Expressions.
*double take*
It's all about the better optimizations that are now possible!
I know of a pumping lemma or two that would disagree with you: http://en.wikipedia.org/wiki/Pumping_lemma_for_regular_languages
so much for subtlety.
Apr 07 2009