[vlc-devel] Lua-SD: Slightly improved version of the additional Jamendo SD script

[chrcnt7 at swift-mail.com]

I revised the parsing code generator and also two comments, it’s basically what I had already posted on IRC a couple of days ago. A shortened diff is appended (for informational purposes only, I’d say re-downloading is faster than patching it up with diff ;) ) and can also be had with add colouring at http://pastebin.com/rStTgmXx for the next month.
I’m now mostly satisfied with the parsing (in the previous version, it broke a bit too often). Fixing up Unicode escapes ('\u<codepoint nr.>') would probably require switching to a replacement function instead of using a table to indicate the replacements in the call to 'string.gsub'.
Next, I think I’ll either add the XML thing (which I don’t feel like doing right now ;) ) or rather try to figure out how to actually get on-demand loading (Nope, still haven’t done that. :P). I’ll see. :)



diff --git "1/.\\JdoSd_P1.lua" "2/.\\JdoSd_P2.lua"
index 2b9fc21..a4994d5 100644
--- "1/.\\JdoSd_P1.lua"
+++ "2/.\\JdoSd_P2.lua"
@@ -26,8 +26,8 @@
 
 
 --[[ === Comments on this Script ===
-I realize the people at Jamendo probably want to see the playlists of featured tracks here the current
-(2016-08-09, version 2.2.4) default script provides. I’m not against integrating them, they just didn’t
+I realize the people at Jamendo probably would like this script to show the playlists of featured tracks the current
+(2016-08-09, version 2.2.4) default script already has. I’m not against integrating them, they just didn’t
 matter much to me. I will probably add them in a future version.
 The core parsing is done by code I made a parser generator for. I did already publish its source on pastebin.com,
 but people didn’t really like it (I’m not too much surprised by that, I wouldn’t call it beautiful myself). Part of that
@@ -68,7 +68,7 @@ Further improvements which could be made include those:
 
 --[[ === Example Query ===
 -- Comments --
-The line breaks are not present in the orignal answer (use 'format=jsonpretty' for that), they were added to enhance readability here.
+The line breaks are not present in the answer the server gives (use 'format=jsonpretty' for that), they were added to enhance readability here.
 The API documentation can be had at [https://developer.jamendo.com/v3.0], the documentation for the 'tracks' 'method' specifically at
 [https://developer.jamendo.com/v3.0/tracks]. For trying stuff, use a limit like 10 or 5 or so, not 100. The client_id here is the one that
 was given out for testing and still worked 2016-08-09. You might have to get a new one (look at the documentation for the client_id
@@ -100,7 +100,7 @@ https://api.jamendo.com/v3.0/tracks/?client_id=56d30c95&format=json&vocalinstrum
 
  --Those three functions have been carried over from the old script (I altered 'title', obviously)
 function descriptor()
-    return { title = "Custom Jamendo SD", capabilities = {} }
+    return { title = "Custom Jamendo SD 2", capabilities = {} }
 end
 
 function activate()
@@ -126,14 +126,19 @@ local function ExtractingTheTrackInfo(OneJdoJsonTracklistQueryStream) --Returnin
         OJJTQResult = OJJTQResult .. BytesRead --There shouldn’t be many iterations, so table.concat quite probably wouldn’t help
     end
     --@ AfterReading_BeforeParsing = os.clock()
-    local S = string.gsub(OJJTQResult, "\\", "") --Could indeed be the fastest way to do it in Lua (because Lua is a true misfit for this task)
-    OJJTQResult, BytesRead = nil, nil --The GC could take this as a hint to collect the memory, at least at some point (it might be paused)
-    --Using string.find instead of looping and checking for byte values in plain Lua code might be advantageous regarding speed
-    --(as I hadn’t benchmarked this and didn’t expect it to be so slow). On the other hand, the strides should be fairly short in every case,
-    --so maybe it’s not that bad
+    local S = string.gsub(OJJTQResult, "\\.", {["\\\""] = "''", ["\\/"] = "/", ["\\u"] = "\\"})
+        --Could indeed be the fastest way to do it in Lua (because Lua is truly unfit for this task)
+        --Also considered, but took twice the time: string.gsub(string.gsub(OJJTQResult, "\\\"", "''"), "\\", "")
+    assert(S~=nil)
+    OJJTQResult, BytesRead = nil, nil --!The GC could take this as a hint to collect the memory, at least at some point (it might be paused)
+    --In the autogenerated code that follows, find is now used – instead of looping in Lua – to find the delimiters. I did some micro-benches
+    --and it came out faster. Yet, conversion to numbers was faster with the Lua version. Still to be evaluated is whether checking for loop
+    --markers (beginning, repetition and end) should be done using string.byte (as it is done now) or rather string.sub.
+
 -- The following line of code has been auto-generated
[Parsing code omitted]
 -- The previous line of code has been auto-generated
+
     --@ AfterParsing = os.clock()
     --@ log("Reading took " .. tostring(AfterReading_BeforeParsing - BeforeReading) .. "ms, while parsing took " ..
     --@	tostring(AfterParsing - AfterReading_BeforeParsing) .. "ms to complete.")
@@ -240,115 +245,4 @@ function main()
     AddingATracklistInThreeSlices(OuterBundle.add_node({["title"] = "Instrumental | InstTks with the highest buzzrate"}), "JIBT", TopInstTks_Buzzrate, TopInstTks_Buzzrate_Ct)
     AddingATracklistInThreeSlices(OuterBundle.add_node({["title"] = "Instrumental | InstTks which are 300 positions down on the buzzrate scale"}), "JIBL", LowInstTks_Buzzrate, LowInstTks_Buzzrate_Ct)
     --Another format proposal "I: Tracks with the highest buzzrate (Instrumental)"


-- 
http://www.fastmail.com - Email service worth paying for. Try it for free

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JdoSd_P2.lua
Type: application/octet-stream
Size: 23061 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160822/5a793a9c/attachment.obj>