Hosting request: epaati
1. Project name : E-Paati (unix: epaati)
2. Existing website, if any : our blog -- relevant entries:
http://nepal.ole.org/home/?q=node/73
http://nepal.ole.org/home/?q=node/90
http://nepal.ole.org/home/?q=node/102
3. One-line description : Squeak-based classroom learning activities.
4. Longer description : E-Paati is a collection of learning activities
: written in Squeak/Etoys and tailored specifically
: to implement the official Nepali curriculum.
: E-Paati is a joint project between Open Learning
: Exchange Nepal and the Department of Education.
5. URLs of similar projects : Tell us if you know some! :-)
6. Committer list
Username Full name SSH2 key URLE-mail
- --
#1 lukego Luke Gorrie
http://fresh.homeunix.net/~luke/id_rsa.pub [EMAIL PROTECTED]
#2 surendra Surendra Sedhai (below) [EMAIL
PROTECTED]
surendra's public key:
ssh-rsa
B3NzaC1yc2EBIwAAAQEAx9Cr2tZ1XeE6JzAdVmm3mL8dCioUcLJoWfBuJQSJaYpignLcqunPu94O7mKvJMLp+KyKDzXh9bIIwPK/ZsMdUtcPHFzv0mphJhmnkuUJcZzuv7Nk7a9t+kka0I00ZKrGDqN195JiXnNf9IfBVS6IsNGzAVNQ7EMKP9PIB4dOmqnZ0g5HHPJGj4yI9L/xfuzh4nabgycUB1Xgv2FRhGDBKFi7lAJtmLg3W/n6z/A7SUaIjbJDRLDhdZZk41ZKXNA2RUN8QHdFkPLXRfMRsqlbCWHPXLCEY2+0t4B4S0aOdu68x72fD6i2ejp4AiUw5JHXDLWGyg0oMvZbXsp4H8JNyw==
[EMAIL PROTECTED]
7. Preferred development model
SVN repository preferred (as Etoys has). If this is not possible
then we will use a server of our own for the repository. (We are
primarily storing binary data - Squeak Projects - and we don't want
to use GIT for this.)
8. Set up a project mailing list:
[X] No
9. Commit notifications
[X] No commit notifications, please
10. Shell accounts
One shell account so that we can publish an activity bundle for
Joyride.
11. Translation
[ ] Set up the laptop.org Pootle server to allow translation commits to be
made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
How to handle translation is under discussion with the Etoys guys
so we're not requesting Pootle at this time.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New update.1 build 659
On Dec 18, 2007, at 11:55 , Dennis Gilmore wrote: On Tuesday 18 December 2007, Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/update.1/build659/ The url is http://pilgrim.laptop.org/~pilgrim/olpc/streams/update. 1/build659/ Ah, one more script where I need to special-case update.1 ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
John Richard Moser wrote: I just got my OX laptop (hopefully some kid gets the other one soon... or not), and noticed it's slow and kind of buggy. I think I'll get a $25 4GB SD card for a SWAP area... I should run oprofile too, and have it write to the SD card. I understand what an interpreted language like Python does to the CPU but it shouldn't be this bad... it's only going to be like 100 times slower? An actual interpreter will... - Put pressure on the data cache as its code grows - ... but keep the actual interpreter (code) in cache better - Use a relatively large chunk of data for a look-up table - ... or use some convoluted and hard to maintain code - ... or optimally, a look-up table to start the decoding process, if like a CPU bytecode interpreter (Java, CIL) it has an insn + address mode + data (not QUITE optimal for Python, but maybe since simple addition and call happens) - Wind up doing what can easily become a multi-hundred-cycle decoding process for each executed bytecode insn It would be interesting to know whether there are hot spots in the interpreter and whether the interpreter is the major consumer of processor time. In early experiments there were some drawing routine in X that was a hotspot: http://lists.laptop.org/pipermail/devel/2007-March/004163.html http://lists.laptop.org/pipermail/devel/2007-March/004165.html Python rewrites to bytecode (good, interpreting text is slow! Multiple parsing!) but a lot of the main function calls in the API should be C, not Python (taking some of the pressure off). This means Python should be doing a lot of logic in native space, rather than interpreting a lot (unlike Java, which had its whole library written in Java...) I suggest taking a look at PyPy for Python, which will dynamic recompile Python to native code and likely give some good performance benefits. I really can't stand JIT compilation and would prefer something that takes advantage of Mono's own facilities, to centralize the effort in the JIT at least (Mono has nice stuff), but IronPython is Microsoft Permissive License which is not OSI approved. As for real solutions, I want to profile things and see where they're hanging. I may need a Python profiler too, to get a look inside the Python code and see if some functions there are also bad; oprofile will tell me if Python itself is spending an ungodly amount of time in its decoder functions but that's it. I haven't tried it recently on XO machine, but python has some built in profiling: http://lists.laptop.org/pipermail/devel/2007-March/004401.html http://wiki.laptop.org/go/Sugar_Performance -Will ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
John Richard Moser wrote: I just got my OX laptop (hopefully some kid gets the other one soon... or not), and noticed it's slow and kind of buggy. I think I'll get a $25 4GB SD card for a SWAP area... I should run oprofile too, and have it write to the SD card. I understand what an interpreted language like Python does to the CPU but it shouldn't be this bad... it's only going to be like 100 times slower? An actual interpreter will... - Put pressure on the data cache as its code grows - ... but keep the actual interpreter (code) in cache better - Use a relatively large chunk of data for a look-up table - ... or use some convoluted and hard to maintain code - ... or optimally, a look-up table to start the decoding process, if like a CPU bytecode interpreter (Java, CIL) it has an insn + address mode + data (not QUITE optimal for Python, but maybe since simple addition and call happens) - Wind up doing what can easily become a multi-hundred-cycle decoding process for each executed bytecode insn Python rewrites to bytecode (good, interpreting text is slow! Multiple parsing!) but a lot of the main function calls in the API should be C, not Python (taking some of the pressure off). This means Python should be doing a lot of logic in native space, rather than interpreting a lot (unlike Java, which had its whole library written in Java...) I suggest taking a look at PyPy for Python, which will dynamic recompile Python to native code and likely give some good performance benefits. I really can't stand JIT compilation and would prefer something that takes advantage of Mono's own facilities, to centralize the effort in the JIT at least (Mono has nice stuff), but IronPython is Microsoft Permissive License which is not OSI approved. As for real solutions, I want to profile things and see where they're hanging. I may need a Python profiler too, to get a look inside the Python code and see if some functions there are also bad; oprofile will tell me if Python itself is spending an ungodly amount of time in its decoder functions but that's it. I don't have my physical unit yet, but I too am interested in profiling and performance tuning. Unfortunately I have no Python tuning experience so I can't be of much help at the moment. I do have a virtual ship2, running on a 2.2 GHz Athlon64 X2, but that of course is cheating. :) Oprofile is a bit tough to work with -- it makes you install a whole bunch of GUI libraries just to get at the low-level profiling stuff. And the kernel needs to be rebuilt with the right options -- I don't know if the OLPC kernel does so. So for now, I think you'll probably be better off with lower-level command-line tools. I know top is there, but as far as I'm concerned the one must-have package is sysstat. sysstat is a work of pure genius -- it started out as a Linux re-implementation of sar and iostat, but it is much more than that now. Once I get my physical unit, I'll be looking at things in some detail. I'm guessing that adding swap isn't going to help you. If you're memory bound, the solution is to stop activities that you aren't using, not forcing the kernel to move stuff in and out of RAM. top will tell you. Open a terminal window and type top. At the top of the display you'll see memory used, free, cached, etc. There's a keystroke that will sort processes by their resident set size. Type h to get a help menu. If I get a chance tonight, I'll fire up a bunch of activities in my virtual XO and see what it does when it runs out of RAM. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
WPA anomalies in recent Joyride builds
I use WPA-PSK (WPA personal) at home, and I've noticed anomalies. One of the big ones is that it keeps re-prompting for the passphrase (this is with Joyride 1438), and tearing-down the association. I looked at /var/log/messages while this was going on, and it seems like it starts the association logic, puts up the password prompt, and then times out the association attempt after 8 seconds--which typically isn't enough time to type in the passphrase! It turns out that NetworkManager has a wired-in 8 second timer for re-association attempts, and 20 seconds for initial association attempts. I'm not sure how this seems to work OK on a regular Fedora system--which is using almost the same version of NetworkManager. It's possible that the password-prompting happens before we go into the timer-controlled region of the state machine--have we mucked with this at all? Is the password dialog one of our own, or just a standard one with Sugar decorations? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
M. Edward (Ed) Borasky wrote: I don't have my physical unit yet, but I too am interested in profiling and performance tuning. Unfortunately I have no Python tuning experience so I can't be of much help at the moment. I do have a virtual ship2, running on a 2.2 GHz Athlon64 X2, but that of course is cheating. :) Oprofile is a bit tough to work with -- it makes you install a whole bunch of GUI libraries just to get at the low-level profiling stuff. And the kernel needs to be rebuilt with the right options -- I don't know if the OLPC kernel does so. So for now, I think you'll probably be better off with lower-level command-line tools. Newer versions of OProfile RPM have the gui interface split out into a separate RPM (oprofile-gui). This was done in Jun 2006. However, you appear to be correct about the oprofile kernel. $ grep OPROFILE config* config-olpc-generic:# CONFIG_OPROFILE is not set It looks like I didn't enter a tracs entry for oprofile to be enabled: http://lists.laptop.org/pipermail/devel/2007-March/004322.html -Will ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
I suggest taking a look at PyPy for Python, which will dynamic recompile Python to native code and likely give some good performance benefits. I really can't stand JIT compilation and would prefer something that takes advantage of Mono's own facilities, to centralize the effort in the JIT at least (Mono has nice stuff), but IronPython is Microsoft Permissive License which is not OSI approved. Has anyone looked at Psyco on the XO? The point is, no generic mono JIT is going to be as smart about guessing the 95% case for Python, as something written specifically for Python. Disclaimer: I have no experience to back this up. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
Hi, However, you appear to be correct about the oprofile kernel. $ grep OPROFILE config* config-olpc-generic:# CONFIG_OPROFILE is not set It is enabled in our kernel: -bash-3.2# grep OPROFILE /boot/config-2.6.22-20071204.2.olpc.9679b65c8c5ed6e CONFIG_OPROFILE=m Our kernel config lives in olpc-2.6/arch/i386/configs. Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
On 18/12/07 12:39 -0500, Chris Ball wrote: Hi, However, you appear to be correct about the oprofile kernel. $ grep OPROFILE config* config-olpc-generic:# CONFIG_OPROFILE is not set It is enabled in our kernel: -bash-3.2# grep OPROFILE /boot/config-2.6.22-20071204.2.olpc.9679b65c8c5ed6e CONFIG_OPROFILE=m Our kernel config lives in olpc-2.6/arch/i386/configs. It is indeed there - but oprofile is still having issues. It seems that the sample data that is being written out is invalid (files are filled with only zeros, as far as I can tell) , and opreport spits back errors, consistant with badly formed sample files. We need some people who understand oprofile to take a look at whats happening and diagnose it. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 661
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build661/ -xkeyboard-config.noarch 0:1.1-5.20071009cvs.olpc2 +xkeyboard-config.noarch 0:1.1-6.20071130cvs.olpc2 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Software status meeting on IRC (today, 21:00 EST Boston).
Hi, We'll be having the regular software meeting on IRC (irc.freenode.net #olpc-meeting) tonight at 9pm EST. See you there! Date/time: http://www.timeanddate.com/worldclock/fixedtime.html?month=12day=18year=2007hour=21min=0sec=0p1=43 - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1444
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1444/ -bootfw.i386 0:q2d06-0 +bootfw.i386 0:q2d07-0 -olpccontents.i386 0:1.8-0 +olpccontents.i386 0:1.9-0 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
I've been doing some Psyco test. I'll post a new blog entry about it and send the information to the ml. thanks Eduardo http://edsiper.linuxchile.cl On Dec 18, 2007 6:04 PM, John Richard Moser [EMAIL PROTECTED] wrote: Jameson Chema Quinn wrote: I suggest taking a look at PyPy for Python, which will dynamic recompile Python to native code and likely give some good performance benefits. I really can't stand JIT compilation and would prefer something that takes advantage of Mono's own facilities, to centralize the effort in the JIT at least (Mono has nice stuff), but IronPython is Microsoft Permissive License which is not OSI approved. Has anyone looked at Psyco on the XO? The point is, no generic mono JIT is going to be as smart about guessing the 95% case for Python, as something written specifically for Python. The CIL dynamic re-compiler has a well-developed optimizer and a bunch of other stuff, including an awesome garbage collector. The newer version use a compacting garbage collector IIRC; though Python might use reference counting internally (it might be better that way, but consider the interpreter itself would be in CIL and use reflection ...). It's basically Python - CIL - CIL optimizer, not Python - CIL - C# optimizer. Granted, yes, an optimizer aware of specific language ABI specifics (like classes for C++, functions and structures for C, ect) can pre-optimize and then let the lower level optimizer re-optimize the code better (I think that's how GCC does it, optimizes a Gimple tree based on language and then does a general optimization based on hardware); but a CIL reflection compiler could compile Python into an internal tree, optimize it, emit optimized CIL, and let Mono generate optimized x86 code (as in, optimize the generated x86 code). Disclaimer: I have no experience to back this up. I have fuzzy understanding of compiler internals, nothing formal and nothing really great. Ask a gcc guy and a Mono guy. Jameson -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project submission - FiftyTwo
1. Project name : FiftyTwo
2. Existing website, if any :
3. One-line description : A set of card games for the OLPC XO laptop
4. Longer description : FiftyTwo will be a set of card games for
the XO laptop,
: hopefully including games such as Hearts,
Crazy Eights,
: Solitaire, and Go Fish. Eventually,
multi-player mesh-games
: will be supported.
5. URLs of similar projects :
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 URL
E-mail
-
--
#1 kawk
[EMAIL PROTECTED]
#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:
I've set up a Wiki page here: http://wiki.laptop.org/go/Activities/FiftyTwo
I would prefer not to release my name over the internet, so I have not
included my name in the developer list.
My ssh key is attached to this e-mail.
I may have submitted this project request already, but I'm not
completely sure if it went through. Sorry if it has.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
On Dec 18, 2007, at 12:27 PM, Jameson Chema Quinn wrote: Has anyone looked at Psyco on the XO? Psyco improves performance at the cost of memory. On a memory- constrained machine, it's a tradeoff that can only be made in laser- focused, specific cases. We have not done the work -- partly for lack of time, partly for lack of sufficiently good tools -- to determine those foci. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
sudo, not su.
I'd like to draw devel@'s attention to trac bug 5537, which might land sometime soon: http://dev.laptop.org/ticket/5537 The upshot would be that, instead of logging in directly as root with no password, you would log in directly as *olpc* with no password, and then sudo to root (if you need root). Please comment in the bug if you have strong objections and/or be prepared to try logging in as 'olpc' if 'root' seems to stop working in a new build. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivan Krstić wrote: On Dec 18, 2007, at 12:27 PM, Jameson Chema Quinn wrote: Has anyone looked at Psyco on the XO? Psyco improves performance at the cost of memory. On a memory- constrained machine, it's a tradeoff that can only be made in laser- focused, specific cases. We have not done the work -- partly for lack of time, partly for lack of sufficiently good tools -- to determine those foci. Indeed. OLPC's requirements for a Python compiler or JIT are way beyond state-of-the-art. It will take at least a few more years for PyPy to be useful for OLPC. Also: 1. Many performance problems are due to design (e.g. UI waiting on IO). 2. Many computational bottlenecks will be fixable in pure Python by choosing a faster algorithm or implementation. 3. In cases where the fastest version in Python is still not fast enough, Psyco is not likely to be the best solution. See http://scipy.org/PerformancePython , where Psyco is 30% faster than Python, but 400 times slower than Pyrex, C, or C++. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHaFCkUJT6e6HFtqQRAoEkAJ9ebZWS0t2mh/kwAEgq7fGR1/ZnZwCfXUbl /hN3vvpBHVIFciQMm9SyPkY= =VrlC -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
(Note: most of this message isn't very useful probably; it's about theoretical software architecture, that nobody's going to implement, that I can't prove, that I'm not really 100% sure about. Still, if you WANT to read it, hey... remember, bad ideas sometimes get corrected by people who are smart enough to turn them into GOOD ideas) Ivan Krstić wrote: On Dec 18, 2007, at 12:27 PM, Jameson Chema Quinn wrote: Has anyone looked at Psyco on the XO? Psyco improves performance at the cost of memory. On a memory-constrained machine, it's a tradeoff that can only be made in laser-focused, specific cases. We have not done the work -- partly for It would be wise to throw out the idea of laser-focusing which engine to use. Think of memory costs for running multiple versions of Python. Then again, what IS wise? Any such system needs to efficiently use memory. I like the idea of one based on Mono since it has that whole compacting garbage collector, which (although being a cache destroyer by nature) at least shrinks down memory usage. Of course then you still have Mono on top of it, and CIL code that's been generated, and reflected, and JIT'd, which means you (again) have 2 interpreters in memory (one in CIL, one being Mono itself), and one gets dynamic recompiled (the Python one in CIL), and all the intermediary (CIL) code gets kept for later profiling and optimization... ... didn't I say before I hate the concept of JIT dynamic compilation? Interpreters just suck by nature due to dcache problems (code becomes data, effectively your instruction working set is fixed, the load doesn't go onto icache and dcache both as the program gets bigger...) and due to the fact that you have to do a LOT of work to decode an insn in software (THINK ABOUT QEMU). Interpreters for specific script languages like Python and Perl have the advantage of not having to be a general CPU emulator, so they can have instructions that are just function calls that go into native code. So execution time order: Native code // *1 JIT // *2 Specific language interpreter // *3 General bytecode interpreter // *4 Parser script interpreter // *5 *1: Native code. C, obj-C, something compiled. everything else I could mention is out of date. *2: Technically JIT is native code, but there's also extra considerations with memory use and cache pressure comes into play slightly. After the ball gets rolling it just eats more memory but cache and execution speed are fine. *3: A specific language interpreter might call a native code strcpy() function instead of have an insn for CALL that goes into a bytecode implementation of strcpy(), or having an insn for CALL that goes into a bytecode strcpy() that just sets up a binding and calls real native strcpy(). The interpreter would head straight for native land, going function foobar() gets assigned token 0x?? and I'll know what to do when I see it. *4: A general CPU interpreter is going to have to be a CPU emulator. Java and Mono count, for Java and CIL CPUs. These CPUs don't really exist but those interpreters work that way, they even have their own assembly. *5: Some script engines are REALLY FREAKING DUMB and actually send each line through a parser every time they see it, which is megaslow. These usually don't last, or just function as proof of concept until a real bytecode translator gets written to make a specific language interpreter. Maybe, MAYBE by twiddling with a JIT, you could convince it to discard generated bytecode. For example, assuming we're talking about a Python implementation on top Mono, and we can modify Mono any way we want with reasonably little effort: - Python - internal tree (let's say Gimple, like gcc) - Gimple - optimizer (Python) - Gimple (opt) - optimizer (general) - Gimple (opt) - CIL data (for reflection) - FREE: Gimple - CIL (data) - Reflection (CIL) - FREE: CIL data (for reflection) - CIL - CIL optimizer - CIL (opt) - JIT (x86) - While (not satisfied) - The annoying process of dynamic profiling - CIL (opt, profiled) - JIT (x86) - FREE: CIL NOTE: at the FREE CIL data step, we are talking about the Python interpreter freeing the CIL data that it has; Mono has now loaded a copy as CIL code, we don't need to give it to it again, we're done with it. At this point we should have: - A CIL program for a Python interpreter - A CIL interpreter (Mono) - x86 native code for the program Further, you should be able to make the Python interpreter do a number of things: - Translate any Python-written libraries via JIT on a method-for-method basis - Translate Python bindings (Python calling C) to active CIL bindings (to avoid calling back to the interpreter) - Unload most of itself when done (say, when it's been unused for about 5 minutes of execution time), save for a method that loads the Python interpreter back into memory AGAIN when a new method gets
New update.1 build 662
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build662/ -Memorize-22.xo +Memorize-24.xo --- Memorize-24 --- * Change temp folder permisson to allow activity access under rainbow * Fix the mime-type folder location -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
On Dec 18, 2007, at 6:27 PM, John Richard Moser wrote: I like to think of programs like kernels, or kernels like programs. Either way, I like to treat applications like microkernels. In the embedded scene, this may actually be critical; maybe you should think that way for the XO, in a little part. Please post a link to this list when you have (proof-of-concept) code available. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
John Richard Moser wrote: (Note: most of this message isn't very useful probably; it's about theoretical software architecture, that nobody's going to implement, that I can't prove, that I'm not really 100% sure about. Still, if you WANT to read it, hey... remember, bad ideas sometimes get corrected by people who are smart enough to turn them into GOOD ideas) Ivan Krstić wrote: On Dec 18, 2007, at 12:27 PM, Jameson Chema Quinn wrote: Has anyone looked at Psyco on the XO? Psyco improves performance at the cost of memory. On a memory-constrained machine, it's a tradeoff that can only be made in laser-focused, specific cases. We have not done the work -- partly for It would be wise to throw out the idea of laser-focusing which engine to use. Think of memory costs for running multiple versions of Python. Then again, what IS wise? Any such system needs to efficiently use memory. I like the idea of one based on Mono since it has that whole compacting garbage collector, which (although being a cache destroyer by nature) at least shrinks down memory usage. Of course then you still have Mono on top of it, and CIL code that's been generated, and reflected, and JIT'd, which means you (again) have 2 interpreters in memory (one in CIL, one being Mono itself), and one gets dynamic recompiled (the Python one in CIL), and all the intermediary (CIL) code gets kept for later profiling and optimization... ... didn't I say before I hate the concept of JIT dynamic compilation? Interpreters just suck by nature due to dcache problems (code becomes data, effectively your instruction working set is fixed, the load doesn't go onto icache and dcache both as the program gets bigger...) and due to the fact that you have to do a LOT of work to decode an insn in software (THINK ABOUT QEMU). Interpreters for specific script languages like Python and Perl have the advantage of not having to be a general CPU emulator, so they can have instructions that are just function calls that go into native code. So execution time order: Native code // *1 JIT // *2 Specific language interpreter // *3 General bytecode interpreter // *4 Parser script interpreter // *5 *1: Native code. C, obj-C, something compiled. everything else I could mention is out of date. *2: Technically JIT is native code, but there's also extra considerations with memory use and cache pressure comes into play slightly. After the ball gets rolling it just eats more memory but cache and execution speed are fine. *3: A specific language interpreter might call a native code strcpy() function instead of have an insn for CALL that goes into a bytecode implementation of strcpy(), or having an insn for CALL that goes into a bytecode strcpy() that just sets up a binding and calls real native strcpy(). The interpreter would head straight for native land, going function foobar() gets assigned token 0x?? and I'll know what to do when I see it. *4: A general CPU interpreter is going to have to be a CPU emulator. Java and Mono count, for Java and CIL CPUs. These CPUs don't really exist but those interpreters work that way, they even have their own assembly. *5: Some script engines are REALLY FREAKING DUMB and actually send each line through a parser every time they see it, which is megaslow. These usually don't last, or just function as proof of concept until a real bytecode translator gets written to make a specific language interpreter. Maybe, MAYBE by twiddling with a JIT, you could convince it to discard generated bytecode. For example, assuming we're talking about a Python implementation on top Mono, and we can modify Mono any way we want with reasonably little effort: - Python - internal tree (let's say Gimple, like gcc) - Gimple - optimizer (Python) - Gimple (opt) - optimizer (general) - Gimple (opt) - CIL data (for reflection) - FREE: Gimple - CIL (data) - Reflection (CIL) - FREE: CIL data (for reflection) - CIL - CIL optimizer - CIL (opt) - JIT (x86) - While (not satisfied) - The annoying process of dynamic profiling - CIL (opt, profiled) - JIT (x86) - FREE: CIL NOTE: at the FREE CIL data step, we are talking about the Python interpreter freeing the CIL data that it has; Mono has now loaded a copy as CIL code, we don't need to give it to it again, we're done with it. At this point we should have: - A CIL program for a Python interpreter - A CIL interpreter (Mono) - x86 native code for the program Further, you should be able to make the Python interpreter do a number of things: - Translate any Python-written libraries via JIT on a method-for-method basis - Translate Python bindings (Python calling C) to active CIL bindings (to avoid calling back to the interpreter) - Unload most of itself when done (say, when it's been unused for about 5 minutes
New joyride build 1447
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1447/ -kernel.i586 0:2.6.22-20071213.7.olpc.807beb7d0b8a49a +kernel.i586 0:2.6.22-20071218.1.olpc.e1ba84245e054ed -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
Ivan Krstić wrote: On Dec 18, 2007, at 6:27 PM, John Richard Moser wrote: I like to think of programs like kernels, or kernels like programs. Either way, I like to treat applications like microkernels. In the embedded scene, this may actually be critical; maybe you should think that way for the XO, in a little part. Please post a link to this list when you have (proof-of-concept) code available. Forth is the proof of this concept. ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: sudo, not su.
[EMAIL PROTECTED] wrote: I'd like to draw devel@'s attention to trac bug 5537, which might land sometime soon: http://dev.laptop.org/ticket/5537 The upshot would be that, instead of logging in directly as root with no password, you would log in directly as *olpc* with no password, and then sudo to root (if you need root). Please comment in the bug if you have strong objections and/or be prepared to try logging in as 'olpc' if 'root' seems to stop working in a new build. +1 Yes, I think logging in directly as root is a misfeature that should go away. Most of the other unix-derived platforms have been doing their best to kill it off or at least reduce its attractiveness... and being able to sudo is usually pretty trivial. --elijah ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Yeah ... sudo is more secure than su. In fact, some systems, for example, the Gentoo LiveCD, scrambles the root password. So you have to do $ sudo su - and then set a password to ssh in as root. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Oprofile, swap
Jordan Crouse wrote: On 18/12/07 12:39 -0500, Chris Ball wrote: Hi, However, you appear to be correct about the oprofile kernel. $ grep OPROFILE config* config-olpc-generic:# CONFIG_OPROFILE is not set It is enabled in our kernel: -bash-3.2# grep OPROFILE /boot/config-2.6.22-20071204.2.olpc.9679b65c8c5ed6e CONFIG_OPROFILE=m Our kernel config lives in olpc-2.6/arch/i386/configs. It is indeed there - but oprofile is still having issues. It seems that the sample data that is being written out is invalid (files are filled with only zeros, as far as I can tell) , and opreport spits back errors, consistant with badly formed sample files. We need some people who understand oprofile to take a look at whats happening and diagnose it. Jordan Uh ... you're from AMD? Can you get CodeAnalyst to work on an XO? That would be $^%$ awesome! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
