Personal Scripts moving to personal git space ?
Devel team, I'm in the process of both updating my scripts ( http://wiki.laptop.org/go/User:Ixo/Script ) to be under the better GPL , ( :] thanks Tony for the nudge!) and moving them into a better manageable personal git space. I tried to follow the directions at: http://wiki.laptop.org/go/Creating_a_personal_git_tree But alas, the response from ssh Permission denied (publickey). I'm guessing that I actually need to start a project on git, and submit a ssh-key before I can have access ? If a project is necessary, I have quite a number of 'in concept' ideas started at: http://wiki.laptop.org/go/User:Ixo/Project Anyone of which, someone could give me incentive enough to dive into and make the project start up :) Any thoughts or idea/feedback on any of the above ? :) - i X o ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: using the browser as an activity platform : pyxpcom / hulahop / Gears
On Sat, Feb 16, 2008 at 10:21 AM, Samuel Klein [EMAIL PROTECTED] wrote: The core use here is being able to use the browser as activity platform -- letting web developers good at JS code and test on most any platform, and develop something that can be a first-class activity within Sugar. One example is Dan's javascript spreadsheet, anothe ris a dynamic library (see for instance http://wiki.laptop.org/go/Dynamic_library), another is an existing web service online that one might want to run locally. In addition to pyxpcom, let me add Google Gears as a useful piece of this platform, especially when offering local use of popular online tools. Off the top of my head, MediaWiki, MindMeister, I copy Ben Lisbakken, a gears maintainer, who reports that there is a Gears patch to make it work without extension support... Ben, I'll also introduce you to marcopg separately. At the Google Web Toolkit conference in December 2007, many of the developers, along with conference sponsor Pearson Education, expressed interest in working on XO projects in several computer languages. One of us could guest blog on the subject, or take it up on their mailing list. http://code.google.com/webtoolkit/ Java to platform-independent JavaScript compiler. http://googlewebtoolkit.blogspot.com/ Current post: Spreading the word about pollution in the US: MapEcos, built with GWT This relates to the recent Engineers Without Borders query. http://groups.google.com/group/Google-Web-Toolkit This is the official discussion forum for GWT. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Is read_file() always called after an activity __init__?
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__?
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
Metadata preserved across reboots?
Tomeu, As I've mentioned before, I'm working on an EText reading activity that uses metadata to save the current page number when the activity closes, kind of like a bookmark. When the activity is resumed the saved page number would be shown. This works just fine while the XO is turned on, but the page number metadata disappears when you reboot or turn the machine off and on. I'm using the same code that the Read activity does for this purpose, and I notice that Read has exactly the same problem. This is frustrating. The journal entry shows a screenshot of the page I left off on, but I don't go back to that page on opening. I have also noticed that if I open the document from a USB card or an SD card no metadata is saved at all. I had been assuming that this was a bug in Sugar that would be fixed at some point. Your text below makes it sound like this is an actual deliberate feature. Am I understanding this correctly? James Simmons 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 :/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Personal Scripts moving to personal git space ?
Ixo, But alas, the response from ssh Permission denied (publickey). This error message implies that git was unable to use your ssh-agent to log in dev. In order for git to be able to use your ssh-agent, you need to have the ssh-agent running and you need to set SSH_AUTH_SOCK to the value printed by ssh-agent when it starts. You also need to add your ssh keys to the agent. Michael P.S. - there's a handy script called 'keychain', available in most distributions, that will handle these details for you on session creation. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Metadata preserved across reboots?
On Thu, Feb 28, 2008 at 8:02 PM, James Simmons [EMAIL PROTECTED] wrote: Tomeu, As I've mentioned before, I'm working on an EText reading activity that uses metadata to save the current page number when the activity closes, kind of like a bookmark. When the activity is resumed the saved page number would be shown. This works just fine while the XO is turned on, but the page number metadata disappears when you reboot or turn the machine off and on. I'm using the same code that the Read activity does for this purpose, and I notice that Read has exactly the same problem. This is frustrating. The journal entry shows a screenshot of the page I left off on, but I don't go back to that page on opening. I have also noticed that if I open the document from a USB card or an SD card no metadata is saved at all. When is metadata not saved? Or you mean the metadata is saved but not retrieved? I had been assuming that this was a bug in Sugar that would be fixed at some point. Your text below makes it sound like this is an actual deliberate feature. Am I understanding this correctly? No, it's a big bug in the current implementation of the DataStore. Could be fixed in the current implementation, but there have been plans of rewriting it, so nobody has looked into this since a long time ago. See http://dev.laptop.org/ticket/4662 for more details. 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 :/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
Ivan Krstić wrote: On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote: actually we are normally using b64 encoding so that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the TXT record. But _why_ are we encoding at all? TXT RDATA is one or more character strings, which are each a length octet followed by up to 255 arbitrary characters treated as a binary string. Am I misremembering the RFC? I made this comment on #6572 but perhaps it's worth repeating here to a wider audience: Not base64 encoding the key makes current builds fail to get the buddy properties due to a D-Bus issue that needs a workaround. This means you don't see any buddies in mesh view, although they can see you. So if we stop base64 encoding, we lose interoperability with the existing builds and need a flag day to upgrade. This is to save 12 bytes. Is that worth it? Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Metadata preserved across reboots?
Tomeu, When I use the Read activity to open a document stored in a USB drive or my SD card I notice that I do not return to the page I was on previously, even though I have not restarted the computer at all; I've just ended the Read activity, then immediately resumed it. I also notice that I *never* get a screenshot from the previous use of any activity when I open the entry on a USB drive or SD card. All of these things work correctly in the Journal proper, except of course when rebooting. You keep the screenshot but lose the activity-specifc metadata like page number. On the USB and SD, I don't know if the metadata is saved or not. I suppose it could be saved and never retrieved. In any case, it's nice to know this is a bug and not intentional. James Simmons Tomeu Vizoso wrote: When is metadata not saved? Or you mean the metadata is saved but not retrieved? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Journal: two quick suggestions
On Thu, Feb 28, 2008 at 11:41 AM, Eben Eliason [EMAIL PROTECTED] wrote: while toying around with the Journal today I had two ideas about the anything and anytime filter functions: Both interesting ideas... anything: Apart from offering activities and file-types as filter-options I'm thinking that it might make sense to also offer an option for different subjects that kids will have at school. So things like Maths, English, whatever... My thought is that many activities will be started and resumed in a certain class-context and offering such a filter could help them to quickly find related matters. One of our fears here is the proliferation of options within this menu, which could eventually limit its usefulness, and is the reason we chose to limit to some primitive types and the installed activities. A common way to address this problem is to make the menu customizable with user-defined filters and the ability to remove unneeded filters (but keep the option to restore them later). Google mail is an example, where users can create their own tags and set filters to apply them automatically. The usual alternative is folders, as in Moodle. One can imagine that the subject of an activity is actually subjectively defined, and even when it's relatively clear, we might wind up with some for each of math, geometry, trigonometry, algebra, etc. To make a similar functionality available, though, we've chosen to allow developers to supply a list of tags within the .info file for any given activities, which could include several subject related words, as well as more abstract or general terms like game, simulation, or language. We hope that the ability to search by broad terms such as math or games will then turn up a list of appropriately related activities. Having just typed this and then reviewing the wiki, I notice that this part of the spec doesn't appear to be there yet! Can those familiar with this respond about the presence or absence of this capability? If this isn't there, it should get a ticket. It should be a pretty straightforward addition and simple to implement, it seems. anytime: Here it might make sense to add more informal filters such as 5 grado, 2nd semester or something along these lines. This one is actually much harder to do in a general way. We chose, on purpose, to treat time in the relative sense with respect to the Journal. Instead of seeing a story you wrote on November 28, 2007 you might find a story you wrote 3 months ago. This approach was chosen, in a sense, to internationalize (or perhaps simply generalize) the Journal with respect to time, so that school systems with widely different schedules (some might have class daily for one of every 3 months, for instance) can all take advantage of it. Of course one could also argue that such information could be explicitly added via the tags but I think a more implicit mechanism could potentially make more sense. You can see how, in the former case, the tag model is still implicit, in a sense, when installing an activity. In the latter case, I don't see any good way other than explicit tagging that doesn't have additional UI overhead/management to function. I'm open to ideas here. Thanks for your feedback! - Eben ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Journal: two quick suggestions
On Thu, Feb 28, 2008 at 3:11 PM, Edward Cherlin [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 11:41 AM, Eben Eliason [EMAIL PROTECTED] wrote: while toying around with the Journal today I had two ideas about the anything and anytime filter functions: Both interesting ideas... anything: Apart from offering activities and file-types as filter-options I'm thinking that it might make sense to also offer an option for different subjects that kids will have at school. So things like Maths, English, whatever... My thought is that many activities will be started and resumed in a certain class-context and offering such a filter could help them to quickly find related matters. One of our fears here is the proliferation of options within this menu, which could eventually limit its usefulness, and is the reason we chose to limit to some primitive types and the installed activities. A common way to address this problem is to make the menu customizable with user-defined filters and the ability to remove unneeded filters (but keep the option to restore them later). Google mail is an example, where users can create their own tags and set filters to apply them automatically. Indeed. The implied hypothetical at the end of my response alluded to the fact the almost anything is possible, assuming you add additional UI/management tools, but we're trying to find a balance between functionality and management overhead. I'm using Gmail to write this, and their system does work pretty well, but naturally has an entire screen dedicated to both creating labels and assigning filters. We've also discussed the possibility of adding saved searches or the like (there are 15 names for this basic idea...) in the future, but there is a lot of basic functionality left to add before we add this form of meta-functionality. Perhaps the What list is the appropriate place for these saved filters to live, eventually. Thanks for offering that idea. - Eben The usual alternative is folders, as in Moodle. One can imagine that the subject of an activity is actually subjectively defined, and even when it's relatively clear, we might wind up with some for each of math, geometry, trigonometry, algebra, etc. To make a similar functionality available, though, we've chosen to allow developers to supply a list of tags within the .info file for any given activities, which could include several subject related words, as well as more abstract or general terms like game, simulation, or language. We hope that the ability to search by broad terms such as math or games will then turn up a list of appropriately related activities. Having just typed this and then reviewing the wiki, I notice that this part of the spec doesn't appear to be there yet! Can those familiar with this respond about the presence or absence of this capability? If this isn't there, it should get a ticket. It should be a pretty straightforward addition and simple to implement, it seems. anytime: Here it might make sense to add more informal filters such as 5 grado, 2nd semester or something along these lines. This one is actually much harder to do in a general way. We chose, on purpose, to treat time in the relative sense with respect to the Journal. Instead of seeing a story you wrote on November 28, 2007 you might find a story you wrote 3 months ago. This approach was chosen, in a sense, to internationalize (or perhaps simply generalize) the Journal with respect to time, so that school systems with widely different schedules (some might have class daily for one of every 3 months, for instance) can all take advantage of it. Of course one could also argue that such information could be explicitly added via the tags but I think a more implicit mechanism could potentially make more sense. You can see how, in the former case, the tag model is still implicit, in a sense, when installing an activity. In the latter case, I don't see any good way other than explicit tagging that doesn't have additional UI overhead/management to function. I'm open to ideas here. Thanks for your feedback! - Eben ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Read ETexts Activity
Mr. Simmons,
I regret I have not seen your hosting request until now because the
subject line under which you submitted it did not indicate that it was
such a request. The usual way of requesting a hosting via the devel
list would be to submit it with a subject line such as, Activity
hosting application: Read.
Now that I have seen your request, I am still as yet unable to process
it as you omitted your ssh public key from your application, listing
? instead.
Your application as I have seen it follows:
1. Project name : Read ETexts Activity
2. Existing website, if any : None
3. One-line description : A simple Python Activity for reading
Gutenberg etexts
4. Longer description : This will be a fairly trivial activity that allows
: paging through Gutenberg etexts. It will support
: reading text files (loaded from a USB device) or
: Zip files containing a single text file (which is
: the easiest format to download to the
Journal using
: the Browse activity). It will have a
user interface
: quite similar to the Read activity, and
will support
: most of the functions of that activity except it
: will support plain text files instead of PDFs.
5. URLs of similar projects : http://wiki.laptop.org/go/Read
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URLE-mail
- --
#1 jdsimmons James Simmons ?
ja.simmons at sbcglobal.net
#2
#3
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
main tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[ ] A separate mailing list, projectname-git, should be created for commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Translation
[X] Set up the laptop.org Pootle server to allow translation
commits to be made
[ ] Translation arrangements have already been made at ___
12. Notes/comments: Since the toolbar will be adapted from the Read
toolbar I should
be able to use the same translations. Also, since the activity
will be simple
and entirely in Python it might be good sample code for new
Activity developers
to look at. The memory requirements of the Activity will be very
low, because
I'm building a list of pointers to where each page begins rather than storing
the document in memory.
---
Henry
Re: Is read_file() always called after an activity __init__?
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
Regarding project and activity hosting requests
I've recently join olpc as sysadmin. I've been going through trying to catch up with the hosting requests but there are probably several which have been pending which I've missed. It would be very helpful in the future if hosting requests could be cc:ed to [EMAIL PROTECTED] as that will open a ticket on our internal ticket system for me. I will then watch the list talk regarding the application for about a week and if there is no major objection will go ahead and create the account and repository. This will help reduce the chance of applications going missing or unfilled for prolonged periods. I will see about updating the wiki page and application accordingly. --HH. [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
OK, put like this, I agree with you. We can burn 12 bytes to save a flag day conversion; we will already have saved a ton of bytes as it is; 12 bytes is no more than a 10% improvement on top - Jim On Thu, 2008-02-28 at 21:27 +0200, Morgan Collett wrote: Ivan Krstić wrote: On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote: actually we are normally using b64 encoding so that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the TXT record. But _why_ are we encoding at all? TXT RDATA is one or more character strings, which are each a length octet followed by up to 255 arbitrary characters treated as a binary string. Am I misremembering the RFC? I made this comment on #6572 but perhaps it's worth repeating here to a wider audience: Not base64 encoding the key makes current builds fail to get the buddy properties due to a D-Bus issue that needs a workaround. This means you don't see any buddies in mesh view, although they can see you. So if we stop base64 encoding, we lose interoperability with the existing builds and need a flag day to upgrade. This is to save 12 bytes. Is that worth it? Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project name : Moon is created
Mon Feb 25 18:47:03 EST 2008, Gary C Martin wrote: 1. Project name : Moon Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/activities/moon Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Semi-successful Bayer-mode capture from internal camera
Are you using gstreamer or are you just accessing the camera with v4l? If you do not change the parameters V4L will just use the current settings that were set by the last program to use it. -Peter Benjamin M. Schwartz wrote: HUGE BUG: 1. After each reboot YOU MUST OPEN Record (or any other program that uses gstreamer to access the camera) BEFORE RUNNING bayertest.py. Otherwise, your images will be squished into the left half of the field. I have no idea why. It's pretty weird. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Google Summer of Code and OLPC
Last year OLPC mentored a couple of GSoC projects - as documented at http://wiki.laptop.org/wiki/OLPC_Google_Summer_of_Code - I think we could have a lot more projects. This year, GSoC is starting early, so we should be getting in motion asap. From the School Server side of things, there's a lot to do, and many of those tasks can be broken down in small steps that can be tackled by a GSoC student. I would like to setup a few tasks there for OLPC, and I am prepared to mentor a few well-picked students. I have mentored students for the Moodle project last year, and that had excellent results. The moodle team is already on the move preparing things for their GSoC 2008, that's how I caught wind of the early start ;-) cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Semi-successful Bayer-mode capture from internal camera
On Thu, 2008-02-28 at 16:25 -0800, Peter Krenesky wrote: Are you using gstreamer or are you just accessing the camera with v4l? If you do not change the parameters V4L will just use the current settings that were set by the last program to use it. -Peter I'm using pyvideograb, which is based on the v4l2 example code. This may represent a bug in that code. I am not sure how consistent this behavior really is. I intend to switch to gstreamer once OLPC upgrades to a version of gstreamer that supports Bayer mode (bug #4580) --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: School Server Architect
This is great news. Great decision to choose Martin. Bryan Date: Thu, 28 Feb 2008 01:25:57 -0500 From: John Watlington [EMAIL PROTECTED] Subject: School Server Architect To: server-devel [EMAIL PROTECTED] Cc: devel devel@lists.laptop.org, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm extremely pleased to announce that Martin Langhoff will be joining OLPC, taking the position of School Server Architect, starting officially around March 15th. Martin is currently one of the lead developers of Moodle --- a FOSS Course Management System for online learning (http://moodle.org/), although he has contributed to a number of other FOSS projects. Most of his last 10 years of work is well indexed by Google. Interesting keywords to try include mod_perl, GIT, Midgard, Arch (or GNU Arch), Moodle, OSCOM, metadata, dublin core, performance, Eduforge, Elgg, e-Prints, Mahara, PostgreSQL, Debian, TWIG, Ubuntu. He will continue to reside in New Zealand. He's fluent in English and Spanish, and can speak some Portuguese, Catalan, Italian and German. I will continue to work on the School Server, but will increasingly focus on the hardware, as we renew our efforts to provide low power, environmentally robust servers for rural schools. It is also time to begin work on the next generation of laptop hardware. John Watlington Hardware Architect ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
