Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

GNUe Traffic #40 For 3�Aug�2002

By Peter Sullivan

An endorsement (I think) - "python might be crap, but we consider it a polished turd - not diarreha like java ;) - or bloated gas cramps like C# (i.e. a crap waiting to happen)"

Table Of Contents


This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on, or you can review the logs. For more information about the GNU Enterprise project, see their home page at

1. xml2sql utility and .gsd (GNUe Schema Definitions)

24�Jul�2002�Archive Link: "[IRC] 25 Jul 2002"

Topics: Common, Designer

People: Ariel Cal�,�Jason Cater,�Jay Felice,�Derek Neighbors,�Jan Ischebeck

Further to Issue�#39, Section�#11� (22�Jul�2002:�Using schema creation tools to set up GNUe Applications) , Ariel Cal� (ariel_) noted "the syntax for foreign keys that you and jan are definining is not what the xsl's are expecting" . Jason Cater (jcater) said he "has not defined any foreign keys - that whole thing needs to be discussed - as jan is doing a lot of stuff in there" . Ariel asked "so it is better that i speak to jan" ? Jason said "well - that wasn't my point - but sure" .

Later, Jay Felice (Eraserhd) asked "Anyone with authority on xml2sql, .gsd in here?" He was "not using gnue or working on it, but in the spirit of not inventing wheels, would like to use xml2sql." Jason said "xml2sql is really in the early stages - I don't think we are satisfied with its current state" . Derek Neighbors (dneighbo) said "the idea of xml2sql is it will be part of common - any product with a gpl compatiable license may use it. I dont necessarily seeing us packaging it outside common - as ultimately in will be a tool too small in the toolbox of GNUe to segregrate out. I think the idea is that integrator and designer will provide solid interfaces to it" . He asked that "before more changes are made to .gsd that they be documented and sent to dev list" to keep everyone involved and up-to-date.

Jay said he "would like to collect multiple schemas into a composite schema." Derek said "im thinking you do this with includes" . Jay said "the includes could conceivably overlap, so the "combinator" would have to be smarter" - "I need a schema to be able to add a field. ... or one row, or a table, or an index." . Derek invisioned "we would provide update schemas" as an alternative to the full scheme for new installs, addoing "we will have similar issues for 'package' management. Another idea i had was a schema 'diff' program or updater so to speak - so if you have an existing schema/database and you want want it to now look like schema X you could run this compare/diff utility and it would create the schema necessary to do the updates" . Jay said this "is something that I very much need. I wrote a dbdiff utility a long time ago, but it only works on PostgreSQL databases and has some flaws."

Derek suspected "the first phase will be providing tags that do alter/drop etc" which would allow you to have seperate schema definition files for upgrade and new install. "Its not great because you have to maintain a separate update file by hand - but it provides upgrade mechanism - ultimately a program should be able to do compare 1.0.gsd to 1.1.gsd" and work out the differeces for itself. Jay felt, based on his experience writing his own dbdiff utility, that "there is no way for the database to "know" how to upgrade data structure without destroying data." Jan Ischebeck (siesel) said "you need a: GNUe schema transformation hint file" . Jay suggested "The hints would have to be fairly complex" and gave some examples. He did not think "there's a way around a tested upgrade script" written by someone who understood the logic behind the changes "but the diff utility (which prompts) is useful for developing on one db and publishing to another."

Derek said he would expect to do an upgrade script from each previous version to the next - if people skipped upgrades, they would need to "simply apply the upgrades in succession" . Jay still was not sure "why would the upgrade be a .gsd?" Derek said that, by adding alter/drop/add to the existing insert/create/update syntax in GNUe Scheme Definition (.gsd) files, .gsds could support both - but if it would "make everyone feel warm and fuzzy to have a .gud gnue update defition and maintain yet ANOTHER .xsl file?" he would not object, although he did not see any real need. Jay said "I'm thinking that how I plan to use this is tainting the conversation... at this point, I don't care about db independence for my project."

Derek said "to me that is only reason xml2sql is around (db independence)" - and to provide "a quick migration path" for converting from, say, PostgreSQL to SAP-DB. Although "postgres is a good little database" , he was increasingly finding "it has friggin issues - not as many as mysql but still" , giving some examples involving type casting - "which is fine if you only want to use postgres - but if you are doing any kind of x DB stuff you are hosed as its so non standard" . He felt that "from what i have seen of SAP-DB i think thats where its at - especially because its supported on windows exponentially better" . It was "GPL - so even a better license than postgres ;)" , with all the tools released under either the GNU Public License (GPL) or Lesser GNU Public License (LGPL). He had had a really good response from their developers with queries, and "we have committment from the SAP-DB team to work with us on any issues we find in the python driver for SAP-DB" . He felt "from what i have seen SAP AG might be one of the few big boys that actually gets free software - i.e. SAP-DB was not a money maker for them anymore (oracle and mssql and db2) were always chosen instead - but they wanted to keep it for those customers who do use it and believed in it - they figured making it GPL would help draw some new blood outside SAP R/3 users" .

Jay explained what he would want to use xml2sql for - as a way of doing a consolidated schema from a number of php files, each of which defined "it's own "interface" to the database." Derek felt "this is outside scope of our toolset" as "gsd is mainly way to get cross db definitions." xml2sql could be used to produce .gsds "then write a program that uses an xml parser to aggregrate them" but "that doesnt solve your issue" . Jan suggested "the merging of schemata s hould be done with gnue-designer - its quite easy to add wizards" , now that support had been added for plug-ins, as discussed in Issue�#39, Section�#7� (18�Jul�2002:�GNUe Designer plug-in support) , "so writing a "merge schema X wizard" should be quite easy." . Even if the underlying application was in PHP, that "doesn't mean that he cannot use a GNUe Development tool" .

For the .gsd format, Jan asked "any objection against <constraint name="fk_address_personid" type="foreignkey"><constraintfield name="personid"/> <constraintref name="id" table="person"/></constraint> ?" Jay did not "like uniqueKey/index/primaryKey, those should be the same, though. but all said, I just care if it works." Jan said "I can understand why differentiating between index and uniq index (=primary key), but doing 2 ways of specifying uniq keys possibly makes programming a bit complicated :)" . Derek said "i need time to look at what we have and where we are giong" but in principle "i like the idea of <contraint with a type=" .

2. GNU Enterprise's influence on other projects

24�Jul�2002�Archive Link: "[IRC] 25 Jul 2002"

People: Marcos Dione,�Jason Cater,�Derek Neighbors

Marcos Dione (StyXman) asked a "python question: is there something like class enums?" Jason Cater (jcater) said "no enums :( - my ONE gripe w/python" . Derek Neighbors (dneighbo) thought "they had a clever work around to this" , and suggested some web references. Jason said "yeah, but that stuff is a little different" - as a workaround "it will suffice - but, bleh" . Derek said "it will be interesting to hear what python 3.0 will hold" . Jason felt "it will be interesting to see python after we become even more major - as zope had the most influence on the development of 2.x" . Derek thought "gnue will be one of python's glory projects soon - as well as wxWindows - we certainly abuse both of them a lot" . Jason "REALLY hopes we can influence DB_SIG 3.0" . Derek thought this was unlikely. However, Jason noted "read over the spec - DBSIG 2 is primarily for reading data i.e., non-transactional stuff - iow, DBSIG 2 was written to create a standard so that Zope could get a lot of drivers so it is really web-oriented" - GNUe really needed a more transaction-based approach to the standard.

3. CVS access issues

24�Jul�2002�Archive Link: "[IRC] 25 Jul 2002"

People: Derek Neighbors,�Marcos Dione

Derek Neighbors (dneighbo) noted that the changes made by Project papo staff had been kept in their own CVS tree until now, but the Free Software Foundation (FSF) had now received the postal copyright assignments, "so i think we are probably ok to start taking patches from the papo pals ;)" . Marcos Dione (StyXman) suggested "uh, we'll stick to our tree till everything's in place." Derek was "more concerned that the longer it is the harder it will be to do" - if he had known earlier that they were maintaining their own tree, then he might "have told you we would take patches on good faith - to avoid having to merge really stale trees together" . Marcos did not think there would be a problem - "we're not puttin too much stuff in. at least, nothing that can clash on your works..." Derek "just gets nervous that we will be playing the reintroducing fixed bugs game i have seen in places ive worked" - he would rather all patches were applied to the central CVS tree, especially as the copyright assignment issues "i think will be resolved by weeks end" . For the future, "im not sure best answer going forward - as there was thought of giong to colonels like the linux kernel - i.e. limited cvs write access heads of state - and way to do things is submit patches for review and then colonel applies them if accepted. However there are many practical issues with that as far as resources go" .

4. Using the DCL e-mail gateway to accept tickets from other applications

24�Jul�2002�-�25�Jul�2002�Archive Link: "[IRC] 25 Jul 2002"

Topics: DCL

People: Marc Lovelace,�Jason Cater,�Derek Neighbors

Marc Lovelace (AnZaC) said he was "lookin' to find a way to use an outside php script to create trouble tickets through the DCL functionality.. that make sense? As in, I'd like to be able to pass in all the information required to the function.. and let DCL run with the ball..." Jason Cater (jcater) suggested "look at the email gateway - it does just that - err, I mean as an example of what to do" . Marc said he did not have root access, but Jason suggested "I imagine you could set up a fetchmail script that runs like every 10 or so minutes that fetches mail from an account and pipes it into - that wouldn't require root access" . This would involve setting up a .procmailrc and .forward file for the designated mail account. Marc thought "that might just work" , asking "any way I can set up the .forward file to ONLY forward email with XXXX in the subj?" Jason "thinks you'll need to use procmail for that" , giving a sample procmail file. Marc "got qmail sending the email over to procmail... got the .procmailrc filtering the mail as it comes in... now I'm just trying to find where it put it.."

The next day, Marc reported "got the gateway workin' somewhat w/o the MIME module..." Derek Neighbors (dneighbo) said "i would still encourage getting them to let you install the mime module" . Marc agreed, but asked "how I can get the BODY part of the message w/o the module" , just in case? He noted "The rest of the script works like a charm.. I'd just like to be able to have a little more information inserted in the DB for the Issue Description..." Jason was "sure there are some perl cpan modules you can grab that'll break apart the mime message" Marc said he did not have install rights on the box he was using - if he had, he would have installed the MIME module and solved the problem directly. Jason was "sure you can install cpan modules locally" . Derek said they had tried this, but, as Marc reported, it "gave me a root permissions problem" . Jason pointed to some information on the web about installing perl modules. Marc read the information and tried it out, but still could not "install it into the perl directory" . He concluded that his "best bet is to stand by and wait for the folks who own the box to give me a response on installing the MIME parser..." .

5. Using CVS or official releases on Microsoft Windows

25�Jul�2002�Archive Link: "[IRC] 26 Jul 2002"

Topics: Designer, Application Server, Forms

People: Carl Kigundu,�Andrew Mitchell,�Ariel Cal�

Carl Kigundu (clock) said he wanted "to use gnue on windows 2000 with mysql" . Andrew Mitchell (ajmitch) recommended "you should be fine with the 0.3.0 release - i've used gnue designer & forms on winXP with the mysql ODBC drivers (mysql on a GNU/Linux box)" . For initial familiarisation, he would prefer the 0.3.0 release over CVS, as "i don't know how usable cvs is at the moment, jcater has been working heavily on designer" , as referred to in Issue�#38, Section�#5� (11�Jul�2002:�Designer branched in CVS) . Alternatively, "you could install both in separate paths & compare them if you wanted" .

Carl asked "now if my code is in the gfd does this mean each form will have to open its connection to the db? isnt that expensive? anything I can do? wouldnt i have to write a connection server or plug something into apperver to serve requests?" Andrew said "only if you use appserver, i think" . Carl asked "i thought i call the forms from withing the triggers of other forms?" Ariel Cal� (ariel_) said "the issue of triggering other forms has been discussed" , pointing to Issue�#34, Section�#7� (12�Jun�2002:�Opening one form from within another) , saying "it is doable but not trivial right now" .

6. Primary keys in Forms and hand-editing GNUe Form Definitions (.gfd)

25�Jul�2002�-�28�Jul�2002�Archive Link: "[IRC] 26 Jul 2002"

Topics: Forms, Designer

People: Matthew Emmett,�James Thompson,�Jason Cater

Matthew Emmett (memmett) noted "when i was entering data into my "trip log" form that had a master/detail relationship, the "detail" wasn't picking up the new master id, so i had to continually press F8, F9, re-select the master i had just inserted, then enter the data for the detail... is there some magical thingy i'm missing? hmmm, i see some voodoo for "populating our primary key" in one of the examples... perhaps this is what i need?" James Thompson (jamest) confirmed "you'll have to use a trigger to pull the value - our backend doesn't reload the record data after commit so the primary key remains blank :( - this also causes issues with backend triggers altering data - the form doesn't reflect it" . He gave "a working example" , but felt "we really need to handle this better by default" . Matthew said "yeah that'd be nice. althought i guess the trick finding a robust way to get the id of the record one just inserted. MSAccess is totally broken in this regard, imo." Jason Cater (jcater) said "designer now autocreates those triggers if you drag from the Schema navigator - /me needs to update the Create new form wizard to do the same" .

Matthew said "ahh... well my luck with designer isn't so great, and editing the xml by hand is just so much fun! :)" James said that "before jcater created designer" , that had been the only way to do it, but "nobody liked hand editing the gfd files :)" . Matthew said "heh.. yeah the only annoying part is having to tweak the x's and y's. the great part about designer is that it produces clean xml, so that one can easily use their favorite text editor to quickly rename names="" or whatever." Jason said "that was a BIG requirement when I wrote designer the XML had to be editable - a lot of that stemmed from the fact that the first designer couldn't do much more than move stuff around" . James said even then "it was still a god send for widget placement - now it's almost a l33t development tool! ;)"

Some days later, Matthew reported "when i switch to a new master records (new as in, going to insert a new record) the detail remains as it was before i switched to the new record. I think it causing problems when i press F6" giving the log message. James explained "querys from a detail don't really work" as of time of writing - "it should be generating a popup saying it's not supported but it stopped doing that for some reason" .

7. Application Server planning

26�Jul�2002�Archive Link: "[IRC] 27 Jul 2002"

Topics: Application Server

People: Jan Ischebeck,�Christian Selig

Jan Ischebeck (siesel) said he had written "some notes about transaction support and locking. just need to add the stuff to _featuretest" This was, as of time of writing, "on a good old piece of paper :)" but an earlier version was at Christian Selig (sledge_) supposed "transactioning looks simpler that it is to code" . Jan agreed, adding "writing transaction deadlock detection will be much more difficult to do code than simple transactional locking :)" However, "there are many other small steps to go: f.e. appserver should read out a configuration file etc." Christian noted "since python 2.x, there is a module for that in the standard distribution" .

8. Visual Schema plug-in for Designer

26�Jul�2002�-�28�Jul�2002�Archive Link: "[IRC] 27 Jul 2002"

Topics: Designer

People: Christian Selig,�Jan Ischebeck,�Derek Neighbors,�Jason Cater

Christian Selig (sledge_) said he had "a very specific idea on how" the visual schema Designer plug-in for GNUe Designer (as previously discussed in Issue�#39, Section�#7� (18�Jul�2002:�GNUe Designer plug-in support) ) "should look like :)" . He suggested:

Jan agreed, but said "the last point is a bit problematic" as "I don't want to store the positions in the gsd." Christian agreed "saving them in .gsd is not nice, right." Jan said "that would mean, that you would need a seperate file for every gsd" - or else "have a position cache which safes the positions for the last 5 files" . Christian suggested "for the last "n" files, configurably :)" Jan suspected that Christian "would set it to 9999 or something like that :)" . Christian said "i don't know who told you rumors that i'd ever do that :)" . Alternatively, the application could try "automatic positioning?" - Jan suggested "depending on foreign key conections tables should be positioned in a way make it easy to look at" .

Jason Cater (jcater) said he "didn't intend on the first version of schema designer to be an ERD - /me was thinking ala access (grid table) - ERD to me would be a secondary window" . Jan suggested "Why not use display modes, i.e. you can switch between graphical or table view" ? Derek Neighbors (dneighbo) asked "can we keep things simple re schema editor in designer - and have REAL design sessions for the rest" . Jan was not keen on making it look too much like Microsoft Access. Derek Neighbors (dneighbo) said "i am not a huge access fan but in reality 90% of the business population uses access and knows how to use it" - being able to say "if you can use access you wont be too lost in GNUe Schema Editor" was "a HUGE factor" . However, "the goal of gnue is not access" , and "there are so many other parts of GNUe that need attention it seems silly to put too much effort early on into schema stuff - short of making it work" . Jason said "to me, having tables with lines connecting them to show foreign keys IS close enough to ERD to call it that" . He felt that a full graphical canvas for tables was "overkill for the time being" .

Christian said "there are two modes: editing the tables in grids, and visual display on a canvas - so, strategically, either visual display has to be left out or done right" . Jason agreed - "for the time being" just a "table designer" . Derek said he could "do some screen shots and such to better facilitate the discussion" . Jason felt that ""done right" is highly subjective - I threw away my ERD packages 3 years ago - because they are counter-productive - and once you move beyond a few tables, totally useless imho" although he "isn't arguing against such a tool in the future" . Christian felt that "personally, even with large databases, a visual designer and, more important, a way to print out the visual version :) is very helpful" . Jan agreed "that its quite complicated to work visually with more than 20 tables" .

Jan posted a screenshot of what "a visual editor could look like" . Derek warned "wx has been well not polite with drag/drop and mouse stuff - so it scares me to put too much effort (i do want something like what you are pasting very badly) - but im going best bang for buck to start with" . As of time of writing, "im concerned with BASIC single table creation/modification - i.e. im not against what you are proposing but i think its the 'second' step not the first one" . Initially he envisaged something more like this.

Some days later, Derek pointed to "a free tool (nasty ole java) that might be some inspiration for what you all would like to do with gnue schema stuff - it is very similar to pgadmin" . Jan said "I think the main goal of having a schema designer instead of f.e. pgaccess, is that you design a schema which will work on all databases which are supported by GNUe. I.e. it should be very easy to use, without providing too much db specific features i.e. if you just use GNUe tools for developing and creating your application you can move it from one type of database to another just with copying the data from one db to another - this is possibly a bit too optimistic, but I would like that :)" Both Jason and Derek felt this was an absolute requirement. Derek said "i dont think there is a good 'python' (xplatform) tool out there that we could just bolt on support for our schema stuff - or i would say lets go that route. I see GNUe as a real framework in that it shouldnt be a replacement to hardcore db management tools but certainly developers should be able to use the framework (so they dont have to learn something new and/or install more crap). I like it from the prospective of it should really help us a. increase power of python DBSIG b. increase functionality of our common dbdriver system :) - maybe someday Zope or such might even consider using it :)"

9. Application Server API and multi-language support

29�Jul�2002�Archive Link: "[IRC] 30 Jul 2002"

Topics: Application Server

People: Jan Ischebeck,�Andrew Mitchell,�Dan Kuykendall

Jan Ischebeck (sisel) said "it is important to split the API in different implementation levels:"

Andrew Mitchell (ajmitch) said "we should define remote calls to other implementations, for getting lists of methods, etc - since this should be able to work over multiple transports" . Jan agreed - "this would be a kind of introspection function which should be added to the API" . Andrew said that, with some thought, this could be done in most languages - "for C# i'll probably need to build proxy objects using Reflection.Emit, which outputs IL (sort of like meta-assembly)" - "with php - generate code & cache it" . "however for GNUe, since we have the beautiful python to use, it's much much simpler ;)" . For php (especially php GroupWare), Andrew said that Dan Kuykendall (Seek3r) had hinted that once version 1.0 was stabilised, "a more structured project will be born that makes the phpgwapi more accessible - apps will be composed of a backend & a frontend UI - so GNUe will be able to talk to the apps quite nicely" . Jan said he had "talked a bit about defining object types with seek3r."

10. Contact Management and extreme database normalisation

29�Jul�2002�Archive Link: "[IRC] 30 Jul 2002"

Topics: Forms, Customer Relations

People: Jan Ischebeck,�James Thompson,�Derek Neighbors

Jan Ischebeck (siesel) asked about "the status of that forms/samples/track/forms/contact_manager.gfd form?" James Thompson (jamest) said "that's a derek form that was created long ago - i think it still works but IIRC the pre-existing data model he had to wrap around was fugly" . Jan said "some parts are quite usable, but I can't test it, because the triggers are broken." It seemed to be using some old-style code, including using triggers to do nextRecord(). James said these were now done within the block rather than via triggers. The problem with the contact manager form was "IIRC that data was hyper-normalized just like you're taught in class - which doesn't work in the real world in most cases IMHO :)" and in this case had meant having to use a specially-written trigger to check data integrity before calling nextRecord().

Jan asked "jamest: at the moment GFBlock just expose gotoRecord, newRecord and clear, do you think that adding nextRecord, prevRecord, deleteRecord would break anything?" James said "it shouldn't as long as you use the arrays in there to extend the trigger namespace" .

Later, Derek Neighbors (dneighbo) noted "before you do too much work i had (as of a month ago a WORKING contact_manager.gfd file) just not in GNUe :) for some fsf stuff" . He tried to get access to it, but did not have all his ssh keys set up properly. He eventually found "a more up to date contact manager" file he had written - "im pretty sure a month or so ago it was working (er around 0.3.0) - i could swear the next/prev was working thne. I hope to work on this some tonight and then merge changes softly back into the samples directory" . Now that he had "got the LIST of copyright from youmans i will add the 'assignment' status back in" to the sample database, and also set this up for his own use to keep track of FSF copyright assignments for the GNUe project.

11. Navigator search path for Forms

29�Jul�2002�Archive Link: "[IRC] 30 Jul 2002"

Topics: Navigator, Forms

People: Andrew Mitchell,�Jan Ischebeck,�James Thompson

Andrew Mitchell (ajmitch) reported "i can open forms in the current dir with navigator if i do "./form.gfd" but not "form.gfd"" . Jan Ischebeck (siesel) said "if there is no ./ before form.gfd it looks for that file in ~/gnue/forms - there should be a setting for that in gnue.conf - but I think we should change it to search in local dir AND default forms path" . James agreed - "I could test new forms in the std navigator menu by just cd'ing to dir holding new forms and running std navigator" . Andrew changed the code and submitted it as a patch.

12. GNU Enterprise tools as an alternative application development environment to PHP

29�Jul�2002�Archive Link: "[IRC] 30 Jul 2002"

Topics: Why GNUe?, Financials (Accounting)

People: Jose Javier,�James Thompson

Jose Javier (josejavier) asked "i'm looking for a tool to make programs like accounting software, my question is, is gnuenterprise manure enough to do this kind of programs?" He quickly changed "manure=mature" but James Thompson (jamest) thought "you had it right the first time ;-)" He said "gnue could do accounting but it's very much a work in progress - i'd love to see you work with it but I don't want to give impression it'll be easy at this time - i'm sure you'll find things that are missing, need improved, etc, etc" . Jose said "i think this is a very interesting project, an i would like to contribute" He had been considering using PHP for his next major project "but gnuenterprise looks more interesting" .

13. Status of GNUe Applications

29�Jul�2002�Archive Link: "[IRC] 30 Jul 2002"

Topics: Application Server, DCL, Financials (Accounting), Bayonne, Forms, Reports

People: Reinhard M�ller,�Derek Neighbors

Reinhard M�ller (reinhard) said that "the actual packages are _way_ too early in development - what is quite usable now is the tools like forms, reports etc. however appserver is still at the very beginning of development - and the packages would heavily depend on a working appserver :)" . Derek Neighbors (dneighbo) said "we have three 'applications' that are somewhat functional that are getting converted to the framework" :

He clarified that NOLA was not actually part of GNUe, but "the GNUe team is porting NOLA to the GNUe Framework" and improving it - "then we will add GNUe Forms Screens for it - we are offerring the (somewhat massive changes back to noguska) - if they accept them (they seem willing at this point) it will be normal NOLA - other wise we will fork" .

He also noted that Application Server "works with forms now - its just not 'mature' - and the 'business logic' side of the fence probably is very immature but its being actively worked on by siesle and sledge (iirc)" . However, "im about to beat jcater up for some gruesome report loving soon and that will probably spur appserver development" .

14. Config for encoding in Reports and Forms

30�Jul�2002�Archive Link: "[IRC] 31 Jul 2002"

Topics: Reports, Forms, Common

People: Ariel Cal�,�Arturas Kriukovas,�Jan Ischebeck,�James Thompson

Ariel Cal� said that he had "a problem with the patch you introduced in (encoding) - grcvs does'nt run if the encoding variable is not in gnue. conf. Either: 1)give it a default value, 2) check if it is defined in gnue.conf, if not call in line 220 as pre-patch" . Arturas Kriukovas (Arturas) said that "when i first introduced 'formFontEncoding' in gnue.conf i also introduced default value - going to check it..." He confirmed "it has default value already (it is there more than for a month if i'm not mistakening) called formFontEncoding - default value should be iso8859-1" . Ariel said he was having problems with this in Reports. Jan Ischebeck (siesel) noted that it "seems like formFontEncoding is defined in section forms, but not defined in section reports - if you start up reports it uses "section reports" as default section, i.e. you can't access formFontEncoding (see:" . Arturas suggested "would it be good if i add check whether encoding is set - and if not would set it to 'iso8859-1'?" . Jan suggested "a much cleaner solution would to add a [gnue] section to the config file" . James Thompson (jamest) agreed - "i think I started work on this but didn't finish" . He "was wanting a global [gnue] section that std gconfig reads first then merges in the specific [forms] [reports] etc - so that a person could override specific global settings in certain apps" . In terms of the code base, "I'd think it should be moved into a generic one in common - i _think_" . Ariel suggested that "[common] is a better name than [gnue]" .

15. Walk-through on installing and running GNU Enterprise

30�Jul�2002�Archive Link: "[IRC] 31 Jul 2002"

Topics: Forms

People: Stuart Bain,�Derek Neighbors

Stuart Bain (stbain) said "I'm on a RHL7.3 box now, what do I need to get up and running w/ the latest and greatest?" Derek Neighbors (dneighbo) said that "the major components are python 2.x (preferably 2.1), wxPython and a database (Postgres, MySQL, SAP-DB). Most of the other dependencies have started to go away. If you want to do reports you will probably want to pick up Sablotron and PySablot. Oh and you will need the python driver for whichever db you choose. I like to get wx and python first to verify a normal form works - then grab db set it up - then get its driver test a db form - then move on to swearing at reports :)"

Stuart confirmed "I have wxPython RPM installed - should I grab the CVS snapshot?" Derek said yes - "un tar it somewhere - then in gnue/ run and answer questions to your liking (i pretty much just hit enter (i.e. take defaults)) but certainly you can do as you like - the defaults put everything in your home dir (which makes nice for clean up later)) or running cvs in conjunction with stable" .

Stuart set up postgres, and Derek suggesed "go to gnue/forms/samples/intro/ and run the intro.gfd" . Stuart reported an error - "This GNUe tool requires mxDateTime to be installed" . Derek said "grrrr - i forgot about that" . Stuart confirmed the error message suggested an URL to collect the dependency, which he installed and reported "intro form is up and running" . Derek asked "do you have postgres running? if so do you ahve an databases? if so do you ahve any tables in the database if so do they have any data :) and do you have a postgres python driver" ? Sturt said he had the "postgresql-python-7.2.1-5.i386.rpm" driver. Derek said that Stuart would have to edit his connections.conf file to alter the gnue database connection from psycopg to postgresql - "then go to gnue/forms/samples/zipcode/ - do a psql gnue then inside psql do \i pg_zip_code.sql " . He added "after that loads do a ~/bin/gfcvs zipcode.gfd and see if things work" . He confirmed Stuart would have to set a user up within postgresql.

Stuart did this, but got a message "Error: Driver not installed: pygresql for PostgreSQL [No module named pgdb] - I must have missed something somwhere" . After some digging, Stuart checked "if the postgresql-python RPM has the files we're looking for" . Derek warned "on redhat they have 1.5 and 2.x" versions of python. Stuart confirmed this was the problem - "postgresql-python - /usr/lib/python1.5/site-packages/" . He had had similar problems with Red Hat before - "apparently they haven't noticed that the rest of the world is moving on without python 1.5.2" . He found "postgresql-python-7.2.1-14.i386.rpm" - "after a --nodeps install - it works - prompts me for a login - then promptly crashes" . Derek said "rerun it - i think some 'themes' dont play nicely - i.e. i have seen this on mor ethan on occasion - and simply relaunching makes problem go away" .

Stuart confirmed "ok... now I have a bunch of blank fields - city, state, zip" . Derek suggested "hit the prepare query button on tool bar then hit execute query button - or use the function keys or menus" . Nothing was coming up in the zip code form, so Derek suggested "ok shut it down and run states.gfd instead - then on login run f8/f9" . Stuart reported "I have a list of hte states - the states were populated in the zipcodes.gfd dropdown selection box as well" . Derek confirmed "if you are getting data loaded when you run states.gfd - then you are workign :) - you have a workign GNUe System - /me runs before you try to really use it and ask real hard questions" .

Stuart asked "ok - so where do I download accessmdb2gnuegfd - lol" . Derek said "in all seriousness - go to - download that application (runs only on windows) and download the access migration tool - this tool will provide mechanism to convert all tables/indexes/keys etc from access into postgres which is half the battle. At which point with some effort you could then rebind their existing access screens/forms to use postgres tables - then you start on the conversion of access forms to gnue forms :) We have no 'direct' migration tool for that part, but it should be fairly easy using our 'wizards' in designer since the 'structures' exist" .

16. Preparing for Linux World Expo in San Fransisco

30�Jul�2002�Archive Link: "[IRC] 31 Jul 2002"

People: Derek Neighbors,�Jason Cater,�David Sugar

Derek Neighbors (dneighbo) asked "how are the marketing items coming /me is hoping we will have somethign by friday?" Jason Cater said "/me will try to show you what I have tonight" . Derek said he was not heading off to Linux World Expo early, "just next week will be hectic so im hoping that this weekend or monday maybe can get stuff to printer (or if you are printing suppose it doesnt matter as long as it drops before next friday) :)" Jason said it "may work better for me" for him to print them and ship direct to San Fransisco. Derek said "i just have very little left of old stuff so will need something for the show and would rather not make copies of what we had :) i.e. we need more effective marketing. I also need to get our sample applications and such up and running on my laptop. I want to demonstrate schema stuff as well i.e. create a db schema - push button and now its mysql and postgres. I also want to get sapdb installed and functioning well. /me pulls hair out, so much to do so little time" .

Later, Derek asked David Sugar (dyfet) about demonstrating "gnucomm/bayonne in gnue booth - i would love to get some stuff working - you have any samples that write to a database? preferablly postgres" . David said he did not "know what type of demo rich had in mind to setup." Derek said he would "love to make some forms to interact with it - to show not so much 'integration' but combination" . David agreed - "In fact, I want to do a model gnu enterprise "debit calling" system with the debit card accounts managed thru gnue forms."

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.