[aur-dev] [PATCH] Fixed a couple more lingering JSON bugs
This patch applies to the current testing branch that includes Simo's patches to JSON. Now you can properly retrieve package info by name. I have this little script for testing. Yarr. #!/bin/sh wget http://aur.archlinux.org/rpc.php?type=$1\&arg=$2 -O rpc.tmp && less rpc.tmp exit 0
On 2/19/08, Loui <louipc.ist@gmail.com> wrote:
This patch applies to the current testing branch that includes Simo's patches to JSON. Now you can properly retrieve package info by name.
I have this little script for testing. Yarr.
#!/bin/sh
wget http://aur.archlinux.org/rpc.php?type=$1\&arg=$2 -O rpc.tmp && less rpc.tmp
exit 0
Your patch adds a needless string concatenation operation, for the sole sake of a line break. Not a good idea. String concatenation adds up, peformance wise.
On Tue, Feb 19, 2008 at 12:11 PM, eliott <eliott@cactuswax.net> wrote:
Your patch adds a needless string concatenation operation, for the sole sake of a line break. Not a good idea. String concatenation adds up, peformance wise.
Sorry I wasn't aware of that. I really hate the long lines though. It's a lot easier to work with code that fits neatly within a certain number of columns (for me). Even with the performance hit I'd probably still go for it. I bet there's a lot of other places that performance can be improved. I've just read something about an output buffer that sounds like it might increase performance for all output strings. Should we go about using that in the rest of the code where applicable?
On Tue, Feb 19, 2008 at 01:29:50PM -0500, Loui wrote:
On Tue, Feb 19, 2008 at 12:11 PM, eliott <eliott@cactuswax.net> wrote:
Your patch adds a needless string concatenation operation, for the sole sake of a line break. Not a good idea. String concatenation adds up, peformance wise.
Sorry I wasn't aware of that. I really hate the long lines though. It's a lot easier to work with code that fits neatly within a certain number of columns (for me). Even with the performance hit I'd probably still go for it. I bet there's a lot of other places that performance can be improved.
I've just read something about an output buffer that sounds like it might increase performance for all output strings. Should we go about using that in the rest of the code where applicable?
I'm pretty sure eliott wants to uber-optimize the json interface because it's very possible that this code will get hit more frequently than any other aur code. Generally though, I don't really see anything wrong with string concatenation, espcially if it enhances readability (which php tends to lack sometimes imho). Patch applied, without string concatenation :) zoom zoom -S
On 2/20/08, Simo Leone <simo@archlinux.org> wrote:
I'm pretty sure eliott wants to uber-optimize the json interface because it's very possible that this code will get hit more frequently than any other aur code. Generally though, I don't really see anything wrong with string concatenation, espcially if it enhances readability (which php tends to lack sometimes imho).
Patch applied, without string concatenation
:) zoom zoom
Alrighty good stuff. That line that I did the string concatenation actually had a valid fix though :P the space after AND at the end of the string is required. Either that, or a space before "Name=" further down in the code.
On Wed, Feb 20, 2008 at 03:26:06PM -0500, Loui wrote:
On 2/20/08, Simo Leone <simo@archlinux.org> wrote:
I'm pretty sure eliott wants to uber-optimize the json interface because it's very possible that this code will get hit more frequently than any other aur code. Generally though, I don't really see anything wrong with string concatenation, espcially if it enhances readability (which php tends to lack sometimes imho).
Patch applied, without string concatenation
:) zoom zoom
Alrighty good stuff. That line that I did the string concatenation actually had a valid fix though :P the space after AND at the end of the string is required. Either that, or a space before "Name=" further down in the code.
hehehe, wow I missed that, I totally looked. Fixed in testing though, and some git magic says you fixed it :) -S
On 2/20/08, Simo Leone <simo@archlinux.org> wrote:
hehehe, wow I missed that, I totally looked.
Fixed in testing though, and some git magic says you fixed it :)
Holy friggen wizardry! Nice.
participants (3)
-
eliott
-
Loui
-
Simo Leone