Hi, I noticed you had a closed issue for this on June 13, but it's doesn't appear to be resolved. Sorry I had to create another issue, my experience with commenting on a closed issues on GH is they go unanswered.

I tried installing the ruby19 branch, getting the following:

Using radius (0.7.0.prerelease) from git://github.com/jlong/radius.git (at ruby19) 
radius at /Users/.../.rvm/gems/ruby-1.9.2-p0/bundler/gems/radius-a95223efea34 did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
  ["lib/radius/parser/scan_19.rb"] are not files

My Gemfile has:

gem 'radius', :git => 'git://github.com/jlong/radius.git', :branch => 'ruby19'

I don't think the issue has anything to do with ruby-1.9.2-p0 because I have tried ruby-1.9.2-p180 and get the same result.

Short of cloning and regenerating gemspec myself I'm not sure what to do. Any advice?

The following code:

p = Radius::Parser.new
p p.parse('<fb:test>hello world</fb:test>')

outputs:

"<fb:test>hello world/fb:test>"

Not sure if this is the appropriate place...

I'm having an issue using RadiantCMS (unofficial branch) on Ruby 2.6 with Nokogiri 1.10.9 and Radius 0.7.5

In my case the selector is comming from Tag-Attribute which is a Radius::OrdString which breaks the Nokogiri-Selection:

selector = Radius::OrdString.new('div')
Nokogiri("<div></div>").css(selector).size

=> 0

While this works:

selector = 'div'
Nokogiri("<div></div>").css(selector).size

=> 1

I can't see why tags are defined each time a Context instance is created. It should be possible to define tags at class level, so speeding up application performance, since tags don't need to be created at each request.

Hello,

I have installed latest version of radius gem from GitHun and noticed the following warning:

Using radius (0.7.0.prerelease) from https://github.com/jlong/radius.git (at master)
radius at /home/closer/.rvm/gems/ruby-1.9.2-p180@studiomobile/bundler/gems/radius-d621b8ac11e9 did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
  ["lib/radius/parser/scan.rb", "lib/radius/parser/scan.rl", "lib/radius/parser/scan_19.rb"] are not files

Thanks

I've updated my performance project to add a ruby-prof test to it and the ruby-prof output for 0.8.1 and 0.9.1 as html files: https://github.com/jfahrenkrug/Radiant-Performance-Decline

It clearly shows that the new Ragel parser in Raduis 0.6.1 is horribly slow: it looks at every single byte.

See this ticket: radiant/radiant#247

Can you please add I18n support in order ParseError messages could be easily translated without affecting source code in the error.rb file?

I am using rails 2.3.11 and ruby 1.9.2 with RVM.
Ex:-
When I am passing HTML content along with the radius tag,then the Radius Parser is returning unwanted characters like \r\n and [" and multiple slashes before the double quotes.

Like :-
"<p align=\"left\">"
I am using radius gem 0.7.1.

In the current gem release (0.7.2) Utility.array_to_s is broken when used with frozen strings. I've fixed it in daf1cd0

It might be good to do a bug fix release soon.

I'd like to request a feature. I'd like to be able to use Radius tags without having to set a prefix. Eg.

  parser = Radius::Parser.new(context, :tag_prefix => nil)
  puts parser.parse(%{A small example:\n<repeat times="3">* <hello />!\n</repeat>})

Is that feasible?

Hello,

After 0.7.0.prerelease2 version the Radius don't handle '-' char in tag names. Could you please repair it?

Code to reproduce: https://gist.github.com/1336022

Thanks

It looks like will not run in Ruby 1.9.1. Although I can install it cleanly from gems and git repo most tests fail. I even tried running the simple example from the README on irb but it failed to render properly:

require 'radius'
=> true

context = Radius::Context.new do |c|

• c.define_tag 'hello' do
  

•   'Hello world'
  

  end
  c.define_tag 'repeat' do |tag|

•   number = (tag.attr['times'] || '1').to_i
  

  result = ''
  number.times { result << tag.expand }
  result
  end
  end
  => #<Radius::Context:0x92dc108 @definitions={"hello"=>#Proc:0x92dc040@(irb):4, "repeat"=>#Proc:0x92dbc1c@(irb):7}, @tag_binding_stack=[], @Globals=#<Radius::DelegatingOpenStruct:0x92dc090 @object=nil, @hash={}>>

parser = Radius::Parser.new(context, :tag_prefix => 'r')
=> #<Radius::Parser:0x92d5a9c @context=#<Radius::Context:0x92dc108 @definitions={"hello"=>#Proc:0x92dc040@(irb):4, "repeat"=>#Proc:0x92dbc1c@(irb):7}, @tag_binding_stack=[], @Globals=#<Radius::DelegatingOpenStruct:0x92dc090 @object=nil, @hash={}>>, @tag_prefix="r">

puts parser.parse(%{A small example:\n<r:repeat times="3">* <r:hello />!\n/r:repeat})
[#<Radius::ParseTag:0x982b2d0 @block=#Proc:0x982b2a8@/opt/ruby1.9/lib/ruby/gems/1.9.1/gems/radius-0.5.1/lib/radius.rb:413>, #<Radius::ParseContainerTag:0x982b1cc @contents=[#<Radius::ParseTag:0x982b050 @block=#Proc:0x982b028@/opt/ruby1.9/lib/ruby/gems/1.9.1/gems/radius-0.5.1/lib/radius.rb:413>], @attributes={"times"=>"3"}, @name="repeat", @block=#Proc:0x982afec@/opt/ruby1.9/lib/ruby/gems/1.9.1/gems/radius-0.5.1/lib/radius.rb:437>, #<Radius::ParseTag:0x982aec0 @block=#Proc:0x982ae98@/opt/ruby1.9/lib/ruby/gems/1.9.1/gems/radius-0.5.1/lib/radius.rb:422>]
=> nil

Any plans to support ruby 1.9? Any ideas on where it is breaking?

Thanks in advance,

Adrian Madrid

Hello,

I have noticed that the Radius has broken Rails applications closing by Ctrl+C.

Steps to reproduce:

1. Create empty Rails 3.0.8 app
2. Add the following string to Gemfile:

gem "radius", :git => "https://github.com/jlong/radius.git"

3. bundle install
4. rails s
5. Press Ctrl+C several times.

Application continue working.

Expected behaviour:

App should be closed after Ctrl+C

Additional Information:

• Rails 3.0.8
• Ruby 1.9.2

Let me know if required additional information.

Thanks

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.