Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - chi

#1
newLISP newS /
May 21, 2009, 04:55:38 PM
Quote from: "Kazimir Majorinc"chi,  (...)

This function modifies its code during evaluation, so it runs indefinitely although there is no loop or recursion. (...) I wrote about it (...)


Hello Kazimir,



thank you very much for your explanation. Now I do understand! I think, you are right, that this is not normally possible via CL or Scheme. But OTOH both languages are not forced to compile theirs lambdas, so there may be some implementations, where this nice trick could be possible :-)



Unfortunately I did not stumble over said article of your block, as that would probably spared you the time to answer my question ...



I am at blog article #7 right now ... well done! :-D



Ciao,

chi :-)
#2
newLISP newS /
May 20, 2009, 11:41:38 PM
Oops, perhaps I posted too fast! Suddenly I am not sure, if I interpreted the line in the release notes
Quotelambda functions (not lambda-macro) now allow for large or infinite running bodies without stack impact
correctly!



My Scheme example will crash the newLISP interpreter due to stack size. So perhaps I did misunderstood the line above.



Could someone, please, clarify the meaning for me?



Thanks in advance and



ciao,

chi :-)
#3
newLISP newS /
May 20, 2009, 11:31:48 PM
Quote from: "Kazimir Majorinc"(...) I think CL and Scheme have no equivalent, since their functions are not just lambda lists, but results of evaluation of lambda lists. (...)

At least Scheme ought to have this feature. To be a Scheme, the system has to support two important features: call/cc and tail recursion optimization. For instance this (set! lop (lambda (n) (print "n: " n) (lop (+ n 1))))
(lop 1)

will run endlessly without growing stack space at around 960K. While this(set! lop! (lambda (n) (print "n: " n) (+ (lop (+ n 1)) 1)))
(lop! 1)

will slowly raise the stack space up to 1.9G while nearly killing my system :-)



But I do not know anything for CL about that ...



Ciao,

chi :-)
#4
newLISP newS /
May 19, 2009, 07:04:49 AM
Quote from: "Lutz"From the new sqlite3.lsp test routines:


Quotetry to drop table fruits via SQL injection attack ... no luck, table was safe against SQL injection.


nice  :-)


I am glad, you like it! :-)


QuoteI did some further testing (for memory leaks and 64-bit newLISP on OpenBSD and Mac OS X) and everything seems to be fine.



Thanks again a for this contribution.


You're welcome. I hope, I will have the opportunity to contribute some more in the future ...



Ciao,

chi :-)
#5
newLISP newS /
May 18, 2009, 01:44:31 PM
Quote from: "Lutz"Thanks for the information Chi. You can just email or pm me the file sqlite3.lsp and I include it in the upcoming 10.0.6 development release.




I sent you the extended file just a few moments before to the address you told me below. Thank you for considering to include my enhancement :-)


QuoteI assume you added an optional parameter to the 'sql3:sql' function so the function is used with or without extra variable binding?


You are right. I hope I did document it well, but if I need to improve the documentation, please let me know.



The optional parameter may be a normal list (if the host variables within the SQL statement are marked '?' only -- positional arguments), or a association list, if one choose to use the '?<number>', ':<name>', '@name' or '$name' style of host variable markup. In the second case, the parameter are not positional as they will be identified by the key part of an association, whereas the associations' value will be the value to be bound to the host variable.



If there is anything unclear. please let me know!


QuoteThanks for adding a testing function too. You can send me the file to lutz at nuevatec dot com. Also let me know what name to add in the author line.


Thank you for your nice language! :-)



Ciao,

chi :-)
#6
newLISP newS /
May 18, 2009, 09:21:30 AM
Quote from: "Lutz"Is it something like this, you are doing?


(sql3:sql (format "select * from fruits where name = %s;" '("grapes")))


No, as this statement would be easily attackable via SQL injection attack. To avoid that, I use the sqlite3_bind_*() calls to bind a value to a host variable mentioned in the SQL statement. That way, no injection attack is possible!


Quote from: "Lutz"can you post the whole function?


Of couse I could. It is a small additional internal function and a bit of additional code in (sql3:sql). And I have also extended (test-sqlite3) to test that feature, so it would be some pieces of code to post.



I could post a unified diff against 10.0.5 and my additions. Or I send a PM to you, with my sqlite3.lsp file attached.



Whatever you like!


Quote from: "Lutz"Ps: the 'format' function can take it's parameters in a list


Thank you for the hint, but (format) is not used here ;)



Ciao,

chi :)
#7
newLISP newS / How to contribute code?
May 17, 2009, 11:28:47 PM
Hello,



I am interested in newLISP for some time now. I read in the forum and studied several code examples. Now I intend to use newLISP for a small project at work.



For that, I have enhanced sqlite3.lsp a bit. I introduced the possibility of host variable bindings in the SQL statement of (sql3:sql) so that following would be possible now:
(sql3:sql "select * from fruits where name = ?;"  
     '("grapes"))


Now my questions are: is there any interest for such enhancement? If yes, how do I contribute the code? Should I provide the whole file sqlite3.lsp or a patch against 10.0.5?



Thanks in advance and



ciao,

chi :)