Can not compile to a native executable with Clozure CL on OS X 10.10 Yosemite - build

I have created a simple hello world (hello.lisp) ,code:
(defun main ()
(format t "Hello,World"))
, program to test CCL's native executable compilation. I proceed to compile and load buffer from the CCL GUI (using version Clozure Common Lisp Version 1.10-store-r16266 (DarwinX8664)).
When i test it:
? (main)
Hello,World
NIL
?
It finds the main function. When i proceed to compile it with: (save-application "/tmp/h" :toplevel-function #'main :prepend-kernel t), it proceeds with the operation and CCL exits.
The file is created and is arround ~56MB. When i try to run it though I get the following output:
Error: There is no applicable method for the generic function:
#
when called with arguments:
(# :NOTE-CURRENT-PACKAGE #)
While executing: #, in process toplevel(6).
Error: There is no applicable method for the generic function:
#
when called with arguments:
(# :BREAK-OPTIONS-STRING T)
While executing: #, in process toplevel(6).
Error: There is no applicable method for the generic function:
#
when called with arguments:
(# :BREAK-OPTIONS-STRING T)
While executing: #, in process toplevel(6).
Error: There is no applicable method for the generic function:
#
when called with arguments:
And the errors proceed. What do I do wrong? Is it a bug?
Thank you

I found the keywords :note-current-package and :break-options-string in the cocoa-ide of the sources. Since prepend-kernel t prepends the kernel that was used in the current session, it seems that you would include the cocoa-ide startup in your application. However, the methods dispatching on those keywords only dispatch on ´ns-application`s, which your new application seems not to be.
The solution might be to prepend a kernel without cocoa-ide, either by loading your code into a non-GUI image, or by using the pathname of such a kernel for the :prepend-kernel argument.

To create executables of Clozure CL on Mac OS X:
for non-GUI applications, you need to install Clozure CL from the repository: Installing Clozure CL. You need to download CCL from there. This version comes with an executable Lisp (kernel + image), which hasn't the GUI loaded.
for GUI applications you need to use the Application Builder. The corresponding function is ccl::build-application. GUI applications on Mac OS X need some infrastructure, which is created then. Note that CCL comes with a example application in ccl/examples/cocoa/currency-converter/. Personally I would also prefer to use CCL from the repository - it's usually a bit newer than the version in the Mac Application store.

Related

Fatal error: debugger does not support channel locks

I am trying to use ocamldebug with my project, to understand why a 3rd party lib I'm using is not behaving the way I expected.
https://ocaml.org/manual/debugger.html
The OCaml debugger is invoked by running the program ocamldebug with the name of the bytecode executable file as first argument
I have added (modes byte exe) to my dune file.
When I run dune build I can see the bytecode file output, alongside the exe, as _build/default/bin/cli.bc
When I pass this to ocamldebug I get the following error:
ocamldebug _build/default/bin/cli.bc
OCaml Debugger version 4.12.0
(ocd) r
Loading program... done.
Fatal error: debugger does not support channel locks
Lost connection with process 33035 (active process)
between time 170000 and time 180000
Restart from time 170000 and try to get closer of the problem ? (y or n)
If I choose y the console seems to hang indefinitely.
I found the source of the error here:
https://github.com/ocaml/ocaml/blob/f68acd1a618ac54790a8347fad466084f15a9a9e/runtime/debugger.c#L144
/* The code in this file does not bracket channel I/O operations with
Lock and Unlock, so fail if those are not no-ops. */
if (caml_channel_mutex_lock != NULL ||
caml_channel_mutex_unlock != NULL ||
caml_channel_mutex_unlock_exn != NULL)
caml_fatal_error("debugger does not support channel locks");
...but I don't know what might be triggering it.
My project is using cmdliner and lwt ...I think at this early point of execution it hasn't hit any lwt code though.
Is ocamldebug incompatible with cmdliner?
If that's the case then I will need to make a new entrypoint just for debugging I guess. (currently the bin/cli is the only executable artefact in my project, the code I need to debug is all under lib/s)
It looks like that the OCaml debugger is broken for your version of macOS. Please, report the issue to the OCaml issue tracker including the detailed information on your system. I can't reproduce it on my machine, but I am using a pretty old version of macOS (10.11.6) and I have the 4.12 debugger working flawlessly.
As a workaround, try using an older version of OCaml, as this channel lock test was introduced very recently you can install any version prior to 4.12,
opam switch create 4.11.0
eval $(opam env)
Then, do not forget to rebuild your project (previously installing the required dependencies),
opam install lwt cmdliner
dune build
and then you can use the debugger to your taste.

Call dll function works in IronPython, doesn't work in CPython3.4 gives "No method matches given arguments" error

For a project I need to include a DLL in Python. I'm using CPython3.4 and for including the dll I use pythonnet clr module (pythonnet-2.0.0.dev1-cp34-none-win_amd64.whl). In the dll I need a function that gives me a continuous update of a measurement. The dll is written in VB.net, the function that I need is shown below:
Public Sub AdviseStart(ByVal item As Integer, ByVal a As Action(Of Object)) Implements IConversation.AdviseStart
_parameterPoller.RegisterCallback(item, a)
End Sub
This is the code that I have written in python to call this function:
import clr
clr.AddReference('dll name')
from dll import SetupMonitor
monitor = SetupMonitor(None, None, None)
# call to the dll function
# Everytime the measurement is changed the "test" function should be executed
monitor.AdviseStart(8, test)
def test(data):
print("Value: " + str(data))
For the sake of my further project I want to use Python3.4 and not Ironpython.
I tested this code in python3.4 and 2.7 and I got this error:
No method matches given arguments
I am 100% sure that the error is from the AdviseStart function. Because when I use the same code with IronPython it works. In Ironpython this codes gives the output I expect:
Value: -74
The goal of this function is that everytime a new measurement is made the function "test" will be called. Everything for the measurement and calling is in the dll. Is there anyway I can make this function work in any CPython version?
There were some problems with integer arguments in the 64 bit builds. As far as I know that particular problem has been solved, but it would have been after that build you are using was released.
Try getting the source from github (https://github.com/renshawbay/pythonnet) and build that instead. To build and install it you just run "python setup.py install" (or any of the usual setup.py commands).
If it still doesn't work you can build a debug version by setting CONFIG="Debug" in setup.py and rebuilding. You will then be able to attach the visual studio debugger to your python process and step through the python.net code to see what signatures it's finding and why it's not matching with the arguments you're calling it with.

Installing glLoadGen 2.0.2

I need an opengl loader, extension or core. I know I am suppose to use gl code inside after gl context has been called. My problem is actually setting up this opengl development environment.
I tried glew, and failed horribly.
Next one on my list is gl load generator. It generates specific opengl core, so all i have to do is include them to use those core functions.
However, I can not get this to install and feel like giving up and moving onto gl3w soon...
This is the error I am recieving when I try to make a simple file:
C:\MinGW64\glLoadGen_2_0_2>lua LoadGen.lua -style=pointer_c -spec=gl -version=3.
3 -profile=core core_3_3
lua: ./modules/Styles.lua:37: attempt to index local 'lfs' (a boolean value)
stack traceback:
./modules/Styles.lua:37: in main chunk
[C]: in function 'require'
./modules/GetOptions.lua:28: in main chunk
[C]: in function 'require'
LoadGen.lua:17: in main chunk
[C]: ?
C:\MinGW64\glLoadGen_2_0_2>cd C:\MinGW64\glLoadGen_2_0_2
Environment:
Windows 7 64 bit, running cmd as adminstrator, luafilesystem 1.5.0-1
There's a little syntax mistake. However, if you did some researches on this you would have found this Ticket
You have to replace
local lfs = pcall(require, "lfs")
if(lfs and lfs.attributes("modules/UserStyles.lua", "mode") == "file") then
with
local status, lfs = pcall(require, "lfs")
if(status and lfs.attributes("modules/UserStyles.lua", "mode") == "file") then
This fixes the errors.
Cheers
I get the exact same error message on Ubuntu 14.04 with default lua with glLoadGen_2_0_2. The only way I have been able to use glLoadGen is to download the glLoadGen_1_9 distribution and run the exact same lua command. It generates the gl .h and .c files fine. I'm assuming something is badly broken in the glLoadGen_2_0_2 distribution to get identical errors in such very different environments.
Seems it is trying to use mingw compiler suite to do the build. You either need to install mingw, or you need to tell luarocks (or whatever command you're using for the installation) how to find it, or you need to tell that command to use MSVC (or whatever build tool chain you want to use).

How to generate two different version source code at the same time

I'm using QtCreator 2.8.0 qt 4.8.1
I have a program but two versions of it and have a variable to control.like that:
if(var==version1){/*...*/}else{/*...*/}
In the main function:
var=version1
Some of the function are shared.It's boring build everyone of them,How can I build both of them at the same time?
I've read this one .
In your Makefile have a target setup like this:
both: version1 version2
version1:
# commands to compile version 1
version2:
# commands to compile version 2
then you can just do
% make both
Technically this is called making a dependency, but it gives the effect you appear to want.

How to make OCaml bytecode that works on Windows and Linux

I want to compile some OCaml bytecode and have it run on Windows and Unix-type systems. My source code works fine if I recompile it on each platform, but the bytecode isn't portable.
Sample code:
open Unix
let on_windows = Filename.dir_sep <> "/";;
Printf.printf "On windows: %b\n" on_windows;;
let child = create_process "gpg" (Array.of_list ["gpg"; "--version"]) stdin stdout stderr;;
Printf.printf "Child %d\n" child;;
Build command:
ocamlbuild -use-ocamlfind -pkg unix test.byte
If I compile on Windows and run on Linux, I get
Fatal error: unknown C primitive `win_waitpid'
If I compile on Linux and run on Windows I get:
Fatal error: unknown C primitive `unix_waitpid'
How can I make the bytecode work everywhere?
Obviously, the reason is that ocaml unix library has different names for C stubs depending on the platform, and this hinders bytecode portability. I do not see the way out except for patching stub names..
Merely renaming the C symbols doesn't work because there are two completely different versions of the unix.ml module (though with the same interface). If you link your code statically, you'll get the one for the build platform and it won't work on the other platform.
The solution is to create and distribute a .cma archive (with the Unix module not linked in) rather than an executable. Then use ocaml to link dynamically on the target platform:
http://roscidus.com/blog/blog/2013/07/07/ocaml-binary-compatibility/#windows--linux-compatibility
Update: This isn't safe. When you do ocaml /path/to/script.ml, it adds the current directory (not the directory containing the script) to the start of the search path. Thus:
$ cd /tmp
$ /usr/bin/myprog
will first try to load myprog's libraries (e.g. unix.cma) from /tmp.
Should be fixed in 4.03: http://caml.inria.fr/mantis/view.php?id=6081