headers
Adam Tauno Williams | 14 Sep 2009 14:51
Gravatar

New Schema Attributes

Recently we added new attributed to the DB schema and model -

To Contact:
  birthplace - This is intended to be just a free form string?

  family_status - This is a free form string or some enumeration>?

  citizenship - There was a comment about this being a CSV field?  Is it
a CSV of free-form country names or some enumeration?  For country field
in address we use ISO 3166-1 alpha3 codes.  Could we perhaps
'standardize' on using that standard for representing countries?   I
could easily provide a table that contains all the country codes if that
would be useful.

To Address:
  district - This is a free form string or is some more specific meaning
intended?

--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer
Permalink | Reply | 1 comment |
headers
Adam Tauno Williams | 14 Sep 2009 22:43
Gravatar

Re: valgrind & Obj-C ? [Was: ZideStore & odd leak behaviour]

On Sun, 2009-03-08 at 21:10 +0100, Helge Hess wrote:
> On 08.03.2009, at 20:51, Adam Tauno Williams wrote:
> > Does anyone know if valgrind is useful with Objective-C?
> I've used KCacheGrind a lot to profile SOPE/OGo. But more for  
> profiling, not for leak detection. Don't know about this.

It doesn't appear that KCacheGrind does much in regard to finding leaks.

> In theory libFoundation supports BoehmGC PLUS retain counting in a  
> leak-detection mode. Not sure whether this still works ... most likely  
> not :-/
> Its quite nice to find ObjC leaks.

I've googled about for this but only found dead links;  any chance you
have some pointers?

> Well, then of course one could try OmniObjectMeter with OGo on MacOSX  
> to find leaks.

Sadly, no Macs here.

==23038== 1,672,776 (383,216 direct, 1,289,560 indirect) bytes in 17,154
blocks are definitely lost in loss record 36 of 55
==23038==    at 0x4025E92: calloc
(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==23038==    by 0x490A2FB: objc_calloc (in /usr/lib/libobjc.so.2.0.0)
==23038==    by 0x47CB518: _i_NSDefaultZone__calloc_byteSize_
(NSDefaultZone.m:129)
==23038==    by 0x47C2E3E: NSAllocateObject (NSZone.h:136)
==23038==    by 0x47F4631: _c_NSTemporaryString__allocWithZone_
(Continue reading)

Permalink | Reply | 1 comment |
headers
Helge Hess | 15 Sep 2009 17:58
Favicon

Re: valgrind & Obj-C ? [Was: ZideStore & odd leak behaviour]

On 14.09.2009, at 22:43, Adam Tauno Williams wrote:
>> In theory libFoundation supports BoehmGC PLUS retain counting in a  
>> leak-detection mode. Not sure whether this still works ... most  
>> likely not :-/
>> Its quite nice to find ObjC leaks.
> I've googled about for this but only found dead links;  any chance  
> you have some pointers?

Well, no. I guess its not too easy to make it working again.

Not sure what the following is saying. From an RC perspective the code  
seems to look fine.

> ==23038== 1,672,776 (383,216 direct, 1,289,560 indirect) bytes in  
> 17,154
> blocks are definitely lost in loss record 36 of 55
> ==23038==    at 0x4025E92: calloc
> (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> ==23038==    by 0x490A2FB: objc_calloc (in /usr/lib/libobjc.so.2.0.0)
> ==23038==    by 0x47CB518: _i_NSDefaultZone__calloc_byteSize_
> (NSDefaultZone.m:129)
> ==23038==    by 0x47C2E3E: NSAllocateObject (NSZone.h:136)
> ==23038==    by 0x47F4631: _c_NSTemporaryString__allocWithZone_
> (NSString.m:1967)
> ==23038==    by 0x47F441F: _c_NSString_NSStringCreation_allocWithZone_
> (NSString.m:1379)
> ==23038==    by 0x47BFC3F: _c_NSObject__alloc (NSObject.m:153)
> ==23038==    by 0x47EFA03:
> _c_NSString_NSStringCreation_stringWithCString_ (NSString.m:1420)
> ==23038==    by 0x4831FF7:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helge Hess | 15 Sep 2009 18:08
Favicon

Re: New Schema Attributes

On 14.09.2009, at 14:51, Adam Tauno Williams wrote:
> Recently we added new attributed to the DB schema and model -
>
> To Contact:
>  birthplace - This is intended to be just a free form string?

Yes. Eg 'Berlin' or 'New York'.

>  family_status - This is a free form string or some enumeration>?

Good question. In the application where I use it, its a popup.  
('verheiratet' / 'nicht verheiratet'). I suppose it should be a proper  
enum.

>  citizenship - There was a comment about this being a CSV field?

No. 'keywords' aka 'categories' is a CSV field.

I currently use citizenship as a free form field. But it probably  
makes sense to use some code.
(I'm not 100% sure whether thats possible. Is there always a 1:1  
mapping between citizenship and country? Hm Hm. Probably)

> Is it a CSV of free-form country names or some enumeration?  For  
> country field
> in address we use ISO 3166-1 alpha3 codes.  Could we perhaps
> 'standardize' on using that standard for representing countries?

Makes sense, yes.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane