headers
sergio_101 | 3 Feb 05:20

which vm for pier

i have two new pier sites going up, and i am not sure where the issue
is, but the headless server seems to die after a few hours..

i got the vm from one of the cog prebuilt binaries, but i would have
to go searching around to find out where..

the details are:

VM Version:     Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.140]
VM Type:        32bit
Endianness:     little

anyway.. i was wondering which one everyone was currently using on
their deployed systems..

thanks!

--

-- 
----
peace,
sergio
photographer, journalist, visionary

http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
Permalink | Reply | 4 comments |
headers
John Toohey | 3 Feb 18:00

Re: which vm for pier

When the COG VM is running in headless mode, any exceptions will cause
the VM to exit, logging the exception to the PharoDebug.log file.
Check the log for an exception.

On Thu, Feb 2, 2012 at 23:20, sergio_101 <sergiolist <at> village-buzz.com> wrote:
> i have two new pier sites going up, and i am not sure where the issue
> is, but the headless server seems to die after a few hours..
>
> i got the vm from one of the cog prebuilt binaries, but i would have
> to go searching around to find out where..
>
> the details are:
>
> VM Version:     Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.140]
> VM Type:        32bit
> Endianness:     little
>
> anyway.. i was wondering which one everyone was currently using on
> their deployed systems..
>
> thanks!
>
> --
> ----
> peace,
> sergio
> photographer, journalist, visionary
>
> http://www.CodingForHire.com
> http://www.coffee-black.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sven Van Caekenberghe | 3 Feb 18:33
Picon
Favicon

Re: which vm for pier


On 03 Feb 2012, at 18:00, John Toohey wrote:

> When the COG VM is running in headless mode, any exceptions will cause
> the VM to exit, logging the exception to the PharoDebug.log file.
> Check the log for an exception.

Correction: any unhandled exceptions at 'top level'.
The 'older' behavior was to open a debugger.
The result is the same in both cases: thread stopped.

Most if not all servers will/should abandon and stop that request/thread but continue to service new
requests until they run out of resources.

> On Thu, Feb 2, 2012 at 23:20, sergio_101 <sergiolist <at> village-buzz.com> wrote:
>> i have two new pier sites going up, and i am not sure where the issue
>> is, but the headless server seems to die after a few hours..
>> 
>> i got the vm from one of the cog prebuilt binaries, but i would have
>> to go searching around to find out where..
>> 
>> the details are:
>> 
>> VM Version:     Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.140]
>> VM Type:        32bit
>> Endianness:     little
>> 
>> anyway.. i was wondering which one everyone was currently using on
>> their deployed systems..
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Igor Stasenko | 3 Feb 20:24
Picon

Re: which vm for pier

On 3 February 2012 18:33, Sven Van Caekenberghe <sven <at> beta9.be> wrote:
>
> On 03 Feb 2012, at 18:00, John Toohey wrote:
>
>> When the COG VM is running in headless mode, any exceptions will cause
>> the VM to exit, logging the exception to the PharoDebug.log file.
>> Check the log for an exception.
>
> Correction: any unhandled exceptions at 'top level'.
> The 'older' behavior was to open a debugger.
> The result is the same in both cases: thread stopped.
>
> Most if not all servers will/should abandon and stop that request/thread but continue to service new
requests until they run out of resources.
>

Yes, and you free to change that by putting a proper exception handler
in topmost context
of worker thread.
If you don't , then a default behavior is to log error and quit to OS.

--

-- 
Best regards,
Igor Stasenko.
Permalink | Reply | 1 comment |
headers
sergio_101 | 4 Feb 12:55

Re: which vm for pier

great.. thanks, all.. i am just running box stock pier on that one..
maybe i need to look at that?

thanks..

--

-- 
----
peace,
sergio
photographer, journalist, visionary

http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
Permalink | Reply | 0 comments |
headers
Milan Mimica | 4 Feb 18:12
Picon

multiple components

Hello!


   Some of my more complex views contain a hierarchy of components, each component taking care of some small part of UI logic. This view is implemented as a container component which delegates rendering to several sub-components. From outside, this view looks like an ordinary WAComponent. Everything goo so far. A small problem arises when such component tries to #call: another component. Since technically it is usually the inner component sending #call: to self, the new view doesn't replace the whole hierarchy, but only the inner component that actually sent #call:, which is not fine in this case.
What am I doing now, is sending each inner component a reference to its container component and then the inner object sends #call: to its container instead of self. I find it ugly, need to elaborate why? Is there a better solution?

A similar problem arises with #answer -- you cannot #answer from an inner component because it wasn't the one which wall #call-ed in the first place. Again I need a reference to a container component to #answer from there.


--
Milan Mimica
http://sparklet.sf.net
_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Permalink | Reply | 3 comments |
headers
Robert Sirois | 4 Feb 21:44
Picon
Favicon
Gravatar

RE: multiple components

I don't have a good answer but I generally use announcements in that situation.

RS

Date: Sat, 4 Feb 2012 18:12:34 +0100
From: milan.mimica <at> gmail.com
To: seaside <at> lists.squeakfoundation.org
Subject: [Seaside] multiple components

Hello!

   Some of my more complex views contain a hierarchy of components, each component taking care of some small part of UI logic. This view is implemented as a container component which delegates rendering to several sub-components. From outside, this view looks like an ordinary WAComponent. Everything goo so far. A small problem arises when such component tries to #call: another component. Since technically it is usually the inner component sending #call: to self, the new view doesn't replace the whole hierarchy, but only the inner component that actually sent #call:, which is not fine in this case.
What am I doing now, is sending each inner component a reference to its container component and then the inner object sends #call: to its container instead of self. I find it ugly, need to elaborate why? Is there a better solution?

A similar problem arises with #answer -- you cannot #answer from an inner component because it wasn't the one which wall #call-ed in the first place. Again I need a reference to a container component to #answer from there.


--
Milan Mimica
http://sparklet.sf.net

_______________________________________________ seaside mailing list seaside <at> lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside 
_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Permalink | Reply | 1 comment |
headers
Johan Brichau | 4 Feb 22:12
Picon
Gravatar

Re: multiple components

For the #call: sites, I don't know any other way than passing the reference to the container. 
But for the #answer: sites, your container component can intercept subcomponents answers [1]. You can use
that to propagate an answer from a subcomponent as the answer of the container component.

[1] http://book.seaside.st/book/components/embedding/intercepting-answer

On 04 Feb 2012, at 18:12, Milan Mimica wrote:

> Hello!
> 
>    Some of my more complex views contain a hierarchy of components, each component taking care of some small
part of UI logic. This view is implemented as a container component which delegates rendering to several
sub-components. From outside, this view looks like an ordinary WAComponent. Everything goo so far. A
small problem arises when such component tries to #call: another component. Since technically it is
usually the inner component sending #call: to self, the new view doesn't replace the whole hierarchy, but
only the inner component that actually sent #call:, which is not fine in this case.
> What am I doing now, is sending each inner component a reference to its container component and then the
inner object sends #call: to its container instead of self. I find it ugly, need to elaborate why? Is there a
better solution?
> 
> A similar problem arises with #answer -- you cannot #answer from an inner component because it wasn't the
one which wall #call-ed in the first place. Again I need a reference to a container component to #answer
from there.
> 
> 
> -- 
> Milan Mimica
> http://sparklet.sf.net
> _______________________________________________
> seaside mailing list
> seaside <at> lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Permalink | Reply | 0 comments |
headers
Milan Mimica | 5 Feb 11:00
Picon

Re: multiple components

On 4 February 2012 21:44, Robert Sirois <watchlala <at> hotmail.com> wrote:
I don't have a good answer but I generally use announcements in that situation.

Yes, I think it's about time I take a look at announcements too.
This answer pretty much summarizes it: http://stackoverflow.com/a/7980099/514306


--
Milan Mimica
http://sparklet.sf.net
_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Permalink | Reply | 0 comments |
headers
Stephan Eggermont | 6 Feb 13:32
Picon
Favicon
Gravatar

FOSDEM devroom

Yesterday we had a nice day filled with great presentations.

Getting to Brussels the day before proved to be a challenge, 
as the Dutch railways showed to have lots of trouble with
3 cm of snow and a cold night. Andy showed us a good place
to eat and talk near the Central Station.

In the end all presenters managed to be on time and the whole
day ran smoothly. As the devroom was the second day of 
FOSDEM, we thought it wise not to start too early. That was 
a good idea, as the ULB was still very quiet when Norbert 
showed us how to create REST/json/xml based services.
Markus followed with the Pharo Vision. 

Gradually more people came to the devroom until the 
jQueryMobile presentation was so filled that we had to refuse
people entering the room. The Amber presentation also attracted 
a lot of people new to smalltalk. The ability to create a fast feedback
cycle apparently is a major issue for javascript developers. 
The progress made since ESUG2011 is impressive. 

The next subjects (working with many cores, making smalltalk fast,
spoon) still attracted over 40 participants.

The introduction to smalltalk attracted quite a lot of young developers.
Some remarks by participants:
- a consistent set of keybindings, allowing switching between
 windows is essential (a developer who has trouble using a
 mouse for longer periods);
- current developers are no longer used to free floating windows,
 it doesn't matter if it is better, to attract new people you need to
 remove barriers to entry (a freepascal maintainer);
- I would have expected to have started with the basics (we focused
 on the things we experienced as difficult and different, using the 
 different inspectors and browsers to navigate a large codebase,
 debugger driven development)
And some reminder for ourselves
- Tests for the domain model are not enough to ensure that the
 whole application works correctly;
- Throw away old builds;
- Check if there are enough power strips.

I very much liked talking to people otherwise only known from 
the mailing lists and the cross-pollination between the different
dialects. I would have liked to have more time for discussions.
A lunch break might be a good idea. 

And finally a remark for next years devroom manager: don't expect
to see much from FOSDEM :)

Stephan Eggermont
Permalink | Reply | 0 comments |

Gmane