[Ecls-list] Problems with updating an external global variable

[Dietrich Bollmann]

Hi Matt,

Thanks for your answer - and sorry for my late reply!

On Thu, Jul 18, 2013 at 2:39 AM, Matthew Mondor <mm_lists at pulsar-zone.net>
 wrote:

> On Sun, 14 Jul 2013 00:31:27 +0900
> Dietrich Bollmann <dietrich at formgames.org> wrote:
>
> > I compiled my ECL lisp functions with asdf:make-build into a library.
> >
> > Some functions depend on the value of a global variable which has to be
> set
> > in the code using the library.
> >
> > But when changing the value of the global variable in the code using the
> > library, the library functions still use the old value...
>
> I don't really understand why in your example code only the original
> value is obtained, possibly that the scope of the variable is not the
> expected one (that there are two such variables or such)?  I recommend
> to use (setf c::*delete-files* nil) and to inspect the resulting C code.
>

I seem to be unable to understand myself.

But approaching the problem by

  - using a static variable together with a lisp setter and getter and
  - compiling the lisp files to a library with ASDF:MAKE-BUILD

results in a working solution.  This one is more elegant anyway, so I will
just continue with this one.

Just for reference I'll send the sources of two failing attempts as well as
those of two working solutions to the list.  See the attachment to the next
email responding to Juanjo's answer.


> Note also that for handling foreign pointers (other than :pointer-void
> with C-INLINE which it handles implicitely), there are the public
> interfaces ecl_make_pointer() and ecl_to_pointer().
>

Thanks!

These are the functions I was looking for!


> In your next message I see that you seem to be doing it right to store
> the context in a C variable (although I didn't test your code).  If
> it's to store a unique global context on which the Lisp code should
> have no control, it might not matter, but otherwise, it might be best
> to have interface functions require the context parameter or to obtain
> it from a dynamic/special variable, which would allow Lisp code to
> handle multiple objects more elegantly than is generally possible from
> C/C++ because of the power of dynamic scope...
>

What do you mean by "dynamic/special variable"?

But anyway, I rewrote my solution as mentioned before and now use
'ecl_make_pointer()' rather than my own complicated way to wrap the pointer
(See the forth version in the code attached to the answer to Juanjo).  This
looks good enough to me and I will use this one from now on!

Thanks again for your help!

Cheers,
Dietrich


> --
> Matt



On Thu, Jul 18, 2013 at 2:39 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> On Sun, 14 Jul 2013 00:31:27 +0900
> Dietrich Bollmann <dietrich at formgames.org> wrote:
>
> > I compiled my ECL lisp functions with asdf:make-build into a library.
> >
> > Some functions depend on the value of a global variable which has to be
> set
> > in the code using the library.
> >
> > But when changing the value of the global variable in the code using the
> > library, the library functions still use the old value...
>
> I don't really understand why in your example code only the original
> value is obtained, possibly that the scope of the variable is not the
> expected one (that there are two such variables or such)?  I recommend
> to use (setf c::*delete-files* nil) and to inspect the resulting C code.
>
> Note also that for handling foreign pointers (other than :pointer-void
> with C-INLINE which it handles implicitely), there are the public
> interfaces ecl_make_pointer() and ecl_to_pointer().
>
> In your next message I see that you seem to be doing it right to store
> the context in a C variable (although I didn't test your code).  If
> it's to store a unique global context on which the Lisp code should
> have no control, it might not matter, but otherwise, it might be best
> to have interface functions require the context parameter or to obtain
> it from a dynamic/special variable, which would allow Lisp code to
> handle multiple objects more elegantly than is generally possible from
> C/C++ because of the power of dynamic scope...
> --
> Matt
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130724/b611ef67/attachment.html>