I fscked the patches for various reason, so they are all like they are now.. Should still apply on the fresh git.
I'll forward this message I originally sent to skeezix, since there have been no activity:
---------- Forwarded message ----------
This patch should apply on the fresh clone of http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ...
It adds few stuff more for package support, and the last patch fixes leaks on libpnd discovery. However the discovery example will still leak however, as it does not destroy disco objects. I can send patch to it too later, as some people might use it as reference.
I kinda screwed the patches, but they should still apply. So make sure you don't apply the old ones :)
http://dl.dropbox.com/u/15640770/libpnd_patches.tar
Also why do I keep trying to use vim bindings on gmail?
I've looked at these patches and they look ok, except for adding new fields to existing structures, won't that break binary compatibility with existing apps that use libpnd? Granted, stuff that comes with firmware will get recompiled and be ok, but maybe there is something else. You could probably add new stuff at the end of the structures to avoid this problem. There is also minor indentation differences between your and surrounding old code.
So I've applied patch 3 and left out all *_version_* stuff. For this you need to either fix it or distract skeezix from his twins and make him say modifying those structs is ok. You'll also need to rebase and resend parts of patch3 that I left out and probably merge all *_version_* patches, there is no real need for splitting of what's left of them.
On Sat, Aug 27, 2011 at 3:37 AM, Jari Vetoniemi mailroxas@gmail.com wrote:
I fscked the patches for various reason, so they are all like they are now.. Should still apply on the fresh git.
I'll forward this message I originally sent to skeezix, since there have been no activity:
---------- Forwarded message ----------
This patch should apply on the fresh clone of http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ...
It adds few stuff more for package support, and the last patch fixes leaks on libpnd discovery. However the discovery example will still leak however, as it does not destroy disco objects. I can send patch to it too later, as some people might use it as reference.
I kinda screwed the patches, but they should still apply. So make sure you don't apply the old ones :)
http://dl.dropbox.com/u/15640770/libpnd_patches.tar
Also why do I keep trying to use vim bindings on gmail? _______________________________________________ Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On Sat, 27 Aug 2011, Grazvydas Ignotas wrote:
# I've looked at these patches and they look ok, except for adding new # fields to existing structures, won't that break binary compatibility # with existing apps that use libpnd? Granted, stuff that comes with # firmware will get recompiled and be ok, but maybe there is something # else. You could probably add new stuff at the end of the structures to # avoid this problem. # There is also minor indentation differences between your and # surrounding old code.
Generally new struct additions should always be at the bottom; for a couple patches that have come in, I think I massaged them that way.
On the other hand, few people have leveraged internal structures of libpnd too much, so we can usually get away with such things, but still best avoided, but disco_t is the sensitive interface struct.
# So I've applied patch 3 and left out all *_version_* stuff. For this # you need to either fix it or distract skeezix from his twins and make # him say modifying those structs is ok. You'll also need to rebase and # resend parts of patch3 that I left out and probably merge all # *_version_* patches, there is no real need for splitting of what's # left of them.
Ah, many thanks notaz!
We still need to go through the exercise of breaking libpnd into libpnd and libpandora -- on the off chance pnd-related stuff may be useful off-pandora, and to keep Pandora specific stuff in one place, but I think I don't wan tot tackle such a thing ('rock the boat') at this point for myself. (I'm "on call", and not interested in leaving things in a broken state.)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Yes, the patches should be well tested and are in fact used by milkyhelper and panorama (Also valgrinded against 300+ PND's). And yeah, there were few bad patches mostly because the libpnd way of doing things was quite confusing. But yeah, I sorted it all out eventually. I agree on adding the version information to the bottom of the struct, heck there should not be even reason why the disco struct would not give all the information from PND.
But yeah, I'll lurk around and see what future holds.
2011/8/29 skeezix skeezix@skeleton.org:
On Sat, 27 Aug 2011, Grazvydas Ignotas wrote:
# I've looked at these patches and they look ok, except for adding new # fields to existing structures, won't that break binary compatibility # with existing apps that use libpnd? Granted, stuff that comes with # firmware will get recompiled and be ok, but maybe there is something # else. You could probably add new stuff at the end of the structures to # avoid this problem. # There is also minor indentation differences between your and # surrounding old code.
Generally new struct additions should always be at the bottom; for a couple patches that have come in, I think I massaged them that way.
On the other hand, few people have leveraged internal structures of libpnd too much, so we can usually get away with such things, but still best avoided, but disco_t is the sensitive interface struct.
# So I've applied patch 3 and left out all *_version_* stuff. For this # you need to either fix it or distract skeezix from his twins and make # him say modifying those structs is ok. You'll also need to rebase and # resend parts of patch3 that I left out and probably merge all # *_version_* patches, there is no real need for splitting of what's # left of them.
Ah, many thanks notaz!
We still need to go through the exercise of breaking libpnd into libpnd and libpandora -- on the off chance pnd-related stuff may be useful off-pandora, and to keep Pandora specific stuff in one place, but I think I don't wan tot tackle such a thing ('rock the boat') at this point for myself. (I'm "on call", and not interested in leaving things in a broken state.)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Mon, 29 Aug 2011, Jari Vetoniemi wrote:
# heck there should not be even reason why the disco struct would not # give all the information from PND.
It wasn't done at random; best to consisder a projects history when putting code in (just like its a best practice to make new code fit existing code in style to avoid having 30 peoples fingerprints all over it, its usually good idea to find out why something is the way it is.) Just as a typical container class doesn't expose the inner workings of the structure unless you ask to see it .. the user often doesn't need to see it all unless they want to.
Permit me to meander, it may be useful to be on record so readers down the road know why things are the way they are.
But I might have been wrong there with disco-t and pxml-t, who knows; recall that when this stuff was designed, we were already past 'release date' and thought we had only weeks to build the entire thing :)
The reason I did that (perhaps unwisely? who knows ;) was that the PXML could include a 'lot' of stuff, and certainly stuff 'light users' (such as launcher menus) may not want to know about (witness, packages and so on. At the time, I was thinking about long descroptions versus short descroiptions and multi-language .. I figured that if disco was in (say) English context, and quite possible apps might have dozens of length descriptions in many languages and we are on a constrained device, it best not to return all of them, say.) I had rather figured two interfaces that you can see..
- discovery -- find apps, and report 'minimal' info (which is now a lot of info, but originalyl ewas just a half dozen fields); consider minimenu or even a simpler menus -- use cases are.. . get me a list of apps (or scan one app) . run an app ... doesn't care about icons or packages, etc
- pxml-parser -- given a discovery return, if you want more info, go ask pxml parser to get you the full details for a given app(s); it had been intended that to keep speed up, this would be cached, but I never got so far as to release any caching code for discovery or PXML, so fetching each PXML is slow still due to the mount/pull/unmount problem (something else we wanted to address :) Use case was.. . get me a list of apps (or scan one app) . want more? pull the pxml (slow, or cached, internally by libpnd) . do something (show it, run it..) . remember, to get icon or the like, it also has a mount, so its not so far fetched to then parse the PXML then. Minimenu does its own caching, for instance, too.
So the goal was separation -- light pull, versus comprehensive per unit pull; instead, now we've got a lot of the data in disco-t (to save on extra PXML pulls), which means we have disco-t and pxml-t with multiple get/setter type functions, data copying and so on. Right now disco-t still doesn't have all the multilanguage stuff and all that, but we're rather leaning that way it seems, which may or may not be wise, who knows.
To me, it seems like.. if we're going the route of disco-t being a clone of pxml-t, maybe the two handles should be the same thing, so one set of getter/setters... or we go back to the way it was originally intended. ie:Whats the point of articulation here -- get it all in one swoop, or get a little bit and pull as needed; whats are usual use case, so we can best serve it?
(Who is the audience for libpnd? So far it is things like minimenu, pndnotifyd, milky and pndstore .. the libpandora type stuff for IO/cpu-setting/etc is really considered separate.)
If we look at libpnds audience as tools like that, pretty low level stuff, that maybe pushes us towards the all-in-one-swoop mentality; at the time, libpnd/libpandora were thought of as being more linked to a lot of apps to make dev porting easier (just use the ready to go IO stuff, say) so I wanted to keep it mroe general, hence the leaning towards the quick swoop and pull detail later.
Hindsight always lets you review your guesses :)
Rigth now we're sort of in the middle.
But thats okay -- evolution happens, and being pragmatic, we use what works and try to aim for the best. Truly clean code only happens in textbooks ;)
# But yeah, I'll lurk around and see what future holds.
Well, you're making it, so hope so :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
But yeah, I sorted it all out eventually. I agree on adding the version information to the bottom of the struct, heck there should not be even reason why the disco struct would not give all the information from PND.
But yeah, I'll lurk around and see what future holds.
Well if you need those things for your stuff to work you should just patch them in now, otherwise lurking/waiting for someone else may get too close to infinite. Reworking those few patches to add stuff at the end and resending doesn't sound hard.
Done and done, Includes version patch, more leak fixes on libpnd and discovery test leaks fixed. You should get 0 bytes leaked when you run with valgrind.
Cheers.
2011/8/30 Grazvydas Ignotas notasas@gmail.com:
On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
But yeah, I sorted it all out eventually. I agree on adding the version information to the bottom of the struct, heck there should not be even reason why the disco struct would not give all the information from PND.
But yeah, I'll lurk around and see what future holds.
Well if you need those things for your stuff to work you should just patch them in now, otherwise lurking/waiting for someone else may get too close to infinite. Reworking those few patches to add stuff at the end and resending doesn't sound hard.
Hey, Just noticed that the buffer freeing wasn't quite sane on the 0002 patch, so here is bit better version.
Cheers.
2011/8/30 Jari Vetoniemi mailroxas@gmail.com:
Done and done, Includes version patch, more leak fixes on libpnd and discovery test leaks fixed. You should get 0 bytes leaked when you run with valgrind.
Cheers.
2011/8/30 Grazvydas Ignotas notasas@gmail.com:
On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
But yeah, I sorted it all out eventually. I agree on adding the version information to the bottom of the struct, heck there should not be even reason why the disco struct would not give all the information from PND.
But yeah, I'll lurk around and see what future holds.
Well if you need those things for your stuff to work you should just patch them in now, otherwise lurking/waiting for someone else may get too close to infinite. Reworking those few patches to add stuff at the end and resending doesn't sound hard.
Bleh, included the old patch... Sorry about that.
2011/8/31 Jari Vetoniemi mailroxas@gmail.com:
Hey, Just noticed that the buffer freeing wasn't quite sane on the 0002 patch, so here is bit better version.
Cheers.
2011/8/30 Jari Vetoniemi mailroxas@gmail.com:
Done and done, Includes version patch, more leak fixes on libpnd and discovery test leaks fixed. You should get 0 bytes leaked when you run with valgrind.
Cheers.
2011/8/30 Grazvydas Ignotas notasas@gmail.com:
On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
But yeah, I sorted it all out eventually. I agree on adding the version information to the bottom of the struct, heck there should not be even reason why the disco struct would not give all the information from PND.
But yeah, I'll lurk around and see what future holds.
Well if you need those things for your stuff to work you should just patch them in now, otherwise lurking/waiting for someone else may get too close to infinite. Reworking those few patches to add stuff at the end and resending doesn't sound hard.
On Wed, 31 Aug 2011, Jari Vetoniemi wrote:
# Bleh, included the old patch... Sorry about that.
Looks good; I'll apply later on today.
jeff
# # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > Hey, # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > patch, so here is bit better version. # > # > Cheers. # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # >> Done and done, # >> Includes version patch, more leak fixes on libpnd and discovery test # >> leaks fixed. # >> You should get 0 bytes leaked when you run with valgrind. # >> # >> Cheers. # >> # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # >>>> But yeah, I sorted it all out eventually. I agree on adding the # >>>> version information to the bottom of the struct, # >>>> heck there should not be even reason why the disco struct would not # >>>> give all the information from PND. # >>>> # >>>> But yeah, I'll lurk around and see what future holds. # >>> # >>> Well if you need those things for your stuff to work you should just # >>> patch them in now, otherwise lurking/waiting for someone else may get # >>> too close to infinite. Reworking those few patches to add stuff at the # >>> end and resending doesn't sound hard. # >>> # >> # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
OKay, to be specific here..
Earlier email included patches 0001/0002/0003
Next email included redone patch 00002 --
So I should still apply 0001/replacement-0002/0003, and they should still mesh nicely together, right?
jeff
On Wed, 31 Aug 2011, Jari Vetoniemi wrote:
# Bleh, included the old patch... Sorry about that. # # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > Hey, # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > patch, so here is bit better version. # > # > Cheers. # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # >> Done and done, # >> Includes version patch, more leak fixes on libpnd and discovery test # >> leaks fixed. # >> You should get 0 bytes leaked when you run with valgrind. # >> # >> Cheers. # >> # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # >>>> But yeah, I sorted it all out eventually. I agree on adding the # >>>> version information to the bottom of the struct, # >>>> heck there should not be even reason why the disco struct would not # >>>> give all the information from PND. # >>>> # >>>> But yeah, I'll lurk around and see what future holds. # >>> # >>> Well if you need those things for your stuff to work you should just # >>> patch them in now, otherwise lurking/waiting for someone else may get # >>> too close to infinite. Reworking those few patches to add stuff at the # >>> end and resending doesn't sound hard. # >>> # >> # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
# So I should still apply 0001/replacement-0002/0003, and they # should still mesh nicely together, right?
Yeah, that's right :)
2011/9/1 skeezix skeezix@skeleton.org:
OKay, to be specific here..
Earlier email included patches 0001/0002/0003
Next email included redone patch 00002 --
So I should still apply 0001/replacement-0002/0003, and they should still mesh nicely together, right?
jeff
On Wed, 31 Aug 2011, Jari Vetoniemi wrote:
# Bleh, included the old patch... Sorry about that. # # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > Hey, # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > patch, so here is bit better version. # > # > Cheers. # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # >> Done and done, # >> Includes version patch, more leak fixes on libpnd and discovery test # >> leaks fixed. # >> You should get 0 bytes leaked when you run with valgrind. # >> # >> Cheers. # >> # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # >>>> But yeah, I sorted it all out eventually. I agree on adding the # >>>> version information to the bottom of the struct, # >>>> heck there should not be even reason why the disco struct would not # >>>> give all the information from PND. # >>>> # >>>> But yeah, I'll lurk around and see what future holds. # >>> # >>> Well if you need those things for your stuff to work you should just # >>> patch them in now, otherwise lurking/waiting for someone else may get # >>> too close to infinite. Reworking those few patches to add stuff at the # >>> end and resending doesn't sound hard. # >>> # >> # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
On Fri, 2 Sep 2011, Jari Vetoniemi wrote:
# # So I should still apply 0001/replacement-0002/0003, and they # # should still mesh nicely together, right? # # Yeah, that's right :)
Applied. See:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ...
Thanks :)
Does that make trunk same as your cloned libpnd, or you still running with some other stuff in there?
ie: if you can use trunk now, woudl be good for testing sake
jeff
# # 2011/9/1 skeezix skeezix@skeleton.org: # > # > OKay, to be specific here.. # > # > Earlier email included patches 0001/0002/0003 # > # > Next email included redone patch 00002 -- # > # > So I should still apply 0001/replacement-0002/0003, and they # > should still mesh nicely together, right? # > # > jeff # > # > On Wed, 31 Aug 2011, Jari Vetoniemi wrote: # > # > # Bleh, included the old patch... Sorry about that. # > # # > # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > # > Hey, # > # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > # > patch, so here is bit better version. # > # > # > # > Cheers. # > # > # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # > # >> Done and done, # > # >> Includes version patch, more leak fixes on libpnd and discovery test # > # >> leaks fixed. # > # >> You should get 0 bytes leaked when you run with valgrind. # > # >> # > # >> Cheers. # > # >> # > # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # > # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # > # >>>> But yeah, I sorted it all out eventually. I agree on adding the # > # >>>> version information to the bottom of the struct, # > # >>>> heck there should not be even reason why the disco struct would not # > # >>>> give all the information from PND. # > # >>>> # > # >>>> But yeah, I'll lurk around and see what future holds. # > # >>> # > # >>> Well if you need those things for your stuff to work you should just # > # >>> patch them in now, otherwise lurking/waiting for someone else may get # > # >>> too close to infinite. Reworking those few patches to add stuff at the # > # >>> end and resending doesn't sound hard. # > # >>> # > # >> # > # > # > # # > # > -- # > If everyone would put barbecue sauce on their food, there would be no war. # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
# Does that make trunk same as your cloned libpnd, or you still # running with some other stuff in there?
Yes, my trunk is absolutely same now. Expect for makefile with CC= and other "standard" env variable setters are commented out.
I'm gonna clone fresh git and check it out. Should be able to get rid of custom libpnd in panorama and milkyhelper pnds after new firmware update then.
2011/9/2 skeezix skeezix@skeleton.org:
On Fri, 2 Sep 2011, Jari Vetoniemi wrote:
# # So I should still apply 0001/replacement-0002/0003, and they # # should still mesh nicely together, right? # # Yeah, that's right :)
Applied. See:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ...
Thanks :)
Does that make trunk same as your cloned libpnd, or you still running with some other stuff in there?
ie: if you can use trunk now, woudl be good for testing sake
jeff
# # 2011/9/1 skeezix skeezix@skeleton.org: # > # > OKay, to be specific here.. # > # > Earlier email included patches 0001/0002/0003 # > # > Next email included redone patch 00002 -- # > # > So I should still apply 0001/replacement-0002/0003, and they # > should still mesh nicely together, right? # > # > jeff # > # > On Wed, 31 Aug 2011, Jari Vetoniemi wrote: # > # > # Bleh, included the old patch... Sorry about that. # > # # > # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > # > Hey, # > # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > # > patch, so here is bit better version. # > # > # > # > Cheers. # > # > # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # > # >> Done and done, # > # >> Includes version patch, more leak fixes on libpnd and discovery test # > # >> leaks fixed. # > # >> You should get 0 bytes leaked when you run with valgrind. # > # >> # > # >> Cheers. # > # >> # > # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # > # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # > # >>>> But yeah, I sorted it all out eventually. I agree on adding the # > # >>>> version information to the bottom of the struct, # > # >>>> heck there should not be even reason why the disco struct would not # > # >>>> give all the information from PND. # > # >>>> # > # >>>> But yeah, I'll lurk around and see what future holds. # > # >>> # > # >>> Well if you need those things for your stuff to work you should just # > # >>> patch them in now, otherwise lurking/waiting for someone else may get # > # >>> too close to infinite. Reworking those few patches to add stuff at the # > # >>> end and resending doesn't sound hard. # > # >>> # > # >> # > # > # > # # > # > -- # > If everyone would put barbecue sauce on their food, there would be no war. # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
Cloned fresh, and yeah. Everything is neat now :)
Cheers!
2011/9/2 Jari Vetoniemi mailroxas@gmail.com:
# Does that make trunk same as your cloned libpnd, or you still # running with some other stuff in there?
Yes, my trunk is absolutely same now. Expect for makefile with CC= and other "standard" env variable setters are commented out.
I'm gonna clone fresh git and check it out. Should be able to get rid of custom libpnd in panorama and milkyhelper pnds after new firmware update then.
2011/9/2 skeezix skeezix@skeleton.org:
On Fri, 2 Sep 2011, Jari Vetoniemi wrote:
# # So I should still apply 0001/replacement-0002/0003, and they # # should still mesh nicely together, right? # # Yeah, that's right :)
Applied. See:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ...
Thanks :)
Does that make trunk same as your cloned libpnd, or you still running with some other stuff in there?
ie: if you can use trunk now, woudl be good for testing sake
jeff
# # 2011/9/1 skeezix skeezix@skeleton.org: # > # > OKay, to be specific here.. # > # > Earlier email included patches 0001/0002/0003 # > # > Next email included redone patch 00002 -- # > # > So I should still apply 0001/replacement-0002/0003, and they # > should still mesh nicely together, right? # > # > jeff # > # > On Wed, 31 Aug 2011, Jari Vetoniemi wrote: # > # > # Bleh, included the old patch... Sorry about that. # > # # > # 2011/8/31 Jari Vetoniemi mailroxas@gmail.com: # > # > Hey, # > # > Just noticed that the buffer freeing wasn't quite sane on the 0002 # > # > patch, so here is bit better version. # > # > # > # > Cheers. # > # > # > # > 2011/8/30 Jari Vetoniemi mailroxas@gmail.com: # > # >> Done and done, # > # >> Includes version patch, more leak fixes on libpnd and discovery test # > # >> leaks fixed. # > # >> You should get 0 bytes leaked when you run with valgrind. # > # >> # > # >> Cheers. # > # >> # > # >> 2011/8/30 Grazvydas Ignotas notasas@gmail.com: # > # >>> On Mon, Aug 29, 2011 at 10:06 PM, Jari Vetoniemi mailroxas@gmail.com wrote: # > # >>>> But yeah, I sorted it all out eventually. I agree on adding the # > # >>>> version information to the bottom of the struct, # > # >>>> heck there should not be even reason why the disco struct would not # > # >>>> give all the information from PND. # > # >>>> # > # >>>> But yeah, I'll lurk around and see what future holds. # > # >>> # > # >>> Well if you need those things for your stuff to work you should just # > # >>> patch them in now, otherwise lurking/waiting for someone else may get # > # >>> too close to infinite. Reworking those few patches to add stuff at the # > # >>> end and resending doesn't sound hard. # > # >>> # > # >> # > # > # > # # > # > -- # > If everyone would put barbecue sauce on their food, there would be no war. # > #
-- If everyone would put barbecue sauce on their food, there would be no war.
On Sat, 27 Aug 2011, Jari Vetoniemi wrote:
# I fscked the patches for various reason, so they are all like they are now.. # Should still apply on the fresh git. # # I'll forward this message I originally sent to skeezix, since there # have been no activity:
yes, sorry, RL has my ass in a basket :P
Is this patch known good then? You've tested it a few rounds in Panorama and milky, so this patch is tested suffuciently to go in?
# ---------- Forwarded message ---------- # # This patch should apply on the fresh clone of # http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=summ... # # It adds few stuff more for package support, and the last patch fixes # leaks on libpnd discovery. # However the discovery example will still leak however, as it does not # destroy disco objects. I can send patch to it too later, as some # people might use it as reference.
yeah, the disco test tool was mostly just to work the lib and show how to pull, so probably shoudl have added the cleanup in case someone uses it; patch away!
# I kinda screwed the patches, but they should still apply. So make sure # you don't apply the old ones :) # # http://dl.dropbox.com/u/15640770/libpnd_patches.tar
Is this a complete 'should apply' group? I've got your latest email still, but if this is the newest one-pack thats good, so I don't use your bad patches.
You'd sent me a few and then lateer said some were bad, so I used it as an opportunity to be careful -- let you vet your latest patch before applying it. (You're sort of sending them to me before they're well tested, so I need necessarily sit on them for awhile before applying, right? ;)
Certainly though, with sebt3 busy right now, and me busy right now, I guess the current libpnd committer is Ivanovic; if he is also busy, we may need to coopy another committer.
The mailing list is probably the better place to submit the patches, than just me, right nowe. (1 month to twins coming, give or take, so I'm distracted.)
For patch submissions, they shoudl include notes as to the goal of the patches and a list of tests performed ;)
# Also why do I keep trying to use vim bindings on gmail?
Becasue you're not using Emacs :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.