Closed mmontone closed 9 years ago
I've also removed SBCL specific code too, and works on CCL now. Haven't tested on other implementations yet.
First off: thanks for all your work on your fork of burgled-batteries! It's nice to see that even though I've unfortunately been neglecting it, it's still getting love.
You are not the first person I've read mention that burgled-batteries is available from Quicklisp. But so far as I know, b-b is not now nor has ever been available through Quicklisp. Certainly, I see no reference to it in quicklisp-projects. Am I missing it?
Anyway, looking over your fork briefly:
There are absolutely some things I'd love to pull in! For instance, it appears you made (asdf:test-system "burgled-batteries") work. Sweet!
I see you converted the tests to use an actual test framework (lift). Also cool! Saves me the trouble of evaluating the bajillion CL test frameworks and picking one for myself. Love it.
Moved the lisp files into src/. I don't really care one way or the other, so no objections there.
But the really big thing you've added--the python syntax--I'm not sold on. If I wanted to use Python's syntax, I'd have just used Python! :P Which is not to say I can't be convinced, but it's definitely not the direction I had in mind when I started.
I'd much rather have the syntax stuff available through a separate project, rather than in burgled-batteries proper. On the other hand, you've put in a lot more effort recently than I have (still haven't written that lisp-package-generation-from-python-module-introspection, have I?), so I'm open to being convinced otherwise.
On 06/02/15 02:09, pinterface wrote:
First off: thanks for all your work on your fork of burgled-batteries! It's nice to see that even though I've unfortunately been neglecting it, it's still getting love.
You are not the first person I've read mention that burgled-batteries is available from Quicklisp. But so far as I know, b-b is not now nor has ever been available through Quicklisp. Certainly, I see no reference to it in quicklisp-projects. Am I missing it?
I think you are right. I don't know why I thought it was. Maybe it was just my wish :)
But the really big thing you've added--the python syntax--I'm not sold on. If I wanted to use Python's syntax, I'd have just used Python! :P :) But there's a difference. You get to interact with your Lisp variables and data directly, and there's no need to import things in advance. You can access any module, function, method, property dynamically.
Which is not to say I can't be convinced, but it's definitely not the direction I had in mind when I started.
I'd much rather have the syntax stuff available through a separate project, rather than in burgled-batteries proper. On the other hand, you've put in a lot more effort recently than I have (still haven't written that lisp-package-generation-from-python-module-introspection, have I?), so I'm open to being convinced otherwise.
Actually, I think the idea of having the syntax in a separate project is good. It may be a cleaner way of doing things. I see quite lots of other projects do that.
So, this is what I can try to do, please correct me if you think differently or have other ideas:
1) Leave b-b as it is, but with some of my changes, like the automated tests. (burgled-batteries) 2) Create a separate project with the syntax thing (burgled-batteries.syntax) 3) Add both projects to quicklisp :)
What do you think?
On 2015.02.06 06:49, Mariano Montone wrote:
So, this is what I can try to do, please correct me if you think differently or have other ideas:
1) Leave b-b as it is, but with some of my changes, like the automated tests. (burgled-batteries) 2) Create a separate project with the syntax thing (burgled-batteries.syntax) 3) Add both projects to quicklisp :)
What do you think?
Sounds like a pretty good plan to me. :)
Great!
I've already separated the packages.
Here are my changes to your package that are no syntax related: https://github.com/mmontone/burgled-batteries. Feel free to cherrypick whatever you want, my syntax package works with your current version of b-b too. Or if you want all of the changes in, I can create a pull request.
And here is my syntax package: https://github.com/mmontone/burgled-batteries.syntax
I'll be looking at how to add these libraries to Quicklisp now :)
Cheers!
Created a pull request just in case: https://github.com/pinterface/burgled-batteries/pull/5
Excellent. Thanks for all your work! I'm going to close #5 and cherry-pick--mostly for the git practice, but also to do a smidge of cleanup (convert tabs to spaces, fix a duplicate test name, minor stuff like that).
Didn't quiiiiiite get it done this weekend, but I'm working on it! (It's been a while since I've fired up SLIME. Feels good, man.)
On 09/02/15 04:32, pinterface wrote:
Excellent. Thanks for all your work! I'm going to close #5 and cherry-pick--mostly for the git practice, but also to do a smidge of cleanup (convert tabs to spaces, fix a duplicate test name, minor stuff like that).
Didn't quiiiiiite get it done this weekend, but I'm working on it! (It's been a while since I've fired up SLIME. Feels good, man.)
— Reply to this email directly or view it on GitHub https://github.com/pinterface/burgled-batteries/issues/4#issuecomment-73467650.
haha :)
I use emacs magit. M-x magit-cherry. Choose branches. Then 'A' key to apply commits from the magit-cherry buffer.
On 2015.02.09 06:23, Mariano Montone wrote:
haha :)
I use emacs magit. M-x magit-cherry. Choose branches. Then 'A' key to apply commits from the magit-cherry buffer.
Apparently I need to update my version of magit. That would have been handy!
Anyway, I've pushed most of your changes. Please double-check my work and feel free to complain if I missed anything or messed something up while I was altering your patches. :)
I haven't included WITH-PYTHON yet. Is that to aid interactive use? It looks like it'd have some ... nonintuitive behaviors if used generally--e.g., (with-python (with-python &body)) ; won't run inner body or (startup-python) (.is-initialized) ; => t (with-python &body) (.is-initialized) ; => nil (!) That's fixable, but I'd like to make sure I understand the motivation.
The motivation for WITH-PYTHON was to have macro that helped users with local Python activation and also to encourage encapsulation.
Imagine a function that uses Python and its icalendar library. You could write it like this:
(defun get-calendar ()
(with-python
....)))
So, with-python would help the implementator with starting up the Python interpreter and stopping it when unwinding. And also, (this is the encapsulation part) there's no need to enable the Python interpreter globally. The other parts of the program don't need to know that the calendar function accesses Python, they just use it as another function.
All of this if the macro works of course! I will look at the problems you mention and try to fix them. But it is ok for me if you decide not to include the macro.
Cheers!
Forgot to mention: your changes compile and work just fine!
WITH-PYTHON feels a little dubious--even if it works for a function like your #'GET-CALENDAR example, it's probably not going to work with very much generality. Top-level definitions, for instance, may be problematic. E.g.,
(with-python
(defpyfun ...))
Nor is it likely to be very helpful for anything that actually wants/needs to pass pointers around.
But! You've been awesome, so I'm deferring to your judgement here. I've fixed the issues I mentioned in my previous comment and pushed it. Enjoy! And thanks for all the patches!
On 11/02/15 11:57, pinterface wrote:
WITH-PYTHON feels a little dubious--even if it works for a function like your #'GET-CALENDAR example, it's probably not going to work with very much generality. Top-level definitions, for instance, may be problematic. E.g.,
(with-python (defpyfun ...))
Nor is it likely to be very helpful for anything that actually wants/needs to pass pointers around.
But! You've been awesome, so I'm deferring to your judgement here. I've fixed the issues I mentioned in my previous comment and pushed it. Enjoy! And thanks for all the patches!
— Reply to this email directly or view it on GitHub https://github.com/pinterface/burgled-batteries/issues/4#issuecomment-73894078.
Now that I think of these issues, I think you are right. So...feel free to revert the patch!
Anyway, out of interest. What do plan to do with Burgled Batteries? What are you working on in general? Do you still work with Common Lisp?
On 2015.02.11 09:15, Mariano Montone wrote:
Anyway, out of interest. What do plan to do with Burgled Batteries? What are you working on in general? Do you still work with Common Lisp?
I'd very much like to check off some of the TODOs in the readme, and build some libraries on top of b-b (e.g., finish wrapping feedparser).
Alas, much to the detriment of my sanity, though to the betterment of my bank account, my current employer pays me to write PHP. I generally end up pretty tuckered by the end of the day, so it's unlikely I'll be doing much of anything in the Lisp world until I'm next between jobs.
Which is sad, but I gotta feed my cat somehow. :)
Thanks again for the patches, btw!
Hi!
What would you think of pulling my changes to your repository so that things are available from the official quicklisp burgled-batteries package?
I've added embedded Python syntax and automated tests.
You can check it here: https://github.com/mmontone/burgled-batteries
Do you think you have some time to review what I did and see if you agree with my changes? Look at the README, the tests, and the embedded syntax, that's the new things, mostly.
Cheers, Mariano