New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anonymous functions #1090

Merged
merged 5 commits into from Jan 2, 2015

Conversation

Projects
None yet
4 participants
@crabmusket
Contributor

crabmusket commented Dec 29, 2014

Slight modification of Konrad's resource for #774. Example:

schedule(2000, 0, function(%a) { echo(%a); }, horses);

@crabmusket crabmusket added this to the 3.7 milestone Dec 29, 2014

@GuyAllard

This comment has been minimized.

Show comment
Hide comment
@GuyAllard

GuyAllard Dec 29, 2014

On the second page of Konrad's resource, he says that the anonymous functions break when compiled into .dso. There's no further mention of this in the resource, has that issue been solved?

GuyAllard commented Dec 29, 2014

On the second page of Konrad's resource, he says that the anonymous functions break when compiled into .dso. There's no further mention of this in the resource, has that issue been solved?

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Dec 29, 2014

Contributor

It appears so, yes - I've been able to use them fine from DSOs. It may have something to do with 170a4ea, or that I changed it to generate function IDs in the parser, not in the lexer. Sorry, forgot to mention that. Here's my silly test script that got DSO'd:

$id = function(%a) { return %a; };
$plus1 = function(%a) { return %a+1; };
error($id SPC $plus1 SPC call($plus1, 2));
function testAnon() {
   %anon = function(%a) { return %a SPC horse; };
   error(call(%anon, future));
   schedule(1000, 0, function() { error(success); });
}

The top-level error is for testing the issue that 170a4ea solved. I can run the engine with this file, then remove the source, run again, and it works just the same.

Contributor

crabmusket commented Dec 29, 2014

It appears so, yes - I've been able to use them fine from DSOs. It may have something to do with 170a4ea, or that I changed it to generate function IDs in the parser, not in the lexer. Sorry, forgot to mention that. Here's my silly test script that got DSO'd:

$id = function(%a) { return %a; };
$plus1 = function(%a) { return %a+1; };
error($id SPC $plus1 SPC call($plus1, 2));
function testAnon() {
   %anon = function(%a) { return %a SPC horse; };
   error(call(%anon, future));
   schedule(1000, 0, function() { error(success); });
}

The top-level error is for testing the issue that 170a4ea solved. I can run the engine with this file, then remove the source, run again, and it works just the same.

@konradkiss

This comment has been minimized.

Show comment
Hide comment
@konradkiss

konradkiss Dec 30, 2014

It's nice to finally see this find its way into master. Thanks, Daniel! As for the DSO-s.. it's been some time since I've worked with it, but I recall the compilation issue being unrelated in the end. I believe my DSOs were broken for a whole other reason. I unfortunately never updated the thread about that find.

konradkiss commented Dec 30, 2014

It's nice to finally see this find its way into master. Thanks, Daniel! As for the DSO-s.. it's been some time since I've worked with it, but I recall the compilation issue being unrelated in the end. I believe my DSOs were broken for a whole other reason. I unfortunately never updated the thread about that find.

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Dec 30, 2014

Contributor

Ah, good to hear - it's always worrying when you're not sure why something's fixed :P. Thanks for the resource, it was exactly what I was looking for when I went to implement this :).

Contributor

crabmusket commented Dec 30, 2014

Ah, good to hear - it's always worrying when you're not sure why something's fixed :P. Thanks for the resource, it was exactly what I was looking for when I went to implement this :).

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket
Contributor

crabmusket commented Dec 30, 2014

@GuyAllard

This comment has been minimized.

Show comment
Hide comment
@GuyAllard

GuyAllard Dec 30, 2014

Great work adding this, very useful.

GuyAllard commented Dec 30, 2014

Great work adding this, very useful.

@jamesu

This comment has been minimized.

Show comment
Hide comment
@jamesu

jamesu Dec 31, 2014

Might be better to use dSprintf in a buffer, otherwise every time you declare an anonymous function you will allocate memory. This sort of goes against the whole idea of reducing memory allocations and fragmentations by using the console alloc stuff.

jamesu commented on Engine/source/console/CMDgram.y in 1204b81 Dec 31, 2014

Might be better to use dSprintf in a buffer, otherwise every time you declare an anonymous function you will allocate memory. This sort of goes against the whole idea of reducing memory allocations and fragmentations by using the console alloc stuff.

@jamesu

This comment has been minimized.

Show comment
Hide comment
@jamesu

jamesu Dec 31, 2014

Contributor

Other than that seems ok. I don't see how else it could better be done given the current way console values are referenced.

Might be an idea in the future to extend this to support storing of local values for closures.

Contributor

jamesu commented Dec 31, 2014

Other than that seems ok. I don't see how else it could better be done given the current way console values are referenced.

Might be an idea in the future to extend this to support storing of local values for closures.

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Jan 2, 2015

Contributor

For some reason the number of lines in the generated parser seems to have dropped significantly. Hrm. Ah well. Let's do it!

Contributor

crabmusket commented Jan 2, 2015

For some reason the number of lines in the generated parser seems to have dropped significantly. Hrm. Ah well. Let's do it!

crabmusket added a commit that referenced this pull request Jan 2, 2015

Merge pull request #1090 from eightyeight/anon-functions
Anonymous functions in Torquescript

@crabmusket crabmusket merged commit e446502 into GarageGames:development Jan 2, 2015

1 check passed

default Merged build finished.
Details

@crabmusket crabmusket deleted the crabmusket:anon-functions branch Jan 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment