So I'm new to Julia and I'm testing out some of it's GUI capabilities with Cairo and Tk. I'm following one of the tutorials on the Julia website and I've tried out the code they have for it.
using Base.Graphics
using Cairo
using Tk
win = Toplevel("Test", 400, 200)
c = Canvas(win)
pack(c, expand=true, fill="both")
The Stacktrace it generates is as follows:
ERROR: LoadError: UndefVarError: Graphics not defined
Stacktrace:
[1] include(::Function, ::Module, ::String) at ./Base.jl:380
[2] include(::Module, ::String) at ./Base.jl:368
[3] exec_options(::Base.JLOptions) at ./client.jl:296
[4] _start() at ./client.jl:506
in expression starting at /path/to/my/julia/program.jl:1
I've installed the Graphics package, but that didn't seem to help anything. I tried to install the Base package, but it told me "* Base (not found in project, manifest or registry)."
Maybe it's me, but this trace isn't really helping describe the issue. It says Graphics is not defined, but then acts like Base is the issue. What's going on here? Any help is appreciated.
Your reading of the error was correct when you interpreted you needed to install the package: Julia is not finding a Graphics submodule inside Base (when you do using Base.Graphics, you are instructing Julia to look for the name "Graphics" inside "Base",which is why the error appears there).
What is happening is that you are following an 8 year-old blog post, from way before Julia reached its 1.0 version. Since then, the Graphics module was taken out of Base
For what I could see, if you installed the Graphics package now you should do:
using Graphics
using Cairo
using Tk
If you have not installed the package, then:
]add Graphics #(the package is now a separate package, do this only the first time)
using Graphics
But by the age of the blog post, it could be possible that you run into further issues. Let's see if someone can point you to newer material regarding graphical interfaces.
Related
For a project that I am working on, I need to use Point Cloud Library and the author of some of the code that I am reusing had suggested to go for PCL 1.8.1 and the latest branch of Eigen3. I downloaded all dependencies and built them successfully. I checked this by making sure I see them in my usr/local/include directory and also ran simple examples for each library (VTK, Boost, Eigen) to see if they work. All is good till there.
Then I downloaded PCL source from GitHub and I am able to configure it. But when I attempt to compile it, I see this error:
Downloads/pcl-pcl-1.8.1/surface/include/pcl/surface/impl/bilateral_upsampling.hpp:112:88: error: cannot convert ‘Eigen::internal::enable_if, float, float> >::type {aka Eigen::IndexedView, float, float>}’ to ‘float’ in initialization
float val_exp_depth = val_exp_depth_matrix(dx+window_size_, dy+window_size_);
I am using the following:
Ubuntu 16.04, PCL 1.8.1, VTK 8.1.1, FLANN 1.8.4, Eigen 3.3.90 (Default branch),Boost 1.68.0.
Probably unrelated: CUDA 9.1, Ceres 1.14, gtest, ROS-kinetic (I did ruin my ROS installation in the process, but I don't mind reinstalling it later. I am bringing this up, if by any chance it has some correlation that I have no clue about).
I am new to most of this, so I apologize in advance if I was not able to explain well or have not shared enough information for you to help me. Please let me know, and I'll do as much as I can. Any help is much appreciated. Thanks!
The problem is that the matrix val_exp_depth_matrix is indexed using float values (dxand dy). They must be cast to integral types, like int or long.
This issue has already been fixed in PCL repository.
I'm learning Common Lisp (Clozure CL) on the Mac and would like to create a simple GUI. I have downloaded the "ltk" library from CLiki and put it into the project directory at the root level (I assumed I had to do this as I couldn't find instructions for a beginner).
Page 4 of the "LTK - a Lisp binding to the Tk toolkit" documentation says that the library should be compiled using (compile-file "ltk") before loading the library using (load "ltk"). However, I get this error message:
Error: File #P"/Users/myName/Desktop/lisp_experiments/GUI_EXAMPLE/ltk" not found
While executing: CCL::FCOMP-FIND-FILE, in process Listener(4).
Type cmd-. to abort, cmd-\ for a list of available restarts.
Type :? for other options.
I also used the full file pathname and got the same error.
What am I doing wrong?
Thanks for your help.
Marc
ps - there are almost no noob tutorials about this sort of thing online that takes the user through the process step by step.
I have downloaded the "ltk" library from CLiki and put it into the project directory at the root level.
Nowadays, this is a step that is seldom required, because libraries are easily accessible using Quicklisp (see also this gif).
Basically, you should be able to install Quicklisp and run the following:
(ql:quickload "ltk")
The above downloads, compiles and install Lisp libraries, but not necessarily the required C libraries, which you might need to install separately. If the above works without problem, then the following should work too:
(ltk:ltktest)
Quicklisp relies on Lisp systems being described with ASDF (Another System Definition Facility). The best practices document is also interesting to read.
In the case of LTK, you can see that ltk.asd only specifies one component, ltk.lisp. When you install the system named "LTK", quicklisp will do all the necessary work to install its dependencies, then compile and load ltk.lisp, as described in the manual.
What is unclear is why your explicit compile-file failed.
I found the ltk.lisp file on my machine; its pathname looks like:
#P"/home/user/quicklisp/dists/quicklisp/software/ltk-20150113-http/ltk.lisp"
Sure enough, calling compile-file with that pathname works and returns another pathname which ends in .fasl (the object format). Loading the returned pathname loads the library. Please provide more information about the error so that we can help you debug this problem.
I'm trying to compile a custom system image of Julia to speed up the loading of some libraries, specially Gadfly. I tried the docs tutorial but Julia complains about undefined paths (it makes me require every single library) and after linking all of them about undefined variables STDOUT and STDERR. If I don't use a userimg.jl file the compilation works perfectly.
I first tried a userimg.jl file with only
include("/home/clavero/.julia/v0.4/Gadfly/src/Gadfly.jl")
but it complained about libraries not in path, with error messages like
Base.ArgumentError(msg="Codecs not found in path")
so I started including about 30 libraries in the correct order only to arrive at the errors about STDERR and STDOUT.
I'm running Julia as root to have write permission in the needed files, and runing in the root REPL homedir() gives me /root, so I suspect is a path problem.
How can I generate a custom image with Gadfly in it? Did I follow the guide wrong?
Because julia 0.4 supports package precompilation, for me loading Gadfly (with using Gadfly) is not too bad, certainly not as big of a problem as the JIT-delay in generating the first plot. So simply building in Gadfly via userimg.jl won't help much.
However, you could add precompile statements to eliminate the delay. The following may be helpful:
https://github.com/timholy/SnoopCompile.jl
https://github.com/dcjones/Gadfly.jl/pull/673
http://julia-programming-language.2336112.n4.nabble.com/Precompilation-and-functions-with-keyword-arguments-td32038.html
I have a problem with my PyCharm. After I updated Python from 3.3.5 to 3.4, I have an annoying error in PyCharm of the following form:
from multiprocessing import Queue, Process
PyCharm underlines Queue and Process in red and shows an unresolved reference. The code actually runs fine both in the command line and inside PyCharm. Code completion seems to be broken too for these classes.
I am suspecting a problem with PYTHONPATH, but I'm not sure how to solve it.
System details: Mac OS X 10.9.2, Python 3.4 installed through Homebrew, Pycharm 3.1.1
It's not a problem with PYTHONPATH. If we look in multiprocessing\__init__.py, we see the following:
#
# Copy stuff from default context
#
globals().update((name, getattr(context._default_context, name))
for name in context._default_context.__all__)
__all__ = context._default_context.__all__
Notably there is nothing in the file that looks like Queue, Process, etc.
Now what is this context._default_context? If we look in multiprocessing\context.py, we see
class BaseContext(object):
...
def Queue(self, maxsize=0):
'''Returns a queue object'''
from .queues import Queue
return Queue(maxsize, ctx=self.get_context())
So in reality, Queue is never defined in the module itself, but rather through some dynamic code, it gets set correctly at runtime depending on the user's operating system. This is why Pycharm doesn't know that there are Queue and Process classes in the multiprocessing module.
Maybe you can file a bug report and try to get them to selectively run code to figure out these dynamic names or to make an exception here and put some workaround that tells Pycharm that there are in fact Queue/Process classes, but that seems like it would be low on their priority list. So you'll just have to live with it, probably. (In the same boat here)
I'd definitely report an issue with JetBrains if one doesn't already exist, but I would not suggest downgrading Python merely due to your IDE not interpreting an import as expected (the actual interpreter still works).
I have the same issue, simply adding # noinspection PyUnresolvedReferences above the unresolved references silences the compiler 'errors'. Of course I'd love this to be fixed and will remove the # noinspection lines once it is, but it certainly won't stop me from writing code using PyCharm and Python 3.4.
Edit: Looks like someone reported it: http://youtrack.jetbrains.com/issue/PY-12860
Edit: Reportedly fixed in build 138.913
I have had the same issue. If you are using python 3.4.4, please try this:
from queue import Queue
You can read more here: https://docs.python.org/3.4/library/queue.html
I am lost in a rabbit hole, please bear with me.
I'm trying to use the OpenCV Stitching module from the 2.3.1 Win superpack distribution. I dragged all the source files in /modules/stitching into a Visual Studio project, resolved the Includes and Libs as best I could, and got it to compile.*
The first strange runtime error I had was that I could not read a JPG file from disk with imread(). It did not throw an error, but was returning true for myImage.empty(). I reverted to cvLoadImage() and then it worked.
Now, after that, there is a new runtime error:
Unhandled exception at 0x00870d8f in MyStitcher.exe: 0xC0000005: Access violation writing location 0x010e7000.
This occurs in /modules/stitching/matchers.cpp when trying to pass reference to features.keypoints as a detector_->detect() argument. I assume detect() is supposed to populate the keypoints with its result. features appears to be uninitialized (it has 612933850 empty keypoints at the breakpoint). Now this is starting to sound like the source I'm trying to compile is just broken, but opencv_stitching.exe that comes prebuilt works just fine. Was it compiled from different source?
By the way, I do not know how to use the CMake system to generate Visual Studio projects, as recommended, for OpenCV. The CMakeLists.txt file in the /modules/stitching folder did not work. Is it not supposed to be used as a starting point?
*One note on this: CMakeLists.txt in /modules/stitching specifies some
libs named opencv_core, opencv_imgproc, opencv_highgui, etc. (without
a version indication) but the libs included with OpenCV 2.3.1 Win32
superpack (which I'm linking to) are named opencv_core231.lib,
opencv_imgproc231.lib, etc. Is this a clear indication that I am using
mismatched binaries for the stitching module?
I got this working after building the latest from the OpenCV SVN. The stitching module came a long way since the 231 release.