Re: [Catalyst] DB2 Connection string problem
On Tue, 27 Mar 2012 21:32:12 +0200, Kenneth S Mclane ksmcl...@us.ibm.com wrote: am able to connect from Perl directly with a quick test file I wrote. Ok, then you're 99% done. I just cannot figure out how Catalyst passes/parses the arguments. Maybe you could start by posting your working perl code and then people on the list can help you transpose that to the relevant Catalyst parts/plugins? Just an idea. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DB2 Connection string problem
On Tue, 27 Mar 2012 20:49:41 +0200, Gianni Ceccarelli dak...@thenautilus.net wrote: On 2012-03-27 Kenneth S Mclane ksmcl...@us.ibm.com wrote: [IBM][CLI Driver] SQL1031N The database directory cannot be found on the indicated file system. SQLSTATE=58031 This is the result I get from that change. I can't really help you more than this, I was just reading the documentation… I've never worked with DB2, and those error messages (in perfect IBM style) are quite hard to understand. Hope someone else has some experience in DB2. Or you may try asking to some different crowds, though (no, I don't know where to find people that know DB2). Let's see. Last time I managed to connect to DB2 from perl was around 2002, with ancient versions of DBD::DB2... :) IBM messages might be cryptic, but the guys are smart enough to include error number and SQLSTATE, so you need to look those up. Try this: https://encrypted.google.com/search?client=operarls=nbq=%22%5BIBM%5D%5BCLI+Driver%5D+SQL1031N+The+database+directory+cannot+be+found+on+the+indicated+file+system.+SQLSTATE=58031%22sourceid=operaie=utf-8oe=utf-8channel=suggest#client=operarls=nbq=%22%5BIBM%5D%5BCLI+Driver%5D+SQL1031N+The+database+directory+cannot+be+found+on+the+indicated+file+system.+SQLSTATE%3D58031%22sourceid=operaie=utf-8oe=utf-8channel=suggestfp=1bav=on.2,or.r_gc.r_pw.,cf.osbcad=b or search term: [IBM][CLI Driver] SQL1031N The database directory cannot be found on the indicated file system. SQLSTATE=58031 in your preferred search engine. IBM documentation usually gives you a hint about any type of error. AFAIK, most DB2 connectivity problems come from: * misconfigured DB2 client (see web search above) * DB2 database on the server host (mine was running on OS/400, YMMV) needs to be exported for clients to connect via TCP/IP directly. (Oh, /me just realized now I'm writing to a IBM email address) Sorry... you clearly know better than me ... :) -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Job Queue recommendation
In data 22 gennaio 2011 alle ore 07:13:49, Bill Moseley mose...@hank.org ha scritto: On Fri, Jan 21, 2011 at 7:30 AM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: t0m created CatalystX::JobServer which is currently only available on github: https://github.com/bobtfish/CatalystX-JobServer So, venturing a bit off topic, anyone have suggestions on managing worker (consumer) processes? There seems to be two common approaches. One is to just start up a bunch of worker processes independently (managed like any other daemon) killing and starting more as needed. For some time I used this approach, with a fake init script like '/etc/init.d/worker' that would start one of them, so I could run it multiple times to spawn more workers. A munin plugin monitored the number of active workers, and if it detected less than normal, it would spawn a new one. I thought that'd be neat, then I changed my mind. It worked just fine, but in the end I didn't like mixing munin plugins with application-related stuff. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Creating HTML docs from POD
In data 30 ottobre 2010 alle ore 16:29:34, Octavian Rasnita orasn...@gmail.com ha scritto: Is there a tool that can be used to extract the POD from all the modules of a Catalyst app and create an HTML version of that documentation? Hi Octavian, I'm trying to build on http://github.com/jonallen/perldoc.perl.org I made my own fork, http://github.com/cosimo/perldoc.perl.org . You invoke project-doc.pl. It's still really messy, and it depends on various directories to exist, but it can already build an entire project's local documentation. The ultimate goal is to be able to point it to your source code, and output all the html in a ./build folder. I have also succeeded in adding my own header, logo, css, etc... Unfortunately, as I said, it's messy and still incomplete, but maybe you can take a look at it. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] I18N with variables
On Mon, 02 Aug 2010 07:08:04 +0200, Julien Sobrier jul...@sobrier.net
wrote:
Also, writing [% c.loc(foo) %] does not create an entry in messages.po
when running xgettext.pl, like [% c.loc('foo') %] does.
To make that work, I think you'd have to actually *run*
your templates for all possible cases, and then collect all
the strings that were passed as arguments to c.loc().
In other words, I'm not saying it's impossible, but
xgettext.pl will probably never be able to do that.
A slightly different approach, that works for me,
is to create your .PO files in different stages.
First step parses the templates with xgettext.pl and generates
the .PO files.
A second step can, for example, parse the actual source
code, for stuff like '$c-loc(foo)'.
xgettext.pl can do that with a bit of trickery.
The new messages will be merged together in the same .PO files.
In your case, you could pull the messages you want to be translated
directly from the database, and write some on-the-fly
fake templates (or text files for that matter),
and feed them to xgettext.pl.
--
Cosimo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] I18N with variables
On Fri, 06 Aug 2010 16:57:42 +0200, Bill Moseley mose...@hank.org wrote: I've been arguing with work about how to key our text. So far we continue to use the English in the loc() tags in the templates, and then the I18N team uses a script to pull out this text which gets sent to translation services. We also chose to use english text as message keys. I wanted to avoid ids because: 1) Retrofitting i18n in an existing app would make you spend weeks/months replacing all the text messages with ids. 2) Designers or front-end developers work suddenly becomes much harder. You need to provide them a database of already used IDs and what they mean. 3) With IDs it's difficult to identify when a message has arguments, and which ones, or even how many of them: Hello, [_1], you have [_quant,_2,message,messages,no messages] The main disadvantage I see is that when you change your text, all the .PO files need to be updated, so you actually kill some of the existing messages, and you have to manage that with your i18n tools. So, I'd like to hear about your translation workflow and any tools you are using. I found the latest Transifex (0.9.0+) very good for us: http://trac.transifex.org/ We're managing our own instance. Pay attention if you plan to do that: http://my.opera.com/cstrep/blog/2010/06/22/dependencies-suck -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] I18N with quotation marks
Gunnar Strand gunnarstr...@yahoo.com wrote:
Ton Voon skrev:
Final question: How do you internationalise a bit of text that does
want some markup within it? For instance, I want something that outputs:
Click a href=/abouthere/a for the about page.
Wouldn't you need to send every part of the text through c.loc
individually? I guess something like this:
c.loc(Click ) _ link _ c.loc( for the about page)
If you collect all your i18n messages into .po files,
that are worked on by translators, they have little or no
context information, so they are going to have a really
hard time figuring out the sense of words.
We internationalized a dynamic non-catalyst website in
19 languages now, and we found the following, in gettext notation,
to be the best for front-end and back-end developers
and translators.
_('Click a href=[_1]here/a for the about page')
So,
1) Keep the markup. It's ugly, but to us it's slightly better than
the alternatives.
2) Variables as variables. This also conserves strings
if/when you're changing URLs or variable content.
Example:
You can upload up to [_1] Mb of pictures.
As the string embeds the variable, your string won't need
to be translated again if you change your upload limit.
3) Don't break sentences. In general, the longer, the better.
In general.
--
Cosimo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Serving static content from DB
Mihai Bazon mi...@bazon.net wrote: I wrote some tests, since you ask me about numbers. You can download it here to run it yourself: http://mihai.bazon.net/Static-VS-DBI.tar.bz2 Excellent! Thanks for this. Will look into it. 1. is the file cached? - If not, retrieve from DB then save it on disk. - If yes, is its mtime older than what's in DB? [...] For most requests, the Perl handler steps in only to check that the cached file is up-to-date. So this is the critical step. The one that will force you to hit the db for every static file request. Again, if it's fine for you, everyone's happy. And probably that db table will be mostly read-only and cached in memory... Moreover, the cache is outside the document_root, which is many times convenient. I don't know what you mean here. Can you explain me? -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
In data 19 februar 2009 alle ore 16:12:36, Matt Pitts mpi...@a3its.com ha scritto: I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl. [...] Sad to say, but I completely agree with this. It's quite ironic how the drive of open source has only furthered the need for OS agnostic software and platforms, which in turn, has actually made life harder for things like Perl that have strong origins in *nix OSes. [...] I really, really want to be able to just run my Cat apps in Windows, and I probably could get it going under ActiveState or Strawberry if I stuck to it Does that mean that you haven't tried? but I _need_ it to not be that hard. I'm sure I'm not the only one. It's _not_ that hard. Perl has been good in the Windows world for long. Strawberry has improved this a great deal. Perl on Windows runs most of CPAN without problems. And yes, I sent my small amount of patches too, whenever it hurt me. Perl fully supports building on MSVC from 6 to 2008, and Win32 GCC. In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Cross-platform is one point where Perl excelled, and I think it's still very strong. Then if WxPerl is not developed as WxPython is not Perl's fault. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita orasn...@gmail.com ha scritto: From: David Wright dave-catal...@dexy.org I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html I think it could be good to have a link to a Success stories page in the main page of catalystframework.org that also show it. We're not BBC of course, but I took some time to add the My Opera community site (developed by our team in Opera Software) to appliedstacks.com. I never heard of this site before, but since it's mentioned here I assume it's somewhat trusted. http://www.appliedstacks.com/website/My%20Opera We use Catalyst not for the main backend stuff, but for the administration tools. We used it as a pilot project. If you want to mention it, you're welcome to do so. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Proper ngettext with Catalyst
In data 31 gennaio 2009 alle ore 17:29:39, Nikolai Prokoschenko niko...@prokoschenko.de ha scritto: Locale::Maketext::Lexicon, which C::P::I18n bases on, doesn't support standard plural forms. I worked on implementing i18n/l10n for a fairly big non-catalyst web site, and that's based on Locale::Maketext. When I researched on how to do this, it seemed there was just one way to do things, but it wasn't the case... :-) An example: if I wanted to translate the string I have $x apples I would write using gettext: ngettext(I have %d apple, I have %d apples, $x). Thus xgettext would produce: What about the zero form? Some languages have a totally different idea of the zero/single/plural form. I also encountered some problems with xgettext/xgettext.pl, that I wanted to address in the future. In particular, they work in a slightly different way, so I had to use the former to extract messages from the templates, and the latter to extract them from code. Plus, xgettext.pl is much slower, and it shouldn't be. msgid I have [quant,_1,apple,apples] msgstr a. is wrong technically, [...] b. is wrong semantically, [...] c. forces translators to deal [...] The only solution I've came up with so far is taking parts of Locale::gettext_pp and building up a module which uses standard gettext tools. I just checked L::M::Lexicon and it seems a lot more work has been done since my last patches to keep user comments (0.67). I'm looking forward to help improving I18N/L10N in Locale::Maketext, since I'm in the process of adding support for 21 different languages, plus one rtl language for experimental/testing purposes. Can anyone recommend a sane solution for this problem? I don't know really. I'm learning along the way, but I think we should try to join forces on this. Maybe there's a specific mailing list about l10n or L::M? -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PDF creation in Catalyst?
In data 22 ottobre 2008 alle ore 20:08:45, Kirby Krueger [EMAIL PROTECTED] ha scritto: PDF::ReportWriter. Some time ago I did an evaluation of all different PDF creation Perl modules, to build our own internal solution, and I chose this one. Then I worked with the original author to extend it with some interesting (for me at least) features, like the (easy and quick) xml reports definition, and the page templating. With page templating you can create your own template page in PDF with a tool of your choice, and then let PDF::ReportWriter render the report data on top of it. This seems pretty much what you need. This looks like it's maintained Yes. under active development Yes. and has excellent documentation Mmh... I contributed to the docs as well, but I wouldn't say they are excellent. In particular, the xml format needs to be documented better, and all the groups/headers mechanism maybe needs a better explanation. Anyone heard of this? Try it. At least take a look at the examples and the pdf-template option (in the docs): http://search.cpan.org/src/DKASAK/PDF-ReportWriter-1.5/examples/ It's not mentioned in the usual places like perlmonks. And the design really forces you to learn more about PDF than I ideally want to. I'm not sure. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
Alex Povolotsky wrote:
Martin Ellison wrote:
Is there anything attached to Catalyst similar to the CGI.pm module?
That is, creating the HTML by a series of procedure calls rather than
by instantiating a template?
Creating HTML inside the code is the best way to make unreadable,
unmaintainable program with mysterious errors.
Also, Kieren Diment wrote:
I'd really recommend that you use a proper template engine,
otherwise your code will grow into a horrible monster before you know it.
It seems to me that these are generalizations. They are often true, but
it is indeed possible to create html inside your code, while keeping
a clean and oo approach.
For example, I designed and maintained for years a web framework where
we allowed something like:
my $table = html::styledtable-new(skin='whatever');
my $chart = html::chart-(type='pie3d', data=[EMAIL PROTECTED]);
my $tree = html::treeview-new(plugin='filesystem', subtree='/mypath');
my $doc = html::document-new(splashscreen=1);
$table-add_row('this', 'that');
$table-add_row($chart);
$table-set_cell_opt(1, 0, colspan=2);
$doc-body-add($table);
$doc-body-add($tree);
We had many kind of html widgets, from simple ones, like 'table',
to complex ones, like 'treeview' or 'multiselect', or charts.
You can still separate (almost) clearly your presentation from your
application logic, and your code is highly maintainable,
at least IMO.
You can also evolve (or change completely) your application presentation, or
even changing the underlying layer to use pre-made templates, without
touching a single line of application code.
--
Cosimo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
