Pages: 1
  Print  
Author Topic: What limitations does Enigma have?  (Read 2413 times)
Offline (Unknown gender) juggernaut
Posted on: July 25, 2009, 06:43:25 PM
Member
Joined: Apr 2008
Posts: 16

View Profile
I am just curious what things will not be possible to implement in Enigma which are possible in GM. Or are there no limitations?

Is anyone in a position to answer this. Thanks.
Logged
Offline (Male) notachair
Reply #1 Posted on: July 25, 2009, 07:25:23 PM

Definitely not a chair
Contributor
Joined: Feb 2008
Posts: 299

View Profile
Anything involving parsing a string as code
Logged
Offline (Unknown gender) score_under
Reply #2 Posted on: July 27, 2009, 05:54:04 AM

Member
Joined: Aug 2008
Posts: 308

View Profile
Anything involving parsing a string as code
I thought Josh just spent a few millennia coding a C++ and GML runtime parser?
Logged
Offline (Male) Josh @ Dreamland
Reply #3 Posted on: July 27, 2009, 10:06:53 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
Only one millennium.

But yeah. Executing a string will hopefully be possible, too. Really wanna see such a thing put to use in debug mode. But er, execute_string prolly will bite you if you declare something as int.

ENIGMA, being C++, technically has an infinite extensibility; anything C++ can do, it can do. This doesn't mean that I'll offer a help file over everything that C++ offers, as that would be impossible, due to the fact that it's so big. It also doesn't mean that it will always be as easy as a function with a 30-character name that you can guess at.

C++ is a huge language. Putting that at the fingertips of the user removes any limits, so long as you're willing to learn and willing to put some real work into it.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) notachair
Reply #4 Posted on: July 28, 2009, 01:34:48 AM

Definitely not a chair
Contributor
Joined: Feb 2008
Posts: 299

View Profile
You're saying you're going to try and make this possible?
Code: [Select]
execute_string("var asdf"+zxcvbnm+"ghjkl;");
Logged
Offline (Male) RetroX
Reply #5 Posted on: July 28, 2009, 10:15:54 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
You're saying you're going to try and make this possible?
Code: [Select]
execute_string("var asdf"+zxcvbnm+"ghjkl;");
asdfzxcvbnmghjkl
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Male) Josh @ Dreamland
Reply #6 Posted on: July 29, 2009, 12:27:19 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
a2h--
Realize the simplicity.
Variables users add can be stored in a separate hash map. Think: if the variable, asdfWHATEVERghjkl, isn't referenced in the compiled code, there is no need to keep the compiled vars extensible; only to make sure that they can be accessed from within the string to execute.

Hash maps are a safe way to do that, too. I probably won't allow access to non-primitives in execute_string. Meaning the best you can do is int, double, char, and so on. Structs and pointers would therefore be disallowed, with exception, I imagine, of string. (And of course var)

At the moment I'm ready to go to bed, and am too tired to give it much thought. But thinking about how var and string would be allowed, I could *probably* add support for any predeclared structures; the ones I know at compile time. Dynamic structures, ones defined in execute_string, are probably out of the question, unless they are scopeless... Overall seems like too much work to bother with. Too much room to do something inefficiently.

But as for your basic GM execute_string, it doesn't seem all that hard, really.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Rusky
Reply #7 Posted on: July 29, 2009, 11:31:55 AM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
So... you're going to include a GML parser in games that use execute_string? Hopefully you can figure out how to reuse the main one.
Logged
Offline (Unknown gender) score_under
Reply #8 Posted on: July 29, 2009, 08:53:41 PM

Member
Joined: Aug 2008
Posts: 308

View Profile
Structs and pointers would therefore be disallowed, with exception, I imagine, of string. (And of course var)
If you do not allow pointers I shall come to your house and strangle you with a knife.
Logged
Offline (Male) Josh @ Dreamland
Reply #9 Posted on: July 30, 2009, 08:35:36 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
I meant in execute_string. Pointers have been allowed in full force since R3.

Also, you try that, and I'll take out my knife and shoot you.
« Last Edit: July 30, 2009, 09:00:22 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) notachair
Reply #10 Posted on: July 31, 2009, 02:32:49 AM

Definitely not a chair
Contributor
Joined: Feb 2008
Posts: 299

View Profile
KNIFE GUNS?
Logged
Offline (Unknown gender) score_under
Reply #11 Posted on: July 31, 2009, 12:02:46 PM

Member
Joined: Aug 2008
Posts: 308

View Profile
I meant in execute_string. Pointers have been allowed in full force since R3.
Can't you just... you know... deference the pointer? lol
Or is it the pointer type that you're worried about?
Logged
Pages: 1
  Print