Starting Iliad without gst-remote

Hello,

I installed Iliad on GST 3.2.2. I'm able to start it via

Iliad.SwazooIliad startOn:8080

both on gst-browser and gst-remote

but when I invoke gst on my console:

> gst -I iliad.im (an image with Iliad loaded)

and then do

Iliad.SwazooIliad startOn:8080

It doesn't give any error but when I try to go to

http://localhost:8080/browse

the browser says "Waiting for localhost" and does nothing. What might be the problem?

Hi Canol!

Can you try:
Processor activeProcess suspend

It should fix the problem.

Cheers,
--
Nicolas Petton

ObjectFusion S.A.R.L.
Applications web, consulting, design
http://www.objectfusion.fr

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi Nicolas,

It worked, though it prevented me doing other things. I had to ctrl+z to terminate it.

On 08/17/2010 06:35 PM, ZuLuuuuuu wrote:
>
> Hi Nicolas,
>
> It worked, though it prevented me doing other things. I had to ctrl+z to
> terminate it.

"stdin next" might work too, though I haven't tested it.  Just press
"enter" to exit back to the REPL.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini-2 wrote

"stdin next" might work too, though I haven't tested it.  Just press
"enter" to exit back to the REPL.

Yes, it works as well. And pressing enter allows me to quit nicely. Thanks. What is the logic behind this?

stdin next

It just ask for an input and suspend the REPL since it wait for an input.
When you hit return it consume the stdin and the REPL restart listening the stdin.
AFAIK
        Mth




On Aug 17, 2010, at 6:56 PM, ZuLuuuuuu wrote:


       

       
               
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/18/2010 12:56 AM, ZuLuuuuuu wrote:

>
> Yes, it works as well. And pressing enter allows me to quit nicely. Thanks.
> What is the logic behind this?

The current VM is not pre-emptive so only if one process is yielding another
will run. The --enable-preemptive switch is mostly working though.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, Aug 18, 2010 at 02:53, Holger Hans Peter Freyther
<[hidden email]> wrote:
> On 08/18/2010 12:56 AM, ZuLuuuuuu wrote:
>
>>
>> Yes, it works as well. And pressing enter allows me to quit nicely. Thanks.
>> What is the logic behind this?
>
> The current VM is not pre-emptive so only if one process is yielding another
> will run.

No, that's not the reason why the REPL blocks I/O.  The reason is simply
that at any time _either the REPL or the VM_ will run, and I/O is obviously
handled by the VM.

Also, the VM _is_ preemptive, despite the ill-named --enable-preemptive.
Semaphores (which include Delay timeouts and I/O events) can and will
preempt the running process.  It is just that the VM will not preempt a
process just because it's been running for some time; that is, the VM is
not time-sharing.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/18/2010 03:56 PM, Paolo Bonzini wrote:

> Also, the VM _is_ preemptive, despite the ill-named --enable-preemptive.
> Semaphores (which include Delay timeouts and I/O events) can and will
> preempt the running process.  It is just that the VM will not preempt a
> process just because it's been running for some time; that is, the VM is
> not time-sharing.

Well, it really depends on your definition of pre-emption. Calling a primitive
to trigger a context is something that I understand as cooperation... :)

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/18/2010 10:02 AM, Holger Hans Peter Freyther wrote:
No, you don't need to call a primitive.  A process sitting on "aSocket
next" will preempt other processes when data becomes available.
Similarly for Delays.

Non-preemptive means basically "you can be sloppy about locks" as long
as there are no yields in a critical section.  This is definitely not
the case in any Smalltalk.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk