I'm using an Intel Mac with Mac OS 10.5 and SBCL 1.0.29. I've done pre-1.0 Hunchentoot development here before, so I've had that installed (via asdf-install).
Recently I started a new project, and decided I'd start from Hunchentoot 1.0. I asdf-install'ed Hunchentoot, and it seemed to install 1.0 (and deps) just fine. I can load it in SBCL (via SLIME or Terminal), and I can write code against the new interface, and it compiles great, and everything seems fine.
That is, until I try to access the webpage: I only get empty responses. Firebug reports "200 OK" but Page Info shows size "0 bytes" (text/plain, ISO-8859-1, but I'm guessing those are defaults). So I tried netcat and telnet, and it seems to accept a connection on my port and then immediately disconnect.
Is there a problem with Hunchentoot 1.0 on Mac OS? Or with having 2 Hunchentoot versions asdf-install'ed at the same time? Or something else I'm not thinking of? I'm sure it's probably something obvious but I'm drawing a blank here.
Thanks!
I recently wrote a tutorial on how to write a Lisp webapp that includes a known working set of dependencies (including Hunchentoot, CFFI, etc).
You might want to check out the documentation. Try running the code from the linked github page and see if it works for you - if it doesn't then the problem is in your Lisp Compiler (not your libraries). I'd link directly to github, but I'm new here, and apparently I don't have enough reputation points to post two links in one answer.
Off the top of my heads, I know SBCL has trouble with threads on Mac OS X. I'd consider looking into Clozure Common Lisp - which is very optimized for Macs.
Related
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
Is there a version of the CUPS server available for Windows? Looking at the CUPS source code it seems it is ready for Visual Studio compilation, but I did not find any trace of an actual supported package. I'd like to set up a CUPS server on Windows so that I can print form Linux/MacOSX/Win clients to printers I set up on this server.
I've got a new answer for you:
Since some time there is a project called ippsample on GitHub. It's slowly approaching a mature version 1.0 release.
Here are the first two sentences of given as self-description in the mandatory README file:
"This code provides sample implementations of IPP Clients, Printers, and Proxies. It is largely based upon the CUPS software, with substantial changes to the ippproxy and ippserver implementations to make them more general-purpose and configurable." (my emphasis)
This project is hosted by the ISTO Printer Working Group (PWG), the same industry organization which develops and promotes the IPP as a general standard.
The ippserver, ipptool, ippfind, ippproxy and ipptransform components of the IPP Sample project together make up for a standard-conforming IPP Everywhere implementation, covering the client as well as the server side of printing.
The GitHub code for IPP Sample project is maintained by the very same Mike Sweet who also develops CUPS -- so it's the real thing.
Yes, it compiles and works nicely on Windows, and there are a bunch of .vclxproj and .sln files available to make the build process with MS Visual Studio as smooth as possible.
Yes, the IPP Sample code is working and can print to a CUPS server (or receive print jobs from there) running on macOS or any blend of Linux.
No, this is not yet a fully-blown CUPS server for Windows which can serve as a drop-in replacement for a Windows print server. It does not have with ALL the features which would be required.
But if you want to create such a beast:
this is the place were you would have to poke around first;
this is were you possibly could fork the code and start adding functionality to get where you want to go.
Oh, and did you know that Apple recently changed the license conditions for CUPS and made it more permissive, moving away from GPL2 to Apache 2.0 licensing?
You have never heard of "IPP Everywhere" before? It is the future of "driverless" printing.
Never heard of "driverless printing"? A slightly modified (and stripped down) version of it already implemented as "Apple AirPrint" for iPhone and iPad devices.
The current implementation of the CUPS-based printing stack includes new pieces of code in the cups-drivers project which recently moved to GitHub. This new code implements IPP Everywhere functionality.
This cups-filters project is under the stewardship by The Linux Foundation's OpenPrinting department ever since Apple handed over these parts of the original CUPS source code to them when they became no longer useful for macOS but were still important to Linux.
What are the basic ideas of driverless printing then?
Have the devices automatically announce their presence and their type of service in the local network. Use the IETF standard protocols mDNS and DNS-SD (which are implemented in macOS under the name of "Bonjour" and in Linux as "Avahi") to take note of the offered services.
Tell the print clients that they can use the IPP protocol in order to get a query response when they make a get-printer-attributes request. This request will tell them which set of print options the devices support. The print clients can then show an exactly tailored print dialog to show to the printing user a selection of choices. The print client will also be told what job submission formats each devices supports. This MUST be either PDF or a simple raster format called "PWG-Raster".
So... where would you need a specific "printer driver" in such an environment? Everything and everyone can create PDF documents nowadays. Check! No need for a device-specific conversion to any other print language.
Are there printers which support IPP Everywhere already? Oh yes, look here -- they are all said to be fully compliant with the standard:
List of IPP Everywhere printer models
The .sln and .vcproj files you've been seeing in the CUPS sources are not meant to compile all of CUPS for Windows.
They serve to compile only a few of its utilities (such as ipptool.exe)...
Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world.
CUPS uses Internet Printing Protocol for client-server communications. According to Technet article, Windows can be used as IPP host:
To enable a computer running Windows
Server 2008 to act as a server
supporting Internet printing, you must
install the Web Server (IIS) role, the
Print Services role, and the Internet
Printing role service in the Print
Services role.
Moreover, it seems that Windows, Linux and Mac OS X clients can use printers shared via SMB.
"Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world."
Back in the dial up internet days, I ran into a problem where some IPS' had a replacement dll for modem functionality. The problem with it was that the dll prevented legit programs from accessing the modem until you uninstalled the IPS program.
This same technique can be used to create a Windows CUPS server by writing a Windows spooling and printing replacement program that, rather than printing directly to the printer, hands off the printing tasks to the CUPS server.
It would of course, take someone with in depth knowledge of the windows spooling and printing protocols.
cygwin ports has patch files for implementing a cups in (some versions of) cygwin. I can't speak to how well it might work.
https://github.com/cygwinports-extras/cups
I'm trying to get Wanderlust working in Windows to connect to Gmail. Compiling the code is much more painful than expected. Here are the barriers so far:
Can't download dependent packages: SEMI, APEL, and FLIM. I eventually found newer versions, but I'm not sure they will work. Anyone have the older versions?
Needs make and install. I used MSYS and it seems to have compiled okay.
SSL support. I was getting a "Cannot open load file: ssl" error. I found an ssl.el that comes with w3. So installed w3.
Bash command in ssl.el: ssl-get-command is running something from /bin/sh (not a directory I have in Windows). I really don't want to refactor this code. Is there a better way?
Others speak very highly of Wanderlust, so I want to give it a try. I feel like I'm almost there, but am pretty much worn out with all the crazy configuration I have to do. Does anyone have this working on Windows? I'm pretty sure it will work with Gmail, because of this post. But will it work in Windows too? If you have a few pointers, please help.
ssl.el is part of wanderlust. Just look in the wanderlust/utils directory.
For STARTTLS you may either use the starttls or gnutls-cli programs.
Unfortunately, both of these programs use signals (SIGALRM to be precise) which are not supported on Windows.
You need to use the Cygwin ports of these programs -- not MSYS!
Additionally, if you're using a Windows port of Emacs (ie. not Cygwin's emacs) you need to modify starttls.el (which is part of GNU Emacs) because the signal-process function doesn't do anything regarding SIGALRM. Replace all instances of
(signal-process (process-id process) 'SIGALRM)
with
(call-process kill-program nil nil nil
"-ALRM" (format "%d" (process-id process)))
and initialize kill-program somewhere apropriately to point to cygwin's kill.exe:
(setq kill-program "c:/cygwin/bin/kill.exe")
If you want to use SSL you have to set ssl-certificate-verification-policy to a value greater than 0. Otherwise connecting to Gmail would fail.
Using the wl configuration here:
http://box.matto.nl/emacsgmail.html
After adding ssl.el from here:
http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/contrib/ssl.el
I am able to get wanderlust talking just fine to gmail on a linux configuration of wanderlust, and since the ssl.el file there isn't really system-dependent (although it does require the openssl command-line tools), I don't see that there should be any problem with it working on msys.
The 'cannot open load file: ssl' error is exactly what I ran into until I installed that ssl.el file too :)
Edit; Just in case you have trouble finding it, the MSYS port of openssl you'll want is here:
http://sourceforge.net/projects/mingw/files/MSYS%20openssl/
[posted as a new answer since I think you'll get a notification that way :)]
I recently installed wl on a linux host, and had the same issue with not being able to locate the dependencies as specified. However, I, like you, found the 'more recent versions' and used them. They did indeed work fine, so unless those new versions have added any incompatibility with windows, they shouldn't present any problem.
The error you're receiving is because it's not finding the 'install' utility, which is part of GNU coreutils. Autotools (and it's family) depend on install being able to work, so if you want to continue with the cygwin method, then installing autotools should bring in the install program.
(I have no idea if wl will compile/work using cygwin otherwise, though.)
I've got a user reporting crashes in my Mac OS X application, and their console logs report the following:
Symbolication warning: error parsing FDE at 0x100052649 in:\n
Does anyone have any insight into what this might be? I assume that somehow the symbols have been stripped from my app in a way that gets in the way of Mac OS X's crash reporter, but I've not seen it before.
I can honestly say that I have never seen this one before. I have seen a number of other dynamic linking problems just not this one. If the user is amenable to helping you with this defect, you might want to write a shell script to enable some dynamic linking environment variables and then launch your application.
#! /bin/bash
export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_APIS=1
export DYLD_PRINT_BINDINGS=1
export DYLD_PRINT_DOFS=1
open -a Console.app > /tmp/link-log 2>&1
The output log might provide some hint as to what is going on. You could also capture the output of otool and other command line utilities to check for unexpected libraries and what not.
You might want to google Symbolication to get a better handle of what is going on here. I came across an interesting chunk of code from Darwin that points this to a dynamic symbol lookup warning. There is also a utility called Shark that may be of interest as well.
Good luck...
I just found this topic via Google because I'm having the same problem. The StarCraft installer crashes immediately. It points to /usr/libexec/oah/translate, which seems to work perfectly well. My guess is this has something to do with the fact the computer it doesn't work on runs iDeneb 1.3 (aka Mac OS X 86 for use on non-Apple hardware), whereas the computer that can run the application just fine has a genuine version of Leopard.