Langupdate second attempt

[rumblesan]

OK, here's another attempt to get version 2 of the language merged in.

Currently this still breaks the doOnce functionality, but it should be easier to fix than with the last pull requests I created. languages are selectable from the menu.

Other fixes as well but nothing major I think.

[davidedc]

nice! Just give me a couple of days to go through it so I understand what the delta is...

[rumblesan]

no worries mate, it needs a good look over.

currently, both versions of the language appear to work fine. The only issue with V1 is that the doOnce blocks actually always run. It's not causing an error, but I didn't get a good chance to dig into it on the way home last night.

TBH, I'm tempted to say, that if we can decide on whether we want the doOnce functionality to work like we discussed on Sunday, it might be easier to just build that new implementation and then try to retire Live Lang V1.

For the time being though, I'd be happy with just getting V2 merged into master in some fashion

[davidedc]

@rumblesan I have the following glitch: 1) load page 2) type

rotate
box

3) go to languages -> LCL V2

obtained: the frame freezes. Takes a bit of fiddling between languages and clearing the program to get the drawing to happen again.

[rumblesan]

so there were quite a few changes to the animation loop on my initial merge branch. Didn't realise I'd missed stuff though so will give it a look.

Will also investigate the language switching issues, though tbh I'm less worried about that. I think the expectation that there could be issues when changing the compiler/interpreter is reasonable, though if they're easy to get rid of then it would be nice.

[davidedc]

I see. if language selection works fine "at restart" then perhaps easier to have it as a parameter in the url?

[rumblesan]

right, that's most things fixed. Still seems that sometimes the framerate/stats aren't being shown. will have a look at that now.

So as far as render being called, it happens as soon as there is a valid program that isn't just whitespace. This would include 1 + 1 for example. I think that's fine for the moment, but if we really want to do more optimisation later then we can.

This stuff also seems to work better when you change between versions now.

if you could give it a look over and let me know if you come across anything else that would be awesome.

[davidedc]

I'll try my best to take a look the next couple of days but I might need more time.

Let me explain what I meant by the no-render mechanism that was in place: there would be no 3d rendering happening if there were no actual geometry commands being issued in the frame. So: no buffer would be cleared, no invocation to three.js rendering, no post-processing. In other words, the "render" method in renderer.coffee would not be invoked at all in a large number of cases beyond the program being empty. That's a lot of saving...

Which is actually useful because playing sound is much more regular when there are no graphic commands in the program.

If we could have that back it would be great...

Let's see how it looks in a couple of days, worse case I'll pick the changes from your branch and put in mine rather than you taking that on your shoulders.

[rumblesan]

Right, a few more commits here. I had a look at the changes you made so that things would only render when there were graphics on screen and got things sorted. There was an issue with the way the v1 runner was saving the last working program but that should be sorted now.

have a look, and make sure it works as you expect

[rumblesan]

so I've also just had a look at the no stats issue when loading demos, and that seems to have been taken care of as well.

that basically just leaves the doOnce problem atm. will investigate that further

[rumblesan]

OK, so doOnce blocks are now working! though I suspect there is some further discussion around how exactly they should work. Hopefully this is good enough to merge now though.

Currently, doOnce blocks will work in either block or single line form, though usual caveats apply

doOnce box

doOnce background(red)

doOnce
    rotate
    box

These will all get correctly rewritten with ticks at the beginning, can have their ticks deleted to run the relevant code, and will then immediately get the ticks replaced.

At the moment, this rewriting is done for All doOnce blocks whenever any of them run, so nested doOnce blocks might not work as previously expected. TBH, I now realise that the old way the doOnce rewriting was being done wasn't such a bad idea, but a combination of a slightly messy implementation and my misunderstandings about the way events in the browser propagate meant I didn't quite get it. If we want to have nested/etc doOnce blocks working we can, but I think we need to decide what we want.

Anyway, I think this branch is now good to merge to master. There's still other fixes that have been talked about, but at least with this in we'll just have the one branch again.

[rumblesan]

have just rebased everything onto master to give us a slightly neater merge hopefully

[davidedc]

@rumblesan Hey Guy,

are there special steps to build this?

gives me the following error:

Running "requirejs:compile" (requirejs) task

Tracing dependencies for: lcl-init
Error: ENOENT, no such file or directory '/Users/daviddellacasa/livecodelab/dist/js/languages/livelangv1.js'
In module tree:
    lcl-init
      core/livecodelab-core
        core/languages

{ [Error: Error: ENOENT, no such file or directory '/Users/daviddellacasa/livecodelab/dist/js/languages/livelangv1.js'
In module tree:
    lcl-init
      core/livecodelab-core
        core/languages

    at Object.fs.openSync (fs.js:427:18)
]
  originalError: 
   { [Error: ENOENT, no such file or directory '/Users/daviddellacasa/livecodelab/dist/js/languages/livelangv1.js']
     errno: 34,
     code: 'ENOENT',
     path: '/Users/daviddellacasa/livecodelab/dist/js/languages/livelangv1.js',
     syscall: 'open',
     fileName: '/Users/daviddellacasa/livecodelab/dist/js/languages/livelangv1.js',
     moduleTree: [ 'core/languages', 'core/livecodelab-core', 'lcl-init' ] } }

[davidedc]

this seems to work: https://github.com/davidedc/livecodelab/commit/51ae7a2bcc53fda0893d880a29a9bccd27b67f28

the Require manual mentions using voodoo dolls but I ran out.

[davidedc]

this is the better fix: https://github.com/davidedc/livecodelab/commit/09eb753b493f85f2c4fd0bbd2df639adc0ed76ac

(using some really high-power voodoo dolls here)

[rumblesan]

hhmm, interesting... wonder if you're using an older version of require perhaps? as long as it's building for you though that's fine, we can get to fixing other things now

[davidedc]

seem to have latest version RequireJS 2.1.15 in js_lib directory. Mysterious, also because it compiled fine from your branch, then didn't compile after merge, which doesn't make any sense since you rebased. go figure.

[rumblesan]

So the requirejs lib in js_lib is only used when loading up the dev version of the site. When building the compressed javascript file, the r.js executable is used, via grunt, which should be installed with npm. Just doing npm install should sort it, though not sure why you got issues.

Eh, if those changes work then we can keep them

On 3 November 2014 21:07, Davide Della Casa notifications@github.com wrote:

seem to have latest version RequireJS 2.1.15 in js_lib directory. Mysterious, also because it compiled fine from your branch, then didn't compile after merge, which doesn't make any sense since you rebased. go figure.

— Reply to this email directly or view it on GitHub https://github.com/davidedc/livecodelab/pull/240#issuecomment-61548667.

[davidedc]

ah I see. indeed there was an old r.js in grunt-contrib-requirejs.

I did a rite inside a pentagon and it fixed it. Checked that the changes still worked and they still do.

considered reverting my changes but I like the new packagey way better, seems more packagey.