Re: glib on Symbian
>Kalle Vahlman wrote :-
>>Wrong. Symbian does not support static data in DLL:s in all versions out
there:
Please refer to the following link for the updated latest version of the
document :-
http://developer.symbian.com/main/downloads/papers/static_data/SupportForWriteableStaticDataInDLLs.pdf
The SYMBIAN OS EKA2 emulator only allows a DLL with WSD to load into a
single process
Hence for Support for emulator WSD
Symbian OS v9.4 provides emulator WSD (EWSD library), a mechanism to allow
DLLs
with WSD to be able to load into multiple processes. The support is not
transparent to the DLL writer;
they have to wrap the WSD in a data structure and pass it to the EWSD
library.
This library maintains the relationship between the library, and its WSD
values in each process.
The DLL writer has to make emulator-conditional changes to the source code
to:
? wrap all the WSD in the DLL into a single ?wrapper? data structure
? change code to refer to the wrapper data member rather than directly
? prevent EPOCALLOWDLLDATA being declared in the emulator build
For example, consider a DLL with a function foo() that uses WSD iState as
shown:
// source for foo.cpp
int iState;
void foo()
{
if (iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
You would change as shown:
// source for foo.cpp
struct MyWSD
{
int iState;
};
void foo()
{
#ifdef _USE_EWSD_
MyWSD *MyWSDPtr = Pls(ThisLibUid);
// Pls is an API provided by the ewsd - it fetches the ptr for this
// (process,libuid) tuple.
// You can also pass an initialisation function to Pls() to initialise the
WSD
// ? initialisation is only done the 1st time the templated function is
called
#endif
10
if (MyWSDPtr->iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
The MMP file of that DLL must not have EPOCALLOWDLLDATA for the emulator
build,
so you would make its specification conditional on use of EWSD in the MMP
file:
#ifndef _USE_EWSD_
EPOCALLOWDLLDATA
#endif
WSD in DLLs is not, and never will be, supported on EKA1 based versions of
Symbian OS. However WSD in DLLs is supported on EKA2.(versions 9.x)
Hence for the port of GLIB to work on EKA2 version of Symbian OS emulator
we had to do these changes.
Regards
Biswajeet Dash|
Symbian Software India Private Limited |
[EMAIL PROTECTED]
Behdad Esfahbod <[EMAIL PROTECTED]>
Sent by: Behdad Esfahbod <[EMAIL PROTECTED]>
09/06/2008 02:14 AM
To
sparkymat <[EMAIL PROTECTED]>
cc
Tor Lillqvist <[EMAIL PROTECTED]>, [EMAIL PROTECTED], gtk+ dev
Subject
Re: glib on Symbian
sparkymat wrote:
> We are doing what you have mentioned above, i.e. defining name of global
> variables as function calls returning a pointer.
So, this limitation is *only* for the simulator, not the actual Symbian
running on mobile hardware, right? If that's the case I believe the
simulator
should be fixed instead.
behdad
> For example, in gdate.c,
>
> static gboolean using_twodigit_years = FALSE;
>
> would become
>
> #if defined(__SYMBIAN32__) && defined(EMULATOR)
>PLS(using_twodigit_years,gdate, gboolean)
>#define using_twodigit_years
> (*FUNCTION_NAME(using_twodigit_years ,gdate)()
> #else
> static gboolean using_twodigit_years = FALSE;
> #endif
>
> where the PLS() macro will add the specified variable to the Process
> Local Storage, and the define will map it to a function pointer.
>
> This is repeated for all write-able static data (WSD).
Experience innovation in action - visit the Smartphone Show, 21-22
October 2008, Earls Court 2, London
**
Symbian Software Ltd is a company registered in England and Wales
with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London, SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify [EMAIL PROTECTED] and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
**___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting - September 9th
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. things I'd like to discuss are o branching o filechooser threading issues (bug 551337) o 2.90/3.0 plan, next steps o cube.gtk.org availability o miscellaneous eventual changes will be notified on the wiki page[0]. everyone can participate, as usual. Matthias [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=9&day=9&year=2008&hour=20&min=0&sec=0&p1=0 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Murray Cumming wrote:
On Mon, 2008-09-08 at 10:09 -0500, Mike Kestner wrote:
On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:
Paul Pogonyshev wrote:
Johan Dahlin wrote:
[...]
> I'm leaning towards using the "ownership" terminology instead of "transfer".
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
} GITypeOwnership;
Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers. Maybe you could come up with something
different, especially in place of 'callee'?
Agreed, I'm open to suggestions.
caller/subroutine ?
In GAPI, we have two ownership attributes on list elements: owned and
elements_owned.
or nothing is owned. Yes, we have these 3 in gtkmm too. Johan's system
offers a fourth combination, list-not-owned, element-owned, so-far not
seen in the wild), but it seems fine.
True, but most importantly: it supports lists of lists.
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Hi, On Mon, Sep 8, 2008 at 12:07 PM, Mike Kestner <[EMAIL PROTECTED]> wrote: > > If either attribute is unspecified, it's assumed to be false. > Kind of a detail, but with the scanner setup in g-i, I think it would be good to require manual specification of ownership for all allocated types. Otherwise we can't tell what has been looked at. If you're adding introspection to a new library (or a new part of an old library), bottom line is somebody has to go through and specify all the ownerships by hand, so at least in some mode we should be able to tell whether that's been done. If a new function appears in a library, g-i should somehow notify us that ownership has to be specified. If we don't automate detecting the case where ownership hasn't been looked at by hand, surely it's going to constantly break ... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
On Mon, 2008-09-08 at 17:28 +0200, Murray Cumming wrote: > > In GAPI, we have two ownership attributes on list elements: owned and > > elements_owned. > > or nothing is owned. Yes, we have these 3 in gtkmm too. Johan's system > offers a fourth combination, list-not-owned, element-owned, so-far not > seen in the wild), but it seems fine. Just to clarify, this is what I'm talking about by "attributes on list elements" in GAPI XML. If either attribute is unspecified, it's assumed to be false. -- Mike Kestner <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
On Mon, 2008-09-08 at 10:09 -0500, Mike Kestner wrote:
> On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:
> > Paul Pogonyshev wrote:
> > > Johan Dahlin wrote:
> > >> [...]
> > >>
> > > > I'm leaning towards using the "ownership" terminology instead of
> > > "transfer".
> > >> typedef enum {
> > >>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after
> > >> use */
> > >>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it
> > >> is */
> > >> } GITypeOwnership;
> > >
> > > Just as a nitpick, these two names look very similar and quite confusing
> > > for non-native English speakers. Maybe you could come up with something
> > > different, especially in place of 'callee'?
> >
> > Agreed, I'm open to suggestions.
> > caller/subroutine ?
>
> In GAPI, we have two ownership attributes on list elements: owned and
> elements_owned.
or nothing is owned. Yes, we have these 3 in gtkmm too. Johan's system
offers a fourth combination, list-not-owned, element-owned, so-far not
seen in the wild), but it seems fine.
> It's either true or false, and it is from the
> perspective of the recipient of the object. Thus, an owned list in a
> return value is owned by the caller. An owned list in a method "in"
> parameter is owned by the function.
>
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:
> Paul Pogonyshev wrote:
> > Johan Dahlin wrote:
> >> [...]
> >>
> > > I'm leaning towards using the "ownership" terminology instead of
> > "transfer".
> >> typedef enum {
> >>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use
> >> */
> >>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is
> >> */
> >> } GITypeOwnership;
> >
> > Just as a nitpick, these two names look very similar and quite confusing
> > for non-native English speakers. Maybe you could come up with something
> > different, especially in place of 'callee'?
>
> Agreed, I'm open to suggestions.
> caller/subroutine ?
In GAPI, we have two ownership attributes on list elements: owned and
elements_owned. It's either true or false, and it is from the
perspective of the recipient of the object. Thus, an owned list in a
return value is owned by the caller. An owned list in a method "in"
parameter is owned by the function.
--
Mike Kestner <[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject Introspection included in the Softpedia Linux software database
Congratulations, GObject Introspection, one of your products, has been added to Softpedia's database of software programs for Linux. It is featured with a description text, screenshots, download links and technical details on this page: http://linux.softpedia.com/get/Desktop-Environment/Gnome/GObject-Introspection-40832.shtml The description text was created by our editors, using sources such as text from your product's homepage, information from its help system, the PAD file (if available) and the editor's own opinions on the program itself. If you feel that having your product listed on Softpedia is not a benefit for you or simply need something changed or updated, please contact us via email at [EMAIL PROTECTED] and we will work with you to fix any problem you may have found with the product's listing. -- Sincerely, The Softpedia Team --- Softpedia is a library of over 400,000 free and free-to-try software programs for Windows, Mac OS and Linux, games and gaming tools, Windows device drivers, mobile devices and IT-related articles. --- Softpedia - the encyclopedia of free software downloads http://www.softpedia.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Mikkel Kamstrup Erlandsen wrote:
> 2008/9/7 Paolo Bonzini <[EMAIL PROTECTED]>:
I'm leaning towards using the "ownership" terminology instead of
"transfer".
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use
*/
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is
*/
} GITypeOwnership;
>>> Just as a nitpick, these two names look very similar and quite confusing
>>> for non-native English speakers. Maybe you could come up with something
>>> different, especially in place of 'callee'?
>> It's actually commonly-used terminology, e.g. "caller-save registers"
>> vs. "callee-save registers" in compilers.
>
> With all due respect I am not sure compiler-writers are the main
> audience of GObject Introspection. I for one find the terminology a
> bit confusing too.
What about "employer" and "employee" instead? :-)
Paolo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
