Re: Is read_file() always called after an activity __init__?

2008-03-01 Thread Tomeu Vizoso
On Sat, Mar 1, 2008 at 3:12 AM, John Gilmore [EMAIL PROTECTED] wrote:
  Hmmm, so if my activity needs it's preferences before it can display
   anything to the user, potential future lazy loading of the data-store
   (to try and speed up general activity start-up time) is going to leave
   folks watching my activity with a blank screen for a lazy while? Ouch.

  Ahem.  The Grand Unified Theory of OLPC was that the datastore/journal
  were going to entirely replace the filesystem (as far as Activites
  are concerned).  Activities aren't permitted to read/write the ordinary
  Linux filesystem, according to this theory.

Not true. The datastore is for recording actions and storing the
documents associated to those. In other words: for saving the child's
work and allowing for efficient retrieval. Where have you found this
theory?

See the link below for an explanation of the suggested guidelines for
writing to the fs:

http://wiki.laptop.org/go/Low-level_Activity_API#Writable_Directories

  If the datastore isn't just as ready, just as fast, and just as
  available as the filesystem, e.g. for holding tiny little files that
  rapidly keep the Activity's configuation options, then there's
  something terribly wrong here.

Can you elaborate? I'm certainly not happy with the current state of
the DS, but would like to know more about which problems you see in
the current implementation.

Thanks,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Is read_file() always called after an activity __init__?

2008-02-29 Thread Tomeu Vizoso
On Thu, Feb 28, 2008 at 10:56 PM, Gary C Martin [EMAIL PROTECTED] wrote:
  It does seem like read_file() is only triggered if you have
   previously
   saved an actual file to filesystem, if you just have metadata, no
   call
   is ever made to read_file() so it's a rather bad place to pick-up the
   metadata. At least this is what I'm seeing here – I've just created a
   0 size file in my write_file() and now a resume from that journal
   entry is triggering read_file() every time.
  
   You are right again. Perhaps we should add a read_metadata() method?
   An alternative would be to have a 'datastore-loaded' method, but that
   would be less consistent with the current API.

  Hmmm, so if my activity needs it's preferences before it can display
  anything to the user, potential future lazy loading of the data-store
  (to try and speed up general activity start-up time) is going to leave
  folks watching my activity with a blank screen for a lazy while? Ouch.

Well, metadata loading shouldn't be as slow as for the user to notice.
But if you add this to all the other initializations, it is
significant. Also, the user wouldn't see a blank screen, just startup
will be (say) 100ms slower than for an activity that can start without
reading the metadata.

   But the determining reason would be that metadata properties other
   than the custom ones are not preserved across reboots :/
  
   http://dev.laptop.org/ticket/4662

  Oooh thanks, double ouch, I hadn't spotted that gotcha yet!

  I'm getting the distinct feeling I should avoid current metadata
  interactions by an activity (too flakey and in transition just now)
  and just create a custom preference like file format, it only needs to
  store two key/value pairs at the moment, probably will eventually need
  only half a dozen at the most for future display options. Though I
  guess even that's still going to be a problem if lazy data-store
  loading is ever implemented (though every activity that needs to load
  a file for display will suffer there).

  Leave the metadata alone for the Journal and lower level activity
  class behaviours.  Pity, metadata looked like a nice solution for
  storing simple custom activity state information, maybe in update. 2...

Right, metadata in journal entries was thought exactly for that. Using
some other kind of preferences file may be the best for now.

Regards,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Is read_file() always called after an activity __init__?

2008-02-29 Thread John Gilmore
 Hmmm, so if my activity needs it's preferences before it can display  
 anything to the user, potential future lazy loading of the data-store  
 (to try and speed up general activity start-up time) is going to leave  
 folks watching my activity with a blank screen for a lazy while? Ouch.

Ahem.  The Grand Unified Theory of OLPC was that the datastore/journal
were going to entirely replace the filesystem (as far as Activites
are concerned).  Activities aren't permitted to read/write the ordinary
Linux filesystem, according to this theory.

If the datastore isn't just as ready, just as fast, and just as
available as the filesystem, e.g. for holding tiny little files that
rapidly keep the Activity's configuation options, then there's
something terribly wrong here.

John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Is read_file() always called after an activity __init__?

2008-02-28 Thread Gary C Martin
Hi Tomeu,

On 28 Feb 2008, at 09:40, Tomeu Vizoso wrote:

 Well, __init__ is too soon.

Well before calling activity.Activity.__init__(self, handle) yes that  
would be a real bad idea for sure :-) but after that it 'should' be  
fine shouldn't it, as the activity class is all set up? I can  
certainly read the metadata in my main __int__ just after the call up  
to super, and all works well.

 AFAIK, the API docs say that you can
 safely access Activity.metadata in the read_file() and write_file()
 methods. read_file() is called when the user is resuming an existing
 activity and write_file() when sugar thinks it is a good time to save
 changes to the journal (probably several times during the life of an
 activity).

It does seem like read_file() is only triggered if you have previously  
saved an actual file to filesystem, if you just have metadata, no call  
is ever made to read_file() so it's a rather bad place to pick-up the  
metadata. At least this is what I'm seeing here – I've just created a  
0 size file in my write_file() and now a resume from that journal  
entry is triggering read_file() every time.

 Is very probable that the API documentation is lacking, can you point
 me to the docs you were following? Have you already read the HIG in
 the wiki?

Not an officially maintained page I know, but:
http://wiki.laptop.org/go/Beyond_Hello_World

Same suggestion comes from the current pydocs:
http://xo_running_pydoc-p8080:8080/ 
sugar.activity.activity.html#Activity-read_file

http://www.vrplumber.com/sugar-docs/sugar.activity.activity.html#Activity-read_file
 
  (an online version)

I also went through a number of activity sources in git looking for  
examples, but I didn't find one that ONLY used metadata. They all seem  
to either not bother storing any UI state (so resuming or from new  
makes no difference), or they save actual files.

BTW: I'm quite happy with read_file() not getting called in file-less  
cases, just a matter of documenting it somewhere (if that is indeed  
the correct behaviour intended).

Thanks for your input.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Is read_file() always called after an activity __init__?

2008-02-28 Thread Tomeu Vizoso
On Thu, Feb 28, 2008 at 12:45 PM, Gary C Martin [EMAIL PROTECTED] wrote:
 Hi Tomeu,


  On 28 Feb 2008, at 09:40, Tomeu Vizoso wrote:

   Well, __init__ is too soon.

  Well before calling activity.Activity.__init__(self, handle) yes that
  would be a real bad idea for sure :-) but after that it 'should' be
  fine shouldn't it, as the activity class is all set up? I can
  certainly read the metadata in my main __int__ just after the call up
  to super, and all works well.

You are right, though at some point we would like to defer the fetch
of data from the datastore to a later point after construction. In
this way some activities will be able to launch faster.

   AFAIK, the API docs say that you can
   safely access Activity.metadata in the read_file() and write_file()
   methods. read_file() is called when the user is resuming an existing
   activity and write_file() when sugar thinks it is a good time to save
   changes to the journal (probably several times during the life of an
   activity).

  It does seem like read_file() is only triggered if you have previously
  saved an actual file to filesystem, if you just have metadata, no call
  is ever made to read_file() so it's a rather bad place to pick-up the
  metadata. At least this is what I'm seeing here – I've just created a
  0 size file in my write_file() and now a resume from that journal
  entry is triggering read_file() every time.

You are right again. Perhaps we should add a read_metadata() method?
An alternative would be to have a 'datastore-loaded' method, but that
would be less consistent with the current API.

   Is very probable that the API documentation is lacking, can you point
   me to the docs you were following? Have you already read the HIG in
   the wiki?

  Not an officially maintained page I know, but:
 http://wiki.laptop.org/go/Beyond_Hello_World

Not that we have many officially maintained pages about sugar docs :/

  Same suggestion comes from the current pydocs:
 http://xo_running_pydoc-p8080:8080/
  sugar.activity.activity.html#Activity-read_file
 
 http://www.vrplumber.com/sugar-docs/sugar.activity.activity.html#Activity-read_file
   (an online version)

Would be nice to have a wiki bot that would update the API docs in the
wiki from the sources. Anybody know something like that?

  I also went through a number of activity sources in git looking for
  examples, but I didn't find one that ONLY used metadata. They all seem
  to either not bother storing any UI state (so resuming or from new
  makes no difference), or they save actual files.

I think at some point activities like those realize that they have
some data that would be better saved in a file.

But the determining reason would be that metadata properties other
than the custom ones are not preserved across reboots :/

http://dev.laptop.org/ticket/4662

  BTW: I'm quite happy with read_file() not getting called in file-less
  cases, just a matter of documenting it somewhere (if that is indeed
  the correct behaviour intended).

  Thanks for your input.

Thanks,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Is read_file() always called after an activity __init__?

2008-02-28 Thread Gary C Martin
 It does seem like read_file() is only triggered if you have  
 previously
 saved an actual file to filesystem, if you just have metadata, no  
 call
 is ever made to read_file() so it's a rather bad place to pick-up the
 metadata. At least this is what I'm seeing here – I've just created a
 0 size file in my write_file() and now a resume from that journal
 entry is triggering read_file() every time.

 You are right again. Perhaps we should add a read_metadata() method?
 An alternative would be to have a 'datastore-loaded' method, but that
 would be less consistent with the current API.

Hmmm, so if my activity needs it's preferences before it can display  
anything to the user, potential future lazy loading of the data-store  
(to try and speed up general activity start-up time) is going to leave  
folks watching my activity with a blank screen for a lazy while? Ouch.

 But the determining reason would be that metadata properties other
 than the custom ones are not preserved across reboots :/

 http://dev.laptop.org/ticket/4662

Oooh thanks, double ouch, I hadn't spotted that gotcha yet!

I'm getting the distinct feeling I should avoid current metadata  
interactions by an activity (too flakey and in transition just now)  
and just create a custom preference like file format, it only needs to  
store two key/value pairs at the moment, probably will eventually need  
only half a dozen at the most for future display options. Though I  
guess even that's still going to be a problem if lazy data-store  
loading is ever implemented (though every activity that needs to load  
a file for display will suffer there).

Leave the metadata alone for the Journal and lower level activity  
class behaviours.  Pity, metadata looked like a nice solution for  
storing simple custom activity state information, maybe in update. 2...

Thanks again.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Is read_file() always called after an activity __init__?

2008-02-27 Thread Gary C Martin
Hope this is not too silly a question, but is the read_file() method  
always called after the Python activity __init__'? I'm just started  
using self.metadata to store some basic preferences to pickup after a  
Journal resume, but I'm finding read_file() is never called in my  
activity. My write_file() method is correctly called as the activity  
is closed. I'm wondering if read_file() is only ever triggered during  
a resume if you have a real chunk of filesystem to write/read (my  
activity needs/has no file)?

FYI: If I pop a self.read_file('foo.bar') in my activities main  
__init__ all works as I'd expect. Should I just be picking up metadata  
values in my __init__? All documentation I've seen so far says to  
check your metadata in read_file.

Thanks for any help.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel