StepTalk TODO

From GNUstepWiki

(Difference between revisions)
Revision as of 21:42, 9 March 2005
Stefan Urbanek (Talk | contribs)

← Previous diff
Revision as of 21:47, 9 March 2005
Stefan Urbanek (Talk | contribs)

Next diff →
Line 68: Line 68:
* Remove empty directories (Source, Modules/StepTalk) * Remove empty directories (Source, Modules/StepTalk)
* Replace STMethod languageName with map table of method class->engine class * Replace STMethod languageName with map table of method class->engine class
 +
 +* integrate with Gorm - use Script objects, make a palette for Gorm with script objects

Revision as of 21:47, 9 March 2005

If you would like to help StepTalk, just contact me and I will guide you. Requirements: courage only :-)

Contact: Stefan Urbanek

Contents

1.0 release

  • implement NSRect object - see STStruct object
  • implement distant conversations
  • create stenvironment tool

STEnvironment tool

First, changes to the STConversation is needed as follows:

  • method executing code should not return a value
  • script result object should be fetched by method: -(id)result or -(bycopy id)resultByCopy;
  • conversation object should collect error messages - it should hold kind of transcript
  • it would be great if conversation object can send notifications when transcript was updated
  • conversation object should hold last exception raised by the script

Then stand-alone process should be created with following functionality:

  • point of the stand alone process is that it can load any framework it likes and it should provide semi-persistent environment holding intermediate results of a inter-process and inter-application tasks
  • one creates an STDistantEnvironment object - the object is in fact represented by single process that will be launched on -init
  • the environment process will handle all execution requests - connections are created in form of conversations: user makes conversation with the environment
  • environment is "live" until someone requests it to die

To make it more clear about the STEnvironment stand-alone process, here is an analogy:

  • stenvironment process = database instance
  • conversation = database connection
  • StepTalk script = SQL script
  • result = SQL script result (rows, message, ...)

one should be able to do following:

stenv create experiment
stenv execute experiment script.st
stenv execute experiment script2.st
...
    env = [STEnvironment distantEnvironmentWithName:@"experiment"];
    conversation = [STConversation conversationWithEnvironment:env language:nil];
    [conversation executeScript:aScript];
    result = [conversation resultByCopy]; /* or .... [conversation result] */ 
...

Smalltalk

  • Rewrite Smalltalk compiler (grammar)
    • Remove STBytecodeInterpreter and use only STCompiler. How?

Simply convert language constructions into 'command' objects like SmalltalkStatement, SmalltalkPrimary, SmalltalkMethodSend, ... and implement executeInEnvironment:context:receiver:

  • Update application scripting to use STConversation

Other

  • handle 'connection did die' notification for distant objects in STEnvironment
  • fix class-info lookup for proxies in STEnvironment
  • Smalltalk: separate compiler and compilation context
  • create a 'Shell' scripting environment
  • Create ApplicationScripting framework, instead of bundle. It should offer

passive application scripting (without linking) and active app. scripting (linking with the framewotk). Give it some reasonable name, becauase that one is already used by Apple

  • Add framework list into environment description
  • Change Modules to Frameworks
  • Fill implementation of STScriptObject, STMethod and related STEngine methods
  • Remove empty directories (Source, Modules/StepTalk)
  • Replace STMethod languageName with map table of method class->engine class
  • integrate with Gorm - use Script objects, make a palette for Gorm with script objects