Re: [maemo-developers] IT2006 development problems - HildonProgram and HildonWindow
2006/7/16, Steven Hill <[EMAIL PROTECTED]>: In the documentation for the new UI using HildonProgram andHildonWindow, we see the following, both in the porting instructions andin the "developing new application" doc:"/* Begin the main app */ gtk_widget_show ( GTK_WIDGET ( program ) );gtk_main();"where "program" is a pointer to HildonProgram - this statement generates apile of run-time errors because HildonProgram is not a GTK_WIDGET and has no "visible" properties. Obviously this is wrong.In addition - the old UI with HildonApp had the very useful method "hildon_app_set_appview"What is the replacement of this with HildonProgram and HildonWindow? - I see only methods like hildon_program_add_window and ...remove_window, but how do we know which of the registered windowsis the window that is currently being shown by HildonProgram??This new UI is confusing to me... can anyone help clear up the confusion? Steve Hill___maemo-developers mailing listmaemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers Hello! hildon_window_get_is_topmost () gbooleanhildon_window_get_is_topmost(HildonWindow *self); self : A HildonWindow Returns : Whether or not the HildonWindow is currenltly activated by the window manager. Laci ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
On Sat, 2006-07-15 at 23:19 +0300, Tomi Ollila wrote: > Philip Van Hoof <[EMAIL PROTECTED]> writes: > > > > > If somebody feels brave, feel free to assist me in getting it 4 byte > > aligned ;-). I don't have a lot experience here. > > (((char *)address + 3) & ~3) I simply use this on each char* pointer? That's it? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Gazpacho problem
hi all, i m trying to install gazpacho following the instruction in the "how to" section but i fail all the times. I downloaded the three pachages from repository.maemo.org/pool/mistral/free and i installed them inside scratchbox. Then i m trying to run the application following the commands from the how to. I always get some warnings and some errors and nothing more. Also i have the beta version of maemo 2 installed and not the final. Is there any problem with that? Does anyone have an idea to solve the problem? regards, dionysis ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: The fixes11 mmap patch doesn't respect data alignment on some architectures
Hi there everybody who so far assisted me in trying to get the mmap-for- camel patches to correctly data aligned. Thanks. I will repeat the situation so that everybody has a clear idea of what and why about this E-mail. During the last weeks, I worked on Camel's summary loading. The summary which Camel (a framework for E-mail access being used by Evolution and tinymail) loads is typically used by E-mail clients like Evolution and tinymail for displaying the summary. The summary is a view with mostly headers like the "date received", the "from" and the "subject" headers. Most E-mail clients have this and as you might think, this is indeed one of the most memory and cpu consuming ui pieces of a E-mail client. Therefore I decided to mmap() this information rather than the current fread implementation being used by Camel. You see, tinymail is targeted for small devices with very few memory availability. Yet tinymail promises displaying a lot such headers (more than 10,000). Tinymail can already do this on a device like the Nokia 770. Even with the fread implementation. But as a passionate software developer, I want more. You can read some technical information on the mmap stuff here (and on the Evolution hackers mailing list, and on other GNOME blogs). http://pvanhoof.be/blog/index.php/the-camel-mmap-summary-stuff-what-is-this-all-about/ I want to display 150,000 headers. And I'm certain this is possible if I make sure only the visible headers are really in memory. I know doing that is possible, and I know the shortest path to getting their (going from A to C without passing B) is mmap. That is the reason why I did these Camel patches. Surprise, on a x86 architecture I'm already at B. This is actually working stuff on certain architectures. On architectures that require data aligned access to memory, however, this isn't working. An example of a device using such an architecture is the Nokia 770 which has an ARM cpu. The Nokia 770 *is* definitely a target device for tinymail. I have been trying, with very few experience with ARM and such data aligned memory access, to get the patch to become data aligned. I've received some very useful pointers and information. As Freddie Mercury once said: "I thank you all". I don't have debugger infrastructure for the Nokia 770, nor do I have an emulator running where I can actually use a debugger on. Nor do I have good testing infrastructure myself. So this is making it harder for me to get it right (I'm thinking the problem is a very small one). Using all these hints and tips, I cooked this version of the patch (you'll find an URL below). I will describe how you can get your hands dirty quickly: It's possible that evolution-data-server is already migrated to GNOME's Subversion (this migration is happening these days). Nevertheless should this anonymous CVS infrastructure still work and is this patch based on the anonymous CVS repository. cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/gnome co evolution-data-server cd evolution-data-server/camel patch -p0 < thepatch cd .. ./autogen.sh --prefix=/opt/camel && make && make install The most important files are camel-file-utils.c and camel-folder-summary.c. There's also some ./providers/*/*-summary.c files that are also reading things from the mmap memory (like some version integers). You can get yourself a simple test E-mail client using tinymail: svn co https://svn.tinymail.org/svn/tinymail/ cd tinymail/trunk export PKG_CONFIG_PATH=/opt/camel/lib/pkgconfig ./autogen.sh --prefix=/opt/tinymail && make && make install You can configure an account in tinymail using this simple script: http://pvanhoof.be/files/tny-account-create.sh If you go "online" and open a folder, it will create "summary" files in for example: $HOME/.tinymail/mail/imap/$hostname/folders/INBOX/summary It's that file (for your INBOX folder) that will be mmap-ed if you close that folder and re-open it (or if you restart the application). This is the original patch that didn't care about data alignment at all. This patch works: http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11.diff This is my 3th attempt to get data alignment correct. It's not working on a Nokia 770. It will (when the loading of the mmap stuff happens) get killed. On the tty, it will print "Killed". http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment03.diff The camel_folder_summary_load method is where all this starts. On Sat, 2006-07-15 at 10:15 +0200, Philip Van Hoof wrote: > On Fri, 2006-07-14 at 17:15 -0400, Jeffrey Stedfast wrote: > > ah, you're going to have to pad strings and possibly other stuff. > > The pstrings themselves and the 7bit encoded unsigned 32 integer bytes. > Since data padding on ARM is 4 bytes (32bit), unsigned int32 will be > aligned correctly? So the header, references and extra information per > provider is mostly going to work out fine. But for example the count in > front of the references, the length-
Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
Philip Van Hoof <[EMAIL PROTECTED]> writes: > On Sat, 2006-07-15 at 23:19 +0300, Tomi Ollila wrote: >> Philip Van Hoof <[EMAIL PROTECTED]> writes: >> >> > >> > If somebody feels brave, feel free to assist me in getting it 4 byte >> > aligned ;-). I don't have a lot experience here. >> >> (((char *)address + 3) & ~3) > > I simply use this on each char* pointer? That's it? Something like it... you just have to ensure there is enough space at the end (i.e aligning requires that there is 1-3 bytes more space for the data). Also, maybe better (or worse!) is (char *)(((int)address + 3) & ~3), assumed that sizeof (char *) == sizeof (int). This latter version seems to compile... ... this too: (char *)((int)((char *)address + 3) & ~3));, but that is not any better (in sizeof comparisons...). > Philip Van Hoof, software developer at x-tend Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
Assuming you are building the structures yourself, you might also try this:
typedef union ALIGNED_STRING
{
uint32 aligner;
char string[MAXLEN];
} ALIGNED_STRING;
Then declare all strings within your structures using ALIGNED_STRING:
struct MyHeaderSummary
{
int16 foo;
char bar;
ALIGNED_STRING text;
};
Of course, you then access the contexts of .text as ".text.string. In
*theory* (as in "I have not tried this myself") the presence of the
uint32 in the union should force the compiler to align the union.
Of course, in theory you could also skip the typedef:
struct MyHeaderSummary
{
int16 foo;
char bar;
union
{
uint32 dummy;
char string[MAXLEN];
};
};
Lastly, if you don't mind a GNUCC`ism in your code, you could use
__attribute__
struct MyHeaderSummary
{
int16 foo;
char bar;
char string[MAXLEN] __attribute__ ((aligned (4)));
};
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
> Very cool! > > Great thing, thanks a lot! > That will definitely help. Let's just hope that the "regular users" We still have to make it happen. I hope enough Maemo developers get their hands on it so we can achieve and sustain enough interest and activity to keep it going and even grow in scope. We are piloting the use of Sardine for development of the HAF at Nokia, so there will be in any case Nokia people working with it and therefore finding and fixing its problems. But we need developers outside Nokia to join in, to really make it take off. At this point, what is really important is to try it out and report problems. Right now, the best place to do it is this list. > really get the "smell" and stay away (and so do not cause too many cries > for support). > I'm pretty sure they will stay away. The announcement and web pages are pretty discouraging for end users ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] A good debugger infrastructure
I'm very sure this is well known by Nokians, Nevertheless I'd like to re-empathize that software developers working on embedded devices like the Nokia 770 are very much in need of a good debugging infrastructure like gdbserver. Please give it a high priority. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
> Smells good, thanks :) :) > One more reason to have rootfs on mmc and dual boot working. Time to > hack initfs to boot from second (ext2) partition on my 1gig card. That would be really good to have. I'd definitely use it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
On Thu, 2006-07-13 at 17:45 +0300, Carlos Guerreiro wrote: > Now, The Sardine is finally on the grill! Great! Carlos, are there any plans to start organising the meetings we asked for during the BOF? I think the more early those get started, the better. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
> > Now, The Sardine is finally on the grill! > > Great! > > Carlos, are there any plans to start organising the meetings we asked No concrete plans yet but a clear understanding that they are needed and will happen soon. > for during the BOF? I think the more early those get started, the > better. Agreed. One thing we need to do first and is on my todo list is to setup a page in the Maemo Wiki to present the results of the BOF and follow up the consequent action. I hope to have that done very soon. Br, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
On Sun, 2006-07-16 at 19:49 +0300, Carlos Guerreiro wrote: > > Carlos, are there any plans to start organising the meetings we asked > > No concrete plans yet but a clear understanding that they are needed and > will happen soon. > > > for during the BOF? I think the more early those get started, the > > better. > > Agreed. One thing we need to do first and is on my todo list is to setup > a page in the Maemo Wiki to present the results of the BOF and follow up > the consequent action. I hope to have that done very soon. Hey Carlos, Your efforts to get Nokia and Maemo even more close to the community are inspiring. Please continue. Thank you. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Sun, Jul 16, 2006 at 06:10:18PM +0200, Philip Van Hoof wrote: > Nevertheless I'd like to re-empathize that software developers working > on embedded devices like the Nokia 770 are very much in need of a good > debugging infrastructure like gdbserver. Could you please be more specific? -- Misha signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Sun, 2006-07-16 at 21:45 +0400, Mikhail Sobolev wrote: > On Sun, Jul 16, 2006 at 06:10:18PM +0200, Philip Van Hoof wrote: > > Nevertheless I'd like to re-empathize that software developers working > > on embedded devices like the Nokia 770 are very much in need of a good > > debugging infrastructure like gdbserver. > Could you please be more specific? Running gdbserver on the device. Or is that already possible? Afaik it's not. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Tinymail using mmap() gets killed by the kernel of the device
Hi,
>>>(((char *)address + 3) & ~3)
>> I simply use this on each char* pointer? That's it?
There shouldn't be any need for aligning addresses manually if the code
is done properly using correct types, sizeof() & offsetof() and not
trying to cast pointers to something that needs larger alignment.
-Wcast-align gcc option warns about the last one, but it
can show some false positives.
Only instance when you need to do alignment manually instead of
letting the compiler do it automatically for you is if you want
to have the same data to be readable by programs running on
different architectures, or compiled with different compiler
or compiler options (affecting the sizes of things.
Otherwise one just needs to be careful.
So, what is done to this so that it breaks:
struct MyHeaderSummary
{
int16 foo;
char bar;
char text[SOMELEN];
};
?
(If program saved stuff like this as a snapshot from memory,
it should obviously be able to be read it back to memory too.)
As to this:
struct MyHeaderSummary
{
int16 foo;
char bar;
char string[MAXLEN] __attribute__ ((aligned (4)));
};
If the point of this is to align the "string" member as a pointer
would, 4 is not correct alignment for 64-bit architectures.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
