Re: [IAEP] fixing etoys
Marco Pesenti Gritti wrote: >> If we manage to make DBus entirely optional, the initial effort >> of porting a Linux applications to Sugar would be greatly >> simplified. > > As far as I know this is already the case. The only non standard bit > are a couple of custom X properties. Oh, is there a way around this requirement too? A few days ago someone here at OLE Nepal bundled up Firefox 2 and was disappointed to get the infamous circle icon. For them, changing the code and rebuilding from source would be overkill. (please don't ask me why Firefox 2... it might have been any large Linux application) If nobody has looked at this before, I might give it a shot to see what the Gnome wnck applet does to pair windows with their applications and desktop icons. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
Am 25.06.2008 um 10:49 schrieb Marco Pesenti Gritti:
> On Wed, Jun 25, 2008 at 4:23 AM, Bernie Innocenti
> <[EMAIL PROTECTED]> wrote:
>> Also, I'd like to check if we could do anything to reduce our
>> dependence on DBus to provide basic desktop services for which
>> there are existing Freedesktop standards and long established
>> X conventions.
>>
>> If we manage to make DBus entirely optional, the initial effort
>> of porting a Linux applications to Sugar would be greatly
>> simplified.
>
> As far as I know this is already the case. The only non standard bit
> are a couple of custom X properties.
>
> The activity has a DBus service associated with the following methods:
>
>@dbus.service.method(_ACTIVITY_INTERFACE)
>def SetActive(self, active):
>logging.debug('ActivityService.set_active: %s.' % active)
>self._activity.props.active = active
>
>@dbus.service.method(_ACTIVITY_INTERFACE)
>def Invite(self, buddy_key):
>self._activity.invite(buddy_key)
>
>@dbus.service.method(_ACTIVITY_INTERFACE)
>def TakeScreenshot(self):
>self._activity.take_screenshot()
>
> They are all optional. SetActive we might be able to get rid off.
> TakeScreenshot is quite an hack, we might be able to use gtk offscreen
> rendering or composite to get rid of it in the future. Invite I
> personally think it's fine to stay a DBus method.
>
> Obviously you start to need DBus heavily as soon as you want to
> interact with the journal and the presence service, though.
Well, since these methods are not mandatory there is no need to get
rid of them. An activity can still choose to implement activation/
deactivation by other means, for example.
- Bert -
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
On Wed, Jun 25, 2008 at 4:23 AM, Bernie Innocenti <[EMAIL PROTECTED]> wrote:
> Also, I'd like to check if we could do anything to reduce our
> dependence on DBus to provide basic desktop services for which
> there are existing Freedesktop standards and long established
> X conventions.
>
> If we manage to make DBus entirely optional, the initial effort
> of porting a Linux applications to Sugar would be greatly
> simplified.
As far as I know this is already the case. The only non standard bit
are a couple of custom X properties.
The activity has a DBus service associated with the following methods:
@dbus.service.method(_ACTIVITY_INTERFACE)
def SetActive(self, active):
logging.debug('ActivityService.set_active: %s.' % active)
self._activity.props.active = active
@dbus.service.method(_ACTIVITY_INTERFACE)
def Invite(self, buddy_key):
self._activity.invite(buddy_key)
@dbus.service.method(_ACTIVITY_INTERFACE)
def TakeScreenshot(self):
self._activity.take_screenshot()
They are all optional. SetActive we might be able to get rid off.
TakeScreenshot is quite an hack, we might be able to use gtk offscreen
rendering or composite to get rid of it in the future. Invite I
personally think it's fine to stay a DBus method.
Obviously you start to need DBus heavily as soon as you want to
interact with the journal and the presence service, though.
Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
> Yoshiki Ohshima wrote:
> > Again, start up time is not a problem. Etoys start up looks a bit
> > slow on XO, but that is because the DBus communication that has to be
> > done.
>
> I frequently hear DBus being accused of latency. As badly
> implemented as it might be, I can't believe a daemon relaying
> a bunch of bytes over a UNIX domain socket can introduce more
> than 1ms of lag per message, even on a very slow processor.
>
> Has anybody ever analyzed the actual DBus traffic? With timings?
> How many messages are we talking about?
It seems that you are right! I took profile data in Etoys and the
DBus part accounts for about 60-70ms on start up. Other 3 seconds are
spent on Squeak part and I think I could speed them up a bit.
The following two message tallys are taken from two different part
of code upon start up. They should cover most of it.
Sorry for the false alerm.
-- Yoshiki
--
- 1761 tallies, 2164 msec.
**Tree**
95.3% {2062ms} SystemDictionary>>send:toClassesNamedIn:with:
|43.2% {935ms} Delay class(Behavior)>>startUp:
| |17.0% {368ms} SecurityManager class>>startUp
| | |17.0% {368ms} SecurityManager>>startUp
| | | 17.0% {368ms} SecurityManager>>loadSecurityKeys
| | |16.8% {364ms} Object class>>readFrom:
| | | 10.6% {229ms} Array(Object)>>isKindOf:
| | | 6.2% {134ms} Compiler class>>evaluate:
| | |6.2% {134ms} Compiler class>>evaluate:for:logged:
| | | 6.2% {134ms} Compiler class>>evaluate:for:notifying:logged:
| | |6.2% {134ms}
Compiler>>evaluate:in:to:notifying:ifFail:logged:
| | | 6.0% {130ms} Compiler>>translate:noPattern:ifFail:
| | |6.0% {130ms}
Parser>>parse:class:noPattern:context:notifying:ifFail:
| | | 4.7% {102ms} Parser>>init:notifying:failBlock:
| | |4.7% {102ms} Parser(Scanner)>>scan:
| | | 4.7% {102ms} Parser(Scanner)>>scanToken
| | |4.7% {102ms} Parser(Scanner)>>xLitQuote
| | | 4.7% {102ms} Parser(Scanner)>>scanToken
[4.7% {102ms} Parser(Scanner)>>xLitQuote
[ 2.4% {52ms} Parser(Scanner)>>scanToken
[|2.4% {52ms} Parser(Scanner)>>xLitQuote
[ 2.3% {50ms} Parser(Scanner)>>scanLitVec
[2.3% {50ms} Parser(Scanner)>>scanToken
[ 2.3% {50ms} Parser(Scanner)>>xLitQuote
| |14.2% {307ms} FileDirectory class>>startUp
| | |9.7% {210ms} FileDirectory class>>setDefaultDirectory:
| | | |9.4% {203ms} FilePath class>>pathName:
| | | | 9.4% {203ms} FilePath class>>pathName:isEncoded:
| | | |9.4% {203ms} FilePath>>pathName:isEncoded:
| | | | 9.4% {203ms} LanguageEnvironment
class>>defaultFileNameConverter
| | | |9.4% {203ms} SystemDictionary>>platformName
| | | | 9.4% {203ms} SystemDictionary>>getSystemAttribute:
| | | |9.4% {203ms} SystemDictionary(Object)>>deprecated:block:
| | | | 9.4% {203ms} Preferences
class>>showDeprecationWarnings
| | | |9.4% {203ms} Preferences
class>>valueOfFlag:ifAbsent:
| | |3.1% {67ms} SmalltalkImage>>openSourceFiles
| | | 3.0% {65ms} FileDirectory class>>openSources:andChanges:forImage:
| | |2.6% {56ms} FileDirectory class>>openSources:forImage:
| |7.3% {158ms} ExternalSettings class>>startUp
| | |7.3% {158ms} ExternalSettings class>>preferenceDirectory
| | | 6.2% {134ms} SmalltalkImage>>vmPath
| | |6.2% {134ms} FilePath class>>pathName:isEncoded:
| | | 6.2% {134ms} FilePath>>pathName:isEncoded:
| | |6.2% {134ms} ByteString(String)>>convertFromWithConverter:
| |3.8% {82ms} Delay class>>startUp
|34.4% {744ms} WeakArray class>>startUp:
| |34.4% {744ms} WeakArray class>>restartFinalizationProcess
| | 34.2% {740ms} Semaphore class>>forMutualExclusion
|13.0% {281ms} AutoStart class>>startUp:
| |7.4% {160ms} AutoStart class>>checkForPluginUpdate
| | |7.4% {160ms} PasteUpMorph>>install
| | | 6.2% {134ms} PasteUpMorph>>installFlaps
| | |4.8% {104ms} Project>>assureFlapIntegrity
| | | 4.8% {104ms} IdentityDictionary(Dictionary)>>removeKey:ifAbsent:
| |5.6% {121ms} AutoStart class>>checkForUpdates
| | 5.6% {121ms} PasteUpMorph>>install
| |3.5% {76ms} PasteUpMorph>>displayWorldSafely
| | |3.5% {76ms} WorldState>>displayWorldSafely:
| | | 3.5% {76ms} PasteUpMorph>>displayWorld
| | |3.5% {76ms} PasteUpMorph>>privateOuterDisplayWorld
| | | 3.5% {76ms} WorldState>>displayWorld:submorphs:
| | |3.5% {76ms} WorldState>>drawWorld:submorphs:invalidAreasOn:
| | | 3.5% {76ms} FormCanvas(Canvas)>>fullDrawMorph:
| | |3.5% {76ms} FormCanvas(Canvas)>>fullDraw:
| | | 3.5% {76ms} SugarNavTab(Morph)>>fullDrawOn:
| |
Re: [IAEP] fixing etoys
Yoshiki Ohshima wrote: > Again, start up time is not a problem. Etoys start up looks a bit > slow on XO, but that is because the DBus communication that has to be > done. I frequently hear DBus being accused of latency. As badly implemented as it might be, I can't believe a daemon relaying a bunch of bytes over a UNIX domain socket can introduce more than 1ms of lag per message, even on a very slow processor. Has anybody ever analyzed the actual DBus traffic? With timings? How many messages are we talking about? It might very well be that the event loop on one of the endpoints is misbehaving and not waking up the process immediately when the socket has incoming data. This is not at all unusual in applications that mix GUI and networking, but I don't know the specific interactions of gtk, dbus and the python bindings. Also, I'd like to check if we could do anything to reduce our dependence on DBus to provide basic desktop services for which there are existing Freedesktop standards and long established X conventions. If we manage to make DBus entirely optional, the initial effort of porting a Linux applications to Sugar would be greatly simplified. Yes, one could wrap the thing in libsugarize, but why resort to a kludge when there are standards we could fall back to? -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: fixing etoys
At Tue, 24 Jun 2008 14:16:22 -0400, Albert Cahalan wrote: > > Here are some ideas that might help you fix some of the problems > with start-up performance, shut-down performance, open source, > and software engineering practices. First, Etoys' start up time is very fast. And shutdown/saving could be very fast if we can save the whole image. What is slow is scanning relevant objects from the image upon saving, due to lack of modularity in the image. > You're trying to do a persistant system image on an OS that wasn't > really designed for it. If you were on an exotic system with a > persistant image (like EROS, KeyKOS, or OS/400), you might be able > to cut the power at any time without losing more than a few seconds > of work. The key here is that the persistant system image OSes > continuously write out changes to disk. They do this atomicly, > and in small chunks, rather than overwriting everything at once in > a dangerous non-atomic operation. > > Start with that. Break each object out into a separate file. > Your database becomes a directory rather than a big blob file. > When an in-memory object changes, you write a copy to a fresh > new file on disk. You keep the old on-disk copy around until > the new one has been synched. (fsync or sync probably, but be > very careful to avoid doing this more than once every few > seconds) You may need subdirectories for better performance; > it is very unwise to rely on Reiserfs-like performance when > having large directories. Saving the Squeak image to disk is not slow. (Back then, Ted Kaehler had a memory system called OOZE for older Smalltalk that does the checkpointing and constant object-grained swapping. ALTO had a memory problem that caused the system crashes once or twice a day without any reasons. OOZE kept people from losing their work except last 30 seconds or so.) > On-demand loading is required for start-up performance. Again, start up time is not a problem. Etoys start up looks a bit slow on XO, but that is because the DBus communication that has to be done. Otherwise, all it needs to do is reading a continuous 20MB file into a continuous memory region and scanning the memory once. > Inheritance from a read-only image will cut per-instance disk size. > On a Debian system, install the read-only image under /usr/share > and the per-instance changes somewhere under $HOME. On the XO, > the read-only image stays in the activity and the per-instance > part goes into the journal. For older XO system software which > does not support grouping multiple files into single Journal entries, > you'll have to do it yourself with a standard archive format. > There are three to choose from: tar, cpio, pax. > > To make things maintainable outside of the walled garden, store the > objects in text form. Make them be like nicely formatted source code. > Be permissive in parsing them, and try to preserve any comments that > might be added by users with regular text editors. Try to maximize > compatibility with GNU Smalltalk. But code and objects are different. Vast majority of incremental changes including object creation and setting preferences are already maintained outside of the walled garden. The latest image is (essentially) just a serial applications of updates available at: http://tinlizzie.org/updates/etoys/updates/ from an early image. > If you have bulk data that would not reasonably be editable with > a text editor, such as PNG images, then leave that part in binary. > > To cut down on dirty anonymous pages in memory, and thus greatly > improve the situation on low-memory swapless systems like the XO, > you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the > binary blobs at startup. This should just be things like PNG images. I don't say there is a problem, such as the problem of modularity, and suggestions similar to yours have been made before. But it seems that you really don't know how it works and what are the real problems. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
fixing etoys
Here are some ideas that might help you fix some of the problems with start-up performance, shut-down performance, open source, and software engineering practices. You're trying to do a persistant system image on an OS that wasn't really designed for it. If you were on an exotic system with a persistant image (like EROS, KeyKOS, or OS/400), you might be able to cut the power at any time without losing more than a few seconds of work. The key here is that the persistant system image OSes continuously write out changes to disk. They do this atomicly, and in small chunks, rather than overwriting everything at once in a dangerous non-atomic operation. You're trying to do a persistant system image on an OS that wasn't really designed for it. If you were on an exotic system with a persistant image (like EROS or OS/400), you'd be able to cut the power at any time without losing more than a few seconds of work. The key here is that the persistant system image OSes continuously write out changes to disk. They do this atomicly, and in small chunks, rather than overwriting everything at once in a dangerous non-atomic operation. Start with that. Break each object out into a separate file. Your database becomes a directory rather than a big blob file. When an in-memory object changes, you write a copy to a fresh new file on disk. You keep the old on-disk copy around until the new one has been synched. (fsync or sync probably, but be very careful to avoid doing this more than once every few seconds) You may need subdirectories for better performance; it is very unwise to rely on Reiserfs-like performance when having large directories. On-demand loading is required for start-up performance. Inheritance from a read-only image will cut per-instance disk size. On a Debian system, install the read-only image under /usr/share and the per-instance changes somewhere under $HOME. On the XO, the read-only image stays in the activity and the per-instance part goes into the journal. For older XO system software which does not support grouping multiple files into single Journal entries, you'll have to do it yourself with a standard archive format. There are three to choose from: tar, cpio, pax. To make things maintainable outside of the walled garden, store the objects in text form. Make them be like nicely formatted source code. Be permissive in parsing them, and try to preserve any comments that might be added by users with regular text editors. Try to maximize compatibility with GNU Smalltalk. If you have bulk data that would not reasonably be editable with a text editor, such as PNG images, then leave that part in binary. To cut down on dirty anonymous pages in memory, and thus greatly improve the situation on low-memory swapless systems like the XO, you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the binary blobs at startup. This should just be things like PNG images. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
