parallel mozrepl processes / windows?

91 views
Skip to first unread message

MozreplGuy

unread,
Feb 22, 2009, 6:41:16 PM2/22/09
to MozLab
Hi all, can Mozrepl work in an environment where multiple instances
access/run Mozrepl on a single system? For example it could be
possible that quite a few developers create some clever scripts for
example based on Stilgar's au3 library. But I wonder what happened if
these script were to run in parallel? Any predictions?

Kind regards, MozreplGuy

Massimiliano Mirra

unread,
Feb 23, 2009, 6:04:49 AM2/23/09
to moz...@googlegroups.com
MozRepl accepts multiple connections and automatically renames a
"repl" object to "repl1", "repl2" etc if there is conflict in the
current scope. I don't know how this interacts with Stiglar's
library, though.

-m

MozreplGuy

unread,
Feb 23, 2009, 7:19:36 AM2/23/09
to MozLab
Yes, I noticed that too.

However, all the sessions share the same context. This of course makes
"concurrent sessions" or "parallel scripts" not feasible. Any ideas
how to resolve this?

-Peter

PS Mozrepl, is really great!!!
> > Kind regards, MozreplGuy- Hide quoted text -
>
> - Show quoted text -

MozreplGuy

unread,
Feb 23, 2009, 7:31:30 AM2/23/09
to MozLab
Hi Massimiliano,
I noticed that too, however these parallel connections share the same
context etc. Which makes "independent sessions" or "paralllel scripts"
not feasible. Any ideas how to resolve this?

-Peter

PS Mozrepl is really great!


On Feb 23, 3:04 am, Massimiliano Mirra <hyperstr...@gmail.com> wrote:

Massimiliano Mirra

unread,
Feb 23, 2009, 3:49:51 PM2/23/09
to moz...@googlegroups.com
On Mon, Feb 23, 2009 at 1:31 PM, MozreplGuy <moz...@gmail.com> wrote:
>
> Hi Massimiliano,
> I noticed that too, however these parallel connections share the same
> context etc. Which makes "independent sessions" or "paralllel scripts"
> not feasible. Any ideas how to resolve this?

Hmm, not sure what's the problem here. Extensions load scripts in the
same context (the browser window) too, and that works fine. Is this
different?

>
> -Peter
>
> PS Mozrepl is really great!

Thanks. :)
-m

MozreplGuy

unread,
Feb 24, 2009, 5:58:46 AM2/24/09
to MozLab
Hi Massimiliano.
Please accept my apologies. I am very inexperienced with Firefox.

But in the meantime I have done some research. I believe the way
ff.au3 opens handles windows doesn't allow you to work independently
on different instances.

That probably means I can not use ff.au3. It is still to incomplete. I
guess I will have to write my own little library and use
"nsIWindowWatcher" or something like this to track the different
windows. Of course I have to study this first :-)

May be I can ask you another question.
- What telnet client do you recommend?
- When I connect to mozrepl, I always get this ....> and I have to
press ; how can I avoid this?

Ciao!
Peter


Here is what I would like to do.

On Feb 23, 12:49 pm, Massimiliano Mirra <hyperstr...@gmail.com> wrote:
> >> - Show quoted text -- Hide quoted text -

Massimiliano Mirra

unread,
Feb 24, 2009, 7:38:24 AM2/24/09
to moz...@googlegroups.com
Hey, no need for apologies, I was just trying to understand. :)

I normally use the Emacs interaction mode to have MozRepl integrated
with my editor, but I know Linux telnet and netcat to work. Better
run them under rlwrap to get history and history-search. Under
Windows, Microsoft Telnet is known to be troublesome, putty is known
to work.

I don't experience the issue with "...>" at the beginning of the
session, maybe that's due to control characters being sent by the
client you're using?

MozreplGuy

unread,
Feb 24, 2009, 10:19:36 PM2/24/09
to MozLab
Thanks, I am using rlwrap with cygwin right now. Much more
comfortable :-)

I did some more research and hopefully can explain the problem a
little better.

In AutoIt you can communicate with MozlRepl/TCP basically through two
functions

TCPSend (http://www.autoitscript.com/autoit3/docs/functions/
TCPSend.htm)
and
TCPRecv (http://www.autoitscript.com/autoit3/docs/functions/
TCPSend.htm)

In a situation where Mozrepl scripts run in parallel the problem is
that you can not guarantee that the response you get from mozrepl with
TCPRecv is actually the response to the request you sent with TCPSend.
Other scripts could have send overlapping requests as well.
Example:
TCPSend from Script1
TCPSend from Script2
TCPRecv from Script1

Unfortunately there seems no way to match the response to the request.


The only work-around I see is probably to have each script start
Firefox with a new port (4242,4243,4244 ...). But I am not sure,
whether that would be an acceptable work-around (may be a problem with
firewalls?). What do you think?

Is there a better way to solve that problem?

By the way, in the work-around I noticed a problem. Example: 10
scripts run and open 10 firefox/mozrepl at ports from 4242 to 4251 and
at the end 9 of the 10 firefox are closed again. I would expect that
in the end there would be only one active listening Mozrepl left.
However, there are still all 10. Only when I close the last open
firefox window, all ports are closed. Is that a bug?

-Peter

Massimiliano Mirra

unread,
Feb 25, 2009, 3:29:18 AM2/25/09
to moz...@googlegroups.com
I can only comment about plain MozRepl as I'm not familiar with AutoIt.

With MozRepl, if you connect two or more sessions and execute e.g.
"2+2" in the first, "4+1" in the second, etc. results aren't going to
be mixed up. Input-read-eval-print happens within a single
invocation.

> Is there a better way to solve that problem?
>
> By the way, in the work-around I noticed a problem. Example: 10
> scripts run and open 10 firefox/mozrepl at ports from 4242 to 4251 and
> at the end 9 of the 10 firefox are closed again. I would expect that
> in the end there would be only one active listening Mozrepl left.
> However, there are still all 10. Only when I close the last open
> firefox window, all ports are closed. Is that a bug?

I have no idea, I suggest you talk with AutoIt developers about this. :)

By the way, are you subscribed to this mailing list? Google is asking
me to approve each of your messages manually...

-m

MozreplGuy

unread,
Feb 25, 2009, 4:53:38 AM2/25/09
to MozLab
Yes, I am subscribed.

> With MozRepl, if you connect two or more sessions and execute e.g.
> "2+2" in the first, "4+1" in the second, etc. results aren't going to
> be mixed up. Input-read-eval-print happens within a single
> invocation.

I think I understand what you mean by "single invocation". This might
be true within the mozrepl, but I wonder how you can ensure over a
network/telnet connection that the result is communicated back and
forth "as one". First "some script" has to send mozrepl a command
through the tcp, right? Then the result is received through the same
socket. In this case it is possible that the result can be received in
a different order. Depending on the timing the following could happen
TCPSend from Script1
TCPRecv from Script2
TCPRecv from Script1

Script2 is not supposed to receive the result from Script1 (or should
ignore it, but how?)

I guess what that means is that for interactive use Mozrepl works
perfectly, but for it is probably not well suitable to use it for
scripting or so (like Thorsten tried).

Are there other ways to connect synchronously to Mozrepl or Firefox?
(may be similar to COM an IE)?

Regarding:
> > By the way, in the work-around I noticed a problem. Example: 10
> > scripts run and open 10 firefox/mozrepl at ports from 4242 to 4251 and
> > at the end 9 of the 10 firefox are closed again. I would expect that
> > in the end there would be only one active listening Mozrepl left.
> > However, there are still all 10. Only when I close the last open
> > firefox window, all ports are closed. Is that a bug?
>
> I have no idea, I suggest you talk with AutoIt developers about this. :)

I think this is unrelated to AutotoIt. You can test it yourself:
firefox -repl 4242
firefox -repl 4243
firefox -repl 4244
Now close two firefox windows (e.g. 4243/4). If you look at the active
ports, you can see that 4242-4244 are still active, but it should be
only. I don't think that is right.

Yes, I am subscribed.

> With MozRepl, if you connect two or more sessions and execute e.g.
> "2+2" in the first, "4+1" in the second, etc. results aren't going to
> be mixed up. Input-read-eval-print happens within a single
> invocation.

I think I understand what you mean by "single invocation". This might
be true within the mozrepl, but I wonder how you can ensure over a
network/telnet connection that the result is communicated back and
forth "as one". First "some script" has to send mozrepl a command
through the tcp, right? Then the result is received through the same
socket. In this case it is possible that the result can be received in
a different order. Depending on the timing the following could happen
TCPSend from Script1
TCPRecv from Script2
TCPRecv from Script1

Script2 is not supposed to receive the result from Script1 (or should
ignore it, but how?)

I guess what that means is that for interactive use Mozrepl works
perfectly, but for it is probably not well suitable to use it for
scripting or so (like Thorsten tried).

Are there other ways to connect synchronously to Mozrepl or Firefox?
(may be similar to COM an IE)?

-Peter

Regarding:
> > By the way, in the work-around I noticed a problem. Example: 10
> > scripts run and open 10 firefox/mozrepl at ports from 4242 to 4251 and
> > at the end 9 of the 10 firefox are closed again. I would expect that
> > in the end there would be only one active listening Mozrepl left.
> > However, there are still all 10. Only when I close the last open
> > firefox window, all ports are closed. Is that a bug?
>
> I have no idea, I suggest you talk with AutoIt developers about this. :)

I think this is unrelated to AutotoIt. You can test it yourself:
firefox -repl 4242
firefox -repl 4243
firefox -repl 4244
Now close two firefox windows (e.g. 4243/4). If you look at the active
ports, you can see that 4242-4244 are still active, but it should be
only. I don't think that is right.


On Feb 25, 12:29 am, Massimiliano Mirra <hyperstr...@gmail.com> wrote:

Massimiliano Mirra

unread,
Feb 25, 2009, 5:20:04 AM2/25/09
to moz...@googlegroups.com
On Wed, Feb 25, 2009 at 10:53 AM, MozreplGuy <moz...@gmail.com> wrote:
>
> Yes, I am subscribed.
>
>> With MozRepl, if you connect two or more sessions and execute e.g.
>> "2+2" in the first, "4+1" in the second, etc. results aren't going to
>> be mixed up.  Input-read-eval-print happens within a single
>> invocation.
>
> I think I understand what you mean by "single invocation". This might
> be true within the mozrepl, but I wonder how you can ensure over a
> network/telnet connection that the result is communicated back and
> forth "as one". First "some script" has to send mozrepl a command
> through the tcp, right? Then the result is received through the same
> socket. In this case it is possible that the result can be received in
> a different order. Depending on the timing the following could happen
> TCPSend from Script1
> TCPRecv  from Script2
> TCPRecv from Script1
>
> Script2 is not supposed to receive the result from Script1 (or should
> ignore it, but how?)
>
> I guess what that means is that for interactive use Mozrepl works
> perfectly, but for it is probably not well suitable to use it for
> scripting or so (like Thorsten tried).

It makes no difference whether MozRepl is invoked interactively or
not: connections are simply separate. When you connect to a web
server your your browser, you don't expect to randomly get data that
was intended for other browsers, do you? Same here...

Massimiliano Mirra

unread,
Feb 25, 2009, 5:21:48 AM2/25/09
to moz...@googlegroups.com
On Wed, Feb 25, 2009 at 10:53 AM, MozreplGuy <moz...@gmail.com> wrote:

>> > However, there are still all 10. Only when I close the last open
>> > firefox window, all ports are closed. Is that a bug?
>>
>> I have no idea, I suggest you talk with AutoIt developers about this. :)
>
> I think this is unrelated to AutotoIt. You can test it yourself:
> firefox -repl 4242
> firefox -repl 4243
> firefox -repl 4244
> Now close two firefox windows (e.g. 4243/4). If you look at the active
> ports, you can see that 4242-4244 are still active, but it should be
> only. I don't think that is right.

You're not launching separate Firefox'es that way, just launching
additional windows for the same Firefox.

If you want to launch a separate Firefox you have to pass the -no-remote switch.

MozreplGuy

unread,
Feb 25, 2009, 6:18:31 AM2/25/09
to MozLab
Thanks, for the clarification and patient answers. I am on a steep
learning curve at the moment, so please forgive my not so smart
questions (or questions that look like conclusions). I think I have
everything I need so far.


On Feb 25, 2:20 am, Massimiliano Mirra <hyperstr...@gmail.com> wrote:

Massimiliano Mirra

unread,
Feb 25, 2009, 6:26:52 AM2/25/09
to moz...@googlegroups.com
No problem. (BTW I figured why Google was asking to approve all
messages... and also helpfully showing an "Approve always" which I
consistently overlooked. PEBKAC :))

-m

Stilgar

unread,
Feb 25, 2009, 9:35:40 AM2/25/09
to MozLab
Hi,
the window handling in the FF.au3 is (currently) incomplete, but you
can connect with different scripts to MozRepl/FireFox without
problems. But it's not very usefull if you have different scripts that
manipulates the tabs. But you can with one script manipulate pages and
with an other one can you control e.g. the AddOn Screengrab to save
screenshots, or control FireFM at the same time.

Regards
Thorsten

Massimiliano Mirra

unread,
Feb 25, 2009, 10:58:52 AM2/25/09
to moz...@googlegroups.com
One might also want to encapsulate the needed operations in a custom
interactor. I did so for a similar use case (getting screenshots) and
described it here:
http://hyperstruct.net/2009/2/5/turning-firefox-into-a-screenshot-server-with-mozrepl
Reply all
Reply to author
Forward
0 new messages