From david at lichteblau.com  Sun Mar 11 12:39:21 2007
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 11 Mar 2007 13:39:21 +0100
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
Message-ID: <20070311123921.GB17381@ununoctium>

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--


From jdunrue at gmail.com  Sun Mar 11 15:03:07 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 11 Mar 2007 09:03:07 -0600
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <20070311123921.GB17381@ununoctium>
References: <20070311123921.GB17381@ununoctium>
Message-ID: <d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>

On 3/11/07, David Lichteblau <david at lichteblau.com> wrote:
> Hi,
>
> I get this error when trying to build graphic-forms-uitoolkit with SBCL
> 1.0.2 on Windows XP.

Hi David. The latest checked-in version of src/uitoolkit/system/metrics.lisp
should be OK and I just did a quick recompile to verify. Checking past
revisions, I believe the mistake was in rev 417 and I fixed it in 419.

Can you double-check that your working copy is up-to-date?

-- 
Jack


From david at lichteblau.com  Sun Mar 11 16:03:01 2007
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 11 Mar 2007 17:03:01 +0100
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
Message-ID: <20070311160301.GA19046@ununoctium>

Hi,

Quoting Jack Unrue (jdunrue at gmail.com):
> Hi David. The latest checked-in version of src/uitoolkit/system/metrics.lisp
> should be OK and I just did a quick recompile to verify. Checking past
> revisions, I believe the mistake was in rev 417 and I fixed it in 419.

revision 430 is what I've got, checked out today.

Could this be a cffi or alien compatibility issue?
I'm using cffi from darcs.


Thanks,
d.


From jdunrue at gmail.com  Sun Mar 11 17:50:49 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 11 Mar 2007 11:50:49 -0600
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <20070311160301.GA19046@ununoctium>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
	<20070311160301.GA19046@ununoctium>
Message-ID: <d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>

On 3/11/07, David Lichteblau <david at lichteblau.com> wrote:
> Hi,
>
> Quoting Jack Unrue (jdunrue at gmail.com):
> > Hi David. The latest checked-in version of src/uitoolkit/system/metrics.lisp
> > should be OK and I just did a quick recompile to verify. Checking past
> > revisions, I believe the mistake was in rev 417 and I fixed it in 419.
>
> revision 430 is what I've got, checked out today.
>
> Could this be a cffi or alien compatibility issue?
> I'm using cffi from darcs.

I was still using cffi-061208 and haven't been keeping up-to-date with
developments in cffi land. I grabbed the latest from darcs and ran
into the same compile error that you did.

I've checked in a fix, please update and give it another try. The compile
error is resolved and I'm able to call GFS::OBTAIN-DLL-VERSION-INFO
successfully:

   * (gfs::obtain-dll-version-info "comctl32.dll")

   (5 82 2900)

 so I *think* this is the right fix at least on SBCL.

It also seems like I've got some obsolete code that needs updating,
seeing as how stdcall callback support has been added to cffi.

-- 
Jack


From david at lichteblau.com  Wed Mar 14 17:51:00 2007
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 14 Mar 2007 18:51:00 +0100
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
	<20070311160301.GA19046@ununoctium>
	<d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>
Message-ID: <20070314175100.GA32603@ununoctium>

Quoting Jack Unrue (jdunrue at gmail.com):
> I was still using cffi-061208 and haven't been keeping up-to-date with
> developments in cffi land. I grabbed the latest from darcs and ran
> into the same compile error that you did.
> 
> I've checked in a fix, please update and give it another try. The compile
> error is resolved and I'm able to call GFS::OBTAIN-DLL-VERSION-INFO
> successfully:

Thank you, that works great now!


However, I also tried it with Lu?s' new-types branch, and that fails
with a different error now, something about rectangles not being SAPs.

http://article.gmane.org/gmane.lisp.cffi.devel/1034

Of course, since the new-types branch is apparently still experimental,
that might not be an issue in graphic-forms at all.


Thanks,
David


From jdunrue at gmail.com  Thu Mar 15 02:29:47 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Wed, 14 Mar 2007 20:29:47 -0600
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <20070314175100.GA32603@ununoctium>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
	<20070311160301.GA19046@ununoctium>
	<d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>
	<20070314175100.GA32603@ununoctium>
Message-ID: <d3df77800703141929y44dc2070x6c90cd8a6ddee46c@mail.gmail.com>

You wrote:
>
> However, I also tried it with Lu?s' new-types branch, and that fails
> with a different error now, something about rectangles not being SAPs.
>
> http://article.gmane.org/gmane.lisp.cffi.devel/1034
>
> Of course, since the new-types branch is apparently still experimental,
> that might not be an issue in graphic-forms at all.

Thanks for reporting this, too. I haven't yet figured out what to do about
it but I'm still investigating.

I guess it's time to resubscribe to a couple mailing lists :-)

-- 
Jack


From jdunrue at gmail.com  Fri Mar 16 03:20:46 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Thu, 15 Mar 2007 21:20:46 -0600
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <d3df77800703141929y44dc2070x6c90cd8a6ddee46c@mail.gmail.com>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
	<20070311160301.GA19046@ununoctium>
	<d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>
	<20070314175100.GA32603@ununoctium>
	<d3df77800703141929y44dc2070x6c90cd8a6ddee46c@mail.gmail.com>
Message-ID: <d3df77800703152020n1a367254v676a70c82221081@mail.gmail.com>

> David Lichteblau wrote:
> >
> > However, I also tried it with Lu?s' new-types branch, and that fails
> > with a different error now, something about rectangles not being SAPs.
> >
> > http://article.gmane.org/gmane.lisp.cffi.devel/1034
> >
> > Of course, since the new-types branch is apparently still experimental,
> > that might not be an issue in graphic-forms at all.

OK, here's an update. I've made changes that allow GF to
compile on SBCL with cffi-newtypes. But there are some issues:

- the newtypes branch has deviated from the main cffi branch in a couple
  of incompatible ways. The mechanism for defining type translators is
  different (this was the cause of the SBCL compile errors), and there is an
  incompatible change to CFFI:FOREIGN-STRING-TO-LISP.

- there are other problems on LispWorks 5.0 and CLISP that need to be
  worked out yet. I'm pursuing the CLISP issue now and will hopefully figure
  out a patch or something for LW.

So I've created a branch called graphic-forms-newtypes where we can
work with cffi-newtypes for the time being:

svn://common-lisp.net/project/graphic-forms/svn/branches/graphic-forms-newtypes

Some quick testing shows that there are repainting problems that need to be
tackled. So this branch should be considered even more experimental than
the main trunk.

-- 
Jack Unrue


From edgar.goncalves at gmail.com  Sun Mar 25 11:21:06 2007
From: edgar.goncalves at gmail.com (=?ISO-8859-1?Q?Edgar_Gon=E7alves?=)
Date: Sun, 25 Mar 2007 12:21:06 +0100
Subject: [graphic-forms-devel] Dialogs return values
Message-ID: <6fd384780703250421u39ee90f6v86f3deac918d58e5@mail.gmail.com>

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


From jdunrue at gmail.com  Sun Mar 25 14:41:10 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 25 Mar 2007 08:41:10 -0600
Subject: [graphic-forms-devel] Dialogs return values
In-Reply-To: <6fd384780703250421u39ee90f6v86f3deac918d58e5@mail.gmail.com>
References: <6fd384780703250421u39ee90f6v86f3deac918d58e5@mail.gmail.com>
Message-ID: <d3df77800703250741l7f16a74fsab30ca6921f1016@mail.gmail.com>

On 3/25/07, Edgar Gon?alves <edgar.goncalves at 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.

-- 
Jack Unrue


From edgar.goncalves at gmail.com  Sun Mar 25 19:22:54 2007
From: edgar.goncalves at gmail.com (=?ISO-8859-1?Q?Edgar_Gon=E7alves?=)
Date: Sun, 25 Mar 2007 20:22:54 +0100
Subject: Available widgets (was: Re: [graphic-forms-devel] Dialogs return
	values)
Message-ID: <6fd384780703251222td55b47by3d9344f6efb344ee@mail.gmail.com>

On 3/25/07, Jack Unrue <jdunrue at gmail.com> wrote:
> On 3/25/07, Edgar Gon?alves <edgar.goncalves at 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


From jdunrue at gmail.com  Sun Mar 25 19:55:04 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 25 Mar 2007 13:55:04 -0600
Subject: Available widgets (was: Re: [graphic-forms-devel] Dialogs return
	values)
In-Reply-To: <6fd384780703251222td55b47by3d9344f6efb344ee@mail.gmail.com>
References: <6fd384780703251222td55b47by3d9344f6efb344ee@mail.gmail.com>
Message-ID: <d3df77800703251255o51c2205fp3d417983f7d01aa6@mail.gmail.com>

On 3/25/07, Edgar Gon?alves <edgar.goncalves at gmail.com> wrote:
>
> 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!

It's mainly a question of time and effort; there are quite a few areas
in the library that need more work, with controls being just one of
those areas :-) I'd be happy to review and integrate contributions,
but also, I'm open to suggestions as to what you'd like to see done
next -- if you wanted to comment on some of the existing bug tracker
items or add to the wishlist tracker (at the SourceForge project page),
that would be great.

-- 
Jack Unrue


From jdunrue at gmail.com  Fri Mar 30 03:35:26 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Thu, 29 Mar 2007 21:35:26 -0600
Subject: [graphic-forms-devel] Undefined alien: "func_ptr"
In-Reply-To: <d3df77800703152020n1a367254v676a70c82221081@mail.gmail.com>
References: <20070311123921.GB17381@ununoctium>
	<d3df77800703110803r3a53e2b8kdb38a93015430005@mail.gmail.com>
	<20070311160301.GA19046@ununoctium>
	<d3df77800703111050r5f7e394boe02ed4a0efc8d067@mail.gmail.com>
	<20070314175100.GA32603@ununoctium>
	<d3df77800703141929y44dc2070x6c90cd8a6ddee46c@mail.gmail.com>
	<d3df77800703152020n1a367254v676a70c82221081@mail.gmail.com>
Message-ID: <d3df77800703292035k75993eadi426d18a6685ed8b0@mail.gmail.com>

On 3/15/07, I wrote:
>
> So I've created a branch called graphic-forms-newtypes where we can
> work with cffi-newtypes for the time being:
>
> svn://common-lisp.net/project/graphic-forms/svn/branches/graphic-forms-newtypes
>
> Some quick testing shows that there are repainting problems that need to be
> tackled. So this branch should be considered even more experimental than
> the main trunk.

At this point, most of the obvious issues running with the cffi-newtypes
branch have been fixed. I've also dealt with some problems revealed by
running with LW 5.0.1.

Bug reports and other feedback are welcome as always.

-- 
Jack Unrue