Following up from my previous question, here, I am trying to get 'spec' files registered by Atom, which I have succeeded in, however now, no matter how many describe and it's I do, it doesn't do anything when I test it.
I use the command, apm test, and all I get is:
[655:0527/083825:WARNING:resource_bundle.cc(305)] locale_file_path.empty() for locale English
[655:0527/083825:ERROR:file_io.cc(30)] read: expected 40, observed 0
[659:0527/083825:WARNING:resource_bundle.cc(305)] locale_file_path.empty() for locale English
[655:0527/083828:INFO:CONSOLE(52)] "Window load time: 2420ms", source: file:///Applications/Atom.app/Contents/Resources/app.asar/static/index.js (52)
Finished in 0.023 seconds
0 tests, 0 assertions, 0 failures, 0 skipped
Tests passed
Judging by the spec file (which is definitely being registered, as it complains when it doesn't exist), I should have 3 tests run.
My spec file is as follows... (Syntax Highlighter package)
describe "Jazz grammar", ->
grammar = null
beforeEach ->
waitsForPromise ->
atom.packages.activatePackage("language-jazz")
runs ->
grammar = atom.grammars.grammarForScopeName("source.jazz")
it "parses the grammar", ->
expect(grammar).toBeDefined()
expect(grammar.scopeName).toBe "source.jazz"
it "tokenises keywords", ->
tokens = grammar.tokenizeLines('func')
expect(tokens[0][0].value).toBe 'func'
expect(tokens[0][0].scopes).toEqual ['source.jazz', 'storage.type.jazz']
it "tokenizes comments inside function parameters", ->
tokens = grammar.tokenizeLines('module test(arg1, ;; arg2)')
expect(tokens[0][0].value).toBe 'module'
expect(tokens[0][0].scopes).toEqual ['source.jazz', 'storage.type.jazz']
expect(tokens[0][1].scopes).toEqual ['source.jazz', 'comment.line.jazz']
My file structure is as follows:
language-jazz
grammars
jazz.cson
snippets
language-jazz.cson
spec
jazz-spec.coffee
package.json
Other GitHub and Travis CI stuff.
The problem is the indentation and structure of your tests in your spec, bear in mind that in CoffeeScript whitespace is significant and the run blocks are used to encapsulate blocks of the code not to group it statements.
So the spec should be:
describe "Jazz grammar", ->
grammar = null
beforeEach ->
waitsForPromise ->
atom.packages.activatePackage("language-jazz")
grammar = atom.grammars.grammarForScopeName("source.jazz")
it "parses the grammar", ->
expect(grammar).toBeDefined()
expect(grammar.scopeName).toBe "source.jazz"
it "tokenises keywords", ->
tokens = grammar.tokenizeLines('func')
expect(tokens[0][0].value).toBe 'func'
expect(tokens[0][0].scopes).toEqual ['source.jazz', 'storage.type.jazz']
it "tokenizes comments inside function parameters", ->
tokens = grammar.tokenizeLines('module test(arg1, ;; arg2)')
expect(tokens[0][0].value).toBe 'module'
expect(tokens[0][0].scopes).toEqual ['source.jazz', 'storage.type.jazz']
expect(tokens[0][1].scopes).toEqual ['source.jazz', 'comment.line.jazz']
I've tested this locally and it shows up as three failing tests, as I have implemented your grammar.
Related
Below is the sample code
SUBROUTINE HELLO.WORLD
*-----------------------------------------------------------------------------
*
*-----------------------------------------------------------------------------
* Modification History :
*-----------------------------------------------------------------------------
*-----------------------------------------------------------------------------
CRT "HELLO WORLD"
END
Compilation error;
01/01/2019 16:26:03 Compiling HELLO.WORLD... ERROR
Error : (line 12) HELLO.WORLD.b, No component defined. $PACKAGE is mandatory !
Compilation completed for 1 file(s). 1 error
01/01/2019 16:26:03 Compiling HELLO.WORLD... ERROR
Error : (line 12) HELLO.WORLD.b, No component defined. $PACKAGE is mandatory !
Compilation completed for 1 file(s). 1 error
I have setup (during toggle tafj project nature option in design studio);
The TAFJ_HOME correctly.
T24lib directory under "Known Libraries" section.
Java folder : ....\ProjectName-models\java.
Class folder : ....\ProjectName-models\classes.
Thank you
To switch off this check for tCompile, set these properties in tafj.properties:
temn.tafj.compiler.internal.development=false
temn.tafj.compiler.component.strict.mode=false
However, to follow the "best practice way" you should have the $PACKAGE statement, then your JBC code will be compiled into a proper Java Package and put inside a JAR file. Note that before that you should do "New-->T24Component Folder Structure" in T24 Design Studio. This will create the XX.componentname.component file where you can define the subroutines. This "XX.Local.component" has to be compiled first:
component XX.Local
# Component Isolation Definition
metamodelVersion 1.6
# -------------------------------------------------
public method helloWorld ()
{
jBC: HELLO.WORLD
}
Then you can reference the $PACKAGE in the subroutine like this:
$PACKAGE XX.Local
SUBROUTINE HELLO.WORLD
CRT 'Hello, World!'
RETURN
END
The component can also be created manually without Design Studio. You should not use the Dunce Cap (see this: https://en.wikipedia.org/wiki/Dunce) unless you have a good reason.
For R19 Right Click on project navigate to Properties->TAFJ->Compiler->Uncheck Maintain validation code.
Right click on project source folder and click “Put on / Take off the Dunce cap”. Compile again.
It's a subroutine , it needs a RETURN statement
I'm learning Puppet and the biggest frustration I have with the entire paradigm is the try/run/fix development process I'm using to build functional Puppet code. My background is in Java and I'm naturally use to debugging my code to find errors instead of just running the program to see where it bombs making development much faster but I can't seem to find a way to do this using Puppet and Eclipse. I know writing a debugger for Puppet would require some creativity given its nature but I think this is something the community could really benefit from.
I've written debuggers and know the Eclipse SDK but unfortunately it does not map cleanly to the Puppet architecture which is a bit awkward in the sense its runtime stack and execution flow does not happen in natural order as well as the fact the runtime requires a target machine to apply changes on.
I'm curious if the community has done any development work on trying to create some kind of debugger where code can be stepped. To write this I think it would make sense to extend Eclipse with a new Puppet debug configuration type where you specify a target sandbox host to test your code as well as a puppet project in your workspace you want to debug (leveraging existing Gepetto tooling). Then when you start a new Puppet debugging session Eclipse could connect to the remote host, execute puppet apply with some additional debug arguments and somehow provide feedback from the runtime about what line of code is currently being executed.
This still might be awkward but would allow puppet developers to quickly see things like oh duh.. I can't create this directory because the parent path does not exist, wait... why is this if statement not going here like I planned, oh I see here that Puppet is not very clear on single or double quotes or now I see why this fails because this class was not executed first etc. etc.
Instead all we get is a big ugly output on the agent console that yes can give us insight on errors but does not cleanly map exceptions to our code that in my view shows an underlying pain and weakness of Puppet, can you at least give me a stack trace and line number so I know where to look? Nope sorry.
Don't get me wrong, I love how Puppet can make me look very productive throughout the work week when all I'm doing is running Puppet apply on new machines which my manager has not yet figured out but I think for Puppet to really be useful this lack of debugging support is something that needs to be addressed.
Does anyone else feel this pain? - Duncan Krebs
It would be impossible to "step through" puppet code, unless you want to debug against the ruby codebase itself. It's not just that the order of "execution" is unclear, its that the manifest themselves are never executed at a single time. They are actually evaluated in multiple phases throughout execution.
There are ways to simplify finding problems though. The biggest one is writing unit tests using rspec-puppet. It lets you essentially test the compilation phase of puppet, helping you catch errors like circular dependencies, incorrect conditional logic, etc.
There is a new tool called the puppet-debugger which allows you to set breakpoints in your puppet code in order to step through it. So this is no longer "impossible" as it has been available for about 8 months.
You will first need to install the puppet-debugger gem
https://github.com/nwops/puppet-debugger
Then install the debug module, include it in your fixtures or just ensure it is in your module path.
https://forge.puppet.com/nwops/debug
Then just set a breakpoint in your code using debug::break() function.
Ruby Version: 2.0.0
Puppet Version: 4.9.4
Puppet Debugger Version: 0.6.0
Created by: NWOps
Type "exit", "functions", "vars", "krt", "whereami", "facts", "resources", "classes",
"play", "classification", "types", "datatypes", "reset", or "help" for more information.
>> $vars = ['one', 'two', 'three']
=> [
[0] "one",
[1] "two",
[2] "three"
]
>> $vars.each | String $var | {
debug::break()
notify{$var:}
}
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "one"
2:>> exit
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "two"
2:>> exit
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "three"
I'm migrating some shell scripts to Chef recipes. Some of these scripts are fairly involved, so just to make life easier in the short term and to avoid introducing bugs in rewriting everything in Chef/Ruby, I'd like to just run some of them as-is. They're all well-written and idempotent, so honestly there's no rush, but of course, the eventual goal is to rewrite them.
One cool feature of Ruby is its __END__ keyword/method: Lines below __END__ will not be executed. Those lines will be available via the special filehandle DATA.
It would be cool to ship the shell scripts as-is inside the the recipe after __END__, maybe something like the following, which I placed in chef-repo/cookbooks/ruby-data-test/recipes/default.rb:
file = Tempfile.new(File.basename(__FILE__))
file << DATA.read
bash file.path
file.unlink
__END__
echo "Hello, world"
However when I run this (with chef-solo -c solo.rb --override-runlist 'recipe[ruby-data-test]'), I get the following error:
[2014-10-03T17:14:56+00:00] ERROR: uninitialized constant Chef::Recipe::DATA
I'm pretty new to Chef, but I'm guessing the above is something about Chef wrapping my recipe in a class, and there's something simple preventing me from accessing DATA. Since it's "global" (?) I tried putting a dollar sign ($DATA) in front of it but that failed with:
NoMethodError
-------------
undefined method `read' for nil:NilClass
So the question is: How do I access DATA in my Chef recipe? Thanks!
It appears you don't have access to DATA, but you can fake it by reading in the current file yourself and splitting on __END__, like Sinatra does.
I ended up making a Chef LWRP for reuse. I don't know if I'll actually end up using this, but I wanted to figure it out. Like I said, I'm a Chef/Ruby noob, so any better ideas or suggestions welcome!
ruby_data_test/recipes/default.rb:
ruby_data_test_execute_ruby_data __FILE__
__END__
#!/bin/bash
set -o errexit
date
echo "Hello, world"
ruby_data_test/resources/execute_ruby_data.rb:
actions :execute_ruby_data
default_action :execute_ruby_data
attribute :source, :name_attribute => true, :required => true
attribute :args, :kind_of => Array
attribute :ignore_errors, :kind_of => [TrueClass, FalseClass], :default => false
ruby_data_test/providers/execute_ruby_data.rb:
def whyrun_supported?
true
end
use_inline_resources
action :execute_ruby_data do
converge_by("Executing #{#new_resource}") do
Chef::Log.info("Executing #{#new_resource}")
file_who_called_me = #new_resource.source
io = ::IO.respond_to?(:binread) ? ::IO.binread(file_who_called_me) : ::IO.read(file_who_called_me)
app, data = io.gsub("\r\n", "\n").split(/^__END__$/, 2)
data.lstrip!
file = Tempfile.new('execute_ruby_data')
file << data
file.chmod(0755)
file.close
exit_status = ::Open3.popen2e(file.path, *#new_resource.args) do |stdin, stdout_and_stderr, wait_thr|
stdout_and_stderr.each { |line| puts line }
wait_thr.value # exit status
end
if exit_status != 0 && !#new_resource.ignore_errors
throw RuntimeError
end
end
end
Here's the output:
$ chef-solo -c solo.rb --override-runlist 'recipe[ruby_data_test]'
Starting Chef Client, version 11.12.4
[2014-10-03T21:50:29+00:00] WARN: Run List override has been provided.
[2014-10-03T21:50:29+00:00] WARN: Original Run List: []
[2014-10-03T21:50:29+00:00] WARN: Overridden Run List: [recipe[ruby_data_test]]
Compiling Cookbooks...
Converging 1 resources
Recipe: ruby_data_test::default
* ruby_data_test_execute_ruby_data[/root/chef/chef-repo/cookbooks/ruby_data_test/recipes/default.rb] action execute_ruby_dataFri Oct 3 21:50:29 UTC 2014
Hello, world
- Executing ruby_data_test_execute_ruby_data[/root/chef/chef-repo/cookbooks/ruby_data_test/recipes/default.rb]
Running handlers:
Running handlers complete
Chef Client finished, 1/1 resources updated in 1.387608 seconds
Is there any way to define CoffeeScript compilation order in sub-directories?
Please consider the following example:
Files:
src/App.coffee
src/view/B.coffee
src/view/a/A.coffee
Where class A extends B.
coffee --join js/app.js --compile src/view/ src/App.coffee
This throws an error in the browser:
Uncaught TypeError: Cannot read property 'prototype' of undefined
If I rename folder a to z, the error is gone and everything works fine.
src/view/z/A.coffee
I would expect the compiler to read all .coffee files from src/view/ before it goes into src/view/ sub-directories. Again, is there any way to do that?
Edit:
PC Windows 7,
CoffeeScript version 1.3.3
The only solution I think is to create the compile order manually within a build script.
You would create an ordered collection with filenames, where as the loop iterates and concatenates a new big string, which can be compiled as one file.
Create a Cakefile with following content, check Syntax first. And run with cake build. That should work, cake comes with CoffeeScript.
fs = require 'fs'
{exec} = require 'child_process'
viewsDir = "src/view"
coffeeFiles = [
'B'
'A'
]
task 'build'
# loops through coffeeFiles.
for file, index in coffeeFiles then do (file, index) ->
fs.readFile "#{viewsDir}/#{file}", 'utf8', (err, content) ->
appCoffee[index] = content
compile() if --remaining is 0
compile = ->
fs.writeFile 'js/app.coffee', appCoffee.join('\n\n'), 'utf8', (err) ->
throw err if err
exec 'coffee --compile js/app.coffee', (err, stdout, stderr) ->
throw err if err
console.log stdout + stderr
# you can skip deleting the app.coffee file
fs.unlink 'js/app.coffee', (err) ->
throw err if err
console.log 'Created app.coffe, compiled to app.js and removes app.coffee'
# maybe additional taks
# invoke 'test'
Documented also in Wiki of Coffeescript https://github.com/jashkenas/coffee-script/wiki/[HowTo]-Compiling-and-Setting-Up-Build-Tools
Before first loop you could also make it loop through different directories. And just list filenames in coffeeFiles to be processed before the others not in listed and the rest could be added to list with fs.readDir().
We created a simple module to solve a similar problem:
https://github.com/Vizir/rehab
Just put #_require [filename].coffee on your file and you're done.
We are using it in productions with complex dependency graphs.
How does one access command line flag (arguments) as environment variables in Erlang. (As flags, not ARGV) For example:
RabbitMQ cli looks something like:
erl \
...
-sasl errlog_type error \
-sasl sasl_error_logger '{file,"'${RABBITMQ_SASL_LOGS}'"}' \
... # more stuff here
If one looks at sasl.erl you see the line:
get_sasl_error_logger() ->
case application:get_env(sasl, sasl_error_logger) of
% ... etc
By some unknown magic the sasl_error_logger variable becomes an erlang tuple! I've tried replicating this in my own erlang application, but I seem to be only able to access these values via init:get_argument, which returns the value as a string.
How does one pass in values via the commandline and be able to access them easily as erlang terms?
UPDATE Also for anyone looking, to use environment variables in the 'regular' way use os:getenv("THE_VAR")
Make sure you set up an application configuration file
{application, fred,
[{description, "Your application"},
{vsn, "1.0"},
{modules, []},
{registered,[]},
{applications, [kernel,stdlib]},
{env, [
{param, 'fred'}
]
...
and then you can set your command line up like this:
-fred param 'billy'
I think you need to have the parameter in your application configuration to do this - I've never done it any other way...
Some more info (easier than putting it in a comment)
Given this
{emxconfig, {ets, [{keypos, 2}]}},
I can certainly do this:
{ok, {StorageType, Config}} = application:get_env(emxconfig),
but (and this may be important) my application is started at this time (may actually just need to be loaded and not actually started from looking at the application_controller code).