From developer@opengroupware.org Sun Dec 9 21:26:22 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 09 Dec 2007 22:26:22 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk Message-ID: <20071209212623.25A934A395@smtp.l00-bugdead-prods.de> users@opengroupware.org wrote: > On 09.12.2007, at 21:52, Adam Tauno Williams wrote: > > AsteriskDialer.m:61: warning: method possibly missing a [super > > dealloc] > > call > > Thats sounds like a memory leak. Ah, will fix that. > > > AsteriskDialer.m: In function -[AsteriskDialer cleanupNumber:]: > > AsteriskDialer.m:105: warning: NSString may not respond to > > -isNotEmpty > > > You miss an include of NGExtensions/NSNull+misc.h and that too. > > That really belongs on the dev list. Yeah, I just wanted to ask about these on the dev list, as I saw your mail. thanks Sebastian From developer@opengroupware.org Sun Dec 9 22:06:45 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 09 Dec 2007 23:06:45 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk Message-ID: <20071209220646.B8E584A3A9@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > users@opengroupware.org wrote: > > On 09.12.2007, at 21:52, Adam Tauno Williams wrote: > > > AsteriskDialer.m:61: warning: method possibly missing a [super > > > dealloc] > > > call > > > > Thats sounds like a memory leak. > Ah, will fix that. > > > > > > AsteriskDialer.m: In function -[AsteriskDialer cleanupNumber:]: > > > AsteriskDialer.m:105: warning: NSString may not respond to > > > -isNotEmpty > > > > > > You miss an include of NGExtensions/NSNull+misc.h > and that too. > > > > That really belongs on the dev list. > Yeah, I just wanted to ask about these on the dev list, as I saw your mail. I fixed both, and I think, also the other problem Adam reported. I updated the bugzilla entry, changed the attachement from being a patch to just a tarball, hope that makes handling easier. Sebastian From developer@opengroupware.org Sun Dec 9 22:09:14 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 09 Dec 2007 23:09:14 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk Message-ID: <20071209220915.231054A39C@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > users@opengroupware.org wrote: > > On 09.12.2007, at 21:52, Adam Tauno Williams wrote: > > > AsteriskDialer.m:61: warning: method possibly missing a [super > > > dealloc] > > > call > > > > Thats sounds like a memory leak. > Ah, will fix that. > I forgot to ask in the other mail. I added a [super dealloc] in the dealloc method in AsteriskDialer.m, but I have no [super init] in the init method of that class, is that ok? At least there are no warnings or error messages anymore. thanks Sebastian From developer@opengroupware.org Sun Dec 9 22:29:16 2007 From: developer@opengroupware.org (Helge Hess) Date: Sun, 9 Dec 2007 23:29:16 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk In-Reply-To: <20071209220915.231054A39C@smtp.l00-bugdead-prods.de> References: <20071209220915.231054A39C@smtp.l00-bugdead-prods.de> Message-ID: <8938E41C-4F27-4B98-951D-B275A866BC67@opengroupware.org> On 09.12.2007, at 23:09, Sebastian Reitenbach wrote: > I forgot to ask in the other mail. I added a [super dealloc] in the > dealloc method in AsteriskDialer.m, but I have no [super init] in > the init method of that class, is that ok? At least there are no > warnings or error messages anymore. You need to distinguish between a) allocation (+alloc) b) initialization (-init..) c) deallocation (-dealloc) Technically it might be OK not to call [super init] (depending on the Foundation library in use), but its highly recommended. The usual constructs looks like this: - (id)init { if ((self = [super init]) != nil) { // here goes your object setup code } return self; } Note that -init can return *different* objects. Thats sometimes used for caches which return a cached object and dealloc the newly created instance. Its also used in class clusters. etc. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sun Dec 9 22:37:53 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 09 Dec 2007 23:37:53 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk Message-ID: <20071209223753.9BCBC4A39C@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 09.12.2007, at 23:09, Sebastian Reitenbach wrote: > > I forgot to ask in the other mail. I added a [super dealloc] in the > > dealloc method in AsteriskDialer.m, but I have no [super init] in > > the init method of that class, is that ok? At least there are no > > warnings or error messages anymore. > > You need to distinguish between > a) allocation (+alloc) > b) initialization (-init..) > c) deallocation (-dealloc) > > Technically it might be OK not to call [super init] (depending on the > Foundation library in use), but its highly recommended. The usual > constructs looks like this: > > - (id)init { > if ((self = [super init]) != nil) { > // here goes your object setup code > } > return self; > } ok, up to this point, everything is fine, I'll add that too. > > Note that -init can return *different* objects. Thats sometimes used > for caches which return a cached object and dealloc the newly created > instance. Its also used in class clusters. etc. damn, and now I'm confused again, do you have any class or sth, in ogo, where this happens? Sebastian From developer@opengroupware.org Sun Dec 9 22:44:20 2007 From: developer@opengroupware.org (Helge Hess) Date: Sun, 9 Dec 2007 23:44:20 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk In-Reply-To: <20071209223753.9BCBC4A39C@smtp.l00-bugdead-prods.de> References: <20071209223753.9BCBC4A39C@smtp.l00-bugdead-prods.de> Message-ID: On 09.12.2007, at 23:37, Sebastian Reitenbach wrote: >> Note that -init can return *different* objects. Thats sometimes used >> for caches which return a cached object and dealloc the newly created >> instance. Its also used in class clusters. etc. > damn, and now I'm confused again, do you have any class or sth, in > ogo, > where this happens? You can probably ignore that "feature". Anyways, Class cluster do that all the time, eg NSString: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html Eg if you say [[NString alloc] init...] you do not get an object of the NSString class, but some subclass of NSString depending on the -init method and the string passed to that method. (the NSString cluster hides the subclass details from you). But OGo also does that, eg in 'page singletons' (root pages like LSWPersons). Those pages are only allocated once per session and contain code to ensure that in -init. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sun Dec 9 23:02:21 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 10 Dec 2007 00:02:21 +0100 Subject: [OGo-Developer] Re: [OGo-Users] Re: click-to-dial & Asterisk Message-ID: <20071209230221.9B8B649CFB@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 09.12.2007, at 23:37, Sebastian Reitenbach wrote: > >> Note that -init can return *different* objects. Thats sometimes used > >> for caches which return a cached object and dealloc the newly created > >> instance. Its also used in class clusters. etc. > > damn, and now I'm confused again, do you have any class or sth, in > > ogo, > > where this happens? > > You can probably ignore that "feature". > > > Anyways, Class cluster do that all the time, eg NSString: > http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html > > Eg if you say > [[NString alloc] init...] > > you do not get an object of the NSString class, but some subclass of > NSString depending on the -init method and the string passed to that > method. (the NSString cluster hides the subclass details from you). > > But OGo also does that, eg in 'page singletons' (root pages like > LSWPersons). Those pages are only allocated once per session and > contain code to ensure that in -init. Yeah, you told me about the SessionSingletons some time ago, I think it was regarding the ability to save searches on documents in projects. Nevertheless, at least whatever my problem was, afar I could fix the problem afterwards. But I did not really understood, under what circumstances it would be useful to use or not use a SessionSingleton. I think such an explanation would be useful to include in the developer docs. kind regards Sebastian From developer@opengroupware.org Mon Dec 10 12:06:39 2007 From: developer@opengroupware.org (Helge Hess) Date: Mon, 10 Dec 2007 13:06:39 +0100 Subject: [OGo-Developer] click-to-dial & Asterisk In-Reply-To: <20071209230221.9B8B649CFB@smtp.l00-bugdead-prods.de> References: <20071209230221.9B8B649CFB@smtp.l00-bugdead-prods.de> Message-ID: On 10.12.2007, at 00:02, Sebastian Reitenbach wrote: > But I did not really understood, under what circumstances it > would be useful to use or not use a SessionSingleton. Isn't that rather obvious? :-) A cache page preserves its state w/o resorting to defaults and such (until the next logout). Eg if you enter the scheduler page, leave it and reenter it, it still shows the last view and the last query etc. This is because the page object is still the same, its taken from the persistent page session cache. Its hard to generalize, but I would say that NOT using the page cache is preferable. Caching the full page can take quite a bit of memory, especially if unnecessary state is not reset in -sleep. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Dec 10 13:18:58 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 10 Dec 2007 14:18:58 +0100 Subject: [OGo-Developer] click-to-dial & Asterisk Message-ID: <20071210131858.9E4524A4F9@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 10.12.2007, at 00:02, Sebastian Reitenbach wrote: > > But I did not really understood, under what circumstances it > > would be useful to use or not use a SessionSingleton. > > > Isn't that rather obvious? :-) A cache page preserves its state w/o > resorting to defaults and such (until the next logout). yes, I thought sth, like that > > Eg if you enter the scheduler page, leave it and reenter it, it still > shows the last view and the last query etc. This is because the page > object is still the same, its taken from the persistent page session > cache. And with that explanation, I now know what the consequences are, what to look for. > > Its hard to generalize, but I would say that NOT using the page cache > is preferable. Caching the full page can take quite a bit of memory, > especially if unnecessary state is not reset in -sleep. Well, the -sleep, -awake, ... stuff I also not yet understood, but at least I understand, that it is not recommended to use the page cache. thanks Sebastian > > Helge > -- > Helge Hess > http://www.helgehess.eu/ > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer > From developer@opengroupware.org Mon Dec 10 13:26:11 2007 From: developer@opengroupware.org (Helge Hess) Date: Mon, 10 Dec 2007 14:26:11 +0100 Subject: [OGo-Developer] click-to-dial & Asterisk In-Reply-To: <20071210131858.9E4524A4F9@smtp.l00-bugdead-prods.de> References: <20071210131858.9E4524A4F9@smtp.l00-bugdead-prods.de> Message-ID: On 10.12.2007, at 14:18, Sebastian Reitenbach wrote: > Well, the -sleep, -awake, ... stuff I also not yet understood, but > at least I understand, that it is not recommended to use the page > cache. -awake is mostly useless, but -sleep is called when the component object is not used by SOPE anymore (the current request has been processed). Hence its a good place to reset all transient state of the component (self->item is the classic). This happens much earlier than the actual component deallocation. Or, if the component is cached somewhere, eg in the persistent page or in the navigation, its not deallocated at all. Basically what the method name says: component go to 'sleep'. Keep what you need to remember, but free all stuff which can be reconstructed w/o effort. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Dec 10 13:36:06 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 10 Dec 2007 14:36:06 +0100 Subject: [OGo-Developer] click-to-dial & Asterisk Message-ID: <20071210133607.1F9AD4A502@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 10.12.2007, at 14:18, Sebastian Reitenbach wrote: > > Well, the -sleep, -awake, ... stuff I also not yet understood, but > > at least I understand, that it is not recommended to use the page > > cache. > > > -awake is mostly useless, but -sleep is called when the component what about the rare cases where its not useless, well, I don't know any, but as you say mostly, I assume there must be a reason for -awake. > object is not used by SOPE anymore (the current request has been > processed). Hence its a good place to reset all transient state of the > component (self->item is the classic). > > This happens much earlier than the actual component deallocation. Or, > if the component is cached somewhere, eg in the persistent page or in > the navigation, its not deallocated at all. > > Basically what the method name says: component go to 'sleep'. Keep > what you need to remember, but free all stuff which can be > reconstructed w/o effort. Ah, this is something coming from within sope, ok, slowly I think I got the picture. All useful info to include into the dev-docs ;) I only have some rare pages written, but I hope by writing, I'll get a better picture of how everything is working. I hope I'll find some time to come up with sth. first useful on the documentation@ list this week. thanks, Sebastian From developer@opengroupware.org Sun Dec 16 10:44:32 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 16 Dec 2007 11:44:32 +0100 Subject: [OGo-Developer] Re: CTI In General [Was: Re: [OGo-Users] OGo & Asterisk] Message-ID: <20071216104432.BA17D5A219@smtp.l00-bugdead-prods.de> Hi, users@opengroupware.org wrote: > > Been following this asterisk CTI dialer thread with great enthusiasm. I can > > really use this in the future and will start to build up a server next week > > when I get some time. Just a question. What are the plans for implementing > > missed calls and the resulting messages? Will these be accessible via the UI > > some how? I know that with asterisk you can do many things with message, just > > wondering what the current state of implementation is or in what direction > > are you moving? > > I'm also interested in CTI, but not specifically Asterisk. Perhaps we > can extend the CTI capabilities of OGo in a generic fashion like the > current CTI support? > > Currently the CTI support is via an 'interface' that just declares two > methods - > - (BOOL)canDialNumber:(NSString *)_number; > - (BOOL)dialNumber:(NSString *)_number fromDevice:(NSString *)_device; > - and just supports poking the PBX to make a call from within OGo. > > If someone is developing Asterisk support for more features [preferably > as a bundle] I'd like to see it not welded to Asterisk but use some > interface to inter-operate with the "PBX"; that way it could also > potentially support other systems. > > For instance, we have Nortel PBXs that use "Call Pilot" for messaging > and voice mail. "Call Pilot" offers a [really half-baked] Outlook > plugin that provides the ability to call contacts (like the OGo CTI) as > well as a [half-baked] "Unified Messaging". We've decoded / > reverse-engineered most of the functionality / protocol of that > solution. It is one of my projects for next year to try and make a CTI > bundle for OGo that supports Nortel systems. > > So for just e.g. name it NortelDialer.cti this should be easy, and can just be put aside. From my point of view, the CTI bundle api is just sufficient, so no need to change there sth. besides adding new Dialer bundles. > > Maybe we could agree on an extended CTI interface so we don't duplicate > work? (And perhaps this is more of a developers@ question). yeah, therefore taking over this discussion to the developer@ list. I am already unlucky with the name, as it not only supports Asterisk, but also works with Callweaver very well. OK, they share the same API, but that might change over the time. So I already thought about a more generic name for the UI, e.g. change it from AsteriskUI to PBXUI or TelephonyUI, sth. like that. I started the whole thing quite some time ago, my objective-c/webobjects skills where at a low level at the beginning. So there is very likely code in the actual AsteriskUI that will hurt your eyes. Therefore rewriting it to add wrapper classes to be able to use different PBX backends is likely a good idea. Well, I have no idea how to do that in a "good" way. I'd start taking a look to find out how e.g. the CTI Dialers are working, and try to copy that mechanism for the PBXUI stuff. So if someone wants to join the effort, I'd highly appreciate any help ;). For joint work, I think it would be great to have it in SVN, below Misc, with some write permissions for me there, and anybody else who wants to work on the PBXUI. > > Such as [this is off the cough] - > - (BOOL)newMesssages; > - (NSArray)listMessages; > - (UnifiedMessage)getMessage;(NSString *)_messageId; > - (BOOL)deleteMessage:(NSString *)_messageId; > - (BOOL)forwardMessage:(NSString *)_messageId > toExtension:(NSString *)_extensionId; > > And maybe do something the same for CDR? Just encapsulate core / > fundamental CDR and unified messaging support. CDR seems like it could > be pretty simple as it is a read-only thing. > > This way (a) nothing would need to effect OGo Core and we could > potentially support multiple system. I think integrating the whole CDR stuff into the PBXUI first, keeping it as a separate bundle, makes sense. Does the Nortel PBX also record these details to a database? or do you have to query it via the protocol you mentioned? However, I take a look at all that stuff I implemented already, and will propose a list of high level methods for the wrapper class for further discussion. Or should such a stuff be implemented as a @protocol ? Just the problem I have with the Asterisk Management API is, that the things I've implemented up to now follow the same output scheme, easy to parse. There are plenty of more possibilities, but the other commands and their output follow the output from the Asterisk command line interface. So for every additional command an own parser has to be written, therefore I got a bit stuck with the AsteriskUI at that point. In my eyes it would be cleaner to tune the Asterisk to make the missing commands follow the AGI output scheme too, but I never took a closer look at that route. However, sth. needs to be done there. > > My ultimate dream would be to see a IMAP<->DAV gateway [1] in ZideStore > and a UnifiedMessage<->DAV gateway so apps could use a "real" Unified > Message store to at least see a user's messages. The latter should be > relatively easy if there is a Unified Messaging bundle/interface. But I > suppose that may be a ways off [ first I have to get some *@&$*&^@$@$ > content to appear in a ^@&^@#*&@# ZideStore folder ]. > > for sure. kind regards Sebastian From developer@opengroupware.org Mon Dec 17 14:02:28 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Mon, 17 Dec 2007 09:02:28 -0500 Subject: [OGo-Developer] Re: CTI In General [Was: Re: [OGo-Users] OGo & Asterisk] In-Reply-To: <20071216104432.BA17D5A219@smtp.l00-bugdead-prods.de> References: <20071216104432.BA17D5A219@smtp.l00-bugdead-prods.de> Message-ID: <1197900148.8605.10.camel@WM_ADAM1.morrison.iserv.net> --=-hqZPLC7VhnfKFomImAeJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > > So for just e.g. name it NortelDialer.cti this should be easy Yep. > be put aside. From my point of view, the CTI bundle api is just sufficien= t,=20 > so no need to change there sth. besides adding new Dialer bundles. I agree, but the bundle only provides the functionality for the dialer. > I started the whole thing quite some time ago, my objective-c/webobjects=20 > skills where at a low level at the beginning. So there is very likely cod= e > in the actual AsteriskUI that will hurt your eyes.=20 Understood, I have the same issue in zOGI. The code I wrote first is horrible to the code I wrote later. Just the nature of the beast. > For joint work, I think it would be great to have it in SVN, below Misc,=20 > with some write permissions for me there, and anybody else who wants to w= ork=20 > on the PBXUI. Agree. > I think integrating the whole CDR stuff into the PBXUI first, keeping it = as=20 > a separate bundle, makes sense. > Does the Nortel PBX also record these details to a database?=20 Sort of. I think in most cases, regardless of PBX kind, there is going to be some routine to slurp CDR data from the PBX into OGo. > or do you have to query it via the protocol you mentioned? CDR on the BCM is accessed through a wretched little protocol, but I don't see that as part of "OGo's problem". OGo should just use the CDR data it finds in its database and now worry about how it got there. > However, I take a look at all that stuff I implemented already, and will=20 > propose a list of high level methods for the wrapper class for further=20 > discussion. Or should such a stuff be implemented as a @protocol ? Seems like it to me. But that is an implementation detail, either way will work. > Just the problem I have with the Asterisk Management API is, that the thi= ngs=20 > I've implemented up to now follow the same output scheme, easy to parse. > There are plenty of more possibilities, but the other commands and their=20 > output follow the output from the Asterisk command line interface. So for > every additional command an own parser has to be written, therefore I got= a=20 > bit stuck with the AsteriskUI at that point. In my eyes it would be clean= er > to tune the Asterisk to make the missing commands follow the AGI output=20 > scheme too, but I never took a closer look at that route. However, sth.=20 > needs to be done there. Not familiar enough with Asterisk to really comment on any of that. As long as the UI uses commands or an API/protocol to interact with the underlying device the details all will be well. > > My ultimate dream would be to see a IMAP<->DAV gateway [1] in ZideStore > > and a UnifiedMessage<->DAV gateway so apps could use a "real" Unified > > Message store to at least see a user's messages. The latter should be > > relatively easy if there is a Unified Messaging bundle/interface. But = I > > suppose that may be a ways off [ first I have to get some *@&$*&^@$@$ > > content to appear in a ^@&^@#*&@# ZideStore folder ]. > > > for sure. --=-hqZPLC7VhnfKFomImAeJ 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) iD8DBQBHZoF0LRePpNle04MRAjwZAJ488OZp/iixM1KJR7OcGa+a+ozMUgCfUkLY IXbglNXmHj25udGX0e2VkFc= =MCSZ -----END PGP SIGNATURE----- --=-hqZPLC7VhnfKFomImAeJ-- From developer@opengroupware.org Mon Dec 17 15:32:09 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 17 Dec 2007 16:32:09 +0100 Subject: [OGo-Developer] Re: CTI In General [Was: Re: [OGo-Users] OGo &Asterisk] Message-ID: <20071217153209.C8A7D5A5A5@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > > > > So for just e.g. name it NortelDialer.cti this should be easy > > Yep. > > > be put aside. From my point of view, the CTI bundle api is just sufficient, > > so no need to change there sth. besides adding new Dialer bundles. > > I agree, but the bundle only provides the functionality for the dialer. for sure, the additional stuff I wrote for Asterisk is a different question. > > > I started the whole thing quite some time ago, my objective-c/webobjects > > skills where at a low level at the beginning. So there is very likely code > > in the actual AsteriskUI that will hurt your eyes. > > Understood, I have the same issue in zOGI. The code I wrote first is > horrible to the code I wrote later. Just the nature of the beast. > > > For joint work, I think it would be great to have it in SVN, below Misc, > > with some write permissions for me there, and anybody else who wants to work > > on the PBXUI. > > Agree. > > > I think integrating the whole CDR stuff into the PBXUI first, keeping it as > > a separate bundle, makes sense. > > Does the Nortel PBX also record these details to a database? > > Sort of. I think in most cases, regardless of PBX kind, there is going > to be some routine to slurp CDR data from the PBX into OGo. > > > or do you have to query it via the protocol you mentioned? > > CDR on the BCM is accessed through a wretched little protocol, but I > don't see that as part of "OGo's problem". OGo should just use the CDR > data it finds in its database and now worry about how it got there. yeah, not really the problem of ogo. > > > However, I take a look at all that stuff I implemented already, and will > > propose a list of high level methods for the wrapper class for further > > discussion. Or should such a stuff be implemented as a @protocol ? > > Seems like it to me. But that is an implementation detail, either way > will work. > > > Just the problem I have with the Asterisk Management API is, that the things > > I've implemented up to now follow the same output scheme, easy to parse. > > There are plenty of more possibilities, but the other commands and their > > output follow the output from the Asterisk command line interface. So for > > every additional command an own parser has to be written, therefore I got a > > bit stuck with the AsteriskUI at that point. In my eyes it would be cleaner > > to tune the Asterisk to make the missing commands follow the AGI output > > scheme too, but I never took a closer look at that route. However, sth. > > needs to be done there. > > Not familiar enough with Asterisk to really comment on any of that. As > long as the UI uses commands or an API/protocol to interact with the > underlying device the details all will be well. yeah, nothing to worry about here. These are some asterisk internal details, whoever implements the protocol for the asterisk, that person has to care. Sebastian From developer@opengroupware.org Tue Dec 18 15:06:13 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Tue, 18 Dec 2007 16:06:13 +0100 Subject: [OGo-Developer] Incompatibility with WO in WOSwitchComponent? Message-ID: <62F3CB90-BEDE-497A-A385-64E4CAB6E5FE@sente.ch> Hi, First of all, I'm working with an old snapshot of SOPE sources =20 (2007-05-29), and can't access your repository, neither from svn, nor =20= from http://svn.opengroupware.org/viewcvs/. Can you fix the access? =20 Thanks. I'm using a WOSwitchComponent, which returns a stateful component =20 (IIRC there are no stateless components in SOPE). Problem is that =20 this stateful component loses its state, because the component is =20 created no more than four times in a request-response loop! So any =20 state passed to my component during the takeValuesFromRequest is lost =20= when I reach the appendToResponse. The WOSwitchComponent instance is =20 still the same, though, but it recreates the component each time it =20 needs it, unlike what WebObjects does, thus preventing any child =20 component to have a state. Has this bug been fixed since May? Or =20 should I do the change myself? Cheers, St=E9phane From developer@opengroupware.org Tue Dec 18 16:23:47 2007 From: developer@opengroupware.org (developer@opengroupware.org) Date: Tue, 18 Dec 2007 16:23:47 +0000 Subject: [OGo-Developer] Incompatibility with WO in WOSwitchComponent? In-Reply-To: <62F3CB90-BEDE-497A-A385-64E4CAB6E5FE@sente.ch> References: <62F3CB90-BEDE-497A-A385-64E4CAB6E5FE@sente.ch> Message-ID: <1378740224-1197995052-cardhu_decombobulator_blackberry.rim.net-773500126-@bxe045.bisx.produk.on.blackberry> Q2FuIHNvbWVvbmUgcGxlYXNlIHVuc3Vic2NyaWJlIG1lIGZyb20gdGhpcyBsaXN0Pw0KDQpJJ3Zl IHRyaWVkIG9uIG15IG93biBidXQgaXQgZG9lc24ndCB3b3JrLg0KDQpTZW50IGZyb20gbXkgQmxh Y2tCZXJyea4gd2lyZWxlc3MgZGV2aWNlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBTdOlwaGFuZSBDb3J0aOlzeSA8c3RlcGhhbmVAc2VudGUuY2g+DQoNCkRhdGU6IFR1ZSwg MTggRGVjIDIwMDcgMTY6MDY6MTMgDQpUbzpkZXZlbG9wZXJAb3Blbmdyb3Vwd2FyZS5vcmcNClN1 YmplY3Q6IFtPR28tRGV2ZWxvcGVyXSBJbmNvbXBhdGliaWxpdHkgd2l0aCBXTyBpbiBXT1N3aXRj aENvbXBvbmVudD8NCg0KDQpIaSwNCg0KRmlyc3Qgb2YgYWxsLCBJJ20gd29ya2luZyB3aXRoIGFu IG9sZCBzbmFwc2hvdCBvZiBTT1BFIHNvdXJjZXMgIA0KKDIwMDctMDUtMjkpLCBhbmQgY2FuJ3Qg YWNjZXNzIHlvdXIgcmVwb3NpdG9yeSwgbmVpdGhlciBmcm9tIHN2biwgbm9yICANCmZyb20gaHR0 cDovL3N2bi5vcGVuZ3JvdXB3YXJlLm9yZy92aWV3Y3ZzLy4gQ2FuIHlvdSBmaXggdGhlIGFjY2Vz cz8gIA0KVGhhbmtzLg0KDQpJJ20gdXNpbmcgYSBXT1N3aXRjaENvbXBvbmVudCwgd2hpY2ggcmV0 dXJucyBhIHN0YXRlZnVsIGNvbXBvbmVudCAgDQooSUlSQyB0aGVyZSBhcmUgbm8gc3RhdGVsZXNz IGNvbXBvbmVudHMgaW4gU09QRSkuIFByb2JsZW0gaXMgdGhhdCAgDQp0aGlzIHN0YXRlZnVsIGNv bXBvbmVudCBsb3NlcyBpdHMgc3RhdGUsIGJlY2F1c2UgdGhlIGNvbXBvbmVudCBpcyAgDQpjcmVh dGVkIG5vIG1vcmUgdGhhbiBmb3VyIHRpbWVzIGluIGEgcmVxdWVzdC1yZXNwb25zZSBsb29wISBT byBhbnkgIA0Kc3RhdGUgcGFzc2VkIHRvIG15IGNvbXBvbmVudCBkdXJpbmcgdGhlIHRha2VWYWx1 ZXNGcm9tUmVxdWVzdCBpcyBsb3N0ICANCndoZW4gSSByZWFjaCB0aGUgYXBwZW5kVG9SZXNwb25z ZS4gVGhlIFdPU3dpdGNoQ29tcG9uZW50IGluc3RhbmNlIGlzICANCnN0aWxsIHRoZSBzYW1lLCB0 aG91Z2gsIGJ1dCBpdCByZWNyZWF0ZXMgdGhlIGNvbXBvbmVudCBlYWNoIHRpbWUgaXQgIA0KbmVl ZHMgaXQsIHVubGlrZSB3aGF0IFdlYk9iamVjdHMgZG9lcywgdGh1cyBwcmV2ZW50aW5nIGFueSBj aGlsZCAgDQpjb21wb25lbnQgdG8gaGF2ZSBhIHN0YXRlLiBIYXMgdGhpcyBidWcgYmVlbiBmaXhl ZCBzaW5jZSBNYXk/IE9yICANCnNob3VsZCBJIGRvIHRoZSBjaGFuZ2UgbXlzZWxmPw0KDQpDaGVl cnMsDQoNClN06XBoYW5lDQoNCg0KLS0NCk9wZW5Hcm91cHdhcmUub3JnIERldmVsb3Blcg0KZGV2 ZWxvcGVyQG9wZW5ncm91cHdhcmUub3JnDQpodHRwOi8vbWFpbC5vcGVuZ3JvdXB3YXJlLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RldmVsb3Blcg0K From developer@opengroupware.org Tue Dec 18 16:45:17 2007 From: developer@opengroupware.org (Helge Hess) Date: Tue, 18 Dec 2007 17:45:17 +0100 Subject: [OGo-Developer] Incompatibility with WO in WOSwitchComponent? In-Reply-To: <1378740224-1197995052-cardhu_decombobulator_blackberry.rim.net-773500126-@bxe045.bisx.produk.on.blackberry> References: <62F3CB90-BEDE-497A-A385-64E4CAB6E5FE@sente.ch> <1378740224-1197995052-cardhu_decombobulator_blackberry.rim.net-773500126-@bxe045.bisx.produk.on.blackberry> Message-ID: On 18.12.2007, at 17:23, scoutts@bcs.org.uk wrote: > Can someone please unsubscribe me from this list? Instructions on how to do this are on the bottom of every single mail. Thanks, Helge From developer@opengroupware.org Wed Dec 19 14:38:01 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Wed, 19 Dec 2007 09:38:01 -0500 Subject: [OGo-Developer] SVN server Message-ID: <210a-47692d00-5-b73aaab0@100786487> Hi all, I don't know if anyone noticed but the SVN server has not been updated since at least monday morning and now it does connect but sends no data... Cheers! -- 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 Wed Dec 19 14:47:04 2007 From: developer@opengroupware.org (Helge Hess) Date: Wed, 19 Dec 2007 15:47:04 +0100 Subject: [OGo-Developer] SVN server In-Reply-To: <210a-47692d00-5-b73aaab0@100786487> References: <210a-47692d00-5-b73aaab0@100786487> Message-ID: <6632F414-1813-4C1F-96DA-808D35CF52DF@opengroupware.org> On 19.12.2007, at 15:38, Wolfgang Sourdeau wrote: > I don't know if anyone noticed but the SVN server has not been > updated since at least monday morning and now it does connect but > sends no data... Should have been fixed by now, a USV failed. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Wed Dec 19 19:52:19 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Wed, 19 Dec 2007 14:52:19 -0500 Subject: [OGo-Developer] SVN server In-Reply-To: 6632F414-1813-4C1F-96DA-808D35CF52DF@opengroupware.org Message-ID: <3401-47697680-11-b73b3ab0@39871552> Le 19 D=C3=A9c. 2007 09:47 EST, Helge Hess a =C3=A9crit: > On 19.12.2007, at 15:38, Wolfgang Sourdeau wrote: > > I don't know if anyone noticed but the SVN server has not been > > updated since at least monday morning and now it does connect but > > sends no data... > > > Should have been fixed by now, a USV failed. Thanks, it works now! -- 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 Dec 25 12:46:16 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 25 Dec 2007 13:46:16 +0100 Subject: [OGo-Developer] OGo Invoice Application Message-ID: <20071225124616.B3162376EF@smtp.l00-bugdead-prods.de> Hi, the last days I again fiddled a bit around with the OGo Invoice application and actually got it working. I fixed the unresolved symbol problem of LSinvoice.lso/LSInvoice, so now it is actually usable again. I also found a solution to the problem that also Helge mentioned in the README, regarding the double values in the database. There are more or less two ways to fix the problem. 1. add a switch statement to sope-gdl11/PostgreSQL/NSNumber+PGVal.m checking for t_double. 2. exchange all t_double database field definitions in Misc/Invoice code with float. Float is implemented in NSNumber+PGVal.m to use atof(), so returning a double value. What would be the way to go? Another question, when I am watching an article, or an article category, then there is a "switch to Skyrix..." and "switch to MDLink..." button. The button, company names, ... are hardcoded in the objective-c source of the Invoice application. Is there any good reason for that? If not, I'd go make it configurable, also the amount of companies at all. Also when I create an invoice, it seems the invoice is generated for the "MDLink GmbH" as the company that is selling sth. Is there a way to say that the invoice is generated for the other company? I haven't seen anything that would enable me to do so. Further, I am wondering, where can I use the abbreviations of the article categories? I defined some, but have no idea, where to use them. Also when writing an invoice, I find the article selection a bit hairy. The user has to know all article numbers, with no ability to lookup or search for articles by name/category... Further, for each invoice that is created, a company has to exist in the database. What about customers, that just show up and will not come back again? well, that could be solved by creating a general company in the database. Then this company is used to attach invoices for such people? kind regards Sebastian From developer@opengroupware.org Tue Dec 25 22:19:56 2007 From: developer@opengroupware.org (Helge Hess) Date: Tue, 25 Dec 2007 23:19:56 +0100 Subject: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071225124616.B3162376EF@smtp.l00-bugdead-prods.de> References: <20071225124616.B3162376EF@smtp.l00-bugdead-prods.de> Message-ID: <2D67B36C-2686-4FBC-AE8E-D0CDEE53248D@opengroupware.org> On 25.12.2007, at 13:46, Sebastian Reitenbach wrote: > the last days I again fiddled a bit around with the OGo Invoice > application > and actually got it working. Why? Its really not worth the effort. > 1. add a switch statement to sope-gdl11/PostgreSQL/NSNumber+PGVal.m > checking > for t_double. > > 2. exchange all t_double database field definitions in Misc/Invoice > code > with float. Float is implemented in NSNumber+PGVal.m to use atof(), so > returning a double value. > > What would be the way to go? Both double and float are completely inappropriate for storing moneytary values. You need integer arithmetic. In Apple Foundation this is done by NSDecimalNumber which is unsupported in libFoundation ... > Another question, when I am watching an article, or an article > category, > then there is a "switch to Skyrix..." and "switch to MDLink..." > button. > The button, company names, ... are hardcoded in the objective-c > source of > the Invoice application. Is there any good reason for that? If not, > I'd go > make it configurable, also the amount of companies at all. Probably not. But then, the whole app is not worth the effort. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Wed Dec 26 14:41:35 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Wed, 26 Dec 2007 09:41:35 -0500 Subject: [OGo-Developer] OGo Invoice Application In-Reply-To: <2D67B36C-2686-4FBC-AE8E-D0CDEE53248D@opengroupware.org> References: <20071225124616.B3162376EF@smtp.l00-bugdead-prods.de> <2D67B36C-2686-4FBC-AE8E-D0CDEE53248D@opengroupware.org> Message-ID: <1198680095.8811.11.camel@WM_ADAM1.morrison.iserv.net> --=-9j9aGWa+Cq4OJJD//E6y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > the last days I again fiddled a bit around with the OGo Invoice =20 > > application > > and actually got it working. > Why? Its really not worth the effort. I think he's using it as an example / diddle application. Which makes some sense since it is the only not-entirely-trivial non-core OGo application in existence. > > 1. add a switch statement to sope-gdl11/PostgreSQL/NSNumber+PGVal.m =20 > > checking > > for t_double. > > 2. exchange all t_double database field definitions in Misc/Invoice =20 > > code > > with float. Float is implemented in NSNumber+PGVal.m to use atof(), so > > returning a double value. > > What would be the way to go? > Both double and float are completely inappropriate for storing =20 > moneytary values. You need integer arithmetic. Yep, float and double are disasterous ways to store monetary values. --=-9j9aGWa+Cq4OJJD//E6y 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) iD8DBQBHcmgfLRePpNle04MRAgk6AJ9xjHVh/d1YXjZKiTpkvrCi5bPiJwCfbNDW aI/5Pk8NZYG4XNruCihlbPk= =lM08 -----END PGP SIGNATURE----- --=-9j9aGWa+Cq4OJJD//E6y-- From developer@opengroupware.org Wed Dec 26 14:56:58 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 26 Dec 2007 15:56:58 +0100 Subject: [OGo-Developer] OGo Invoice Application Message-ID: <20071226145659.8DAB83786C@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > On 25.12.2007, at 13:46, Sebastian Reitenbach wrote: > > the last days I again fiddled a bit around with the OGo Invoice > > application > > and actually got it working. > > Why? Its really not worth the effort. I take the app as a playground, finding out how things are working, especially the datasource thing, so that I can later implement sth. for the PBX CDR. Furthermore I like to waste my spare time with useless things ;) > > > 1. add a switch statement to sope-gdl11/PostgreSQL/NSNumber+PGVal.m > > checking > > for t_double. > > > > 2. exchange all t_double database field definitions in Misc/Invoice > > code > > with float. Float is implemented in NSNumber+PGVal.m to use atof(), so > > returning a double value. > > > > What would be the way to go? > > Both double and float are completely inappropriate for storing > moneytary values. You need integer arithmetic. In Apple Foundation > this is done by NSDecimalNumber which is unsupported in > libFoundation ... ah, another reason to drop libFoundation and to switch to gnustep-base. > > > Another question, when I am watching an article, or an article > > category, > > then there is a "switch to Skyrix..." and "switch to MDLink..." > > button. > > The button, company names, ... are hardcoded in the objective-c > > source of > > the Invoice application. Is there any good reason for that? If not, > > I'd go > > make it configurable, also the amount of companies at all. > > Probably not. But then, the whole app is not worth the effort. I don't really care about worth of effort, if it is just fun for me. Cheers, Sebastian From developer@opengroupware.org Wed Dec 26 14:59:25 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 26 Dec 2007 15:59:25 +0100 Subject: [OGo-Developer] OGo Invoice Application Message-ID: <20071226145925.625A6377B9@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > > > the last days I again fiddled a bit around with the OGo Invoice > > > application > > > and actually got it working. > > Why? Its really not worth the effort. > > I think he's using it as an example / diddle application. Which makes > some sense since it is the only not-entirely-trivial non-core OGo > application in existence. I couldn't have it said better. Sebastian From developer@opengroupware.org Thu Dec 27 00:21:37 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 27 Dec 2007 01:21:37 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071226145659.8DAB83786C@smtp.l00-bugdead-prods.de> References: <20071226145659.8DAB83786C@smtp.l00-bugdead-prods.de> Message-ID: <161097B6-89B9-41A5-B193-5507D45D5CAD@opengroupware.org> On 26.12.2007, at 15:56, Sebastian Reitenbach wrote: > ah, another reason to drop libFoundation and to switch to gnustep- > base. What a useless comment ... it fixes exactly 0 of the existing issues we have with gnustep-base. Just to reiterate what needs to be done for a gstep-base port: a) make OGo (fully) working with it. This might seem like little work but locating and eliminating gstep-base incompats are a huge time killer. Note that I say gstep-base incompats because OGo does work quite well on Cocoa. I suspect that this is because Cocoa cares about API compat, even if its legacy according to Foundation docs ... b) make OGo/SOPE on gstep install and work in a *proper* FHS hierarchy, preferably the same like we have now. This is probably a lot of work, it means bumping all makefiles to gstep-make-2.x, either port the old fhs.make to that or use the new gstep-make-2.x FHS support (which might be quite different to what we want), and fix the code to honour new layouts. c) make gstep-make/base API stable. Doing that once is easy because we could just make a vendor branch and use it. But the vendor branch would need maintenance as well, and a fork in general s***s. This is an inherent gstep issue and I would be massively surprised if it would go away ;-/ Personally I would love to see gstep-base replace libFoundation for the ObjC code, but unless the issues above get resolved there is little hope. And since all of points are quite a bit of work, my (current) assumption is that they will probably never happen. Personally I would prefer to focus on getting JOPE compiled and working with the GCC Java compiler (GCJ). Helge PS: obviously Java has BigDecimal ;-) From developer@opengroupware.org Thu Dec 27 07:03:33 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 27 Dec 2007 08:03:33 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> Hi, > Just to reiterate what needs to be done for a gstep-base port: > > a) make OGo (fully) working with it. This might seem like little > work but locating and eliminating gstep-base incompats are a > huge time killer. Note that I say gstep-base incompats because > OGo does work quite well on Cocoa. I suspect that this is > because Cocoa cares about API compat, even if its legacy > according to Foundation docs ... sogo is using with gnustep-base, so sope is known to work with it. But I know, there are still subtle compatibility bugs regarding ogo, e.g. memory management... > > b) make OGo/SOPE on gstep install and work in a *proper* FHS > hierarchy, preferably the same like we have now. This is > probably a lot of work, it means bumping all makefiles to > gstep-make-2.x, either port the old fhs.make to that or use > the new gstep-make-2.x FHS support (which might be quite > different to what we want), and fix the code to honour new > layouts. I've created sope gnumakefiles to be compatible for gnustep-make 2.0. I just removed the fhs.make stuff, using the gnustep-make builtin stuff. But I have no real idea, what exactly you mean with *proper* FHS layout. Is there a document that states, what would be a acceptable layout or not? I've no idea how my sope makefiles would work together with cocoa on a Mac. In my eyes, this point b is the easiest to solve, and I'd go update my sope gnumakefiles, and create some for ogo, but it would really really help, if there is a document that states, how a good layout would look like. Reading the existing makefiles to figure out, is a lot of hard work. OK, I hope to get some new gnumakefiles for ogo done in the next days, and will post them here or on the ogo-gnustep-port@ list. > > c) make gstep-make/base API stable. Doing that once is easy because > we could just make a vendor branch and use it. But the vendor > branch would need maintenance as well, and a fork in general > s***s. This is an inherent gstep issue and I would be > massively surprised if it would go away ;-/ again, sogo is based on gnustep-base, so in my eyes, it cannot be such a big deal. Well I have no idea, how much time is spent to keep sogo compatible and working with gnustep-base. As I am subscribed to the CVS changes of gnustep-base, I see the changes that happen day by day. It's not that overwhelming ;) > > Personally I would love to see gstep-base replace libFoundation for > the ObjC code, but unless the issues above get resolved there is me too. > little hope. And since all of points are quite a bit of work, my > (current) assumption is that they will probably never happen. you know that I am from time to time try to compile ogo against gnustep-base and get it running. I hope to get the problems fixed in 2008. > > Personally I would prefer to focus on getting JOPE compiled and > working with the GCC Java compiler (GCJ). Personally I have a hate against Java (I know it's a bit stupid, but it is just as it it), and I doubt that will change in the near future ;) As I do all that OGo hacking in my spare time, for me its all about fun. I just don't have fun with Java. cheers Sebastian > > Helge > > PS: obviously Java has BigDecimal ;-) > From developer@opengroupware.org Thu Dec 27 09:04:06 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 27 Dec 2007 10:04:06 +0100 Subject: [OGo-Developer] exception in PrintfFormatScanner.m Message-ID: <20071227090407.1DCB83786D@smtp.l00-bugdead-prods.de> Hi, I just ran into a segfault in libFoundation/Foundation/PrintfFormatScanner.m I opened a bug report with a patch attached to fix the problem. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1932 While trying to fix the problem i figured out, there is a second PrintfFormatScanner.m in ./sope-gdl1/GDLAccess/FoundationExt/PrintfFormatScanner.m. Comparing both files shows only minor differences, no functional differences, there is just one more #include in the libFoundation file a. As I had to fix the problem in the libFoundation file, I wonder what is the reason for having the PrintfFormatScanner.m in sope-gdl1? thanks Sebastian From developer@opengroupware.org Thu Dec 27 13:05:09 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 27 Dec 2007 14:05:09 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> Message-ID: <3CE393AE-3334-4AA3-8F2C-EC0A1E0BC0E3@opengroupware.org> On 27.12.2007, at 08:03, Sebastian Reitenbach wrote: > sogo is using with gnustep-base, so sope is known to work with it. So what, SOGo was built something like 8 years after OGo and is a significantly smaller codebase, and is currently developed on top of gstep-base. > But I know, there are still subtle compatibility bugs regarding ogo, > e.g. > memory management... Exactly. As I mentioned, Cocoa works quite fine, so its not really OGo specific. >> > But I have no real idea, what exactly you mean with *proper* FHS > layout. Well, what is the FHS layout you accomplished? Do the server binaries properly live in sbin. Are binaries properly versioned and can be installed in multiple versions? > Is there a document that states, what would be a acceptable layout > or not? The wished for layout is the one we currently have (more or less what is required by FHS/Debian?!). > I've no idea how my sope makefiles would work together with cocoa on > a Mac. That shouldn't be an issue. > In my eyes, this point b is the easiest to solve, and I'd go update > my sope > gnumakefiles, and create some for ogo Yes, it would be very nice if we could move SOPE and OGo to gstep-make 2.0. > but it would really really help, if there is a document that > states, how a good layout would look like. That would be the FHS standard. Its probably easiest to look at the current layout ... But actually its rather simple: ROOT/ sbin/ ogo-webui-x.y ogo-zidestore-x.y ... bin/ ogo-account-add-x.y ... lib/ libOGoABC.x.y.z sope-x.y/ zidestore-x.y/ opengroupware-x.y/ commands/ ... datasources/ ... webui/ PersonsUI.lso ... share/ sope-x.y/ zidestore-x.y/ opengroupware-x.y/ templates/ ... >> c) make gstep-make/base API stable. Doing that once is easy because >> we could just make a vendor branch and use it. But the vendor >> branch would need maintenance as well, and a fork in general >> s***s. This is an inherent gstep issue and I would be >> massively surprised if it would go away ;-/ > again, sogo is based on gnustep-base, so in my eyes, it cannot be > such a big > deal. I fail to see how your eyes work then, its rather obvious :-) > Well I have no idea, how much time is spent to keep sogo compatible > and working with gnustep-base. As I am subscribed to the CVS changes > of > gnustep-base, I see the changes that happen day by day. It's not that > overwhelming ;) The issue is that certain important things are quite unstable, eg KVC. Subtle changes are done and few people really care about backwards compat. Even non-subtle, large changes are done w/o upgrade pathes, eg just consider how much work the gstep-make 2.0 brought to us! >> Personally I would prefer to focus on getting JOPE compiled and >> working with the GCC Java compiler (GCJ). > Personally I have a hate against Java (I know it's a bit stupid Yes, it really is ;-) Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Dec 27 13:06:48 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 27 Dec 2007 14:06:48 +0100 Subject: [OGo-Developer] exception in PrintfFormatScanner.m In-Reply-To: <20071227090407.1DCB83786D@smtp.l00-bugdead-prods.de> References: <20071227090407.1DCB83786D@smtp.l00-bugdead-prods.de> Message-ID: On 27.12.2007, at 10:04, Sebastian Reitenbach wrote: > I wonder what is the reason for having the PrintfFormatScanner.m in > sope-gdl1? Its in there for other Foundation libraries. (if you compile sope-gdl1 against gstep-base/Cocoa instead of lF). Oh, and a subclass is used for SQL and qualifier formatting in gdl1. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Dec 27 13:45:32 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 27 Dec 2007 14:45:32 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071227134533.134C637968@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 27.12.2007, at 08:03, Sebastian Reitenbach wrote: > > sogo is using with gnustep-base, so sope is known to work with it. > > So what, SOGo was built something like 8 years after OGo and is a > significantly smaller codebase, and is currently developed on top of > gstep-base. > > > But I know, there are still subtle compatibility bugs regarding ogo, > > e.g. > > memory management... > > Exactly. As I mentioned, Cocoa works quite fine, so its not really OGo > specific. > > >> > > But I have no real idea, what exactly you mean with *proper* FHS > > layout. > > Well, what is the FHS layout you accomplished? Do the server binaries > properly live in sbin. Are binaries properly versioned and can be > installed in multiple versions? yes, they are in sbin and have the version numbers, e.g. /usr/local/sbin/sope-4.7. > > > Is there a document that states, what would be a acceptable layout > > or not? > > The wished for layout is the one we currently have (more or less what > is required by FHS/Debian?!). afaik, there are gnustep-make packages for debian. so there is a filesystem layout specified for debian, and other distris/OS have their own. I think however these gnustep-make packages are installed, they have the correct filesystem layout for the system already configured/setup. > > > I've no idea how my sope makefiles would work together with cocoa on > > a Mac. > > That shouldn't be an issue. ah, ok good. > > > In my eyes, this point b is the easiest to solve, and I'd go update > > my sope > > gnumakefiles, and create some for ogo > > Yes, it would be very nice if we could move SOPE and OGo to gstep-make > 2.0. ok, then this just raised in priority, I'll see that I can provide some patches to the gnumakefiles for sope and ogo in the next days. > > > but it would really really help, if there is a document that > > states, how a good layout would look like. > > That would be the FHS standard. Its probably easiest to look at the > current layout ... But actually its rather simple: > > ROOT/ > sbin/ > ogo-webui-x.y > ogo-zidestore-x.y > ... > bin/ > ogo-account-add-x.y > ... > lib/ > libOGoABC.x.y.z > sope-x.y/ > zidestore-x.y/ > opengroupware-x.y/ > commands/ > ... > datasources/ > ... > webui/ > PersonsUI.lso > ... > share/ > sope-x.y/ > zidestore-x.y/ > opengroupware-x.y/ > templates/ > ... OK, I see, and I think that should work very well with gnustep-make 2.0.X. > > > >> c) make gstep-make/base API stable. Doing that once is easy because > >> we could just make a vendor branch and use it. But the vendor > >> branch would need maintenance as well, and a fork in general > >> s***s. This is an inherent gstep issue and I would be > >> massively surprised if it would go away ;-/ > > again, sogo is based on gnustep-base, so in my eyes, it cannot be > > such a big > > deal. > > I fail to see how your eyes work then, its rather obvious :-) > > > > Well I have no idea, how much time is spent to keep sogo compatible > > and working with gnustep-base. As I am subscribed to the CVS changes > > of > > gnustep-base, I see the changes that happen day by day. It's not that > > overwhelming ;) > > The issue is that certain important things are quite unstable, eg KVC. > Subtle changes are done and few people really care about backwards > compat. > Even non-subtle, large changes are done w/o upgrade pathes, eg just > consider how much work the gstep-make 2.0 brought to us! ok, with gstep-make you are right, its incompatible. But in general I'd say, the gnustep-make 2. package makes a lot of thing easier in the makefiles. Regarding the other things, I cannot say much about it as I am not a seasoned objective-c programmer, just lacking that much experience over the time. > > > >> Personally I would prefer to focus on getting JOPE compiled and > >> working with the GCC Java compiler (GCJ). > > Personally I have a hate against Java (I know it's a bit stupid > > Yes, it really is ;-) and another point we agree... greetings Sebastian From developer@opengroupware.org Thu Dec 27 13:50:20 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Thu, 27 Dec 2007 08:50:20 -0500 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> Message-ID: <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> --=-+M8kQKwlSUh1j+05lADZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've created sope gnumakefiles to be compatible for gnustep-make 2.0. > I just removed the fhs.make stuff, using the gnustep-make builtin stuff. > But I have no real idea, what exactly you mean with *proper* FHS layout. > Is there a document that states, what would be a acceptable layout or not= ?=20 Yes. =20 http://www.pathname.com/fhs/pub/fhs-2.3.html http://www.pathname.com/fhs/ But pretty much it boils down to "is everything where a recently trained Linux admin would expect it to be." Configs in /etc, binaries in /bin, service binaries in /sbin, blah blah.=20 > > Personally I would love to see gstep-base replace libFoundation for =20 > > the ObjC code, but unless the issues above get resolved there is =20 > me too. I'm not nearly versed in the technology enough to have an opinion. :) My gut reaction comes from the fact that I was subscribed to the GNU-step project for awhile and it just doesn't appear to be going anywhere; at least from the perspective of an ignoramus. > > little hope. And since all of points are quite a bit of work, my =20 > > (current) assumption is that they will probably never happen. > you know that I am from time to time try to compile ogo against gnustep-b= ase=20 > and get it running. I hope to get the problems fixed in 2008. > > Personally I would prefer to focus on getting JOPE compiled and =20 > > working with the GCC Java compiler (GCJ). > Personally I have a hate against Java (I know it's a bit stupid, but it i= s=20 > just as it it), and I doubt that will change in the near future ;) As I d= o=20 > all that OGo hacking in my spare time, for me its all about fun. I just=20 > don't have fun with Java. Yea, I'm not a big fan either; the whole environment feels hacked together and building any decently sized Java app always seems an order of magnitude more complicated that it should be; DLL hell replaced by CLASSPATH hell. =20 But whatever, it does work and as a language it is a spitting distance from most others. It sure as anything beats doing assembly language on a cluster of Z80 processors - now *THAT* is awful. The first machine I worked on for $$$$ was a mini-computer that consisted of a cluster of 32 Z-80 processors managed by a central 80186 processor that moved data over "the network" via interrupt driven bank-switching - Ahhhhhh! Java is beautiful! --=-+M8kQKwlSUh1j+05lADZ 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) iD8DBQBHc62cLRePpNle04MRAkkBAJ4ktjJjD6ciDEkiPmaTAJL2EwfMuQCfad+x PrdSF38PLEWnPrLj27zEZvU= =vDh+ -----END PGP SIGNATURE----- --=-+M8kQKwlSUh1j+05lADZ-- From developer@opengroupware.org Thu Dec 27 13:55:13 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 27 Dec 2007 14:55:13 +0100 Subject: [OGo-Developer] exception in PrintfFormatScanner.m Message-ID: <20071227135513.E373237993@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 27.12.2007, at 10:04, Sebastian Reitenbach wrote: > > I wonder what is the reason for having the PrintfFormatScanner.m in > > sope-gdl1? > > Its in there for other Foundation libraries. (if you compile sope-gdl1 > against gstep-base/Cocoa instead of lF). > > Oh, and a subclass is used for SQL and qualifier formatting in gdl1. indeed, this is only available in libFoundation, then maybe the patch mentioned in the bugreport should be applied to both files. I still wonder, why I have seen this segfault only on that machine, and nowhere else before. cheers Sebastian From developer@opengroupware.org Thu Dec 27 14:04:47 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 27 Dec 2007 15:04:47 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <0662FC9A-63BA-495C-A1E5-14619F7A970B@opengroupware.org> On 27.12.2007, at 14:50, Adam Tauno Williams wrote: > DLL hell replaced by CLASSPATH hell. Well, from a deployment perspective it would be just like now ... if we get it compiled with GCJ. It produces real binaries and regular shared libraries. I think not having those is one of the bigger Linux deployment "issues" with Java, pretty similiar to why GNUstep deployment roots are annoying for server applications. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Dec 27 14:34:43 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Thu, 27 Dec 2007 09:34:43 -0500 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <0662FC9A-63BA-495C-A1E5-14619F7A970B@opengroupware.org> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> <0662FC9A-63BA-495C-A1E5-14619F7A970B@opengroupware.org> Message-ID: <1198766083.9325.25.camel@WM_ADAM1.morrison.iserv.net> --=-FX3JiI8ZLpnn09DMHWbF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > DLL hell replaced by CLASSPATH hell. > Well, from a deployment perspective it would be just like now ... if =20 > we get it compiled with GCJ. It produces real binaries and regular =20 > shared libraries. I think not having those is one of the bigger Linux =20 > deployment "issues" with Java, pretty similiar to why GNUstep =20 > deployment roots are annoying for server applications. Cool. =20 I host a number of Java applications, but they are all straight-up normal in-the-JVM apps. I've had horrible experiences trying to host multiple apps in the same Tomcat instance, for example, which I though was the whole bleedin point of an application container - deploy and go. (that and figuring out what is going on inside Tomcat's little mind is no fun either) I've never encountered GCJ and didn't realize it produced "real" binaries. Are they "real" in the sense that they can be copied to a machine without a JVM and run or are they "real" like Mono AOT libraries (which run like binaries but still need the original assembly)? --=-FX3JiI8ZLpnn09DMHWbF 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) iD8DBQBHc7gDLRePpNle04MRAoQOAJ9slBvdAD1J645XZhO4jG8ZWyVZfwCbBp0B KGRgLdmJ+05LOApdl1Nb4U8= =L7mJ -----END PGP SIGNATURE----- --=-FX3JiI8ZLpnn09DMHWbF-- From developer@opengroupware.org Thu Dec 27 14:37:43 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Thu, 27 Dec 2007 09:37:43 -0500 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <1198766083.9325.25.camel@WM_ADAM1.morrison.iserv.net> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> <0662FC9A-63BA-495C-A1E5-14619F7A970B@opengroupware.org> <1198766083.9325.25.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <1198766263.9325.29.camel@WM_ADAM1.morrison.iserv.net> --=-aA24j1oaLOVBRE5DyfRm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > > DLL hell replaced by CLASSPATH hell. > > Well, from a deployment perspective it would be just like now ... if =20 > > we get it compiled with GCJ. It produces real binaries and regular =20 > > shared libraries. I think not having those is one of the bigger Linux =20 > > deployment "issues" with Java, pretty similiar to why GNUstep =20 > > deployment roots are annoying for server applications. > Cool. =20 > I host a number of Java applications, but they are all straight-up > normal in-the-JVM apps. I've had horrible experiences trying to host > multiple apps in the same Tomcat instance, for example, which I though > was the whole bleedin point of an application container - deploy and go. > (that and figuring out what is going on inside Tomcat's little mind is > no fun either) > I've never encountered GCJ and didn't realize it produced "real" > binaries. Are they "real" in the sense that they can be copied to a > machine without a JVM and run or are they "real" like Mono AOT libraries > (which run like binaries but still need the original assembly)? Never mind. The website provides a beautifully direct answer to my question: http://gcc.gnu.org/java/ GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code. Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications. --=-aA24j1oaLOVBRE5DyfRm 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) iD8DBQBHc7i3LRePpNle04MRAvaMAJwM2myRrlEoBBaCxvy+TNFT6/BtsACcC3+P t2HwAWS4q9xI4OCeo075miw= =lnL6 -----END PGP SIGNATURE----- --=-aA24j1oaLOVBRE5DyfRm-- From developer@opengroupware.org Thu Dec 27 15:08:31 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 27 Dec 2007 16:08:31 +0100 Subject: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <1198766083.9325.25.camel@WM_ADAM1.morrison.iserv.net> References: <20071227070333.E64B3373B9@smtp.l00-bugdead-prods.de> <1198763420.9325.15.camel@WM_ADAM1.morrison.iserv.net> <0662FC9A-63BA-495C-A1E5-14619F7A970B@opengroupware.org> <1198766083.9325.25.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <7E747C8B-EA4A-4945-AC23-2125993FD864@opengroupware.org> On 27.12.2007, at 15:34, Adam Tauno Williams wrote: > I host a number of Java applications, but they are all straight-up > normal in-the-JVM apps. I've had horrible experiences trying to host > multiple apps in the same Tomcat instance, for example, which I though > was the whole bleedin point of an application container - deploy and > go. > (that and figuring out what is going on inside Tomcat's little mind is > no fun either) Yes, that can be a pain. I would expect JOPE apps to be run in an own Jetty instance. Writing apps which can be *properly* hosted in a JVM container is quite an additional amount of work. By properly I mean, apps which can be unloaded, refreshed etc. > I've never encountered GCJ and didn't realize it produced "real" > binaries. Are they "real" in the sense that they can be copied to a > machine without a JVM and run or are they "real" like Mono AOT > libraries > (which run like binaries but still need the original assembly)? They are plain binaries, on Linux GCJ produces an ELF binary just like cc1obj. Of course you need the runtime (libgcj.so), similiar to libobjc.so. (it also contains an interpreter for dynamically loaded .class files) The gotcha was that GCJ did not support Java 1.5 (which we use in JOPE), but AFAIK that has been resolved (do they use the Eclipse compiler or something? don't remember and haven't looked again). Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri Dec 28 19:21:24 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 28 Dec 2007 14:21:24 -0500 Subject: [OGo-Developer] JOPE & Java 1.6.0? Message-ID: <1198869684.5931.47.camel@WM_ADAM1.morrison.iserv.net> --=-FtwsNsRDJFDWcZdCDzKC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Does JOPE build under Java 1.6.0 or does it require 1.5.x? $ java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) and making JOPE dies with - Making all for java_package foundation... Compiling file NSClassLookupContext.java ... ../../../../org/opengroupware/jope/foundation/UString.java:42: package org.apache.commons.codec.binary does not exist import org.apache.commons.codec.binary.Base64; ^ ../../../../org/opengroupware/jope/foundation/UString.java:557: warning: sun.misc.BASE64Decoder is Sun proprietary API and may be removed in a future release return new sun.misc.BASE64Decoder().decodeBuffer(_src); ^ Note: ../../../../org/opengroupware/jope/foundation/NSJavaRuntime.java uses unchecked or unsafe operations. --=-FtwsNsRDJFDWcZdCDzKC 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) iD8DBQBHdUy0LRePpNle04MRAtbXAJ9j5l9idiBMZor1kOhBaWZrBhWo2QCePEBv WJGCbUHuW0UpH9hDRkO00tA= =tjSo -----END PGP SIGNATURE----- --=-FtwsNsRDJFDWcZdCDzKC-- From developer@opengroupware.org Fri Dec 28 19:22:42 2007 From: developer@opengroupware.org (Helge Hess) Date: Fri, 28 Dec 2007 20:22:42 +0100 Subject: [OGo-Developer] JOPE & Java 1.6.0? In-Reply-To: <1198869684.5931.47.camel@WM_ADAM1.morrison.iserv.net> References: <1198869684.5931.47.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <734C197E-3FA6-4EB2-B716-184FB718C352@opengroupware.org> On 28.12.2007, at 20:21, Adam Tauno Williams wrote: > Does JOPE build under Java 1.6.0 or does it require 1.5.x? Didn't try, but should work just fine. > Compiling file NSClassLookupContext.java ... > ../../../../org/opengroupware/jope/foundation/UString.java:42: package > org.apache.commons.codec.binary does not exist > import org.apache.commons.codec.binary.Base64; > ^ Welcome to CLASSPATH hell ;-) You need to include the JARs contained in the ThirdParty directory to the CLASSPATH. How do you compile, using 'ant'? Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri Dec 28 19:56:50 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 28 Dec 2007 14:56:50 -0500 Subject: [OGo-Developer] JOPE & Java 1.6.0? In-Reply-To: <734C197E-3FA6-4EB2-B716-184FB718C352@opengroupware.org> References: <1198869684.5931.47.camel@WM_ADAM1.morrison.iserv.net> <734C197E-3FA6-4EB2-B716-184FB718C352@opengroupware.org> Message-ID: <1198871810.5931.52.camel@WM_ADAM1.morrison.iserv.net> --=-8Nw/f9u4i3ccUsORkiZN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > Does JOPE build under Java 1.6.0 or does it require 1.5.x? > Didn't try, but should work just fine. Ah, it is working now. > > Compiling file NSClassLookupContext.java ... > > ../../../../org/opengroupware/jope/foundation/UString.java:42: package > > org.apache.commons.codec.binary does not exist > > import org.apache.commons.codec.binary.Base64; > Welcome to CLASSPATH hell ;-) You need to include the JARs contained =20 > in the ThirdParty directory to the CLASSPATH. > How do you compile, using 'ant'? No, I'm an idiot, I typed "make". With "ant" it builds, although it still complains. ---------------- compile.jetty: [javac] Compiling 1 source file to /home/awilliam/Documents/Works/OpenGroupware/jope/Core/ant-obj/jetty [javac] /home/awilliam/Documents/Works/OpenGroupware/jope/Core/org/opengrou= pware/jope/foundation/UString.java:556: warning: sun.misc.BASE64Decoder is = Sun proprietary API and may be removed in a future release [javac] return new sun.misc.BASE64Decoder().decodeBuffer(_src); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 warning ------------ But I have bin/ant-obj/lib/jettyrunner-1.3.8.jar & bin/ant-obj/lib/jope-1.3.8.jar --=-8Nw/f9u4i3ccUsORkiZN 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) iD8DBQBHdVUCLRePpNle04MRAiJmAKCAKK8TRLX64pxnISyQzLnZA8P5dwCeOg3E 1vWJHGOCDH5OaKLEhea4Z6A= =pFrN -----END PGP SIGNATURE----- --=-8Nw/f9u4i3ccUsORkiZN-- From developer@opengroupware.org Fri Dec 28 20:19:56 2007 From: developer@opengroupware.org (Helge Hess) Date: Fri, 28 Dec 2007 21:19:56 +0100 Subject: [OGo-Developer] JOPE & Java 1.6.0? In-Reply-To: <1198871810.5931.52.camel@WM_ADAM1.morrison.iserv.net> References: <1198869684.5931.47.camel@WM_ADAM1.morrison.iserv.net> <734C197E-3FA6-4EB2-B716-184FB718C352@opengroupware.org> <1198871810.5931.52.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <996F3F6F-FAC9-4566-9D49-885E5E303D02@opengroupware.org> On 28.12.2007, at 20:56, Adam Tauno Williams wrote: >>> > No, I'm an idiot, I typed "make". Not so. Actually I once started an attempt to use gnustep-make to compile JOPE. Especially in combination with GCJ this might be a good option, don't know. > With "ant" it builds, although it still complains. You can ignore that. We'll replace it when Sun removes it ;-) The API is wrapped in our own API ... > But I have bin/ant-obj/lib/jettyrunner-1.3.8.jar & > bin/ant-obj/lib/jope-1.3.8.jar Great, then you are ready to go ;-) org/opengroupware/jope/samples Contains a few sample applications you can try. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sat Dec 29 06:58:52 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sat, 29 Dec 2007 07:58:52 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071229065853.66DBB37C5E@smtp.l00-bugdead-prods.de> Hi, > > > > That would be the FHS standard. Its probably easiest to look at the > > current layout ... But actually its rather simple: > > > > ROOT/ > > sbin/ > > ogo-webui-x.y > > ogo-zidestore-x.y > > ... > > bin/ > > ogo-account-add-x.y > > ... > > lib/ > > libOGoABC.x.y.z > > sope-x.y/ > > zidestore-x.y/ > > opengroupware-x.y/ > > commands/ > > ... > > datasources/ > > ... > > webui/ > > PersonsUI.lso > > ... > > share/ > > sope-x.y/ > > zidestore-x.y/ > > opengroupware-x.y/ > > templates/ > > ... > OK, I see, and I think that should work very well with gnustep-make 2.0.X. > I updated the GNUmakefiles of sope and ogo installation to use gnustep-make 2. Well, where files end up, is defined when installing gnustep-make, and deciding for a filesystem layout, fitting to the OS you are installing on. I only was wrong when I stated that the service binaries ended up in a sbin directory, they still end up in bin :( But as there are existing GNUSTEP_*_ADMIN_TOOLS=/sbin environment variables, I think there must be a way to get the service binaries installed into such directories, only need to figure out how ;) cheers Sebastian From developer@opengroupware.org Sat Dec 29 14:12:54 2007 From: developer@opengroupware.org (Helge Hess) Date: Sat, 29 Dec 2007 15:12:54 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071229065853.66DBB37C5E@smtp.l00-bugdead-prods.de> References: <20071229065853.66DBB37C5E@smtp.l00-bugdead-prods.de> Message-ID: On 29.12.2007, at 07:58, Sebastian Reitenbach wrote: > I updated the GNUmakefiles of sope and ogo installation to use > gnustep-make > 2. Well, where files end up, is defined when installing gnustep- > make, and > deciding for a filesystem layout, fitting to the OS you are > installing on. > I only was wrong when I stated that the service binaries ended up in > a sbin > directory, they still end up in bin :( > But as there are existing GNUSTEP_*_ADMIN_TOOLS=/sbin environment > variables, > I think there must be a way to get the service binaries installed > into such > directories, only need to figure out how ;) And share/lib directories are properly versioned? Are binaries properly versioned? (ogo-webui-1.1 etc) I don't care that much about bin vs sbin, this can be easily hacked in a postinstall 'mv'. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sat Dec 29 21:22:39 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sat, 29 Dec 2007 22:22:39 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071229212240.6860837D0F@smtp.l00-bugdead-prods.de> ------=_=-_OpenGroupware_org_NGMime-25131-1198963359.791339-0------ content-type: text/plain; charset="us-ascii" content-transfer-encoding: 7bit content-length: 1894 Hi, developer@opengroupware.org wrote: > On 29.12.2007, at 07:58, Sebastian Reitenbach wrote: > > I updated the GNUmakefiles of sope and ogo installation to use > > gnustep-make > > 2. Well, where files end up, is defined when installing gnustep- > > make, and > > deciding for a filesystem layout, fitting to the OS you are > > installing on. > > I only was wrong when I stated that the service binaries ended up in > > a sbin > > directory, they still end up in bin :( > > But as there are existing GNUSTEP_*_ADMIN_TOOLS=/sbin environment > > variables, > > I think there must be a way to get the service binaries installed > > into such > > directories, only need to figure out how ;) > > > And share/lib directories are properly versioned? Are binaries > properly versioned? (ogo-webui-1.1 etc) appended are the patches to make sope gnustep-make 2 compatible. after applying the patches, you can remove all fhs.make files. find . -name fhs.make -exec rm {} \; also added some patches to configure, switched from bash to /bin/sh, make it able to work on OpenBSD, and make 2 compatible. The patches are done against sope-r1557. I left out the third party stuff, libFoundation. maybe I also missed sth. It works for me, files and directories are well versioned, and found in reasonable places: e.g. /usr/local/sbin/sope-4.7 /usr/local/lib/GNUstep/GDLAdaptors-4.7/ /usr/local/lib/libNGObjWeb.so.4.7 maybe there is still some FHS stuff that can get removed, but as I have seen, that it is also passed as -D define when compiling, I'm not sure about that. > > I don't care that much about bin vs sbin, this can be easily hacked in > a postinstall 'mv'. I also got that, working, after asking on the discuss-gnustep list. sometimes its so easy, you just need to know ;) patches for ogo are mostly done, just need some testing, they will come soon. cheers sebastian ------=_=-_OpenGroupware_org_NGMime-25131-1198963359.791339-0------ content-disposition: inline; filename="sope.patches.tar.gz" content-length: 12000 content-transfer-encoding: base64 content-type: application/x-compressed; name="sope.patches.tar.gz" H4sIAAAAAAAAA+09+3vaRrb9NfwVs8Tft/FigV4ImyxtCWDHWxu8xm7au9lLZZCxNkKikhw7 t5v//Z6Z0WP0QhiI3KY6yQdGmjnzPI85c+bMUnWnd5rzzZcEnpf5VrMJ3wTi3+RvgW9JzabQ aooCPBcESWh90/yitfLg3nFVG4q0Lctdle7hTtOMIipULCzp+DfIN+dYS42bWrY2GZ6MXVtT F87kZHi9UD9ot7qhTZb40Y2hPa0MXuB5RZazxl+A4cbjLyqiAjNFhOeiKLbg+8s0OQp/8vHf Gy018824v1extYX1UUOcMbU/LV10a9nIe1fhOA4FU6MRTI0GMzXq/tSoW7Y+f3Fs66ivTRFq IUFui3y7eYREnm9VarXa2qjiWFptnqdYvv8ecdLhQQvV4FMQEPzu9vunV6ejYfdscnb6ZtI/ vRyjWge9ryDNnOm3FVRB+q32K3q19+pWN2eOa+vmHE0U+QDtvYLSx1eDi8lV9/JkcDXpXVzv 7x/gl/uVWkouqL9548xSco7GOKP3HjKPf4a3536NcIW4s8a9YzcMa6oaDUO/CR7oN5WaZjha BeVnUmQmmyJDRtrGdfOzhXr989wTsYRngRT+ry6XjmZ/1OzJ2Bodj7cXAHn8X2yF/F9qyoT/ y1hf+EJtjkDJ/z3+HzD5YPwbZPzX5vL8YZLLr4MrjuaoLUshmz9UMJsnn/Az4OUv0dJQXRBS C+Qstal+q0+Ro7kusGcH3nP6rZnFtqU8vi0Rrp+ZP5/tQ+28bkUzS3OQabnI1n69120NAcsl AhaLo2QRM9V+0M3MEuhrUoBqzpCp6e6dZtNCztXpaPzTd6her5OOO5IPFFQjn/ATj8bkajQi 0pFIRk/QB/LR71ouW+Ct2XNbdNzeq/HoYtCfDLvng/14ffWpZX4s5dVOYSX/H56Mbv7zTrvZ UgTk8X+Zl+L8XxIEpeT/BcBK/u+P/9oiQODb4mGmCFiJLo5JaAvNUAoAG2sRZkakwNjq4TXq m+th/2wQMIj3pVxYRy4AZWHBQL/gwYM1m5z1j8+6J5TN3trqQnuw7A/o2Lo3Z6qrW2YFVy/g BtDhl93L08F40h9cDIb9yfXFaEhZdJhl8Oj+TmQKbmApSTJgJf931MXS0JyJ3lONC8t2VWMj SZDD/3lF4eP8vymBTCj5/5eHlfzfG/9GOP7rSwKh3WxlSoI1EccNQHJbZgxALSwSWgdHMetP hNRBJrzgjMGoZ5mubRkv6O+fFsblcgp8oD86h8+x+gicreeZT7Zk8Vk18dXtWkzdfqK1Ztfj n0L/xkxdBqTPDMvGZeTRf1NsUfqXWy1FkDD986Jcrv+LgIT9997RYNwddHvn1PHIw0QFEtCc kD/g+RFQMEu2hA2MVZeS7CESxLZw2JbibCArfyyrCLkZO4BwdCCD1nJ0IGF6xzimdx+WD7PJ 6M0/epPj07PB+AXqMC/qiwridHNq3M80lMZdQNPy3oZEfd79YUBw7TdcyzJID2ShsWDmEDxc 8N7vtD+OTpFF/8OTM/y1C/LP3/+RRG//jxdarRbe/2sprZL+i4AM+o+S/6eK86DD/ECuhU6H 46vu2VkXy7gJyM/u6TDGGujUSXKGq3uNkreMQDvgYanIp3GGZPaAMYhHCBiKKLUlMWQMZGVI F4Y5FD21FgvL9GjaT1lv/KjZDlnjVDg/U7SRIJU7DMazUQ+E++VodAUrk/QcpFsgE5XtdO/J Vyr85ZWzf/BJc0BjoMupn4nNC3MwvNLCXUBap7Qw24NPwvbo/s7KRgb4vXZ6esZXzMJK2AJS +P9CX2gF639KqP8pCtX/lHL9VwSsyf8DDo8nxzbKX1b+pPInHYY8XlQwF4RPwgX1Beh4sKDT HDem/TFvSvVvLcii/50ofh7k6X8CH+h/QPjYT0xQmvj9DtqXCyX971D/I9Sdr/jJQhpXWKHx KW1J/so1vnPoAto6kTRPpNb5J+l6KxOr87mtzVVX21YxRN4+izr9oM7/SLyuhCSk8P/5zBAm FzADYL6M/3m2vSjI1f+kUP9rCU2i/zXL/d9C4Kn6H54cjXBybKICrkAR1wKbbUlgDP481gLh k2iBgCamAQIr9R5i5W8lM7y5N2eGzwlf7koR/APqgVH6B935Vp/f29vrfCyspn+hKQpS6P/P E/ufTPzAd1qLDCjpP0r/N6pzpzuLiu+oACoUzA39Rjd09xNyHzT1g1OZWcR34U61Z1MLJjye 7AdA3QvNBTXGQbrroKlqGNoMzQkh3OqPoOaYHxCmTnR7b06JWwFmK8GcS1UWxUDzw/wjSMsq iCKPGQXPeIsIZKsAPkBB5F7+pXGjmw3crkrN+wF/Yh0GqzFDy9Xa6N2dZiJ1NsN7fYTtWUtc QQdrvC70B3Kmtr50D4AdOlA8PIPy3TsN2nxvT+HL1Q2Dlt3E6hv5xPuSlyeTN4N/Xp8Orjp8 hfwcjnqXg+7VwP99cQmc5qdOtUp/Hl+CUvhudPkD1kLxUw4/PRljjtSp7iUYVLVSYxL8Mjdh QmtLj5IRx31UbV0F7tRJ5PyFFtg7PvFwX7zrN2g+wr28Cr07vXo78TL7dSbP+oM31ycdgTrj 8weCiGrwJYq43Sc4NUY7GV/2SEP2fsOefd7Pzw2/nl5Bp8OrwSXeM8V50tLX546X9Ho8GE8i 6TumBcNZe4lmmqtNXcydvRlpatoM5iCMlaGpMPEsE/0NH2iokTHmPiLx28ZM+9gw7w0D/ReB QFqS3MxTJgXeGkb/QnvfIQ40ex79+zXMALNSQ4jUgkx06sLvP6KTv3arV2rwZnpngXj1p1gb 7eE08AZm4dWoP2rjCYiW8wkdgwO0+OT8ani/kOZO/4JXDsMfJrDGgBUEPuHQqUb2ipdzyBDZ MU7ZQq5S9f1vKQC1A40+9RVeK/lkS5O92ke/VWrhnwgBybvo73+fdHuD0XEFvf8lINe/hpTr IBV3cTD4mOHAEFE6cm1NIydPdBPYsmEQT6I6lE1M4cQTuOV5AvulZLbFvjdN3Ne5rVnauule qLbq0CbFfkO7yMhVe14TSKXaVfwC5gNhaHsMnSNQQ4TXmDmYXkaEHoA7oBsN/Xqvw/qr+hoh mBLx/D5jSMtvmX910dTWYPmGsNbhAA5AQVzjiB8EyE/aL1nNCpoBFf8caf+Dapsj8/jt+MIG jeaRdkLaw9gIv+teDivoHSSEbm6jT9Y9UoE1+iON+x4PpQqiwgQGqZozEBcIUMKPT4YGFcSY 6xitB/RJm3YH5YueyxpZ8gui7HuBf9Rty1yAbgrZ2dpEW+Zo7v3y1HQ121QN4JAw3Wjrsl4w Q8Ldor3f4mzpc+NMv7FV+1Pj3FP/iBETT+a6c0cHjbYnwrTXwlMNM56OJ9BNHmsV5CMqUY5i A7yiERg47kF37ziDFgQCYXFjEbY6uLq+mPRG529GnwkvQP7U4ExUrdd92kP1Oggf/JKQqf/0 22/3foNxAnY80+3PDR/f2egEWzM+Y9aHKGdbOwupwc67rUXnzKG8frdhoozOoI+qoc+A6LxB 7tpzj0lkvQAsL33+huiqIZxT1ce9sIFVoPPqY5WdNOzcezs6HzRGJ9Yl6KXrzDpiJucl3GbQ p2NtXlHbZJtJB3WXS0MLm5vyzOt0ogqMry5PiXIQaetvSVH9mbTatKpxWoloGXQERYGc8BPF w7QRTFTmZfboJYctOl7+U48BoVdT696YYYZ9o7kwUb7bp7zP0fwhpMypClOcNqH6GMrb6n/Z X43qPm1Ni47NYdbYrB4Uws294Rvj9jOyKvE44PX+RGQYJhVcvmBxPsH7BXDc33z10HNHw8bO z5GkpDVtxCQNzaKQkrTxsIlPY9bEo6Z3KjOn/tlCaXo7f7BBWNJmRn4FmfaEKvAWKi08LTaO Zq6ZVGyHvD/5iMyBB2Bxc9Miuj3WQQzDesAiDPRnUFkMx0LeUhndfELzQH1p09wIXXSv3vp/ 938+6098Iy95QXRkQpY1SYzPgPQa+W1G1Rffk/ae4QEIeAujqCNYn6iA6qNWjeUkvzET9zVM 586f2aRJNBlRyNKt4A3kOdl7b/DD7zCP3wghMZJ/V/G4fQpnjCx+qugvLIckXaiQ1ZXUSsyv jFGlENkGQCjsH+pX/j55JPh9aAp6OxpHTgRXoyh6o+Hx6cn15QDevTm9anc+gXKGe2h1KYFD abykqD9pDFPvZDyhqj/ZO2h3iD4fSYLXH/EqpuRS5Hg+vB0Qy7gmrnguiome0ebJeB3FhXDq cIUoMM20O0zXMFxpv3FlWYbThrc42X6Sddxp0w9nuvkB+tljH/EnZG74mpGpLjTUAT4iHCD3 05L+LeI0hOUhy5gtH2YdvDwOH7qLJSgznWo9WNhweCJze3t+yw8PhENUk3nxQFQibU+rzeID YEN7FCvpi1nk1xK0scZCBR6qmao51Rqz+8XiEzFNTlEdry4RUbZhaEAmQVNezyyqimH/Y9Cl iBsyZ+z9Bn98JkM/s0zNJ0MoCRNHp8oYNonyRxgP+nbPSwBz2d9Eq0dNBbWUtFxWYp+Df5uC +H3eRl569h5xtiYbaiG0O8TohAcmPZf/duJbkCEH07NhF6RmCv27qYM3yKOgHyJN25L+162B P8jkdEt6TkrRT8WZgSvgGIlXSZ92aGbIKaOv99fCQQBX6LeYDeTzRvMpsOoHIpKahBy00Bxs 03AwIyeauI/S7yH0rXXv1g1rjsRvNdvGf+H+oWueTREQSoV2XQ7G12dXnb3v4hJyj3kNOjTP SEVZ5CmvkUXP/LaS19gLxNm3IXtJ4Z59DebfTDOnuuYwLDTxOMK0Y2IgYLBoxmSjiZhagYRf GGLVJ1lqd1WN18l02Ds0JR0XT+c4RpDMP143ex1oLIx5VzXwwBGj3i/3WAz8glcnnuW7ytj3 UopA5DiHVV2rCN8ouG1VqdUoimP5a4hiVfc5vxowLlI1Lx2xOk4NHdYKVTZddJrY9+apS6dG +CfKsIj9JbBo0dVSaJp67a12yDRuHpHVg3yY0O6YIjLtfb7FPtfepz26NqjLx/D7R9W495YF qU+hcj92z64Hneov4ZLjvwgbLKtO41//2/n33zqNxrz6S0IJWdrWFPjAiFTKX6vFHzGLSoFd S3LcnWYs8TqSu4PlI3pBrKyvSS816aq4KXsqFRXjQGyWOkMp671K2uIfZ7jVbRgnWPaQnHjR E9oUIgg4b49jr0+MF75G9rZSqyefrTMBEmtBmAUwB557K+xPCVn+H+N/nmFuUYj/r9zkQ/8P USLnP1qSUO7/FgAb+X94k2Nj54+U/EnPj6YSbuhGT0H4p8Exn/Fd6tZ14VjT6+0P6MmxGWTR //mnnbh+Ecilf3gX0L8kEvov4z8VAxvRP5kcG1N/Inec9pU2f1jSfjGQRf8n/bPuFKurO+AB +fE/vfg/zaYiEf8vkRfFkv6LgI3oP5gcq3kAMAApiNgQ5QGpGCKZj9o8jgUX8oHmwSEse6Je 8cSwyNj2WYtj4OTPPdnxP22Hq8I90aU/aKIXV4Lu5UvENU0WPG62wUnOP7Gzagk7h+z4z4NH VzMxtWwtAvLXf4z+1yTxnwWxPP9VCDyV/3thm8PJsYkauBJJXBuU2zIjBQSFclD4Kk/E7wCe FP99wzLy13/M+Z8m1f9kpdT/ioAN6T8tbPvTiD8FQ9IGxLMBgASRUD58lZS/M8ii/2LjPwgh /SsyXf81y/N/RcBG9L9F/Ies/Empz8b4kUj8B8mL/2DOp6rBnvvzoUNflaEf1ocs+g9CJhYi /xn9vyV68r/c/ykCNqL/YHJszAFSMSR5gMie/iUBAFtHpfTfJayif1vrq6765c//R/T/Fo3/ 1Cz3fwuBjemfTo6tGEASRZIDCGzAX7L0b5Ur/x1ClP4fF4a9nE7w0e0dRoDK1f/9+3+ahBuQ /V9BKOm/CHgC/TOT44lkn5EzTu1Su8no/AI919qiOz7szGQ0fxri+9mUfVRBC3VqOY/c8sMc tdsV9OIl8oIj3NzrxgypCL/5z71Db9QjsQRwkb8XlpIi/6Gr8VGd3TGAXPkv8SH9k/g/Qotv lvb/IuCp8h8mRwMmxyZyPyVrnAMIkQD/Ai8Tix98lRL/C0GW/l9g/Ed8OzCN/yNLsqDwNP6j IJf0XwCk3P9B9PNM+sYRGaU2LwU+WlG9PiuII8kSMekRaz75DO/1C6MKxiUrAsFf4V7ETsHh ojhIBGmw13pQjUotJyU+O9j7oXsyoDfN/WnIPQEZ8t/Qb+Br3P2pb+v4JqCt2EGe/5cUxP8X YPlP4v8Jcqu0/xcBIf3Tk+Qu8iIz0cNHYp0PIoCBoFxfR4hNoNX6Qov4ekkp+sIKNNkYmMuB WhFvMcb/yz/Xzp4YJW5bbHFBqsFPV4Ph+HQ0JKnqjvpY4ZIH4yMxY+N+ZftBEI+x+kjRO9ze q/PuP0aXkx8Hlxj7fh0enA6ZB41KLaccz/Fs/4loUSXe2MlF7y1ZVQF6z6nuzou8JBI9TPTU sHg+4iR3+j+DPj6dOLq+7A38cIzbrcwiMRpLDe7LQAb/792p5lw7s+bBrNpCBOTe/ylKYfxv hez/iILQKvl/AfDk+N8+oVK2NI5y/eS0yY0GLrSFeDTwfEzJ+OB5vD8/PHiGSEhW5I8gFbzR 2UAqpFA+G2H3BblCL5movsBvaBAqIiy8KL0p6OJSAlFGDxz81qovDd1xUSk4ioIM/u9diVjI /V+87Mf/xvY/seWd/yzvfykCNrH/eZNjUxtgSvbkToDI+PwqxFSglH5/XwAy6H+X7n/5+39C M6R/icb/F8r7fwuBTeh/C/e/jOwp9M94/ohk31/09v3xyc9fl3H3v473vPT9expk0D+9Ibmo 89+SHNK/TM9/K3IZ/78I2IT+6eTYlPyTuZPUz3r9yMTvTy79/r4IZOn/Vz/twvJDIdf+LzY9 +4+IfxH535JL+V8EhPQ/JSt1bOJh72bAOwBPWRow82Ydm7+ctj7IwJHMLrS2NfizZRVg1yFX WiSsMPTpTiw8TygAuiRC5eua/yOZYracWgclj92XFpzfMWTw/+Wnxx1t/n6zxvpPZvw/m4T/ 4xwl/y8ANtH/2MmxqRaYhSPFI4yJBSRQhzCPE0UmaeQaOPbNtivCr5sXpdC/ulw6mo37dGyN jsdf/PyHoDD3vykiT/Q/hS/3/4qAp9J/MDkaZHKssb3nW3ID8l+BIu4yprRldl+PBP9veVer 0ZVgil4HWh3Gm6LOYWXucbmNMmdd2Nbsfuru2HXjSWix4kYIM3EC1mu5hwwzPpowpqXhhEsv Dd1v85U2cp+UcKCgGnySXsaqY590bocMXm79KiiMxI4bGyLYxzWPPIgybYwf6lyLJsnqvG4f yiXBysf79Eri1UyeOhTTEAK89Pzhl34nkmIl/x+e7MQOmG//Z/b/6Pl/QSrt/4XA5vzfnxyb aICrsSR1QJ5d6BMaboklCe8CVtL/u8FOgoDl6X9iYP/Ddn+B+H+JzZL+i4DN6Z+dHHlxIAW+ LWbzgCxM2UhoPCByPtDTUyLxFz1XXhZvhqYYTZKmMD5Y21j/3o0eB4a2eIPPAu7a4XcD3MiL RYnCi7Y8RS3SEVRXUqiupJQbL18x5PB/WEq4Fr4UaxsVMJ//S8H+j9Rqev6/Zfy3ImAb/h9M jm3ZfyqiHO7P01uPV3H/AG0m82dSfP28P5PzM71AWTYJt0ycbpplsI2vG1bz/1Ex+j+N/0v5 Pzn/i/X/0v5bBGzB/0dP0//jx4XzMWUjIXZKLAC8O9HXDcwenPJji0yXDWkJvmLhkC0eRrGF QeuQ2F8OS8HwNUAO///pfAeXAK0d/62JhQGN/9os478WAtvwf5gc2xl/EyjiuY8iISNkwnnk kvPsEFLoX8fRdYuN/8zQvyTQ+M9C6f9dBDyV/vHk2OYASFb+JOWLfJbfj659VA3bvje02BZ4 h3lVHgRZC7LoH/uT6u5ufMBz/b+p/x/1/5ao/1+rjP9YCGxE/7HJsc4tYHFH7zw82Sh2fsI/ Vos/wvH+zYO+xOn64vJ02Du96J5NemfdMXbD+XHMdEWK/3ccQ/5x/tL/8vcLWfx/eKL31B0F Ac5f/4XxPwW55Z3/K/d/ioCN+D+dHBurf8nsyZxN1utboHd+CeVmxM4h5/z/Bebf22qBefTf ov5/NP6fTPZ/JaGM/18IrBP1L/Xwf3RmrBPmSVwRCyAbW8QlXGlLmDuwl8K28KWwu1EEo5XY Rg+8Hg8uybWxoQL4hqgxztrn+nAtY9QX8ZbGYZii72HF+/Txz4r/S/trgvtr6zmWR/8K79t/ ZEWh8X8URSn3/4qArPi/DL2knd2VWu1mPGxbPF88y2HkWL+Cr3NWotc551NumHL8w8+UwLa4 5zlcTwX3PO/je567/f4pTodXRRcXx2fdE3K0lVvqSw1x71TDgE/T4pbYcWJqGZXgWnpbw/qS agZ302ehwsEyB8Ory+7wqiM8o5axcv9nR0wg1/7b5EP6x3YfEv+r1P+LgBT6D/dncpiALCTt OqmZk/mabIAPzAnkTTnBdje9744DRPKcDntn1/0BLsW7o+S5xzkLUuh/PjOEyQUsiua2Nv5n ZP934ttsnlRGnv2X55XA/ivwNP6rVOr/hUAK/ePxb4Tj30iz2SXvBABe0Gzz8bOe6+DKRkOM j8TWK7bC44iESjtA9/V6KHiTjj8penYbU3zo4cK82m+c9M+606nmOPUAVeNSc6x7e4p3quDt TF26lu34npSb24IZZDs1Bj8Rr28UgX/PPQtLeC7I4v9ArLqrSdsz/2/W4f98eP5LIfv/QlMp 738pArL4vzf+2zP/VYhKzv/snD+L/o9ty3TfqI4mfvn4H6IU7v+LOO4/vv+5jP9cCGTRfzj+ q6+CWkH56ShW07zE48UgfJLVYK87nPRG5xew/Jscv6FGz5Dwo2994t9svcfagzsorDkujyGF mAWWWKDJMVTZc0Rn0iZ31sOXHrFGcMeDdHTQaRgQPxnHzmudZ7pmapzHncY/w9d5xDqtAwPw +ccTmM7wGm8ZhDkRvsDr2oHlN4y/Sp8i1UHuneY5BSDN9yVP96kP85UqaTGw0v63sGYTc27d /OdBu/mS9780Q/4vyRJd/5fx3wqBlfY/dvy3O+OZhWn1Ic+WhKUBfBJp0L24nPSoKc7fsdt7 5dxphgHf8HIfcdx0ubw11DmxvEPysz6TPiW5MSOp8V/6Dc7kK0brCZEUVopP9gT6YnepAnFh +dLrIQY6aD6dVtBZP+Xh+G33ctDHXBY4I9lvtLwDr60DgcdHXpv4Gx7NQDBMDU018fWI5A8a B0klpXIz3UbtCvcC1L8fsB1yf5WGWqmlpmOOFMUbhQWxCbQD3YlvZwzLpBc17r3y5cfF5egE FG+M1gs6lV+T9fKuVTvu3rHx6GqPMMu8eyRRThENyNPw8jTuXHc5a3yt8ign/tPo5j/vgPcP T95CL2wqAvLjfyqx/R9RbPLl/k8RsJL/++PfoOOfF9BZFttSdrC/FcjieKTAWYSsCciSgMgA dosHWwHw/6ll3urzxP5wrg/IRuuE8fUbYBj/GPSu/LUCbQ1mOB6RpMVRfu5Rzob16P/B8px6 584Gu8E59C/KUsvX/0S+6e3/yKX/RxGQ8P+E3kCOe397u5IhMBOC2R5O+HzJcZ+vNVBFDASt tii2eWaz+JB4fB16Ll/vRpfjy97Z6fCH64u2bxgMjFu+oeDdKLmk3T8Aek57sZYlT8eOXLm5 3w3eTLoXF+NQr3yJrmAtbKoLDVm37LpYd4B1kQesJeIjlKRig6ufk9gCIKehmvN7da45MRyG NVUN/f+0Gcam2hr+enx8nJx1hyfX3ZPBmBpWD1uYpeIvqkkyXQRtoIE3GRMojNKYDFobNKfv GT3xe6pnuZptqgYXDKSneU1A28rofOTcQe1mNKU51bg7TSVH1b2soEDaC8TZt1kIGmlVfo3e E83zqgslTO9uEQeKvfZIJEKn9+OY+VV3Pprw07U4x51Z925qF6D/olfTWVYVXiOvpEcoCNTW l5tWGXI+V539tYd+i/6FOO1JVUf/fo1nn4k2avatTpruV2C6RNzZZXqLMhBXwqgPvbejdzgW LCZqrNuT37C+wwiDd0+qoE+xz82evzisK//h4WbC/5t8+c83m6H8p/e/CUoZ/7EQ2Fj+0wmx vfBn8MQlv9BuSmzEL4mG/JK8+N++SO1rIIAWuqkRYQj4DH2qurploplua1PXsj+xdud3I5DJ EbMzVIJdD5AE4xw9ABJBayq1FZkY8V9B9Yu3o+HPbVZa4pZjMYl3NQJGHH3tS1Jvr0FqiWQt BF9HvtzGjQmFdiCqA+ndjsloFm2bCPRXWKJ7LYwbgGizPMkaMPrY20aiHttK4giyQKQlKsUK M2w4CsVYbg2T0muNRnlCaxt5vWHLGPkYxZDIu4FYzG35n0Ya/vlgPfn/ReO/i7LAh/JfoPHf RZkv5X8BsE38d0+Gb7UxlIZl9aYQ4y4e8QJP9w7f1hF8/chyJK6c3xzPU8iLXSKIoLdg0R2q LdQ+kYWb800Xx2/HwWKF1AmbLXxPgXGi8sGb/aBjKxz1WUpmSuBukFV5Y717Phr+dl6lll2f QAVqMB1DOoAL+oHptfQ76NgE45FXfif/IhLS+QpxIhMUL0x4gCjlSpS9V2xJYVdmXjLTs+yM wLG/p1tmwjHY4JoZ3MRwVIKdynBwvCTxq2j87gmvoiGjcUQieAlH/lXua9zHEAn/UEbs2TU8 Wf5Pgm5cu4w8/49myz//1RSbPJH/kiSW6/8iYL39v1QyShP2YnOtLcBUfHFUSltmvYFBjEok Co0gRZb/vheCj5D4oam3sODlQgeFmB8EK/Z8I2AKR+nOZjo2JKhGI+LS0O9edfeRLwCpnrQJ 0giGmAtGfzC+Wq9mtdyarY0rWiFWRWHzBULiQKhLdX4/pbtRok4RSw8WEdhC8GLtXiPZ/X56 kdckJnVaTaIbTk+uCSuS1qpMRIb9vpbSGfE/dnn8P//8vyB66z9Y+OG4j7ygNMv4b4VAyP+d Bx2mAL7/O6qZjs67p8NoDJDMc8HYcEuEAN9MCfaRdiLYyyFHQnsrWGdXnhrVo4DYALX0HKSL sM5L/AFjZ4HXPT/8POOfdf4jOBSzgxNgufSvBPqfIvEtev9Lef9fIZB1/iMY/zVOgFF9TW4l owGsgSqO5QgQMVqfRJxeRd8FeNURe3L84ELFthTQRhx0a9lo4HuGIsOyPtxjPy0u0GlSjSuZ ATviqTvvv39fTUHyvuobNzjmrMpoeHx6cn05mCjym9Or3OggsfQd4UvpDVn0P7LVqaEdFhH/ WeAD+S968d+FVqtZ+n8WAVn0741/blwvPojQHiX6lPwRmS+2m0eRy53pOaqmZ6eLnsfykJVn Pndy5tMn7dhhtueeiSU8B6wf/3UDw58HufEfxZD/8975/5ZQ6n9FQAr/zwrxutLwlxnjexWi 1UG+BXreydvpe0kiUuoG9exxNNfVzblD9bkV6tx59wI4aKe6Zozuc3W5xHgbVX/fLESw5X6Z oz4uWOyEHdeS9WNjezPVAcbtZ6dHu6iRLTQYUkz7T+TjK+3/O4n+vEb8Z9GL/yRLsqBIRP9r tkr//yJgpf1/5cl/Cfv4Sdm3umVpfpBPjJ75J5uC5JO16y/V6Qd1rtGJP7WcR275Ye6f4ONe 1OuNhYr92kzsQN7ARXGQCNLUnbtYXSq1nOR7ry66vR+6JwPP3+m5R6U4yFr/nX/aSeg3Arny vxXe/yjI5PyPIJX3/xQCWes/Mv7bR//JRlPG/nnudeCfiMuVUEIJJZRQQgkllFBCCSWUUEIJ JZRQQgkl/Png/wHROOVBAEABAA== ------=_=-_OpenGroupware_org_NGMime-25131-1198963359.791339-0-------- From developer@opengroupware.org Sat Dec 29 22:53:21 2007 From: developer@opengroupware.org (Helge Hess) Date: Sat, 29 Dec 2007 23:53:21 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071229212240.6860837D0F@smtp.l00-bugdead-prods.de> References: <20071229212240.6860837D0F@smtp.l00-bugdead-prods.de> Message-ID: <5F1BADCB-85A2-444A-8466-93D622B5048B@opengroupware.org> On 29.12.2007, at 22:22, Sebastian Reitenbach wrote: > appended are the patches to make sope gnustep-make 2 compatible. I'll start looking at them once the layout looks reasonable ;-) > It works for me, files and directories are well versioned, and found > in > reasonable places: e.g. > /usr/local/lib/GNUstep/GDLAdaptors-4.7/ Can you change such pathes? Eg currently this lives at: /usr/local/lib/sope-4.7/dbadaptors/ which I consider way less ugly. And actually I would be surprised if the layout you showed actually works with OGo? BTW: a major reason why an exact layout preservation reduces burden is that we don't need to change the packaging. > /usr/local/lib/libNGObjWeb.so.4.7 Sure, libs are properly versioned, but what about resources (share) and bundles (lib/sope-4.7, lib/opengroupware-1.1). > patches for ogo are mostly done Can you reproduce the current layout? If not, how does the layout look like with GS? Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sat Dec 29 23:19:51 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 30 Dec 2007 00:19:51 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071229231951.9DFA237D26@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 29.12.2007, at 22:22, Sebastian Reitenbach wrote: > > appended are the patches to make sope gnustep-make 2 compatible. > > I'll start looking at them once the layout looks reasonable ;-) > > > It works for me, files and directories are well versioned, and found > > in > > reasonable places: e.g. > > /usr/local/lib/GNUstep/GDLAdaptors-4.7/ > > Can you change such pathes? Eg currently this lives at: > > /usr/local/lib/sope-4.7/dbadaptors/ > > which I consider way less ugly. And actually I would be surprised if > the layout you showed actually works with OGo? Its installed in that location above, because I changed the following line in sope-gdl1/PostgreSQL/GNUmakefile.preamble -BUNDLE_INSTALL_DIR = $(GNUSTEP_INSTALLATION_DIR)/Library/GDLAdaptors-$(MAJOR_VERSION). $(MINOR_VERSION)/ +BUNDLE_INSTALL_DIR = $(GNUSTEP_LIBRARY)/GDLAdaptors-$(MAJOR_VERSION). $(MINOR_VERSION)/ but this cold be easily changed to : +BUNDLE_INSTALL_DIR = $(GNUSTEP_SYSTEM_LIBRARIES)/sope-$(MAJOR_VERSION). $(MINOR_VERSION)/dbadaptors > > BTW: a major reason why an exact layout preservation reduces burden is > that we don't need to change the packaging. > > > /usr/local/lib/libNGObjWeb.so.4.7 > > Sure, libs are properly versioned, but what about resources (share) > and bundles (lib/sope-4.7, lib/opengroupware-1.1). > > > patches for ogo are mostly done > > Can you reproduce the current layout? If not, how does the layout look > like with GS? I need to take a look on a suse box or sth. to try to clone that layout. my openbsd box is not good as a reference ;) cheers Sebastian > > Thanks, > Helge > -- > Helge Hess > http://www.helgehess.eu/ > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer > From developer@opengroupware.org Sat Dec 29 23:27:05 2007 From: developer@opengroupware.org (Helge Hess) Date: Sun, 30 Dec 2007 00:27:05 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071229231951.9DFA237D26@smtp.l00-bugdead-prods.de> References: <20071229231951.9DFA237D26@smtp.l00-bugdead-prods.de> Message-ID: On 30.12.2007, at 00:19, Sebastian Reitenbach wrote: >> Can you change such pathes? Eg currently this lives at: >> >> /usr/local/lib/sope-4.7/dbadaptors/ >> >> which I consider way less ugly. And actually I would be surprised if >> the layout you showed actually works with OGo? > Its installed in that location above, because I changed the > following line > in sope-gdl1/PostgreSQL/GNUmakefile.preamble > > -BUNDLE_INSTALL_DIR = > $(GNUSTEP_INSTALLATION_DIR)/Library/GDLAdaptors-$(MAJOR_VERSION). > $(MINOR_VERSION)/ > +BUNDLE_INSTALL_DIR = $(GNUSTEP_LIBRARY)/GDLAdaptors-$(MAJOR_VERSION). > $(MINOR_VERSION)/ > > but this cold be easily changed to : > +BUNDLE_INSTALL_DIR = $(GNUSTEP_SYSTEM_LIBRARIES)/sope-$ > (MAJOR_VERSION). > $(MINOR_VERSION)/dbadaptors Sounds just fine. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Sun Dec 30 10:32:56 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 30 Dec 2007 11:32:56 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071230103256.C187F37D0F@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > On 30.12.2007, at 00:19, Sebastian Reitenbach wrote: > >> Can you change such pathes? Eg currently this lives at: > >> > >> /usr/local/lib/sope-4.7/dbadaptors/ > >> > >> which I consider way less ugly. And actually I would be surprised if > >> the layout you showed actually works with OGo? > > Its installed in that location above, because I changed the > > following line > > in sope-gdl1/PostgreSQL/GNUmakefile.preamble > > > > -BUNDLE_INSTALL_DIR = > > $(GNUSTEP_INSTALLATION_DIR)/Library/GDLAdaptors-$(MAJOR_VERSION). > > $(MINOR_VERSION)/ > > +BUNDLE_INSTALL_DIR = $(GNUSTEP_LIBRARY)/GDLAdaptors-$(MAJOR_VERSION). > > $(MINOR_VERSION)/ > > > > but this cold be easily changed to : > > +BUNDLE_INSTALL_DIR = $(GNUSTEP_SYSTEM_LIBRARIES)/sope-$ > > (MAJOR_VERSION). > > $(MINOR_VERSION)/dbadaptors > > Sounds just fine. First I'll see how well OGo works, when I leave everything in the default GNUstep locations. I don't think its the best idea to remove the possibility to install in the default GNUstep locations, then I think it would be better to keep sth. like it is right know, via a configure switch/environment variable choose to use default GNUstep locations, or the one you named FHS. btw, I found some more or less recent gnustep rpm's for suse 10.3 here, so I'll be able to test the ogo installation easily on suse too. I only have to update my desktop to 10.3 later today. cheers, Sebastian From developer@opengroupware.org Sun Dec 30 10:48:17 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 30 Dec 2007 11:48:17 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071230104818.7D33837D2D@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > Hi, > > developer@opengroupware.org wrote: > > On 30.12.2007, at 00:19, Sebastian Reitenbach wrote: > > >> Can you change such pathes? Eg currently this lives at: > > >> > > >> /usr/local/lib/sope-4.7/dbadaptors/ > > >> > > >> which I consider way less ugly. And actually I would be surprised if > > >> the layout you showed actually works with OGo? > > > Its installed in that location above, because I changed the > > > following line > > > in sope-gdl1/PostgreSQL/GNUmakefile.preamble > > > > > > -BUNDLE_INSTALL_DIR = > > > $(GNUSTEP_INSTALLATION_DIR)/Library/GDLAdaptors-$(MAJOR_VERSION). > > > $(MINOR_VERSION)/ > > > +BUNDLE_INSTALL_DIR = $(GNUSTEP_LIBRARY)/GDLAdaptors-$(MAJOR_VERSION). > > > $(MINOR_VERSION)/ > > > > > > but this cold be easily changed to : > > > +BUNDLE_INSTALL_DIR = $(GNUSTEP_SYSTEM_LIBRARIES)/sope-$ > > > (MAJOR_VERSION). > > > $(MINOR_VERSION)/dbadaptors > > > > Sounds just fine. > First I'll see how well OGo works, when I leave everything in the default > GNUstep locations. I don't think its the best idea to remove the possibility > to install in the default GNUstep locations, then I think it would be better > to keep sth. like it is right know, via a configure switch/environment > variable choose to use default GNUstep locations, or the one you named FHS. > > btw, I found some more or less recent gnustep rpm's for suse 10.3 here, so > I'll be able to test the ogo installation easily on suse too. I only have to > update my desktop to 10.3 later today. there is the link, if someone is interested, or needs these for testing: http://www.cenon.info/frame_gb.html Sebastian From developer@opengroupware.org Sun Dec 30 18:37:53 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 30 Dec 2007 19:37:53 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071230183754.0932A37DD2@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > developer@opengroupware.org wrote: > > On 29.12.2007, at 22:22, Sebastian Reitenbach wrote: > > > appended are the patches to make sope gnustep-make 2 compatible. > > > > I'll start looking at them once the layout looks reasonable ;-) > > > > > It works for me, files and directories are well versioned, and found > > > in > > > reasonable places: e.g. > > > /usr/local/lib/GNUstep/GDLAdaptors-4.7/ > > > > Can you change such pathes? Eg currently this lives at: > > > > /usr/local/lib/sope-4.7/dbadaptors/ > > > > which I consider way less ugly. And actually I would be surprised if > > the layout you showed actually works with OGo? no, its not working this way, and when I took a look, I stumbled across this in sope/sope-appserver/NGObjWeb/WOCoreApplication.m + (NSString *)ngobjwebShareDirectorySubPath { return [NSString stringWithFormat:@"share/sope-%i.%i/ngobjweb/", [self sopeMajorVersion], [self sopeMinorVersion]]; } + (NGResourceLocator *)ngobjwebResourceLocator { return [NGResourceLocator resourceLocatorForGNUstepPath: @"Library/Libraries/Resources/NGObjWeb" fhsPath:[self ngobjwebShareDirectorySubPath]]; } when I see this, I think it's easier to get the hardcoded FHS stuff working first than the other way around. Sebastian From developer@opengroupware.org Sun Dec 30 19:12:45 2007 From: developer@opengroupware.org (Helge Hess) Date: Sun, 30 Dec 2007 20:12:45 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071230183754.0932A37DD2@smtp.l00-bugdead-prods.de> References: <20071230183754.0932A37DD2@smtp.l00-bugdead-prods.de> Message-ID: <1829EFDB-D9D7-4F11-9259-E9BA464A41C8@opengroupware.org> On 30.12.2007, at 19:37, Sebastian Reitenbach wrote: > I think it's easier to get the hardcoded FHS stuff working > first than the other way around. Not sure what you mean by "hardcoded FHS stuff"? Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Dec 31 01:43:38 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 31 Dec 2007 02:43:38 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071231014339.165BB37E36@smtp.l00-bugdead-prods.de> ------=_=-_OpenGroupware_org_NGMime-19204-1199065418.207579-0------ content-type: text/plain; charset="us-ascii" content-transfer-encoding: 7bit content-length: 1049 developer@opengroupware.org wrote: > On 30.12.2007, at 19:37, Sebastian Reitenbach wrote: > > I think it's easier to get the hardcoded FHS stuff working > > first than the other way around. > > > Not sure what you mean by "hardcoded FHS stuff"? I just mean the hardwired pathes in the objective-c sources. however, appended is a changed version of the sope patches. Now completely imitating the FHS environment as it is used by the suse rpm. I used a opensuse 10.3 as reference system, and the patches were tested on opensuse 10.3, compiled with the gnustep-make, -base and -gui rpms mentioned in the previous mail. Only for -devel packages, the Headers are going into the GNUstep Header dirs. As they are not needed for running sope/ogo I did not cared about them. For developing, a working gnustep environment is required too, I saw no point why they should not end up there. Further I don't have seen yet a variable or sth. that is intended to install the headers outside the GNUstep header directories. kind regards Sebastian > ------=_=-_OpenGroupware_org_NGMime-19204-1199065418.207579-0------ content-disposition: inline; filename="sope.patches.tar.gz" content-length: 14575 content-transfer-encoding: base64 content-type: application/x-compressed; name="sope.patches.tar.gz" H4sIAAAAAAAAA+09e1/bRrb9F3+KWZffr2GNsCW/iLNua7AhtIBdDE16N3tdYQujRpZcSQS4 3Xz3e86MHqOXJWwwJNW0sbE0c+Z5nnPmzFy2x9eK9c1TpkqlVmnW6/BNU/ib/i1WmtVGpSZJ YhWei2K10vym/qStctKNZcsmVGkahr0o3+21omjraNB605zNf5l+C5YxV4SxYSqj08OhbSry zBodnl7M5I/Klaopozk+utSUh9VRESuVRq2WNP8iTDfOv9SQYAVUJHguSVITvp+my8H0N5// zf5c0feG3c2CqcyMTwoRtLF5P7fJlWES511BEATiLY2ytzTK3NLYcZfGjmGq040DUyVdZUxI k4i1llRp1V8TqVJpFkqlUmZQYSjNVqXCoPz4IxGqu9tNUoJPUSTwu9PtHp0f9U87x6Pjo71R 9+hsSEpt8qFAFH2iXhVIgahXyp/k1earK1WfWLap6lMyatS2yeYrqH143huMzjtnh73z0f7g YmtrG19uFUoxpaD9+qU1iSnZH2JB5z0UHv4Gb0/cFmGDhOPyjWWWNWMsa2VNvfQeqJeFkqJZ SoGkF2rUuGKNGhRkfcxanq/UGZ/nXoh5epYUQ//l+dxSzE+KORoa/YPh6gwgjf43gNa7/F+U mpT+1+rNnP6vIfn03yPy3vyX6fwvoPInhk7pc1UkFaklSa1KI0Tls8BKBoNkvtnYFoHOw9fr xWR+A0g08BR5fE0mqrm9+aoLZBnfb20LBz6h3rs4Ou7i863y5ivIuLXlcwhhKQ4hPJxeC5RQ ZyjIE2qBNVOg/5FvyVyTbejxjFhzZaxeqWNiKbYNbbZYV/QkvlVNY1xVyvYSy6fzPWids67I xFAsohs2MZU/b1RTIdAVKmEgP45WMZHNW1VPrIG9phXI+oToimpfKyar5EQe94fvfyA7Ozt0 5byubTdIabcBn/ATl+PovN+n64auGUfS8aZ/0Sp42MitMHCbr4b9Qa87Ou2c9LbC7VXHhv7p cRn2Qvp/eti//OOdcrkiC0ih/0DsK2H6XxVRD3ycLi5OOf1Ppv/u/D+IBewmsoCF4JIhIS7X K0D+S/DZeHomEKXKm6/2+6cHR4cXZ71R8O2WS4wnCozjRNHHqmIxXcOlbaY8U24N86O1tX2v WFu0O7t1Spok0GDg560xCWI66wgdvZk6UwDxL62tDe4pKk/Rp3czjT0slBDk0enwvHN8TDvR dggLrWcIvR0a+6jm712cdo97cRXrU+Pyj1vlMlpNoEkOoQUO/drpTSLknGel8yxRRHZVEsUa W+k4j8fdg+POIWMB3moiB8aNPpFt1dAL2DyPVMOAn3XOjnrDESz93ml3dDHonzL24Rfp3dkv hN9F1v6TcLk8JaWF/N+SZ3NNsUbqvqwNDNOWtaUkgRT+X2k0Kp79r1rHfFK9Wsn5/zrSQv7v zH/Zn//MJj9RbNWbiZJARsBhA2CtVeMMgE3kOs2IWhjhpILW6+8bum0a2gb7/X6mnc3HQGq6 /RP4HMp3QDz3HfPZilwkqSWutlEKaRsPtNY99vzH4L82kece6nPTsnQdafafOuC6L//jPpEE SkGO/+tIEfv/jaXAvFvk6trawZmHhQooAEKtRx9wfXgYzKNtgkIghchAUvnkolQyonIRlYpQ koJylq3MiVsY5RhB1cfazUQBaaoM/4MYcaVOaScAqRNfEfeVj9onnZ97B0fHveEW5JzNDN3J WSAUpVE3J0hbqPC7vQuyr7MJEXxNNrCr4+uP89vJBhWA8bdmjfp7P+2PaAUbkJE93JkVSs5r TnDfCEvuZQZEmlgzLQYOfe6CYpkyQGNNjAHHXrjwnGwpAGF2+GH4FooIQGLGHwvc31xdkMd7 DDXRuX69XSMlSdqu4qBmayHxZj+Ok6TMsm0YmjPH8WAMoBIUjr/IXAT5skXUJPp/eniMX49B /lPpv1gXQ/RfbDYaOf1fR0qg/0Hyf1+wblVYH8Q2iIP9HZRxRiA/dY5OQ6yBLZ2lOUO0eBpj ECvIGeDzGVmDB6T8q2JaVCsvCG6h4Jg55hj35XF/H2TFs37/HHTp+BJ0lKEQExUXm5cIMwD8 5tJfahvAEaWD1WgiZYVPSlnZdvHCTnrwnX46YuvfjEp+vSmG/qN9b53yv1Srcvu/1QqT//H7 EfuZmHL6n4X+exQeF8cDhH+xFiLxSeWTi75k4V+sbYvYstq2VIuT/9UZSKiGbiuWzRQAfPDn jWHLvACMqU2O4NUv+OqcCqP0t/OnVwolcR/EIkGcVSWPtXBFGaqCUm5FY3uxAsGqmSp2UjUc WMjlgsUC6WBHKJZHB8p75UJj+RbDw3Un3c2iw9EmJ/jq/UxzmurmROheqfTGBtQ6EjcG+Oex atnckDC1zym+uA5cQ6M/5xNlbEyUoPoUeIUAg3k5uBGolqp8UkLDjJV7zxGcnyl9GJzVHgLH vfFWlpNxMchcrXvilMT/H0Xxc1Ka/oc+30H+LzbqlZz/ryM9rv5HuXsGqaAaJxU8QBp4oMaX JAx8lboesjM6TDXckC/BJ91JfpCWtzCzPJ2aylS2lVVVQuL4BMjjj/L070JwX1iKof/TiSaO BjBxMM3DX45XZwXp9j/e/4vu/1ZqjUZO/9eQHqr/4eIo+4sjldiL0ZMfC0Akl0aCJlGCJjE/ I6QcR1fopbNNbk3VVpA52dcKOTAVhQyNK/tWNhXOTWYbSwC4cwWVTzLQ5LFCBDK8wbLVamWb 7EGbIB856UDloigKeAptm1wMOzvrtSFyjCXKa+jWdwXNePBJzXgwoCGZG3iB8xB3Rha24BLG R3NJ+bePJU7/TaXpLy8F6T9buDfm6jI/nxbTf6lar3D2vwbd/6lVm7Wc/q8hRej/pWxdq9as 4PpCAoWCtaFeqppq3xP7VpE/WoWJQd0jr2VzgiYGKnhvA3WfKTZInxZRbYuMZU1TJmRK0f9K vQPpVP9IbRXk6kYfU89FZCvemkviH5xDsZc3ZktI5BWEGuoHaJIrCN/+o3yp6mXsV6Hk/IA/ UfREjnBq2EqLvLtWdCJPJujrQ9meMccGWoypqBaxxqY6B1aj6BZUD89km3Iby7gxgY9Ytqpp rO46Min6iX5JZ4ejvd4vF0e983alQH+e9vfPep3znvt7cAb09X27WGQ/D85Aln/XP/uZ2mvg qYBPD4dIh9vFzQhZLhZKXIbfp/oNqkIOJhNB+CSbqgw0uR0p+TurcP/g0IE9eNflWZfToHdH 529HTmG3zfRZt7d3cdgW2WHMyrYokRJ8SaiUkUPMjWBHw7N92pHNv6hhh/38XHbb6VR0dHre O0OfKSwTl39najlZL4a94SiQv60bMJ0ldMK2lbGNPMlZkbqiTGANwlxpigwLDxbNP/FAa4nO sfCJSN+XJ8qnsn6jaeS/BASSOS3NPeVyoGsY+TfZ/IEIoJBVyH/ewArQCyVCaCuYJMB8yJxH bPGXrtRCCdfaeb/bb+EyI/PpiI30NpndW39qzi+i2ON/oFp3+jM6moN6h77r7WLAI2w+hQIB v7AYR7Ei063+GZNAxAN1K/YVijkucrJsr7bIX4WS/ychgNg2+de/Rp39Xv+gQD787iHldz5+ WkR2tXI6xUhWYCIYttgooeH5YlUH4qtpVDxDEYvuUDaoW1+N4Y9bS2JfzBtdR6RN7c3cVHV7 IJuyxboU+g39UsbXBinuO12gjWoV8QXMOiVbmxw2o21XfIMkQHcKEnILNIBcKuRPFCl3im8I gYkPl3fRP668oX9nk7GpgG5NUKKyAAaAoG5G1NtRrDh0JalbXjeg4Z8D/QdpWO/rB2+HAxOk tTs2CHEPQzP8rnN2WiDvICMMc4vcGzcE5Wp3pnHscSplYAg6kEEZpG1zQgAk/LgHOXtOIe8U iJfYkxYbDkb9HN93eo5AdAR8ILWfVNPQZ6CBQHG+NcGeWYp9Mz/SbcXUZQ3oICw31rukF9yU CFdk868w8flcPlYvTdm8L584oi3dqsLFvGNds0lj/QmQ5kxwin7Bo+EIhskhoGLtNeMbzdAE L+gEJkG4Ve1rPI6BFQHZn10alHj2zi8Go/3+yV7/M6UFxF0agk6KOzsu7oGyASwGX1I0dZ9+ //3mXzBPQHQnqvm57MI77h+iqekzEjhCNrGfmYvQFjz6sDXZmnGP0mQZNkTK4Ar6JGsqKImK M8kdc+oQiaQXACVodeTXVPFu0+9gEfC8eFfkFw2/9t72T3rl/qFxBtJnllVH1eBKlerBohjq 84LWRvtMB6gzB1XY727MM2fQKcMfnp8dUREg0Ne/ogz5M+21bhTDuBKQJdgMSuIu0+obcTMY acy3ybMXnbbgfLlPHQJEXo2NG22CBPtSsWGh/LDFaJ+luFPIiFMRljjrQvHO57fF//K/ykV2 sEtqsrnZTZqbxZNCqbkzfUPsP8erIo89Wu8uRI5gMsblMhbrHt7PgOL+5QqBjtM5WqI/B7LS 3rQIl9W3WUNO2sfdOrq7lqTXVcftNaX9yUxpfDWlthvWzcAvr9CmWATawriFI6uGwUwVnbFt n/ZHH9E1cAskbqobVIJHGUTTjFtkYSAlg8iiWQZxFGJyeU+mnvjSYqUJGXTO37p/d3877o5c Czx9wSThKjorVAE7dwNjE9si1kWflnBT6LFYKonAGISGgHijhwCIIzfAer5vke82IdsIsg+/ KwZzFpF0+z+pjI1z2/59fjv5PfTWteJ8cIRxughcQxQFHG4G06ZQSBjLOgF90jRVACDr945G RWQUDb/DQf0Oxhr3HQD1QK+atorRPrFEOdNEubyZtu9BJmLDLFJEq0rVbamZPs7f+nA3fqSD fowL3Rt3Tu0hoO3JAOqTUgyVZD0WiCfJW9cuBaFLh2Wjgm/8VlCZOKciuU3vH3DIlwJId4qc 4mzco0EKsDOoqd8rNpE/yaqGqiB5BbQVFzhnfdxC9R3Qg4FjydC1e9DxPymBZekqlBZfM+AV TDhIrwg5dKJF1ZkKjaSFGmKJasMs2Za7PiYgA1/e8zXzZtHgiqRnDT9EIzR88C2Wb/vDQICG 0KL2j/I2antH5y22plJr8U4AhWsKHgAKV3Y4HDEtju7RtdpUNQtkQYUxQ6lGLVwOt92Wg5UA KTwIujMKIG55K5buXW4njymfl1XbaseBKMPDUNO2yolQ485IfeBPZUerDTcxbrgWV0C5e3wz HcoXI/UFzDdF8g9e+qN0S6JHv6v1OoY1SaVbQYLoqdcTqnOhkuVI38Vw5vCAt9q8RBPOXWQC fYgvsE7D9P3V7Q3PUTKHP8OAP8cNUTy87l6n2xmc98+Gy8As080jyH3S+al/Nvq1dzYEMvh5 B58cnXJPypNLeSLPbcO04tsxOOt3L/bPn7gVc9OY3IzthDYMO++7Z0eY+WlbYcl3ExN4WdJY vOu/p8EQnrwht8adcHmjapPEppwe9vd+etfbS22HdS2bSvaa3UgGL6lWmP6TzmBwdHqYPuwP rBhmfCbP5xhTIb5u6luXWuulqscX73ShwoxArDgoTN+gRw9SCJwrnfFEzrGHVasSpaNU30ol owELnG+89m1wC5tig1ZAkdmRQqcoD+C+R/FNuBx974oUmfrJAdcNXchYAejWbBjqu9vSa1Kq VSrsIPTicZgYuhKUsl39hVqK2puBnxHVQXDF38cTN4Xs4qbwuOKmEC9uCquLm0K8jMGLm8Es CeJeIBMT7VLLhUsxqUcId2uhaJfQ/hVFuwSoy4l2sZ18FNHOWeM8tsqfDHUCaphvD6DWdFgM oUrRCEDHJMbMslVGv2+rBW8x21bUFoIHYI9V/SPAdewh4SfU8OCaenVQnUn7e7IpbhP7fs7+ ljAPteEQQ5uASt/GXT3/oT2bT1SzXdzxKJCAhFHY3HToye7utrgL9ESsbEuNAEGJa83sI0Aj mwwqpRaTwK85+rLMZFW3FV3Wx0p5cjOb3VM/kjHZYRoHEnqYA8TbTfHNxGDsAsMmtIubNHqC oG3+BX98ppzEJWH4D2rC2WgXOS8UOiVUwyffbzoZfEtG0DmHAozkTfAc9c1k38cA/hDrMcMR lvji+/6JET+12nSvHCcmvpT7duS6+0AJbmT9IYgt5IelYHEpNkV/HAJdW1ELztoCd5Jp3J/4 kp5e+yCYCbAYtYgb1yip+LAg9FcmGDRhg/4Kbep+Xmo9eS5Yni2K7WRbZKZYuElrIX+hWwsu SHeEyPfGjb2jGVMifQ98EP/C8WGbOMsCoJgK/TrrDS+Oz9ubP4TV4k3uNYhbFU4VrkkVRmvq QGukVFpjzohgXvnkJYZ6drkgbBwJjTyOiqM8uXcIbCCkG8vEtQrU+pkmFV2UZcZNWXsTzYeH mmPyCeF8lqV52dzAY5M3nmmQ80qRNZw46ovw+w2ygd9xu8Vx2ClybgkxVRAahcYoZqrC9WVY talsGzwIY/6nD2LR8Fl/ajAv1WJaPupGMdZUkBmLfL7gMjFv9CObLQ3/z7CC4G7x/yOkHvh7 7W84TaRWp9E/SrXodghXRaIDg+tolOrAoNzZpjy2D+D3r7J24+xzxD6Fxv3aOb7otYu/+3so /yXogVG0yv/+3/Z//tkul6fF3yNCCKgiY6ADfdood/Mp/Ij4u2QivzkmCNeKNseNMeG6uFUg G9Rt5A0L4Mi2+ep1Z6OWsXFANkOexO1+FOJ2M7HAlWrCPIECQEviLo6/SRoAIDiuWZtduhvr SmRvC6Wd6LMsCyCyuQWrANbAc3vwrZaS/P+Hvxwj2q0l/lOlwcf/pvd/NJtifv5rHWkp/39n cWRx/g9Hg00qn1w09/znPf+DATzc0JtIutwzYVld+DMe28o9+b/qlET/T+4f5egXTan0v94I nf8Sm7VqPaf/a0hL0X+6OJY++hUpnZ/6yml/np4nJdH/w+5xZ4x63yPwgNT7f6rVyPlfSRJz +r+GtBT99xbH0jwgFsJiPiDSE0ZPG+ePPudosxBHnIUodU6J/xDnS4vXRjwosoM3ZE6cajom EnU2FSXH2RRtIkKv32HuL6GARO3QazwaDKOgK2M7vkw7+hrLhCoZ7L+l+Zklr+1upl7HAefy chlLIYh8SKBIfNlSFOrC/E6QCf/iBOtmPjdM2zl1UaVHBeGr+uAgGQ4T/bKPTCff/9m7sxUd V/fKLCA1/n+zEY7/J4qNnP6vIz2U/jvXdvqLI0u4HzH+7s94IDHl1xoGPMwD0u7yAfGF0pBG 9UsMqvqg+3+XrCPj/R+B+J+1ao7/60hL4n/ctb0JyB8O8pwM4aVhfpycxw6qShTjRelLxPhg SsL/Ncb/rdQl5/7vWrPZbDj6Xz2P/7SOtBT+J8b/Hco2u69nl4iAvbutavgOoKTyoaJSrVXl cL/aQISDT4pv+nQsx8S1RZ2Cvspvg8iekvDfuzJpLfw/Iv9XarV8/3cdaSn89xbHMrE+kyEk F36Zkn+TXlMDn1+wFLAI/02lK9vyk8d/BP0/cv9vpZ7f/7eWtDT+s8WxtPYfDyK59AulAFT1 b36Rmj9LMfiP8e67/ZPHCwGeiv913v+rQff/K/n9T2tJD8V/WBxlWBxZbncKM/6YosmlXia+ i5Ua1fzh64vF+GBK4v9rjP8P76QQ/xcbdTGP/7mOFHP/L+XPy/L1p2LmjxzCv0AGnf2fO4c9 usHa9trvxGig1gaJBhB1EdaPUw+FZ/LYsO6E+ccpabWIrGkFYSN00g3rESAT5EHPdL+GUkpO PB/oN23riQ0KSfd/sHsE1nL/I9X1Q/d/NBvN3P9vHSkG/+llHGz+l77LI1r8uZX75RzxvjRz 3oNTgvyvqZfwhUFKaPCQ1ehA6v0/9Vr4/m+xlu//ryX5+E+lfQyVwCIzs1N80k7FiwAOaJhd RwgtoGVug00Bs/hWWBou14mlGreP50Zi449eUzcrvjovV+/9ee8Uw6vQXDuWfFcQoqHcAlf9 hP3AtrzwnkP5joG3hM1XgXAuWzvwgI/mgv5OCfWEogjRu9LCWOu5W/FeWcypmuoxkqPGhMtR N7Wj/+l18eBu/+Jsv+d6hK22sRK4a+KlaEB/75RA//evZX2qHBtTb7GuwALS6H9NYv6/9XpF wrOAFfT+FZs5/V9DevD9by5aM7I0DFL96LKJEv7zG4Vt9NaIKLYqYlSRTIfk7RZLr4m425Ia AbtRHO3PohLGsoRoQ14yVwjNztYDwcIgxGA+7xK8gffYbkQz7czwDQtPTVmLczdRDLgwTyGM LQC9vzJ25ppq2Ste+5mzmewpgf7DbPUv/9hfj/4f8P+j8r/YbFZz+/860jL2f2dxLCvTxxRf LMu/vH2ABrUQNr5O/z/E/8d0/0uV/5q1emT/XxRz+9860jL4n+j+l20PMM7775n3AbNIh36k tjZhko5Y3RZxN7DqXHoVzEE28GTun3MqMRWIaVkSFW7E4BEr/znejM7lilX4vVNNXkYpAZwU ACelg5vLpqUEvSrb3nMHGMuzGBSIwUhBQu6Zbec5vU+e5VgMBnLoUR/PNn2OQOj7xSAmxiy2 Jew5AnFyLAbDpjEKhj1HME6OxWBepk9qAv1/P9PO5uP1xH+oNALxH5j/R6Oe0/91pGXoP1sc y5L/aOnnpv4Plf5q1O+z9kX7fbopSf87f/8Ylj+WUu1/9WoI/6VKsy7l+L+G5OP/mFpq0MTH 382JO0APUQ25dbMsgUiCkUYmxCoND1B9aXvI2bef+J6vwcpI5ZOITZA9XWEXKkA7sm5BBQqF LISlNokGX8jtgo+SEuj//P7ukTb/v8lw/q/mnP+r448q3f+HEjn9X0NaRv7jF8cyZwAXwQif AxRbNS4OpMjcbx2aEVikAS2Yf7PqacCvm2rE4L88n1uKiWM6NPoHwyc//4OzG7H/NSq5/886 0kPx31scZbo4ssh4jRD6LwCRXPql2AGzR+tr1uk2tHNhN9MSY+Q+kPpwFGLEPRT27uarCHvG wLmDbGVHI/fKNGbIYnQhxjhHXziVIt1lGUPiHGZ0Lkdztnv5YXtNZ/m1c38uVt7lfLRT+xG0 07LWdx1Pamh54EGQZyB8NOYFs8SOBncF1hYLMLWYwbCjIyxoROUFhJr64rhUnp4qLeT/p4eP YgdOk/+bzVqY/4tVMd//X0danv+7i2M1ESAOylclBVCq35ReKtFfiP/veo8SBDDd/zN8/k+S pFqO/+tIy+M/vziy0ICwFSAdUjKQL48OiCjQlkRHrA1Ed3UOHvCjkKApBLPEKQy3xirW4Xf9 u56mzPaca3pX1hq4y4WZ4sC0IP+ObEdMD/SLCcsNJiw3voY9tpecUug/6HK2gbdLriICptP/ SPwXCX7n9H8NaRX67y2O1UTABEBfkxQoVij1ryyi/t4gJBJ/LscXR/sTKT/XKUay6W1xNK5O /QuOq/OlpMX0v78e+b8uRuX/ek7/15FWoP/9h8n/CxhAAqSviQO8Rgbw2jmTlvHaB+9MMj9A 8bwhLsOXwxyS2UM/pBg0d6k5ZTdnDI+UUuj/+5NHuAQu1f5bidh/KvU8/vNa0ir0HxZHlgAx lQWEPwQiufQzR4BPpe81SphqXxxhisF/FaNrrzf+e8Pz/xLx3geM/y7m/r/rSA/Ff1wcq8R/ TyofLvq6JVWS/L5U5ZOsmeaNpkRuuPJf5UHgM6Uk/EcXYdV+nDMAqfpf4Pw3vf9BbObxH9eS lsL/0OJY5hbANDipdwG+AGf/UAWLLwiM9/gPjcBLDi0SdvWneluYTAzOjk73jwad49H+cWeI blW/DrnexTj+hyGkRwfJ3XkfMSXR/9NDdV9+jMs/vskS/z8c/w/Pf+b0fx1pKfrPFkcWo19Y 90sonlzyxVn6IneBsdv/xC90ryIl/scACe6qUmCq/UdsOPHfxCbGAgH5ryrm9/+tJVEcT4n6 GRv8I7gysoR5i4sFlA4tEOqt0aqiWumTBupjX3+kUG/BRqwii10Me2f0mmdfCNujcoeVOXIb jVEexL6AuzoGGAm+B4334fOfFP+fjdcIx2vlNZbK/yuu/afWaDjx/xuNfP9vHSkp/j+HL1HT TrNVbbbqsfH/uXLhIrsBY25je5eUGpSpL8GGQR35+TeGYCvcy+5V59/LvoX3sne63SPMh2rM YHBw3Dmkh5CFuTpXiPBO1jT41A1hjr4LY0PDgBFsR89UUF6Sddvd0EsChaF1e6fnZ53T87b4 jFrFwv2fRyICqfbfesXHf1F04v/l8V/WkWLw39+fSSECNbFVqyVu7iRTAihX5yhBDSlBbVlK kGp4WRMFCJQ5Ot0/vuj2sBZa7sOLtRvE4P90oomjASgeU1MZ/hLY/x25RpYH1ZEq/1cj9l+p mt//uZYUg/84/2V//stxRrasZt4ssBabeiUazVlq+udBKZa2qTbvM96oK02MnN1CjPedTLhX W+XD7nFnPFYsa8cDVT5TLOPGHONOFbydyHPbMC3XmXF5eywHbGWDbHev0+0MzvuOlyUzJTzg 3pIk/D8wDd3eky1FenL/D1ESef+/Krv/V8r5/zpSEv77859ld2c3Du3jQSSXpldvVVAYgE8q Dex3Tkf7/ZMBsP/RwR5Ten2UD7510X45fs/bA9rEbznWx6FCSAOnFgh6sKfmuPZxeaNbIf5L B/0DsMOn5NvkyA+IHt1HcnrnmC64FqfRpeFv8HUSsE6oQABcivQQcoPW2AsLxC2Yb5mVJ7JF 7GvF2bUhiuu+F++V6Jd7sQLSV54W6n8zYzLSp8blH7fK5Rr8v+t1qVKtVZn8l8d/WktaqP/x 87/Y2QdtOy0p+YhnEqRkIM71yrv0emXKDTqDs9E+U8Vci+3mK+taAV1s8xW83CKCMJ7PrzR5 Si0vkP24y+WPya5NaG78S73EQq4AlY2JxJBS9JX2JMXOXAbkQv6yv0+41CbT8bhAjrsxD4dv O2e97uj4aA8oJbU3G84Roua2WMFDRHX8hkcTYAxjTZF1vIOS/sFikci0VmGimqRVEDZAoPwZ 9dCtRbJpoRSbz3FH34rpFDJiHXAHhhOvwPTrZLdhbr5y+cfgrH8IIjeCdaK+pLckW9lMrRNu LBNnV7mDVeZc1klSqihDmbJTpnxt2/NJ+WvlTynxP/qXf7wD2n96+BZGYVkWkB7/rxGy/0lS vZLL/+tIC+m/O/9lNv+LWUCzVZNa1bABIBOwMJyqt1lIdQKqEjjb/6GN/hUC+i+lJwwv9oBg /NTbP3d1BdYbJDgOksRFPH3uWU5O2fD/1nC8sKbWErsBafH/atWmK/9Jlbrk2P/y/b91pIj/ D4wGseybq6uFBIFbENz2QGTPvxbe888AKrDh3wz7Au3SHf9dZ8v/HSiiZ/vHR6c/XwxarknQ M4K5hoJ3/ahKu7UN+Bz3IpMNT8WN/NTS73p7o85gMPTlym/JOejGujxTiHHF68mqBaSLPuAt EZ+gJhmtrW5JaguAkpqsT2/kqWKFYGjGWNbU/1MmCE02Ffy6u7sbHXdODy86h70hM6nuNpGk 4heTJLkhgj6wyHec8RNmaUgnrQWS04+cnPgjk7NsxdRlTfAm0pG8RiBtJQw+sa6hdROWUx8r wrUi04OFTlEQIM0ZEcyrJADluCa/IR+o5HnegRrG11dEAMFeuaMcob3/65D7tWN90uGnbQiW PTFu7NghIP8lr8aTpCa8IU5Nd1ARiK3fLttkKPlcbXZ1D/WK/JsIyoOaTv7zBlefTpbq9pVK u+42YDwnwvFZfI8SAHO3NOy/7b/DeIyI1Cjb09+g3yFA792DGuhi7HOT5ydPWfk/PFyO+X+T If5vve7z/yq7/7tRz+N/rSMtzf/Zglid+XNwwpxfbNX5Cx4qVRZEpepE1HVZalcBBjRTdYUy Q4CnqWPZVg2dTFRTGduGec/bod/1gScHzNDQCF4foBmGKXIAZILeFEoLCnHsv0B2Bm/7p7+1 eG6JPUc2ibsaHiEOvnY5qbPXUG1KVBeCr9cu38bO+EzbY9Ue926FeDQPtkUZ+ivk6E4PwwYg 1i2Hs3qEPvS2HGnHqpw4AMxjaZFG8cwMDUc+G0ttYZR7ZeiUw7RW4ddL9ozjj0EIkbJLsMXU nv9tuOHfL2Xj/08a/1dq1CPx/0Wpkfv/rCOtEv/X4eEZjgGF/QMWQ0kGEHIXzBC4YVVHwOyx emikHrc7jo+Qc3ZdlEBuQdbtiy2Lb5kTXNPFwduhp6zQNqHZwvUUGEYa773Z8ga2IDBvpWih COwy1crL2QLtl93tvEIpCpr6CkAL9n4CIch3TBK8znNDFX9FFJ9h2HcqbaeH/6crhEbbq9aY nMhDetvrdHtnzMMiZLbxByxQwuubc+Siq1zJN5ptMb8MerfrxrFrjfEfChvdzq8D05ifyHPn KQgO0YfUvwTm4aRzOkD7DHMWJRt0DtwRFiZupfUN5+bZBvWKExtOPNlIc7mrFjZfxfZnK/E2 in3DTIgw+GKvo8Am++vI21D1l5OTJXxlhdtd/8oKOrqvaTAX8bV7v3eGQNyBY8VfUGCJB/P/ kde+zHWk+X/Um67/f12qV6j/b7Uq5fr/OlK2/b/Y9RnnBSLVM20BxsILg2q0arwfcI3GfGBf vPrveiG4AGnwbPkKFF7Bd1AI+UHwbM81AsagamcyUdGQIGvlgEtDt3Pe2SIueWZy0jJAAxBC Lhjd3vA8W8tKqS3LDCvYIF5E4ct5VHpb3KnuVLZihptE2hSw9CDtRSa5kXnUaHF3nDbSusTl jmtJcMPpwS3haX2mxgSYw8tSpRPOfz/m8c/085+iFI7/0KiLuf/HOpJP/61bFZYA3v8bFOH6 J52j0+AZ8Mi5sKjCFnfYmz8RlnaXr5QW8cE5/9ne2aFqWla/D2HBCVIh5vyYsITaSJY6P/Y8 8x/E/0cJ9xJJqfjP/L+4819iDe+EzfH/6VNQ/ntYIK+nCdWcELwl6OflO3dE8R2t3Wy7hJqK qs7R0nCYlVhSsURAKXk6NZWpbEdiSqVX4Gt6hfiYYa695OnmP+n8l3ccbvXjn+n43/D0v0a1 4t7/ket/60hJ57+8+V9w/DOor9Wa0dPgGUCFobwGQJzWV6VO75J7BGDREWt6HGkgoy0VtBGL XBkm6bme4UQzjI836KcpeDpNrHE1MWBDOHf7w48fijFAPhRdO6fAnVXrnx4cHV6c9UaN2t7R eWp0iFD+tvhUekMS/vdNeawpu+uI/yvWxHro/KfYbDZy/F9HSsJ/Z/6XPvwZU37xyU+R3pAg snOUiMnkWB0ruqUQWTP0KQHtBJSTa3RyZPbkN+i1phv2Nrk1VVtBxQX9Pw5MRSFD48q+ldGM DXAODFC/qUPINjnSxzvbBISYcwUDT5GBJo+VbTK8QQjVamWb7AFTxpwnHWikKIqCCCyJXAw7 AOtF3SjBDp7WnR2A4AFWZ/Tz4/EJx+Nd6hY6z/vcyPgMKXv8zyUM/05Kv/+hGbL/YPzn3P9/ HSmG/ieF+AwZ/pcO9slZ/FPCftLzjp7aiBEJVY159lmKbav61GLy3AJx7qQzAILQLmaMk3wi z+cIt1x09819ACvul1vy3YyHTmlRyQfvxleGJ4Oj00MgWEUkVW4Zdp6TWdb9XQJWfGt5yrVw /++RzEFp+F+TnPiftWpNbDD5r97M8X8daeH+X+J5P3TQraKPbzXZsycphieUAzzndvaqdLed fvL7enN5/FGeKgwHxoZ1J8w/Tt0TvMIGCEgzGf1adTxAUsaqBMgEeXas61BbCqWU7JuvBp39 nzuHPcff8blnZX0pSf87uX+U0F80ZY3/y9//kMd/WE9K0v/o/K8e+isZTB716xmjfvkpYf/3 UTeCUvl/wP7ToPu/1Ua+/7OOFIP/uFWbwae3GrPDu3hHqLrkjlCynWXZs/+EZ/dtt/l/I7bv pST+D2RbtZXqo0gAqfxfksLx/8R6jv9rSUn835n/B0kAsYbgRYAWW4RzGWANMkAQ/4EImvPx aIyHAx9PBEjF/wYX/7Naofq/mN//tpb0gPM/3OLIcu0rJx8klEwuREWE6rYogpBAv+ABvzY5 u71zYOL9TDubj/c1Fdp7Tj3s6dGM02H/8g9lbJcGJij/qj51nr+V0SNz31QmkF+VNYuV3JkV Snw9HOJteIh33u8fs+MTz3a/ZNgmAj36lkwM3A4jl3hJN5EJvvkDVjfdB6cbZ1hlmDzE8P+Z OlNGp4dHM3leW8v+b4Xn/w7+N+u5/+c6Ugz/x/kvO/OfBdHDTh9J5ZOLvrhLvsK3fDVo6IFG 1T1txXAjch+P8+JEVrVL446G752xI2LOm31D14EaAeATWZeneGcPvua6FktJSil0JvmM4sK+ WzeXc9NA8ui6pqN089wrMk/rTMn0H1fxeu5/rDU5+2/Vuf+lkt//vY6UTP9x/lcg/+HiL5/6 F8iDPf2fe/bylKc85SlPecpTnvKUpzzlKXv6f9l29igAaAEA ------=_=-_OpenGroupware_org_NGMime-19204-1199065418.207579-0-------- From developer@opengroupware.org Mon Dec 31 03:03:57 2007 From: developer@opengroupware.org (Helge Hess) Date: Mon, 31 Dec 2007 04:03:57 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application In-Reply-To: <20071231014339.165BB37E36@smtp.l00-bugdead-prods.de> References: <20071231014339.165BB37E36@smtp.l00-bugdead-prods.de> Message-ID: On 31.12.2007, at 02:43, Sebastian Reitenbach wrote: >> Not sure what you mean by "hardcoded FHS stuff"? > I just mean the hardwired pathes in the objective-c sources. There are no hardwired pathes, there are just specific relative (subdir) names. And I fail to see how else this can be done? Since there is just one (configurable) lib dir, do you want to put everything in a single place? Why would you want to do that instead of using subdirs? Please enlighten me ... > Only for -devel packages, the Headers are going into the GNUstep > Header > dirs. As they are not needed for running sope/ogo I did not cared > about > them. This isn't the most important thing for me. Though its definitely un- Unixy ;-) > For developing, a working gnustep environment is required too, I saw > no point why they should not end up there. Because for developing a GNUstep environment is NOT required, only for running. How could it be required for compilation? > Further I don't have seen yet a variable or sth. that is intended to > install > the headers outside the GNUstep header directories. Too bad ... But probably you can do using GNUSTEP_HEADER_INSTALLDIR or something. Ask Nicola ;-) Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Mon Dec 31 07:11:08 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 31 Dec 2007 08:11:08 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071231071108.F0AD337E6D@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 31.12.2007, at 02:43, Sebastian Reitenbach wrote: > >> Not sure what you mean by "hardcoded FHS stuff"? > > I just mean the hardwired pathes in the objective-c sources. > > There are no hardwired pathes, there are just specific relative > (subdir) names. And I fail to see how else this can be done? > Since there is just one (configurable) lib dir, do you want to put > everything in a single place? Why would you want to do that instead of > using subdirs? > Please enlighten me ... The hardcoded share/sope-.../dbadaptors What if someone had the idea to rename sope for some reason, what if someone has the idea trying to port the software to a not unix like operating system? Maybe some standard will change over time, and someone decides to start all directory names with an uppercase letter. Well, maybe not too often, but having easy switchable configuration options would make life easier in general, no matter whether compile time or runtime option. And with "hardcoded FHS stuff" I did not meant, that the GNUstep lookup path stuff is not hardcoded too ;) > > > Only for -devel packages, the Headers are going into the GNUstep > > Header > > dirs. As they are not needed for running sope/ogo I did not cared > > about > > them. > > This isn't the most important thing for me. Though its definitely un- > Unixy ;-) but maybe NEXTish ;) > > > For developing, a working gnustep environment is required too, I saw > > no point why they should not end up there. > > Because for developing a GNUstep environment is NOT required, only for > running. > How could it be required for compilation? Well, when you only want to compile from source and install, or develop, the headers are needed in both cases. I just wanted to say that when you install from packages for your system, and you only want to run OGo, then you do not need to care about the headers files. > > > Further I don't have seen yet a variable or sth. that is intended to > > install > > the headers outside the GNUstep header directories. > > > Too bad ... But probably you can do using GNUSTEP_HEADER_INSTALLDIR or > something. Ask Nicola ;-) I've seen these _HEADER_FILES_INSTALL_DIR, but these are defining relative pathes, beginning from the Header dir, defined in GNUstep Environment. I'll need to check whether there is a variable, but would it really be a big problem if the Header files would not end up in e.g. $FHS_INSTALL_ROOT/include? cheers Sebastian From developer@opengroupware.org Mon Dec 31 07:22:06 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 31 Dec 2007 08:22:06 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application Message-ID: <20071231072206.B849737E40@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > developer@opengroupware.org wrote: > > On 31.12.2007, at 02:43, Sebastian Reitenbach wrote: > > >> Not sure what you mean by "hardcoded FHS stuff"? > > > I just mean the hardwired pathes in the objective-c sources. > > > > There are no hardwired pathes, there are just specific relative > > (subdir) names. And I fail to see how else this can be done? > > Since there is just one (configurable) lib dir, do you want to put > > everything in a single place? Why would you want to do that instead of > > using subdirs? > > Please enlighten me ... > The hardcoded share/sope-.../dbadaptors > What if someone had the idea to rename sope for some reason, what if someone > has the idea trying to port the software to a not unix like operating > system? Maybe some standard will change over time, and someone decides to > start all directory names with an uppercase letter. Well, maybe not too > often, but having easy switchable configuration options would make life > easier in general, no matter whether compile time or runtime option. > And with "hardcoded FHS stuff" I did not meant, that the GNUstep lookup path > stuff is not hardcoded too ;) > > > > > > Only for -devel packages, the Headers are going into the GNUstep > > > Header > > > dirs. As they are not needed for running sope/ogo I did not cared > > > about > > > them. > > > > This isn't the most important thing for me. Though its definitely un- > > Unixy ;-) > but maybe NEXTish ;) > > > > > For developing, a working gnustep environment is required too, I saw > > > no point why they should not end up there. > > > > Because for developing a GNUstep environment is NOT required, only for > > running. > > How could it be required for compilation? > Well, when you only want to compile from source and install, or develop, the > headers are needed in both cases. > I just wanted to say that when you install from packages for your system, > and you only want to run OGo, then you do not need to care about the headers > files. > > > > > > Further I don't have seen yet a variable or sth. that is intended to > > > install > > > the headers outside the GNUstep header directories. > > > > > > Too bad ... But probably you can do using GNUSTEP_HEADER_INSTALLDIR or > > something. Ask Nicola ;-) > I've seen these _HEADER_FILES_INSTALL_DIR, but these are defining > relative pathes, beginning from the Header dir, defined in GNUstep > Environment. > I'll need to check whether there is a variable, but would it really be a big > problem if the Header files would not end up in e.g. > $FHS_INSTALL_ROOT/include? I've just came across this line in Makefiles/Instance/Shared/headers.make: HEADER_FILES_INSTALL_DIR = $($(GNUSTEP_INSTANCE)_HEADER_FILES_INSTALL_DIR) I think that looks promising do the trick. Sebastian From developer@opengroupware.org Mon Dec 31 07:30:40 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Mon, 31 Dec 2007 08:30:40 +0100 Subject: gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OG