With your changes on your local master and the github master reset to the old master, do a "git rebase -i origin/master". Squash all your commits into one, save and push to github. That should do. Let us know if it does not.
-Hans
Am 28.05.2010 20:49 schrieb "Frederico Muñoz" fsmunoz@gmail.com:
Hi,
2010/5/28 Hans Hübner hans.huebner@gmail.com:
I'd prefer if you could eventually rebase your commits and squash them into one before I pull th...
I've tried to, but I'm afraid I probably didn't do it correctly. I reset my master by using upstream/master, forced the push to github, switch to my wip branch, did a git rebase master. The switched to my local master, merged the wip branch, and did a push.
From reading the docs I was expecting something more akin to a single
commit, which isn't the case. I'm likely missing a step, or doing one to many.
Regards,
Frederico
Hi,
Thank you for the assistance, as I said I'm new to git.
2010/5/28 Hans Hübner hans.huebner@gmail.com:
With your changes on your local master and the github master reset to the old master, do a "git rebase -i origin/master". Squash all your commits into one, save and push to github. That should do. Let us know if it does not.
It worked, I only had to keep one of the changes as "pick", and the others as "squash". Rebased with master, then merged my wip branch with master, then pushed. I think it worked as expected, all changes are in one commit.
Regards,
Frederico
Hi Frederico,
the rebase seems to have worked fine. I reviewed your changes and made a few very minor comments in github. If you can take care of them, I'll happily pull into my repository, thanks!
Cheers, Hans
2010/5/28 Frederico Muñoz fsmunoz@gmail.com:
Hi,
Thank you for the assistance, as I said I'm new to git.
2010/5/28 Hans Hübner hans.huebner@gmail.com:
With your changes on your local master and the github master reset to the old master, do a "git rebase -i origin/master". Squash all your commits into one, save and push to github. That should do. Let us know if it does not.
It worked, I only had to keep one of the changes as "pick", and the others as "squash". Rebased with master, then merged my wip branch with master, then pushed. I think it worked as expected, all changes are in one commit.
Regards,
Frederico
Hi Hans,
2010/5/29 Hans Hübner hans.huebner@gmail.com:
Hi Frederico,
the rebase seems to have worked fine. I reviewed your changes and made a few very minor comments in github. If you can take care of them, I'll happily pull into my repository, thanks!
Fixed in the latest commit; while the modifications I made are in hindsight relatively minor at one point I had debug output sprinkled all over in order to understand what was going on (hence also the differences in indentation in places where there are no changes... I used the default emacs indentation, but if you have special standards I will happily add them to my init.el when working on the tree).
Regards,
Frederico
Hi Frederico,
I pulled your changes into my repository, thanks again!
-Hans
2010/5/29 Frederico Muñoz fsmunoz@gmail.com:
Hi Hans,
2010/5/29 Hans Hübner hans.huebner@gmail.com:
Hi Frederico,
the rebase seems to have worked fine. I reviewed your changes and made a few very minor comments in github. If you can take care of them, I'll happily pull into my repository, thanks!
Fixed in the latest commit; while the modifications I made are in hindsight relatively minor at one point I had debug output sprinkled all over in order to understand what was going on (hence also the differences in indentation in places where there are no changes... I used the default emacs indentation, but if you have special standards I will happily add them to my init.el when working on the tree).
Regards,
Frederico
Hi Hans,
2010/5/30 Hans Hübner hans.huebner@gmail.com:
I pulled your changes into my repository, thanks again!
Splendid, I'm happy that my trivial work has been useful!
I'm going to further test the changes and come up with a small list of enhancements/doubts, I'll try to be as succinct as possible. At this stage I only have one of each, which I will put here just to exemplify:
1) As it is write-to-xml defaults to *standard-output*. It seems sensible to me to do so, and one can always provide a different stream. The tutorial, however, seems to indicate that write-to-xml should return the XML output as a return value... not sure if adapting the tutorial is the best course, or changing the way write-to-xml works by using a string stream and returning the output (I've tried, it works, but returns everything escaped, which is aesthetically doubtful) 2) As it is one can't use lists (including cons) as slot values. I've found this by having a "location" slot in my "army" class which is represented by a cons like (X . Y). This returns an error (since the test is made with consp, but the cdr isn't a list). For cons the "fix" is easy (e.g. use alexandria's proper-list-p), but when a slot value is really a list the output isn't as expected: a class which has '(1 2 3) has a slot value will produce:
<element>1</element> <element>2</element> <element>3</element>
instead of what would be expected:
<element>'(1 2 3)</element>
I'm trying to find a way to deal with this. Ultimately one can always say that list values shouldn't be used.
Again, there is no pressure in terms of replying to this observations: I'll continue to tackle them as I see fit (right or wrong), and then provide something more concrete which can be reviewed.
Regards,
Frederico
2010/5/31 Frederico Muñoz fsmunoz@gmail.com:
- As it is write-to-xml defaults to *standard-output*. It seems
sensible to me to do so, and one can always provide a different stream. The tutorial, however, seems to indicate that write-to-xml should return the XML output as a return value... not sure if adapting the tutorial is the best course, or changing the way write-to-xml works by using a string stream and returning the output (I've tried, it works, but returns everything escaped, which is aesthetically doubtful)
I would stay with WRITE-TO-XML writing to a stream that defaults to *STANDARD-OUTPUT*. If you like, add a trivial wrapper WRITE-TO-XML-STRING that returns an XML string instead. Writing to a string consumes more memory and it would be stupid to first serialize into a string when one really wants to write to a stream.
- As it is one can't use lists (including cons) as slot values. I've
found this by having a "location" slot in my "army" class which is represented by a cons like (X . Y). This returns an error (since the test is made with consp, but the cdr isn't a list). For cons the "fix" is easy (e.g. use alexandria's proper-list-p), but when a slot value is really a list the output isn't as expected: a class which has '(1 2 3) has a slot value will produce:
<element>1</element> <element>2</element> <element>3</element>
instead of what would be expected:
<element>'(1 2 3)</element>
I do not think that a quoted list in Lisp syntax is expected in XML output. I rather think that the current behavior that you describe is correct, and the XML deserializer should combine the individual elements that occur multiple times into one list. The XML produced should, by default, try to serialize everything into proper XML and not use Lisp data formats.
Cheers, Hans
Hi Hans,
Thanks for the comments!
2010/6/1 Hans Hübner hans.huebner@gmail.com:
I would stay with WRITE-TO-XML writing to a stream that defaults to *STANDARD-OUTPUT*. If you like, add a trivial wrapper WRITE-TO-XML-STRING that returns an XML string instead. Writing to a string consumes more memory and it would be stupid to first serialize into a string when one really wants to write to a stream.
Yes, good idea. I've added another macro that does exactly that.
I do not think that a quoted list in Lisp syntax is expected in XML output. I rather think that the current behavior that you describe is correct, and the XML deserializer should combine the individual elements that occur multiple times into one list. The XML produced should, by default, try to serialize everything into proper XML and not use Lisp data formats.
I had the wrong approach, and what you say makes much more sense. I've played around with exporting/importing, and by specifying adequate parsers for the slots my example works as expected, in the sense that the exported XML produces the correct values when imported.
At this stage the only other issue I can think of is the containment parsing, which isn't being done (I mean, the containment slot isn't being initialised to :* or :+ depending on the DTD, and so any multi-element slot only contains the last element). It works correctly when one explicitly sets the :container though, so the issue is only with setting the initial value.
So, my plans at this stage are:
1) Tackle the containment issue 2) In the end of the changes update the tutorial 3) Eventually look at the "xml-update" file which is lingering there, could be useful.
I'll come back when I have something worth seeing. As it is right now I have successfully used XML impex to export and import objects, almost in a datastore kind of way.
Regards,
Frederico