' Maybe, you can help me? Sorry for my bad english. -- Thomas From cathal.alexandria at gnostai.org Fri Jun 4 20:51:56 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Sat, 5 Jun 2010 01:51:56 +0100 Subject: [Alexandria-list] Alexandria on ArchLinux In-Reply-To: <4C095E3F.8020701@gmail.com> References: <4C095E3F.8020701@gmail.com> Message-ID: <20100605015156.09fa7f80@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 04 Jun 2010 22:12:47 +0200 Tomasz Chabinka wrote: > /usr/bin/alexandria:3: warning: variable $KCODE is no longer > effective; ignored > unexpected $end, expecting ']' > 'Adri?n Chaves Fern?ndez ^ > from /usr/lib/ruby/site_ruby/1.9.1/alexandria.rb:21: > from /usr/bin/alexandria:11:in `

' You are using Ruby 1.9. Alexandria has only been tested with Ruby 1.8.* The problem is to do with the encoding of the Ruby source files. Try running the following command from a terminal: ruby -Ku /usr/bin/alexandria ... which should load the .rb files as utf-8 Another user on ArchLinux made some patches for Alexandria to make it work on ruby-1.9 a bit better. http://rubyforge.org/tracker/?func=detail&atid=865&aid=28231&group_id=205 But it doesn't include a fix for the issue you're describing. The other alternative is to try installing a ruby-1.8 package alongside ruby-1.9 (I'm not sure how hard this is with ArchLinux). The other problem is that you'll have to install Ruby-GNOME2 packages for ruby-1.8, as well as all the rest of Alexandria's dependencies. Hope this helps, - C. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwJn6wACgkQfMAUnRdb+8ohhwCeKXv7MdGVYaLHlxoNE4ir+IcV 26gAnj7vgxbA7kPDRLa57YNWHydV4esK =Krnd -----END PGP SIGNATURE----- From ras at acm.org Thu Jun 17 13:03:34 2010 From: ras at acm.org (Robert A. Schmied) Date: Thu, 17 Jun 2010 10:03:34 -0700 Subject: [Alexandria-list] the provider douban refuses to stay disabled ... Message-ID: <4C1A5566.90103@acm.org> aloha alexandria gurus when the douban provider is initialized it ignores predefined prefs. the fix -- add statement 'prefs.read' to the douban initialize() method. i have done no testing beyond verifying that the provider is now marked with the prior preference setting. in point of fact i have no evidence that the provider was actually 'enabled', but the douban provider dialog always indicated initialized with the check box 'checked' and that is what this change corrects. % gdiff -u alexandria/book_providers/douban.rb alexandria/book_providers/douban.rb --- alexandria/book_providers/douban.rb 2010-06-14 20:25:45.770577000 -0700 +++ alexandria/book_providers/douban.rb 2010-06-17 09:25:11.266523000 -0700 @@ -38,6 +38,7 @@ def initialize() super("Douban", "Douban (China)") + prefs.read end def url(book) From cathal.alexandria at gnostai.org Thu Jun 17 14:33:21 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Thu, 17 Jun 2010 19:33:21 +0100 Subject: [Alexandria-list] the provider douban refuses to stay disabled ... In-Reply-To: <4C1A5566.90103@acm.org> References: <4C1A5566.90103@acm.org> Message-ID: <20100617193321.625b7d78@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 17 Jun 2010 10:03:34 -0700 "Robert A. Schmied" wrote: Thanks, I had noticed this earlier but didn't get around to figuring out the issue. It did indeed keep the Douban Provider enabled by default upon each re-start. Added fix to SVN (r1143). - Cathal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwaanEACgkQfMAUnRdb+8q2VwCfRW6NSLf0//5WBC9mUrRVLf9j vwQAnRKVB5zNTw9+yoR2W5np2mvyDKY1 =DZAG -----END PGP SIGNATURE----- From cathal.alexandria at gnostai.org Mon Jun 21 18:55:51 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Mon, 21 Jun 2010 23:55:51 +0100 Subject: [Alexandria-list] [ANN] Alexandria 0.6.6 Message-ID: <20100621235551.3fa5ed28@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Happy Summer Solstice, Everyone. Alexandria 0.6.6 has just been released. Alexandria is a GNOME application for managing your book collection. After several long lulls in development between the first two beta releases, the final 0.6.6 includes a handful of new bug fixes and improvements to the user-interface. On-line release notes, including installation instructions, are here: http://alexandria.rubyforge.org/news/2010-06-21--0.6.6-released.html - Cathal Mc Ginley. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwf7fcACgkQfMAUnRdb+8qCDQCffI2FQPxeLKJFbg2QQP0jhdLK cTwAoJ2BKHiI0rRmc0LWh0Z1dIqilotH =nmzC -----END PGP SIGNATURE----- From cathal.alexandria at gnostai.org Fri Jun 25 16:55:52 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Fri, 25 Jun 2010 21:55:52 +0100 Subject: [Alexandria-list] Future Development of Alexandria Message-ID: <20100625215552.306cc0d6@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everyone, After I finally managed to get Alexandria 0.6.6 out the door (ridiculously long beta period notwithstanding), I thought it might be a good time to discuss future development of Alexandria. I had a query from Robert A. Schmied a few weeks ago about whether Palatina (my experimental Alexandria re-write) has stalled, if is ever going to be merged into Alexandria, or failing that, what the plan is for adding new features to Alexandria. Well, Alexandria has lots of built-in limitations (like only one copy of a Book per Library) which are low-level and would require lots of changes everywhere to fix. And from recent experience, bug fixes and new features are sometimes patched on any-old-how (mea culpa) resulting in hard-to-read and frangible code. So adding new features directly to Alexandria wouldn't be my first choice. Work on Palatina has actually been very slow (no GUI yet, for instance), and it turns out to be very different from Alexandria in structure. I'm not sure if I'd actually like to merge the two projects or just produce a GUI for Palatina that looks very like Alexandria but with tonnes more features. The question now becomes, should I consider such a new program to be "Alexandria"? Should I even continue discussion of Palatina on this mailing-list (I could easily set up one for Palatina development). I'd welcome all your opinions on this point. In the mean time, Robert suggested, and I agree, that a public schedule for work on Palatina might be helpful. (Outside attention on my work helps to motivate me.) There's a development roadmap on the Palatina Wiki http://palatin.as/wiki/DevelopmentRoadMap which I could add dates to if anyone's interested in trying out the code at some stage. In terms of making "a better Alexandria", I think that by the "0.4 Kafkaesque" milestone it would be possible to produce a Alexandria-like program which used Palatina. (Ideally, in 3 or 4 months, so it won't drag on indefinitely). - Cathal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwlF9gACgkQfMAUnRdb+8o/nACePxcIUBj9SblF0I9IFL2QiiPM E5EAoJ/Qf3EaDgfB+z/w/kWFAlsF3/cL =Vooz -----END PGP SIGNATURE----- From phil at pricom.com.au Sat Jun 26 02:33:21 2010 From: phil at pricom.com.au (Philip Rhoades) Date: Sat, 26 Jun 2010 16:33:21 +1000 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <20100625215552.306cc0d6@jadzia> References: <20100625215552.306cc0d6@jadzia> Message-ID: <4C259F31.5010308@pricom.com.au> Cathal, On 2010-06-26 06:55, Cathal Mc Ginley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Everyone, > > After I finally managed to get Alexandria 0.6.6 out the door > (ridiculously long beta period notwithstanding), I thought it might be a > good time to discuss future development of Alexandria. > > I had a query from Robert A. Schmied a few weeks ago about whether > Palatina (my experimental Alexandria re-write) has stalled, if is ever > going to be merged into Alexandria, or failing that, what the plan is > for adding new features to Alexandria. > > Well, Alexandria has lots of built-in limitations (like only one copy > of a Book per Library) which are low-level and would require lots of > changes everywhere to fix. And from recent experience, bug fixes and > new features are sometimes patched on any-old-how (mea culpa) resulting > in hard-to-read and frangible code. So adding new features directly to > Alexandria wouldn't be my first choice. > > Work on Palatina has actually been very slow (no GUI yet, for instance), > and it turns out to be very different from Alexandria in structure. I'm > not sure if I'd actually like to merge the two projects or just produce > a GUI for Palatina that looks very like Alexandria but with tonnes more > features. The question now becomes, should I consider such a new program > to be "Alexandria"? Should I even continue discussion of Palatina on > this mailing-list (I could easily set up one for Palatina development). > I'd welcome all your opinions on this point. > > In the mean time, Robert suggested, and I agree, that a public schedule > for work on Palatina might be helpful. (Outside attention on my work > helps to motivate me.) There's a development roadmap on the Palatina > Wiki http://palatin.as/wiki/DevelopmentRoadMap > which I could add dates to if anyone's interested in trying out the > code at some stage. In terms of making "a better Alexandria", I think > that by the "0.4 Kafkaesque" milestone it would be possible to produce a > Alexandria-like program which used Palatina. (Ideally, in 3 or 4 > months, so it won't drag on indefinitely). I am particularly interested in the new possibilities - some time ago, before I had found Alexandria, I had already done my own thing as an exercise: http://pricom.com.au/library but was interested in what Alexandria could do and looked at it as an alternative to my own setup but never made any more progress either way. If Palatina ends up being more customizable or able to fit into how I want to do things then it would be quite interested in getting involved to some extent - I shouldn't really be getting involved in any more projects really . . Could you add more detail to the Palatina website about how it is currently constructed? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil at pricom.com.au From ras at acm.org Sat Jun 26 10:53:02 2010 From: ras at acm.org (Robert A. Schmied) Date: Sat, 26 Jun 2010 07:53:02 -0700 Subject: [Alexandria-list] the provider douban refuses to stay disabled ... Message-ID: <4C26144E.3040005@acm.org> on 17jun10 cathal appears to have replied as quoted below, but for some reason i never got it, nor his most recent message regarding Palatina, i did however get phils reply to cathal post!?) > On Thu, 17 Jun 2010 10:03:34 -0700 > "Robert A. Schmied" wrote: > > Thanks, I had noticed this earlier but didn't get around to figuring > out the issue. It did indeed keep the Douban Provider enabled by > default upon each re-start. Added fix to SVN (r1143). > > - Cathal. not withstanding the email list issue i've also noted these book_providers appear to have the same missing statement (e.g. prefs.read), but i've not noticed them having the same prefs enable/disable problem ??? bol_it.rb ibs_it.rb renaud.rb webster_it.rb ras From cathal.alexandria at gnostai.org Sat Jun 26 11:58:10 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Sat, 26 Jun 2010 16:58:10 +0100 Subject: [Alexandria-list] the provider douban refuses to stay disabled ... In-Reply-To: <4C26144E.3040005@acm.org> References: <4C26144E.3040005@acm.org> Message-ID: <20100626165810.16a7376d@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 26 Jun 2010 07:53:02 -0700 "Robert A. Schmied" wrote: > book_providers appear to have the same missing statement (e.g. > prefs.read), but i've not noticed them having the same prefs > enable/disable problem ??? > > bol_it.rb > ibs_it.rb > renaud.rb > webster_it.rb That's because they aren't loaded: they're considered non-functional. Their associated websites have changed considerably since they were last updated, and I didn't have time to fix them before the latest release (the language barrier didn't help) so I just disabled them. You may still have the settings hanging around in your "Book Data Providers" list from some earlier installed version of Alexandria. - C. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwmI5IACgkQfMAUnRdb+8rYIgCfSlTemOgdvzBjfab++hUf70Ul aPMAn2E5eXObWCxZ5X4LTFrNsBYZU0L9 =uEbu -----END PGP SIGNATURE----- From cathal.alexandria at gnostai.org Sat Jun 26 12:08:13 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Sat, 26 Jun 2010 17:08:13 +0100 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <4C259F31.5010308@pricom.com.au> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> Message-ID: <20100626170813.7a770de3@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 26 Jun 2010 16:33:21 +1000 Philip Rhoades wrote: > involved to some extent - I shouldn't really be getting involved in > any more projects really . . Domain analysis, feedback on using the code and suggestions for features are the kinds of input I'm most interested in at the moment. Should be the kind of stuff done in spare moments, hopefully! > Could you add more detail to the Palatina website about how it is > currently constructed? Good idea, there's a tiny amount of that here (only three documents): http://palatin.as/development/index.html but I'll add some more stuff about Node, NodeProperties and Plugin (the real complex heart of the system) soon. Then, a "Getting Started" document, and a "Hacker's Guide". - C. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwmJe0ACgkQfMAUnRdb+8plOwCfWHdh2U+jMLj6fiIltMT29oKS xEcAn3YpEPXFR0AdAVAynqYPfr7UQEin =gmzZ -----END PGP SIGNATURE----- From phil at pricom.com.au Sat Jun 26 12:58:09 2010 From: phil at pricom.com.au (Philip Rhoades) Date: Sun, 27 Jun 2010 02:58:09 +1000 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <20100626170813.7a770de3@jadzia> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> <20100626170813.7a770de3@jadzia> Message-ID: <4C2631A1.1030101@pricom.com.au> Cathal, On 2010-06-27 02:08, Cathal Mc Ginley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 26 Jun 2010 16:33:21 +1000 > Philip Rhoades wrote: > >> involved to some extent - I shouldn't really be getting involved in >> any more projects really . . > > Domain analysis, feedback on using the code and suggestions for features > are the kinds of input I'm most interested in at the moment. Should be > the kind of stuff done in spare moments, hopefully! OK, good. >> Could you add more detail to the Palatina website about how it is >> currently constructed? > > Good idea, there's a tiny amount of that here (only three documents): > http://palatin.as/development/index.html > but I'll add some more stuff about Node, NodeProperties and Plugin (the > real complex heart of the system) soon. Then, a "Getting Started" > document, and a "Hacker's Guide". Great! - look forward to it. Regards, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil at pricom.com.au From ras at acm.org Sat Jun 26 13:12:30 2010 From: ras at acm.org (Robert A. Schmied) Date: Sat, 26 Jun 2010 10:12:30 -0700 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <4C259F31.5010308@pricom.com.au> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> Message-ID: <4C2634FE.8020506@acm.org> Philip Rhoades wrote in reply: > Cathal, > On 2010-06-26 06:55, Cathal Mc Ginley wrote: > >> Hi Everyone, >> >> After I finally managed to get Alexandria 0.6.6 out the door >> (ridiculously long beta period notwithstanding), I thought it might be a >> good time to discuss future development of Alexandria. >> >> I had a query from Robert A. Schmied a few weeks ago about whether >> Palatina (my experimental Alexandria re-write) has stalled, if is ever >> going to be merged into Alexandria, or failing that, what the plan is >> for adding new features to Alexandria. >> >> Well, Alexandria has lots of built-in limitations (like only one copy >> of a Book per Library) which are low-level and would require lots of >> changes everywhere to fix. And from recent experience, bug fixes and >> new features are sometimes patched on any-old-how (mea culpa) resulting >> in hard-to-read and frangible code. So adding new features directly to >> Alexandria wouldn't be my first choice. >> >> Work on Palatina has actually been very slow (no GUI yet, for instance), >> and it turns out to be very different from Alexandria in structure. I'm >> not sure if I'd actually like to merge the two projects or just produce >> a GUI for Palatina that looks very like Alexandria but with tonnes more >> features. The question now becomes, should I consider such a new program >> to be "Alexandria"? Should I even continue discussion of Palatina on >> this mailing-list (I could easily set up one for Palatina development). >> I'd welcome all your opinions on this point. >> >> In the mean time, Robert suggested, and I agree, that a public schedule >> for work on Palatina might be helpful. (Outside attention on my work >> helps to motivate me.) There's a development roadmap on the Palatina >> Wiki http://palatin.as/wiki/DevelopmentRoadMap >> which I could add dates to if anyone's interested in trying out the >> code at some stage. In terms of making "a better Alexandria", I think >> that by the "0.4 Kafkaesque" milestone it would be possible to produce a >> Alexandria-like program which used Palatina. (Ideally, in 3 or 4 >> months, so it won't drag on indefinitely). > > > > I am particularly interested in the new possibilities - some time ago, > before I had found Alexandria, I had already done my own thing as an > exercise: > > http://pricom.com.au/library > > but was interested in what Alexandria could do and looked at it as an > alternative to my own setup but never made any more progress either way. > If Palatina ends up being more customizable or able to fit into how I > want to do things then it would be quite interested in getting involved > to some extent - I shouldn't really be getting involved in any more > projects really . . > > Could you add more detail to the Palatina website about how it is > currently constructed? > > Thanks, > > Phil. cathal i too am interested in the new possibilities of a reconstructed alexandria, one that especially doesn't have the 100 book or so per library responsiveness issue (assuming alex still does per alexandria-0.6.6-beta2/doc/BUGS). i'd be willing to contribute in any way i can, just let me know ... as i mentioned the one item that isn't being tracked by either alex or 'tina is the acquisition date of the media (or date it is added to the collection). ahha! i see that added to the book data requirements ... name wise, as an alex newby my opinion should have very little weight, but if the reconstructed alexandria can read alexandria data and reform/rewrite it as needed and works *identically* (from a command-line api prospective -- probably doesn't really apply in this case as alex doesn't have much in the way of a command line driven interface) then the reconstructed alexandria is really still alexandria. on the other hand, if it works differently then it probably is some other library. (assuming 'tina is a reference to Palatine Library in Parma and not The Bibliotheca Palatina ("Palatinate library") of Heidelberg, nor The Palatine Chapel in Palermo, nor Claus Ableiters 2006 image Many grapes / Palatina) as far as mailing list -- if alex and 'tina are one in the same then this list is fine (but it would be nice if cathals' posts get to me), but if 'tina isn't alex (in some other clothing) then the list should bifurcate ... schedule wise -- where is 'tina currently? and is there anything an outsider can do now to enhance progress? i can submit "here's what i've got and what i've had to do to get alex to make it work for me kind of stuff" or just post the hacks directly to the list (or if encouraged) directly on the alex rubyforge patches tracker ... for example, being a unix-greybeard my 'book list' is on two text files one being isbns, the other title-author. each file allows for blank lines, comment lines, and data lines that might also include a comment. lines starting with a '#' are comments and ignored unless they encode a date string like '# 26jun10' which sets the acq date. it remains current until another one supercedes it. comments on a data line start with the sequence '\s+#.*$' currenly i have limited processing to ensuring 1) the isbn is valid 2) there are no duplicate isbns in the file 3) via perl WWW::Scraper::ISBN and hacked LOC driver i can download and store data about each publication: Title: Author: Edition: VolNo: Publisher: Location: Year: ISBN: LofCCNo: PubBookNo: Binding: acquisition date: record date: url: '' this info is also stored on a single text file and can be processed via traditional unix command pipes in whatever manner desired ... in order to convince alex to import my isbn list file i had to hack the import to deal with files that contain blank lines, comment lines and comments on data lines as well as hack the handler to accept a file without a predefined extension, but well it does seem to work ... aloha ras From cathal.alexandria at gnostai.org Sat Jun 26 16:25:54 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Sat, 26 Jun 2010 21:25:54 +0100 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <4C2634FE.8020506@acm.org> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> <4C2634FE.8020506@acm.org> Message-ID: <20100626212554.59d5153a@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick netiquette point, if you're not responding point-by-point, it's easier to read your post if you don't quote the whole previous message. On Sat, 26 Jun 2010 10:12:30 -0700 "Robert A. Schmied" wrote: > > i too am interested in the new possibilities of a reconstructed > alexandria, one that especially doesn't have the 100 book or so per > library responsiveness issue (assuming alex still does per > alexandria-0.6.6-beta2/doc/BUGS). 0.6.6 is much better than pre-0.64 days. Clicking on my "Owned" Smart Library pulls up 328 books in about 2 seconds. So that's an improvement. > can read alexandria data and reform/rewrite it as needed and works > *identically* [....] then the reconstructed alexandria is really > still alexandria. I'm sure the GUI will be different in many areas, but it should still *feel* like Alexandria, and hopefully be as easy to use. My main concern is *lineage*; if essentially every line is new code, and I'm not the original author, can I really say it's a continuation of the program. I guess I'll wait for more opinions (or until the program is closer to completion and users can judge). > (assuming 'tina is a reference to Palatine Library in Parma and not > The Bibliotheca Palatina ("Palatinate library") of Heidelberg It *is* actually named after the the Bibliotheca Palatina of Heidelberg, http://en.wikipedia.org/wiki/Bibliotheca_Palatina (I thought I'd continue the theme of "great vanished libraries of antiquity"). > as far as mailing list -- if alex and 'tina are one in the same then > this list is fine (but it would be nice if cathals' posts get to me), (I've turned off nodupes on your Mailman settings, that might do it. It seems e-mails from me to you aren't getting through - check your spam filter.) > but if 'tina isn't alex (in some other clothing) then the list should > bifurcate ... > > > schedule wise -- where is 'tina currently? Well, it's pre-0.1. Code and APIs are fluid. If I put together a very simple GUI just to list books, I would be at milestone 0.1 > and is there anything an outsider can do now to enhance progress? Um, good question. I would have said feedback on the structure of the Palatina API, but I've started changing that about recently, and anyway most on this list are interested in the end-user GUI experience. So, domain analysis and adding to requirements http://palatin.as/wiki/BookDataRequirements (To sign up to modify the Palatina wiki you'll need an invite code, which is currently IAmNotANumber) Also, perhaps people could go through the Feature Requests on the Tracker http://rubyforge.org/tracker/?func=browse&group_id=205&atid=866 and summarize and consolidate them on the wiki here: http://palatin.as/wiki/AlexandriaFeatureRequests (there are many duplicates, and some ideas are already handled by Palatina). > i can submit "here's what i've got and what i've had to do to get > alex to make it work for me kind of stuff" or just post the hacks > directly to the list (or if encouraged) directly on the alex > rubyforge patches tracker ... Feel free in both cases. Maintenance of regular Alexandria will continue in any case, and technical HOWTOs are always helpful. > in order to convince alex to import my isbn list file i had to hack > the import to deal with files that contain blank lines, comment lines > and comments on data lines as well as hack the handler to accept a > file without a predefined extension, but well it does seem to work ... Sounds good! As long as it's not too specific to your own case, it can be rolled into Alexandria. - Cathal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwmYlIACgkQfMAUnRdb+8qzMwCgr8EMkFM1yfjJTGrIqoRQSaUV xAwAoLiasJrY5iq4V8rQoxuojDwBiIE8 =ITTc -----END PGP SIGNATURE----- From ophidian at ophidian.homeip.net Sun Jun 27 22:13:12 2010 From: ophidian at ophidian.homeip.net (Aaron Clark) Date: Sun, 27 Jun 2010 22:13:12 -0400 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <20100626212554.59d5153a@jadzia> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> <4C2634FE.8020506@acm.org> <20100626212554.59d5153a@jadzia> Message-ID: <4C280538.3010409@ophidian.homeip.net> On 06/26/2010 04:25 PM, Cathal Mc Ginley wrote: >> > i too am interested in the new possibilities of a reconstructed >> > alexandria, one that especially doesn't have the 100 book or so per >> > library responsiveness issue (assuming alex still does per >> > alexandria-0.6.6-beta2/doc/BUGS). > 0.6.6 is much better than pre-0.64 days. Clicking on my "Owned" Smart > Library pulls up 328 books in about 2 seconds. So that's an improvement. > Is it still the same issue with the GTK construct rather than actual I/O loading problems? Aaron -- "The goblins are in charge of maintenance? Why not just set it on fire now and call it a day?" --Whip Tongue, Viashino Technician From cathal.alexandria at gnostai.org Mon Jun 28 12:38:38 2010 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Mon, 28 Jun 2010 17:38:38 +0100 Subject: [Alexandria-list] Future Development of Alexandria In-Reply-To: <4C280538.3010409@ophidian.homeip.net> References: <20100625215552.306cc0d6@jadzia> <4C259F31.5010308@pricom.com.au> <4C2634FE.8020506@acm.org> <20100626212554.59d5153a@jadzia> <4C280538.3010409@ophidian.homeip.net> Message-ID: <20100628173838.58b8a77d@jadzia> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 27 Jun 2010 22:13:12 -0400 Aaron Clark wrote: > On 06/26/2010 04:25 PM, Cathal Mc Ginley wrote: > > 0.6.6 is much better than pre-0.64 days. Clicking on my "Owned" > > Smart Library pulls up 328 books in about 2 seconds. So that's an > > improvement. > > Is it still the same issue with the GTK construct rather than actual > I/O loading problems? I've put together a prototype GUI for Palatina which loads thousands of test books from memory (not from the database yet). It uses Gtk.queue and Gtk.main_with_queue as suggested on the Ruby/GNOME2 website: http://ruby-gnome2.sourceforge.jp/hiki.cgi?tips_threads When doing a test load of 1,000 items into a list view, the GUI seems to respond almost instantaneously (though it takes about 200-300 milliseconds to actually add all the items). Adding 10,000 items seems to respond in a second or so, but actually takes about 7 or 8 seconds to load everything fully (so if you click an item low down the list it takes a while to catch up to you, and if you cover the Palatina window it doesn't repaint immediately when you uncover it - it looks grey until everything's loaded). Anyway, I call it progress. Now I have to work on the database loading; catalogues and collections should use hand-written SELECTSs, loading simply using DataMapper ORM-style code is leading to unacceptably slow results, but tests with SELECTs through DataMapper show it to be zippy-fast. - Cathal. P.S. The prototype Palatina GUI is in the git repository: git clone git://code.gnostai.org/git/palatina.git P.P.S. I really think this stuff is starting to need its own mailing list, I'll look into creating one. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkwo0A4ACgkQfMAUnRdb+8q33gCeNQU7yzMJRhTnRHA8V2/3nRi1 d/0AoNB0JTfWYEhV9oXy4X0Lwi49stCm =NOZt -----END PGP SIGNATURE----- From fauli at gentoo.org Mon Jun 28 15:20:04 2010 From: fauli at gentoo.org (Christian Faulhammer) Date: Mon, 28 Jun 2010 21:20:04 +0200 Subject: [Alexandria-list] Direction of Alexandria Message-ID: <20100628212004.3cbe488c@gentoo.org> Hi, I just subscribed to this list but followed the archives about the direction of Alexandria. As it is an introduced "brand" I would vote for a rewrite (taking Palatina, maybe code name) which is then the 1.0 release of Alexandria. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: