XML parsing in Ruby - ruby-on-rails

I am using a REXML Ruby parser to parse an XML file. But on a 64 bit AIX box with 64 bit Ruby, I am getting the following error:
REXML::ParseException: #<REXML::ParseException: #<RegexpError: Stack overflow in
regexp matcher:
/^<((?>(?:[\w:][\-\w\d.]*:)?[\w:][\-\w\d.]*))\s*((?>\s+(?:[\w:][\-\w\d.]*:)?[\w:][\-\w\d.]*\s*=\s*(["']).*?\3)*)\s*(\/)?>/mu>
The call for the same is something like this:
REXML::Document.new(File.open(actual_file_name, "r"))
Does anyone have an idea regarding how to solve this issue?

I've had several issues for REXML, it doesn't seem to be the most mature library. Usually I use Nokogiri for Ruby XML parsing stuff, it should be faster and more stable than REXML. After installing it with sudo gem install nokogiri, you can use something like this to get a DOM instance:
doc = Nokogiri.XML(File.open(actual_file_name, 'rb'))
# => #<Nokogiri::XML::Document:0xf1de34 name="document" [...] >
The documentation on the official webpage is also much better than that of REXML, IMHO.

I almost immediately found the answer.
The first thing I did was to search in the ruby source code for the error being thrown.
I found that regex.h was responsible for this.
In regex.h, the code flow is something like this:
/* Maximum number of duplicates an interval can allow. */
#ifndef RE_DUP_MAX
#define RE_DUP_MAX ((1 << 15) - 1)
#endif
Now the problem here is RE_DUP_MAX. On AIX box, the same constant has been defined somewhere in /usr/include.
I searched for it and found in
/usr/include/NLregexp.h
/usr/include/sys/limits.h
/usr/include/unistd.h
I am not sure which of the three is being used(most probably NLregexp.h).
In these headers, the value of RE_DUP_MAX has been set to 255! So there is a cap placed on the number of repetitions of a regex!
In short, the reason is the compilation taking the system defined value than that we define in regex.h!
This also answers my question which i had asked recently:
Regex limit in ruby 64 bit aix compilation
I was not able to answer it immediately as i need to have min of 100 reputation :D :D
Cheers!

Related

Ruby gem origami sign signature failed

I'm trying to make the PDF file with signature with origami gem, follow this example https://github.com/gdelugre/origami/blob/master/examples/signature/signature.rb
Now i just run this signature.rb and got error
[error] Breaking on: ">>\nendobj\n..." at offset 0x1f6f3
[error] Last exception: [Origami::InvalidObjectError] Failed to parse object (no:43,gen:0) -> [ArgumentError] wrong number of arguments (given 1, expected 0; required keyword: year)
I have no idea to move forward :'<
I also found the sign method of gem at https://github.com/gdelugre/origami/blob/master/lib/origami/signature.rb, and have take a look, I can't find any specific things to do :'<
Might this example is outdate?
The error message is known see https://github.com/gdelugre/origami/issues/80
A fix should be available https://github.com/gdelugre/origami/pull/74/commits
But has not been added so use newer file from the fork https://github.com/pocke/origami/tree/fix-ruby-2.7-kwargs-warnings
Specifically you need this updated file and may need to follow any other suggestions from above.
https://github.com/pocke/origami/raw/fix-ruby-2.7-kwargs-warnings/lib/origami/filters/predictors.rb
However it always worth looking for a fork with many more recent improvements such as
https://github.com/joelsondrew/origami

Haskell-src-exts throws TemplateHaskell error

I'm trying to use the haskell-src-exts package to parse Haskell modules. Currently, I'm trying to parse the acme-io package's module, but I keep getting this error no matter what parse mode I try:
*** Exception: fromParseResult: Parse failed at [System/IO/Unsafe/Really/IMeanIt] (1:57): TemplateHaskell is not enabled
The module mentioned makes no references to TemplateHaskell, not in it's LANGUAGE pragma, nor is there a $ anywhere in the source file.
I'm wondering if my parse mode has something to do with it - here it is:
defaultParseMode { parseFilename = toFilePath m
, baseLanguage = Haskell2010
, extensions = []
, ignoreLanguagePragmas = True
, ignoreLinePragmas = True
, fixities = Nothing
}
I've also tried to replace the extensions field with knownExtensions from the parsing suite, without any luck.
This is a duplicate question of this answer - using the parseFile function fixed the issue. However, the reader should note that haskell-src-exts uses different parsing than GHC - I ran into another similar issue right after this, because haskell-src-exts can't handle multi-param contexts without -XMultiParamTypeClasses, yet GHC can, borking the parser if you're scraping Hackage. Hint may be a better option, can't say for sure though.

Emacs css-mode not loading

I'm not sure why, but on my Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.4) css-mode is not loading and with M-x css-mode gives this error in Messages:
Symbol's function definition is void: apropos-macrop
or
File mode specification error: (void-function apropos-macrop)
my css file (ending in .css) is in Fundamental. I just tried it on a 23.1.1 and CSS mode comes up and works fine.
Update: Traced problem to my autoloads. i.e., comment out autoloads
;(load "~/modes/autoloads" 'install)
and the problem goes away. I'm not sure what to hack with an autoloads file. Any way to "step" through an autoloads? Here's my autoloads: http://gmcongo.org/temp/autoloads
In Emacs 24.4 and the bleeding edge versions leading to it (like 24.3.50+), apropos-macrop has been replaced by macrop. In css-mode.el, replace the call to apropos-macrop with a call to macrop and the error goes away.
Building upon the existing correct answer, you can create an alias in your ~/.emacs instead of editing css-mode (if for example, it came in a package with your distribution):
;; For css-mode, temporarily.
(defalias 'apropos-macrop 'macrop)

Paamayim nekudotayims in PHP 5.2

I can upgrade php 5.2 in my server. I have to make this server work today (the vacation I have planned tomorrow is under question because of this error) with new testlink. I am stuck with following error i.e Paamayim nekudotayims.
What changes I should do to resolve it?
This link contains the file with the bug.
The Scope Resolution Operator (also called Paamayim Nekudotayim) or in simpler terms, the double colon, is a token that allows access to static, constant, and overridden properties or methods of a class.
SO may be in your codes you try to call static method or properties with wrong operator.
From Wikipedia:
In PHP, the scope resolution operator is also called Paamayim
Nekudotayim (Hebrew: פעמיים נקודתיים‎), which means “double colon” in
Hebrew.
The name "Paamayim Nekudotayim" was introduced in the
Israeli-developed Zend Engine 0.5 used in PHP 3. Although it has been
confusing to many developers who do not speak Hebrew, it is still
being used in PHP 5, as in this sample error message:
$ php -r :: Parse error: syntax error, unexpected
T_PAAMAYIM_NEKUDOTAYIM
As of PHP 5.4, error messages concerning the scope resolution operator
still include this name, but have clarified its meaning somewhat:
$ php -r :: Parse error: syntax error, unexpected '::'
(T_PAAMAYIM_NEKUDOTAYIM)

Issues with SWI-Prolog editor

Some time ago I was fiddling with SWI-Prolog editor, trying to get something to work, and I change some configuration settings. It didn't work so I changed it back. Now SWI-Prolog editor is not working correctly. I will load files but when I click 'consult' it will just throw this error:
consult('C:/Users/Cubearth/Documents/Prolog/'filename.pl').
and I am not able to perform queries, on the knowledge base... it just does nothing. I know that it should return:
% library(win_menu) compiled into win_menu 0.00 sec, 20,952 bytes
% library(swi_hooks) compiled into pce_swi_hooks ......... (etc, etc)
For help, use ?- help(Topic). or ?- apropos(Word).
but I am not even getting that. I tried uninstalling both prolog and the editor, but still no luck.
Any ideas on how to fix this?
In order to help, I have included the configuration dump of prolog:
Installation
C:\Program Files (x86)\SWIPrologEditor\SWIMachine.ini
C:\Users\Cubearth\AppData\Roaming\SWIPrologEditor\SWIUser.ini
C:\Users\Cubearth\AppData\Roaming\SWIPrologEditor\SWIColor.ini
[SWI]
PortableApplication=0
Verzeichnis=C:\Program Files\pl
Manual=C:\Program Files\pl\bin\doc\Manual\Contents.html
XPCE=C:\Program Files\pl\bin\doc\UserGuide\Contents.html
[Program]
InterpreterParameter=-L32M
FileExtension=.pl
[Editor]
TabWidth=2
Indent=2
Indenthelp=1
AutomaticIndent=1
FileTab=1
Linenumbering=1
BracketPair=0
CursorBehindLine=1
Author=
Encoding=0
Structure=0
[Code]
Code-Completion=1
Parameter-Hints=1
Delay=100
[Options]
ColoredConsole=1
IntegratedWindow=1
ReturnToContinue=1
TraceStopsDebugToo=1
BAKFiles=1
RemoveWriteProtection=1
FileTabsMultiline=1
Language=C:\Program Files (x86)\SWIPrologEditor\english.ini
[Browser]
UseIEinternForDocuments=1
OnlyOneBrowserWindow=0
Browser=C:\Users\Cubearth\AppData\Local\Google\Chrome\Application\chrome.exe
Title=unknown
AltKeysBrowser=
ProxyEnabled=0
ProxyIP=
ProxyPort=0
[Printer]
Left=20
Top=20
Right=20
Bottom=20
Header=#%PATH%#
Footer=##- %PAGENUM% -
Linenumbers=0
LinenumbersInMargin=1
Let me enlighten the poor lost soul that is cubearth. You should double check to see which version of swi-prolog you installed (32-bit or 64-bit), because swi-prolog editor only works with the 32-bit version. If you tried using the editor with the 64-bit version, you'll get the error described above. ^^ .
p.s. You are welcome.
Enable trace, run cmd --
?- trace. consult('C:/Users/Cubearth/Documents/Prolog/'filename.pl').

Resources