From t.schreiner at gmx.de Mon Nov 3 22:32:01 2003 From: t.schreiner at gmx.de (Thomas Schreiner) Date: Mon, 03 Nov 2003 12:32:01 +0100 Subject: [albatross-users] Problem running al-session-daemon Message-ID: <3FA63CB1.9060201@gmx.de> Hi, I have problems starting the session-deamon. When I try to start it, i get the following traceback: [thomas at pooka session-server]$ ./al-session-daemon start Traceback (most recent call last): File "./al-session-daemon", line 26, in ? from albatross import simpleserver File "/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/site-packages/albatross/__init__.py", line 9, in ? from albatross.context import * File "/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/site-packages/albatross/context.py", line 12, in ? import cPickle ImportError: /usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/lib-dynload/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String the same error occurs when I try to do ./al-session-daemon --help objdump -x tells me that there is a PyUnicodeUCS2_AsUTF8String in the correct cPickle.so but there are more than one python versions installed and not all of them have PyUnicodeUCS2_AsUTF8String in cPickle I am using RedHat 9 and tried albatross 1.10 and 1.11pre2 I am very new to Python and Albatross and new to Linux, so if missed something obvious please forgive me. any help is appreciated thanks, Thomas From andrewm at object-craft.com.au Tue Nov 4 10:14:42 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 04 Nov 2003 10:14:42 +1100 Subject: [albatross-users] Problem running al-session-daemon In-Reply-To: Message from Thomas Schreiner of "Mon, 03 Nov 2003 12:32:01 BST." <3FA63CB1.9060201@gmx.de> References: <3FA63CB1.9060201@gmx.de> Message-ID: <20031103231442.8444E3C1F5@coffee.object-craft.com.au> >ImportError: >/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/lib-dynload/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String > >objdump -x tells me that there is a PyUnicodeUCS2_AsUTF8String in the >correct cPickle.so but there are more than one python versions installed >and not all of them have PyUnicodeUCS2_AsUTF8String in cPickle > >I am using RedHat 9 and tried albatross 1.10 and 1.11pre2 >I am very new to Python and Albatross and new to Linux, so if missed >something obvious please forgive me. This looks like a problem with your python installation (rather than with albatross). If you're using a RH package, maybe you're missing an optional extra (maybe RH have broken the unicode support out into an add-on package)? Generally I like to build my own python anyway - it should be quite painless on RH - download the python-2.3.2 tar file, unpack it, run configure, then "make install" as root. The new python interpreter will be installed under /usr/local/bin (and /usr/local/lib/python2.3). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From t.schreiner at gmx.de Tue Nov 4 20:56:59 2003 From: t.schreiner at gmx.de (Thomas Schreiner) Date: Tue, 04 Nov 2003 10:56:59 +0100 Subject: [albatross-users] Problem running al-session-daemon In-Reply-To: <20031103231442.8444E3C1F5@coffee.object-craft.com.au> References: <3FA63CB1.9060201@gmx.de> <20031103231442.8444E3C1F5@coffee.object-craft.com.au> Message-ID: <3FA777EB.8080103@gmx.de> Andrew McNamara wrote: >>ImportError: >>/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/lib-dynload/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String >> >>objdump -x tells me that there is a PyUnicodeUCS2_AsUTF8String in the >>correct cPickle.so but there are more than one python versions installed >>and not all of them have PyUnicodeUCS2_AsUTF8String in cPickle >> >>I am using RedHat 9 and tried albatross 1.10 and 1.11pre2 >>I am very new to Python and Albatross and new to Linux, so if missed >>something obvious please forgive me. > > > This looks like a problem with your python installation (rather than > with albatross). If you're using a RH package, maybe you're missing an > optional extra (maybe RH have broken the unicode support out into an > add-on package)? > > Generally I like to build my own python anyway - it should be quite > painless on RH - download the python-2.3.2 tar file, unpack it, run > configure, then "make install" as root. The new python interpreter will > be installed under /usr/local/bin (and /usr/local/lib/python2.3). Problem soled. I was starting the deamon in the directory where I Downloaded albatross. During the installation of python I found out that there was a copy of the sesseion-server-daemon in pythons bin directory. When starting this one everything works. Thanks for your help, Thomas From t.schreiner at gmx.de Wed Nov 5 04:00:19 2003 From: t.schreiner at gmx.de (Thomas Schreiner) Date: Tue, 04 Nov 2003 18:00:19 +0100 Subject: [albatross-users] apache does not find albatross module Message-ID: <3FA7DB23.2040402@gmx.de> Hi, when going through the samples of albatross i got stuck with sample 2. I don't know how to configure apache to find albatross. the following is from the apache error_log. [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] Premature end of script headers: simple.py [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] Traceback (most recent call last): [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] File "/usr/local/FreeGee-v1.0/Server/Apache-2.0.43/cgi-bin/alsamp/simple2/simple.py", line 2, in ? [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] from albatross import SimpleContext [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] ImportError: No module named albatross thanks in advance Thomas From skytteren at netcom.no Wed Nov 5 08:23:51 2003 From: skytteren at netcom.no (skytteren at netcom.no) Date: Tue, 04 Nov 2003 22:23:51 +0100 Subject: [albatross-users] States... how to go around... Message-ID: <1021c11030dd.1030dd1021c1@netcom.no> Hi!!! I got a problem with "going around" mye albatross webpage. The problem i quite simple: I go into one page, does something and are sent to another page... Of course, I did something wrong and wants to go back with my "Back" button in my browser. It looks like I go back, but the server gives me all the functinality of the second page (it looks like I'm still in the second page, but se the first page)... What do i need to do to get this working proparly... I use : class AppContext(SessionAppContext): def __init__(self, app): SessionAppContext.__init__(self, app) and py_mod's! There's also another problem: How do i know what Node class I've "clicked" in a al-tree??? Here is som of the code that I find relevant: def page_enter(ctx): ctx.locals.debug = "" ctx.add_session_vars('debug') if ctx.locals.debug == "": e = Exercise() ctx.locals.exercise = e ctx.add_session_vars('exercise') def page_process(ctx): if ctx.req_equals('cancel'): ctx.locals.creating_exercise = False ctx.set_page('main') elif ctx.req_equals('create_problem'): ctx.locals.exercise_problemset = get_problemset (ctx.locals.exercise, ctx.locals.create_problem, ctx) if ctx.locals.exercise_problemset != None: ctx.locals.problemstate='exercise' ctx.add_session_vars('problemstate') ctx.add_session_vars('exercise_problemset') ctx.set_page('problem_creation') elif ctx.req_equals('insert_problem'): ctx.locals.exercise_problemset = get_problemset (ctx.locals.exercise, ctx.locals.insert_problem, ctx) if ctx.locals.exercise_problemset != None: ctx.locals.creating_exercise = True ctx.add_session_vars('exercise_problemset') ctx.add_session_vars('creating_exercise') ctx.set_page('problems') elif ctx.req_equals('remove_problem'): pass #elif ctx.req_equals('edit'): elif ctx.req_equals('insert_composite_problem'): ctx.locals.exercise_problemset = get_problemset (ctx.locals.exercise, ctx.locals.insert_composite_problem, ctx) if ctx.locals.exercise_problemset != None: ps = ProblemSet() ctx.locals.exercise_problemset.children.append(ps) def get_problemset(problemset, problemsetid, ctx): ctx.locals.debug += "Problemset: " + str(problemset) ctx.locals.debug += "ProblemsetID: " + problemsetid if str(problemset) == problemsetid and problemset.type != 'p': return problemset elif problemset.type != 'p': for ps in problemset.children: potensiell = get_problemset(ps, problemsetid, ctx) if potensiell is not None: return potensiell else: return None .... Create problem  Insert problem  Insert composite problem .... If there are anyone that know how to solv these problems or now where I can look please help me.. :) Stein K. Skytteren Trondheim, Norway From gnb at itga.com.au Wed Nov 5 09:11:49 2003 From: gnb at itga.com.au (Gregory Bond) Date: Wed, 05 Nov 2003 09:11:49 +1100 Subject: [albatross-users] States... how to go around... In-Reply-To: Your message of Tue, 04 Nov 2003 22:23:51 +0100. Message-ID: <200311042211.JAA22501@lightning.itga.com.au> > Of course, I did something wrong and wants to go back with my "Back" > button in my browser. It looks like I go back, but the server gives me > all the functinality of the second page (it looks like I'm still in the > second page, but se the first page)... What do i need to do to get this > working proparly... Short answer - you can't. This is a problem of the whole WWW architecture and server-side sessions, not of albatross or any other toolkit. The Back button on the browser is local only - it redisplays the previous page but never tells the server that it has happened. So the server state still thinks you are on the new page, so you get the sort of problems you see. Using client-side sessions will not have this problem (as bad... other problems still crop up though) The answer for me was to teach the users "don't use the back button" and make sure the application had lots of good nav functionality so the back button wasn't needed. Easy for me, when the number of users can be counted on one hand, not so easy if you have lots of users! With a bit of work in javascript it is apparently also possible to remove the back button, but I didn't bother with that. From djc at object-craft.com.au Wed Nov 5 09:30:22 2003 From: djc at object-craft.com.au (Dave Cole) Date: Wed, 05 Nov 2003 09:30:22 +1100 Subject: [albatross-users] apache does not find albatross module In-Reply-To: <3FA7DB23.2040402@gmx.de> References: <3FA7DB23.2040402@gmx.de> Message-ID: <1067985021.30535.0.camel@echidna.object-craft.com.au> On Wed, 2003-11-05 at 04:00, Thomas Schreiner wrote: > Hi, > > when going through the samples of albatross i got stuck with sample 2. I > don't know how to configure apache to find albatross. the following is > from the apache error_log. > > [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] Premature end of > script headers: simple.py > [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] Traceback (most > recent call last): > [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] File > "/usr/local/FreeGee-v1.0/Server/Apache-2.0.43/cgi-bin/alsamp/simple2/simple.py", > line 2, in ? > [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] from albatross > import SimpleContext > [Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] ImportError: No > module named albatross Are you able to import albatross when using Python in interactive mode? - Dave -- http://www.object-craft.com.au From t.schreiner at gmx.de Wed Nov 5 18:50:49 2003 From: t.schreiner at gmx.de (Thomas Schreiner) Date: Wed, 05 Nov 2003 08:50:49 +0100 Subject: [albatross-users] apache does not find albatross module In-Reply-To: <1067985021.30535.0.camel@echidna.object-craft.com.au> References: <3FA7DB23.2040402@gmx.de> <1067985021.30535.0.camel@echidna.object-craft.com.au> Message-ID: <3FA8ABD9.5020002@gmx.de> Dave Cole wrote: > On Wed, 2003-11-05 at 04:00, Thomas Schreiner wrote: > >>Hi, >> >>when going through the samples of albatross i got stuck with sample 2. I >>don't know how to configure apache to find albatross. the following is >>from the apache error_log. >> >>[Tue Nov 04 17:57:25 2003] [error] [client 127.0.0.1] ImportError: No >>module named albatross > > > Are you able to import albatross when using Python in interactive mode? Kind of. I can import it, but get a different error message where python is complainig about not finding some unicode stuff in cPickle.so. Traceback (most recent call last): File "./albatross-test.py", line 3, in ? import albatross File "/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/site-packages/albatross/__init__.py", line 9, in ? from albatross.context import * File "/usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/site-packages/albatross/context.py", line 12, in ? import cPickle ImportError: /usr/local/FreeGee-v1.0/Core/Python-2.2.2/lib/python2.2/lib-dynload/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String Thomas From fabbe at paniq.net Thu Nov 6 23:27:07 2003 From: fabbe at paniq.net (Fabian Fagerholm) Date: Thu, 06 Nov 2003 14:27:07 +0200 Subject: [albatross-users] Build failure with python 2.3: test failure Message-ID: <1068121627.821.121.camel@kernel> Hi! I'm progressing on my Debian packaging of Albatross. Apart from the unsolved issue of documentation generation previously discussed on this list and in private mail, I have one remaining issue before the package is fit for introduction in Debian unstable (not counting issues not yet discovered, of course): The test suite fails 10 of 61 tests when running with python 2.3. The relevant part of the build log is attached. The first class of errors is clear: the test expects the boolean values true and false to be represented as 1 and 0, respectively, but the python 2.3 interpreter outputs them as "True" and "False". This is because python 2.3 introduced a boolean type, whereas earlier versions relied on the C-style convention of using integers for boolean operations. Related documentation: http://www.python.org/doc/2.3/whatsnew/section-bool.html http://www.python.org/2.3.2/NEWS.html The other class of errors seems to be related to hashing or object pickling; the test expects a certain character sequence as "value" attribute in the hidden tag named "__albform__", but the python 2.2 interpreter in Debian sid produces a different, and slightly longer sequence. Related documentation: http://www.python.org/doc/2.3/whatsnew/section-pep305.html http://www.python.org/2.3.2/NEWS.html I might drop building for python2.3 in the first version of the package, but on the other hand, it would make sense to fix it right from the start. Perhaps the test could be made more dynamic by generating the expected results with the python interpreter before running the actual tests? I assume that a prerequisite for the tests is a working python interpreter? Opinions, suggestions? -- Fabian Fagerholm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From djc at object-craft.com.au Fri Nov 7 11:04:56 2003 From: djc at object-craft.com.au (Dave Cole) Date: Fri, 07 Nov 2003 11:04:56 +1100 Subject: [albatross-users] Re: Build failure with python 2.3: test failure In-Reply-To: <1068121627.821.121.camel@kernel> References: <1068121627.821.121.camel@kernel> Message-ID: <1068163496.3618.18.camel@echidna.object-craft.com.au> On Thu, 2003-11-06 at 23:27, Fabian Fagerholm wrote: > Hi! > > I'm progressing on my Debian packaging of Albatross. Apart from the > unsolved issue of documentation generation previously discussed on this > list and in private mail, I have one remaining issue before the package > is fit for introduction in Debian unstable (not counting issues not yet > discovered, of course): > > The test suite fails 10 of 61 tests when running with python 2.3. > The relevant part of the build log is attached. > > > The first class of errors is clear: the test expects the boolean values > true and false to be represented as 1 and 0, respectively, but the > python 2.3 interpreter outputs them as "True" and "False". This is > because python 2.3 introduced a boolean type, whereas earlier versions > relied on the C-style convention of using integers for boolean > operations. All of those failures are in a class of tests that would be quite ugly and difficult to fix. All of the tests in the doctest/ directory are interactive examples that are used in the documentation. The idea is that by using the interactive examples as part of the test suite we can be sure that the documentation is always correct (at least as far as examples are concerned). The only way I can see that we can fix these would require that we either respectively redefine True and False to 1 and 0, or postprocess the results of the test (very flakey). > The other class of errors seems to be related to hashing or object > pickling; the test expects a certain character sequence as "value" > attribute in the hidden tag named "__albform__", but the python 2.2 > interpreter in Debian sid produces a different, and slightly longer > sequence. I am even less sure how we might fix these for multiple versions of Python. Maybe we could change the tests so they never display the results of a pickle? > Related documentation: > http://www.python.org/doc/2.3/whatsnew/section-pep305.html > http://www.python.org/2.3.2/NEWS.html > > > I might drop building for python2.3 in the first version of the package, > but on the other hand, it would make sense to fix it right from the > start. > > Perhaps the test could be made more dynamic by generating the expected > results with the python interpreter before running the actual tests? I > assume that a prerequisite for the tests is a working python > interpreter? Yup. Hmm... Maybe your suggestion would work. Maybe we could create some of the doctest files as part of the build process. This would mean that all pickle and repr strings would match the version of Python being used to install Albatross. It makes me a little scared in that it has the potential to make things more flakey. - Dave -- http://www.object-craft.com.au From tfheen at raw.no Mon Nov 10 10:34:59 2003 From: tfheen at raw.no (Tollef Fog Heen) Date: Mon, 10 Nov 2003 00:34:59 +0100 Subject: [albatross-users] Bug with persistentlists and such (1.10) Message-ID: <87y8upundo.fsf@yiwaz.raw.no> (please Cc me, I'm not on the list) It seems like checkbox_to_html in 1.10 has a bug if you try to give it something which isn't a python list (but looks, walks and talks like one). IMHO, a better way to test for whether this is a list is just to try to use map, and if that fails, use str on the value itself; see below. def checkbox_to_html(self, ctx): self.write_attribs_except(ctx, 'value', 'checked') name, value, value_attr = self.get_name_value_checked(ctx, 'on') if value and self.has_attrib('treeselect'): value = 'on' ctx.write_content(' name="%s"' % name) ctx.write_content(' value="%s"' % value_attr) try: if str(value_attr) in map(str, value): ctx.write_content(' checked') except TypeError: if str(value) and str(value) == str(value_attr): ctx.write_content(' checked') if not self.has_attrib('disabled'): ctx.input_add('checkbox', name, value_attr, self.has_attrib('list')\ ) -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From neel at mediapulse.com Tue Nov 11 10:43:23 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 10 Nov 2003 18:43:23 -0500 Subject: [albatross-users] Bug with persistentlists and such (1.10) Message-ID: Doesn't map imply a function call for every element of the list? A bit high on the overhead don't you think for a type check? I'm not sure how it checks now, but a test of "isinstance(val, list)" will catch lists and classes built from list. Mike > > (please Cc me, I'm not on the list) > > It seems like checkbox_to_html in 1.10 has a bug if you try to give it > something which isn't a python list (but looks, walks and talks like > one). IMHO, a better way to test for whether this is a list is just > to try to use map, and if that fails, use str on the value itself; see > below. > From neel at mediapulse.com Wed Nov 12 06:29:41 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Tue, 11 Nov 2003 14:29:41 -0500 Subject: [albatross-users] Bug with persistentlists and such (1.10) Message-ID: > | Doesn't map imply a function call for every element of the list? > > If it is has a list interface, then yes. But if it has a list > interface, we want to do that anyhow. Look at what the code does: > > try: > if str(value_attr) in map(str, value): > ctx.write_content(' checked') > [handle exception] > > Compare this with the original code: > > if type(value) in (type([]), type(())): > if str(value_attr) in map(str, value): > ctx.write_content(' checked') > > As you can see, it still does the same thing, and map will fail on > objects which doesn't have a list interface. If they _do_ have a list > interface, it's desirable that expr does work as expected. If it > looks like a list, walks like a list and talks like a list, then it is > a list. But strings *do* have a list interface. Consider: >>> test = "testme" >>> test[2] 's' >>> map(str, test) ['t', 'e', 's', 't', 'm', 'e'] So while the odds are low that when value is a string it will match, we still ran a function call for every item (in this case the letters). > | A bit high on the overhead don't you think for a type check? > > Doing an interface check instead of type check? And doing it in C > instead of Python (map is C)? No, that's lower overhead, not higher. > Skipping the string error for a second, in this case we are going to map anyway so there wouldn't be harm - but if you are type checking with map and don't need the output of map, like you just want to get a len(), then we just called str() on every element of the list. It's this function call I mean when I say overhead, not map itself. > | I'm not sure how it checks now, but a test of "isinstance(val, > | list)" will catch lists and classes built from list. > > What do you mean by ? List is a native type, > it's not a class, so you can't inherit from it. > Welcome to python 2.3, it's not your father's python: >>> class MyList(list): ... pass ... >>> lst = MyList() >>> lst [] >>> lst.append(2) >>> lst.append(3) >>> lst.append(4) >>> lst [2, 3, 4] >>> type(lst) >>> isinstance(lst, list) True From tfheen at raw.no Wed Nov 12 04:03:54 2003 From: tfheen at raw.no (Tollef Fog Heen) Date: Tue, 11 Nov 2003 18:03:54 +0100 Subject: [albatross-users] Bug with persistentlists and such (1.10) In-Reply-To: (Michael C. Neel's message of "Mon, 10 Nov 2003 18:43:23 -0500") References: Message-ID: <87ekwe25xh.fsf@yiwaz.raw.no> * "Michael C. Neel" | Doesn't map imply a function call for every element of the list? If it is has a list interface, then yes. But if it has a list interface, we want to do that anyhow. Look at what the code does: try: if str(value_attr) in map(str, value): ctx.write_content(' checked') [handle exception] Compare this with the original code: if type(value) in (type([]), type(())): if str(value_attr) in map(str, value): ctx.write_content(' checked') As you can see, it still does the same thing, and map will fail on objects which doesn't have a list interface. If they _do_ have a list interface, it's desirable that expr does work as expected. If it looks like a list, walks like a list and talks like a list, then it is a list. | A bit high on the overhead don't you think for a type check? Doing an interface check instead of type check? And doing it in C instead of Python (map is C)? No, that's lower overhead, not higher. | I'm not sure how it checks now, but a test of "isinstance(val, | list)" will catch lists and classes built from list. What do you mean by ?classes built from list?? List is a native type, it's not a class, so you can't inherit from it. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- From pmoermans at linuxmail.org Tue Nov 18 02:33:38 2003 From: pmoermans at linuxmail.org (Pierre Moermans) Date: Mon, 17 Nov 2003 16:33:38 +0100 Subject: [albatross-users] Hello, When using hyperlinks for page change, I get different results using version 1.10 and 1.11 of Alabatross: I have a page "first.py" (please see below). The corresponding html page contains the following code: Add When pressing the Add link, with version 1.10, I get forwarded as I expected to the "add_image" page, but with version 1.11, I get back to the page "http://localhost/imghot/login.py.add_image=1", which is the index page of the imghost directory. As I haven't seen any change concerning the al-a tag in the changelog from 1.10 -> 1.11, I wondered if I missed something or if this would be a bug. If I missed something, how can I achieve the same result using the newest release? Can anybody help me out ? Thanks! -------------- file first.py: def page_process(ctx): if ctx.req_equals('add_image'): ctx.set_page('add_image') def page_display(ctx): ctx.run_template('first.html') -------------- From fabbe at paniq.net Wed Nov 19 08:52:56 2003 From: fabbe at paniq.net (Fabian Fagerholm) Date: Tue, 18 Nov 2003 23:52:56 +0200 Subject: [albatross-users] Re: Build failure with python 2.3: test failure In-Reply-To: <1068163496.3618.18.camel@echidna.object-craft.com.au> References: <1068121627.821.121.camel@kernel> <1068163496.3618.18.camel@echidna.object-craft.com.au> Message-ID: <1069192374.1668.161.camel@kernel> First, apologies for the delay; at the moment, this is my average response time. I hope to reduce it in the future without the sacrifice of sleep. On Fri, 2003-11-07 at 02:04, Dave Cole wrote: > All of those failures are in a class of tests that would be quite ugly > and difficult to fix. Not neccessarily: I have a fix now that was not difficult to implement, and given a little more time, I could reduce its ugliness to an acceptable level. Given even more time, I could actually make it quite nice to look at. > The only way I can see that we can fix these would require that we > either respectively redefine True and False to 1 and 0, or postprocess > the results of the test (very flakey). I have taken another approach: preprocessing template test fragments into real test fragments according to build-time python version detection. I will elaborate below. > Hmm... Maybe your suggestion would work. Maybe we could create some of > the doctest files as part of the build process. This would mean that > all pickle and repr strings would match the version of Python being used > to install Albatross. I think you are absolutely right in stating that the build process is the place to do this. My solution works as follows: * The test fragment files are renamed to have a suffix of .in, becoming templates for the real files, and the critical parts are modified as follows: * The textual representations for true and false are converted to __xTRUEx__ and __xFALSEx__, respectively. * In the file tags-for7.in, the columns are reordered so that the boolean values appear last. Also, the values in these last two columns are always printed with exactly one space as separator. This is neccessary because the length of repr strings for booleans is variable (eg. 0 versus False). * There are two different pickles; these are replaced by __xPICKLE1x__ and __xPICKLE2x__, respectively. * doc/test_examples.py is modified to ignore the .in files (line 144). * A new shell script, doctest_preprocess, is introduced in the doc directory. It uses the python interpreter to determine the current python version and substitutes the special values in the test fragment template files with the appropriate values for that version, generating the real test fragment files. * The Makefile is modified in two ways: * The test target depends on the version target. * The version target runs the doctest_preprocess script. > It makes me a little scared in that it has the potential to make things > more flakey. Since this solution still uses only hardcoded strings, I think little can go wrong that would not cause the tests to fail, making the build fail, alerting the user. The solution can accommodate for many more differences among python interpreters. I have only solved the issue for python 2.2 and 2.3, because I do not intend to support 2.1 in the Debian packages. However, I think this is not the optimal solution. A better solution would be to rewrite the doctest_preprocess script in python, reducing clutter and making the build process more consistent. An even more elegant solution would be to merge the functionality of that script into doc/test_examples.py. Two approaches could be taken: the first would be to still use hardcoded strings but read them from eg. doc/doctest/version_strings-x.y.py, where x.y would be the python version and the file would define a dictionary of substitution strings. Every substring of the .in files matching the regexp (__x.+x__) would be replaced with the corresponding dictionary element. The other approach would be to generate the strings at runtime. I will apply this temporary fix to the Debian packages, even though it does not aesthetically please me. I consider this fix merely a workaround for the packages. Therefore, I will not include any patches in this message. I don't want to see this solution in the original version. :) Instead, I intend to modify your build scripts so that they are more general. The Debian package currently has a meaty .diff which changes lots of small things that I think you'd be happy to change in the original version. (Other things I'm not so sure about; you definitely don't want to hear what I'm forced to do to make dia run even when there is no $DISPLAY available... ;) In any case, you can expect some patches for this and other build issues in the future. If there's something you'd like me to consider, or some part you'd like to modify yourself, then I'll be happy to continue this discussion! Cheers, -- Fabian Fagerholm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fabbe at paniq.net Fri Nov 21 09:05:15 2003 From: fabbe at paniq.net (Fabian Fagerholm) Date: Fri, 21 Nov 2003 00:05:15 +0200 Subject: [albatross-users] Including EPS files in source tarball Message-ID: <1069365606.1600.74.camel@kernel> Hello, My attempts to make the Albatross documentation build with the requirements set by the Debian packaging have failed. Albatross is not at fault; the culprit is Dia, which won't run unless it has a $DISPLAY. Thus, the Albatross UML diagrams can't be created as part of the build process. The Debian package can under no circumstances assume a $DISPLAY is available. The Debian autobuilders do not provide one, and pbuilder, which is used to ensure that the packaging works in Debian unstable, does not provide one. I have tried using Xvfb to work around this, but it doesn't work with the package build process. Therefore, I will drop the building of Albatross documentation. I am considering a separate -doc package in which your pre-packaged documentation would be debianized. There is, however, another option. If you would include the EPS files exported from Dia in the source tarball, all problems would be solved. I probably don't have to make an argument for why Dia is bad; this has been expressed already. Perhaps I must convince you that including the EPS files would be good. My arguments follow. Including the EPS files in the source tarball would be good because: * It benefits users of the Debian package, since building the documentation as part of the entire build process ensures the documentation corresponds to the Albatross version. The introduction of a new Albatross package would see all packages updated at once. There is no risk of mistake or delays due to a separate source package. * It benefits users of the Debian package, since the tests performed on the documentation during the build helps ensure that the examples in the documentation work with the Python version used in Debian. * It benefits users who cannot use Dia to build the documentation, but who don't want to download the separate documentation. * It would benefit those who package Albatross for other systems. The downside would be a considerably larger tarball. If Dia is ever fixed, all of this would go away, of course. What do you think? Cheers, -- Fabian Fagerholm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andrewm at object-craft.com.au Fri Nov 21 09:28:02 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 21 Nov 2003 09:28:02 +1100 Subject: [albatross-users] Re: Including EPS files in source tarball In-Reply-To: Message from Fabian Fagerholm of "Fri, 21 Nov 2003 00:05:15 +0200." <1069365606.1600.74.camel@kernel> References: <1069365606.1600.74.camel@kernel> Message-ID: <20031120222802.89FE93C9A8@coffee.object-craft.com.au> >I probably don't have to make an argument for why Dia is bad; this has >been expressed already. Perhaps I must convince you that including the >EPS files would be good. My arguments follow. > >Including the EPS files in the source tarball would be good because: > > * It benefits users of the Debian package, since building the > documentation as part of the entire build process ensures the > documentation corresponds to the Albatross version. The > introduction of a new Albatross package would see all packages > updated at once. There is no risk of mistake or delays due to a > separate source package. > * It benefits users of the Debian package, since the tests > performed on the documentation during the build helps ensure > that the examples in the documentation work with the Python > version used in Debian. > * It benefits users who cannot use Dia to build the documentation, > but who don't want to download the separate documentation. > * It would benefit those who package Albatross for other systems. > >The downside would be a considerably larger tarball. If Dia is ever >fixed, all of this would go away, of course. I think I liked your previous suggestion - a separate "albatross-doc" package. In fact, maybe there should be an "albatross-doc-html" and an "albatross-doc-pdf" package? (But that sounds like a lot of work). This will allow people to install just what they want - the docs can be installed on their corporate intranet server, the albatross module and nothing else could be installed on bastions, etc. Failing that, including the eps files sounds like a good idea. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Fri Nov 21 10:14:11 2003 From: djc at object-craft.com.au (Dave Cole) Date: Fri, 21 Nov 2003 10:14:11 +1100 Subject: [albatross-users] Re: Including EPS files in source tarball In-Reply-To: <20031120222802.89FE93C9A8@coffee.object-craft.com.au> References: <1069365606.1600.74.camel@kernel> <20031120222802.89FE93C9A8@coffee.object-craft.com.au> Message-ID: <1069370051.31388.10.camel@echidna.object-craft.com.au> On Fri, 2003-11-21 at 09:28, Andrew McNamara wrote: > >I probably don't have to make an argument for why Dia is bad; this has > >been expressed already. Perhaps I must convince you that including the > >EPS files would be good. My arguments follow. > > > >Including the EPS files in the source tarball would be good because: > > > > * It benefits users of the Debian package, since building the > > documentation as part of the entire build process ensures the > > documentation corresponds to the Albatross version. The > > introduction of a new Albatross package would see all packages > > updated at once. There is no risk of mistake or delays due to a > > separate source package. > > * It benefits users of the Debian package, since the tests > > performed on the documentation during the build helps ensure > > that the examples in the documentation work with the Python > > version used in Debian. > > * It benefits users who cannot use Dia to build the documentation, > > but who don't want to download the separate documentation. > > * It would benefit those who package Albatross for other systems. > > > >The downside would be a considerably larger tarball. If Dia is ever > >fixed, all of this would go away, of course. > > I think I liked your previous suggestion - a separate "albatross-doc" > package. In fact, maybe there should be an "albatross-doc-html" and an > "albatross-doc-pdf" package? (But that sounds like a lot of work). > > This will allow people to install just what they want - the docs can be > installed on their corporate intranet server, the albatross module and > nothing else could be installed on bastions, etc. > > Failing that, including the eps files sounds like a good idea. Or we could try moving to a different drawing program for the diagrams. I am not sure which one we should use. We are already stuck on an old release of dia (0.88) because they have broken the font handling in EPS export. - Dave -- http://www.object-craft.com.au From fabbe at paniq.net Fri Nov 21 18:25:44 2003 From: fabbe at paniq.net (Fabian Fagerholm) Date: Fri, 21 Nov 2003 09:25:44 +0200 Subject: [albatross-users] Re: Including EPS files in source tarball In-Reply-To: <20031120222802.89FE93C9A8@coffee.object-craft.com.au> References: <1069365606.1600.74.camel@kernel> <20031120222802.89FE93C9A8@coffee.object-craft.com.au> Message-ID: <1069399543.856.16.camel@kernel> On Fri, 2003-11-21 at 00:28, Andrew McNamara wrote: > I think I liked your previous suggestion - a separate "albatross-doc" > package. In fact, maybe there should be an "albatross-doc-html" and an > "albatross-doc-pdf" package? (But that sounds like a lot of work). I must have expressed myself inadequately. The albatross-doc package was always a separate *binary* package[0]. What I'm trying to avoid is having several *source* packages. Everything is buildable from one original tarball, and I'd like to keep it that way. Compared to the twisty maze of dark corridors, all alike, that Dia made me enter, producing separate -doc-html, -doc-pdf and (if deemed neccessary) even -doc-ps packages would be no work at all. I had this on my To Do -list anyway, and a lot of the work is already done. I just need to get rid of Dia, and having the EPS's in the original source tarball would solve that. [0] In Debian, a binary package is what users install on their systems. The binary packages are built from source packages, which are the "upstream" source package and a Debian-specific diff which contains any changes to the upstream package, plus a debian directory with information for the packaging system (such as a control file for specifying the binary packages, the dependencies, and a rules file for building the package). -- Fabian Fagerholm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fabbe at paniq.net Fri Nov 21 20:03:41 2003 From: fabbe at paniq.net (Fabian Fagerholm) Date: Fri, 21 Nov 2003 11:03:41 +0200 Subject: [albatross-users] Re: Including EPS files in source tarball In-Reply-To: <1069370051.31388.10.camel@echidna.object-craft.com.au> References: <1069365606.1600.74.camel@kernel> <20031120222802.89FE93C9A8@coffee.object-craft.com.au> <1069370051.31388.10.camel@echidna.object-craft.com.au> Message-ID: <1069405420.849.115.camel@kernel> On Fri, 2003-11-21 at 01:14, Dave Cole wrote: > > Failing that, including the eps files sounds like a good idea. > > Or we could try moving to a different drawing program for the diagrams. > I am not sure which one we should use. We are already stuck on an old > release of dia (0.88) because they have broken the font handling in EPS > export. The unfortunate truth is that in every respect, except for the lacks in font handling and export features, Dia is quite good. That's probably why you started using it in the first place -- its user interface is very intuitive, and as long as you don't need to move the diagrams to another program (including another version of Dia), you're going to be fine. I've checked out some other programs including the following: * tcm - this is a program directed at very specific diagrams, including UML Class Diagrams (they call it Static Structure Diagrams). It uses a special file format. The user interface is horrid. EPS export requires X, so it's no better than Dia in that respect. Font handling is "better" because you can only select from a predefined set of fonts... * Umbrello - requires KDE, which makes it somewhat unsuitable for including in the build process. It can export to PNG, but as far as I can see, this works only from within the GUI... * xfig - a generic program for drawing figures. Redrawing the diagrams in xfig would probably be possible, but would require lots of work. * Sodipodi - a general-purpose vector drawing program. It saves in a subset of SVG, so the build process could use any SVG-to-EPS tool to render the images. Redrawing the diagrams would require lots of work. Despite Dia's shortcomings, I think it may be the only way at the moment. I've experimented with Dia's SVG output, but it's basically just as bad as anything else (the fonts and page alignment mainly). I think SVG is the way to go if you want to get rid of Dia. If you use it, you can choose one tool now, and then move to another tool in the future without having to redraw everything from scratch. You may be able to export to SVG from Dia, and use the result as a starting point for the SVG diagrams. With rsvg from the GNOME librsvg project (http://librsvg.sourceforge.net/), any SVG file could be converted to PNG, which is suitable for all the current Albatross doc formats. Perhaps it would just be worth waiting for Dia to be fixed? -- Fabian Fagerholm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From matt at pollenation.net Sat Nov 29 04:21:54 2003 From: matt at pollenation.net (Matt Goodall) Date: Fri, 28 Nov 2003 17:21:54 +0000 Subject: [albatross-users] Importing page modules Message-ID: <3FC78432.9020909@pollenation.net> Hi all, Some time ago I raised an issue with importing page modules and how it affected sys.modules. It's not been resolved yet although that's not what this message is about. Someone recently posted to python-list with a related issue so I thought I'd mention it here too: Generated code that is exec-ed (to simulate import) cannot import os.path?? http://mail.python.org/pipermail/python-list/2003-November/197043.html This is one of the problems I came across when inventing an imaginary package for the page modules to live in. IIRC, I ended up loading page modules as modules with names like albatross_page_home rather than using something a bit more obvious like albatross.pages.home. Anyway, in the end I abandoned the above approach (too magical for me and I don't like hacking with the Python import mechanism) and went with execfile() even though that also has issues. The history of that conversion will be in the archives if anyone is interested. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenationinternet.com e: matt at pollenation.net t: +44 (0)113 2252500