Setting up webpack build

[rumblesan]

So this is dependant on v2 of the language being merged. unfortunately the coffee script compiler doesn't seem to play nicely with being included :(

relevant commands

• npm run build run an optimised build
• npm run devbuild run a development build that should generate source maps and the like
• npm run serve run the development server with hot reloading and other nice stuffs
• npm run test run the nodeunit test suite

[rumblesan]

Just realised that tests seem to be broken at the moment because of a reliance on webpack. will get that sorted

[rumblesan]

ok, tests sorted now. These are just the tests for the v2 language parser btw. have no idea how much of the old test suite might run (or indeed how to run it) but a lot of the test cases from there have been pulled in to the new one now

[rumblesan]

so the last commit added in the travis CI configuration. I've got it running against my fork of the repo (https://travis-ci.org/rumblesan/livecodelab), but it's probably worth turning it on for your repo @davidedc. Would be good to get more tests happening and being run regularly

[davidedc]

how do I build this and try this out? npm run devbuild gives no joy...

[rumblesan]

so if you run npm run serve then it will start up the dev server. once that's going, browse to http://localhost:8080. Any changes you make to the code should be instantly reloaded.

devbuild and build both just create the files and dump them in the dist/ folder. tbh I think with the devserver sorted, the devbuild option isn't really necessary.

[davidedc]

hmm... I downloaded livecodelab-b78979af28f17234479f90cff6fd25a0e45f6cea and did npm install and then npm run serve got this...

[rumblesan]

when you say downloaded, do you mean downloaded the tarball and then ran from there? or checked out the branch? if the latter have you cleaned the repository first? I've got no issues running npm run serve from within a clean repo. Will double check I've not got anything installed globally that should be local though

[davidedc]

downloaded the .zip from the github webpage, so I think it's a clean install...

[rumblesan]

hhmmm, so I just did the same thing and it's working fine. I'm running it in version 4.4.7 of node, though I don't know how much of a difference that might make

[rumblesan]

ok, build should be working with later versions of node now

[davidedc]

OK I think there is some strangeness with v2 - trying on ee29ae2 which seems to be the latest at the moment language-wise.

So, I think for how we mean the tabs to behave,

scale wave 1 box

(which works)

should be equivalent to:

scale wave 1
box

(which works)

should be equivalent to:

scale wave
box

(which works)

should be equivalent to:

scale wave box

(which doesn't work)

also, probably related, in:

scale wave box
ball

the box should be pulsating but also the ball should be steady

[rumblesan]

right, figured out what the problem is. comes down to wave being a function. specifically it's to do with functions that can be called with no arguments. for example

scale (wave) box

will work because we're explicitly saying that wave should be called on its own, whilst without the parens, box gets pulled in as one of the arguments to wave.

how should this work? box is already marked as being a function and as being inlinable. that's how the parser does some of its stuff. but should we also say that inlinable functions can't be the arguments to other functions? they're either standalone on their own line

box

or if they're on a line with other stuff, they will always cause another block to me made? I think this is how it should work, but I just want to make sure that makes sense

[davidedc]

against all odds I found a comment in my transformer, adding it here with some minor edits. This worked in my mechanism but you might have better levers to action.

  # HOW DOES IT WORK?
  # Example: in
  #   rotate 3, wave pulse / 10, -> box 3, 4
  # 1) the part between the qualifiers (rotate, scale, things that change the display context) and the function chaining ( -> box, the function that is chained and passed as a parameter)
  # is isolated:
  #   3, wave pulse / 10
  # then a count is made of the expressions and
  # user functions accepting arguments followed by
  # a space, which
  # in this case is 1 (the only one being wave)
  # 2) then since we add one closing parens before the chaining:
  #   rotate 3, wave pulse / 10), -> box 3, 4
  # 3) then an open parens replaces each
  # expression or user function followed by a space:
  #   rotate 3, wave(pulse / 10), -> box 3, 4

[davidedc]

(... and I think the same mechanism would generate a wave() if there are no parameters, or something I can pick up and transform into a wave())

[davidedc]

(in the example above, some other previous transformation took care of turning "box" into "-> box").

[davidedc]

in fact I should make that transformation more aggressive, as it doesn't work on

box wave 2 ball

which I think it should, I guess it should become

box(wave 2), -> ball

and not:

box(wave 2, -> ball)

as I don't think we should expect "normal" functions to be passed graphics primitives like that?

Unless that introduces some gotchas that I can't foresee now, I'll try and see if it creates problems.

[davidedc]

yes so if I widen that replacement to match on any possible function or command instead of just a qualifier, then there are no clashes with the other 280 snippets and box wave 2 ball works fine. At least are no obvious breakages.

Can I add that change?

[davidedc]

I mean I see no reason why box wave 2 ball should be anything else other than box(wave 2), -> ball , I think it's the only way to read that.

[rumblesan]

so I've had a bit more of a think about this, and I think that the clarifying example is

scale wave wave 1 ball

which to my mind should be equivalent to

scale(wave(wave 1))
    ball

my thinking is actually that none of the inlinable functions (ball, scale, move, etc) should be passable as an argument without the <lazy evaluation> stuff happening. So if one of them ever appears further along in a line, it will always be parsed as starting a new scope.

I'm going to push my changes onto the v2langupdate branch and not this one. means that later I can rebase around the v1language removal commit

[davidedc]

OK that squares up with existing v1 implementation. Can I do a commit on master to handle box wave 2 ball or is that going to trip you up?

[rumblesan]

ok, so I've fixed it in v2. inlinables are now more separate from other functions. I was going to say you could commit it to a branch, but tbh I don't see there being any issues if you just commit it to master. I've not actually touched any of the v1 code in the v2lang branch so it should be ok