Convert library to SCOOP

31 views
Skip to first unread message

Jimmy Johnson

unread,
May 30, 2026, 3:38:08 PM (5 days ago) May 30
to Eiffel Users
I would like opinions and advice about moving a library to SCOOP.

1)  Is moving to SCOOP worth the effort?
2)  How do the changes affect non SCOOP systems?

I have a windowing library build on Vision2 that allows me to easily build a GUI.  An application can have multiple MAIN_WINDOWs and each window can contain one or more TOOLs and each tool can contain one or more VIEWs, giving an interface similar to VisualStudio.  When an object changes, all views containing that object can be redrawn.  I guess this is like the old Model-View-Controller idea, but VIEW is the View and Controller, and the model is the target.

The top abstraction is a VIEW.  A view displays [or controls] a single `target' initialized on creation or with feature `set_target (a_object: ANY)'.  To use class view, a descendant must inherit from VIEW and ALSO some EV_xxx class to effect a couple of features and redefine `target_imp' which anchors the target's type.  Feature `draw' which defines how to display the target must also be redefined.  If an event occurs in a view, triggering a change to the target, the view can tell all views that target that object to draw themselves using `draw_views (a_object: ANY)'.  This synchronous method has worked well for me up till now, but I just came across a use for asynchronous processing, requiring SCOOP.

This new use case must run a [long-running] process on an RPI while simultaneously displaying information about the changing states of the registers in the RPI, say in the EV_APPLICATION `on_idle actions'.  This requires the RPI to be in a different region than the GUI.  Something like:

     rpi_view: RPI_VIEW    -- redefine `target_imp' and `draw' minimum
     rpi: separate RPI
         ...
     rpi_view.set_target (rpi)

So now `target_imp', `set_target', and all features taking a "like `target_imp' argument" must be redone to take a separate argument.  All redefinitions in descendants will also have to be changed to handle a separate argument.  Also, calls in feature `draw' can no longer use the `target' directly but must accommodate the separate `target', perhaps with an inline separate block:
     draw
          do
               separate target as t do
                    print (t.name)    -- was "print (target.name)"
                    print (t.rank)      -- was "print (target.rank)"
               end
          end

Problems:  
1)  changes propagate throughout my library and descendants
2)  library users must use separate blocks (or do they if not using SCOOP?)

Questions:
1)  Do you think the benefits of SCOOP are worth the effort?
2)  How does it affect non-SCOOP systems?
3)  Must non-SCOOP systems use the separate blocks?

I look forward to feedback.  Thanks,
jjj


Eric Bezault

unread,
May 30, 2026, 5:38:13 PM (5 days ago) May 30
to eiffel...@googlegroups.com, Jimmy Johnson
Hi Jimmy,

To the question whether non-SCOOP systems should use `separate` blocks,
the answer is no. In non-SCOOP systems, the keyword `separate` is just
ignored. So creating an object of type `separate T` is like creating
an object of type `T`. In non-SCOOP system, it's as if we have only
one region, and all objects are created in this region, regardless of
the `separate` keyword.

To the question whether it will affect non-SCOOP systems, the answer
is probably. If the system is designed to work with different SCOOP
regions concurrently, some code may never be executed. For example
when creating an object declared of a separate type, in SCOOP mode
this object will live its own life in its separate processor, while
the instructions following this creation will be executed. In non-
SCOOP mode, the instructions following this creation will be executed
only after creation procedure returns, which may never happen (for
example if this object is listening to a socket). But you can tailor
your code to work in both modes using `{PLATFORM}.is_scoop_capable`.
You can find an example here:

https://github.com/gobo-eiffel/gobo/blob/312f94ce4f472ccd63aca497cfc31de5b246b447/library/langserver/src/client_server/ls_message_manager.e#L645

In this example, in non-SCOOP mode, messages are not handled here,
avoiding endless execution.

Is moving to SCOOP worth the effort? It depends on the benefit you
will gain from having a concurrent system. I have a personal private
project which is similar in some way to yours. The difference is that I
wrote it from scratch with SCOOP, instead of having it single-threaded
and then modifying it to make it SCOOP aware. My system is a home
automation system. For example one thing that it does is to show a
map of my house, and when a light is turned on in some room, then
this room is displayed in yellow on the map. When I click on a
room on the map, the light will turn on if it was off, or vice-versa.
So it works more or less like your views, with events that trigger
some actions in other regions. There is the UI SCOOP region (the map
displayed on the screen, using EiffelVision2), a region containing
the model objects (light objects, room objects, etc.), a region to
listen to sockets to get physical events (i.e. a light being turned
on) and another region to send command to the physical world (i.e
turn off the light). When an event is received on the socket, the
model object is notified (asynchronous call) and updated. When the
model object is updated, the view is notified (asynchronous call)
and updated. When the user asks for an action, the UI receives this
request, and notify another region (asynchronous call) to send the
command to the physical world. This system has not been designed to
work in non-SCOOP mode. So I'm pretty sure it will hang somewhere
(probably in the code which listens to the socket) if executed in
non-SCOOP mode. But with some care, it could be made non-SCOOP
compatible.

Hope this helps.

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-
> users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.



Jimmy Johnson

unread,
May 30, 2026, 6:25:54 PM (5 days ago) May 30
to Eiffel Users
Eric,
Thanks for the tip about `{PLATFORM}.is_scoop_capable'  I will study your example.

Taking the plunge, I have added separate block:

     s: STRING
     separate target as t do
          if attached {EDITABLE} t as e then
               s := s + e.display_name.to_string_8
          else
               s := s + t.generating_type.name
          end
     end

1)  Since `t' is separate, will the true branch ever get executed or must I check for detachable EDITABLE or something?

2)  The statement in the else branch gives "Invalid Opereator expression:
          feature:  pluse]
          Formal type:  READABLE_STRING_8
          Actual type:  separate IMMUTABLE_STRING_8

Eric Bezault

unread,
May 30, 2026, 6:36:06 PM (5 days ago) May 30
to eiffel...@googlegroups.com, Jimmy Johnson
Hi Jimmy,


s: STRING
separate target as t do
if attached {separate EDITABLE} t as e then
s := s + create {STRING}.make_from_separate
(e.display_name.to_string_8)
else
s := s + create {STRING}.make_from_separate
(t.generating_type.name)
end
end

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com


> src/client_server/ls_message_manager.e#L645 <https://github.com/
> gobo-eiffel/gobo/blob/312f94ce4f472ccd63aca497cfc31de5b246b447/
> library/langserver/src/client_server/ls_message_manager.e#L645>
> https://www.gobosoft.com <https://www.gobosoft.com>
> >                     print (t.name <http://t.name>)    -- was
> "print (target.name <http://target.name>)"
> >                     print (t.rank)      -- was "print (target.rank)"
> >                end
> >           end
> >
> > Problems:
> > 1)  changes propagate throughout my library and descendants
> > 2)  library users must use separate blocks (or do they if not
> using SCOOP?)
> >
> > Questions:
> > 1)  Do you think the benefits of SCOOP are worth the effort?
> > 2)  How does it affect non-SCOOP systems?
> > 3)  Must non-SCOOP systems use the separate blocks?
> >
> > I look forward to feedback.  Thanks,
> > jjj
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Eiffel Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > users+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel- <https://groups.google.com/d/msgid/eiffel->
> > users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/eiffel- <http://groups.google.com/d/
> msgid/eiffel->
> > users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/e1ae2f6a-b83a-4b1f-9b7e-a5704e929358n%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-users/e1ae2f6a-b83a-4b1f-9b7e-
> a5704e929358n%40googlegroups.com?utm_medium=email&utm_source=footer>.



Jimmy Johnson

unread,
May 30, 2026, 7:29:10 PM (5 days ago) May 30
to Eiffel Users
Eric, you are on a role.  Thanks.  How about:

f: RAW_FILE
separate target as t do
     f.general_store (t)     -- `general_store' does not take a separate object.
end

Also, calls to Vision2 action sequences don't compile because `target' is separate:
     label.set_pebble_function (agent on_get_target)   -- where on_get_target: like target
     button.drop_actions.extend (agent on_drop_target)     -- on_drop_target (a_t: like target)

Incompatible argument
formal argument type:  FUNCTION [detachable ANY]
actual argument type: attached FUNCTION [[like target] attached separate ANY]

jjj

Eric Bezault

unread,
May 30, 2026, 8:01:28 PM (5 days ago) May 30
to eiffel...@googlegroups.com, Jimmy Johnson
Jimmy,

Here is a workaround (not tested though):

c: CELL [separate T]
create c.put (t)
f.general_store (c)

Alternatively, you should ask the target to store itself
in its own region:

separate target as t do
t.general_store
end

and in target's class:

general_store
local
f: RAW_FILE
do
...
f.general_store (Current)
end

As for Vision2 action sequences, can your pebble be non-separate,
using the CELL trick above?

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com


> (t.generating_type.name <http://t.generating_type.name>)
> end
> end
>
> --
> Eric Bezault <er...@gobosoft.com>
> Eiffel expert - available for freelance work
> https://www.gobosoft.com <https://www.gobosoft.com>
>
>
> On 31/05/2026 0:25, Jimmy Johnson wrote:
> > Eric,
> > Thanks for the tip about `{PLATFORM}.is_scoop_capable'  I will study
> > your example.
> >
> > Taking the plunge, I have added separate block:
> >
> >      s: STRING
> >      separate target as t do
> >           if attached {EDITABLE} t as e then
> >                s := s + e.display_name.to_string_8
> >           else
> >                s := s + t.generating_type.name <http://
> > https://github.com/gobo-eiffel/gobo/ <https://github.com/gobo-
> eiffel/gobo/>
> > blob/312f94ce4f472ccd63aca497cfc31de5b246b447/library/langserver/
> > src/client_server/ls_message_manager.e#L645 <https://github.com/
> > https://www.gobosoft.com <https://www.gobosoft.com> <https://
> > >                     print (t.name <http://t.name> <http://
> t.name <http://t.name>>)    -- was
> > "print (target.name <http://target.name> <http://target.name
> <http://target.name>>)"
> > >                     print (t.rank)      -- was "print
> (target.rank)"
> > >                end
> > >           end
> > >
> > > Problems:
> > > 1)  changes propagate throughout my library and descendants
> > > 2)  library users must use separate blocks (or do they if not
> > using SCOOP?)
> > >
> > > Questions:
> > > 1)  Do you think the benefits of SCOOP are worth the effort?
> > > 2)  How does it affect non-SCOOP systems?
> > > 3)  Must non-SCOOP systems use the separate blocks?
> > >
> > > I look forward to feedback.  Thanks,
> > > jjj
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Eiffel Users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > > users+un...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > eiffel- <https://groups.google.com/d/msgid/eiffel- <https://
> groups.google.com/d/msgid/eiffel->>
> > > users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>> <https://
> > > groups.google.com/d/msgid/eiffel- <http://groups.google.com/d/
> msgid/eiffel-> <http://groups.google.com/d/ <http://
> groups.google.com/d/>
> > msgid/eiffel->
> > > users/3fc8e4ed-44a9-4811-855e-5246873cd013n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Eiffel Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > users+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel- <https://groups.google.com/d/msgid/eiffel->
> > users/e1ae2f6a-b83a-4b1f-9b7e-a5704e929358n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/eiffel-users/e1ae2f6a-b83a-4b1f-9b7e-
> <http://groups.google.com/d/msgid/eiffel-users/e1ae2f6a-
> b83a-4b1f-9b7e->
> > a5704e929358n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/82b46b1a-4908-4090-b6b8-b5b9e18a9011n%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-users/82b46b1a-4908-4090-b6b8-
> b5b9e18a9011n%40googlegroups.com?utm_medium=email&utm_source=footer>.


Jimmy Johnson

unread,
Jun 1, 2026, 4:45:00 PM (3 days ago) Jun 1
to Eiffel Users
Eric,
Thanks.  The workaround compiled!  So closer.  Problem, though, is that any time I need to pick up or drop a separate `target' of a VIEW as a pebble, I have to wrap it in a CELL to pass it to a PROCEDURE or to get a result from a FUNCTION.  

Perhaps EiffelSoftware can chime in with a fix that allows ROUTINE, FUNCTION, PROCEDURE, and PREDICATE to use separate objects?  Maybe?

Thanks again,
jjj

Eric Bezault

unread,
Jun 1, 2026, 5:07:01 PM (3 days ago) Jun 1
to eiffel...@googlegroups.com, Jimmy Johnson
I don't think that the problem is with the classes ROUTINE,
FUNCTION, PROCEDURE, and PREDICATE. As far as I can see,
they can accept separate actual generic parameters.

The problem is with the EV_*_SEQUENCE classes which pass
non-separate actual generic parameters to these classes.

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com



> https://www.gobosoft.com <https://www.gobosoft.com>
> > (t.generating_type.name <http://t.generating_type.name> <http://
> t.generating_type.name <http://t.generating_type.name>>)
> > end
> > end
> >
> > --
> > Eric Bezault <er...@gobosoft.com>
> > Eiffel expert - available for freelance work
> > On 31/05/2026 0:25, Jimmy Johnson wrote:
> > > Eric,
> > > Thanks for the tip about `{PLATFORM}.is_scoop_capable'  I will
> study
> > > your example.
> > >
> > > Taking the plunge, I have added separate block:
> > >
> > >      s: STRING
> > >      separate target as t do
> > >           if attached {EDITABLE} t as e then
> > >                s := s + e.display_name.to_string_8
> > >           else
> > >                s := s + t.generating_type.name <http://
> t.generating_type.name> <http://
> > t.generating_type.name <http://t.generating_type.name>>
> eiffel/gobo/> <https://github.com/gobo- <https://github.com/gobo->
> www.gobosoft.com <https://www.gobosoft.com>> <https://
> > www.gobosoft.com <http://www.gobosoft.com> <https://
> t.name <http://t.name>> <http://
> > t.name <http://t.name> <http://t.name <http://t.name>>>)    -- was
> <http://target.name>> <http://target.name <http://target.name>
> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/eiffel-> <https://
> groups.google.com/d/> <http://
> > groups.google.com/d/ <http://groups.google.com/d/>>
> > > msgid/eiffel->
> > > >
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>.
> > >
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Eiffel Users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > > users+un...@googlegroups.com>.
> > > users/e1ae2f6a-b83a-4b1f-9b7e-a5704e929358n%40googlegroups.com
> > > groups.google.com/d/msgid/eiffel-users/e1ae2f6a-b83a-4b1f-9b7e-
> <http://groups.google.com/d/msgid/eiffel-users/e1ae2f6a-
> b83a-4b1f-9b7e->
> > <http://groups.google.com/d/msgid/eiffel-users/e1ae2f6a- <http://
> groups.google.com/d/msgid/eiffel-users/e1ae2f6a->
> > b83a-4b1f-9b7e->
> > > a5704e929358n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Eiffel Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > users+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel- <https://groups.google.com/d/msgid/eiffel->
> > users/82b46b1a-4908-4090-b6b8-b5b9e18a9011n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/eiffel-users/82b46b1a-4908-4090-b6b8-
> <http://groups.google.com/d/msgid/eiffel-users/82b46b1a-4908-4090-
> b6b8->
> > b5b9e18a9011n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/82610bda-f3c8-48f4-b1c3-1e0c4030087cn%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-users/82610bda-f3c8-48f4-
> b1c3-1e0c4030087cn%40googlegroups.com?utm_medium=email&utm_source=footer>.



Eric Bezault

unread,
Jun 1, 2026, 5:21:07 PM (3 days ago) Jun 1
to eiffel...@googlegroups.com, Jimmy Johnson
On 01/06/2026 22:44, Jimmy Johnson wrote:
> Eric,
> Thanks.  The workaround compiled!  So closer.  Problem, though, is that
> any time I need to pick up or drop a separate `target' of a VIEW as a
> pebble, I have to wrap it in a CELL to pass it to a PROCEDURE or to get
> a result from a FUNCTION.

Note that if you pass the separate target as argument to
`on_drop_target`, then according to SCOOP the call will
not be asynchronous as you may expect. It will be synchronous
and you may lose the concurrency behavior that you try
to get with the use of SCOOP. Using the CELL trick has
the double advantage that it might help you get the
expected asynchronous behavior, provided that the target
object is not controlled when you pass the cell containing
it to `on_drop_target`.
> https://www.gobosoft.com <https://www.gobosoft.com>
> > (t.generating_type.name <http://t.generating_type.name> <http://
> t.generating_type.name <http://t.generating_type.name>>)
> > end
> > end
> >
> > --
> > Eric Bezault <er...@gobosoft.com>
> > Eiffel expert - available for freelance work
> > On 31/05/2026 0:25, Jimmy Johnson wrote:
> > > Eric,
> > > Thanks for the tip about `{PLATFORM}.is_scoop_capable'  I will
> study
> > > your example.
> > >
> > > Taking the plunge, I have added separate block:
> > >
> > >      s: STRING
> > >      separate target as t do
> > >           if attached {EDITABLE} t as e then
> > >                s := s + e.display_name.to_string_8
> > >           else
> > >                s := s + t.generating_type.name <http://
> t.generating_type.name> <http://
> > t.generating_type.name <http://t.generating_type.name>>
> eiffel/gobo/> <https://github.com/gobo- <https://github.com/gobo->
> www.gobosoft.com <https://www.gobosoft.com>> <https://
> > www.gobosoft.com <http://www.gobosoft.com> <https://
> t.name <http://t.name>> <http://
> > t.name <http://t.name> <http://t.name <http://t.name>>>)    -- was
> <http://target.name>> <http://target.name <http://target.name>
> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/eiffel-> <https://
> groups.google.com/d/> <http://
> > groups.google.com/d/ <http://groups.google.com/d/>>
> > > msgid/eiffel->
> > > >
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>.
> > >
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Eiffel Users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > > users+un...@googlegroups.com>.
> > > users/e1ae2f6a-b83a-4b1f-9b7e-a5704e929358n%40googlegroups.com
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Eiffel Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > users+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel- <https://groups.google.com/d/msgid/eiffel->
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-

Jimmy Johnson

unread,
Jun 1, 2026, 10:58:36 PM (3 days ago) Jun 1
to Eiffel Users
Eric
Could you expand on "according to SCOOP the call will not be asynchronous".

Eric Bezault

unread,
Jun 2, 2026, 3:31:33 AM (3 days ago) Jun 2
to eiffel...@googlegroups.com, Jimmy Johnson
What I had in mind is lock passing. This is one of the trickiest
mechanism in SCOOP, as explained here:

https://www.eiffel.org/doc/solutions/Asynchronous_Calls

Here is a concrete example:

f (a: separate T)
local
b: separate U
do
...
separate b as s do
s.g (a)
end
end

Here, the call to `g` will be synchronous. Unfortunately, contrary
to what I had thought, the use of CELL will not help make this call
asynchronous.

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com




> https://www.gobosoft.com <https://www.gobosoft.com>
> <http://t.generating_type.name <http://t.generating_type.name>>
> <http://
> > t.generating_type.name <http://t.generating_type.name> <http://
> t.generating_type.name <http://t.generating_type.name>>>)
> > > end
> > > end
> > >
> > > --
> > > Eric Bezault <er...@gobosoft.com>
> > > Eiffel expert - available for freelance work
> > > https://www.gobosoft.com <https://www.gobosoft.com> <https://
> > > On 31/05/2026 0:25, Jimmy Johnson wrote:
> > > > Eric,
> > > > Thanks for the tip about `{PLATFORM}.is_scoop_capable'  I will
> > study
> > > > your example.
> > > >
> > > > Taking the plunge, I have added separate block:
> > > >
> > > >      s: STRING
> > > >      separate target as t do
> > > >           if attached {EDITABLE} t as e then
> > > >                s := s + e.display_name.to_string_8
> > > >           else
> > > >                s := s + t.generating_type.name <http://
> t.generating_type.name> <http://
> > t.generating_type.name <http://t.generating_type.name>> <http://
> > > t.generating_type.name <http://t.generating_type.name> <http://
> gobo-eiffel/gobo/> <https://github.com/gobo- <https://github.com/gobo->
> > eiffel/gobo/> <https://github.com/gobo- <https://github.com/gobo-
> > <https://github.com/gobo- <https://github.com/gobo->>
> > > eiffel/gobo/>
> > > > blob/312f94ce4f472ccd63aca497cfc31de5b246b447/library/
> langserver/
> > > > src/client_server/ls_message_manager.e#L645 <https://
> > github.com/ <http://github.com/> <https://github.com/ <https://
> > > www.gobosoft.com <http://www.gobosoft.com> <http://
> > t.name <http://t.name> <http://t.name <http://t.name>>> <http://
> > > t.name <http://t.name> <http://t.name <http://t.name>> <http://
> > <http://target.name <http://target.name>>> <http://target.name
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>
> > > > eiffel- <https://groups.google.com/d/msgid/eiffel- <https://
> msgid/eiffel-> <http://groups.google.com/d/ <http://
> groups.google.com/d/>
> > msgid/eiffel->>>
> > > > >
> groups.google.com/d/> <http://
> > groups.google.com/d/ <http://groups.google.com/d/>> <http://
> > > groups.google.com/d/ <http://groups.google.com/d/> <http://
> <http://40googlegroups.com <http://40googlegroups.com>>>>?
> > > > > utm_medium=email&utm_source=footer>.
> > > >
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the
> Google
> > > > Groups "Eiffel Users" group.
> > > > To unsubscribe from this group and stop receiving emails from
> it,
> > > send
> > > > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > > > users+un...@googlegroups.com>.
> > > > To view this discussion visit https://groups.google.com/d/
> > > > users/e1ae2f6a-b83a-4b1f-9b7e-
> a5704e929358n%40googlegroups.com <http://40googlegroups.com>
> > > > groups.google.com/d/msgid/eiffel-users/e1ae2f6a-
> > > <http://groups.google.com/d/msgid/eiffel-users/e1ae2f6a-
> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Eiffel Users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > > users+un...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > eiffel- <https://groups.google.com/d/msgid/eiffel- <https://
> groups.google.com/d/msgid/eiffel->>
> > > users/82b46b1a-4908-4090-b6b8-b5b9e18a9011n%40googlegroups.com
> > > groups.google.com/d/msgid/eiffel-users/82b46b1a-4908-4090-b6b8-
> <http://groups.google.com/d/msgid/eiffel-users/82b46b1a-4908-4090-
> b6b8->
> > <http://groups.google.com/d/msgid/eiffel-
> users/82b46b1a-4908-4090- <http://groups.google.com/d/msgid/eiffel-
> users/82b46b1a-4908-4090->
> > b6b8->
> > > b5b9e18a9011n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Eiffel Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> > users+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel- <https://groups.google.com/d/msgid/eiffel->
> > users/82610bda-f3c8-48f4-b1c3-1e0c4030087cn%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/eiffel-users/82610bda-f3c8-48f4-
> <http://groups.google.com/d/msgid/eiffel-users/82610bda-f3c8-48f4->
> > b1c3-1e0c4030087cn%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/02516f09-f4cf-4689-9899-9ca60f1ca6dfn%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-users/02516f09-
> f4cf-4689-9899-9ca60f1ca6dfn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

Reply all
Reply to author
Forward
0 new messages