Moxie seems to be very Moose-esque but the title is pretty uninformative,
Moxie - Not Another Moose Clone
Reading it, it seems to use B::CompilerPhase::Hook for extra voodoo. What is the end purpose of this library? If it's not a Moose clone, what does it intend to do differently?
The description seems pretty vague too,
reference implementation for an object system built on top of a set of modules.
Is there a specification for Moxie?
Moxie is the Moose-like system that Stevan Little hopes to get included in the Perl core at some point.
This video from last month's TPC explains it all in a lot more detail - https://www.youtube.com/watch?v=w5U7eoeuO90
Related
I"m having to work with legacy code (mostly CFML) with very little or no documentation, no domain model of any sort to follow either.
To start building some sense out of it, I though 'start keeping notes', then wondered if plain old journal and pencil for text notes would do. Maybe a text document (searchable). Or is it best to take the plunge and UML the beast over time? If that's an overkill on one hand, on the other I repeatedly find myself feeling around the elephant over and over again. How do you build a up a map of the territory?
Sorry for the late answer, but I've ended in situations like this couple of times before. I'd suggest you not to create UML for that, since it will take much time and this code is not very nice, as you've noted (no domain model, no structure).
You could use pen and paper, or text file. Browse through the code, find the most important parts for you and write down where it is located, with some description. If there is no data structure, you could use file name, module, line number, etc. After spending some time doing this, you will have something like navigation plan for the part of the system and general understanding of how it works.
Also, you should refer to this question, there are some answers that can be useful.
I've just started getting into Catalyst, and I've been finding it really helpful. One of my favorite things about it was TTSite in that it got me going fast and gave me something to develop with without just black text (and it required no work from me to setup). However, I've been reading in a lot of places that it's buggy, or even deprecated as mentioned here on the actual Catalyst tutorial. However I've found it nothing but helpful and have had no issues, so basically I'm wondering is there reason for me to be worried and not use it? And if so, does anyone know of a similar alternative that kind of gives you a base template set up to work within? Thanks a lot!
I don't think TTSite is officially deprecated in terms of support .. it is still included in the Catalyst::View::TT distribution as of 0.39 (released 10-April 2012). I suspect it is more a case of some developers disliking the base templates that are provided and TTSite no longer being recommended as part of the default Catalyst tutorial.
TTSite provides a very simple base that has some quirks. For example, the context object is called Catalyst instead of c, and the use of TT's WRAPPER command can get in the way of AJAX and non-html views.
More background reading:
Discussion on the Catalyst-Dev mailing list regarding changing the Catalyst tutorial from TTSite to straight TT
Catalyst wiki: disabling TT wrapper for AJAX requests
A blog post on TTSite including changing Catalyst context reference to c
A modern base theme would probably start with something like Bootstrap or one of the 960 Grid HTML/CSS frameworks. I'm not aware of an actively maintained Catalyst::View helper that would be a better replacement for TTSite, but also don't find it too onerous to drop in the latest version of Bootstrap :)
I started using Dist::Zilla several months ago. However, at YAPC::NA someone mentioned that they use ShipIt instead. Then today I noticed a .shipit file in miyagawa's cpanminus directory on github, so I decided to look into it some more...
My initial impression is that ShipIt has a subset of what is available with Dist::Zilla, but I don't want to jump to conclusions. So, for those who have had experience with both, what are the strengths/weaknesses of ShipIt vs Dist::Zilla?
crossposted at perlmonks
I'm the author of Dist::Zilla.
I evaluated ShipIt pretty extensively before choosing to go ahead and write Dist::Zilla, and initially they covered almost exactly the same problem space: doing all the boring grunt work of building and uploading a CPAN distribution. All of the features that Dist::Zilla now has beyond ShipIt are later additions, more or less.
If you only need the features of ShipIt, I still advise you to strongly consider Dist::Zilla, for one very simple reason: hackability. If I had been able to not write something new, I would've used ShipIt, but I found it to be underdocumented and difficult to extend. Its plugins were not generic enough and the core behavior made too many assumptions about how you'd like to work.
Dist::Zilla was inspired specifically by this problem: it turned everything into a plugin, and every plugin was given a very, very small interface so that its assumptions would be forcibly limited.
One benefit of ShipIt over Dist::Zilla is that ShipIt has (to the best of my knowledge) no plugins that will alter the way you actually write your code. This means your documentation will still look the same, you will still have a Makefile.PL, and so on. Some hackers don't like that so many DZ-based dists fundamentally change the assumptions of how to test and build CPAN code from its source repository. ShipIt will never change that.
It's possible to avoid using any such plugins with Dist::Zilla, but in general my experience is that people do use them, almost always, in one form or another.
As far as I can tell, my initial impressions were correct.
ShipIt provides functionality for releasing distributions:
keeping track of version numbers
integrating with version control
uploading to CPAN
displaying the changelog file in an editor so that you can edit it before release.
Dist::Zilla, by default, provides the ability to upload distributions to CPAN with a single command (i.e. dzil release). Dist::Zilla also has functionality for creating new distributions (i.e. dzil new My::New::Module). It also automatically generates so many of the files that I used to have to maintain by hand.
Using plugins, Dist::Zilla seems able to provide most, if not all, of the functionality available with ShipIt. It is also relatively easy to add brand new features using plugins.
There are quite a number of modules on CPAN relating to the creation and manipulation of .pdf files, and I'm hoping this community can save me some time going down blind alleys.
I am looking to create .pdf files from scratch, with only simple formatting such as bold/italic and left/right/center justify. Being able to use a template file would nice, from an MVC perspective, but if the best module doesn't support that, I'm ok. I want the best module for my narrow problem set.
Edit: let's add the constraint that it does have to be a Perl module, if not a pure-perl solution. Thanks for answers thus far!
Update: PDF creation is one difficult problem to decide how to approach. In addition to the good suggestions here, there seems to be about 1,000 different ways to solve this, and knowing which solution(s) to invest your time in is a real challenge. It is easy to acquire dependencies on outside executables in the process of building this solution, which is why I have been favoring doing everything in Perl if possible.
I went down the road of trying to use PDF::Create but found it too limiting. You have to give coordinates to place each string of text and there is no built-in concept of text wrapping... this is all work you have to do. Impossible amount of overhead for my task.
I am now using PDF::API2, which is much more powerful than PDF::Create, but still demands the PDF be assembled at a troublingly low level. Luckily, there is some help online. See Rick Measham's excellent PDF::API2 tutorial with accompanying text_block() subroutine, which thankfully does the heavy lifting on the text wrap problem.
Unless you see another update here, this is the solution that ended up working for me.
I'm the author of the CPAN module CAM::PDF which is definitely not the best tool for this job -- it's designed for high-performance editing, not creating.
Among free PDF creation libraries, I like PDF::API2 the best. It has a very rich feature set and good encryption support (inspired by CAM::PDF I might add!) The author, Alfredo, manages a popular email list. People sometimes complain about documentation, but I've found it to be adequate.
Among commercial libraries, I've had good experiences with pdflib.
Three modules for creating PDF come to mind (in no particular order)....
PDF::API2
PDF:::Create
PDF::Template
PDF::Template gives you that template option you maybe hankering for? PDF::Create seems more straightforward (at least from the docs) and may meet your "simple formatting" requirement more adequately.
However if you want to know what the "community" thinks then only PDF::API2 gets a rating on CPAN Ratings coming in with 4 out of 5 stars overall score.
Hope that helps.
PS. Disclaimer: I've not used any of these modules. In past I've always gone for XML/XSLT/XSL-FO using Apache FOP with Perl being used to create the initial XML data. This can be an overkill for something small and not always ideal if you want to embed PDF generation into your Perl app.
PPS. So I'll also be looking at these CPAN PDF modules at some point in near future!
Does it have to be a Perl module? You could always use LaTeX and convert that to PDF. Not quite as straight-forward, but it is another option.
G'day Marcus,
Glad you found the tutorial. I do a lot of work in PDF::API2, so if there's anything I can help with, just let me know.
Naturally, I recommend PDF::API2!
There's a guy Jay Hannah, who's currently turning the text block into a module for CPAN that does exactly what you want: bold, italic, etc. If you check the mailing list, you'll see his posts at the top.
Cheers!
Rick Measham
Yeah, tough to answer without knowing exactly what your constraints are. If pure-Perl is not a necessity, I'd be inclined towards DocBook.
The initial markup you'll generate can be very simple XML; and the transformation requires just an XSL processor and shelling out to something like Apache's FOP.
how to save a online pdf file using perl?
http://www.nwcc.bc.ca/FNC/pdfs/Stepping%20Stones%20to%20improved%20Relationships%20-%20web.pdf
I am using file::download. but the problem is its not downloading url with url encoded strings.
sharma
Are there any libraries out there that do this? Playing around with Common Lisp it seems like this would be one of the most useful things to lower barrier of entry for newcomers. ASDF seems mostly designed for deployment, not for rapid prototyping and development. Following threads on comp.lang.lisp it seems like people agree that CL's package system is powerful, but lacks the ease of something like Python's dead simple module system. It is FAIL in the sense that it's designed for power not usability.
Glad to know if I'm wrong. If I'm right, I'm stunned that noone has tried to build a Python module-like system on top of ASDF.
Zach Beane wrote how he nowadays starts new Common Lisp projects by using Quicklisp and Quickproject. This might be along the lines you want.
Not sure if it's ready for prime time or whether it fits your requirements at all, but here's a link to XCVB.
I don't know. I mostly use ASDF for my in-development compilation needs. Once you notice that you'd benefiot from more than one source file, open <projectname>.asd, slap in a basic ASDF system definition template and start slapping filenames in. As and when you notice a cross-file dependency, update the dependency list.
But, then, I use the exact same method dealing with Makefiles (yes, I know there are automatic dependency checkers that can do it for you, but since I mostly code on my own, it's easier to just amend the Makefile/ASDF definition as I go).
In SBCL, there's a hook on REQUIRE that checks for ASDF systems, so you end up with something that is about as convenient as Python's import, but somehow I suspect that is not what you meant.
This may not be the answer you want, but clearly you have some idea of what you want in a module system. Have you considered creating one yourself? That is, taking your limited domain, your limited requirements, your environment and simply pounding out whatever abstractions will quickly make your life easier?
That's one of the key benefits of Lisp I'm sure you know, is that these simple abstractions and little tools are typically very easy to craft in Lisp.
I'm not suggesting solving everyone who has a problem with the package system or ASDF, I'm simply suggesting solving your own problem as you understand it, which is likely simpler and smaller than some more powerful larger scope.
There is Mudballs now, too.
If you're looking for a piece of software to add this functionality to then it's a good bet.
If you want a command line tool that just uses bash to generate new common lisp project directory and file layouts, you may find one that I created for myself useful: lispproject. If it doesn't match your needs, go ahead and fork it or the repo it gets it templates from to suit your needs: lisp-project-template. Look at the sh file in lispproject repo to see how the templates are used. Also, please note that you may need to adjust the calls to sed to fit your platform as I am using this on macOS. Alternative sed calls are in the main script but just commented out if you need them.
it's designed for power not usability
that's how most Lisp gurus like it.