Where is Lisp code box in OM6's menu?

[fredvoisin]

Hello,

I’m sorry to don’t find the “Lisp code” box which evaluate included lisp as soon as the parent patch is loaded (shouldn’t be in Class > kernel > lisp" menu ?).
As I remember, it exists in some previous versions of OM.
It differs from the “lispfunction” box since it does not have to include a lambda expression, the embeded code is evaluated at load (i.e before the patch’s eval process) and it can define named functions.
By the way, I don’t find the “lispfunction” box in the menu either (I got it by typing “lisp” into the patch).

Bonne journée !
Fred

.

[didierdebril]

Hello Fred, is this the Lisp code editor window? If so, it is in the windows menu => Lisp Editor. For Lispfunction, to call it, you have to insert it by typing “Lisp” as you did.

[fredvoisin]

Hello Didier,

thank’s for helping.
I’m sorry, it’s not the Lisp code editor included with LW environment, nor the lispfunction box called by typing 'lisp". I remember a “Code box” where you can edit Lisp code as in a code editor window, but instead of creating a separate file (lisp file) the code is embeded into a patch, in a OM box. I try to call it by typing “codebox”, “lispbox” or so but unsuccessfully.
Or may be I’m confusing with Patchwork or PWGL ?
If yes, why not make it possible into OM ? Be able to write some embeded and short lisp code - but too long to be a lambda - may be very usefull !

[didierdebril]

Hello Fred, maybe it’s in PWGL. For Patchwork, I would have to look in the manual that I still have. If not, yes, it might be helpful. For my part, I have a problem with the Lisp editor with the Mac. When I copy-paste an example from the manual to create a function with “defmethod!”, While it works fine with both my PCs, I always get an error message on the Mac and if the function is evaluated when I call it in a patch by typing its variable name, the Listener tells me that this function does not exist. I am confused…

[haddad]

Dear Didier,

Can you give a MWE example of the copy/paste issue?
Best
K

[haddad]

Dear Fred,

I think you are mixing up everything here. There was no lispbox codebox in OM. You have as stated by Didier (thanx to Jean) the Lispfunction that you may call from the file menu. It is as expected: You type your lisp code inside the lambda statement, and you get what your function/method as a box:

Best

[fredvoisin]

Dear Karim and Didier,

in effect, I just checked on a good old mac that the ‘lisp-code-box’ exists in PWGL. It was probably there in Patchwork, I remember I used it quite soon and often.
The ‘lispfunction’ box in OM has exactly same functionnalities than the ‘code-box’ (whith no lisp-) in PWGL: you can write (only) lambda expressions and inputs connectors are graphically updated according to its arguments list.

But these two kind of way to write lisp code are not equivalent.
In the first way (Patchwork way), one can define lisp functions, methods, etc, not only anonymous functions (lambda).
In the second way, a lambda has to be defined, and all lisp functions defined using, for instance a ‘defun’ statement seems to be not recognized into the patch.
I really like (need) the first way… it is very convenient.

Bests.

[fredvoisin]

Hi Didier,
This sounds strange, I use to write lisp in the LW Lisp editor attached to OM in both OSX and Linux.
But I never use defmedthod! directly… At that point - for testing and developping, I use standard lisp defun/defmethod statements.
May be you just need to declare such a specific OM method in the main lisp file in a OM Lisp library, as if it’s part of the Lib’s menu ?

[didierdebril]

Thank you Karim, I am preparing a PDF with the screenshots of the Mac and the PC with which it works.
Best.
Didier

[didierdebril]

Hello Fred, I have the same problem on the Mac with defun too. I finish a little job and make a PDF with screenshots from the Mac and PC.

[fredvoisin]

Lispfunction seems to not provide the functionality I’m looking for, see my previous screenshot. Here is a screenshot in PWGL the lisp-code-box I’m looking for, different than lispfunction (code-box).
The lisp-code-box is represented in the patch with the “(Lisp)” icone, in grey at the top of the patch. When double-cliking on it, it opens the “Text-Editor” window, the one in the middle on the right side of the screenshot, and the embeded code is loaded when opening the patch.

I know I’m touching a taboo in mixing up everything here, bit as you know anthroplogists really like taboos

Bests.

[haddad]

Dear Fred, dear Didier,

For the time being you can always open an editor from the listener (ctrl+n) and type in your code:

1. One thing is mandatory in order to use this code in a OM patch:
   (in-package :om)

2. Just type ctrl+y to evaluate all your code and call your functions and methods.

3. you can even put your .lisp file in your init folder at startup.

I thought you knew this already (??)

Best
K

[haddad]

addendum, (for fred): if you want to see the code connected to your custom code, just select the box and type e.

Best
K

[fredvoisin]

Dear Karim,

yes, we know it of course.
The point is to make the lisp code embeded into any patch so that there is no risk for files dependancies which can be outdated or lost…
It can be very usefull for (captain) ad-hoc projects which do not need to develop a dedicated library… In such a case a patch can be self-sufficient.

[bresson]

Hello Fred and al.,
A few complementary options in OM are:

• Put your lisp file(s) in your workspace’s “user” folder so everything it contains gets loaded with the workspace.

• Use a TEXTFILE box and evaluate all its contents it using the eval-textfile function.

This second one seems the closest option to what you are looking for (embedding the code within the patch file itself), although you still need to evaluate it manually.

Jean

[bresson]

Also (as a side note:), one thing to be aware of with this “evaluate code within a patch” idea (either with TextFile or with in PWGL’s lisp-code-box I guess?) , is that the patch that contains this generates side effects: it potentially defines (or redefines) functions, and is therefore likely to change how some other (visual) programs behave, depending on whether they are executed before or after this patch. This is something we try to avoid in general.

[bresson]

ps. you can also define functions inside the lambda
(but you also need to evaluate it yourself)

[fredvoisin]

Dear Jean,

Using defun declarations inside a lambda (in a lispfunction box) or using a textfile box do not work when loading OM and then the patch: the function defined in that ways become ‘dead’. And after reloading and evaluating the definitions, the boxes remain dead and need to be changed.
May be this last behavior could be adapted: the boxes could appear as dead before evaluating the definitions and be alive again after evaluating the lambda or textfile containng the definitions ? These should be quite intuitive…

Anyway, puting the lisp code in the workspace’s ‘user" folder works
And, at the end, it seems more intuitive than embeding lisp defintions into a patch, it’s a middle way before developping a dedicated library (shouldn’ this way have the same side effects of 'evaluating code within a patch ?).
The only point I would suggest in that way, is to not use the same ‘lisp’ simple icon as the standard lisp icons but to use a specific icon which may explicitly tell the user that the function she is using is specific to its own workspace - or why not using same lisp icone but with a different color ?

All the best.
Fred

[bresson]

@fredvoisin

Using defun declarations inside a lambda (in a lispfunction box) or using a textfile box do not work when loading OM and then the patch: the function defined in that ways become ‘dead’.

Yes, as I said, the code is not loaded automatically and you need to do it “manually” after the patch is loaded.

@fredvoisin

And after reloading and evaluating the definitions, the boxes remain dead and need to be changed.

You can also just reload the patch (right-click or “File” menu + “Last saved”).

[bresson]

@fredvoisin

Anyway, puting the lisp code in the workspace’s ‘user" folder works
And, at the end, it seems more intuitive than embeding lisp defintions into a patch, it’s a middle way before developping a dedicated library (shouldn’ this way have the same side effects of 'evaluating code within a patch ?).

Not really, because in this case the code is loaded at the beginning, when starting the session, and shared by all patches right away (not depending on whether you have open some given patches in a given order before to use another patch).