squiddev-cc / howl Goto Github PK

What about adding a Dependencies:Resource(f) function that includes the resource as a multilinestring instead of code?

Link to packager

Let me know if you need me to explain what certain parts do, it isn't programmed in the cleanest way as you likely noticed.

The packager software will be changed between now and Titanium's full release, hopefully that won't cause problems when ensuring Howl uses the latest version of the packager.

The packager already handles minification, the advantage of it running in Howl would largely be it's dependency management.

The environment and options hooks are ugly.

I'm thinking a better way would be to use Mediator Lua. This is a simplistic event system. So instead we might do something like:

Mediator:subscribe({"HowlFile", "env"}, function(env)
  env.Something = MyModule
end)

I think this would also be useful for the Combiner module. Since #14, this is getting complicated. Rearranging it so it uses events in separate modules might be the nicer option. We could have Combiner:StartFile, Combiner:StartModule, etc...

Try to use native package.preload and require if available. When a program is shipped as an API, people will be able to require the provided file and it'll populate the preload table.

Cloning Howl to a root directory is broken

There's a bug in the Combiner: line 64 should be "if not noWrap then" (same with line 66)

There should be an 'Interop' module. It would be great to run Howl in normal lua. We would need to override the file system and terminal:

• Terminal colours: AnsiColors
• File system LuaFileSystem

Lua file system

The functions can be found here

• lfs.attributes - This can be used for fs.exists, fs.isDir
• lfs.mkdir - Replacement for fs.makeDir
• lft.dir - Replacement for fs.list. Creates an iterator instead of a table though.
• Pure lua IO - fs.open

Terminal

• Cursor, clear - Escape sequences
• Scroll - Nope, cannot be done. Also done via escape sequences
• Colours - use AnsiColors (and Wikipedia)

Installed via pastebin run LYAxmSby get 703e2f46ce68c2ca158673ff0ec4208c/Howl.min.lua Howl

Tried pastebin run LYAxmSby get 703e2f46ce68c2ca158673ff0ec4208c/Howl.lua Howl and that worked (well stopped after not finding a Howlfile, but that's my fault).

build a project with :LineMapper() and :Traceback(), open the built file and look for the line the lineToModule table and the modulestarts table is declared.
it says:
lineToModule = setmetatable(nil, ...
modulestarts = nil

The TraceMapper (Traceback + Linemapper = TraceMapper) errors and can't call the finalize function, too.

If you try to use bedrock for example as a module, the built program will crash because the function it's contained in has no varargs, but it tries to access varargs.

The fix is simple: just emit local <modulename> = _W(function(...) <modulecontent> end) instead of the old local <modulename> = _W(function() <modulecontent> end)

http://www.computercraft.info/forums2/index.php?/topic/11067-idea-exchange/page__view__findpost__p__235132

https://developer.github.com/guides/building-a-ci-server/

Could you add a way to minify a whole folder? And it would be nice to have a flag to do it recursively.

If you minify a program that has the linemapping feature enabled, the linenumbers used by the linemapper will be broken.

It would be cool to port Moonscript to CC. However it does rely on LPeg. A pure Lua implementation exists but will be much, much slower. The only reason this is here is that we should have Howl support.

Implement a source minifier using an adapted version of this
Started some stuff on minify

It would be nice to have a testing framework with build in support for Howl. Busted looks like a nice choice.

I'm not sure if tests should count as a task or should be printed in a sub panel, probably the latter.

#5 is now implemented, so some tests would be nice. I think the best way would be to build Howl with globals/exporting turned on. Then we could test individual options without a HowlFile.

In my project, I have a task to upload to a gist. I set up the settings.lua file in .howl so that it had my github key in it. It still showed the "You have no github key" message.

My .howl/settings.lua looks like:

{
    ["githubKey"]="redacted"
}

Various things required to make Howl easier to use:

• Add argument validation to all public facing methods
• Detect between programmer and user errors.
• Document all tasks, globals and plugins
• Add a series of libraries to perform standard tasks: path handling, etc...
• Auto-create namespace tasks for those beginning with :.

Thanks to CCTweak's HTTP tweaks we should be able to edit pastebin pastes by simulating the login process. This project has done it already in Javascript.

We can just use the same format as the Gist block, but only allowing one file.

At the moment Howl is quite a small project at the moment. However, when building larger projects (such as #2 (LDoc), #6 (Moonscript) or maybe #5 (Busted testing)) we should be able to define namespaces/sub-modules. The syntax should be something like:

sources:Name "Utils.lua"
    :Name "Utils"

sources:Namespace('thing', 'thing', function(lexer)
    lexer:File "Foo.lua"
        :Name "Foo"
        :Depends "Bar"
    lexer:File "Bar.lua"
        :Name "Bar"
        :Depends "Utils"
end)

sources:Name "Something"
     :Depends "lexer.Foo"

The function should be of the type: :Namespace(name, path, generator). When combining/bootstrapping the files should be run inside a sub namespace. The above would generate this:

--All the header stuff

local Utils = _W(function() ... end)
local lexer = _W(function()
  local Bar = _W(function()
    return function()
      Utils.Print("HELLO")
    end
  local Foo = _W(function() Bar() end)

  -- We then export all functions
  return {
    Foo = Foo,
    Bar = Bar,
  }
end)

local Something = _W(function() lexer.Foo() end)

Something to be considered is to store modules in separate Howlfiles. Then load them with loadfile or something.

Wrote down some ideas for Howl 1.0. Heavily inspired by Rake and Groovy, though I'd like to chuck some Gulp into there too.

The aim would be to make it more:

• Extensible: add the ability to write plugins
• Sensible: Incremental builds
• Powerful: Adding in support for source transformations, documentation generation, etc...

It would be nice to be able to build Grin packages. We would need to zip them and then base64 encode them.

Using deflate to compress them would be optional, but nice.

It would be wonderful if we could optimise some basic Lua constructs:

• if false then ... end - we can remove entirely
• if true then ... end - we can replace with do ... end
• Constant evaluation ( true and true , 0.2*4 , etc...)
• while false / repeat until false - Run never/once.
• for i = 1, 1, 1 do ... end - Replace with do ... end

A task should be able to depend on a file being generated, like Rake.

Something like:

aTask:Produces('myFile.lua') -- Produces a file

anotherTask:Requires('myFile.lua`) -- Calls aTask first

Using patterns and wildcards would be nice

-- Anything that looks like {name}.lua is replaced with {name}.min.lua. 
-- What we actually do is when {name}.min.lua is requested we pass in {name}.lua {name}.min.lua
-- This isn't as intuitive, but from a code position, makes more sense
aTask:Maps('ptrn:%1%.lua', 'ptrn:.+%.min%.lua') 

-- Wildcards are just replaced at runtime. '*' is replaced with '(.*)' or '%1'.
aTask:Maps('wild:src/*.lua', 'wild:build/*.lua')

-- Runs aTask with `something.lua` as an argument.
anotherTask:Requires('something.min.lua') 

We should be able to capture life cycle events of tasks and environments. This would allow abstracting some existing features into plugins:

• Add events for start/finish/error of
  • Tasks
  • Task cycle (instantiation of Runner)
  • Howlfiles
• Move task timings into plugin
• Move task status output into plugin (maybe)

Currently the dependency system is rather susceptible to breaking, especially on mappings: they tend to send it into an infinite loop. Some tasks do not correctly set the outputs or inputs or do not gather all inputs, resulting in a fairly limited system. Ideally we would be able to have:

• Breadth first search of dependency tree
• Sources capture outputs of other tasks: *.lua could capture the output of other tasks. It might be possible to have *.min.lua use a mapping task to minify a source set. We would have to see.

It might also be nice to detect whether dependencies have changed or not and so have some form of incremental compilation.

• Allow basic help
• License

Currently renaming variables is broken, especially for loop variables. The trouble lies where normal variables are renamed so they conflict with existing variables:

local something = "HELLO"
local a = "HELLO"
for t=1,10 do print(a) end

becomes:

local t = "HELLO"
for t=1,10 do print(t) end

The second loop is broken. We could fix this with a proper set of nodes maybe?

What is happening is something is converted to e. Then e is converted to t for some reason?

It breaks the code when a semicolon is used to determine an ambiguous syntax, it doesn't place a semicolon in the output. For example:

something(a, b); (c or d)(x, y) becomes something(a, b)(c or d)(x, y) in the minified code, which will result in an attempt to call nil

If no arguments are given and no Howlfile is found then have the program suggest running Howl -h.

Also don't try to find HowlFile when viewing help.

@ardera Suggested:

ardera, on 07 January 2015 - 06:43 PM, said:
What about adding a task which builds a program from a GitHub repository? I think luarocks has this option too.
something like this:
howl webbuild SquidDev-CC/Howl
It would fetch the repository to a cache directory, and try to run the build task.

What do you think?

Yeah, I don't see why not. I mostly use Grin-Get or pastebin for releases, this is possible. I think a task should be defined in the HowlFile though. Like :Default but :WebBuild. Development is different to deployment, so it should be different commands.

The idea would be Howl WebBuild SquidDev-CC/Howl would clone the Howl repo, and run the :WebBuild task.

I'm wondering if we could use an emulated file system such as Compilr so we don't end up spamming the file system. Anything that the task :Produces would be saved to the filesystem.

Use the BSRocks versions of busted and LDoc.

See #2

Port LDoc to CC, so documentation generation can be automated.
I need to think about how this should be implemented. the options are:

1. CCML: The trouble with this is that it won't work on normal browsers
2. HTML: Won't work in CC
3. Custom format - in game documentation browser

A mix of 2 and 3 seem most likely, but I don't know yet.