Uninitialized constant NSJSONSerialization - macruby

How can I get NSJSONSerialization to be recognized in macruby?
framework 'foundation'
puts NSXMLDocument
#=> NSXMLDocument
puts NSJSONSerialization
#=> /Users/home/Desktop/Dropbox/script.rb:3:in `<main>':
uninitialized constant NSJSONSerialization (NameError)
also
$ macruby -v
MacRuby 0.12 (ruby 1.9.2) [universal-darwin10.0, x86_64]

Actually, I feel like a dunce, this fails because I was running on Snow Leopard. NSJSONSerialization isn't supported until 10.7.
I'll leave this question up for anyone else who stubbles across the same thing.

irb(main):001:0> framework 'foundation'
=> true
irb(main):002:0> puts NSJSONSerialization
NSJSONSerialization
=> nil
irb(main):014:0> NSJSONSerialization.dataWithJSONObject(['dog', 'cat', 'rabbit'], options:0, error:nil).to_str
=> "[\"dog\",\"cat\",\"rabbit\"]"
$ macruby -v
MacRuby 0.13 (ruby 1.9.2) [universal-darwin10.0, x86_64]
Maybe it's fixed in later builds. This actually is not specific to RubyMotion, but NSJSONSerialization is something of broad enough interest it's worth keeping the question tagged as such.

Related

difference yap and swi-prolog reading canonical lists

I have the following test code trying to read file into a list
open('raw250-split1.pl', read, Stream),
read(Stream,train_xs(TrainXs)),
length(TrainXs, MaxTrain).
I will omit part of the output due to the file is quite large.
It works well with yap,
➜ chill git:(master) ✗ yap [18/06/19| 5:48PM]
% Restoring file /usr/lib/Yap/startup.yss
YAP 6.2.2 (x86_64-linux): Sat Sep 17 13:59:03 UTC 2016
?- open('raw250-split1.pl', read, Stream),
read(Stream, train_xs(TrainXs)),
length(TrainXs, MaxTrain).
MaxTrain = 225,
Stream = '$stream'(3),
TrainXs = [[parse([which,rivers,run,through,states,bordering,new,mexico,/],answer(_A,(river(_A),traverse(_A,_B),next_to(_B,_C),const(_C,stateid('new mexico')))))],
<omited output>
,[parse([what,is,the,largest,state,capital,in,population,?],answer(_ST,largest(_SU,(capital(_ST),population(_ST,_SU)))))]]
But on swi-prolog, it will produce Type error
➜ chill git:(master) ✗ swipl [18/06/19| 7:24PM]
Welcome to SWI-Prolog (threaded, 64 bits, version 7.6.4)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit http://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
?- open('raw250-split1.pl', read, Stream),
read(Stream, train_xs(TrainXs)),
length(TrainXs, MaxTrain).
ERROR: raw250-split1.pl:4:
Type error: `list' expected, found `parse(which.(rivers.(run.(through.(states.(bordering.(new.(mexico.((/).[])))))))),
<omited output>
,answer(_67604,(state(_67604),next_to(_67604,_67628),const(_67628,stateid(kentucky))))).[].(parse(what.((is).(the.(largest.(state.(capital.(in.(population.((?).[])))))))),answer(_67714,largest(_67720,(capital(_67714),population(_67714,_67720))))).[].[]))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))' (a compound)
In:
[10] throw(error(type_error(list,...),context(...,_67800)))
[7] <user>
Note: some frames are missing due to last-call optimization.
Re-run your program in debug mode (:- debug.) to get more detail.
What might be the problem for the error here?
File raw250-split1.pl can be found from the ftp url below, if you'd like to try it.
Thank you for the help!
I am trying to migrate an earlier code to SWI-Prolog, which was written in
SICStus 3 #3: Thu Sep 12 09:54:27 CDT 1996 or earlier
by Raymond J. Mooney ftp://ftp.cs.utexas.edu/pub/mooney/chill/.
All the questions with this tag are all related to this task. I'm new to prolog, helps and suggestions are welcomed!
The raw250-split1.pl was apparently written using canonical notation. The traditional list functor is ./2 but SWI-Prolog 7.x changed it to '[|]'/2 in order to use ./2 for other purposes. This results in the the variable TrainXs being instantiated by the read/2 call to a compound term whose argument is not a list:
?- open('raw250-split1.pl', read, Stream), read(Stream,train_xs(TrainXs)).
Stream = <stream>(0x7f8975e08e90),
TrainXs = parse(which.(rivers.(run.(through.(states.(bordering.(... . ...)))))), answer(_94, (river(_94), traverse(_94, _100), next_to(_100, _106), const(_106, stateid('new mexico'))))).[].(parse(what.((is).(the.(highest.(point.(... . ...))))), answer(_206, (high_point(_204, _206), const(_204, stateid(montana))))).[].(parse(what.((is).(the.(most.(... . ...)))), answer(_298, largest(_300, (population(_298, _300), state(...), ..., ...)))).[].(parse(through.(which.(states.(... . ...))), answer(_414, (state(_414), const(..., ...), traverse(..., ...)))).[].(parse(what.((is).(... . ...)), answer(_500, longest(_500, river(...)))).[].(parse(how.(... . ...), answer(_566, (..., ...))).[].(parse(... . ..., answer(..., ...)).[].(parse(..., ...).[].(... . ... .(... . ...))))))))).
YAP still uses the ./2 functor for lists, which explains why it can handle it. A workaround for SWI-Prolog is to start it with the --traditional command-line option:
$ swipl --traditional
...
?- open('raw250-split1.pl', read, Stream), read(Stream,train_xs(TrainXs)).
Stream = <stream>(0x7faeb2f77700),
TrainXs = [[parse([which, rivers, run, through, states, bordering|...], answer(_94, (river(_94), traverse(_94, _100), next_to(_100, _106), const(_106, stateid('new mexico')))))], [parse([what, is, the, highest, point|...], answer(_206, (high_point(_204, _206), const(_204, stateid(montana)))))], [parse([what, is, the, most|...], answer(_298, largest(_300, (population(_298, _300), state(...), ..., ...))))], [parse([through, which, states|...], answer(_414, (state(_414), const(..., ...), traverse(..., ...))))], [parse([what, is|...], answer(_500, longest(_500, river(...))))], [parse([how|...], answer(_566, (..., ...)))], [parse([...|...], answer(..., ...))], [parse(..., ...)], [...]|...].
The type error you get is due to the length/2 expecting a list when the first argument is bound.
There is a tilde as last character in that file, causing the syntax being invalid, so you should remove it before reading. I don't know why YAP accept the file as valid, should raise an error AFAIK.
There is a read option dotlists/2 in SWI-Prolog:
dotlists(Bool)
If true (default false), read .(a,[]) as a
list, even if lists are internally nor constructed
using the dot as functor. This is primarily intended
to read the output from write_canonical/1 from
other Prolog systems. See section 5.1.
http://www.swi-prolog.org/pldoc/man?predicate=read_term/2
This gives you the desired result, without changing the mode:
Welcome to SWI-Prolog (threaded, 64 bits, version 8.1.0)
?- read_term(X, [dotlists(true)]).
|: .(a,.(b,.(c,[]))).
X = [a, b, c].

python 3.5: numpy - how to avoid deprecated technique

I'm just starting to teach myself to program in Python and I'm getting a "error" message I don't understand:
DeprecationWarning: converting an array with ndim > 0 to an index will
result in an error in the future
value_could_be[i0:i1, j0:j1, k] = 0
value_could_be is a 9*9*9 numpy.ndarray of integers.
i0, i1, j0, j1, k are all integers, presumably valid as subscripts as the code works just as I want it to.
value_could_be[i, :, k] = 0
doesn't generate the same warning
How should I code this to be future proof?
I'm running numpy 1.10.1, python 3.5, spyder 2.3.7, anaconda 2.2.0 (originally installed with python 2.7 and python 3.5 added later). The whole is running under OSX Mountain Lion.
When I Google the message I find references to "theano" but as far as I am aware I'm not using that. Neither do I want to just suppress the message.

How can I figure out how scipy is generating its C code?

I have the same exact versions of numpy (1.9.3) and scipy (0.17.0.dev0+7dd2b91) installed on my laptop and on a computing cluster.
When I run scipy.test on my laptop, it completes without any failures. But when I run scipy.test on the computing cluster, it completes with a single failure, reported in this question.
I've traced the cause of this failure to the file scipy/linalg/_decomp_update.so, which is a C file (I believe . . . or C++?), not a Python file.
Hence, I've concluded that the C software on my laptop differs from that on the cluster.
My question is, what is the relevant C software? Which compiler does scipy use by default? How do I check what version of C I have installed?
Update #1
Note that the .so file is compiled. The original files in the Git repo from which I installed scipy are _decomp_update.c, _decomp_update.pyx, and _decomp_update.pyx.in.
Perhaps the relevant difference between my laptop and the cluster isn't in the C code, but in the Python package that translates between C and Python (which in this case appears to be cython)?
My laptop has cython version 0.23.2.
The cluster has cython version 0.22.1.
I am currently updating the cluster's version and re-running the tests.
Update #2
I now have cython version 0.23.3 installed on both my laptop and the cluster.
The failure persists on the cluster; it continues not to occur on my laptop.
Hence, the difference seems to be in the C implementation itself, not in Python or cython.
Because the cython docs mention gcc as the standard C compiler it uses, it makes sense to me to check this.
On the cluster, I have gcc version 4.4.7.
On my laptop, I have 4.8.4.
In the future I may want to update the cluster's version and re-run the tests.
Update #3
I aborted the update to gcc in order to invetigate whether the cluster's versions of LAPACK and BLAS differ from those on my laptop (see the comment below). I followed this answer.
This is what I see for my laptop:
$ cd /usr/local/lib/python2.7/dist-packages/scipy/linalg/
$ ldd cython_lapack.so
linux-gate.so.1 => (0xb7792000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0xb7159000)
libblas.so.3 => /usr/lib/libblas.so.3 (0xb6a7e000)
libgfortran.so.3 => /usr/lib/i386-linux-gnu/libgfortran.so.3 (0xb697f000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6939000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb691c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb676e000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6752000)
libquadmath.so.0 => /usr/lib/i386-linux-gnu/libquadmath.so.0 (0xb66d6000)
/lib/ld-linux.so.2 (0xb7793000)
This is what I see on the cluster:
dbliss#nx3[~]> cd lib/python2.7/site-packages/scipy/linalg/
dbliss#nx3[linalg]> ldd cython_lapack.so
linux-vdso.so.1 => (0x00007ffe6bbec000)
liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007fceb3f35000)
libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007fceb3cdd000)
libpython2.7.so.1.0 => not found
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007fceb39eb000)
libm.so.6 => /lib64/libm.so.6 (0x00007fceb3766000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fceb3550000)
libc.so.6 => /lib64/libc.so.6 (0x00007fceb31bc000)
libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007fceb2f9c000)
libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007fceb2d7c000)
/lib64/ld-linux-x86-64.so.2 (0x000000377cc00000)
libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007fceb2720000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fceb2502000)
There are differences here for sure, but are there any important differences?

How to compile WPF IronPython project to exe

I've seen many questions in this forum which are questions of how to fix a problems of compiling IronPython WPF to exe.
But the problem is that I haven't seen any guide Step-by-step of how to compile my project.
I understood it includes using the clr module.
I've 6 files:
Window.py, Window.xaml.
Window1.py, Window1.xaml.
Window2.py, Window2.xaml.
That's all the files
Thanks
((irrelevant: Update- 3 hours later:
I've started using SharpDevelop and when I run it through the software itself it can be run. However , when I try to run this through the .exe file in the project's folder it doesn't work... ))
Update 2 - SharpDevelop created an exe file which works but the problem is it didn't encrypt my xaml to dll ..
Have you tried the script from this thread: Ironpython 2.6 .py -> .exe
Supposedly it includes wpf support:
#!/usr/bin/env python
# CompileToStandalone, a Python to .NET ILR compiler which produces standalone binaries
# (C) 2012 Niall Douglas http://www.nedproductions.biz/
# Created: March 2012
import modulefinder, sys, os, subprocess, _winreg
if len(sys.argv)<2:
print("Usage: CompileEverythingToILR.py <source py> [-outdir=<dest dir>]")
sys.exit(0)
if sys.platform=="cli":
print("ERROR: IronPython's ModuleFinder currently doesn't work, so run me under CPython please")
sys.exit(1)
sourcepath=sys.argv[1]
destpath=sys.argv[2][8:] if len(sys.argv)==3 else os.path.dirname(sys.argv[0])
ironpythonpath=None
try:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, None)
except Exception as e:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\Wow6432Node\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, "")
except Exception as e:
pass
finally:
if ironpythonpath is not None:
_winreg.CloseKey(keyh)
print("IronPython found at "+ironpythonpath)
else:
raise Exception("Cannot find IronPython in the registry")
# What we do now is to load the python source but against the customised IronPython runtime
# library which has been hacked to work with IronPython. This spits out the right set of
# modules mostly, but we include the main python's site-packages in order to resolve any
# third party packages
print("Scanning '"+sourcepath+"' for dependencies and outputting into '"+destpath+"' ...")
searchpaths=[".", ironpythonpath+os.sep+"Lib"]
searchpaths+=[x for x in sys.path if 'site-packages' in x]
finder=modulefinder.ModuleFinder(searchpaths)
finder.run_script(sourcepath)
print(finder.report())
modules=[]
badmodules=finder.badmodules.keys()
for name, mod in finder.modules.iteritems():
path=mod.__file__
# Ignore internal modules
if path is None: continue
# Ignore DLL internal modules
#if '\\DLLs\\' in path: continue
# Watch out for C modules
if os.path.splitext(path)[1]=='.pyd':
print("WARNING: I don't support handling C modules at '"+path+"'")
badmodules.append(name)
continue
modules.append((name, os.path.abspath(path)))
modules.sort()
print("Modules not imported due to not found, error or being a C module:")
print("\n".join(badmodules))
raw_input("\nPress Return if you are happy with these missing modules ...")
with open(destpath+os.sep+"files.txt", "w") as oh:
oh.writelines([x[1]+'\n' for x in modules])
cmd='ipy64 '+destpath+os.sep+'pyc.py /main:"'+os.path.abspath(sourcepath)+'" /out:'+os.path.splitext(os.path.basename(sourcepath))[0]+' /target:exe /standalone /platform:x86 /files:'+destpath+os.sep+'files.txt'
print(cmd)
cwd=os.getcwd()
try:
os.chdir(destpath)
retcode=subprocess.call(cmd, shell=True)
finally:
os.chdir(cwd)
sys.exit(retcode)

How to compile a C extension as part of a ruby gem with mkmf on Mac OS X?

I am trying to create a gem that wraps libpuzzle, but cannot figure out this flat_namespace issue:
--- personal/sayzame ‹master* M⁇› » gem build sayzame.gemspec && gem install sayzame-0.0.1.gem
Successfully built RubyGem
Name: sayzame
Version: 0.0.1
File: sayzame-0.0.1.gem
Building native extensions. This could take a while...
Successfully installed sayzame-0.0.1
1 gem installed
--- personal/sayzame ‹master* M⁇› » pry -rsayzame -Ilib
[1] pry(main)> Sayzame.compare_images :a, :b
dyld: lazy symbol binding failed: Symbol not found: _puzzle_init_dvec
Referenced from: /usr/local/lib/libpuzzle.dylib
Expected in: flat namespace
dyld: Symbol not found: _puzzle_init_dvec
Referenced from: /usr/local/lib/libpuzzle.dylib
Expected in: flat namespace
[1] 56394 trace trap pry -rsayzame -Ilib
My full source code here: https://github.com/neezer/sayzame
I'm fairly sure the problem is in my ext/puzzle/extconf.rb file, in that I am not linking the library correctly. I have already posted on ffi/ffi's issue tracker about it and followed up on those two leads with no success.
I would really appreciate any and all help here; been banging my head against the wall for quite sometime on this.
Possibly related:
- https://groups.google.com/d/msg/picky-ruby/8kuG8FkATgU/89JLc6U7SrcJ

Resources