Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3

Author Topic: Dwarf Script v0.13 - Lots of new stuff  (Read 17401 times)

NRN_R_Sumo1

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #15 on: August 04, 2010, 02:39:44 am »

Yes, once I have implemented a timer that you can script to call a particular function at a regular interval, and if you know where the designations (for mining) are stored you could do it. I suppose devek knows it because he has made a feature designating trees to be cut in dwarf foreman. As for the fish you can go through the creature vector using the idx (meaning index) and count (size of the vector) script functions and check the race. But yeah, the possibilites are endless, to make all those micromanagement tasks automated :)


Good LORD!
I'm going to need to figure this out, or atleast hope for some "demo" scripts to come out for me to base things on.
Logged
A dwarf is nothing but an alcohol powered beard.

nbonaparte

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #16 on: August 04, 2010, 06:47:58 am »

this is... damn. This is going to be extremely useful.
Logged
A service to the forum: clowns=demons, cotton candy=adamantine, clown car=adamantine tube, circus=hell, circus tent=demonic fortress.

keda

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #17 on: August 04, 2010, 11:15:23 am »

Looks like I'm going to have to make a short tutorial in how to use the script. Being a postfix language, Dwarf Script has an advantage in learning it, because it allows playing around and improvise, rather than having to compose whole sentences like with prefix or infix languages. Postfix allows for an easy to understand down-to-earth concrete data manipulation, rather than having juggle with dozens of abstractions in your head while writing something. It is data-oriented rather in contrast to function-oriented. The reason people like object-oriented languages is that they are more concrete than functional languages - but they don't go all the way, its a middle ground between data and function oriented languages, and as it turns out unlike OOP which uses an infix notation, data oriented languages doesn't dispose of the possibility of features you want to have in a functional language like multiple dispatch, but, thats for future developement.

If you have used a stack based calculator, then you should be able to easily learn this language, which is a stack based language. What this means that there is an operand stack, on which you have data that you are currently working with, and by typing in a
a) constant, the data ends up on the stack
b) a function, which pops up some data from the stack, manipulates it, and pushes the result back on the stack (sometimes it only does one of these, or neither)

When you start ds, the first thing you see, is two red brackets [] This is actually the stack, which is empty for now. To fill you you can type in a number, say 5  and press enter
[5]
This means 5 is on the stack. Now type in 3

[5:3]
Now you have two operands on the stack. 3 is on top, because you pushed it in last. Type + and press enter.
[8]
Since + is a function(an operator) it does not end up on the stack. Instead it picks up 5 and 3, and pushes 8 down. The nice thing is while you are doing this, step by step, you will immediately notice when something goes wrong, unlike in other languages where you write a whole bunch of code and then compile and pray, something screws up and you have no idea where, after which a tedious bug hunt follows. Not so with dwarf script. If something doesn't work, then you can just do it step by step in the konsole.

Still, you have infix taught to you in your school, so its ingrained in your head. How do you type for instance 2 * (6 + 5)
6 5 + 2 *
Which may look confusing to you. This is because you're not used to seeing stuff like this and interpret what it means. You've been taught 2 * (6 + 5) and the complex rules of how to interpret that, you don't even think about, its all automatic because you've been practicing that all the time. But basically what goes on in your head is this:
1. evaluate what's inside parentheses first
2. then evaluate powers and roots
3. then evaluate multiplications and divisions
4. lastly evaluate additions and subtractions
This is called operator precedence. As a programmer you probably have a much deeper hierarchy of up to 15 levels precedence inculcated in your head. Either that or you use parentheses all the time in fear of not having the wrong thing evaluated first. e.g. 1 << 2 | 3 *4 can be difficult for a beginner, but an experienced coder knows what that means because the precedence rules are built in. In Dwarf Script you can forget all that. Any beginner can easily learn it because there are no precedence rules, not even parentheses. Well, actually there are parentheses but they're used for something else.
6 5 + 2 *
Has no parentheses. Instead, the parenthesis that you evaluated first (6+5) is now the very first thing in the code. What you do first, is thus always first you type. In other words you don't have to keep complex rules in your head. You have 5 and 6, and add them together. Then you have the result of that and two, and multiply them together. And thats the order you think, and also the order that computers compute, and also the order in which you write the code
6 5 + 2 *
Yet, you've been taught in school that 2 * (6 + 5) which is totally unintuitive and stupid. But you've been taught to be stupid.


Part 2








 
« Last Edit: August 06, 2010, 11:10:31 am by keda »
Logged

DennyTom

  • Bay Watcher
  • !!Urist!!
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #18 on: August 04, 2010, 12:57:53 pm »

Oh my GOD! This could be a complete revolution! Please continue working on this and possibly contact the author of some dwarf manager - possibility to manage scripts for dwarves through GUI where you already can manage profesions by hand would be amazing experience.
Logged
It is so much easier to measure life in experience points...

Zantan

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #19 on: August 04, 2010, 06:21:37 pm »

This sounds like a great project!  Of course, this will add some wonderful features to the game, but I'm really excited because if this project is really well developed, we can add a lot of custom features, even custom scenarios to the game by writing utilities that rung alongside the game.  Here are some example scripts that came to mind:

Dwarf advisors/tutorial - a utility that monitors your stocks, workshops, etc, and advises the player on what the next step in fortress development should be, and what menus/keys to use to do it.

Enhanced monsters - If a dragon attacks the fort, a script scans the stocks screen to see if there are any dragon bones in your fort.  If you are, the dragon may go berzerk, and become even tougher.  If there is a complete dragon skeleton, the dragon may use its magical powers to turn it into an undead dragon in your stockpiles.

Blessings/Curses - Another script could monitor the use of altar workshops.  It could compare offerings at the altar to your population and total created wealth, and periodically receive blessings or curses as appropriate (more clowns, plagues of vermin, boosts to happiness, gifts of masterwork weapons, etc.).  It could even monitor the prayer habits of individual dwarves, and pious dwarves could be aided in times of need (wounds healed in combat, temporary changes to STR, or pious civilians under attack could get speed boosts or be teleported to an altar.)

Creature transormations - other utilities like runesmith are already able to replace one creature with another and I think even replace them so using complex conditions, you could do things like allow vampires to occassionally turn their wounded enemies into new vampires, or insects that at a certain age are replaced by immobile coccoons, and later by a new monster.  You could even replace the corpses of snake golems with hundreds of venomous snakes (vermin).

If this is ever possible, it probably won't be for a long time, but it would be marvelous if these utilities became possible!  Additionally, these added features would also not reduce FPS as long as their utilities were on a separate thread (and your CPU had multiple threads).
« Last Edit: August 04, 2010, 06:36:15 pm by Zantan »
Logged

devek

  • Bay Watcher
  • [KILL_EVERYTHING]
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #20 on: August 04, 2010, 11:47:40 pm »

This was actually the type of thing I was thinking about when it came to replacing dwarf therapist.

I would rather be able to assign a "class" to a dwarf, and assign a class to a class, etc. and assign rules on that.
Logged
"Why do people rebuild things that they know are going to be destroyed? Why do people cling to life when they know they can't live forever?"

stormsaber

  • Bay Watcher
    • View Profile
Feature request
« Reply #21 on: August 05, 2010, 11:58:11 am »

Hi,
Good work! The ability to create arbitrary creatures at a given location, and to create arbitrary objects (like walls, floors, magma, etc.) at a given location would also be very very cool, as would the ability to create custom in-game announcements. That would allow the community to make something Ive always thought would be awesome: a campaign or even just a tutorial!

Daniel
Logged

Zantan

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #22 on: August 05, 2010, 02:23:26 pm »

It's also worth noting that standing production orders are #2 on the eternal suggestion list right now, so Toady should be working on that sometime soon.  I know this project aspires to do a lot more than that, but it may help in the long run if you figure out how this may end up in the game.  My thoughts are that Toady will probably let standing production orders be stored in a text file for easy access.  If that is the case, and you get Toady to allow for complex conditions, you can save yourself some work by making a standing production order in DF that triggers no actions, and use your program to simply check whether DF has evaluated the condition to be true.
Logged

dree12

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.10 - Scripting your dwarves to work
« Reply #23 on: August 05, 2010, 04:08:57 pm »

Update:
You can now also set mental attributes, in the same manner as physical attributes.
Also, traits have been added, which are also set using the same syntax

Note that traits range from 0-100 while attributes range about 0-2300
I'd like to point out that attributes range 0-5000. Otherwise, this looks like an awesome program! Except that I can't see how to make conditional stuff (like only running a function only if [strength 4000 >]) Is this possible yet?
Logged

keda

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #24 on: August 05, 2010, 06:30:16 pm »

I've just finished working on the first linux version release. It might slightly differ from the windows version since i did a big cleanup and reorganization of code yesterday and ended up altering a lot of code and even fixing some sleeping bugs. Yes, the swap function might be buggy with floating points, so don't use that with floating points in the windows version until the next release.

The linux addresses and offsets are different from the windows version so the current main.ds cannot be used with it unless the addresses and offsets are altered. For starters the creature vector is at 0x9306a00 - thats the only thing I have tested so far and it shows the right number of creatures with count.

I'll upload it in a moment and post replies

keda

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 - Scripting your dwarves to work
« Reply #25 on: August 05, 2010, 07:34:48 pm »

Update:
You can now also set mental attributes, in the same manner as physical attributes.
Also, traits have been added, which are also set using the same syntax

Note that traits range from 0-100 while attributes range about 0-2300
I'd like to point out that attributes range 0-5000. Otherwise, this looks like an awesome program! Except that I can't see how to make conditional stuff (like only running a function only if [strength 4000 >]) Is this possible yet?
Thanks for pointing that out. Yes, you can do conditional stuff, e.g.

Code: [Select]
1(2)(3)?
should end up with 2 being pushed on the stack
Code: [Select]
0(2)(3)?
while this will give you 3.

Note that there is a strong typing check that disallows you from doing things like:
Code: [Select]
1(2 3)(4)?
or
Code: [Select]
1("asdf")(2)?
because both must produce the some amount and types of output. This is necessary for the interpreter to internally produce efficiently executing "code" (more like data structures) without having to perform typechecks.

It's also worth noting that standing production orders are #2 on the eternal suggestion list right now, so Toady should be working on that sometime soon.  I know this project aspires to do a lot more than that, but it may help in the long run if you figure out how this may end up in the game.  My thoughts are that Toady will probably let standing production orders be stored in a text file for easy access.  If that is the case, and you get Toady to allow for complex conditions, you can save yourself some work by making a standing production order in DF that triggers no actions, and use your program to simply check whether DF has evaluated the condition to be true.
Yeah I saw that, but I'm guessing that its easy enough to implement, and checking for what items you have in a stockpile could be useful for other things as well.

Hi,
Good work! The ability to create arbitrary creatures at a given location, and to create arbitrary objects (like walls, floors, magma, etc.) at a given location would also be very very cool, as would the ability to create custom in-game announcements. That would allow the community to make something Ive always thought would be awesome: a campaign or even just a tutorial!

Daniel
Thanks, creating arbitrary creatures should be easy, except I only know how to do that in windows yet thanks to devek. Supposedly peterix knows about how to do injecting code using SHM. Creating arbitrary objects on the map should be easier I guess as it doesn't involve reallocating memory in df. Not sure about custom announcements.

This was actually the type of thing I was thinking about when it came to replacing dwarf therapist.

I would rather be able to assign a "class" to a dwarf, and assign a class to a class, etc. and assign rules on that.
Sounds like a better idea than I had with dwarf sets. I'm thinking about allowing the creation of custom datatypes so you have certain functions operating on particular datatypes and have "rules" interact with "classes".

This sounds like a great project!  Of course, this will add some wonderful features to the game, but I'm really excited because if this project is really well developed, we can add a lot of custom features, even custom scenarios to the game by writing utilities that rung alongside the game.  Here are some example scripts that came to mind:

Dwarf advisors/tutorial - a utility that monitors your stocks, workshops, etc, and advises the player on what the next step in fortress development should be, and what menus/keys to use to do it.

Enhanced monsters - If a dragon attacks the fort, a script scans the stocks screen to see if there are any dragon bones in your fort.  If you are, the dragon may go berzerk, and become even tougher.  If there is a complete dragon skeleton, the dragon may use its magical powers to turn it into an undead dragon in your stockpiles.

Blessings/Curses - Another script could monitor the use of altar workshops.  It could compare offerings at the altar to your population and total created wealth, and periodically receive blessings or curses as appropriate (more clowns, plagues of vermin, boosts to happiness, gifts of masterwork weapons, etc.).  It could even monitor the prayer habits of individual dwarves, and pious dwarves could be aided in times of need (wounds healed in combat, temporary changes to STR, or pious civilians under attack could get speed boosts or be teleported to an altar.)

Creature transormations - other utilities like runesmith are already able to replace one creature with another and I think even replace them so using complex conditions, you could do things like allow vampires to occassionally turn their wounded enemies into new vampires, or insects that at a certain age are replaced by immobile coccoons, and later by a new monster.  You could even replace the corpses of snake golems with hundreds of venomous snakes (vermin).

If this is ever possible, it probably won't be for a long time, but it would be marvelous if these utilities became possible!  Additionally, these added features would also not reduce FPS as long as their utilities were on a separate thread (and your CPU had multiple threads).
Nice ideas - custom scenarios sounds great, altough I wonder whether it will be possible to somehow make df display custom messages and such. Otherwise they would have to show up in the konsole, which isn't as good, although otherwise it sounds doable. A tutorial would be of great benefit to new players. Enhanced monsters should easily be doable by switching race and editting raws and such. Blessings and Cures would also be easy to implement. Thanks for the suggestions.
Oh my GOD! This could be a complete revolution! Please continue working on this and possibly contact the author of some dwarf manager - possibility to manage scripts for dwarves through GUI where you already can manage profesions by hand would be amazing experience.
Yup, as I hope people will now easily be able to contribute their own scripts for the betterment of the dwarf fortress experience :) I've actually been looking through Dwarf Therapist code for a long time to understand how the creatures stuff is stored, but for the rest, I think peterix should have a lot of the stuff already pinned down.

keda

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.11 and v0.11b - Scripting your dwarves to work
« Reply #26 on: August 06, 2010, 12:34:47 am »

Part 2 of the tutorial

Once you have understood the basic idea behind postfix, you can easily code any simple sequential script. But that is still a bit limited. So next you would probably want to do something more advanced like, using conditionals and loops.

A conditional is quite easy, but I'll demonstrate how for instance you would make a max function, that is a function that picks the bigger of two numbers. Lets assume we have 5 and 7 on the stack:
[5:7]
Then if we do:
Code: [Select]
a. b. a b > (a)(b)?a. <-- this gives the name 'a' to 7 and pops it off the stack
b. <-- this gives the name 'b' to 5 and pops it off the stack
a  <-- this picks out 'a' and puts it on the stack (7)
b  <-- this picks out 'b' and puts it on the stack (5)
>  <-- this compares the two and gives 1 =true (note that all integer values except 0 are interpreted as true in a boolean expression)
()()? <-- this basically is a conditional. unless the preceding value is 0, the first clause is executed, otherwise the second.
a <-- since it is 1 means true, the first clause is executed and a (7) is pushed on the stack.

The bigger value got pushed on the stack. Try the other way around on the stack. It will always give you the bigger one.

Now you might want to make a function out of this, so you can use it without having to retype the whole thing.
Code: [Select]
(a. b. a b > (a)(b)?)max;
Then you can try:
Code: [Select]
12 5 max
So now you've learn not only how to make conditional statements but also how to write functions, and how to define and use variables.

A couple things to note about the conditional though:
- The preceding value must be of int-type
- Both the true-clause and the false-clause must have the same input types (arguments) as well as same output types (return values). If they don't match ds will complain about it. Note, that DS will not execute anything half digested but interprets the whole string so that the input/output types of every expression is known before execution, which is why you can't have conditionals at odds with this rule.

Next on to the while loop which is a bit more trickier. Might seem easy at first but there are some things you have to keep in mind.
Code: [Select]
int i=5;
while(i--){
   cout<<i;
}
Here's a typical C++ loop. The equivalent in DS looks like this:
Code: [Select]
5 (1-i. i# i)@The # function prints out i, which is first 4, then 3, then 2, then 1, then 0.
This can actually written in a bit more efficient form:
Code: [Select]
5 (1-$ #)@And I don't just mean syntactically taking less space, but it executes faster because this saves pushing and popping the named values. Instead $ duplicates the top value and uses the first of those two for printing and the second lives on to the next iteration as the decrement.

However that said, for newbies, the first one is a useful template and names makes it much more readable. And no, once interpreted, the names are stripped out and are replaced with hard physical addresses on a stack, so they are not that inefficient. These are the odd purple operations you never typed in, in the execution queue view.

So, I will make a couple of templates for easy loops for you:

The decrement loop:
Code: [Select]
5(1-i.      i)@the increment loop:
Code: [Select]
0 $5<(i.      i 1+$5<)@where you replace 5 with the number of iterations you want.

So far so good. The tricky part comes in when you want to keep a value other than the iterator. Then you have to think more like tail-recursion.
At least at the moment, since there is no way to redefine or reassign a variable. So at the moment this part resembles more a declarative language than an imperative one. But this will soon change, as I will allow reassignment of variables, and then I will update this part of the tutorial. Until then the trick is to have the clause take more values than the iterator. Here's an example of 3 values being pushed out of the loop back in at the beginning.
Code: [Select]
1 2 3   0 $5<(i. a.b.c.       c b a  i$5<)@
Now there are a few more things to note about while loops:
- it must be preceded by an int
- it takes at least one argument, the first of which is that int
- it returns the exact same types, in the same order so that the tail recursion works.

Btw you might be wondering, why I put together terms without spaces. I just like code taking less space. If you are the same as me, then you will be grateful that DS allows for extreme whitespace compression, more than in most languages. Basically you can remove all whitespace to the point the expression takes on a different meaning. All identifiers are either composed of a-z/A-Z followed by a-z/A-z/0-9/_ or alternatively any character besides these, double quotes, parentheses and whitespace, which can be used to define names so, yes &/*  actually constitutes a valid name for a function. Strings, numbers, both types of identifiers can all be put side by side with the exception for numbers after the a-Z type identifier. You can even put two strings side by side like this: "blah""asdf" But for simplicity and newbies might want to stick to putting space between everything, or at least to the same amount they put in a regular C/C++/java program.

To be continued...
« Last Edit: August 06, 2010, 11:07:19 am by keda »
Logged

keda

  • Bay Watcher
    • View Profile

I've released a new version for both Linux and Windows

Added addresses/offsets for linux, except for skills vector

Also fixed:
   using escape characters no longer leave the escape character used
   errors during execution are now no longer overwritten
   linux "reads" reads now full string, not just first character + garbage
   linux "readstl" fixed
   made possible negative numbers
   "set" now works again
new feature:
   getfirstnames gets the dwarf first names rather than nicknames - can be combined with nicknames

keda

  • Bay Watcher
    • View Profile

   There has been a delay in the release of the next version for a couple of reason. One being that there are several major features that I'm slowly trying to implement, and the second being that doing this, I had to restructure the program in major ways resulting in a whole bunch of bugs that took me ages to track down. At the moment they have quieted down so I hope I can release something somewhat stable. Since most of the work went into preparations for the major features, which will probably take a lot more time, the upcoming release will not have any of the major features in a usable state. However there are still a bunch of goodies in it and some bug fixes.

Here's a full list of features I'm planning for upcoming releases:

Note:
 - green means this feature has already been implemented and will be in the upcoming version 0.13
 - yellow means this feature is partially implemented.
 - cyan means this feature is just planned.


Major features:

1. multithreading and timer support

Most of the time has gone to restructure the program in preparation for this feature which allows the instantiation of threads which all have their own private stacks, but can communicate using the global variable namespace, as well as by picking up certain arguments. In addition threads can be put to sleep for a specified amount of milliseconds. This feature should allow developement for scripts executing in the background checking for conditions in df triggering scriptable events

2. Views management

"Views" is an arbitrary name I picked for an area of the screen showing certain information.
The previous version has incorporated 5 views in a haphazard manner, specifically
  - the operand stack, which shows what operands are on the stack
   - the execution queue, which shows what functions are to be applied on the stack given the current command line
   - the command line, which shows the string you are typing in to be interpreted and executed
   - the errors view, which shows any errors that occur during interpretation or execution
   - the output types given by the command

   Some of these are implemented right next to each other, and none of these respond well when going past the width of the console.
   For the next version, I have already implemented a function that caps these to a specified width and allows scrolling of the output, however I'm also in the process of implementing a system to manage and configure views in a way the user finds desirable. In addition I have planned several new views:
  - intellisense
      - lists applicable functions within current context alphabetically sorted
      - autocomplete
         - grey text of letters that are the only way out of current context
         - up/down select between multiple functions
         - right key(or space?) autocompeltes
   - function help (lists inputs, outputs as well as a description of what it does with these, of the function currently under caret)
   - a memory scanner (for aiding finding offsets)
   - split view (allows display of 2 views side by side, can be used recursively for more than 2)

      modes of split views:
        - fixed (split in half by default, but splitter can be moved using ctrl-left/right)
         - left priority (prioritizes the left side allowing its length to determine the splitter position
         - right priority (same but for the right side)

      note that the current execution queue/error view represent left priority behaviour overlooking the behaviour when they hit the console width limit.
   Also there will be a few improvement on the existing views:
      - the command line will be color coded, with red color representing errenous code for easy identification
      - background color could be used with commandline to display what arguments are taken by the function currently under caret
      - up and down keys will go through commandline history
     - errors during parsing will provide
         -line, column
         - excerpt that is a scrollable view in itself (useful for evals and function template instantiations)
         - command line view will also paint the relevant code red, whether in the command itself or the function which could not be parsed.
         and exerpt of code where error occurs (for evaluated strings) or point to code in the command

    view (e.g. blinking or red text)
     - errors during execution will point to the location in the execution queue (blinking section?)
      - execution view will have its own caret for selecting and getting help on a particular function
      - execution view will have collapsed functions by default, pressing enter will open/close them.
      - during debugging, executed steps will be shifted out of view
      - during debugging, one step will involve opening the collapsed function
      - during debugging loops, an iteration will be instantiated beside the "blueprint" of the loop

So how should views be managed?
  - using the alt key, moving up and down will switch between views vertically,
   - using the alt key moving left and right will switch between views horizontally, in case of split views.
   - using alt+del to delete a view (deleting a split view will unsplit the view in favour for the other side)
   - using page up/down to switch between view types
   - using ctrl left/right to configure splitter, ctrl up/down to configure split view mode, or alternative have separate view types for each mode
   - left/right scrolls views


3. Lists

At the moment there is no kind of container in Dwarf Script at all, except for perhaps the potential to use the global namespace + string concatenation to dirtily implement arrays/associative arrays. So, the next step would be to have a basic list container which will be a new datatype.
  - head function gives the top element of the list
   - tail function gives the list without the top element.
   - head or tail on an empty list will throw an error.
   - empty will return 1 when its size is 0
   - size will return the size of the list
   - list constants declaration using {1 2 3} syntax
   - in addition to inputs which are passed by value and outputs which passed by reference, user defined functions will be able to take inputs by reference, allowing the direct manipulation of stack elements, making list processing and later to be implemented data structures efficient.


Minor features:
  - capped views with scrollable output
   - commenting is possible in two variants like in C/C++/Java:
      /* blah */
      // blah
   - stack data is now completely separate from type info, allowing faster execution without passing around type info at all.
   - stack is restored if execution fails (solved a bunch of problems i didn't want to deal with, implementing the above)
   - ascii 0-32 show as "?" inside strings in stack.
   - \123 inside string constants converts to ascii char 123
   - bitwise not
   - the ability to set or unset flags (untested)
   - loop mismatch error is more informative
   - rearranged views
   - used commands are now shown for easy copy/paste until history scrolling works.
   - history scrolling is now also implemented (use up and down keys)

   - the semantic separation of "" strings and () clauses. Yes, currently these are interchangable.
   - the syntactic separation of function declarations [] from loops and conditionals ()
   - once the above separations are made, typing loops and conditions in commandline can be more informative than currently (just showing
as a string)
  - inlining &/ optimations
      I intend to have 4 optimation levels that a function call and utilize:
      1. inlining (internal + external merge compiling + simplification)
      2. internal interpretation + simplification
      3. internal interpretation
      4. text (evaluation at execution)
   - save string to file
   - enumerate template functions
   - extracting text from a template function
   - enumerating variables
   - using something else than STL string, it weighs down heavily on the size of the executable in the windows version
   - function pointers (almost implemented)
   - user defined types
   - scriptable error handling
   - scriptable coloured output
   - more string functionality
   - improved eval, that allows specifying output and input types
  - recursion, through specifying input and output. A specific form of function template instantiation (there is a way to cheat and do recursion at the moment by overwriting a mock function of the same name having the same signature.)
Bug fixes:
  - view disruption is fixed through capping and scrollable output
   - fixed disruptions caused by ascii chars 0-31 in strings on the stack
   - $ now displays in execution view
   - code now fetched rather than recompiled at every function call, and various sleeping bugs that this triggered
   - enter no longer executes when there are parse errors
   - fixed a bunch of memory leaks
   - multiline text outputs is now clean
   - functions should now list correctly
   - linux: fixed read4 bug when highest bit set, due to pread having a stupid 2G limit so switched to pread64
« Last Edit: August 16, 2010, 04:33:55 am by keda »
Logged

keda

  • Bay Watcher
    • View Profile
Re: Dwarf Script v0.13 - Lots of new stuff
« Reply #29 on: August 16, 2010, 04:47:01 am »

Ok, finally updated. I haven't had any chance to test the latest changes on windows though, but it should still work. If it doesn't, I'd be happy to know about it.
Pages: 1 [2] 3