Smalltalk › Amber Smalltalk

Ban JS files from version control

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Markus Kahl

Ban JS files from version control

Hey!

I'm about to start a new project (a game) in the browser and I didn't feel like writing Javascript again.

So I looked around and found Amber. Looks nice. I really like Smalltalk.

So I started playing with it. First thing I noticed was that in the amber repository not only the Smalltalk but also the Javascript files are under version control. I imagine this must be a pain in the ass to merge. Especially when all that really should be relevant is the Smalltalk source and not the derived Javascript source, or am I missing something here?

The ultimate goal is not having any Javascript files under version control.

For starters I would be happy to have this only for my own files outside of Amber. Then again I'm definitely going to change Amber Kernel classes too in the course of my project to add fancy methods all over the place. So ultimately it would be good if this was supported for all loaded files.

Anyway I started pimping my fork of Amber.

So if someone else commits a new file to our project it will show up as a new .st file.

The JS is in .gitignore. For me to be able to run it it has to be compiled first.

So that's what I did. If amber.js tries loading files like this:

<script type="text/javascript">
loadAmber({
deploy: false, // only works in dev mode obviously since we need the compiler
files: ['MyGame', 'MyGame-Support'],
prefix: 'game/js'
});
</script>

With only MyGame.js in game/js but with both MyGame.st and MyGame-Support.st in game/st.

When MyGame-Support.js cannot be found amber.js will import that .st file and save the according Javascript. The next step would be that it recognises when existing .st files have been updated (say through a merge) and to recompile them on that occasion. All that's left to do for that is to extend the FileServer to be able to watch files and support some kind of AJAX/comet request for update notifications. Or perhaps simply support for HEAD requests. But polling is not that cool.

I will do something along those lines next.

Questions

Right now I'm only importing single files with no dependencies between each other, but that case will surely arise. I'm guessing just using the Importer won't do for this scenario? But I should be able to do it somehow using the Compiler directly, right?
Am I missing anything that would stand in the way of me and my goal? Right now it doesn't seem as though it should be much of a problem. All I need is a bit of time (damn you dissertation!).

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Dave Mason-3

Re: Ban JS files from version control

On Sat, Jun 15, 2013 at 6:05 AM, Markus Kahl <[hidden email]> wrote:

The ultimate goal is not having any Javascript files under version control.

Absolutely!

For starters I would be happy to have this only for my own files outside of Amber. Then again I'm definitely going to change Amber Kernel classes too in the course of my project to add fancy methods all over the place. So ultimately it would be good if this was supported for all loaded files.

Just wanted to point out that if your changes to the Kernel classes simply involve adding methods (as is my situation so far), then setting the category of the method to *YourProject will cause them to be saved and loaded with YourProject (the same as the Monticello VCS on Pharo/Squeak). Of course, this doesn't help if you start *modifying* methods.

When MyGame-Support.js cannot be found amber.js will import that .st file and save the according Javascript.

That's one route. I am just about to set up the alternative route: when you pull a new version, (automatically) use amberc to compile the .st files to .js files.

../Dave

Markus Kahl

Re: Ban JS files from version control

Hey Dave!

Your route sounds like a good idea. How would this deal with merge conflicts? Could there perhaps be a hook for resolving (commiting) that?

I think in my route I will do it so that the IDE informs the user that the source has changed on the hard disk offering to reload.

That would also lead to the question how to handle conflicts between the life version and the version in the file, though.

Well, I will see where all this leads me.

Thanks for the tip on how to add methods to Kernel classes within your own package.

I would indeed also mostly add new methods rather than change existing ones.

~ Markus

Am Samstag, 15. Juni 2013 16:14:13 UTC+1 schrieb Dave Mason:

On Sat, Jun 15, 2013 at 6:05 AM, Markus Kahl <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="kh1HT1X-KXEJ">mach...@...> wrote:

The ultimate goal is not having any Javascript files under version control.

Absolutely!

For starters I would be happy to have this only for my own files outside of Amber. Then again I'm definitely going to change Amber Kernel classes too in the course of my project to add fancy methods all over the place. So ultimately it would be good if this was supported for all loaded files.

Just wanted to point out that if your changes to the Kernel classes simply involve adding methods (as is my situation so far), then setting the category of the method to *YourProject will cause them to be saved and loaded with YourProject (the same as the Monticello VCS on Pharo/Squeak). Of course, this doesn't help if you start *modifying* methods.

When MyGame-Support.js cannot be found amber.js will import that .st file and save the according Javascript.

That's one route. I am just about to set up the alternative route: when you pull a new version, (automatically) use amberc to compile the .st files to .js files.

../Dave