Ok I have all the libraries loaded. I also ran config.lisp and it ran fine. I then set the variables I think I set them right since I already have the libraries loaded the readme said to set them to nill so I did something like
(setq gfsys::*cffidir* "") (setq gfsys::*gfdir* "c:/graphic-forms")
Etc...
Then when I ran (gfsys::configure-asdf)
I got nill is that correct?
I assumed it was so I did the next thing which was
(asdf:operate 'asdf:load-op :graphic-forms-uitoolkit)
And got this:
(asdf:operate 'asdf:load-op :graphic-forms-uitoolkit) ; loading system definition from C:graphic-forms-uitoolkit.asd into #<PACKAGE AS DF0> ;; Loading file C:graphic-forms-uitoolkit.asd ... "Graphic-Forms UI Toolkit" "Copyright (c) 2006-2007 by Jack D. Unrue" " " ; registering #<SYSTEM GRAPHIC-FORMS-UITOOLKIT #x19F63DF5> as GRAPHIC-FORMS-UITO OLKIT WARNING: The generic function #<STANDARD-GENERIC-FUNCTION PERFORM> is being modified, but has already been called. ;; Loaded file C:graphic-forms-uitoolkit.asd *** - component "binary-data" not found, required by #<SYSTEM "graphic-forms-uitoolkit" #x19F18DF5>
Did I do something wrong?
Ken
On 8/27/07, Ken Perry kperry@blinksoft.com wrote:
;; Loaded file C:graphic-forms-uitoolkit.asd *** - component "binary-data" not found, required by #<SYSTEM "graphic-forms-uitoolkit" #x19F18DF5>
I suspect your current working directory is not the top of the graphic-forms directory when you go to load the system, which is mentioned as step 3 in the How To Configure and Build section of the readme.
If you're using SLIME, you can use the ,cd command. That is, a comma followed by the letters 'cd'. SLIME will prompt you for the destination path.
Keep in mind that config.lisp and the instructions in the readme are just a 'default' procedure for loading graphic-forms. As you get more experience, you may decide you want to re-organize where all the pieces go, in which case you'd probably just write your own local script for loading everything.
Hi Jack,
Quoting Jack Unrue (jdunrue@gmail.com):
I suspect your current working directory is not the top of the graphic-forms directory when you go to load the system, which is mentioned as step 3 in the How To Configure and Build section of the readme.
I have not followed graphic-forms changes in the last year, and when I tried building it with clbuild the last time it worked well, but in general the whole procedure described in "How To Configure and Build" is a little bit unusual.
IIRC when adding graphic forms to clbuild I just ignored all that was written there; the only trick is to set up .asd file symlinks for src/external-libraries/*/*/*.asd
While that is easy enough, I think most users will be confused by extra instructions (config.lisp, gfsys::configure-asdf) that are not strictly necessary and not familiar from other projects.
Having to special-case graphic-forms in build scripts that would otherwise expect to just symlink graphic-forms/*.asd is also slightly inconvenient. I would suggest either moving those extra .asd files into the top-level graphic-forms directory or to move those external-library directories into separate installations.
Finally, I seem to recall various configuration variables for absolute paths that could have been computed automatically using (slot-value (asdf:find-system :graphic-forms) 'asdf::relative-pathname) in the appropriate places.
Thanks, d.
On 8/29/07, David Lichteblau david@lichteblau.com wrote:
Hi Jack,
Hi David, thanks for your comments.
Quoting Jack Unrue (jdunrue@gmail.com):
I suspect your current working directory is not the top of the graphic-forms directory when you go to load the system, which is mentioned as step 3 in the How To Configure and Build section of the readme.
I have not followed graphic-forms changes in the last year, and when I tried building it with clbuild the last time it worked well, but in general the whole procedure described in "How To Configure and Build" is a little bit unusual.
Yep, I grant you that is true.
IIRC when adding graphic forms to clbuild I just ignored all that was written there; the only trick is to set up .asd file symlinks for src/external-libraries/*/*/*.asd
I haven't tested shortcut support in the 4 Lisps that I currently develop with. I should do that. But, as you point out on your clbuild webpage, in the case of SBCL a patch is needed in order to understand shortcuts. Is a newcomer to Lisp expected to be able to do that?
Ken may be in luck since he is using CLISP on Cygwin, and perhaps for him clbuild is the way to go. Note for Ken, the URL for clbuild is:
http://common-lisp.net/project/clbuild/
In general, I'm not sure how I could expect symlinks to be available to all Windows users, unless they are running a shell like bash from MSYS or Cygwin.
What you did to get clbuild working is what I had intended. Experienced developers may prefer different/better ways of loading this stuff. But I was trying (and I guess failing) to give new users an 'easier' way to get started.
You may have guessed that gfsys::configure-asdf pushes a bunch of values onto asdf:*central-registry*. Well, that's something anyone can do themselves if they are familiar with ASDF.
While that is easy enough, I think most users will be confused by extra instructions (config.lisp, gfsys::configure-asdf) that are not strictly necessary and not familiar from other projects.
Having to special-case graphic-forms in build scripts that would otherwise expect to just symlink graphic-forms/*.asd is also slightly inconvenient. I would suggest either moving those extra .asd files into the top-level graphic-forms directory or to move those external-library directories into separate installations.
That's a good idea.
Finally, I seem to recall various configuration variables for absolute paths that could have been computed automatically using (slot-value (asdf:find-system :graphic-forms) 'asdf::relative-pathname) in the appropriate places.
At least some of those locations are for libraries such as CFFI which the user may have placed anywhere.
My motivation for config.lisp, et. al., in the first place was because I figured that explaining what asdf:*central-registry* was, and explaining why symlinks may or may not work on Windows, was a bit more than I wanted to bite off in terms of instructions for new users. So I came up with this other mechanism.
I won't argue that the current system is surprisingly different from other projects, or that improvements can't be made (c.f. your idea about relocating the .asd files for the bundled libraries). I just didn't think I'd be any better off leaving Windows users to their own devices to configure ASDF by hand, from a support standpoint.
Quoting Jack Unrue (jdunrue@gmail.com):
In general, I'm not sure how I could expect symlinks to be available to all Windows users, unless they are running a shell like bash from MSYS or Cygwin.
Okay, the whole ASDF-on-Windows situation is not ideal, so your configuration file to get people started is probably a good idea.
I was hoping that the shortcut patch for ASDF makes things a little easier (because ordinary windows shortcuts created manually can be used), but that does not help much as long as it's not committed.
clbuild is something I find valuable to avoid having to install everything manually, but I don't test it regularly on Windows, so it might be more trouble than it's worth for others.
graphic-forms-devel@common-lisp.net