Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
François
@GrandSchtroumpf
Could be. Like the compiler for example.
But still you want to be able to listen on compilation event.
yann300
@yann300
yes so some child_process are not meant to be deactivated on the fly.
i see the need of running a command line (what is the communication support - is that websocket?) and the callOnce can be usefull for certain use case that we don't even know yet.
This could be useful for child_process because you don't want them to stay idle all the time I guess.
If they are idle, that probably means they can trigger event and run in the background
if they terminate after the plugin call that just means they are designed to run and terminate.
François
@GrandSchtroumpf
Yes, but you're allocating memory for nothing. If there are idle there arenot going to emit an event.
Yes, for me the only reason to keep a plugin alive is when it's listening on event from another plugin OR UI event
yann300
@yann300

in the first case (If they are idle...) you probably don't want to call with callOnce,
ok i see your msg

, but you're allocating memory for nothing. If there are idle there arenot going to emit an event.

if the program is idling after the call even though it doesn't not do anything more, that means he is either badly designed or a bug.

back in a few minutes...
François
@GrandSchtroumpf
So you would recommend to let the plugin developer "self destroy" his plugin after a call ?
Aniket
@Aniket-Engg
can someone provide me kovan test ether?
François
@GrandSchtroumpf
Sorry I don't have any test account on my computer right now. There is no faucet for kovan ?
Aniket
@Aniket-Engg
i think they require a social media post link
François
@GrandSchtroumpf
Can you use Goerli instead ? They have an easy faucet
Aniket
@Aniket-Engg
okay, i got it or kovan. they require login with github
actually, I am testing an issue on all testnet
François
@GrandSchtroumpf
ok
yann300
@yann300

So you would recommend to let the plugin developer "self destroy" his plugin after a call ?

the thing is that the command line which is being called it not the plugin it self.
it might make sense to keep the plugin activated even though the exe does not run in the background.
e.g when the plugin is activated, it could check if the command (or commands - if the plugin need multiple commands) is present in the local computer (if the binary-ies are present). If that 's the case the doThis() function will call the command.
if the command finishes then that's ok and the plugin keep being activated cause the command can be called again
if the command doesn't finish, then that's still ok, might be that the command will output something which could be forwarded as event to remix plugin
if the command doesn't finish ( but wrongly ), then it is idle for ever... in that case yes, that's up to the plugin developer (plugin which wrap the command line as remix plugin) to force terminating the exe... (but the plugin itself could still remain activated, just because it is callable again).

the callOnce() still make sense, but the plugin who is calling callOnce() needs to be sure that the called plugin is supporting it. for instance if the called plugin needs to trigger event , using callOnce() for calling it will probably won't work.

callOnce() 'd really make sense now for the debug plugin, with the function getTrace() . but another issue comes: the icon will appear in the vertical bar and disappear just after the call which is a bit weird ux.
yann300
@yann300
continuing... to answer the question: having a plugin which self deactivate after being called... I don't really see the need of that.. at least with the current scenario we have
... well that need more thinking I think ... another input 'd be good
can you share a specific example? @GrandSchtroumpf
also I just remember now that you were mentioning last week a IPC plugin? cause I don't think that will work in the browser
it needs a file system path afaik
François
@GrandSchtroumpf
For now my example is a compiler that runs inside a child process. The compiler has one method :
compile(src: string, version: string): Promise<CompilationResult>
Once you compiled your code you don't need the compiler anymore. So the plugin developer of the compiler could do :
async compile(src: string, version: string): Promise <CompilationResult> {
  const result = await this.doTheCompilationProcess(src, version)
  this.emit('compilationFinished', result) // emit for any other plugin listening
  setTimeout(() => this.call('manager', 'deactivatePlugin', this.name, 10) // self deactivate the plugin after return
  return result
}
The advantages of this process are :
  • plugin developers know better what to do with there plugin
  • it works without any change (we just need to update the canDeactivate method in RemixPluginManager to let plugin deactivate themselves)
François
@GrandSchtroumpf
Doing this makes only sense when is "pure":
  • stateless (do not keep memory)
  • no side effect (do not listen on other plugin or UI event)
I think the current event listener could even work in this case because the engine keeps track of previous event listeners when plugin reactivates.
François
@GrandSchtroumpf
An issue would be that if two plugins are calling the compile method at the same time then the plugin would shutdown before restarting. So the best would be to check if the queue is empty before deactivating. Which would require some update.
yann300
@yann300

plugin developers know better what to do with there plugin

if a plugin developer want to force deactivation of its plugin, that's up to him/her indeed. In the case of the compiler i am not sure that really applies also because other compiler does not have the same behavior (our solidity)

François
@GrandSchtroumpf
ou solidity compiler leaves inside an iframe and wait for UI event (button pressed) & plugin events (save editor) so the example above wouldn't apply for this one
That's why I think it's better to let the plugin developer say want he wants to self destroyed his plugin.
yann300
@yann300

ou solidity compiler leaves inside an iframe and wait for UI event (button pressed) & plugin events (save editor) so the example above wouldn't apply for this one

yes I mean for a plugin of type "compiler" it could be not consistent to have different behavior (one that'll not self deactivate after a call and one that will) but as you said, that's up to the plugin dev to deactivate if he wants it.

also it'd be good to identify what it really means for a plugin to be activated.
in case or remixd, the plugin is activated when the websocket connection is accepted (which means that the connection is made and the plugin is waiting for call and no exe are necessarily running in the background).
in the case of the callOnce i feel there's a mix between plugin is activated and plugin is currently running....
i can't develop more today, time is flying... but let's discuss and looking forward for more input from you all.

maybe we can setup a call this week depending on your availability @GrandSchtroumpf
François
@GrandSchtroumpf
activation:
  • iframe: inject the iframe in the DOM
  • socket: try to connect to a server through a wss connection
  • child process: spawn a new child process from the current process
I don't think callOnce is a good idea in the end because it's not up the caller plugin to know the life cycle of the target plugin.
François
@GrandSchtroumpf
Btw, here is the PR for implementing Child Process : ethereum/remix-plugin#178
@yann300 @LianaHus @ioedeveloper if you want to take a look
yann300
@yann300

I don't think callOnce is a good idea in the end because it's not up the caller plugin to know the life cycle of the target plugin.

ok

child process: spawn a new child process from the current process

spawning a child process is what the plugin does, but what is the communication media between the plugin and the engine in that case ? is that wss ?
iframe and socket are communication medias for transferring messages I don't see what is the media for child process, should child process plugins be a subset of socket plugin?
thanks for the pr, let's have a talk when you have some availability, i should be around all the week and also next Monday.

François
@GrandSchtroumpf
It's IPC.
yann300
@yann300
ah ok, it won't work in the browser then (i mean if the engine runs in the browser), but might be useful for other use cases
François
@GrandSchtroumpf
Yes it's for eth-code (Omkara's extension for VSCode). We could create a WebWorker plugin to achieve the same effect on the browser.
Though WebWorkers have access to some part of the main thread so it shouldn't be used for untrusted code.
David Disu
@ioedeveloper
I think the standup meeting time has changed.
yann300
@yann300
ah I was not really sure, is that in 1 hour?
David Disu
@ioedeveloper
It should be 1pm your time.
yann300
@yann300
ah yeah true it is 1pm in the calendar too...my bad
Aniket
@Aniket-Engg
is standup done?
David Disu
@ioedeveloper
No, it will be in 30 mins
Aniket
@Aniket-Engg
ohkay