Re: MySQL native C wrapper
Yes, you're right, I'll remove it and link straight to the lib, it was something I did in the beginning of the process when I was unsure of how transparently I could pass references to structs around. As it turned out it's completely seamless so your suggestion makes perfect sense, or be my guest and do it yourself if you're anxious, I won't have time until next weekend, feel free to copy whatever you like from me. On Mon, Apr 27, 2015 at 3:28 AM, Alexander Williams a...@unscramble.co.jp wrote: Henrik this is great!! I've been looking for something like this but it was a little lower on my priority list. Thank you! I find it interesting that you wrote some C to initiate the mysql connection Would it be easier to do it in PicoLisp and simply use libmysqlclient.so ? On 2015-04-27, at 6:00 AM, Henrik Sarvell hsarv...@gmail.com wrote: Hi list, I'm announcing this at a very early stage, earlier than I would like to, in case someone else is also thinking about doing a MySQL wrapper, to avoid duplicate work. I'm not doing this because I think that MySQL is in any way a better alternative than the native DB functionality, rather the opposite. The main reasoning is that it might help adoption of the language as I've come to believe that how the data is stored could be as big a hurdle to switch as the language switch itself - for many organisations - if they can keep their data as it is (to begin with) half the battle might already be won. PicoLisp with MySQL is still better than say PHP with MySQL. It also helps in migrating from MySQL to the native DB. It's all inspired by Alex Williams' nice and instructive use of the native stuff here: http://aw.github.io/picolisp//2015/02/22/nanomsg/ And I couldn't have managed without AB's writeup here: http://software-lab.de/doc/native.html Without further ado: https://bitbucket.org/hsarvell/ext/src/default/mysql.l?at=default Note that you can't just run with the file linked to above, you need the mysql.so file in the ext/so folder too. If no one beats me to it I will do some more work on this one in the future and will announce here when there's something to show. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
subscribe
Hello Will Arnold wdarn...@triad.rr.com :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pseudo Random Number Generation across PicoLisp implementations
On Mon, Apr 27, 2015 at 8:01 AM, Alexander Burger a...@software-lab.de wrote: […] A shift of 32 bits, however, would not suffice, because it would put the sign bit of the original 64-bit number into the MSB of the result. OK, I understand. I have some more ideas to try to make the behaviors of (rand m n) in pil32 and ersatz the same, but maybe you are not so much interested. Let me try one. Would it be possible to just cast (Seed 32) to a long: if ((n = evInt(ex.Cdr) + 1 - ((Number)x).Cnt) != 0) n = (long)(Seed 32) % n; return new Number(((Number)x).Cnt + n); Some naive tests (see here: http://pastebin.com/hnnRLPA0) seem to confort my idea, but I may have missed something (again). If still wrong, I may implement a smaller generator specially for my language. Like one with just Xn+1 = a Xn, and a(m−1)2^53 (for ability to use withe JS numbers). Inspired by Wikipedia and this paper: http://www.ams.org/journals/mcom/1999-68-225/S0025-5718-99-00996-5/S0025-5718-99-00996-5.pdf BTW, I wonder why MINSTD is not listed in Table 3. chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pseudo Random Number Generation across PicoLisp implementations
Hi Christophe, Alex, if nobody in the mailing list is against modifying the rand of Ersatz, may I humbly ask you to use 32 instead of 33 ? Sorry, I think this is not a good idea. Now I remembered why the shift is 33 and not 32: It has to do with the fact that Java doesn't support unsigned 32-it integers. But in 'rand', the line n = (int)(Seed 33) % n; requires the result of the shift operation to be a positive number. Fortunately, Java has with '' a shift operation which inserts zero bits from the right (i.e. an unsigned shift), thus guaranteeing a positive result. A shift of 32 bits, however, would not suffice, because it would put the sign bit of the original 64-bit number into the MSB of the result. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
unsubscribe
Good bye Will Arnold thetr...@triad.rr.com :-( You are now unsubscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
