From developer@opengroupware.org Fri Feb 1 10:38:31 2008 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Fri, 1 Feb 2008 11:38:31 +0100 Subject: [OGo-Developer] WOHyperlink href rewriting In-Reply-To: <0C1F46B4-B366-4C8B-9999-9D1BE5EC7790@opengroupware.org> References: <0C1F46B4-B366-4C8B-9999-9D1BE5EC7790@opengroupware.org> Message-ID: Hello, On Feb 1, 2008, at 12:31 AM, Helge Hess wrote: > On 31.01.2008, at 18:19, St=E9phane Corth=E9sy wrote: >> While porting a WebObjects app to SOPE, I encountered a problem =20 >> with the WOHyperlink element: when it has the 'href' binding set, =20 >> it tries to rewrite the passed URL, most of the times: > ... >> This means that you cannot pass a '#myAnchor' binding value, nor a =20= >> 'http://some.where.else/' binding value > > I cannot follow that argumentation. Why would rewriting affect a # =20 > anchor or an absolute URL? If it would, I suppose the rewriting =20 > would be b0rked :-) If I put '#MyAnchor' in href, I don't want the URL to be rewritten =20 'http://server/App/wa/test#MyAnchor'. If I put 'http://another.server.com' in href, WOHyperlink tries an =20 fails to rewrite URL. It shouldn't even touch it. > (I think) the rewriting is just for turning absolute URLs into =20 > (short) relative ones. Which has plenty of advantages (size, =20 > proxying, static dumps). > > Maybe there is a bug in the rewriting itself? Yes, there is. Href starting with '#' should not be rewritten - =20 because if user clicks on such link, browser will reload page - , and =20= absolute URLs having a different base than app should not be =20 rewritten using app's base. St=E9phane > Thanks, > Helge > --=20 > Helge Hess > http://www.helgehess.eu/ > > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Fri Feb 1 10:49:27 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 1 Feb 2008 11:49:27 +0100 Subject: [OGo-Developer] WOHyperlink href rewriting In-Reply-To: References: <0C1F46B4-B366-4C8B-9999-9D1BE5EC7790@opengroupware.org> Message-ID: <92135E14-C5DA-4F6A-BBFF-02E488E740A0@opengroupware.org> On 01.02.2008, at 11:38, St=E9phane Corth=E9sy wrote: > If I put '#MyAnchor' in href, I don't want the URL to be rewritten = 'http://server/App/wa/test#MyAnchor'=20 > . Thats true. Bug in the rewriting :-) I think the code currently assumes that you use the =20 'fragmentIdentifier' binding if you want to generate just the #fragment. Here we probably want to change -shouldRewriteURLString: to return NO =20= if the string starts with a #. > If I put 'http://another.server.com' in href, WOHyperlink tries an =20 > fails to rewrite URL. It shouldn't even touch it. Hm, in this case [NSURL -stringValueRelativeToURL:] apparently doesn't =20= check the host properly. Not sure how that can happen, will need to =20 check this. > Yes, there is. Href starting with '#' should not be rewritten - =20 > because if user clicks on such link, browser will reload page - , =20 > and absolute URLs having a different base than app should not be =20 > rewritten using app's base. Yes, thats correct, we will need to fix it. It would also be good to have a binding (or maybe a default) to =20 disable rewriting completely, though I still think its a sensible =20 default value (if rewriting *works* properly :-). Greets, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Fri Feb 1 14:45:18 2008 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Fri, 1 Feb 2008 15:45:18 +0100 Subject: [OGo-Developer] WOHyperlink href rewriting In-Reply-To: <92135E14-C5DA-4F6A-BBFF-02E488E740A0@opengroupware.org> References: <0C1F46B4-B366-4C8B-9999-9D1BE5EC7790@opengroupware.org> <92135E14-C5DA-4F6A-BBFF-02E488E740A0@opengroupware.org> Message-ID: <9680AC7D-BF55-4C6A-A189-A9F87743B303@sente.ch> On Feb 1, 2008, at 11:49 AM, Helge Hess wrote: > On 01.02.2008, at 11:38, St=E9phane Corth=E9sy wrote: >> If I put '#MyAnchor' in href, I don't want the URL to be rewritten =20= >> 'http://server/App/wa/test#MyAnchor'. > > Thats true. Bug in the rewriting :-) > > I think the code currently assumes that you use the =20 > 'fragmentIdentifier' binding if you want to generate just the =20 > #fragment. Hmm, well, no: you may not bind only 'fragmentIdentifier': you need =20 to bind at least href | pageName | action | (directActionName & =20 actionClass). > Here we probably want to change -shouldRewriteURLString: to return =20 > NO if the string starts with a #. Agreed. >> If I put 'http://another.server.com' in href, WOHyperlink tries an =20= >> fails to rewrite URL. It shouldn't even touch it. > > Hm, in this case [NSURL -stringValueRelativeToURL:] apparently =20 > doesn't check the host properly. Not sure how that can happen, will =20= > need to check this. (Writing some tests for such basic but often used feature would help =20 development.) >> Yes, there is. Href starting with '#' should not be rewritten - =20 >> because if user clicks on such link, browser will reload page - , =20 >> and absolute URLs having a different base than app should not be =20 >> rewritten using app's base. > > > Yes, thats correct, we will need to fix it. > > It would also be good to have a binding (or maybe a default) to =20 > disable rewriting completely, though I still think its a sensible =20 > default value (if rewriting *works* properly :-). Yes, why not? As long as it works correctly :-P Cheers, St=E9phane > Greets, > Helge > --=20 > Helge Hess > http://www.helgehess.eu/-- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Sat Feb 2 10:39:55 2008 From: developer@opengroupware.org (Helge Hess) Date: Sat, 2 Feb 2008 11:39:55 +0100 Subject: [OGo-Developer] WOHyperlink href rewriting In-Reply-To: <9680AC7D-BF55-4C6A-A189-A9F87743B303@sente.ch> References: <0C1F46B4-B366-4C8B-9999-9D1BE5EC7790@opengroupware.org> <92135E14-C5DA-4F6A-BBFF-02E488E740A0@opengroupware.org> <9680AC7D-BF55-4C6A-A189-A9F87743B303@sente.ch> Message-ID: On 01.02.2008, at 15:45, St=E9phane Corth=E9sy wrote: >> I think the code currently assumes that you use the =20 >> 'fragmentIdentifier' binding if you want to generate just the =20 >> #fragment. > Hmm, well, no: you may not bind only 'fragmentIdentifier': you need =20= > to bind at least href | pageName | action | (directActionName & =20 > actionClass). Hm, should we consider this a bug? >> Here we probably want to change -shouldRewriteURLString: to return =20= >> NO if the string starts with a #. > Agreed. OK, did that. >>> If I put 'http://another.server.com' in href, WOHyperlink tries an =20= >>> fails to rewrite URL. It shouldn't even touch it. >> Hm, in this case [NSURL -stringValueRelativeToURL:] apparently =20 >> doesn't check the host properly. Not sure how that can happen, will =20= >> need to check this. I had a look and the code looks reasonable I think. Its in sope-core/=20 NGExtensions/FdExt/NSURL+misc.m. There is a debugURLProcessing constant. Maybe you could enable that and have a look what goes wrong? > (Writing some tests for such basic but often used feature would help =20= > development.) Definitely, contributions are very welcome! ;-) Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Tue Feb 5 15:15:41 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Tue, 05 Feb 2008 10:15:41 -0500 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") Message-ID: Hi, In sope-appserver/NGObjWeb/DynamicElements/ WOComplexHyperlink.m, line 385, we have the following lines: if (r.length > 0 && [ s characterAtIndex:0] =3D=3D '#') return false; Unless the person who did this is using an obscure experimental bridge for Javascript and Objective C, this is erroneous and you should replace "false" with "NO"... This just proves you didn't even bother to try to build your code before committing, which is very bad.... -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From developer@opengroupware.org Tue Feb 5 15:26:11 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 5 Feb 2008 16:26:11 +0100 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: References: Message-ID: <864B264D-C3CB-4AED-8679-60D6D6FCDE41@opengroupware.org> On 05.02.2008, at 16:15, Wolfgang Sourdeau wrote: > In sope-appserver/NGObjWeb/DynamicElements/ WOComplexHyperlink.m, > line 385, we have the following lines: > > if (r.length > 0 && [ s characterAtIndex:0] == '#') > return false; > > Unless the person who did this is using an obscure experimental > bridge for Javascript and Objective C, this is erroneous and you > should replace "false" with "NO"... > > This just proves you didn't even bother to try to build your code > before committing, which is very bad.... Hu? Actually 'false' is regular C99 alias and of course I always build code before a commit. You could at least bother Google before blaming people ;-) Anyways, 'NO' is still better for oldskool environments, I'll change it. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue Feb 5 15:29:29 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 5 Feb 2008 16:29:29 +0100 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: References: Message-ID: On 05.02.2008, at 16:15, Wolfgang Sourdeau wrote: > using an obscure experimental bridge for Javascript and Objective C Oh, BTW, you can find one in the Recycler (NGJavaScript). I don't use it anymore (<2003 stuff), but its actually not that bad and tested rather well (uses Mozilla SpiderMonkey). Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue Feb 5 15:41:17 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Tue, 05 Feb 2008 10:41:17 -0500 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: 864B264D-C3CB-4AED-8679-60D6D6FCDE41@opengroupware.org Message-ID: > > Hu? Actually 'false' is regular C99 alias and of course I always build > code before a commit. > You could at least bother Google before blaming people ;-) > > Anyways, 'NO' is still better for oldskool environments, I'll change it. Ok. Sorry for the wrong assumption. But maybe you are missing a flag to GCC because in my environment (gcc 4.2.3), it won'd build: gcc (GCC) 4.2.3 20080102 (prerelease) (Debian 4.2.2-5) Copyright =C2=A9 2007 Free Software Foundation, Inc. Ce logiciel est libre; voir les sources pour les conditions de copie. Il n'y a PAS GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER. wsourdeau@sogo:~/src/SOPE/sope-appserver/NGObjWeb/DynamicElements$ make messages =3Dyes Making all for subproject DynamicElements... gcc _WOComplexHyperlink.m -c \ -MMD -MP -pipe -pipe -Wall -funsigned-char -O2 -DCOMPILING_NGOBJWEB=3D1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=3D1 -DGNU_RUNTIME=3D1 -DGNUSTEP_BASE_LIBRARY=3D1 -D_REENTRANT -fPIC -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -g -fno-strict-aliasing -fgnu-runtime -fconstant-string-class=3DNSConstantString -I.. -I. -I../.. -I../../../sope-core -I../../../sope-core/NGStreams -I../../../sope-core/NGExtensions -I../../../sope-mime -I../../../sope-xml -I. -I/home/wsourdeau/GNUstep/Library/Headers -I/usr/local/lib/GNUstep/Local/Library/Headers -I/usr/local/lib/GNUstep/Network/Library/Headers -I/usr/lib/GNUstep/System/Library/Headers \ -o shared_debug_obj/_WOComplexHyperlink.o _WOComplexHyperlink.m: In function '-[_WOHrefHyperlink shouldRewriteURLString:inContext:]': _WOComplexHyperlink.m:387: erreur: 'false' undeclared (first use in this function) _WOComplexHyperlink.m:387: erreur: (Each undeclared identifier is reported only once _WOComplexHyperlink.m:387: erreur: for each function it appears in.) make[1]: *** [shared_debug_obj/_WOComplexHyperlink.o] Erreur 1 make: *** [DynamicElements.all.subproject.variables] Erreur 2 wsourdeau@sogo:~/src/SOPE/sope-appserver/NGObjWeb/DynamicElements$ -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From developer@opengroupware.org Tue Feb 5 16:20:37 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 5 Feb 2008 17:20:37 +0100 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: References: Message-ID: <56227DFE-38CE-46BB-A138-CC5286B1FA7C@opengroupware.org> On 05.02.2008, at 16:41, Wolfgang Sourdeau wrote: > Ok. Sorry for the wrong assumption. But maybe you are missing a flag =20= > to GCC because in my environment (gcc 4.2.3), it won'd build: > > gcc (GCC) 4.2.3 20080102 (prerelease) (Debian 4.2.2-5) > Copyright =A9 2007 Free Software Foundation, Inc. > Ce logiciel est libre; voir les sources pour les conditions de =20 > copie. Il n'y a PAS Maybe its because the compiler is emitting French ;-) Anyways, its true, I certainly do not test every single commit on all =20= platforms, usually just on my current one (OSX 10.5 in this case). If =20= it does not build on others, you just need to tell and we'll fix it. =20 Can happen from time to time. After all its trunk, not a snapshot ... Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Wed Feb 6 12:07:27 2008 From: developer@opengroupware.org (=?ISO-8859-1?Q?Marcus_M=FCller?=) Date: Wed, 6 Feb 2008 13:07:27 +0100 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: <864B264D-C3CB-4AED-8679-60D6D6FCDE41@opengroupware.org> References: <864B264D-C3CB-4AED-8679-60D6D6FCDE41@opengroupware.org> Message-ID: --Apple-Mail-637-654147797 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Anyways, 'NO' is still better for oldskool environments, I'll change > it. Hehe, Java overdose I guess. ;-) Cheers, Marcus -- Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ --Apple-Mail-637-654147797 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Anyways, 'NO' is still better for oldskool = environments, I'll change it.

Hehe, Java overdose I guess. = ;-)

Cheers,


  Marcus


-- 

Marcus Mueller  .  .  .  crack-admin/coder = ;-)

Mulle = kybernetiK  .  http://www.mulle-kybernetik.com

Current = projects: http://www.mulle-kybernetik= .com/znek/


 =

= --Apple-Mail-637-654147797-- From developer@opengroupware.org Wed Feb 6 12:21:17 2008 From: developer@opengroupware.org (Helge Hess) Date: Wed, 6 Feb 2008 13:21:17 +0100 Subject: [OGo-Developer] Javascript for ObjC (or "test that your code build!") In-Reply-To: References: <864B264D-C3CB-4AED-8679-60D6D6FCDE41@opengroupware.org> Message-ID: <779F4F92-B939-4506-9B1F-6804C8C814A5@opengroupware.org> On 06.02.2008, at 13:07, Marcus M=FCller wrote: >> Anyways, 'NO' is still better for oldskool environments, I'll =20 >> change it. > > Hehe, Java overdose I guess. ;-) More likely C++ ... Actually 'true' / 'false' are symbols in pretty much any current =20 programming language: http://en.wikipedia.org/wiki/Boolean_datatype The only real exception I could find is Python which does 'True' and =20 'False' instead of the lowercase symbols. Even Ruby uses just 'true' (I would have expected something like "$!=20 @true[[" ;-) Greets, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Wed Feb 6 21:48:47 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 06 Feb 2008 22:48:47 +0100 Subject: [OGo-Developer] Changes to trunk, Testing Message-ID: <20080206214847.F2E5A480C7@smtp.l00-bugdead-prods.de> Hi, "Sebastian Reitenbach" wrote: > Hi, > > > > > Next I changed the way object_version, last_modified, etc fields are > > updated, and I added those to a few classes which didn't have them > > before (eg docs, notes and projects). > > > > Finally I plan to enhance the database schema for 5.4. Mostly: > > - notes/documents attached to company records > > - parent_id in project table > > - a few other minor things > > If someone has wishes for additional fields, shout now ;-) This isn't > > committed yet. > > > I just remembered another one, I don't know whether I already have an open > bug report for that, maybe ... It would be great to have an additional BOOL > field on the resources table per resouce, to allow a checkbox in the UI > whether conflicts are allowed or not. e.g. for cold drinks no conflicts, but > meeting rooms should raise a conflict. As I haven't seen any changes being committed yet, I think it would make more sense to add and INT field where the amount of the resource can be specified. So that instead of having Projector 1, Projector 2, ... just have a resource Projector n times. Only when the n+1 Projector is booked at the same time, a resource conflict is raised. kind regards Sebastian From developer@opengroupware.org Wed Feb 6 22:04:43 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 06 Feb 2008 23:04:43 +0100 Subject: [OGo-Developer] sope/sogo/ogo with gsmake 2 Message-ID: <20080206220444.2726B46ED9@smtp.l00-bugdead-prods.de> Hi, I submitted the changes to the sope/sogo/ogo-gsmake-2 branches. Sope and SOGo install and work well in GNUstep path and FHS path, OGo needs to have sope installed in FHS path and also only installs into FHS path. I just installed it on opensuse 10.3, using gnustep-startup-0.18.4. Sope and SOGo are working fine for me. OGo shows a login page, but then segfaults after login, because of gnustep-base incompatibilities. Btw, I ran all *plist files through recode, but svn ci did not catched that up. Is there an easy way to tell svn that these have changed? cheers sebastian From developer@opengroupware.org Wed Feb 6 23:21:48 2008 From: developer@opengroupware.org (Helge Hess) Date: Thu, 7 Feb 2008 00:21:48 +0100 Subject: [OGo-Developer] Changes to trunk, Testing In-Reply-To: <20080206214847.F2E5A480C7@smtp.l00-bugdead-prods.de> References: <20080206214847.F2E5A480C7@smtp.l00-bugdead-prods.de> Message-ID: On 06.02.2008, at 22:48, Sebastian Reitenbach wrote: > As I haven't seen any changes being committed yet, I think it would > make more sense to add and INT field where the amount of the > resource can be specified. So that instead of having Projector 1, > Projector 2, ... just have a resource Projector n times. Only when > the n+1 Projector is booked at the same time, a resource conflict is > raised. This is called a resource group and is already supported. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Wed Feb 6 23:23:43 2008 From: developer@opengroupware.org (Helge Hess) Date: Thu, 7 Feb 2008 00:23:43 +0100 Subject: [OGo-Developer] sope/sogo/ogo with gsmake 2 In-Reply-To: <20080206220444.2726B46ED9@smtp.l00-bugdead-prods.de> References: <20080206220444.2726B46ED9@smtp.l00-bugdead-prods.de> Message-ID: On 06.02.2008, at 23:04, Sebastian Reitenbach wrote: > OGo shows a login page, but then segfaults after > login, because of gnustep-base incompatibilities. ... > Btw, I ran all *plist files through recode, but svn ci did not > catched that up. Is there an easy way to tell svn that these have > changed? Well, they probably contain nothing which required a change? (plists _usually_ only contain ASCII). If the file actually changed, 'svn stat' / 'svn commit' will show it. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Feb 7 06:29:55 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 07 Feb 2008 07:29:55 +0100 Subject: [OGo-Developer] Changes to trunk, Testing Message-ID: <20080207062956.382C948435@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 06.02.2008, at 22:48, Sebastian Reitenbach wrote: > > As I haven't seen any changes being committed yet, I think it would > > make more sense to add and INT field where the amount of the > > resource can be specified. So that instead of having Projector 1, > > Projector 2, ... just have a resource Projector n times. Only when > > the n+1 Projector is booked at the same time, a resource conflict is > > raised. > > This is called a resource group and is already supported. I did not know that, so the following might be a dumb question, but how do I create a resource that is e.g. 10 times available? Do I need to set a Default to enable this? cheers Sebastian From developer@opengroupware.org Thu Feb 7 06:36:11 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 07 Feb 2008 07:36:11 +0100 Subject: [OGo-Developer] sope/sogo/ogo with gsmake 2 Message-ID: <20080207063611.BDC5448132@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 06.02.2008, at 23:04, Sebastian Reitenbach wrote: > > OGo shows a login page, but then segfaults after > > login, because of gnustep-base incompatibilities. > > ... > > > Btw, I ran all *plist files through recode, but svn ci did not > > catched that up. Is there an easy way to tell svn that these have > > changed? > > Well, they probably contain nothing which required a change? (plists > _usually_ only contain ASCII). If the file actually changed, 'svn > stat' / 'svn commit' will show it. The encoding from at least this file changed: ./WebUI/Mailer/OGoWebMail/Defaults.plist ... mail_MDN_type =3D "ask"; mail_MDN_text =3D "This is a Return Receipt for the mail you sent on $date$ \nto $to$ with subject '$subject$'.\n\nThis only acknowledges that the message was displayed on the recipient's machine. \nThis is no guarantee that the message has been read or understood."; //mail_MDN_text =3D "Dies ist eine Antwortbest=E4tigung f=FCr die Nachricht, die Sie am $date$ \nan $to$ mit dem Titel '$subject$' gesendet haben.\n\nDas bedeutet lediglich, dass die Nachricht auf dem Bildschirm des Empf=E4ngers dargestellt wurde. \nDas ist keine Garantie daf=FCr, dass die Nachricht gelesen oder verstanden wurde."; mail_MDN_subject =3D "Antwortbest=E4tigung"; .... The =E4 and =FC are the problem in there. I could also remove these German lines, and I also wondered, why mail_MDN_subject Default is German, but the rest is English. Sebastian From developer@opengroupware.org Thu Feb 7 09:20:43 2008 From: developer@opengroupware.org (Helge Hess) Date: Thu, 7 Feb 2008 10:20:43 +0100 Subject: [OGo-Developer] Changes to trunk, Testing In-Reply-To: <20080207062956.382C948435@smtp.l00-bugdead-prods.de> References: <20080207062956.382C948435@smtp.l00-bugdead-prods.de> Message-ID: <00DB84F3-3457-46DD-9AF7-5B4F6C4C0EE4@opengroupware.org> On 07.02.2008, at 07:29, Sebastian Reitenbach wrote: > I did not know that, so the following might be a dumb question, but > how do I create a resource that is e.g. 10 times available? You need to create the 10 resources manually, which is sensible IMHO (you usually want to know who has which projector (eg ID or make and color), not just that he has one). > Do I need to set a Default to enable this? No, you just name the group and 'Boom' ;-) .. but those are really questions for the users list ... Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri Feb 8 19:57:19 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 08 Feb 2008 14:57:19 -0500 Subject: [OGo-Developer] server down Message-ID: <5825-47acb400-19-b73aeab0@155617433> Hi Helge and all, I think the anonymous svn is down again.... -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From developer@opengroupware.org Fri Feb 8 20:24:48 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 8 Feb 2008 21:24:48 +0100 Subject: [OGo-Developer] server down In-Reply-To: <5825-47acb400-19-b73aeab0@155617433> References: <5825-47acb400-19-b73aeab0@155617433> Message-ID: <0FF0A7A0-D16D-4877-96E3-61913160E56B@opengroupware.org> On 08.02.2008, at 20:57, Wolfgang Sourdeau wrote: > I think the anonymous svn is down again.... Yes, this server finally died, this affects various services. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri Feb 8 20:51:22 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 08 Feb 2008 15:51:22 -0500 Subject: [OGo-Developer] server down In-Reply-To: 0FF0A7A0-D16D-4877-96E3-61913160E56B@opengroupware.org Message-ID: <5dc0-47acc100-3-b73a5ab0@63226899> Le 08 F=C3=A9v. 2008 15:24 EST, Helge Hess a =C3=A9crit: > On 08.02.2008, at 20:57, Wolfgang Sourdeau wrote: > > I think the anonymous svn is down again.... > > > Yes, this server finally died, this affects various services. Ouch... this is bad news. Any idea on when and how it will be replaced? -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From developer@opengroupware.org Fri Feb 8 20:53:06 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 8 Feb 2008 21:53:06 +0100 Subject: [OGo-Developer] server down In-Reply-To: <5dc0-47acc100-3-b73a5ab0@63226899> References: <5dc0-47acc100-3-b73a5ab0@63226899> Message-ID: On 08.02.2008, at 21:51, Wolfgang Sourdeau wrote: >> Yes, this server finally died, this affects various services. > Ouch... this is bad news. Any idea on when and how it will be > replaced? Those are all vservers which can be easily moved to another server. We'll see. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sun Feb 10 20:02:48 2008 From: developer@opengroupware.org (Adam Tauno WIlliams) Date: Sun, 10 Feb 2008 15:02:48 -0500 Subject: [OGo-Developer] Retrieving values from post / LSWObjectEditor Message-ID: <1202673768.21170.43.camel@ws01.whitemice.org> I'm working on adding extended attribute support for documents like described in Bug#1942 . This is my first real foray into hacking in the WebUI. I have added - ... <#IfExtAttrs> <#DocEditExtAttrs/> ... - to SkyProject4DocumentUpload.html, and in SkyProject4DocumentUpload.wod - IfExtAttrs: WOConditional { condition = isExtAttrsDefined; } DocEditorExtAttrs: LSWObjectEditor { labels = labels; object = uploadData1.extendedAttributes; attributes = extendedAttributeSpec; namespace = "http://www.opengroupware.org/properties/ext-attr"; } - that and the corresponding methods and a touch of init glue in SkyProject4DocumentUpload.m and I get the additional form fields for attributes defined in the "OGoExtendedDocAttributes" default. If no default is defined there are no additional fields. So that works. But I'm at a complete loss as to where the values get bound when a post occurs; setExtendedAttributes (in uploadData1, a SkyP4FileUploadData) does not appear to be called. From developer@opengroupware.org Mon Feb 11 15:15:20 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Mon, 11 Feb 2008 10:15:20 -0500 Subject: [OGo-Developer] compile problem Message-ID: Is this a joke? make[3]: entrant dans le r=E9pertoire =AB /home/wsourdeau/src/SOPE/sope-= core/NGExtensions/EOExt.subproj =BB Making all for subproject EOExt... Compiling file EOGlobalID+Ext.m ... EOGlobalID+Ext.m: In function '-[EOGlobalID(SOPEExt) valueForUndefinedKe= y:]': EOGlobalID+Ext.m:29: erreur: cannot find interface declaration for 'NSCo= nstantString' make[4]: *** [shared_debug_obj/EOGlobalID+Ext.o] Erreur 1 make[3]: *** [EOExt.all.subproject.variables] Erreur 2 make[3]: quittant le r=E9pertoire =AB /home/wsourdeau/src/SOPE/sope-core= /NGExtensions/EOExt.subproj =BB --=20 Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou= privil=E9gi=E9s. Si vous n'en =EAtes pas le v=E9ritable destinataire, ve= uillez nous aviser imm=E9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information.= If you are not the intended recipient, please notify us immediately. Tha= nk you. From developer@opengroupware.org Mon Feb 11 15:19:22 2008 From: developer@opengroupware.org (Helge Hess) Date: Mon, 11 Feb 2008 16:19:22 +0100 Subject: [OGo-Developer] compile problem In-Reply-To: References: Message-ID: On 11.02.2008, at 16:15, Wolfgang Sourdeau wrote: > Is this a joke? No, those are the pleasures of GNUstep ;-) > make[3]: entrant dans le r=E9pertoire =AB = /home/wsourdeau/src/SOPE/sope-=20 > core/NGExtensions/EOExt.subproj =BB > Making all for subproject EOExt... > Compiling file EOGlobalID+Ext.m ... > EOGlobalID+Ext.m: In function '-[EOGlobalID(SOPEExt) =20 > valueForUndefinedKey:]': > EOGlobalID+Ext.m:29: erreur: cannot find interface declaration for =20 > 'NSConstantString' > make[4]: *** [shared_debug_obj/EOGlobalID+Ext.o] Erreur 1 > make[3]: *** [EOExt.all.subproject.variables] Erreur 2 > make[3]: quittant le r=E9pertoire =AB = /home/wsourdeau/src/SOPE/sope-core/=20 > NGExtensions/EOExt.subproj =BB Fixed it. Greets, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Mon Feb 11 17:10:43 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 11 Feb 2008 18:10:43 +0100 Subject: [OGo-Developer] compile problem Message-ID: <20080211171044.363D95AC08@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 11.02.2008, at 16:15, Wolfgang Sourdeau wrote: > > Is this a joke? > > No, those are the pleasures of GNUstep ;-) > > > make[3]: entrant dans le r=E9pertoire =AB /home/wsourdeau/src/SOPE/sope- > > core/NGExtensions/EOExt.subproj =BB > > Making all for subproject EOExt... > > Compiling file EOGlobalID+Ext.m ... > > EOGlobalID+Ext.m: In function '-[EOGlobalID(SOPEExt) > > valueForUndefinedKey:]': > > EOGlobalID+Ext.m:29: erreur: cannot find interface declaration for > > 'NSConstantString' > > make[4]: *** [shared_debug_obj/EOGlobalID+Ext.o] Erreur 1 > > make[3]: *** [EOExt.all.subproject.variables] Erreur 2 > > make[3]: quittant le r=E9pertoire =AB /home/wsourdeau/src/SOPE/sope-core/ > > NGExtensions/EOExt.subproj =BB > While reading this, I remember I've seem sth. similar when compiling sogo, against gnustep-base-1.15.2. I think I haven't seen it with gnustep-base-1.15.0, nor 1.14.X. This must have changed not long ago. against which gs-base version did you compile? I just wonder, because sope was compiling fine against gnustep-base-1.15.2. Sebastian From developer@opengroupware.org Mon Feb 11 17:22:05 2008 From: developer@opengroupware.org (Helge Hess) Date: Mon, 11 Feb 2008 18:22:05 +0100 Subject: [OGo-Developer] compile problem In-Reply-To: <20080211171044.363D95AC08@smtp.l00-bugdead-prods.de> References: <20080211171044.363D95AC08@smtp.l00-bugdead-prods.de> Message-ID: On 11.02.2008, at 18:10, Sebastian Reitenbach wrote: > This must have changed not long ago. I've added the file yesterday or so. Most other .m files include common.h, which in turn includes Foundation.h. The difference is that on GNUstep you need to include NSString.h to use constant string objects. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Feb 11 17:55:51 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 11 Feb 2008 18:55:51 +0100 Subject: [OGo-Developer] compile problem Message-ID: <20080211175552.CEEBB5ACE3@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 11.02.2008, at 18:10, Sebastian Reitenbach wrote: > > This must have changed not long ago. > > > I've added the file yesterday or so. Most other .m files include > common.h, which in turn includes Foundation.h. ah, that might explain why I did not yet ran into it ;) > > The difference is that on GNUstep you need to include NSString.h to > use constant string objects. but with this regard, there also must have been changed sth. between gnustep-base 1.15.0 and 1.15.2, as sogo compiles well with 1.15.0, but not with 1.15.2 anymore. nevertheless, good to know how to resolve this. thanks Sebastian From developer@opengroupware.org Mon Feb 11 18:16:39 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Mon, 11 Feb 2008 13:16:39 -0500 Subject: [OGo-Developer] compile problem In-Reply-To: <20080211171044.363D95AC08@smtp.l00-bugdead-prods.de> Message-ID: <86ee0c6ec910ff6372371af28635ee65@mozzarella> > While reading this, I remember I've seem sth. similar when compiling s= ogo,=20 > against gnustep-base-1.15.2. I think I haven't seen it with=20 > gnustep-base-1.15.0, nor 1.14.X. This must have changed not long ago. > against which gs-base version did you compile? I just wonder, because = sope=20 > was compiling fine against gnustep-base-1.15.2. With 1.13. Until we integrate your patches for gsmake 2. --=20 Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou= privil=E9gi=E9s. Si vous n'en =EAtes pas le v=E9ritable destinataire, ve= uillez nous aviser imm=E9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information.= If you are not the intended recipient, please notify us immediately. Tha= nk you. From developer@opengroupware.org Mon Feb 11 19:16:42 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 11 Feb 2008 20:16:42 +0100 Subject: [OGo-Developer] compile problem Message-ID: <20080211191643.0A9125AD48@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > > While reading this, I remember I've seem sth. similar when compiling sogo, > > against gnustep-base-1.15.2. I think I haven't seen it with > > gnustep-base-1.15.0, nor 1.14.X. This must have changed not long ago. > > against which gs-base version did you compile? I just wonder, because sope > > was compiling fine against gnustep-base-1.15.2. > > With 1.13. Until we integrate your patches for gsmake 2. so you compiled with 1.13, but without my patches? or used gsmake-2, my patches and compiled against 1.13? I thought gsmake 2 requires at least gnustep-base 1.14? when my patches causing the trouble, I'll need to take a look at them. however, what I wanted to say, for me sogo was compiling with my patches with actual stable 1.14.X, and also with 1.15.0, but not anymore with 1.15.2. Sebastian From developer@opengroupware.org Fri Feb 15 16:00:22 2008 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Fri, 15 Feb 2008 17:00:22 +0100 Subject: [OGo-Developer] Bug in -[WOCookie initWithName:value:path:domain:expires:isSecure:] Message-ID: Hi, There's a bug in sope-appserver/NGObjWeb/WOCookie.m, in -[WOCookie =20 initWithName:value:path:domain:expires:isSecure:]: The line self->expireDate =3D [expireDate retain]; should be self->expireDate =3D [_date retain]; St=E9phane From developer@opengroupware.org Fri Feb 15 16:25:20 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 15 Feb 2008 17:25:20 +0100 Subject: [OGo-Developer] Bug in -[WOCookie initWithName:value:path:domain:expires:isSecure:] In-Reply-To: References: Message-ID: <5F0BCF1F-7DBD-4C23-8018-C3979035AB19@opengroupware.org> On 15.02.2008, at 17:00, St=E9phane Corth=E9sy wrote: > The line > self->expireDate =3D [expireDate retain]; > > should be > self->expireDate =3D [_date retain]; Good catched, fixed in r1605. Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/= From developer@opengroupware.org Fri Feb 15 20:58:20 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 15:58:20 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B5FCEC.3030003@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero for the object being deallocated in that From developer@opengroupware.org Fri Feb 15 20:59:31 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 15:59:31 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B5FD33.5000209@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero for the object being deallocated in that From developer@opengroupware.org Fri Feb 15 21:03:44 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 16:03:44 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B5FE30.7080803@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero for the object being deallocated in that From developer@opengroupware.org Fri Feb 15 21:06:18 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 16:06:18 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B5FECA.6000206@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero (NSAutoreleasePool.m:405) for the object being deallocated from the pool in that iteration. If I put a conditional around that line of (ie, if (imps[hash])) the segmentation fault occurs further down in the objc runtime. I realize this is probably *not* a problem with the objc runtime, but I was unable to see any other cause for this further up in the OGo code. I have seen this bug after having installed gnustep-startup-0.18.4 and with gnustep-startup-0.19.2. The line number reference above is for version 0.19.2. If there is anything else I can do to debug this problem please let me know. I am very interested in getting to the bottom of this but I seem to have hit a roadblock. Any information you can share would be very helpful! Thanks in advance, Will From developer@opengroupware.org Fri Feb 15 21:09:16 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 16:09:16 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B5FF7C.4020301@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero (NSAutoreleasePool.m:405) for the object being deallocated from the pool in that iteration. If I put a conditional around that line of (ie, if (imps[hash])) the segmentation fault occurs further down in the objc runtime. I realize this is probably *not* a problem with the objc runtime, but I was unable to see any other cause for this further up in the OGo code. I have seen this bug after having installed gnustep-startup-0.18.4 and with gnustep-startup-0.19.2. The line number reference above is for version 0.19.2. If there is anything else I can do to debug this problem please let me know. I am very interested in getting to the bottom of this but I seem to have hit a roadblock. Any information you can share would be very helpful! Thanks in advance, Will From developer@opengroupware.org Fri Feb 15 21:11:51 2008 From: developer@opengroupware.org (Will Hawkins) Date: Fri, 15 Feb 2008 16:11:51 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <47B60017.9080004@cmf.nrl.navy.mil> Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero (NSAutoreleasePool.m:405) for the object being deallocated from the pool in that iteration. If I put a conditional around that line of (ie, if (imps[hash])) the segmentation fault occurs further down in the objc runtime. I realize this is probably *not* a problem with the objc runtime, but I was unable to see any other cause for this further up in the OGo code. I have seen this bug after having installed gnustep-startup-0.18.4 and with gnustep-startup-0.19.2. The line number reference above is for version 0.19.2. If there is anything else I can do to debug this problem please let me know. I am very interested in getting to the bottom of this but I seem to have hit a roadblock. Any information you can share would be very helpful! Thanks in advance, Will From developer@opengroupware.org Sat Feb 16 09:40:24 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sat, 16 Feb 2008 10:40:24 +0100 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <20080216094024.B80DA5BC94@smtp.l00-bugdead-prods.de> Hi Will, I'm the one that is working on the gsmake2 branch of OGo. Please note, it is a "GS make" branch not a "GS base" one. Well, my long term goal is to run OGo linked against gnustep base. developer@opengroupware.org wrote: > Good afternoon! > > I have been working to get an installation of Ogo using the gsmake2 > versions of SOPE and OGo. I am able to get the software installed and > running. I can log in to the Web Interface. However, the action taken > immediately after log in causes the ogo-webui to restart. I have the I'm stuck at the same point, and also have no idea what to do here to fix the problem. I got a bit busy with other things, therefore had no much time to dig that problem. However, I'll writeup a mail later today, asking for help on the gnustep-discuss ML, maybe someone over there might have a clue. Most likely I'll take your mail, as it summarizes the situation very well. > following backtrace from the process in gdb: > > #0 0x00000000 in ?? () > #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, > _cmd=0x1395cf8) at NSAutoreleasePool.m:405 > #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, > _cmd=0x1395cf0) > at NSAutoreleasePool.m:324 > #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, > _cmd=0x13cab78) > at NSAutoreleasePool.m:317 > #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] > (self=0x9409f70, > _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at > NSRunLoop.m:1137 > #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, > _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 > #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) > at WOCoreApplication.m:541 > #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, > argv=0xbffecca4) at WOApplicationMain.m:42 > #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, > argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 > #9 0x08049a0c in main () > > I have attempted to debug this but after almost two days I am no closer > to the source. In the emptyPool function he segmentation fault occurs > because imps[hash] is zero (NSAutoreleasePool.m:405) for the object > being deallocated from the pool in that iteration. > > If I put a conditional around that line of (ie, if (imps[hash])) the > segmentation fault occurs further down in the objc runtime. I realize > this is probably *not* a problem with the objc runtime, but I was unable > to see any other cause for this further up in the OGo code. > > I have seen this bug after having installed gnustep-startup-0.18.4 and > with gnustep-startup-0.19.2. The line number reference above is for > version 0.19.2. > > If there is anything else I can do to debug this problem please let me > know. I am very interested in getting to the bottom of this but I seem > to have hit a roadblock. Any information you can share would be very > helpful! to better work together on that problem, we could use some faster method of communication, IRC, jabber, ...? cheers Sebastian From developer@opengroupware.org Sat Feb 16 21:02:35 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Sat, 16 Feb 2008 16:02:35 -0500 Subject: [OGo-Developer] OGo, PostgreSQL 8.3, & INT casting Message-ID: <1203195755.5435.14.camel@aleph.morrison.iserv.net> PostgreSQL 8.3, and I think some builds of 8.2.x, not longer performing automatic casting of INT to TEXT when INTs are compared to character types. This causes at least ACL processing in OGo to die with - ERROR: IN types character varying and integer cannot be matched - because a query like - SELECT DISTINCT B.company_id FROM person AS B WHERE (( ( B.firstname ILIKE '%%yser%%' ) OR ( B.name ILIKE '%%yser%%' ) )) AND (( B.owner_id = 10100 ) OR ( ( B.is_private = 0 OR B.is_private IS NULL ) AND ( ( 0 = ( SELECT COUNT(*) FROM object_acl WHERE object_id = B.company_id ) OR 0 < ( SELECT COUNT(*) FROM object_acl WHERE object_id = B.company_id AND action = 'allowed' AND permissions LIKE '%r%' AND ( auth_id = 10100 OR auth_id IN ( 9981, 9991, 10003, 11530, 55000, 77210, 142730, 142780, 142850, 393280, 423400, 445160, 949410, 949540, 955770, 970730, 970990, 1096320, 9153790, 9153880, 9154000, 10597021, 10735169 ) ) ) ) ) )) AND (B.is_template_user IS NULL OR B.is_template_user = 0) AND (B.db_status <> 'archived') LIMIT 50 - is generated where object_acl.auth_id [a CHAR(255)] is IN'd with an integer list. Altering this query to - ... auth_id::INT IN ( 9981, 9991, ....) - fixes this. On the other hand I think a better fix is just to make auth_id an integer column. I've never seen this column be anything but an integer [object id] and integer comparison and integer set comparison is faster than processing text types. I've done - OGo=# ALTER TABLE object_acl ADD auth_id_int INT; OGo=# UPDATE object_acl SET auth_id_int = auth_id::INT; OGo=# ALTER TABLE object_acl DROP auth_id; OGo=# ALTER TABLE object_acl ADD auth_id INT; OGo=# UPDATE object_acl SET auth_id = auth_id_int; OGo=# ALTER TABLE object_acl DROP auth_id_int; OGo=# VACUUM ANALYZE object_acl; This fixes the issue and everything still seems to work fine. The "original" object_acl table is - CREATE TABLE object_acl ( object_acl_id int not null, sort_key int not null, action varchar(10) not null, object_id varchar(255) not null, auth_id varchar(255), permissions varchar(50)); To me it just seems like having object_id and auth_id as VARCHAR(255) is pointless. I've also proceeded to change object_id to an INT - OGo=# ALTER TABLE object_acl ADD object_id_int INT; OGo=# UPDATE object_acl SET object_id_int = object_id::INT; OGo=# ALTER TABLE object_acl DROP object_id; OGo=# ALTER TABLE object_acl ADD object_id INT; OGo=# UPDATE object_acl SET object_id = object_id_int; OGo=# ALTER TABLE object_acl DROP object_id_int; OGo=# VACUUM ANALYZE object_acl; - leaving me with a table of - Column | Type | Modifiers object_acl_id | integer | not null sort_key | integer | not null action | character varying(10) | not null permissions | character varying(50) | auth_id | integer | object_id | integer | Everything still works. However, the OGoModel represents these data-types as VARCHAR(255), so maybe my fix isn't appropriate. { name = "authId"; columnName = "auth_id"; externalType = "VARCHAR(255)"; valueClassName = "NSString"; allowsNull = Y; width = 255; }, { name = "objectAclId"; columnName = "object_acl_id"; externalType = "INT"; valueClassName = "NSNumber"; valueType = i; }, { name = "objectId"; columnName = "object_id"; externalType = "VARCHAR(255)"; valueClassName = "NSString"; width = 255; }, I haven't tried modifying the model to use INT/NSNumber yet. Personally I think just storing INTs is better [and faster], but maybe the object_acl has some [edge / undocumented] functionality I'm not aware of? From developer@opengroupware.org Sat Feb 16 21:18:59 2008 From: developer@opengroupware.org (Helge Hess) Date: Sat, 16 Feb 2008 22:18:59 +0100 Subject: [OGo-Developer] OGo, PostgreSQL 8.3, & INT casting In-Reply-To: <1203195755.5435.14.camel@aleph.morrison.iserv.net> References: <1203195755.5435.14.camel@aleph.morrison.iserv.net> Message-ID: On 16.02.2008, at 22:02, Adam Tauno Williams wrote: > Personally I think just storing INTs is better [and faster], but > maybe the > object_acl has some [edge / undocumented] functionality I'm not aware > of? I think the original idea was that it could be used for other stuff as well (eg LDAP principal URLs instead of pkeys, etc). Anyways, I already have those in my OGo 5.4 upgrade script: ALTER TABLE object_acl ALTER COLUMN object_id TYPE INT USING object_id::int; ALTER TABLE object_acl ALTER COLUMN auth_id TYPE INT USING auth_id::int; Should fix it? (does the ALTER work that way with PG 8.3?) > However, the OGoModel represents these data-types as VARCHAR(255), so > maybe my fix isn't appropriate. I suspect that ACL is done directly at SQL level and doesn't use the model. But I'm not 100% sure. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sat Feb 16 21:29:50 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Sat, 16 Feb 2008 16:29:50 -0500 Subject: [OGo-Developer] OGo, PostgreSQL 8.3, & INT casting In-Reply-To: References: <1203195755.5435.14.camel@aleph.morrison.iserv.net> Message-ID: <1203197390.5435.16.camel@aleph.morrison.iserv.net> > > Personally I think just storing INTs is better [and faster], but > > maybe the > > object_acl has some [edge / undocumented] functionality I'm not aware > > of? > I think the original idea was that it could be used for other stuff as > well (eg LDAP principal URLs instead of pkeys, etc). Anyways, I > already have those in my OGo 5.4 upgrade script: > ALTER TABLE object_acl ALTER COLUMN object_id TYPE INT USING > object_id::int; > ALTER TABLE object_acl ALTER COLUMN auth_id TYPE INT USING > auth_id::int; > Should fix it? (does the ALTER work that way with PG 8.3?) Yep, that should work, and more succinct than my fix. > > However, the OGoModel represents these data-types as VARCHAR(255), so > > maybe my fix isn't appropriate. > I suspect that ACL is done directly at SQL level and doesn't use the > model. But I'm not 100% sure. From developer@opengroupware.org Tue Feb 19 14:38:00 2008 From: developer@opengroupware.org (Will Hawkins) Date: Tue, 19 Feb 2008 09:38:00 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <20080216094024.B80DA5BC94@smtp.l00-bugdead-prods.de> References: <20080216094024.B80DA5BC94@smtp.l00-bugdead-prods.de> Message-ID: <47BAE9C8.3040304@cmf.nrl.navy.mil> Thanks for taking this on. I do now see the difference between "make" and "base". I have no idea how I missed that until this point. I am absolutely available for collaboration via more immediate means. I can join any irc channel that you'd like. I work on EST and I am most available during the day. I look forward to hearing your preferences and getting the issue resolved. I will also keep you posted if I find anything else re: this issue. Will Sebastian Reitenbach wrote: > Hi Will, > > I'm the one that is working on the gsmake2 branch of OGo. Please note, it is > a "GS make" branch not a "GS base" one. Well, my long term goal is to run > OGo linked against gnustep base. > > > developer@opengroupware.org wrote: >> Good afternoon! >> >> I have been working to get an installation of Ogo using the gsmake2 >> versions of SOPE and OGo. I am able to get the software installed and >> running. I can log in to the Web Interface. However, the action taken >> immediately after log in causes the ogo-webui to restart. I have the > I'm stuck at the same point, and also have no idea what to do here to fix > the problem. I got a bit busy with other things, therefore had no much time > to dig that problem. However, I'll writeup a mail later today, asking for > help on the gnustep-discuss ML, maybe someone over there might have a clue. > Most likely I'll take your mail, as it summarizes the situation very well. > >> following backtrace from the process in gdb: >> >> #0 0x00000000 in ?? () >> #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, >> _cmd=0x1395cf8) at NSAutoreleasePool.m:405 >> #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, >> _cmd=0x1395cf0) >> at NSAutoreleasePool.m:324 >> #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, >> _cmd=0x13cab78) >> at NSAutoreleasePool.m:317 >> #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] >> (self=0x9409f70, >> _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at >> NSRunLoop.m:1137 >> #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, >> _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 >> #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) >> at WOCoreApplication.m:541 >> #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, >> argv=0xbffecca4) at WOApplicationMain.m:42 >> #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, >> argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 >> #9 0x08049a0c in main () >> >> I have attempted to debug this but after almost two days I am no closer >> to the source. In the emptyPool function he segmentation fault occurs >> because imps[hash] is zero (NSAutoreleasePool.m:405) for the object >> being deallocated from the pool in that iteration. >> >> If I put a conditional around that line of (ie, if (imps[hash])) the >> segmentation fault occurs further down in the objc runtime. I realize >> this is probably *not* a problem with the objc runtime, but I was unable >> to see any other cause for this further up in the OGo code. >> >> I have seen this bug after having installed gnustep-startup-0.18.4 and >> with gnustep-startup-0.19.2. The line number reference above is for >> version 0.19.2. >> >> If there is anything else I can do to debug this problem please let me >> know. I am very interested in getting to the bottom of this but I seem >> to have hit a roadblock. Any information you can share would be very >> helpful! > to better work together on that problem, we could use some faster method of > communication, IRC, jabber, ...? > > cheers > Sebastian > From developer@opengroupware.org Tue Feb 19 15:25:24 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 19 Feb 2008 10:25:24 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <47BAE9C8.3040304@cmf.nrl.navy.mil> References: <20080216094024.B80DA5BC94@smtp.l00-bugdead-prods.de> <47BAE9C8.3040304@cmf.nrl.navy.mil> Message-ID: <1203434724.21156.0.camel@WM_ADAM1.morrison.iserv.net> --=-ael5mfg3k17JTliwl6es Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Thanks for taking this on. I do now see the difference between "make"=20 > and "base". I have no idea how I missed that until this point. I am=20 > absolutely available for collaboration via more immediate means. I can=20 > join any irc channel that you'd like. I work on EST and I am most=20 > available during the day. I look forward to hearing your preferences and=20 > getting the issue resolved. I will also keep you posted if I find=20 > anything else re: this issue. There is an OGo IRC channel - irc://irc.freenode.net/ogo - but I'm just about the only person who hangs out there. http://www.opengroupware.org/en/users/support/community/index.html#irc --=-ael5mfg3k17JTliwl6es Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHuvTkLRePpNle04MRAkdgAJ9eKY12X4kL2MgB242NtKYv7SGXEwCePb1V PymQaCz0y4u7DrwWsnm1GHE= =Zfzm -----END PGP SIGNATURE----- --=-ael5mfg3k17JTliwl6es-- From developer@opengroupware.org Tue Feb 19 18:19:29 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 19 Feb 2008 19:19:29 +0100 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > > Thanks for taking this on. I do now see the difference between "make" > > and "base". I have no idea how I missed that until this point. I am > > absolutely available for collaboration via more immediate means. I can > > join any irc channel that you'd like. I work on EST and I am most > > available during the day. I look forward to hearing your preferences and > > getting the issue resolved. I will also keep you posted if I find > > anything else re: this issue. > > There is an OGo IRC channel - irc://irc.freenode.net/ogo - but I'm just > about the only person who hangs out there. > > http://www.opengroupware.org/en/users/support/community/index.html#irc > I wasn't aware of it, just joined in ;). So just lets use this. Below the answer I got from Richard on the gnustep-discuss ML, about the crasher: http://lists.gnu.org/archive/html/discuss-gnustep/2008-02/msg00066.html He also just added some debugging code to NSAutoreleasePool to svn to aid debugging the problem. I'm just going to checkout and recompile. cheers Sebastian From developer@opengroupware.org Tue Feb 19 18:33:07 2008 From: developer@opengroupware.org (Will Hawkins) Date: Tue, 19 Feb 2008 13:33:07 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> References: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> Message-ID: <47BB20E3.7030605@cmf.nrl.navy.mil> I will sign in there as well. I noticed that the place of the segmentation fault *is* linked to the selector functions that he mentioned. Specifically, see file NSAutoReleasePool.m on line 397 (or thereabout, depending upon the version). It would appear that those methods are returning nil for whatever object they are trying to deallocate. So, sadly, it appears that we are somehow not able to find a releaseSel for those objects. I am going to set the environment variable that he refers to and run the code that way. I will let you know what I find. Will Sebastian Reitenbach wrote: > Hi, > developer@opengroupware.org wrote: >>> Thanks for taking this on. I do now see the difference between "make" >>> and "base". I have no idea how I missed that until this point. I am >>> absolutely available for collaboration via more immediate means. I can >>> join any irc channel that you'd like. I work on EST and I am most >>> available during the day. I look forward to hearing your preferences and >>> getting the issue resolved. I will also keep you posted if I find >>> anything else re: this issue. >> There is an OGo IRC channel - irc://irc.freenode.net/ogo - but I'm just >> about the only person who hangs out there. >> >> http://www.opengroupware.org/en/users/support/community/index.html#irc >> > I wasn't aware of it, just joined in ;). So just lets use this. Below the > answer I got from Richard on the gnustep-discuss ML, about the crasher: > http://lists.gnu.org/archive/html/discuss-gnustep/2008-02/msg00066.html > > He also just added some debugging code to NSAutoreleasePool to svn to aid > debugging the problem. I'm just going to checkout and recompile. > > cheers > Sebastian > From developer@opengroupware.org Tue Feb 19 21:40:22 2008 From: developer@opengroupware.org (Will Hawkins) Date: Tue, 19 Feb 2008 16:40:22 -0500 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> References: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> Message-ID: <47BB4CC6.1090206@cmf.nrl.navy.mil> When I compile gstep-base with the suggested [anObject class] instead of GSObjCClass(anObject) I get the following (interesting) debug info: Deallocated LSCompanyInfo (0xb52fad0) sent release Deallocated object (0x13b67c0) sent instanceMethodForSelector: The ui still segvs at the same spot, but that is interesting behavior. The selector is looking for the release method of each object in the release pool. Is it possible that the ogo/sope code is overwriting that method for one of those objects due to a bounds error? Or, are we inheriting from something that we assume provides a release method that actually doesn't? (The second seems less likely but would be easier to fix!). I hope this additional information helps! Will Sebastian Reitenbach wrote: > Hi, > developer@opengroupware.org wrote: >>> Thanks for taking this on. I do now see the difference between "make" >>> and "base". I have no idea how I missed that until this point. I am >>> absolutely available for collaboration via more immediate means. I can >>> join any irc channel that you'd like. I work on EST and I am most >>> available during the day. I look forward to hearing your preferences and >>> getting the issue resolved. I will also keep you posted if I find >>> anything else re: this issue. >> There is an OGo IRC channel - irc://irc.freenode.net/ogo - but I'm just >> about the only person who hangs out there. >> >> http://www.opengroupware.org/en/users/support/community/index.html#irc >> > I wasn't aware of it, just joined in ;). So just lets use this. Below the > answer I got from Richard on the gnustep-discuss ML, about the crasher: > http://lists.gnu.org/archive/html/discuss-gnustep/2008-02/msg00066.html > > He also just added some debugging code to NSAutoreleasePool to svn to aid > debugging the problem. I'm just going to checkout and recompile. > > cheers > Sebastian > From developer@opengroupware.org Tue Feb 19 21:48:45 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 19 Feb 2008 22:48:45 +0100 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <47BB4CC6.1090206@cmf.nrl.navy.mil> References: <20080219181930.1AAA05C847@smtp.l00-bugdead-prods.de> <47BB4CC6.1090206@cmf.nrl.navy.mil> Message-ID: <929FC41D-27EF-47CF-B4DD-395F5B7F8242@opengroupware.org> On 19.02.2008, at 22:40, Will Hawkins wrote: > When I compile gstep-base with the suggested [anObject class] > instead of GSObjCClass(anObject) I get the following (interesting) > debug info: > > Deallocated LSCompanyInfo (0xb52fad0) sent release > Deallocated object (0x13b67c0) sent instanceMethodForSelector: > > The ui still segvs at the same spot, but that is interesting > behavior. The selector is looking for the release method of each > object in the release pool. Is it possible that the ogo/sope code is > overwriting that method for one of those objects due to a bounds > error? Or, are we inheriting from something that we assume provides > a release method that actually doesn't? (The second seems less > likely but would be easier to fix!). Well, LSCompanyInfo is an EnterpriseObject (a GDL1 database object). Or it might be an EOFault which fakes being an LSCompanyInfo. In any case, GDL1 does 'interesting' stuff with caching and faulting objects. Its not unlikely that the issue is hidden in there. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sun Feb 24 20:33:30 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 24 Feb 2008 21:33:30 +0100 Subject: [OGo-Developer] gsmake2 branch segmentation fault Message-ID: <20080224203330.9795C5D728@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > On 19.02.2008, at 22:40, Will Hawkins wrote: > > When I compile gstep-base with the suggested [anObject class] > > instead of GSObjCClass(anObject) I get the following (interesting) > > debug info: > > > > Deallocated LSCompanyInfo (0xb52fad0) sent release > > Deallocated object (0x13b67c0) sent instanceMethodForSelector: with that variable, it was immediately followed by an exception: /usr/local/sbin/ogo-webui-1.1: Uncaught exception NSInternalInconsistencyException, reason: nul release for object in autorelease pool > > > > The ui still segvs at the same spot, but that is interesting > > behavior. The selector is looking for the release method of each > > object in the release pool. Is it possible that the ogo/sope code is > > overwriting that method for one of those objects due to a bounds > > error? Or, are we inheriting from something that we assume provides > > a release method that actually doesn't? (The second seems less > > likely but would be easier to fix!). > I also added the [NSObject enableDoubleReleseCheck: YES] directly to the main function of ogo-webui. It generated this output, and stopped immediately: 2008-02-21 19:49:26.724 ogo-webui-1.1[8491] autorelease called without pool for object (80f7288) of class NSMethodSignature in thread 2008-02-21 19:49:26.729 ogo-webui-1.1[8491] autorelease called without pool for object (81ade48) of class GSAutoreleasedMemory in thread 2008-02-21 19:49:26.730 ogo-webui-1.1[8491] autorelease called without pool for object (81946f8) of class GSCInlineString in thread 2008-02-21 19:49:26.730 ogo-webui-1.1[8491] autorelease called without pool for object (819a610) of class NSException in thread 2008-02-21 19:49:26.730 ogo-webui-1.1[8491] autorelease called without pool for object (818ce70) of class GSMutableArray in thread /usr/local/sbin/ogo-webui-1.1: Uncaught exception NSInvalidArgumentException, reason: Can not determine type information for +[NSObject enableDoubleReleseCheck:] Aborted I'm not perfectly sure, whethe adding it there, is the correct place, or whether I do have to do more? > > Well, LSCompanyInfo is an EnterpriseObject (a GDL1 database object). > Or it might be an EOFault which fakes being an LSCompanyInfo. > > In any case, GDL1 does 'interesting' stuff with caching and faulting > objects. Its not unlikely that the issue is hidden in there. > needs more investigation. cheers Sebastian PS: /me is whooha on IRC. From developer@opengroupware.org Mon Feb 25 00:51:51 2008 From: developer@opengroupware.org (Helge Hess) Date: Mon, 25 Feb 2008 01:51:51 +0100 Subject: [OGo-Developer] gsmake2 branch segmentation fault In-Reply-To: <20080224203330.9795C5D728@smtp.l00-bugdead-prods.de> References: <20080224203330.9795C5D728@smtp.l00-bugdead-prods.de> Message-ID: On 24.02.2008, at 21:33, Sebastian Reitenbach wrote: > 2008-02-21 19:49:26.724 ogo-webui-1.1[8491] autorelease called > without pool > for object (80f7288) of class NSMethodSignature in thread 0x80e1738> I suppose this says that no top-level autorelease pool is set, which is weird. ogo-webui actually calls the SOPE WOWatchDogApplicationMain() function. And as far as I can see this looks like: ---snip--- int WOWatchDogApplicationMain (NSString *appName, int argc, const char *argv[]) { NSAutoreleasePool *pool; NSUserDefaults *ud; pool = [[NSAutoreleasePool alloc] init]; // <<== #if LIB_FOUNDATION_LIBRARY || defined(GS_PASS_ARGUMENTS) { extern char **environ; [NSProcessInfo initializeWithArguments:(void*)argv count:argc environment:(void*)environ]; } #endif ---snap--- Something which might help to isolate the problem is this: ---snip--- @implementation NSMethodSignature(Hack) - (void)autorelease { [super autorelease]; } @end ---snap--- and then do a breakpoint on that method and see who calls the autorelease on the object and why there is no pool. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Feb 25 17:04:52 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Mon, 25 Feb 2008 12:04:52 -0500 Subject: [OGo-Developer] Was: OGoAddressMapLink In-Reply-To: <20071219193445.BE8AA5AAF7@smtp.l00-bugdead-prods.de> References: <20071219193445.BE8AA5AAF7@smtp.l00-bugdead-prods.de> Message-ID: <1203959092.5704.23.camel@WM_ADAM1.morrison.iserv.net> --=-ZSwlWjySW76njBUcP62q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > I took a look at SkyExternalLink and added the functionality to=20 > > OGoAddressMapLink. Also the SkyExternalLinkAction Default is honored. > > In the end it turned out easier than expected ;) > > I updated the tarball and page in the docs plone: > http://docs.opengroupware.org/Members/buzzdee/OGo%20AddOns/OGoAddressMapL= ink/document_view=20 > ping! > Anything else to be done to get this into svn? Did you file it as a bug#+patch? Also, just glancing at the doc plone page. I think the template should have a conditional so that the map link is only shown if the OGoAddressMapLink has been defined. - <#AddressTitle><#Buttons/> + <#AddressTitle><#MapLink/><#Buttons/> <#AddressViewer/> ... becomes ... - <#AddressTitle><#Buttons/> + <#AddressTitle><#IfMapLink><#MapLink/><#Buttons/> <#AddressViewer/> --=-ZSwlWjySW76njBUcP62q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHwvU0LRePpNle04MRAopxAJ9qNIt5UXmBcaJWw1VieUWMHogwEwCfcWIT Ecv63PoF/1lzUg64DL197Ak= =hQcA -----END PGP SIGNATURE----- --=-ZSwlWjySW76njBUcP62q-- From developer@opengroupware.org Mon Feb 25 19:11:46 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 25 Feb 2008 20:11:46 +0100 Subject: [OGo-Developer] Was: OGoAddressMapLink Message-ID: <20080225191147.24ED15DA68@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > > I took a look at SkyExternalLink and added the functionality to > > > OGoAddressMapLink. Also the SkyExternalLinkAction Default is honored. > > > In the end it turned out easier than expected ;) > > > I updated the tarball and page in the docs plone: > > http://docs.opengroupware.org/Members/buzzdee/OGo%20AddOns/OGoAddressMapLink/document_view > > ping! > > Anything else to be done to get this into svn? > > Did you file it as a bug#+patch? Also, just glancing at the doc plone not yet, at least I don't think so. > page. I think the template should have a conditional so that the map > link is only shown if the OGoAddressMapLink has been defined. > > - <#AddressTitle><#Buttons/> > + <#AddressTitle><#MapLink/><#Buttons/> > <#AddressViewer/> > > ... becomes ... > > - <#AddressTitle><#Buttons/> > + <#AddressTitle><#IfMapLink><#MapLink/><#Buttons/> > <#AddressViewer/> > I'll change this, and if I do not yet have a bug report created, I'll do and upload there. thanks Sebastian From developer@opengroupware.org Wed Feb 27 18:32:49 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 27 Feb 2008 19:32:49 +0100 Subject: [OGo-Developer] Was: OGoAddressMapLink Message-ID: <20080227183249.B368B5E10C@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > developer@opengroupware.org wrote: > > > > I took a look at SkyExternalLink and added the functionality to > > > > OGoAddressMapLink. Also the SkyExternalLinkAction Default is honored. > > > > In the end it turned out easier than expected ;) > > > > I updated the tarball and page in the docs plone: > > > > http://docs.opengroupware.org/Members/buzzdee/OGo%20AddOns/OGoAddressMapLink/document_view > > > > ping! > > > Anything else to be done to get this into svn? > > > > Did you file it as a bug#+patch? Also, just glancing at the doc plone > not yet, at least I don't think so. > > page. I think the template should have a conditional so that the map > > link is only shown if the OGoAddressMapLink has been defined. > > > > - <#AddressTitle><#Buttons/> > > + <#AddressTitle><#MapLink/><#Buttons/> > > <#AddressViewer/> > > > > ... becomes ... > > > > - <#AddressTitle><#Buttons/> > > + <#AddressTitle><#IfMapLink><#MapLink/><#Buttons/> > > <#AddressViewer/> > > > I'll change this, and if I do not yet have a bug report created, I'll do and > upload there. an entry in bugzilla is created: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1955 I've done it in an a bit different way. I made the MapLink itself a bit smarter. When two or more parameters given to it have a length > 0 then the icon and the link appears, otherwise not. Otherwise, the pages that embed the OGoAddressMapLink must provide a reasonable condition value somewhere, for the IfMapLink. I hope that makes it easier to embed the link into existing pages, as for example I haven't found something reasonable to user for IfMapLink in LSWAddressViewer.m. cheers Sebastian From developer@opengroupware.org Wed Feb 27 18:44:46 2008 From: developer@opengroupware.org (Jeff) Date: 27 Feb 2008 18:44:46 -0000 Subject: [OGo-Developer] Appointment Duration Message-ID: <29185-26268@sneakemail.com> I added a comment to bug 10 (http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=10#c5) to suggest a possible quick solution, though perhaps adding a duration field is just as easy. Since bugzilla didn't send any e-mail out, I thought I'd ping the dev list to see if anyone had any comment on that implementation? Thanks, Jeff