Re: dbus moving into kernel?
Patryk Benderz wrote: Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. There are a lot of complaints about Dbus IPC. That makes me wonder why people don't use one of already existing kernel IPCs [1][2] , and instead try to develop another one, which is not secure as I heard? [1] http://tldp.org/LDP/lpg/node7.html [2] http://tldp.org/LDP/tlk/ipc/ipc.html Actually, netlink comes to mind as a transport layer for something like dbus. It can not all that dbus can, but most of those so called features are actually a total wank anyway. At least it would scale. But I suppose this discussion was lost when dbus was new and it is pointless these days. Dbus will probably have a successor some day, and with any luck it will have more sane foundations... Actually, dbus is not that bad. Some of the things it can do require a approach like they took. Question is, should we have sacrificed those features on the alter of simplicity? I'm not even sure I have a answer to that... Regards Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GNU/Linux Wrist Watch
Jon 'maddog' Hall wrote: BUT the battery life was pathetic, and it was rather clunky looking, and it still could not make a telephone call, so it was never produced. BUT technology moves forward, and someday. Indeed. Some month ago a bought a wrist watch phone for 199 USD just for the fun of it. It is not terribly clunky, has bluetooth and even a (video)camera and stereo mp3 player via bluetooth. But no Linux or any smart Operating system for that matter. :( But it shows, technology is there. I'm just not the right person for a non smart phone with limited user interfaces. Regards Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] French Image
Tilman Baumann wrote: David Reyes Samblas Martinez wrote: 2009/12/1 Thomas HOCEDEZ thomas.hoce...@free.fr: No, I didn't. What would be the interest to do so ? it generate the index from the final filesto be able to search them correctly generating a hash file that must be included, in the image directory: $../host-tools/has-gen/has-gen --fnd=pedia.fnd --pfx=pedia.pfx --hsh=pedia.hsh I suspect there is still something wrong with my modification to the script. Indeed there was. I forgot to append the parser output instead I overwrote it. see http://github.com/tbaumann/wikireader/commit/e5f95508476b34c6c381fa5fec16f1986010f5b4 Now it is much much better. But unfortunately still not 100% correct. At least one link/keyword points to the wrong article. I found the problem with the Walt Kelly keyword which points to a jpeg file article. I suppose if we skip articles we have to also remove them from the index? I will investigate this, but I have little time and my python foo is weak. Regards Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] French Image
David Reyes Samblas Martinez wrote: 2009/12/1 Thomas HOCEDEZ thomas.hoce...@free.fr: No, I didn't. What would be the interest to do so ? it generate the index from the final filesto be able to search them correctly generating a hash file that must be included, in the image directory: $../host-tools/has-gen/has-gen --fnd=pedia.fnd --pfx=pedia.pfx --hsh=pedia.hsh I suspect there is still something wrong with my modification to the script. Building of my German wikipedia finally finished, but it does not work correctly. No link or even search points to the right article. Some articles are not even found. I removed all files that started with pedia* and copied the following files from my image dir on it. pedia0.dat pedia0.idx-tmp pedia.fnd pedia.hsh pedia.idx pedia.pfx Any ideas? I think I jinxed the PARSER_COMMAND and it re-writes the output file every time I restart it. But to test that I need two or three days again. :) Regards Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] French Image
Thomas Hocedez wrote: Hi people. I manage to generate a French image for the wikireader .. but it is not usable. A sad Failed to load article is always displayed. My image strangely a single 1.4Go file ... any idea ? I'm regenerating an image. using lasts scripts. We'll see tomorrow. Tilmasn did you manage to generate something good ? Unfortunately not. I'm building in a virtual machine. So it's slow. :) And I still missed a bug in the code. The programme does not terminate correctly because I left crap in the cleanup routine. Damn runtime errors after 10 hours or so. :) Keep you posted... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] Sharing compiling sources.
Hi, can you maybe release this as a patch? I like to inegrate this in github. But I fear I might miss something if I try to fiddle out the changes by hand. Thanks David Reyes Samblas Martinez wrote: Sorry for the wait Thomas, I was working to solve the broken pipe issue that stops the parser when it finds an error. I have applied a quick and dirty workaround using try-catch technique and now the process will not stop and just skip the faulty article and keeps going :) it logs the faulty ones in a text file (title and position) for posterior forensics, but my first guesses in that is not a codification issue with utf8 is more an unexpected formating tag the php parser don't know how to deal with Actually parsing the german wikipedia with more than 1.3 million articles Count: 1043000 Failing count: 2 and keeps going I supose we can sacrificate two articles for having one milion available now :) as you requested I uploaded my working compiled tools[1] but without any xml sources it's about 113Mb, but if you have a working tools on your system you just have to change host-tools/offline-renderer/ArticleParser.py by the attached on this mail and you can forget to cry like a child that his ice cream has fall to the floor when after more than 24h parsing hundred of thousand articles pased the process you see this ugly python error backtrace blablabla and not your desired file :) by the way the faultyarticles.txt is saved at same host-tools/offline-renderer directory, (i'm too lazy to put a parameter for change that and I hardcoded the name of the file , yes... don't waste typing on correct that bad habit, I know) If you have curiosity of what articles on the german wiki are causing troubles on dewiki-latest-pages-articles.xml (date 2009-11-20) ~Storck Bicycle 832673 ~Musculus serratus posterior inferior 857334 Regards I hope I will upload the German wikipedia on Sunday... and will be available on Monday, sorry for the wait but my Asymmetric DSL is very asymmetric and upload 1.5-2 Gb (expected file size) will take a bunch of hours. For those than wants to compile his own , go for it :) the Quickreference in the doc directory on the souce is all you need to start working, just remember than if you have a 64 bit system you will have to follow the 64 bits method to compile the tools, Regards [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2 David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/11/27 Thomas HOCEDEZ thomas.hoce...@free.fr: Thomas HOCEDEZ a écrit : Hi DAvid, Can you share your scripts configs to do the same in French (and other languages) ? Thanks Thomas As the Mailing list seems to be broken (or users started hibernating for winter...) I find by myself the way to compile things step by step. I'm for now rendering the French Wikipedia. As it started a few minutes ago, the result will be availabel during the weekend (I hope). I'll also post the way I managed to do so ! (I'm at the office for now, and I'm leaving...) Regards to you all ! Thomas ___ 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: [WikiReader] Sharing compiling sources.
Actually the tar file seems to be broken. So much for potentially missing stuff. ;) Tilman Baumann wrote: Hi, can you maybe release this as a patch? I like to inegrate this in github. But I fear I might miss something if I try to fiddle out the changes by hand. Thanks David Reyes Samblas Martinez wrote: Sorry for the wait Thomas, I was working to solve the broken pipe issue that stops the parser when it finds an error. I have applied a quick and dirty workaround using try-catch technique and now the process will not stop and just skip the faulty article and keeps going :) it logs the faulty ones in a text file (title and position) for posterior forensics, but my first guesses in that is not a codification issue with utf8 is more an unexpected formating tag the php parser don't know how to deal with Actually parsing the german wikipedia with more than 1.3 million articles Count: 1043000 Failing count: 2 and keeps going I supose we can sacrificate two articles for having one milion available now :) as you requested I uploaded my working compiled tools[1] but without any xml sources it's about 113Mb, but if you have a working tools on your system you just have to change host-tools/offline-renderer/ArticleParser.py by the attached on this mail and you can forget to cry like a child that his ice cream has fall to the floor when after more than 24h parsing hundred of thousand articles pased the process you see this ugly python error backtrace blablabla and not your desired file :) by the way the faultyarticles.txt is saved at same host-tools/offline-renderer directory, (i'm too lazy to put a parameter for change that and I hardcoded the name of the file , yes... don't waste typing on correct that bad habit, I know) If you have curiosity of what articles on the german wiki are causing troubles on dewiki-latest-pages-articles.xml (date 2009-11-20) ~Storck Bicycle 832673 ~Musculus serratus posterior inferior 857334 Regards I hope I will upload the German wikipedia on Sunday... and will be available on Monday, sorry for the wait but my Asymmetric DSL is very asymmetric and upload 1.5-2 Gb (expected file size) will take a bunch of hours. For those than wants to compile his own , go for it :) the Quickreference in the doc directory on the souce is all you need to start working, just remember than if you have a 64 bit system you will have to follow the 64 bits method to compile the tools, Regards [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2 David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/11/27 Thomas HOCEDEZ thomas.hoce...@free.fr: Thomas HOCEDEZ a écrit : Hi DAvid, Can you share your scripts configs to do the same in French (and other languages) ? Thanks Thomas As the Mailing list seems to be broken (or users started hibernating for winter...) I find by myself the way to compile things step by step. I'm for now rendering the French Wikipedia. As it started a few minutes ago, the result will be availabel during the weekend (I hope). I'll also post the way I managed to do so ! (I'm at the office for now, and I'm leaving...) Regards to you all ! Thomas ___ 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: [WikiReader] Sharing compiling sources.
I realized that it does not apply to the latest version. So I took the liberty of making a fork on github and merged it. http://github.com/tbaumann/wikireader I think I cracked the nut, but have a look if you would be so kind. I'm not sure I completely got it. (Please ignore the first commit. I did not test correctly before checking in. :-/ ) Regards Tilman Baumann David Reyes Samblas Martinez wrote: Here you have :) David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/11/30 Tilman Baumann til...@baumann.name: Hi, can you maybe release this as a patch? I like to inegrate this in github. But I fear I might miss something if I try to fiddle out the changes by hand. Thanks David Reyes Samblas Martinez wrote: Sorry for the wait Thomas, I was working to solve the broken pipe issue that stops the parser when it finds an error. I have applied a quick and dirty workaround using try-catch technique and now the process will not stop and just skip the faulty article and keeps going :) it logs the faulty ones in a text file (title and position) for posterior forensics, but my first guesses in that is not a codification issue with utf8 is more an unexpected formating tag the php parser don't know how to deal with Actually parsing the german wikipedia with more than 1.3 million articles Count: 1043000 Failing count: 2 and keeps going I supose we can sacrificate two articles for having one milion available now :) as you requested I uploaded my working compiled tools[1] but without any xml sources it's about 113Mb, but if you have a working tools on your system you just have to change host-tools/offline-renderer/ArticleParser.py by the attached on this mail and you can forget to cry like a child that his ice cream has fall to the floor when after more than 24h parsing hundred of thousand articles pased the process you see this ugly python error backtrace blablabla and not your desired file :) by the way the faultyarticles.txt is saved at same host-tools/offline-renderer directory, (i'm too lazy to put a parameter for change that and I hardcoded the name of the file , yes... don't waste typing on correct that bad habit, I know) If you have curiosity of what articles on the german wiki are causing troubles on dewiki-latest-pages-articles.xml (date 2009-11-20) ~Storck Bicycle 832673 ~Musculus serratus posterior inferior 857334 Regards I hope I will upload the German wikipedia on Sunday... and will be available on Monday, sorry for the wait but my Asymmetric DSL is very asymmetric and upload 1.5-2 Gb (expected file size) will take a bunch of hours. For those than wants to compile his own , go for it :) the Quickreference in the doc directory on the souce is all you need to start working, just remember than if you have a 64 bit system you will have to follow the 64 bits method to compile the tools, Regards [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2 David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/11/27 Thomas HOCEDEZ thomas.hoce...@free.fr: Thomas HOCEDEZ a écrit : Hi DAvid, Can you share your scripts configs to do the same in French (and other languages) ? Thanks Thomas As the Mailing list seems to be broken (or users started hibernating for winter...) I find by myself the way to compile things step by step. I'm for now rendering the French Wikipedia. As it started a few minutes ago, the result will be availabel during the weekend (I hope). I'll also post the way I managed to do so ! (I'm at the office for now, and I'm leaving...) Regards to you all ! Thomas ___ 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 -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Wikireader] Error on processing the German Wikipedia
Can you reproduce this with a neutral locale?
export LC_ALL=C
I'm at the moment trying the same. I had a lot of hickups, caused by many
things. Among them missing tools and not enough memory.
This is currently where I'm stuck with the German wikipedia.
Count: 823000
Count: 824000
Count: 825000
Count: 826000
Count: 827000
Count: 828000
Count: 829000
Count: 83
Count: 831000
Count: 832000
Count: 833000
Traceback (most recent call last):
File ./ArticleParser.py, line 203, in module
main()
File ./ArticleParser.py, line 168, in main
process_article_text(title.encode('utf-8'), f.read(length), newf)
File ./ArticleParser.py, line 197, in process_article_text
newf.write(text + '\n')
IOError: [Errno 32] Broken pipe
make[1]: *** [parse] Error 1
make[1]: Leaving directory
`/home/tilli/wikireader/host-tools/offline-renderer'
make: *** [parse] Error 2
I suppose it failed somewhere in PARSER_COMMAND
Before that, the following steps went through without fail.
make
make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-20091028-pages-articles.xml index
David Reyes Samblas Martinez wrote:
After the success of the spanish wikipedia pending to resolve the
indexing part, I was starting to work on the german wikipedia
http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
but it fails at first step with the following error
#make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
combine
awk: línea ord.:1: fatal: no se puede abrir el fichero
`work/counts.text' para lectura (No existe el fichero ó directorio)
cd host-tools/offline-renderer make index \
XML_FILES=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
RENDER_BLOCK=0 \
WORKDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work
DESTDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image
make[1]: se ingresa al directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
./ArticleIndex.py \
--article-index=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db
\
--article-offsets=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/offsets.db
\
--article-counts=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/counts.text
\
--prefix=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image/pedia
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
Traceback (most recent call last):
File ./ArticleIndex.py, line 611, in module
main()
File ./ArticleIndex.py, line 172, in main
limit = processor.process(f, limit)
File
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer/FileScanner.py,
line 141, in process
if '#' == body[0] and 'redirect' == body[1:9].lower():
IndexError: string index out of range
Flushing databases
Writing: files
Time: 0s
Writing: articles
Time: 0s
Writing: offsets
Time: 0s
Loading: articles
Time: 0s
Loading: offsets and files
Time: 0s
make[1]: *** [index] Error 1
make[1]: se sale del directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
make: *** [index] Error 2
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
___
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: [Wikireader]Compling from source fails
I had many failed attempt on Fedora. After I went to ubuntu it pretty much worked throughout the toolchain and kernel compiling steps. (Ok I had to install tons of dependencies) Tilman jcolb...@netins.net wrote: I have followed the instructions on http://wiki.github.com/wikireader/wikireader/building-from-source . I run make mbr, trying to make a new flash.rom file to change the boot splash image. It runs for a long time and then fails at this point. It creates an mbr.elf file, but no flash.rom . c33-epson-elf-ld: region a0ram is full (menu.elf section .rodata) make[1]: *** [menu.elf] Error 1 make[1]: Leaving directory `/home/jcolbert/wikireader-wikireader-4e90213/samo-lib/mbr' make: *** [mbr] Error 2 Any ideas or help? Thanks Jeff ___ 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: [Wikireader] Error on processing the German Wikipedia
David Reyes Samblas Martinez wrote:
Well spanish one give me the same error before but now it works,
Any idea what solved it? Or is it just random and will go away if I try it
again? :)
I'm parsing the de wikipedia right now (Count: 173000) lets see whats
happens :)
I would definitely be interessted in the results...
Note:Parsing the 2009-Nov-11
http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-articles.xml.bz2
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
2009/11/20 Tilman Baumann til...@baumann.name:
Can you reproduce this with a neutral locale?
export LC_ALL=C
I'm at the moment trying the same. I had a lot of hickups, caused by
many
things. Among them missing tools and not enough memory.
This is currently where I'm stuck with the German wikipedia.
Count: 823000
Count: 824000
Count: 825000
Count: 826000
Count: 827000
Count: 828000
Count: 829000
Count: 83
Count: 831000
Count: 832000
Count: 833000
Traceback (most recent call last):
File ./ArticleParser.py, line 203, in module
main()
File ./ArticleParser.py, line 168, in main
process_article_text(title.encode('utf-8'), f.read(length), newf)
File ./ArticleParser.py, line 197, in process_article_text
newf.write(text + '\n')
IOError: [Errno 32] Broken pipe
make[1]: *** [parse] Error 1
make[1]: Leaving directory
`/home/tilli/wikireader/host-tools/offline-renderer'
make: *** [parse] Error 2
I suppose it failed somewhere in PARSER_COMMAND
Before that, the following steps went through without fail.
make
make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-20091028-pages-articles.xml index
David Reyes Samblas Martinez wrote:
After the success of the spanish wikipedia pending to resolve the
indexing part, I was starting to work on the german wikipedia
http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
but it fails at first step with the following error
#make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
combine
awk: línea ord.:1: fatal: no se puede abrir el fichero
`work/counts.text' para lectura (No existe el fichero ó directorio)
cd host-tools/offline-renderer make index \
XML_FILES=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
RENDER_BLOCK=0 \
WORKDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work
DESTDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image
make[1]: se ingresa al directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
./ArticleIndex.py \
--article-index=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db
\
--article-offsets=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/offsets.db
\
--article-counts=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/counts.text
\
--prefix=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image/pedia
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
Traceback (most recent call last):
File ./ArticleIndex.py, line 611, in module
main()
File ./ArticleIndex.py, line 172, in main
limit = processor.process(f, limit)
File
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer/FileScanner.py,
line 141, in process
if '#' == body[0] and 'redirect' == body[1:9].lower():
IndexError: string index out of range
Flushing databases
Writing: files
Time: 0s
Writing: articles
Time: 0s
Writing: offsets
Time: 0s
Loading: articles
Time: 0s
Loading: offsets and files
Time: 0s
make[1]: *** [index] Error 1
make[1]: se sale del directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
make: *** [index] Error 2
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
___
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
--
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Wikireader] Error on processing the German Wikipedia
David Reyes Samblas Martinez wrote:
Don't hold your breath :( failing at Count: 832000
Same error as I?
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
2009/11/20 Tilman Baumann til...@baumann.name:
David Reyes Samblas Martinez wrote:
Well spanish one give me the same error before but now it works,
Any idea what solved it? Or is it just random and will go away if I try
it
again? :)
I'm parsing the de wikipedia right now (Count: 173000) lets see whats
happens :)
I would definitely be interessted in the results...
Note:Parsing the 2009-Nov-11
http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-articles.xml.bz2
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
2009/11/20 Tilman Baumann til...@baumann.name:
Can you reproduce this with a neutral locale?
export LC_ALL=C
I'm at the moment trying the same. I had a lot of hickups, caused by
many
things. Among them missing tools and not enough memory.
This is currently where I'm stuck with the German wikipedia.
Count: 823000
Count: 824000
Count: 825000
Count: 826000
Count: 827000
Count: 828000
Count: 829000
Count: 83
Count: 831000
Count: 832000
Count: 833000
Traceback (most recent call last):
File ./ArticleParser.py, line 203, in module
main()
File ./ArticleParser.py, line 168, in main
process_article_text(title.encode('utf-8'), f.read(length), newf)
File ./ArticleParser.py, line 197, in process_article_text
newf.write(text + '\n')
IOError: [Errno 32] Broken pipe
make[1]: *** [parse] Error 1
make[1]: Leaving directory
`/home/tilli/wikireader/host-tools/offline-renderer'
make: *** [parse] Error 2
I suppose it failed somewhere in PARSER_COMMAND
Before that, the following steps went through without fail.
make
make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-20091028-pages-articles.xml index
David Reyes Samblas Martinez wrote:
After the success of the spanish wikipedia pending to resolve the
indexing part, I was starting to work on the german wikipedia
http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
but it fails at first step with the following error
#make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
combine
awk: línea ord.:1: fatal: no se puede abrir el fichero
`work/counts.text' para lectura (No existe el fichero ó directorio)
cd host-tools/offline-renderer make index \
XML_FILES=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
RENDER_BLOCK=0 \
WORKDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work
DESTDIR=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image
make[1]: se ingresa al directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
./ArticleIndex.py \
--article-index=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db
\
--article-offsets=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/offsets.db
\
--article-counts=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/counts.text
\
--prefix=/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image/pedia
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
Traceback (most recent call last):
File ./ArticleIndex.py, line 611, in module
main()
File ./ArticleIndex.py, line 172, in main
limit = processor.process(f, limit)
File
/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer/FileScanner.py,
line 141, in process
if '#' == body[0] and 'redirect' == body[1:9].lower():
IndexError: string index out of range
Flushing databases
Writing: files
Time: 0s
Writing: articles
Time: 0s
Writing: offsets
Time: 0s
Loading: articles
Time: 0s
Loading: offsets and files
Time: 0s
make[1]: *** [index] Error 1
make[1]: se sale del directorio
`/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
make: *** [index] Error 2
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
___
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
Re: WikiReader - first impressions
Hi Sean, I was playing around a bit with the sources on github lately. I have stumbled over some issues. I know I can go to c...@thewikireader.com (and I will) But I guess we should have a mailing list for software aspects of WikiReader... Just a thought. :) Sean Moss-Pultz wrote: Hi Torfinn Really appreciate your feedback. My comments are inline: On Tue, Nov 10, 2009 at 5:48 AM, Torfinn Ingolfsen tin...@gmail.com wrote: Hello, After a few days with the WikiReader, here are my first impressions: The obvious things: - good size: this device is small enough to drag along (ok, it won't fit in my trouser pockets), but has a big enough screen to read on comfortably - use in places: I knew about the missing backlight. I can read the WikiReader while commuting (most tram's have good lighting), but on the other hand it is difficult in a cosy cafe, because the lighting is not s good there. - scrolling: this works great, even better than I thought. One friend asked: how do I get to the next page, but was happy with scrolling after I told him to use that instead. Are you running the latest kernel? (The way to tell is if you have kinetic scrolling, yes == latest kernel) http://cloud.github.com/downloads/wikireader/wikireader/kernel-2009-10-30.zip Scrolling is really really good there. - history: it's there when I turn on the device - and I like that. - the search button removes the on screen keyboard so I can scroll on the search screen. Yes! I like that. That's another fun random like way of searching. The questions: - search screen: where is the delete word and start over button? (this was the first question I got from two friends trying the device) You can hold down the backspace key. It will delete the word extremely fast. We're working on a few minor UI changes for the next release. Clear will be more obvious. - why isn't there a back button? Sure, I can use the history button and select from the list (and that works quite well), but a back button would save one keypress We didn't want to add another button. We might use left to right swipes in a later release. Not sure yet... Annoyances: - it is impossible (for me at least) to take out the microSD card without using a tool (pliers or something). Why do I want to take it out? To actually show people the small size of a Wikipedia database. :-) Push it in and it will pop out (beware it will *really* pop sometimes) - the buttons on the on screen keyboard is a bit small for my fingers (it is easy to press the character left or right of the one I want). I don't know how to solve this yet. Software. If you've used an iPhone, the keypad is 70% of WikiReader's size. And typing is a lot better. So just bear with us. We're working on this big time. - sometimes, the history screen is unresponsible, I have to press the other two buttons a couple of times before I can select anything on the history screen Working on this, too... small annoyances: - the moment it takes to display an article (after selecting it, either from the search screen or from a link) is just long enough that the device feels a bit slow sometimes. Same as my last comment :) Some things I haven't figured out yet: - how do I get another Wikipedia (for example the Norwegian one) onto a MicroSD card? - how do I convert an e-book and put it onto a microSD card for the device? Like David said, we encourage you to check out github.com/wikireader for now. All in all - I really like this device. Great. We love to hear this! -Sean ___ 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: [wikireader] Images on the WR not so imposible :P [was [wikireader]Error on parsing the spanish wikipedia]
Rui Miguel Silva Seabra wrote: On Tue, Nov 03, 2009 at 12:15:11PM +0100, David Reyes Samblas Martinez wrote: Also some way to not infringe the authoring and licencing text includings clauses must be used by the images viewer. but I guess it can be done by links to text as other wikipage more. The problem isn't so much about WikiMedia or OpenMoko, but that the original authors did not free the images. As such, whilst maybe they can be on Wikipedia, which is on a non-profit environment, distributing on the WikiReader (which is for-profit) may be legally problematic. I'm not sure if this is a desired workflow. But I don't think whis will be a problem if everybody builds his own wikireder offline database. Meaning, Wikireader ships and maintains a database with all safe content. And if you like more you do it yourself. PS: I think it would be a good idea to only use pics with low dnamic in the first place. There is no use to have a van Gough on a 1bit low res screen. But having maps, flags, schematics and other low dynamic stuff makes total sense. I especially think about the huge amount of svg content. I imagine, that this can be fairly easily detected. (Maybe just simply by compression factor) PPS: Apropos SVG. I guess we can keep them as some kind of vector format to save space. PPPS: We need a mailinglist Tilman ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader] Images on the WR not so imposible :P [was [wikireader]Error on parsing the spanish wikipedia]
David Reyes Samblas Martinez wrote: But having maps, flags, schematics and other low dynamic stuff makes total sense. I see the flags more problematic than van Gough ... a lot of them relies on colors to diferentiate each other so italian,french,irish, and all the miriad trhee vertical colors flags will be very hard differentiable You see that effect on cheap newspaper prints. They have fairly large 1bit pixels. It works good enough. It's ugly for pictures. But very well for diagrams or anything like that. You won't have absolute colours but that still works well. PPS: Apropos SVG. I guess we can keep them as some kind of vector format to save space. With the sizes we are talking abuout (3-4Kb once compressed), rarely a svg will be smaller than this, and I think reder a vector image is more resouce hungry than just a plain bitmap, but if the device can hold it it can be awesome as map viewer :) True. 1 bit images are probably smaller then vector graphics. What would be a miss could maybe 'scrolling' (Paging) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] Hardware
Thomas HOCEDEZ wrote: Hi folks, I opened my WR this weekend and I took some pictures for those who wants : http://freerunner.daily.free.fr I was really surprised to see a little connector (not soldered) which is exactly a mini USB ! I soldered it, plugged it on my desktop and ... TADA !! ..nothing, nada, keutch, queudalle lsusb is totally quiet ... If someone have informations about this plug, and the other jtag plug (on more than the one present near batteries). I think there will be rough hacking those future nights. I'm not sure what you are talking about. The software is free. http://github.com/wikireader (Can't see any caviats if there are any) If you look at it you will notice that is not running a OS in the regular sense. Especially not a full blown OS with a USB stack like Linux. The software is fully loaded from SD card. As far as I understand you can compile anything you like and get it booted from SD. http://github.com/wikireader/wikireader/blob/master/samo-lib/00ReadMe.text I suppose you can create a usb stack. And I think a usb-storage mode would be fantastic to update the SD contents. If you find out if it has a battery charger you could maybe even charge the device via usb... The gist. Wikireader is not anything like the Neo. It's very minimalistic. Regards Tilman ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rod Whitby (MokoMakefile author) moves on to start WebOS Internals
Thank you anyway. Traitor! :) And ROFL about the northern hemisphere chauvinism issue with your GPS. *g* I hope that is not a omen... See you back ;) Rod Whitby wrote: http://www.rwhitby.net/blog/webos-internals/palm-pre-lands-in-australia.html It is with some sadness that I must say goodbye to the OpenMoko community, and move on to new things. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [SHR] Setting regional codes
Sorry I missed the whole thread. Need to read it all in a free minute. Sorry if I spam you with irrelevant stuff. But my post to dial plans and number cannonification from last year might be interesting for you guys. http://www.mail-archive.com/de...@lists.openmoko.org/msg00073.html There was much discussion on that thread. But the conclusion is, if you know your dialplan (internationalPrefix, longDistancePrefix and countryCode) you can transform every local number into the full international form +xxyyz And from that, if you would like you can transform it back by applying your dial plan. But there is of course not much need for that on cell networks. Regards Tilman Niels Heyvaert wrote: + should be an alias to 00 if at the beggining of a number. This usage of + is so common and international that it would be IMHO dumb to intentionally ignore it. Not only that, but I intentionally store all my numbers in the + (usually +31...) format, since not every country has 00 as its international prefix! If you look at http://www.kropla.com/dialcode.htm, there is a whole list of IDD codes, and there are lots of 'em that aren't 00... I'm looking forward to having full number recognition, since I now regularly have to 'mentally lookup' a number when it's calling me... Christ van Willegen -- Adding my observations to the mix: I haven't changed any of the phone settings and store all my phone numbers in the international format (with '+' sign). In the config file the default country code is set to 49, which is different from my actual country code. Incomming calls and messages map very nice to the contact names. I haven't received any international calls or text messages since I've started using SHR-U, but will keep an eye on it. Niels. _ Reageer op fotos van je vrienden en bekijk hun reacties op de jouwe. Gegarandeerd hilariteit! http://www.microsoft.com/belux/nl/windows/windowslive/products/photos.aspx ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: On Friday 21 August 2009 16:36:07 Helge Hafting wrote: Now, implement suspend-to-disk (SD-card), and you can start reasonably quick after changing the battery. It should take around 40 seconds to read the memory back from SD, so if you can live with that, implementing suspend-to-disk might be interesting. I like the hybrid suspend method that is used by apple (and possibly others) They do suspend to RAM for fast resume. But also do suspend to disk. And if the battery runs out (or is yanked out for replacement) the system comes up again from disk. It would be neat to have. If it is easy. Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. Resume speed is in my eyes just not a issue. Boot speed is something else. The only reason to boot a phone is if it crashed, ran out of battery or kernel update. Avoiding reboots seems to be the answer for me. Not that it would be cool it it could boot faster. But any modern smartphone has horrendous boot times this day. How long could a phone on a almost empty battery survive after it has shut off all radios and gone into standby? We could maybe have some 'survival' mode to make it to the next charger without shutting off. If that is worth it at all. Still I prefer working on the actual boot process, since getting away from booting like a PC will also have positive effects on memory consumption and battery lifetime. +1 Booting after init still takes ages. I don't know, but it seems to be a IO throughput problem rather then CPU speed. Maybe more compression can help? Just a hunch, I'm basically clueless. And of course delaying stuff. What I would wish for is quicker GSM login. I think have the latest firmware, but SHR still takes ages after the phone is fully booted until it is on line. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On 21 Aug 2009, at 18:10, Edder wrote: On Fri, Aug 21, 2009 at 6:52 PM, Michal Brzozowskiruso...@poczta.fm wrote: 2009/8/21 Tilman Baumann til...@baumann.name Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. There are many use cases if you're on battery for an extended period (for example when traveling) and don't need the GSM to be online all the time. There have been a few occasions where suspend to disk would have helped me, assuming reasonable wakeup time. But I understand I'm in the minority. I would also like suspend to disk and agree that there are a number of use cases when it is very practical. For example I am often out of the country for a weekend. Often it is not practical to recharge the phone during that time and it would be a lot easier if I could just suspend to disk and quickly check for missed msgs every couple of hours or so. Well yea, but it's a phone after all. :) I would be really interested how long the phone would survive on the deepest not off sleep possible (No radio, all chips possible shut off). That could beat system to disk I would expect. Maybe I am biased because I also always suspend my laptop to disk, so know from experience how nice it is to be able to quickly boot up :) Your laptop would probably survive for three month on suspend to RAM. ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Replacement battery for GTA01/Neo
Gerald A wrote: Hi, Looking at my Neo this morning, I noticed that it looked like the case wasn't put back on straight. My GTA01 Battery was always a bit bulgy from the beginning. If you feel it has become worse quickly, be afraid. :) -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
Laszlo KREKACS wrote: Dear List, Is anyone aware of any images, with prepacked maps with tangogps or navit? Im going to travel in the next days across Europe, and a gps device would be handy. I have a spare 2G uSD card. So some ready-made uSD image would be extremely cool. I only need the map and gps, no phone functionality is required. Any ideas? Navit has support for that kind of use. But I don't think you can get a europe opkg package quite yet. But there is a template how to throw a little xml snipped into some directory (included in the mapset esction of navit.xml). Just poit it to your sd card where your europe.bin is. I can't give you a exact description sinc ei don't have a openmoko phone at hand right now. But the wiki tells you how to get osm maps and the default config shows you how to integrate it. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
Robin Paulson wrote: 2009/5/28 arne anka openm...@ginguppin.de: don't know about any images. but with a map for all of europe 2gb is pretty little. it certainly won't work with tangogps -- once i tried to get all of germany in a usable resolution for tangogps and it exceed by far 2gb. so, your best bet would be navit with its binary maps which are much smaller for the same are covered. ho to fetch a map for a selected area is described in the navit wiki (in short: wget an url with the coordinates), and there are even a lot of links at osm where others have put together more or less regularyl updated binary map files of several regions of the world. cloudmade.com provide ready to go navit maps - the one for new zealand was 4 megabytes; i imagine germany won't be too much bigger ROFL. I see, the Kiwis have some catching up to do with their OSM coverage. :) Europe ~550MiB Germany ~250MiB http://wiki.navit-project.org/index.php/OpenStreetMaps#Getting_a_pre-processed_planet.osm -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
btw. if you consider it. The reiseplaner maps are great. But at least on my GTA01 (64MB) it does not really work well because navit becomes unusabely slow. http://wiki.navit-project.org/index.php/European_maps#Marco_Polo_Grosser_Reiseplaner Would be interesting to see how it does on a gta02... Tilman Baumann wrote: Laszlo KREKACS wrote: Dear List, Is anyone aware of any images, with prepacked maps with tangogps or navit? Im going to travel in the next days across Europe, and a gps device would be handy. I have a spare 2G uSD card. So some ready-made uSD image would be extremely cool. I only need the map and gps, no phone functionality is required. Any ideas? Navit has support for that kind of use. But I don't think you can get a europe opkg package quite yet. But there is a template how to throw a little xml snipped into some directory (included in the mapset esction of navit.xml). Just poit it to your sd card where your europe.bin is. I can't give you a exact description sinc ei don't have a openmoko phone at hand right now. But the wiki tells you how to get osm maps and the default config shows you how to integrate it. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
arne anka wrote: Since the 'bin' format is a .zip file with lots of smaller files in it, unzipping the (europe).zip file won't grow the data much... that's actually quite interesting! it never occured to me to analyze the resulting file. so, which map format would be faster -- navit or osm? the same map in osm being far bigger suggests somehow that less cpu is necessary ... I'm not sure I'm getting the point here. But the navit format is binary and the osm format is (zipped) xml. The navit binfile format is clearly more economical. osm files contain redundant informations and the xml needs to be parsed and built into a in memory structure (i guess) and the binfile format is basically a memory format and as far as I can read it mmappable. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
arne anka wrote: basically a memory format and as far as I can read it mmappable. i never looked into navit's source code. the train of thought was simply: small file - highly compressed information - increased cpu usage while extracting. No it is more like optimised computer readable format versus human readable very redundand and bloated format. *g* -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher/Home Page (Proof of concept) Working Release
I think this is so far focused on SHR. Warren Baird wrote: so - the question I have - should this be a separate app - or should this be considered a proposal for the new Paroli UI? I think the intent of Paroli was to be a proper home page for OM2009, right? shouldn't it provide all of the functionality this app provides? On Mon, May 25, 2009 at 9:57 AM, Rui Miguel Silva Seabra r...@1407.orgwrote: On Mon, May 25, 2009 at 06:45:48AM -0700, c_c wrote: Hi, 22 views and no feedback? I thought this was a much needed app! Hmmm. Shouldn't repeat functionality from Paroli (even if it's currently lacking) like the missed calls, and separation by f.d.o categories are way more needed before I'll give it a try! But good work so far, it looks good! :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: root almighty
GNUtoo wrote: *a free version compilable from source without google stuff(such as maps) I was told I had to gab source.android.com, type make and then make sdk Yes, a hand full of Google apps are unfree. But what I find amazing is, that they cust comply to a known api as any other program could do. So you can in fact repace them without yinxing usability. Even on a 'official' android device. so I think I'll try android...but I'll look first if it's tight to google services...(I'm already spied a lot using google search engine...I don't want to be spied more) _that_ is a real issue for me too. I use a G1 for a while now, and I mostely like it. Though it has serious problems. But the fact that is not even intended not to have a google account and not having your contacts and calendars mirrored in the google cloud is really annoying. Not not annoying, it angers me greatly. And Bluetooth support is a mess. No OBEX, no FTP nothing useful. Imagine a smartphone where you can't send contacts via bluetooth! (ok, varous OM distros don't do it out of the box too...) -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all e/illume based] copy/paste
On 27 Apr 2009, at 02:07, Carsten Haitzler (The Rasterman) wrote: On Mon, 27 Apr 2009 00:38:20 +0200 Marco Trevisan (Treviño) m...@3v1n0.net said: Recent versions of Elementary include a support for easy copy/paste actions. I think it's a good example that could be ported also to other toolkits (wich mostly need patches, BTW). yes. just hold down your finger for a second and presto.. menu (you can paste or begin selecting things). the selection is malleable ie the first time when there is no selection you define it with a drag. but after that pressing near the beginning or end of the selection allows you to adjust it to get it right. press and hold again for menu to copy or cut or cancel. cancel just clears the selection and does nothing. copy and cut put that selection in the copy buffer, and going anywhere else to paste will paste it. Wow, nice! But it does only work in text edit fields. Not for example in the sms message view text area. Feature request... ;) Tilman ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NEW e-tasks Alpha release
On 30 Apr 2009, at 02:44, c_c wrote: Hi, 20 odd views and no feedback? Seems like PIM apps aren't really on very many people's radar :-) I'm still trying to understand the UI. PIM is second most important after phone. So, go ahead. And thank you for your effort. :) But really, I did not understand how to use it yet. But hings happen when I press buttons. *g* Tilman ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-testing timezones! responding?
On 30 Apr 2009, at 15:40, jeremy jozwik wrote: sorry, that last post did not work right. how do i properly respond to mail list messages? If your mail client does not know better, reply-to-all. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
c_c wrote: The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I never felt a noticeable speed difference. with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
Michael 'Mickey' Lauer wrote: with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. This solely depends on your usecase. If you're in for single-window-single-app paradigm, combined with some clever logic to always show a panel, then you don't really need window management. Yes, but this really means always only one app _running_. (or drawing) This would require some extensive framework and very specialised code in the apps. (Apps need to free the fb and save the screen state and there would be some supervision needed for managing accesses to screen resources/and switching windows.) I don't think we have the resources for that. I mean, we just barely manage to make a working phone. :) And just forget about porting apps from any other environment. I could imagine doing this all with a evas (that rendering thingy of E, i always confuse the names) frontend which gets instructed to draw some scenario and connects the signals via rpc to a client... Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. If you do that, you quickly reinvent X ;) My point exactly. Seriously though, some projects have gone that way (evoak, picogui, ...), but dropped the ball. If you really do need window managment, use X. If not, fb- only could be a very viable alternative -- if only we had illume's softkeyboard working... If there is no swap out solution. I would just don't bother. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01 question : what capacity of ....
Tim Niemeyer wrote: Hallo wim.delvaux, * wim.delv...@adaptiveplanet.com wim.delv...@adaptiveplanet.com [24-04-09 04:16]: I.e. if I buy a 8GB micro SD card, would the GTA01 be able to use it ? I have never tried it, but i have heared it supports SDHC cards, but can't boot it? (Booting with Uboot???/Qi???; i don't know) More or less. :) SDHC is no problem for Linux. But UBoot can not load a kernel from SDHC. The wiki has a section how to boot a rootfs from sd and use the kernel from internal flash. And *never ever* use Qi on GTA01. You will loose the DFU loader! -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bluetooth spam
Roland Whitehead wrote: What you haven't experienced then is Toothing. Apparently, it's rife on the trains between London and Brighton (in the UK) and often ends up with the people toothing each other getting it together... Nothing to do with spam. If OpenMoko made this really easy then there'd be lots of new users! Hehe, I once did this on a ICE train. I was bored so I scanned for bluetooth devices. And then send them text files. O group of girls answered. Was really funny. Bur did not help me to ge laied tough. :) -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bluetooth spam
Jose Luis Perez Diez wrote: El Friday, 24 de April de 2009 13:48:37 Alexey Feldgendler va escriure: O group of girls answered. Was really funny. Bur did not help me to ge laied tough. :) Modern advances in mobile computing technologies still don't get one laid. Someone needs to work on that. we need to fill a bug report then. G And if someone stets the bug on 'WORKSFORME'? -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01 question : what capacity of ....
Ben Wilson wrote: Tilman Baumann wrote: Tim Niemeyer wrote: Hallo wim.delvaux, * wim.delv...@adaptiveplanet.com wim.delv...@adaptiveplanet.com [24-04-09 04:16]: I.e. if I buy a 8GB micro SD card, would the GTA01 be able to use it ? I have never tried it, but i have heared it supports SDHC cards, but can't boot it? (Booting with Uboot???/Qi???; i don't know) More or less. :) SDHC is no problem for Linux. But UBoot can not load a kernel from SDHC. The wiki has a section how to boot a rootfs from sd and use the kernel from internal flash. And *never ever* use Qi on GTA01. You will loose the DFU loader! It says this on the wiki Booting from SDHC requires a u-boot from 2008-07-23 or later. *But pay attention* : there are problems with SDHC cards at suspend time. This is GTA02 I got it from here http://wiki.openmoko.org/wiki/Supported_microSD_cards Might only apply to GTA02 though. It does. Unfortunately the ancient knowledge of GTA01 users degenerates in the wiki. Some GTA02 only topics are not marked as such. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navit is not finding current position
On 07.04.2009, at 09:23, Francesco de Virgilio wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christ van Willegen ha scritto: On Mon, Mar 9, 2009 at 6:55 PM, Christ van Willegen cvwille...@gmail.com wrote: Any hint on this? What am I doing wrong? If you run Navit from the terminal, it may tell you... In my case, it seems that the libgps installed on my system is too new. I haven't figured out how to solve this yet, but I'll let you know if I find out. I got Navit to work doing the following - Drop to a shell prompt on the FreeRunner (or use ssh to connect) - cd /usr/lib - ln -s libgps.so.17 libgps.so.16 This makes Navit think that libgps.so.16 is installed. Note: This may work for Navit for now, but may break other programs. Pardon!? Yes it is hackish and ugly and potentially not stable. But there is just no way how it could break other apps that are correctly linked. And wrongly linked apps might work which they did not before. If someone has used this solution, could confirm me that TangoGPS continued to work? I'm trying this in my SHR-testing, but I don't want any breakage. Com on. People who don't understad what this command does should not use a developer phone or should not tinker with it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS emergency call standards
Harald Welte wrote: On Tue, Feb 24, 2009 at 12:06:20PM +0100, Tilman Baumann wrote: Hi, I'm just wondering if there are any open standards for emergency services for location. I'm thinking about services like http://www.steiger-stiftung.de (European, websites in other languages should be available) I have asked them. They are basically not prepared to share any information on details. It is somehow a service they provide, but how it is implemented is unknown. Reply to my question if I might have some information to make my phone use their service, the answer was 'there are many phones which support us...' Yes, and I want to become one of them. But this is to much to ask from them. Stupid fuckers. I'm sure they did not even understand what I was asking. :-/ eCall seems to be a more open system, but still no real informations to find. And it as a slightly different focus too. A SMS to the respective emergency (112, 911) number containing the GPS position could be a start, but then someone has to read it. I would guess there is a standard for a computer readable format. Building a emergency call app would be a nice thing to have. PS: According to Wikipedia, 112 works on all GSM networks no matter if the number is a emergency number in tie state. that depends on what the network operator does. Yep, but there seems to be some international agreement on the significance of 112. I don't have any quote yet, but as far as I understood it is even required to by the GSM standards. But that might be wrong. The SIM card has a list of emergency numbers. If you call one of those numbers, or make an emergency call without a SIM card inserted, the phone will do itts request for a physical channel indicating its a EMERGENCY call, and then use EMERGENCY SETUP instead of SETUP, so the network can decide to rather kill somebody elses call and free resources for your emergency call in case the cell is otherwise full. That would be a great thing to have indeed. This needs to be included in the (FSO) dialer/contacts framework. Including the other special numbers the sim has, like ones own. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Hi all, for those of you who didn't see the blog on Openmoko-Planet or read the SHR Mailinglist... We did publish new testing images. Time for re-install by image or is opkg upgrade safe? -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Hi all, for those of you who didn't see the blog on Openmoko-Planet or read the SHR Mailinglist... We did publish new testing images. Time for re-install by image or is opkg upgrade safe? See the announcement :-) upgrading from old shr-testing does not work... Sombody even tried it me thinks. Changing the repo config and upgrading from shr- unstable is supposed to work though. Oh, sorry. I was a bit unclear. I was on unstable before and I intend to stay on the bleeding edge. (Or at least see where that brings me...) Question is, what will happen if I do nothing. Is the new unstable a clean continuation of the old unstable or does it break updates? Or should I just go testing anyway because unstable is really not intended for real use? -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann: Or should I just go testing anyway because unstable is really not intended for real use? Well... if you need it as a phone you should switch to testing. We intend to do some big changes that most definitely will lead to a not working phone in the beginning. If you just want something to play with and do not depend on it as your daily phone... thats different then :-) Or you could do what most of us SHR devs do... Have them both. One in flash and one on SD. Oh, good idea. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Hi all, for those of you who didn't see the blog on Openmoko-Planet or read the SHR Mailinglist... We did publish new testing images. Time for re-install by image or is opkg upgrade safe? See the announcement :-) upgrading from old shr-testing does not work... Sombody even tried it me thinks. Changing the repo config and upgrading from shr- unstable is supposed to work though. Oh, sorry. I was a bit unclear. I was on unstable before and I intend to stay on the bleeding edge. (Or at least see where that brings me...) Question is, what will happen if I do nothing. Is the new unstable a clean continuation of the old unstable or does it break updates? It still is a clean continuation... that might change though some day. Something is odd with this repo. :) See below. Looks like the repository is broken. I had to disable the /etc/opkg/armv4-feed.conf feed. (src/gz shr-armv4 http://shr.bearstech.com/shr-unstable/ipk//armv) Since it always produced 404. But that should not have anything to do with that. (shortened output) r...@om-gta01 ~ $ opkg upgrade Upgrading python-ecore on root from 0.3.1+svnr38274-ml0 to 0.3.1+svnr39379-ml0... Downloading http://shr.bearstech.com/shr-unstable/ipk//armv4t/python-ecore_0.3.1+svnr39379-ml0_armv4t.ipk Upgrading libecore-evas on root from 2:0.9.9.050+svnr38274-r1 to 2:0.9.9.050+svnr39379-r1... Downloading http://shr.bearstech.com/shr-unstable/ipk//armv4t/libecore-evas_0.9.9.050+svnr39379-r1_armv4t.ipk Upgrading libevas-engine-buffer on root from 2:0.9.9.050+svnr38274-r1 to 2:0.9.9.050+svnr39379-r1... Downloading http://shr.bearstech.com/shr-unstable/ipk//armv4t/libevas-engine-buffer_0.9.9.050+svnr39379-r1_armv4t.ipk Upgrading libehal0 on root from 2:0.5.0.050+svnr38274-r1 to 2:0.5.0.050+svnr39379-r1... .. Collected errors: * Failed to download http://shr.bearstech.com/shr-unstable/ipk//armv4t/python-ecore_0.3.1+svnr39379-ml0_armv4t.ipk, error 404 * Failed to download python-ecore. Perhaps you need to run 'opkg update'? * Failed to download http://shr.bearstech.com/shr-unstable/ipk//armv4t/libecore-evas_0.9.9.050+svnr39379-r1_armv4t.ipk, error 404 * Failed to download libecore-evas. Perhaps you need to run 'opkg update'? * Failed to download http://shr.bearstech.com/shr-unstable/ipk//armv4t/libevas-engine-buffer_0.9.9.050+svnr39379-r1_armv4t.ipk, error 404 * Failed to download libevas-engine-buffer. Perhaps you need to run 'opkg update'? * Failed to download http://shr.bearstech.com/shr-unstable/ipk//armv4t/libehal0_0.5.0.050+svnr39379-r1_armv4t.ipk, error 404 * Failed to download libehal0. Perhaps you need to run 'opkg update'? .. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 16:43:47 schrieb Tilman Baumann: Looks like the repository is broken. you catched the moment while building with a new EFL_SRCREV :-) while building the packages already built are there, but the index not yet... That might happen quite frequently in shr-unstable ;) Updating the feed should be more atomic. If I might say so. I would suggest uploading in a temp dir and then moving it on the right location. Or uploading dirs with build numbers and after finished just symlinking the new build on the default location. That would not break anyone currently in the process of upgrading. Build has finished now and upgrade should work. Oddly not. Still same error after update,uprade. Is there sill anything uploading? Or maybe not, I just remember that our admin has enabled a transparent proxy. That might give me the old index... -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 17:14:41 schrieb Tilman Baumann: Or maybe not, I just remember that our admin has enabled a transparent proxy. That might give me the old index... that would indeed be bad then :-) Indeed. Luckily there was a alternative route which I could use. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New SHR-Testing release
Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 16:43:47 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann: Klaus 'mrmoku' Kurzmann wrote: Hi all, for those of you who didn't see the blog on Openmoko-Planet or read the SHR Mailinglist... We did publish new testing images. Time for re-install by image or is opkg upgrade safe? See the announcement :-) upgrading from old shr-testing does not work... Sombody even tried it me thinks. Changing the repo config and upgrading from shr- unstable is supposed to work though. Oh, sorry. I was a bit unclear. I was on unstable before and I intend to stay on the bleeding edge. (Or at least see where that brings me...) Question is, what will happen if I do nothing. Is the new unstable a clean continuation of the old unstable or does it break updates? It still is a clean continuation... that might change though some day. Something is odd with this repo. :) See below. Looks like the repository is broken. you catched the moment while building with a new EFL_SRCREV :-) while building the packages already built are there, but the index not yet... Sorry to further pollute this thread. I successfully upgraded. No my desktop is completely empty. No icons whatsoever. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GSM Buzz fix also applicable to GTA01?
I have the feeling my GTA01 would also need the buzz fix. Especially in high antenna power situations I have quite substantial buzzing. That might be new, since I have never seen this before, but I only lately started to use my GTA01 as my main phone, I was more of a land line type before. So my question is basically if the GTA02 buzz fix works for me and is it reasonable to think that I need it? Maybe it can really be fixed with a better alsa state file. GTA02 and GTA01 seem to differ quite substantially in regard to board layout, but I guess the audio schematic does not so much. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Buzz fix also applicable to GTA01?
Joerg Reisenweber wrote: So my question is basically if the GTA02 buzz fix works for me and is it reasonable to think that I need it? Maybe it can really be fixed with a better alsa state file. I'll answer more detailed questions on HW-ML (as you can tell from delay I read [community] rather infrequent). Oh, good to know. I did not know that hardware topics have a seperate list. I have the same problem with the community list. Too much noise, too much unimportant. Basically the answer is: yes applies to GTA01 as well. And no we don't think buzz can be fixed by better statefile neither on gta02 nor on gta01. Does this mean you have a solution for me? Or maybe some upcoming? Or only a conformation that it needs to be fixed too? -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS emergency call standards
Hi, I'm just wondering if there are any open standards for emergency services for location. I'm thinking about services like http://www.steiger-stiftung.de (European, websites in other languages should be available) A SMS to the respective emergency (112, 911) number containing the GPS position could be a start, but then someone has to read it. I would guess there is a standard for a computer readable format. Building a emergency call app would be a nice thing to have. PS: According to Wikipedia, 112 works on all GSM networks no matter if the number is a emergency number in tie state. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS emergency call standards
Am 24.02.2009 um 12:38 schrieb Helge Hafting: Tilman Baumann wrote: Hi, I'm just wondering if there are any open standards for emergency services for location. I'm thinking about services like http://www.steiger-stiftung.de (European, websites in other languages should be available) A SMS to the respective emergency (112, 911) number containing the GPS position could be a start, but then someone has to read it. I would guess there is a standard for a computer readable format. Building a emergency call app would be a nice thing to have. PS: According to Wikipedia, 112 works on all GSM networks no matter if the number is a emergency number in tie state. If you have the gps coordinates, just tell them over the phone as you make the call. They will use it if they have gps eqipment, which is likely. As log as you are able to do so. I'm more thinking about something like a machine readable side channel paralel to a regular emergency call. BTW. the German ADAC is completely helpless if you provide them GPS coordinates. Automating this seems dangerous in that your SMS to the emergency service is delayed by a few minutes as the phone struggle to get the first fix. When you talk, you can fall back on other descriptions of the place (addresses, road names) if coordinates aren't available. Depends, when a GPS fix is made it will be much more precise and quicker. And there seems to be a standard for cars to make automatic emergency calls on accidents. It is called eCall and no technical information is to be found... :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-unstable, GTA01 (neo1973) and GPS?
Jay Vaughan wrote: Hiya, Well, I got SHR-testing up and running on my neo1973 after many recommendations from folks on this list and in the #openmoko channel, and so far it looks pretty nice - can make calls and receive them and so on, and it doesn't crash too much (after I did an opkg update +upgrade), so for now at least the neo1973 seems to be useful for me with SHR-testing .. except for one thing: GPS. Can't seem to get it working. Do we still need to install the gllin package on neo1973? Sure If so, how do I do it 'properly' on SHR-testing? Just opkg install it. (I have my gllin package always on my SD card) Rest should be taken care of by framreworkd. Last time I checked, this worked with FSO and SHR. But, as the flash space on GTA01 with SHR is extremely limited, you will not be able to install Navit. Which is a pitty. You might even get trouble while installing gllin, best you deinstall some crap before since opkg fails very very ungracefully on full file systems. You may need to re flash it to get it working again in when this happens. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-unstable, GTA01 (neo1973) and GPS?
Jay Vaughan wrote: Do we still need to install the gllin package on neo1973? Sure If so, how do I do it 'properly' on SHR-testing? Just opkg install it. okay it doesn't seem to be working for some reason. the gta01 has sat on the window for an hour, no fix .. FR got one in 5 minutes. (I have my gllin package always on my SD card) Rest should be taken care of by framreworkd. Last time I checked, this worked with FSO and SHR. is there anything special to do with the /etc/init.d/* scripts and setup of the /tmp/nmeaP file, like we used to have to do with OM? If nothing is broken, this should do automatically. fso-gpsd should fire up, which does connect to freameworkd. If you connect to gpsd gllin should start. But to be honest, I had mine sitting on the shelf for some time now. But the only thing it get is the GPS-Time. But it could not be totally broken though, because at least I get the time. But it is ondor, maybe the roof changes. It usually works pretty well in this spot. :) But, as the flash space on GTA01 with SHR is extremely limited, you will not be able to install Navit. i opted for a SD-on-root install, with 4 gigs, so this shouldn't be an issue. Btw. Can you share how you did this? Last time I checked this u-boot did not find any partitions. I have the feeling ongoing GTA02 shauvinism had let gta01 information to rot a bit on the wiki. -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-unstable, GTA01 (neo1973) and GPS?
Tilman Baumann wrote: If nothing is broken, this should do automatically. fso-gpsd should fire up, which does connect to freameworkd. If you connect to gpsd gllin should start. But to be honest, I had mine sitting on the shelf for some time now. But the only thing it get is the GPS-Time. I just re started tango and then it instantly had a position. There is probably something racy... -- Imagination is more important than knowledge. Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buy GTA01
I have one. And I would give it away if it brings me any further to a Freerunner which I would not buy right now. Angus Ainslie wrote: Does anyone have a working gta01 they'd like to sell ? Please message me of list if you do. Thanks Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buy GTA01
arne anka wrote: to whom do you prefer to sell? angus or debian/fso, ie luca? Oh, is this really a contest? Honestly I don't care much. Angus was first on the list... price? Ideally the same as a new Freerunner. *g* Who makes the best offer? I would be ready to invest something to upgrade to a Frerunner... -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buy GTA01
Tilman Baumann wrote: arne anka wrote: to whom do you prefer to sell? angus or debian/fso, ie luca? Oh, is this really a contest? Honestly I don't care much. If anyone is interested please contact me off the list. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci wrote: Xavier Cremaschi ha scritto: Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? yes etag i check with this: curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d \ -f 2 do you know a better way? Doen't python have a http lib? Calling external apps is not really the fastest and safest way. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Tilman Baumann wrote: Carlo Minucci wrote: Xavier Cremaschi ha scritto: Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? yes etag i check with this: curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d \ -f 2 do you know a better way? Doen't python have a http lib? Calling external apps is not really the fastest and safest way. Untested code: import httplib conn = httplib.HTTPConnection(tile.openstreetmap.org) conn.request(HEAD, /file...) r1 = conn.getresponse() print r1.status, r1.reason etag = getheader(ETag) print etag And if stuff was new, make GET instead of HEAD -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA01 Qi] doku fuckup and SD-Boot problems
I like to wrap this topic up. First, any idea why booting from flash does not work for me neither with uboot or qi? And second, as it looks like my Qi endeavour was futile, can I use the following command to go back to uboot? nandwrite -p /dev/mtd0 $u-boot-image Or is there some magic that needs to happen? Tilman Baumann wrote: Hi, I have just flashed Qi and have two questions. First, http://wiki.openmoko.org/wiki/Qi clearly states that the boot menu via power+aux will still work. I was sceptical about how that should work since gta01 has no NOR flash. But I trusted the source. Needless to say that there is no boot menu! Am I right in assuming that the wiki is just BS in this regard? If that is so, I like to change the text to warn others. And, how can I get my device in DFU-Mode now? Am I right in assuming that Qi has none? Does this mean that when I trash my rootfs I have no way to re-flash? How would I write a new bootloader (or whatever) to NAND via a running system? And secondly. I did flash Qi because booting from SD with U-Boot as described in the Wiki did not work for me. Somehow u-boot was not able to read the SD (8gb SDHC). (Sorry, I have no exact error message because I stopped debugging when the USB console trashed my hosts USB subsystem) I thought maybe Qi does it right. I have a SD with one ext2 formated partition containing the rootfs and /boot/append-GTA01 and /boot/uImage-GTA01.bin But it still always boots from NAND. I tried /boot/append-GTA01 with rootfstype=ext2 root=/dev/mmcblk0p1 but this did not work either. Any ideas? PS: Remember GTA01! Some people seem to forget them. ;-) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How do you like to read a phone number?
DIN specification for German numbers is AFAIK +49 (1 23) 1 23 45 68 That is, area code in parentheses and each number block in sets of two, but from right to left. (1 23 45 instead of 12 34 5) Alternative variant for area code for not fully canonical numbers is (01 23) ... (0 prefix within the area code) Really a pitty that there is no universal method. But I have to say, i like this one pretty much. Michele Renda wrote: Hello to all I would like to know how do you like to read the phone number: I try to explain: when we read a phone number we usually like to separe it with some spaces or signs: for example in Italy when someone give me a mobile phone number I usually write: +39 347 123456 Or if it is a fixed number: +39 02 123456 or +39 011 123456 But I know in USA is more common something like: +1-212-123456 Please, who has some time, can you please write your country (Italy, France, etc.) and the way how usually is normal to read a phone number in your country (with international prefix) The format I use to descrive is this: +39 ### * or +1-###-* (where # replace a char, and * replace all remaining chars) Thank you a lot for your time Michele Renda ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How do you like to read a phone number?
Tilman Baumann wrote: DIN specification for German numbers is AFAIK +49 (1 23) 1 23 45 68 That is, area code in parentheses and each number block in sets of two, but from right to left. (1 23 45 instead of 12 34 5) Ah, and btw. There is no fixed number length. Phone numbers can range from tree digits to seven and probably more. Some countries seem to have fixed length, so that's probably important. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[GTA01 Qi] doku fuckup and SD-Boot problems
Hi, I have just flashed Qi and have two questions. First, http://wiki.openmoko.org/wiki/Qi clearly states that the boot menu via power+aux will still work. I was sceptical about how that should work since gta01 has no NOR flash. But I trusted the source. Needless to say that there is no boot menu! Am I right in assuming that the wiki is just BS in this regard? If that is so, I like to change the text to warn others. And, how can I get my device in DFU-Mode now? Am I right in assuming that Qi has none? Does this mean that when I trash my rootfs I have no way to re-flash? How would I write a new bootloader (or whatever) to NAND via a running system? And secondly. I did flash Qi because booting from SD with U-Boot as described in the Wiki did not work for me. Somehow u-boot was not able to read the SD (8gb SDHC). (Sorry, I have no exact error message because I stopped debugging when the USB console trashed my hosts USB subsystem) I thought maybe Qi does it right. I have a SD with one ext2 formated partition containing the rootfs and /boot/append-GTA01 and /boot/uImage-GTA01.bin But it still always boots from NAND. I tried /boot/append-GTA01 with rootfstype=ext2 root=/dev/mmcblk0p1 but this did not work either. Any ideas? PS: Remember GTA01! Some people seem to forget them. ;-) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default IP Address on All Distributions
One word. zeroconf Oh, it is two words zeroconf and bonjour www.zeroconf.org/ PS: As fallback for DHCP of course. Esben Stien wrote: Why on earth would you choose 192.168.0.*? This is probably the most common IP address on an internal network in the world and of course this means problems. If your network is configured with this IP range and you pop a freerunner in, it of course cause a world of pain. Please choose a more sensible default. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navit city search ?
Lothar Behrens wrote: Hi, has someone an example of searching a city and a street that works with the germany map when it was downloaded from the quicklink as of the page here lists: http://wiki.navit-project.org/index.php/OpenStreetMaps ? http://wiki.navit-project.org/index.php/OpenStreetMaps#Search_doesn.27t_work_in_most_countries and following... -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ask Sean Moss-Pultz about community matters
Name a application that you would have expected to be made by the the community first but not has been delivered yet? (Something quirky but obvious or just in dire need) Where do you think has the community let you down? Name a aerea where you would have expected more community thrust but has failed. Where do you think could any person do the most for the project right now? Think of if that person would be ideal and have all the skills needed. And then, which skills are in most need right now and in the future? Minh Ha Duong wrote: Dear friends, Sean kindly agreed to be interviewed for the next edition of the Community Update newsletter. I invite every subscriber of this list to post the question or questions that s-he cares about most. No gloves. The general topic is Openmoko, the community, past-present-future, but yours truly will select with undue care the 3-5 most interesting / provocative / popular / relevant / funny / whatever and forward them to Sean next Monday. You may send your questions in this mailing list thread or privately to me. Minh PS: Everybody knows that Sean Moss-Pultz is Openmoko CEO, but you may also be interested to find that many of his past interviews are available here: http://wiki.openmoko.org/wiki/Openmoko:Current_events http://wiki.openmoko.org/wiki/Press_Coverage ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fast screen rotate app
Moritz Bitsch wrote: Hi, thanks for testing. I've fixed the build script and the desktop file. All files are now with PREFIX=/usr. I also fixed the stupid dependency error. A updated ipkg and tgz can be get from here: https://turmspitze.org/files/ I suppose it works now. I'm completely baffled by another problem, which seems unrelated to your app. X/enlightenment or Illume sems to be broken in the recent SHR feed. rotate does not even work with the xrandr command. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fast screen rotate app
Moritz Bitsch wrote: Hi, I've built a small binary package. It can be get from here: https://turmspitze.org/files/rotate_0.0.1_armv4t.ipk A Source package can be get from here: https://turmspitze.org/files/rotate-0.0.1.tar.gz I have just installed your package. The prefix /usr/ is missed on all files. opkg files rotate Package rotate (0.0.1) is installed on root and has the following files: /share/pixmaps/rotate.png /share/applications/rotate.desktop /share/license/rotate/COPYING /bin/rotate That should be all /usr/... And it depends against libx11 which is at least on my distro (shr testing) caled libx11-6. And the .desktop file has misses the Icon field. (Icon=rotate) And your .Rotate name hack looks really ugly in my desktop. I would rather have a alphabetical order instead of this. ;) If the odering of icons turns out to be a problem, we might need some Categoeries hack in the desktop launcher. PS: Hi moritz *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] state of enlightment and illume packaging
mallikarjun arjun wrote: On Mon, Nov 24, 2008 at 3:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello guys, can any one of u tell me how to install e17 on debian??? because i did not find any package when i typed apt-get install enlightenment e17 is unstable, that is why it is not in debian right now. I have recently installed it from source, which turned out quit nicely. No big deal, when you have figured out where the sources are on the enlightenment site. Maybe there are some unofficial debian sources somewhere, i did not bother searching for one because i needed sources anyway. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fast screen rotate app
Carlo Minucci wrote: Tilman Baumann ha scritto: Moritz Bitsch wrote: hi i have made a similar application, can you test on SHR for me? :) you can download from http://minucci.net/file/opkg/ruotami_0.2_all.opk thank you Sure. But I like to point out that I'm rather biased towards mortz's app, because he is my colleague and his app is only a hand full of C. So i woud probably always dig his version. I looked at your app. Here is what i found: 1. Problem Not all Categories in .desktop files are shown. Which distro shows which Categories seems to be a moving target. I changed your categories to Categories=Utilities;Applications; and the icon shows up in my launcher. I don't know if these Categoreis are documented somewhere but this is at least what makes it work on SHR. 2. Problem Your program is not Neo 1973 compatible. [EMAIL PROTECTED] ~ $ ruotami.py Traceback (most recent call last): File /usr/bin/ruotami.py, line 16, in module fb = open(/sys/class/backlight/pcf50633-bl/actual_brightness, r) IOError: [Errno 2] No such file or directory: '/sys/class/backlight/pcf50633-bl/actual_brightness' I guess framework has a interface which you could use here. That would be the only right thing to do on FSO and SHR. (Both using frameworkd) You could ask the FSO guys what to do here. I would have tested your app with the right backlight path (/sys/class/backlight/gta01-bl/actual_brightness), if it would have been a single variable in your script. But it is all over the place. No thanks... ;) 3. The real problem And I have t say, I find your idea of manipulating the .desktop file absolutely revolting. Sorry. It seems to depend on being sliped by ruotami in the first place to get a grip on the current rotation. I like the idea of blanking the screen while rotating. But this needs to be done in some other way. Sorry, zero points for style. ;) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Survey about the Touchscreen
Vikas Saurabh wrote: I think we need to decide upon this without the bias of UIone might get excited with iPhone's UI. What we would have to remember: * capacitive screen would always require a touch of finger (hence all the UI elements need to take enough space on screen) so the whole fun of high reso is gone * otoh, pressure based screen need a little more pressure to react but is often manageable with fingers as well Agree. Either a really big capacitive screen with no boarders or a small hi res screen as currently (I like it) with either a stylus or a keypad. I would vote for the same screen as currently used or at least the same quality but bigger and a keypad. Finger use for the current screen is pretty much a failure. (not impossible but as far as text input goes pretty much failed) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Survey about the Touchscreen
I just want to point out that I will not vote because the vote is bullshit. The type of the screen is not the only thing. Size and resolution matters too. And even more important. Price and availability. What you want is totally unimportant. The question is which compromises are you ready to make? This is nothing that can be figured out by some stupid two options poll. What goes is eventually a question that can only be answered by looking at sold units in retrospect. What you all want is unimportant, because you can not honestly say that it will bias your buying decision in a way you would admit now. I would like openmoko to do bold steps. But they should also be careful. Tilman Baumann wrote: Vikas Saurabh wrote: I think we need to decide upon this without the bias of UIone might get excited with iPhone's UI. What we would have to remember: * capacitive screen would always require a touch of finger (hence all the UI elements need to take enough space on screen) so the whole fun of high reso is gone * otoh, pressure based screen need a little more pressure to react but is often manageable with fingers as well Agree. Either a really big capacitive screen with no boarders or a small hi res screen as currently (I like it) with either a stylus or a keypad. I would vote for the same screen as currently used or at least the same quality but bigger and a keypad. Finger use for the current screen is pretty much a failure. (not impossible but as far as text input goes pretty much failed) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost FreeRunner
Matthias Apitz wrote: El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz escribió: Hello Stacy, I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/ and as an owner of the FreeRunner I will build this nice box; thanks for your pioneer work on this; ... Shouldn't it be easy to add this 'wall charger indicator resistor' to the mintyboost circuit? I don't remember where that resistor needs to go, but this can be researched on the wiki... -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost FreeRunner
Matthias Apitz wrote: El día Thursday, November 20, 2008 a las 01:47:43PM +0100, Tilman Baumann escribió: Matthias Apitz wrote: El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz escribió: Hello Stacy, I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/ and as an owner of the FreeRunner I will build this nice box; thanks for your pioneer work on this; ... Shouldn't it be easy to add this 'wall charger indicator resistor' to the mintyboost circuit? I don't remember where that resistor needs to go, but this can be researched on the wiki... What would be the bennefit of this? I'm not an electronic guy anymore :-( 1A charging out of the box with no software needed. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost FreeRunner
Matthias Apitz wrote: El día Thursday, November 20, 2008 a las 02:04:22PM +0100, Tilman Baumann escribió: Matthias Apitz wrote: El día Thursday, November 20, 2008 a las 01:47:43PM +0100, Tilman Baumann escribió: Matthias Apitz wrote: El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz escribió: Hello Stacy, I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/ and as an owner of the FreeRunner I will build this nice box; thanks for your pioneer work on this; ... Shouldn't it be easy to add this 'wall charger indicator resistor' to the mintyboost circuit? I don't remember where that resistor needs to go, but this can be researched on the wiki... What would be the bennefit of this? I'm not an electronic guy anymore :-( 1A charging out of the box with no software needed. Here is what the Wiki page says: http://wiki.openmoko.org/wiki/Neo_FreeRunner_Battery «DIY external battery pack from a Minty case Mintyboost: Charge from a couple of AA batteries: Minty Boost!, report on a Neo FreeRunner application. Adding the 47k resistor to the minty boost so that the Freerunner fast charges at 1A is a poor idea for a couple reasons, the biggest one being that the minty boost can't supply 1A the max is 600mA. Ups, that's a pitty. I did not anticipate this. Even if the Linear Technology step up voltage converter is supposed to be able to do 600mA, the AA cells seem to have a problem with supplying 500mA. They get a little toasty :-). One powerpack built using D cells doesn't seem to have any issues with supplying 500mA.» Well, Batteries usually put out a great much of current without suffering too much. I could not find any specifications (which of course vary) on a short notice, but I don't think that 5W (plus a little bit loss in the converter) is too much. Maybe we just need to make a heavy duty mintyboost with a bigger converter... My FR switches outomagically to 1A charging mode, but maybe it's better to only use 500mA Probably. The reports of hearing the converter when it is under load support this. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost FreeRunner
Cédric Berger wrote: On Thu, Nov 20, 2008 at 15:14, Matthias Apitz [EMAIL PROTECTED] wrote: Adding the 47k resistor to the minty boost so that the Freerunner fast charges at 1A is a poor idea for a couple reasons, the biggest one being that the minty boost can't supply 1A the max is 600mA. as far as I know, there is no magic resistor to identify a 500mA charger to the Freerunner, it depends on USB host telling it that it can provide 500mA. Yes 1A is a lot. I am not an electronician but would not it be possible to have a little circuit in the minty boost limiting current to 500mA (or other value), even though the freerunner tries to get 1A ? Nope. Current is a effect not a cause. *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new application: AaTerm-terminal (patched openmoko-terminal2)
Aapo Rantalainen wrote: Instructions and package: http://www.cs.helsinki.fi/u/rantalai/freerunner/aaterm/ Tell me what is missing? Well, looks nice. (From a user point of view) I really like the idea of the right side toolbar. Some questions. Does it invoke the keyboard when you select the text area? (illume keyboard) The current terminal does not, which is rather annoying. And what is this copy button for, intuitively I would think there is a paste button missing. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new application: AaTerm-terminal (patched openmoko-terminal2)
Tilman Baumann wrote: Aapo Rantalainen wrote: Tell me what is missing? I just installed it. Some questions. Does it invoke the keyboard when you select the text area? (illume keyboard) Does not, pitty. The current terminal does not, which is rather annoying. And what is this copy button for, intuitively I would think there is a paste button missing. I just got the idea how that works. Not bad. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What theme is this?
Richy wrote: I think hire did create the colorful theme. You should be able to catch him in #openmoko-cdevel I did. It was not him. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What theme is this?
Leonti Bielski wrote: Hi! I found this image on scap.linuxtogo.org http://scap.linuxtogo.org/files/cb247f8d70308d5fec6a479c329e75f3.png There are also some other themes. Where I can download it? Who is making it? Thanks. Leonti I agree it looks nice. And as we are on this topic. I think this theme http://scap.linuxtogo.org/files/4dc340d6661464ca15a0789011cdd3c6.png is ingenious! I never liked the grey theme. Bright colours on black are the way to go. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[shr] phone apps don't work
I have problems with all openmoko-* apps regarding GSM/SIM. But strangely the GSM applet shows i have service. I have collected some messages from the console output. Maybe they have a common cause which i can fix. Because i really like to use shr, because it has just the right gui and the right philosophy in general. openmoko-dialer starts, bu when i press call this comes: ** (process:1401): DEBUG: initiate call: 076145CENSORED Failed to handle dbus error: type: class 'framework.resource.ResourceNotEnabled' , 69 (dbus-glib-error-quark), code 32 (Sorry for bad line breaks, emails suck for this kind of info) openmoko-contacts (dies instantly) Trying to get the system bus Adding signals. ** (process:1215): DEBUG: phonegui_init() ** (process:1215): DEBUG: Entering ecore loop ** (process:1215): DEBUG: phonegui_contacts_show() ** (process:1215): DEBUG: Initiated elementary ** (process:1215): DEBUG: Initiated etk ** (process:1215): DEBUG: Added exit callback to ecore. ** (process:1215): DEBUG: event_callback() ** (process:1215): DEBUG: contacts_event(), event: 0 ** (process:1215): DEBUG: window_create() ** (process:1215): DEBUG: Adding delete-request-callback ** (process:1215): DEBUG: contacts_event(), event: 1 openmoko-messages (also never comes up) Trying to get the system bus Adding signals. ** (process:1217): DEBUG: phonegui_init() ** (process:1217): DEBUG: Entering ecore loop ** (process:1217): DEBUG: phonegui_messages_show() ** (process:1217): DEBUG: Initiated elementary ** (process:1217): DEBUG: Initiated etk ** (process:1217): DEBUG: Added exit callback to ecore. ** (process:1217): DEBUG: event_callback() ** (process:1217): DEBUG: messages_event() ** (process:1217): DEBUG: Event: 0 ** (process:1217): DEBUG: window_create() ** (process:1217): DEBUG: Adding delete-request-callback ** (process:1217): DEBUG: messages_event() ** (process:1217): DEBUG: Event: 1 -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] SHR image released
GSM is flaky, but I can not put my finger yet on any specific faults. But shutdown is broken. If I shutdown from X, the screen will freeze at some time and shutdown seems to abort some way. I had to reset the device. If I shutdown with X stopped, I see dozens of exquisite errors, but it eventually shuts down. But all after all I'm extremely pleased with this distro. I know it is not done yet, but this is my favourite from now on. ;) Enlightenment/Illume crashes from time to time, but this seems to be normal on every distro I had so far. PS: gta01 PPS: Nice fit $ df -h / FilesystemSize Used Available Use% Mounted on rootfs 61.1M 59.8M 1.3M 98% / David Garabana Barro wrote: Anyone? http://wiki.openmoko.org/wiki/SHR Images: http://shr.bearstech.com/shr-testing/images/neo1973/ It's pretty, seems stable, is *fast* (for me faster than FDOM and FSO M3 for sure) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] SHR image released
Julien Cassignol wrote: PS: gta01 This is interesting. We had issues on GTA01, could you please come and join us on #openmok-cdevel on freenode, to give more input for us think about? Channel seems empty. I'm that DPThought dude there. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] SHR image released
Tilman Baumann wrote: Julien Cassignol wrote: PS: gta01 This is interesting. We had issues on GTA01, could you please come and join us on #openmok-cdevel on freenode, to give more input for us think about? Channel seems empty. I'm that DPThought dude there. Doh, typo. Never mind. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] SHR image released
Julien Cassignol wrote: On Thu, Nov 13, 2008 at 5:49 PM, Lech Karol Pawłaszek [EMAIL PROTECTED] wrote: ;-) I can confirm this. I've just flashed SHR and USB networking doesn't work unless you restart networking. This is weird and unheard of on our side. I flashed the image and had no problem last time. Did you flash the kernel too? I just like to report that I have no USB networking issues at all. I have of course the right kernel and i have a gta01. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IMAGE/MP3 licensing issue.
In-Reply-To: [EMAIL PROTECTED] Very professional :-/ Ray Chao wrote: Dear Community; We are sorry that currently we have to remove all the images on the download server of Openmoko. http://downloads.openmoko.org/release/ We will make another stable release as soon as possible. At the mean time, we could rebuild those old releases without mp2/mp3. However, this might not stable due to the missing packages and we have no capability to test them all. So, ladies and gentlemen, please let us know, if you want these old and unstable images or any other ideas. Any feedback are welcome, and please, let us know what you think on this one. Ray Chao Openmoko System Admim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IMAGE/MP3 licensing issue.
Oh, I'm really sorry. I read your mails in the wrong order. Pardon, no hard feelings please. ;) Tilman Baumann wrote: In-Reply-To: [EMAIL PROTECTED] Very professional :-/ Ray Chao wrote: Dear Community; We are sorry that currently we have to remove all the images on the download server of Openmoko. http://downloads.openmoko.org/release/ We will make another stable release as soon as possible. At the mean time, we could rebuild those old releases without mp2/mp3. However, this might not stable due to the missing packages and we have no capability to test them all. So, ladies and gentlemen, please let us know, if you want these old and unstable images or any other ideas. Any feedback are welcome, and please, let us know what you think on this one. Ray Chao Openmoko System Admim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-control
Nice
This adds some long missing featues.
Some way to invoke the illume lock thing as it did in early previews
with the aux button would be great. Regarding the lock button... ;)
Invoking it via power button does not work tough. I still get the wired
'keep pressed, let go, ...' dialog which seems like a nice idea but does
not work well and i don't get the concept...
digger vermont wrote:
Hello,
Here's something I'm working on, fso-control.
http://mysite.verizon.net/~digver/apps/fso-control.tar.gz
Uses python and edje to control the state (suspend, reboot, shutdown)
with frameworkd. It's not unlike what I remember 2007.* and 2008.*
having when the POWER button is pressed.
Some points
* install.sh will cp the files to install but its probably safer
to do it manually.
* It works from the desktop icon
* lock and more buttons currently do nothing.
* Add a rule to /etc/freesmartphone/oevents/rules.yaml
---
trigger: InputEvent()
filters:
- HasAttr(switch, POWER)
- HasAttr(event, pressed)
actions: Command('fso-control')
* Why doesn't it work from the POWER button?
I asked about in devel list.
http://n2.nabble.com/-FSO-testing--Can%
27t-start-GUI-with-oevents-rule.-td1389692ef1958.html;cid=1225223928263-321
* With fso-testing /etc/dbus-1/system.d/frameworkd.conf has an error:
Its changed in frameworkd.git.
--
policy user=root
allow own=org.freesmartphone.ousaged/
- allow send_path=/org/freesmartphone/usage/
+ allow send_path=/org/freesmartphone/Usage/
allow send_destination=org.freesmartphone.Usage/
allow receive_sender=org.freesmartphone.Usage/
/policy
* I plan to add control of the various radios.
* I plan to figure out how to package it.
* Think thats all. Hope it works!
digger
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: New Rasterman Image...
Where does FSO stand in regard to rasters releases? Is FSO bleeding edge on Illume and co? I would like to have them in FSO. Since this is the distro i trust the most right now for delivering me the newest and greatest stuff that will also work on my gta01. Marco Trevisan (Treviño) wrote: In the enlightenment archives there's a new Rasterman image: - openmoko-illume-image-glibc-ipk--20080929-om-gta02.rootfs.jffs2 [1] It looks so cool with the new illume theme [2] [3] [4] [5] [6], but practically it has no telephony related software installed in since it seems a simple OE built with these scripts [7], so (I figure) that you're free to put in both the FSO and/or the Om2008.8 stack, just install the needed packages! Bye. [1] http://download.enlightenment.org/misc/Illume/ [2] http://forum.telefoninux.org/index.php/topic,533.0/topicseen.html [3] http://www.rasterman.com/files/illume-01.ogg [4] http://www.rasterman.com/files/illume-02.ogg [5] http://www.rasterman.com/files/illume-03.ogg [6] http://www.rasterman.com/files/illume-04.ogg [7] http://www.rasterman.com/files/oe-setup.tar.gz -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
Carsten Haitzler (The Rasterman) wrote: really hard to scroll and not to miss and then, by so many scrolls around, i usually accidentally trigger another app. I even tried setting double tap :) What about paging while scrolling? Going up or down given pages seems easier for me than having to scroll around and always miss... or? i don't plane to touch the launcher as it is as it is just a filemanager icon view widget. i do intend to actually pretty much nuke it in favor of a much better launching mechanism/idea. not just launching apps too - though i now note that android is kin of doing this (put not just apps but contacts, clocks, calendars etc. on your home screen anywhere u like - and at any size). a launcher with a list of apps could be once such desktop gadget type I like the idea. And just for a useless opinion from me, the Nokia770 desktop had something like this. They allowed free positioning of elements with various sizes. The effect whas a cluttered appearance and a real pain to position the widgets in a nice way. And many of these elements wasted just some pixels too much to bring them into position next to each other with others. Especially on a phone i would like the container to control size and placement of the gadgets. The gadget designer could still decide how many 'units' he wants and shape his elements like tetris blocks but the container would enforce placement and size. As i said, this is at the moment a useless idea. But i wanted to share my experience with a floating unconstrained gadget layout. *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
Petr Vanek wrote: On Tue, 23 Sep 2008 15:48:07 -0700 Kelvie Wong [EMAIL PROTECTED] (KW) wrote: On September 23, 2008 15:16:26 wp wrote: http://server6.theimagehosting.com/image.php?img=artconcept1.png These look really nice :) One problem I see, though, it seems that without a stylus, the links (and just hyperlinks in general) are _really_ hard to press. I think we should be optimizing for finger-based usability instead. What you say makes sense. Just think about the REMOVE link in Shelve. 80% impossible without a stylus. But as far as the REMOVE link stays as it is and one has a stylus in his hand already, than the small links are actually OK. So the whole concept has to go either one direction or another. I would like to have the 'remove' button in the upper right corner as a big button (named close not remove) which i can press with my thumb. This would even make one handed finger use possible. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
woho! I see great things to come. I like the slider checkbox from illume-02.ogg And the keyboard zoom thing. But i also really like WP's idea for a desktop shelf homescreen with info screen and quicklauncher. And if i may throw some ideas in the pot too. * Move the Remove button as bigger button to the top right corner of the (opened) illume slider. (As proposed in my earlier mail) * App launcher as scrollable list like in the 2008.2 home screen. (with sections as in 2008.2 too) Carsten Haitzler (The Rasterman) wrote: On Wed, 24 Sep 2008 18:00:56 +0200 DJDAS [EMAIL PROTECTED] babbled: shameless plug: http://www.rasterman.com/files/illume-01.ogg http://www.rasterman.com/files/illume-02.ogg http://www.rasterman.com/files/illume-03.ogg http://www.rasterman.com/files/illume-04.ogg new (incomplete though) theme with e's new scaleability options enabled and demos in multiple dpi's and resolutions - keyboard had a few minor tweaks. theme is INCOMPLETE. definitely not done, but on its way. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
Am 25.09.2008 um 00:36 schrieb Carsten Haitzler (The Rasterman): On Wed, 24 Sep 2008 19:26:21 +0200 Tilman Baumann [EMAIL PROTECTED] babbled: woho! I see great things to come. I like the slider checkbox from illume-02.ogg that's not part of e/illume - it's a quick and simple toolkit i am writing though. Great. A phony (pun) toolkit seems to be the last thing missing for world domination, or at least world satisfaction. :) And if i may throw some ideas in the pot too. * Move the Remove button as bigger button to the top right corner of the (opened) illume slider. (As proposed in my earlier mail) why top right as opposed to top-left? does it matter? as such the close cutto n consumes the entire space that the visible shelf region has (just slid down ) - just the icon uses a sub-section of it, but the hit area is large. (and as such the theme is able to just do this - no code changes needed). The top right corner is not used and easily reachable with your thumb if you hold the phone just in one hand. I tried how it would feels, and i think it's the best position. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
fso bug/oddity
dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged, org.freedesktop.Gypsy.Satellite.SatellitesChanged and org.freedesktop.Gypsy.Time.TimeChanged signals. But GPS is off. I think neither of the events makes sense in this case and wastes cycles. Probably not good for battery life. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Tilman Baumann wrote: dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged, org.freedesktop.Gypsy.Satellite.SatellitesChanged and org.freedesktop.Gypsy.Time.TimeChanged signals. But GPS is off. I think neither of the events makes sense in this case and wastes cycles. Probably not good for battery life. I just had a look at the fso apis again. And i almost fell of my chair. I just found org.freesmartphone.Device.RealtimeClock What is wrong with gettimeofday anc co with all it's beauty? Who wants time via dbus? I hope this is just some over enthusiastic proof of concept. *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Michael 'Mickey' Lauer wrote: Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann: Michael 'Mickey' Lauer wrote: Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann: Tilman Baumann wrote: dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged, org.freedesktop.Gypsy.Satellite.SatellitesChanged and org.freedesktop.Gypsy.Time.TimeChanged signals. But GPS is off. I think neither of the events makes sense in this case and wastes cycles. Probably not good for battery life. I just had a look at the fso apis again. And i almost fell of my chair. I just found org.freesmartphone.Device.RealtimeClock What is wrong with gettimeofday anc co with all it's beauty? Last time I checked gettimeofday reads from system time. org.freesmartphone.Device.RealtimeClock is a dbus interface to program the RealtimeClock (sic!). My mistake. But what about /dev/rtc and the hwclock command? programming /dev/rtc works fine from C and asm, much less so for higher level languages. But they will however probably never be in a position where they need to. Keeping the rtc in sync sounds to me like a framework job. I don't know, the system clock should probably be stored in rtc before going to sleep and saved back afterwards. And the usual stuff, shutdown and booting. I felt a dbus interface for that would be nice. It's not in use yet, but we need something like that anyways when we want to support waking up arbitrary dbus clients for PIM events. What about a interface where a process can register a timer event for a callback/dbus signal? Getting and setting stuff to the clock does not sound to me like something that needs to be exposed as a interface. Sorry if my sarcasm sounded too harsh. It isn't all that bad. ;) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Michael 'Mickey' Lauer wrote: I felt a dbus interface for that would be nice. It's not in use yet, but we need something like that anyways when we want to support waking up arbitrary dbus clients for PIM events. What about a interface where a process can register a timer event for a callback/dbus signal? Getting and setting stuff to the clock does not sound to me like something that needs to be exposed as a interface. Ok, how would you design it then? Lets say we have a couple of clients who know about certain appointments and every time you go into suspend, you need to find out which client knows about the soonest appointment and have the RTC programmed accordingly. The back end only needs to keep the soonest timer in the clock and change to the next if the time passed. And emit messages when a timer is passed. How do these programs know each other? Are all supposed to concurrently program the RTC? = Boom. That's why i'm suggesting this abstraction. Programms should never set the rtc. They should just tell the backend that they need a timer for a specific time, and the backend can then make sure the system is running at this time and inform the client about the event. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Michael 'Mickey' Lauer wrote: It's important though that people understand why we need all these abstractions. It's not because we love high level interfaces, it's because we need to prepare for application _integration_. Yea, but there are things which are already solved and people are used to work with them. Integration could well go over the top. As i probably already said. I like the effort, but some things are better left alone. :) Not that i have some spcific critique right now, but i could easyly see fso going in that direction. That's why i reacted this way in this case, i thought it had happened. *g* I see fso walking a fine line between genius and insanity. :) settingsd vs. gconf would be one of these cases. I just refused to really think about it yet, so i don't really know how much sense it makes. I think i would not like the outcome... (gconf is horrible, but it was there long enough to be considered a standard...) pimd vs. eds the same... -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Michael 'Mickey' Lauer wrote: How do these programs know each other? Are all supposed to concurrently program the RTC? = Boom. That's why i'm suggesting this abstraction. Programms should never set the rtc. They should just tell the backend that they need a timer for a specific time, and the backend can then make sure the system is running at this time and inform the client about the event. Heh, sounds we're on the same page then. org.freesmartphone.Device.RealtimeClock always belonged to the lower level dbus interfaces in my thinking (as are most of the other .Device.* ones). I want to use this from the PIM agent, but not from any app. Aaah, yes the Device namespace. Makes sense. But why not cut the intermediate layer? the pim agent will most likely be not the only app which needs wakeup times. But i guess we have the same idea about how it sould be. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Federico Lorenzi wrote: On 9/17/08, Tilman Baumann [EMAIL PROTECTED] wrote: I see fso walking a fine line between genius and insanity. :) settingsd vs. gconf would be one of these cases. I just refused to really think about it yet, so i don't really know how much sense it makes. I think i would not like the outcome... (gconf is horrible, but it was there long enough to be considered a standard...) pimd vs. eds the same... Just because something has been around long enough to be considered a standard, doesn't make it a good one. Look at .doc, it has been around for a few years (in one incarnation or another), but does that make it a good standard? No, but something where you need to carefully think about before you waste resources on replacing it and nobody wants it. ;) And i don't say we should all use .doc, that's something where the ugly penalty is too great. *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Michael 'Mickey' Lauer wrote: I see fso walking a fine line between genius and insanity. :) Agreed. But you'll never know on which part you walk unless you start moving. That's what we're doing atm. Please help us to stay on the genius' path ;) Happyly. At the moment i'm just observing the show. My time management for private projects is currently just horrible. I always feel bad talking about doing great stuff and never doing it. :) settingsd vs. gconf would be one of these cases. I just refused to really think about it yet, so i don't really know how much sense it makes. I think i would not like the outcome... (gconf is horrible, but it was there long enough to be considered a standard...) Hmm, that doesn't count for me as a stopsign. First, gconf is already deprecated by the powers (with dconf being the dbus-based successor they work on), O i did not notice. But i guess the api and namespaces will stay? 2nd being a standard doesn't necessarily mean it should stay there forever unquestioned. Certainly not. But i see the influence from the desktop to the phone as more important and fruitful as the other way around. (For being in the position to change the world) pimd vs. eds the same... Again, lets first concentrate on sane APIs (which is what the GSoc'08 project did) and then check whether any of the existing solutions fit our needs. Right. Full steam ahead! -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
