- graphic-forms-devel@lists.common-lisp.net

[graphic-forms-devel] Undefined alien: "func_ptr"
by David Lichteblau 30 Mar '07

30 Mar '07

Hi, I get this error when trying to build graphic-forms-uitoolkit with SBCL 1.0.2 on Windows XP. d. Undefined alien: "func_ptr" [Condition of type UNDEFINED-ALIEN-ERROR] Restarts: 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A8AF309}> on #<ASDF:CL-SOURCE-FILE "metrics" {B31B561}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A8AF309}> on #<ASDF:CL-SOURCE-FILE "metrics" {B31B561}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-SYS:ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS "func_ptr" #<unused argument>) 1: (SB-IMPL::LINK-FOREIGN-SYMBOL "func_ptr" NIL) 2: (SB-IMPL::ENSURE-FOREIGN-SYMBOL-LINKAGE "func_ptr" NIL) 3: (SB-SYS:FOREIGN-SYMBOL-ADDRESS "func_ptr" NIL) 4: (SB-FASL::FOP-FOREIGN-FIXUP) 5: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" {BC57C79}>) 6: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" {BC57C79}> NIL #<unavailable argument>) 7: (SB-FASL::INTERNAL-LOAD #P"C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" #P"C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" :ERROR NIL NIL :BINARY NIL) 8: (SB-FASL::INTERNAL-LOAD #P"C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" #P"C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl" :ERROR NIL NIL NIL :DEFAULT) 9: (LOAD #P"C:\\cygwin\\home\\david\\clbuild\\source\\graphic-forms\\src\\uitoolkit\\system\\metrics.fasl") 10: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {A8AF309}> #<ASDF:CL-SOURCE-FILE "metrics" {B31B561}>) 11: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {A8AF309}> #<ASDF:CL-SOURCE-FILE "metrics" {B31B561}>) 12: ((LAMBDA ())) 13: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {AC447C5}>) 14: (NIL ASDF:LOAD-OP :GRAPHIC-FORMS-UITOOLKIT) 15: (ASDF::MODULE-PROVIDE-ASDF :GRAPHIC-FORMS-UITOOLKIT) 16: ((LAMBDA (#:G21)) ASDF::MODULE-PROVIDE-ASDF) 17: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 #<CLOSURE (LAMBDA #) {B3FDFE5}> (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 18: (REQUIRE :GRAPHIC-FORMS-UITOOLKIT NIL) 19: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE :GRAPHIC-FORMS-UITOOLKIT) #<NULL-LEXENV>) --more--

2 7

Available widgets (was: Re: [graphic-forms-devel] Dialogs return values)
by Edgar Gonçalves 25 Mar '07

25 Mar '07

On 3/25/07, Jack Unrue <jdunrue(a)gmail.com> wrote: > On 3/25/07, Edgar Gonçalves <edgar.goncalves(a)gmail.com> wrote: > > > > Hi! I've just started playing with graphic-forms, and I wanted to > > build some macros to generate message-boxes (which I did based on your > > demo about-dialog), and some input-prompts, like Yes/No questions, or > > a simple OK/Cancel. But I'm not figuring how I can set a return value > > for such functions (they seem to return the value 4 once (gfw:show dlg > > t) is called). Right now I managed a dirty hack by placing a global > > variable and making the dialog change it. but this is not as > > functional as I would want... Any suggestions? > > > > Hi Edgar. Your macros could be written to establish a lexical binding > and then use a closure as a callback for each widget in the dialolg. > Or you could define a new dispatcher class and specify that for each > widget, with one or more slots carrying important return info. You > might consider constructing your macros such that the user of the > macro provides one or more symbols to identify bindings whose values > are to carry whatever result info your dialogs will provide, which can > then be accessed within the body of the macro. The WITH-* macros > for the color, file, and font dialogs work this way. > > The exact return value of GFW:SHOW is whatever the underlying > window system returns -- I might change the function to return (values) > just to emphasize that it's not a value that the application can use. > But you could obviously implement a wrapper around GFW:SHOW if > you wanted a function-based API. > That's what I was getting at. I'll make some wrappers to do it. On another subject, the list of controls you make available in graphic-forms is still limited. Is that because you haven't needed more, yet, or are there technical impediments? I would like to use most of the controls in MFC - http://msdn2.microsoft.com/en-us/library/47xcww9x(VS.80).aspx -, do you have some quick recipe ready for this? It'd be great to share user's widgets! Thanks again for the help! -- Edgar Gonçalves Instituto Superior Técnico, INESC-ID - Software Engineering Group, Portugal

2 1

[graphic-forms-devel] Dialogs return values
by Edgar Gonçalves 25 Mar '07

25 Mar '07

Hi! I've just started playing with graphic-forms, and I wanted to build some macros to generate message-boxes (which I did based on your demo about-dialog), and some input-prompts, like Yes/No questions, or a simple OK/Cancel. But I'm not figuring how I can set a return value for such functions (they seem to return the value 4 once (gfw:show dlg t) is called). Right now I managed a dirty hack by placing a global variable and making the dialog change it. but this is not as functional as I would want... Any suggestions? Thanks, -- Edgar Gonçalves Instituto Superior Técnico, INESC-ID - Software Engineering Group, Portugal

2 1

[graphic-forms-devel] SLIME and SBCL issues
by Jack Unrue 05 Nov '06

05 Nov '06

I've been investigating a problem where starting a Graphic-Forms app from within SLIME using the SBCL backend results in seemingly nothing but a hang. What appears to be happening is that the message loop in GF is not even getting past the first call to the Windows get-message function. I fired up Winspector Spy, which is a utility for inspecting the window hierarchy, and saw that application windows are getting created. But since no messages are getting processed (except for maybe the very initial WM_NCCREATE or WM_NCCSIZE), the windows don't appear and obviously are non-functional. This problem has something to do with the combination of SLIME and SBCL, since CLISP and SLIME work together ok as fas as GF is concerned. Also, running SBCL from a command prompt works, albeit that's not nearly as nice an environment. So there are a couple workarounds right now (both assuming that you want to use SLIME, rather than the LispWorks IDE). The first is to switch to CLISP at least for the time being, as this is a configuration that works fine. The second is to run SBCL from a command prompt. It's important to keep in mind that SBCL/Win32 is currently still a single-threaded Lisp like CLISP is, so in both cases, the SLIME REPL would be queueing requests until the message loop exits. When we see multi-threading support appear in those Lisps, then hopefully we can get back our REPL while our GF apps are running. I've sent a query to the slime-devel list in the hopes of getting some pointers to possible solutions, and I will continue to investigate this problem myself as time allows. -- Jack Unrue

1 0

[graphic-forms-devel] updated fixes for loading the system
by Jack Unrue 05 Nov '06

05 Nov '06

Please find attached an updated set of fixes for loading the library and the test programs. I've fixed some confusion in the initialization of the gfsys::*gf-tests-dir* variable. I've verified (again) that the procedure documented in the top-level readme works. Also, the file extensions may be getting munged for these attachments. The files are: graphic-forms-tests.asd config.lisp tests.lisp all of which go in the top of the installation directory. -- Jack Unrue

1 0

[graphic-forms-devel] fixes for the config and loading process
by Jack Unrue 01 Nov '06

01 Nov '06

Mea culpa. I have not been adequately testing the configuration and loading process documented in the top-level README, and have found to my chagrin that it was badly broken. I will stop using my private build.lisp to help make sure this doesn't happen in the future. Please find attached replacements for files in the Graphic-Forms source distribution. The procedure documented in the README is still valid. My apologies to anyone that has tried to experiment with GF and been stymied by these mistakes. Thanks to Mark Haniford for his problem reports. -- Jack Unrue

1 0

[graphic-forms-devel] SLIME vs. message loops
by Jack Unrue 09 Sep '06

09 Sep '06

I need to do some research into the interaction between SLIME and Windows GUI message loops. Michael Jung was able to get a test program working if he ran SBCL from a command prompt instead of SLIME -- and a command prompt window is the mode I run the various CLs in as well, so I had not yet seen this problem with SLIME. I will post an update once I have investigated this further. -- Jack Unrue

1 1

[graphic-forms-devel] API change: select-span, selection-span --> selected-span
by Jack Unrue 06 Sep '06

06 Sep '06

I've got another little API cleanup issue to report. The existing generic functions SELECT-SPAN and SELECTION-SPAN in the GFW package are going to be collapsed to SELECTED-SPAN which will have a corresponding SETF function defined as well. This affects existing code that uses edit controls. -- Jack Unrue

1 0

Re: [graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

At 19:15 04.09.2006, you wrote: >If it were me at this point, I would start sprinkling debug statements >around to try to find out more info. I would do this with Alastair's >hello.lisp since it is such a small amount of code to work with. >Check that REGISTERCLASSEX is not returning zero, and that >CREATEWINDOW is returning a non-null foreign pointer. Check >that his WINDOW-PROCEDURE function is getting called, >and print out the argument values, so that you can see what >events get processed. > >If those debug statements indicate everything is succeeding, >but you still don't see any window, then I would suggest installing >a Spy utility (I use Winspector Spy) so that you can check whether >the window is getting created but not being made visible. Alastair's >window classname is "hello". Winspector Spy says that window class is registered and window is created. At the moment it looks as if it get stuck in the message loop Michael Jung

2 1

Re: [graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

At 19:23 04.09.2006, you wrote: >Another thing to try is to restart SBCL without the callback >patch, and remove the :stdcall attribute from Alastair's >code. Win32 has a special hack that allows non stdcall >callbacks to be used as window procedures. This would >help rule out whether that patch is causing the problem. Jack, I tried this (hopefully the right way) too but it changed nothing Michael Jung

1 0