Re: Toolchain-VM for C/Vala programs?
Hi, I am interested too in this project, but I would suggest using a readonly base image and an additional writable to decrease the download size while development until to a stable. Is this possible? Thanks Lothar Am 30.06.2009 um 14:44 schrieb Christ van Willegen: > On Thu, Jun 25, 2009 at 3:20 PM, Aapo > Rantalainen wrote: >> If I make VirtualBox virtualmachine containing installed om- >> toolchain, >> where I should upload it? It is sure that somebody wants something >> else than VirtualBox, but this it only what I can offer. > > That would be great, I've been trying _forever_ to get a reasonably > small virtual host 'together' for building OM apps! It would make app > starting a bugfixing so much easier! > > Regards, > > Christ van Willegen > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Wed, Jul 1, 2009 at 7:44 AM, W.Kenworthy wrote: > 1/2 an hour is no problem (often use GPS daily on the way to work - coz > I can :) - longest drive was ~5 hours, which needed power at about the > 3.5 hour mark - was 6 months ago and it should go longer now. fsck does > take an hour or so, but i only do it once a month as programmed > maintenance - rarely finds an error UNLESS there has been a nasty crash > which is rather rare these days (shr-unstable, built by myself). Yes it > sometimes used to happen that I get a call or SMS when using tangogps > and have had crashes so need to take the battery out to reset - almost > always no errors (using ext3, for at least the past two months). If you > are worried about fsck speed, put the SD card in a usb key and use a > desktop/laptop to fsck it - much faster. When I use gps, I dont have laptop > > Try reducing the clock speed as I suggested - thats the most likely > cause of your problems. Your symptoms sound very like what happens to > me (on any SD card) when running with the standard clock speed. While > the speed drop is ~1/3, its unnoticeable in my usage pattern. Also make > sure that the card is mounted async - sync is dismally slow and any gain > in stability is lost because transfers are exposed as they take much > longer to complete. Swap will also add a degree of reliability in > normal use, but if using a lot of swap, the phone can slow down > dramaticly as thrashing starts - manually flushing swap gets things back > on an even keel. Yepp, but the problem only occurs with tangogps > > There are some "tar" based compressed file systems out there (when > tested, ~3.3gbytes of png's will compress down to ~550Mbytes as tar.bz2, > but you need a lot of cpu cycles to extract) and they are not reliable > at all. the problem is that OSM maps are either png (lots of small > files) or vector based which adds a real and critical processing load as > seen by navit. I actually symlink similar files (many are just > ocean/desert - South Western Australia) and symlinks less than a certain > size get stored in the inodes (fast symlinks) so dont take any disk > space - the problem then becomes that ext3 has an upper limit to > inodes :( I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. > In short, you are barking up the wrong tree if you think that large > numbers of files are causing your problem. Maybe. But if I wouldnt have any problem with those crash, I would like to see implemented. If nothing else, the inode usage. (for me, the fast copying to sd card). Im extra-paranoid about this kind of file-access. I dont like to stressing the filesystem to the limit. I have this experience in normal computer usage: Compressing a directory into zip and copyying a single file to the pen drive, takes several time less, then copying the directory as-is. If you ever tried a pendrive like 16 or 32GB you know what Im talking about. And it is independent of OS (windows vs. linux), and the filesystem of the pendrive (vfat vs. ext2) I didnt brother to reinstall tangogps since a month, because exactly of the above issue. To bad it seems that Im the only one in this boot. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: DNS fix disappears on android beta 7
> Since the init.rc goes back to it's original state upon reboot, there is > nothing to be undone. sounds a bit suse-like ... maybe you have to enter those changes into a specific config file/database (using a config tool?) from which android creates these files upon boot? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain-VM for C/Vala programs?
On Thu, Jun 25, 2009 at 5:32 PM, Marcel wrote: > Am Donnerstag, 25. Juni 2009 15:20:54 schrieb Aapo Rantalainen: >> If I make VirtualBox virtualmachine containing installed om-toolchain, >> where I should upload it? It is sure that somebody wants something >> else than VirtualBox, but this it only what I can offer. > > That'd be great... Maybe we can dump it somewhere on the OM servers that > host the distro images? I *have* a small server vm I could use for > hosting, but it's located behind a consumer dsl line so the upstream is > limited to 80kbps. :/ I would be interested in illume keyboard modification (recompile the keyboard). Is it possible? Is e installed? Setting up a working (compilable) openembedded toolchain takes multiple day of works. So Im definietly interested in it. So generating .ipkg package, that would be ready to install on the phone. Laszlo ps: Thats why I love python so much. I modify the files on the phone, and I can try my result straight on the way. Nice for little bugfixes, improvements. I even developed .edc files, without any knowledge about e, and on my laptop I didnt installed e at all. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] bluetooth keyboard - key presses not making it to X
On Wed, Jul 1, 2009 at 1:18 AM, Tim Abell wrote: > I hadn't realised till now that SHR is the main focus of development, so I > have just reflashed with that and will try again. In my opinion SHR is more focused on bleeding edge, and trying every new in their distro, while om2009 (which is community based too in these days) are focusing in the stable direction. So I see om2009 as a stable version of SHR, with only the base necessary apps. I think shr and om2009 is not competing with each other, but focusing on two different directions (stable vs. bleeding edge). There is only a bit difference still. SHR is coming with their own set of phone applications, while om2009 pushing paroli. But under the hood, there is lot of similarity between shr and om2009. I would like to see paroli properly packaged on shr, and an easy ability to switch between shr phone suite, and paroli (from end-user point of view). But trying out the newest glamo and such, shr is the best candidate. Best regards, Laszlo ps: I only wanted to say, that there are development in om2009 distro too;-D ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Why is it so slow ?
Hello Guys, I've purchased recently a new freerunner, and I'm really surprised until about the slowlyness of the interface. Comparing it to an iphone, the GUI is really very slow, using Android, or openmoko distribution. Could anyone explain why and if this will be ever better one day (more software optimizations...) Thanks, Omar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wed, Jul 1, 2009 at 5:39 PM, Omar Belkhodja wrote: > Hello Guys, > > I've purchased recently a new freerunner, and I'm really surprised > until about the slowlyness of the interface. Comparing it to an > iphone, the GUI is really very slow, using Android, or openmoko > distribution. Could anyone explain why and if this will be ever better > one day (more software optimizations...) The concept here seems to be relative, may you try hackable:1 and report if you feel it slow? regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
there's a bunch of distributions out there with different guis. as long as you don't tell us, what you are using and what exactly you mean by "slow", there's not much to tell. always prefix the subject with the name of the distribution liek [android] or [om2009.x]. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
only slowness that annoys me is application load time in shr. everything else is a ok. On Wed, Jul 1, 2009 at 8:46 AM, arne anka wrote: > there's a bunch of distributions out there with different guis. > as long as you don't tell us, what you are using and what exactly you mean > by "slow", there's not much to tell. > > always prefix the subject with the name of the distribution liek [android] > or [om2009.x]. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New case (was Re: Freerunner's Future)
Werner has the ability to embed the debug board "on board" On Tue, Jun 30, 2009 at 7:56 PM, Jianming.Liu wrote: > > Hi, I have posted the symbols and schematic of the debug board v3 in the > list > of GTA02-Core, and I think that could be a part of the GTA02-Core, or we > could start a new debug board project? Thank you. > > Werner Almesberger wrote: > > > > [ Let's give threads that change direction a clearer name than just > > "Freerunner's Future" ] > > > > Fabian Sch?lzel wrote: > >> I'm not an engineer, but a draftsman, so I could also help with the > >> mechanical design and modeling of the case and other things related > >> to the project. > > > > Great ! I think "redoing" the GTA02 case should be a project on its > > own, independent from gta02-core or such. > > > > There are no technical dependencies anyway - gta02-core will fit > > into any GTA02 case and a new GTA02 case can host any GTA02 board. > > > > Two considerations: > > > > I think just making a case equivalent to the existing one would be > > an interesting enough task on its own, without adding any changes > > that aren't motivated by feasibility (machinability, etc.) alone. > > > > Ideally, someone who's already experienced the whole process from > > design to prototype production getting done would take care of > > coordinating that project. > > > > - Werner > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > -- > View this message in context: > http://n2.nabble.com/Freerunner%27s-Future-tp3012885p3186744.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: > only slowness that annoys me is application load time in shr. > everything else is a ok. > Scrolling is wy to slow too... This is the case on nearly all apps on om200x and SHR. Especially a full SHR Messages inbox takes forever to move the list around. The only exceptions I know are canola that feels a bit smoother and Neon that scrolls really fast. Cheers, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On 7/1/09, Michael Zanetti wrote: > On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: >> only slowness that annoys me is application load time in shr. >> everything else is a ok. >> > > Scrolling is wy to slow too... This is the case on nearly all apps on > om200x and SHR. Especially a full SHR Messages inbox takes forever to move > the > list around. The only exceptions I know are canola that feels a bit smoother > and Neon that scrolls really fast. > > Cheers, > Michael In SHR just use X11-16 engine (ELM_ENGINE=x11-16). It'll be *much* better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
This has been discussed to death on various mailing lists -- if you're really interested in the details, please dig into the archives. The bottom line though is: The iPhone has a smaller resolution to fill, combined with a faster processor (including a very performant graphics accelerator). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
have yet to install neon have we? On Wed, Jul 1, 2009 at 10:44 AM, Michael Zanetti wrote: > On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: >> only slowness that annoys me is application load time in shr. >> everything else is a ok. >> > > Scrolling is wy to slow too... This is the case on nearly all apps on > om200x and SHR. Especially a full SHR Messages inbox takes forever to move the > list around. The only exceptions I know are canola that feels a bit smoother > and Neon that scrolls really fast. > > Cheers, > Michael > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wednesday 01 July 2009 19:48:55 Sebastian Krzyszkowiak wrote: > On 7/1/09, Michael Zanetti wrote: > > On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: > >> only slowness that annoys me is application load time in shr. > >> everything else is a ok. > > > > Scrolling is wy to slow too... This is the case on nearly all apps on > > om200x and SHR. Especially a full SHR Messages inbox takes forever to > > move the > > list around. The only exceptions I know are canola that feels a bit > > smoother and Neon that scrolls really fast. > > > > Cheers, > > Michael > > In SHR just use X11-16 engine (ELM_ENGINE=x11-16). It'll be *much* better. I've tried this... Setting SOFTWARE_16 in illume settings affects only illume itself. All SHR apps still scoll slow as always. How do I set this option for all ELM apps? Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wednesday 01 July 2009 19:56:20 jeremy jozwik wrote: > have yet to install neon have we? > http://www.opkg.org/package_62.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
yes i know what neon is. have you tried it was the question. the scrolling speed is one of the best for the freerunner On Wed, Jul 1, 2009 at 11:11 AM, Michael Zanetti wrote: > On Wednesday 01 July 2009 19:56:20 jeremy jozwik wrote: >> have yet to install neon have we? >> > > http://www.opkg.org/package_62.html > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On 7/1/09, Michael Zanetti wrote: > On Wednesday 01 July 2009 19:48:55 Sebastian Krzyszkowiak wrote: >> On 7/1/09, Michael Zanetti wrote: >> > On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: >> >> only slowness that annoys me is application load time in shr. >> >> everything else is a ok. >> > >> > Scrolling is wy to slow too... This is the case on nearly all apps >> > on >> > om200x and SHR. Especially a full SHR Messages inbox takes forever to >> > move the >> > list around. The only exceptions I know are canola that feels a bit >> > smoother and Neon that scrolls really fast. >> > >> > Cheers, >> > Michael >> >> In SHR just use X11-16 engine (ELM_ENGINE=x11-16). It'll be *much* better. > > I've tried this... Setting SOFTWARE_16 in illume settings affects only > illume > itself. All SHR apps still scoll slow as always. How do I set this option > for > all ELM apps? > > Thanks, > Michael Just set ELM_ENGINE env variable to x11-16. You must know about /etc/profile, didn't you? ;> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
2009/7/1 Sebastian Krzyszkowiak > > Just set ELM_ENGINE env variable to x11-16. You must know about > /etc/profile, didn't you? ;> > > Why isn't it set by default in SHR? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On 7/1/09, Michal Brzozowski wrote: > 2009/7/1 Sebastian Krzyszkowiak > >> >> Just set ELM_ENGINE env variable to x11-16. You must know about >> /etc/profile, didn't you? ;> >> >> > Why isn't it set by default in SHR? > Cause with default theme it makes everything ugly. (but that's not my point. I would be for setting it as default) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wednesday 01 July 2009 20:27:26 Sebastian Krzyszkowiak wrote: > On 7/1/09, Michael Zanetti wrote: > > On Wednesday 01 July 2009 19:48:55 Sebastian Krzyszkowiak wrote: > >> On 7/1/09, Michael Zanetti wrote: > >> > On Wednesday 01 July 2009 17:52:20 jeremy jozwik wrote: > >> >> only slowness that annoys me is application load time in shr. > >> >> everything else is a ok. > >> > > >> > Scrolling is wy to slow too... This is the case on nearly all apps > >> > on > >> > om200x and SHR. Especially a full SHR Messages inbox takes forever to > >> > move the > >> > list around. The only exceptions I know are canola that feels a bit > >> > smoother and Neon that scrolls really fast. > >> > > >> > Cheers, > >> > Michael > >> > >> In SHR just use X11-16 engine (ELM_ENGINE=x11-16). It'll be *much* > >> better. > > > > I've tried this... Setting SOFTWARE_16 in illume settings affects only > > illume > > itself. All SHR apps still scoll slow as always. How do I set this option > > for > > all ELM apps? > > > > Thanks, > > Michael > > Just set ELM_ENGINE env variable to x11-16. You must know about > /etc/profile, didn't you? ;> > oops... I was looking for an elm config file... Thanks! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wed, Jul 1, 2009 at 5:44 PM, Nicola Mfb wrote: > On Wed, Jul 1, 2009 at 5:39 PM, Omar Belkhodja > wrote: >> Hello Guys, >> >> I've purchased recently a new freerunner, and I'm really surprised >> until about the slowlyness of the interface. Comparing it to an >> iphone, the GUI is really very slow, using Android, or openmoko >> distribution. Could anyone explain why and if this will be ever better >> one day (more software optimizations...) > > The concept here seems to be relative, may you try hackable:1 and > report if you feel it slow? Now the long answer: Freerunner is not only a smartphone, it's a revolutionary object that waked up a lot of peoples to achieve the idea of a linux based free phone. You may think it as a not so fast device that show the "reference implementation" of what is going in that direction. For that reason software is in a "quick prototype" phase and to have a fast grow, a lot of developers adopted python and in general prefers ideas instead of waste time in performance issues. For the same reason you may see a lot of small tools instead of a big and memory resident and fast phone application. Again for the same reason you see, in the case of SHR for example, python apps interacting with python ophonekitd, interacting with python framework. This phase is quite terminating and things are going to be faster with migration to c, vala etc. E toolkits (or at least how them are used) seem not target the Freerunner, but I think it's better to have them slow than boring authors to use faster but "not future" toolkits. We cannot stop this if we want the next linux open and faster device be modern and compete with other proprietary devices. That's the real reason that bring me to say "slow it's relative". If you want, you may use some "legacy" fast solutions as QtE where the "prototyping" phase has terminated some times ago :) Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Wednesday 01 July 2009 20:25:43 jeremy jozwik wrote: > yes i know what neon is. have you tried it was the question. the > scrolling speed is one of the best for the freerunner > Yes, I meant that as an example for an app with very great scrolling speed. Cheers, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New archive file format (was: [omgps] collect feature requests)
> I dont want to compress at all. The 118MB for me is perfect. I only > want to pack the directory into a file. But not compressing. > Im thinking about tar or ar. Hi! I have studied all the available archive and compression options. Most notably tar[1][2][4][6] and zip file format [3]. They are the most common archive types. I read also ar (dpkg and ipkg uses it) and cpio format. So I did my homework, and made some researches. Our requirements: - no compression (no wasted cpu time) - random access (no slow waiting time and memory issue) - readily available module/library for easy of integrating (best: no additional package is required to install on the phone) Tar completely fail at random access, simply it lacks the table of content, so accessing the last file in the archive requires reading the whole content before it. Zip support accessing each files in the archive, although it compress the file by default. There are dar[5] and xar[7], which meets our random access criteria. However dar needs to be ported to the device, and xar is still in development (that means limited python support for example). So I wrote down the most dumb archive fileformat ever;) When I wrote the specification, I only had one goal: make it so simple, that everybody can implement it, so no need to wait for ready-made library. It is called KISS fileformat (keep it simple and stupid), the preferred extension would be filename.kiss You can read it here, I also included it (at the end of mail) for reference: http://pastebin.com/m608acaeb I think it is suitable for our map tile usage. What do you think? Best regards, Laszlo [1]: http://en.wikipedia.org/wiki/Tar_(file_format) [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) [6]: http://en.wikipedia.org/wiki/Archive_formats [7]: http://code.google.com/p/xar/ KISS archive fileformat specification: # KISS archive format (Keep It Simple and Stupid) ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content - first file contains the filenames - header: start block, end block, position of last block ## Overall file structure [header][filenames][1. file][2. file][3. file] ## [header] [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. [ header ] [ filenames ] [1. file] etc.. SB (start block): 4 byte EB (end block): 4 byte POS (position of last block): 2 byte All numbers are stored big-endian. That means most significant bit first. Example: 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) Note: The remaining part of the header block MUST be filled with zero bytes. You will always have remaining part in the block, simply each file takes 10 bytes. (512/10 = 51 and 2 bytes left) ## [filenames] UTF-8 text for each filename, delimited with '\n' byte. The directory structure is preserved too. [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. Some examples: this is a file.txt this2.tar.gz this3.html images/loller.html weird_dir/this\/files contains\/several\\ slashes.txt Special characters: '\n': You cant have '\n' character in the filename. It is preserved. (it is not supported in most filesystems anyway) '/': directory delimiter. To save directory structure. '\/': if the filename itself contains an / character '\\': if the filename itself contains a \ character ## [X. file] The file content as is. ## FAQ: Q: Why another archive format? A: Because it is the most dumb format ever;) Q: Why not tar, ar, zip, [name archive type here]? A: Short answer: widely used archive format are not suited for random access with no compression. Long answer: tar: there is no index, reading the last file of the archive requires reading the whole file before it. zip: individual files are compressed, which means: processortime xar: it would fit the requirements, but it is not widely supported, and not in every language. Q: I use X language does KISS supported there? A: The fileformat is so simple, it is intented, every programmer could implement it in "no time". Q: Does compression supported? A: No. But you can compress the whole file, just like in tar case: filename.kiss.bz2. Use it for file sharing. Q: Do advanced features (rights, symlinks, hardlinks, user/group/other) are preserved? A: No. It was not the goal of this archive. Although you can implement it, just write those informations in the first file. It is not recommended. Q: If the original file is not multiple of 512 bytes, how it will look in the archive, how many bytes will it take? A: Lets have an example. We have three files: 768bytes file, 1024 bytes, 2047 by
Re: New archive file format (was: [omgps] collect feature requests)
wow On Wed, Jul 1, 2009 at 2:20 PM, Laszlo KREKACS wrote: >> I dont want to compress at all. The 118MB for me is perfect. I only >> want to pack the directory into a file. But not compressing. >> Im thinking about tar or ar. > > Hi! > > I have studied all the available archive and compression options. > Most notably tar[1][2][4][6] and zip file format [3]. > They are the most common archive types. I read also ar (dpkg > and ipkg uses it) and cpio format. So I did my homework, and > made some researches. > > Our requirements: > - no compression (no wasted cpu time) > - random access (no slow waiting time and memory issue) > - readily available module/library for easy of integrating > (best: no additional package is required to install on the phone) > > Tar completely fail at random access, simply it lacks the > table of content, so accessing the last file in the archive > requires reading the whole content before it. > > Zip support accessing each files in the archive, although > it compress the file by default. > > There are dar[5] and xar[7], which meets our random access > criteria. However dar needs to be ported to the device, and > xar is still in development (that means limited python support > for example). > > So I wrote down the most dumb archive fileformat ever;) > When I wrote the specification, I only had one goal: > make it so simple, that everybody can implement it, > so no need to wait for ready-made library. > > It is called KISS fileformat (keep it simple and stupid), > the preferred extension would be filename.kiss > > You can read it here, I also included it (at the end of mail) > for reference: > http://pastebin.com/m608acaeb > > I think it is suitable for our map tile usage. > > What do you think? > > Best regards, > Laszlo > > [1]: http://en.wikipedia.org/wiki/Tar_(file_format) > [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html > [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html > [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers > [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) > [6]: http://en.wikipedia.org/wiki/Archive_formats > [7]: http://code.google.com/p/xar/ > > KISS archive fileformat specification: > > # KISS archive format (Keep It Simple and Stupid) > > ## General properties > - blocksize: 512 bytes > - only store filename (and directory if any) and content > - first file contains the filenames > - header: start block, end block, position of last block > > ## Overall file structure > [header][filenames][1. file][2. file][3. file] > > ## [header] > [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. > [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. > [ header ] [ filenames ] [1. file] etc.. > > SB (start block): 4 byte > EB (end block): 4 byte > POS (position of last block): 2 byte > > All numbers are stored big-endian. That means most significant bit first. > Example: > 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) > 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) > > Note: > The remaining part of the header block MUST be filled with zero bytes. > You will always have remaining part in the block, simply each file > takes 10 bytes. (512/10 = 51 and 2 bytes left) > > ## [filenames] > UTF-8 text for each filename, delimited with '\n' byte. > The directory structure is preserved too. > [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. > > Some examples: > this is a file.txt > this2.tar.gz > this3.html > images/loller.html > weird_dir/this\/files contains\/several\\ slashes.txt > > Special characters: > '\n': You cant have '\n' character in the filename. It is preserved. > (it is not supported in most filesystems anyway) > '/': directory delimiter. To save directory structure. > '\/': if the filename itself contains an / character > '\\': if the filename itself contains a \ character > > > ## [X. file] > The file content as is. > > > ## FAQ: > Q: Why another archive format? > A: Because it is the most dumb format ever;) > > Q: Why not tar, ar, zip, [name archive type here]? > A: Short answer: widely used archive format are not suited for random access > with no compression. > Long answer: tar: there is no index, reading the last file of the archive > requires reading the whole file before it. >zip: individual files are compressed, which means: > processortime >xar: it would fit the requirements, but it is not widely > supported, and not in every language. > > Q: I use X language does KISS supported there? > A: The fileformat is so simple, it is intented, every programmer > could implement it in "no time". > > Q: Does compression supported? > A: No. But you can compress the whole file, > just like in tar case: filename.kiss.bz2. Use it for file sharing. > > Q: Do advanced features (rights, symlinks, hardlinks, user/group/other) are > preserved? > A: No. It was not the goal of this archive. Although you can im
Re: New archive file format (was: [omgps] collect feature requests)
add another wow from here :o 2009/7/1 jeremy jozwik : > wow > > On Wed, Jul 1, 2009 at 2:20 PM, Laszlo > KREKACS wrote: >>> I dont want to compress at all. The 118MB for me is perfect. I only >>> want to pack the directory into a file. But not compressing. >>> Im thinking about tar or ar. >> >> Hi! >> >> I have studied all the available archive and compression options. >> Most notably tar[1][2][4][6] and zip file format [3]. >> They are the most common archive types. I read also ar (dpkg >> and ipkg uses it) and cpio format. So I did my homework, and >> made some researches. >> >> Our requirements: >> - no compression (no wasted cpu time) >> - random access (no slow waiting time and memory issue) >> - readily available module/library for easy of integrating >> (best: no additional package is required to install on the phone) >> >> Tar completely fail at random access, simply it lacks the >> table of content, so accessing the last file in the archive >> requires reading the whole content before it. >> >> Zip support accessing each files in the archive, although >> it compress the file by default. >> >> There are dar[5] and xar[7], which meets our random access >> criteria. However dar needs to be ported to the device, and >> xar is still in development (that means limited python support >> for example). >> >> So I wrote down the most dumb archive fileformat ever;) >> When I wrote the specification, I only had one goal: >> make it so simple, that everybody can implement it, >> so no need to wait for ready-made library. >> >> It is called KISS fileformat (keep it simple and stupid), >> the preferred extension would be filename.kiss >> >> You can read it here, I also included it (at the end of mail) >> for reference: >> http://pastebin.com/m608acaeb >> >> I think it is suitable for our map tile usage. >> >> What do you think? >> >> Best regards, >> Laszlo >> >> [1]: http://en.wikipedia.org/wiki/Tar_(file_format) >> [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html >> [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html >> [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers >> [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) >> [6]: http://en.wikipedia.org/wiki/Archive_formats >> [7]: http://code.google.com/p/xar/ >> >> KISS archive fileformat specification: >> >> # KISS archive format (Keep It Simple and Stupid) >> >> ## General properties >> - blocksize: 512 bytes >> - only store filename (and directory if any) and content >> - first file contains the filenames >> - header: start block, end block, position of last block >> >> ## Overall file structure >> [header][filenames][1. file][2. file][3. file] >> >> ## [header] >> [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. >> [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. >> [ header ] [ filenames ] [1. file ] etc.. >> >> SB (start block): 4 byte >> EB (end block): 4 byte >> POS (position of last block): 2 byte >> >> All numbers are stored big-endian. That means most significant bit first. >> Example: >> 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) >> 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) >> >> Note: >> The remaining part of the header block MUST be filled with zero bytes. >> You will always have remaining part in the block, simply each file >> takes 10 bytes. (512/10 = 51 and 2 bytes left) >> >> ## [filenames] >> UTF-8 text for each filename, delimited with '\n' byte. >> The directory structure is preserved too. >> [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. >> >> Some examples: >> this is a file.txt >> this2.tar.gz >> this3.html >> images/loller.html >> weird_dir/this\/files contains\/several\\ slashes.txt >> >> Special characters: >> '\n': You cant have '\n' character in the filename. It is preserved. >> (it is not supported in most filesystems anyway) >> '/': directory delimiter. To save directory structure. >> '\/': if the filename itself contains an / character >> '\\': if the filename itself contains a \ character >> >> >> ## [X. file] >> The file content as is. >> >> >> ## FAQ: >> Q: Why another archive format? >> A: Because it is the most dumb format ever;) >> >> Q: Why not tar, ar, zip, [name archive type here]? >> A: Short answer: widely used archive format are not suited for random access >> with no compression. >> Long answer: tar: there is no index, reading the last file of the archive >> requires reading the whole file before it. >> zip: individual files are compressed, which means: >> processortime >> xar: it would fit the requirements, but it is not widely >> supported, and not in every language. >> >> Q: I use X language does KISS supported there? >> A: The fileformat is so simple, it is intented, every programmer >> could implement it in "no time". >> >> Q: Does compression supported? >> A: No. But you can compress the whole file, >> just like in tar case: filename
Re: Why is it so slow ?
On Thu, Jul 2, 2009 at 4:27 AM, Sebastian Krzyszkowiak wrote: > Just set ELM_ENGINE env variable to x11-16. You must know about > /etc/profile, didn't you? ;> Just to demonstrate my lack of familiarity in this area, could someone please provide exact example of the line that needs to be added to /etc/profile cheers Denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[shr-unstable] 20090624 suspend off not really off?
list! shr-unstable issue on the table for today. i have just noticed my phone is continually going into suspend mode even though both enlightenment and shr suspends are disabled. is there something in frameworkd.confg that can kill suspend from auto happening but still allow for power menu suspending? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
I have just noticed the opposite problem, I am unable to get shr- unstable to auto suspend. Going to shr settings -> Power and using the slider for the auto suspend to try an enable it does not work, when I drag it, the slider just goes back to "disabled" no matter how many times I try it or even how long I hold it there. On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: > list! shr-unstable issue on the table for today. i have just noticed > my phone is continually going into suspend mode even though both > enlightenment and shr suspends are disabled. > > is there something in frameworkd.confg that can kill suspend from auto > happening but still allow for power menu suspending? > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
yah, i get that too :) the slider is in the off position, so i figured i would slide it on, then off and maybe its be fixed. nope. no on setting yet automatically suspends. its like magic! On Wed, Jul 1, 2009 at 5:29 PM, Adam Jimerson wrote: > I have just noticed the opposite problem, I am unable to get shr- > unstable to auto suspend. Going to shr settings -> Power and using > the slider for the auto suspend to try an enable it does not work, > when I drag it, the slider just goes back to "disabled" no matter how > many times I try it or even how long I hold it there. > On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: > >> list! shr-unstable issue on the table for today. i have just noticed >> my phone is continually going into suspend mode even though both >> enlightenment and shr suspends are disabled. >> >> is there something in frameworkd.confg that can kill suspend from auto >> happening but still allow for power menu suspending? >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
Denis Johnson schrieb: > On Thu, Jul 2, 2009 at 4:27 AM, Sebastian > Krzyszkowiak wrote: > >> Just set ELM_ENGINE env variable to x11-16. You must know about >> /etc/profile, didn't you? ;> >> > > Just to demonstrate my lack of familiarity in this area, could someone > please provide exact example of the line that needs to be added to > /etc/profile > echo ELM_ENGINE=x11-16 >> /etc/profile ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
jeremy jozwik schrieb: > yah, i get that too :) the slider is in the off position, so i > figured i would slide it on, then off and maybe its be fixed. nope. no > on setting yet automatically suspends. > > its like magic! > > On Wed, Jul 1, 2009 at 5:29 PM, Adam Jimerson wrote: > >> I have just noticed the opposite problem, I am unable to get shr- >> unstable to auto suspend. Going to shr settings -> Power and using >> the slider for the auto suspend to try an enable it does not work, >> when I drag it, the slider just goes back to "disabled" no matter how >> many times I try it or even how long I hold it there. >> On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: >> >> >>> list! shr-unstable issue on the table for today. i have just noticed >>> my phone is continually going into suspend mode even though both >>> enlightenment and shr suspends are disabled. >>> >>> is there something in frameworkd.confg that can kill suspend from auto >>> happening but still allow for power menu suspending? >>> >>> sound really crappy now, but that is one of the reasons i use unstalbe from 17th of june... its much stabler (i lost calls with latest unstbale, got some dbus is borked messages, ophonekit crashes, unpredictable suspend behavior... drained my battery a coulbe of times) but i think manual suspend is still working, although gsm was completely shot when the suspend problem ocurred but i think it might be related to this bug: http://trac.freesmartphone.org/ticket/435 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
ugh... re-flash again! i just got everything up and running well! is there some kind of wiki site describing what the shr builds are excelling and sucking at? On Wed, Jul 1, 2009 at 6:06 PM, Bernd Prünster wrote: > jeremy jozwik schrieb: >> yah, i get that too :) the slider is in the off position, so i >> figured i would slide it on, then off and maybe its be fixed. nope. no >> on setting yet automatically suspends. >> >> its like magic! >> >> On Wed, Jul 1, 2009 at 5:29 PM, Adam Jimerson wrote: >> >>> I have just noticed the opposite problem, I am unable to get shr- >>> unstable to auto suspend. Going to shr settings -> Power and using >>> the slider for the auto suspend to try an enable it does not work, >>> when I drag it, the slider just goes back to "disabled" no matter how >>> many times I try it or even how long I hold it there. >>> On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: >>> >>> list! shr-unstable issue on the table for today. i have just noticed my phone is continually going into suspend mode even though both enlightenment and shr suspends are disabled. is there something in frameworkd.confg that can kill suspend from auto happening but still allow for power menu suspending? > sound really crappy now, but that is one of the reasons i use unstalbe > from 17th of june... its much stabler (i lost calls with latest > unstbale, got some dbus is borked messages, ophonekit crashes, > unpredictable suspend behavior... drained my battery a coulbe of times) > but i think manual suspend is still working, although gsm was completely > shot when the suspend problem ocurred > but i think it might be related to this bug: > http://trac.freesmartphone.org/ticket/435 > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
On Thu, 2009-07-02 at 03:01 +0200, Bernd Prünster wrote: > Denis Johnson schrieb: > > On Thu, Jul 2, 2009 at 4:27 AM, Sebastian > > Krzyszkowiak wrote: > > > >> Just set ELM_ENGINE env variable to x11-16. You must know about > >> /etc/profile, didn't you? ;> > >> > > > > Just to demonstrate my lack of familiarity in this area, could someone > > please provide exact example of the line that needs to be added to > > /etc/profile > > > echo ELM_ENGINE=x11-16 >> /etc/profile > Shouldnt that be : echo; echo "export ELM_ENGINE=x11-16" >> /etc/profile ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is it so slow ?
William Kenworthy schrieb: > On Thu, 2009-07-02 at 03:01 +0200, Bernd Prünster wrote: > >> Denis Johnson schrieb: >> >>> On Thu, Jul 2, 2009 at 4:27 AM, Sebastian >>> Krzyszkowiak wrote: >>> >>> Just set ELM_ENGINE env variable to x11-16. You must know about /etc/profile, didn't you? ;> >>> Just to demonstrate my lack of familiarity in this area, could someone >>> please provide exact example of the line that needs to be added to >>> /etc/profile >>> >>> >> echo ELM_ENGINE=x11-16 >> /etc/profile >> >> > > > Shouldnt that be : > echo; echo "export ELM_ENGINE=x11-16" >> /etc/profile > > > yup, sorry export ELM_ENGINE=x11-16 is the correct line that needs to be added to /etc/profile (just copied form my /etc/profile file, so make sure its correct) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] fao nytowl, om2009 listing in wiki distributions page
Hi Tim, It's a little more complicated than that. On June 30, 2009 03:08:49 pm Tim Abell wrote: > Hi All / nytowl, > > I installed Om2009 on the basis that it is listed under "official" on > the distributions page, http://wiki.openmoko.org/wiki/Distributions > As far as it's official status you'll need to get a comment from an OM employee. > I now understand (via irc) that openmoko are no longer maintaining any > distributions, and that Om2009 is produced and maintained by Angus > Ainslie (nytowl). > I am still doing maintenance on a volunteer and very part time basis. The build servers and webservers are still being supplied by OM ( I haven't been given any timeline on if or whether this will continue ). > Do you (Angus) or anyone else object if I move Om2009 in that listing to > the community section as this would clear up any confusion. > > It would also be worth adding a note to this page for those unaware of > the change to openmoko's focus. > Updating and maintaining the wiki is always a good thing, thanks. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Thumb up for your effort:)
A simpler design choice would be:
1. int get_tile_meta(int zoom, int x, int y, TileMeta *tm) -- fill in
, ; return -1 if tile not found
-- implemented by collecting per map meta info into a sqlite database
2. int get_tile_bytes(char* buf, TileMeta *tm) -- read tile content into
of
-- implemented by collecting tiles into a big file.
Where TileMeta is defined as:
struct TileMeta
{
int offset;
int size;
U4 crc;
char *name; // optional
};
This kind of data source is abstracted as a tile provider, in addition to
the default standard file system based one.
I'd like to see if xar works well too.
regards,
mqy
Laszlo KREKACS wrote:
>
> Hi!
>
> I have studied all the available archive and compression options.
> ...
> Best regards,
> Laszlo
> ...
>
--
View this message in context:
http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193471.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Hi! Thank you for the kind words. > I'd like to see if xar works well too. I have only one problem with xar: xml. It complicates things unnecessary. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
XML is used as a database, elements can be easily added, modified, removed. xor tends to be overkilled as of map tile usage -- we don't need iterating, delete, and that much meta information. With my suggested design, we can even add newly downloaded tiles: insert record into meta database, and append tile content into "heap" file. Laszlo KREKACS wrote: > > ... > I have only one problem with xar: xml. > It complicates things unnecessary. > ... > Laszlo > -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193580.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
I assume that auto-suspending is disabled by some app while you try adjusting in SHR-settings :) Auto suspending is disabled by omgps, you can't adjust auto-suspending when omgps is running. vendion wrote: > > I have just noticed the opposite problem, I am unable to get shr- > unstable to auto suspend. Going to shr settings -> Power and using > the slider for the auto suspend to try an enable it does not work, > when I drag it, the slider just goes back to "disabled" no matter how > many times I try it or even how long I hold it there. > On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: > ... > -- View this message in context: http://n2.nabble.com/-shr-unstable--20090624-suspend-off-not-really-off--tp3192622p3193723.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 00:20, Laszlo KREKACS wrote: >> I dont want to compress at all. The 118MB for me is perfect. I only >> want to pack the directory into a file. But not compressing. >> Im thinking about tar or ar. > > Tar completely fail at random access, simply it lacks the > table of content, so accessing the last file in the archive > requires reading the whole content before it. I fail to see how is this true for normal tar files (vs. data read from pipe). Can you elaborate please? > Zip support accessing each files in the archive, although > it compress the file by default. Pardon my ignorance, but wouldn't zip -0 do the trick for your purpose? :) -- Regards, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
