Dead Repo(?) / Undocumented Source Code

[kkirby]

Hello.

It seems to me like gorillascript is no longer being actively maintained. I would love to be able to contribute heavily to this repo, but I find my biggest issue is going through the source code and finding out how everything works internally. It would be a huge help to me, and to others, if the source code was commented, even a little. Or to have some kind of documentation of the philosophy and workings of the parser itself. That way the project can be maintained by others (like myself).

Thanks

[unc0]

io.js released yesterday, I wish someone could rewrite gorilla-script to use the latest ES6 features. Anyway, this is my io.js support branch. Hope I made gorilla-script not so dead.

[kkirby]

Yesterday I started to remove generator translation support from GorillaScript, I didnt get very far but it may be a step in the right direction.

[kkirby]

I just removed generator support in Gorillascript and published the branch to: https://github.com/kkirby/gorillascript/tree/Updates

I haven't actually tested it very well, but it's a start.

[unc0]

:+1: Will try that later with koa/toa.

[kkirby]

Yeah, I'm actually having some issues with building it. Primarily that the compiler is built in Gorillascript, so the new updates are interfering with the build system once it has been built once. I'm currently trying to get the two systems separated out so that I can resolve the conflicts.

[kkirby]

Okay, to get it to compile, you need to modify the grunt-gorilla/tasks/gorilla.js and replace all require('gorillascript') with require('../node_modules/gorillascript/index.js'), then you need to remove the node_modules directory in grunt-gorilla. Next you need to install the latest gorillascript (npm install gorillascript). Afterwards, modify line 430 in node_modules/gorillascript/lib/utils.js to use new WeakMap(). Then you should be able to compile gorillascript and test without having to worry about the two clashing.

Also, I forgot to mention, you should precompile the Gruntfile.gs and use that instead of the hacky method used in Gruntfile.js.

Also, also, if you have issues running the newly compiled Gorillascript, your jsprelude might be cached in your system's TMP dir. I run rm -rf $TMPDIR whenever I have issues. Obviously make sure that $TMPDIR is set, otherwise you might find yourself deleting more than you bargained for.

[kkirby]

Okay, the latest code that I pushed should be able to run out of the box if you had any issues before. Just remember to delete the cached prelude. https://github.com/kkirby/gorillascript/commit/cc5f75a148776beae0cc49f5b19c4fd8e98c94c2

[unc0]

Some thought(My English is quite broken, I don't know if I can express myself clearly):

• Gorillascript can be a language without jsprelude and that pre-defined macros.

The basic language syntax is quite nice, I can write code without any code completion. But when you start using type inference and those is-xxxx! macros, the final generated code's sourcemap will become quite inaccurate. You can checkout #146 , I copied that idea from coffeescript-redux. Sometime the original trace stack position is missing, with type system you may see some type error message with a trace position of jsprelude "library", it is quite hard to debug in this situation.

• The indent block pythonic style may add a {{ }} syntax for code block hinting.

let $lib = {
  proc: #(arg)
    chain-cb
      .flat-map #(x)
        async-staff(x)
          .map #(y)
          .foo()
      .bar()
}

let $lib = {
  proc: #(arg) {{
    chain-cb
      .flat-map #(x) {{
        async-staff(x)
          .map #(y)
          .foo()
      }}
      .bar()
  }}
}

It's easier to jumps between your code block with your editor shortcuts.

• Macro can be design like C's header, and it depends on npm modules. Or maybe macro can be an npm module.

When we translated gorillascript to javascript JST, we can use aster and macro headers to generate the perfect final code with the right sourcemap. If we can integrate this AST transformation with browserify/AMD, gorillascript can be easy to deploy. And this can make macro more useful, you can define a promise syntax macro that support bluebird/when/blahblahblah. You can import that promise macro into different project that has different dependences.

[asilluron]

Just calling in @ckknight to weigh in.

[ckknight]

Hey, thanks, @asilluron.

I haven't been able to devote as much time as I'd hoped to gorillascript, but I do like the effort that you guys have been trying to take.

Regarding the prelude issues, I thought I had put in something to make sure that the prelude was properly updated if a new version was detected (by file modified checking), but I can't remember at this point.

Regarding whether this is a dead repo, I'm thinking the best solution might be to make gorillascript a more public project with others having commit rights. Possibly even under a gorillascript organization rather than me personally.

[vendethiel]

There does seem to have people interested in it ;-).

[kkirby]

@ckknight I don't know how you would want to go about doing a GS organization, but I've made some progress on GS over on my own fork.

[vendethiel]

:+1: you're doing great work, @kkirby :). did you try sending @ckknight an email already?