Tomas Hlavaty writes:
Hi Tomas,
>> So as I see it, I still have to use SWIG to turn these class hierarchies
>> in plain functions calls, and then I can use PicoLisp 'native' calls as
>> wrappers. Would be great though to have a ffi.l that knows how to deal
>> with C++.
>
> Yes, that seems like
Hi all,
I didn't bother with trampolines so far, but add some comments to
On Thu, May 16, 2013 at 12:00:20AM +0800, Samuel Dennis Borlongan wrote:
> ...
> http://stackoverflow.com/questions/12186672/how-can-i-prevent-my-ackerman-function-from-overflowing-the-stack
> ...
The bad thing with overfl
> > Thanks! The 'make' went fine now. However, when I try to run my web
> > app now, I get "IP bind error: Address already in use". ;-)
> > I think I may have to bother C9 Support again.
>
> Ah, but perhaps this is (partially) good news, because it seems to
> have taken the address! :)
Just throw
Hi Rowan,
> Just throwing in an observation in case it hasn't already occurred
> to you - the "Address already in use" error might well not be a picolisp
> or C9 problem at all, but that you are reconnecting to the socket
> without having set the SO_REUSEADDR option (or equivalent). Without it
> y
Hi Alex & Rowan,
As far as I can see, there is no other process listening on 8080 at the
moment when I get this "Address already in use". However, I've just
managed to put together a tiny Ruby server (found something on
stackoverflow) that works. It uses "server = TCPServer.open(host, port)"
On Thu, May 16, 2013 at 01:33:54PM +0200, Alexander Burger wrote:
>: (bench (ack 4 1))
>249.465 sec
>-> 65533
>
>: (bench (ack2 4 1))
>252.487 sec
>-> 65533
>
> though the less-recursive function is slightly slower (as expected).
Oops, forget that! Not "as expected" ... t
Hi Jon,
> stackoverflow) that works. It uses "server = TCPServer.open(host,
> port)" where 'host' is "127.6.26.129" and 'port' is 8080. Right now
I see. So my proposal of calling inet_pton() was not correct :(
I have no idea at the moment. Somebody (me?) must dig into TCP
networking (again). Hav
Re: side-note
(bench (length (ack4 3 8000))) (32-bit Cygwin)
0.070 sec
(bench (length (trampoline ack/t 3 8000))) (32-bit Cygwin)
2.010 sec
(bench (length (trampoline ack/t 3 8000))) (64-bit Ersatz on Java 8, before
=0 and length invocation removal)
9.625 sec
(bench (length (trampoline ack/t 3
Hi Alex,
I'll be off-line for a couple of days. Have a nice weekend!
/Jon
On 16-05-13 16:38 , Alexander Burger wrote:
Hi Jon,
stackoverflow) that works. It uses "server = TCPServer.open(host,
port)" where 'host' is "127.6.26.129" and 'port' is 8080. Right now
I see. So my proposal of calli
Hi Samuel,
> (bench (length (trampoline ack/t 3 8000))) (64-bit Ersatz on Java 8, before
> =0 and length invocation removal)
> 9.625 sec
>
> (bench (length (trampoline ack/t 3 8000))) (64-bit Ersatz on Java 8, after
> =0 invocation removal)
> 4.981 sec
>
> (bench (length (trampoline ack/t 3 8000
On Thu, May 16, 2013 at 04:33:49PM +0200, Alexander Burger wrote:
> > though the less-recursive function is slightly slower (as expected).
>
> Oops, forget that! Not "as expected" ... the opposite would be expected.
> But the values are very close anyway.
One more oops!!
Though it doesn't matter
Hello Martin Curran :-)
You are now subscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Hi Thorsten,
> use this SWIG command line, which produces, besides the probably bloated
> C code, a kind of 'Lisp pseudo code' too, that should be easily
> transformed into 'native calls:
>
> ,--
> | swig -cffi -c++ example.i
That is CFFI, portability layer for Common Lisp
> Alexander Burger wrote:
>
> I see. So my proposal of calling inet_pton() was not correct :(
>
> I have no idea at the moment. Somebody (me?) must dig into TCP
> networking (again). Haven't touched that for a while.
Jon,
I think I might have found an explanation for the "already bound"
error, an
Hello Oskar Wieland :-)
You are now subscribed
Hi,
bitte melde mich fuer die email liste an.
ein kleiner unwichtiger fehler:
: (version)
3.1.2.0 C
-> (3 1 2 0)
: (setq foo 1)
-> 1
: (foo)
Segmentation fault (core dumped)
lg
oskar
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=
On Fri, May 17, 2013 at 02:05:10AM +0300, Rowan Thorpe wrote:
> you to do, but instead of:
>
> : MyIpAddr asciz "127.6.26.129"
>
> you put the ipv6-mapped address for it:
>
> : MyIpAddr asciz ":::127.6.26.129"
Thanks Rowan! This sounds like a very reasonable hint!
♪♫ Alex
--
UNSUBSCRI
Hi Oskar,
> bitte melde mich fuer die email liste an.
Sure! It happened automatically already :)
> : (setq foo 1)
> -> 1
> : (foo)
> Segmentation fault (core dumped)
I understand your worries, but this is actually a "feature".
In general, PicoLisp doesn't catch such errors, as this would indu
Yes, the FAQ should definitely elaborate on that, since people are used to
that interpreted languages can not induce segfaults on their own. Also explain
perhaps that the interpreter could check all C calls against a white list, but
it would take a lot of time
Alexander Burger skrev:
>Hi Os
On Fri, May 17, 2013 at 08:14:12AM +0200, Jakob Eriksson wrote:
> Yes, the FAQ should definitely elaborate on that, since people are
Yes, Jakob, I'll add some explanation. Roughly along the line what I
wrote in the mail. Should make things a little clearer.
> used to that interpreted languages c
and it was a perfectly clear explanation.
no the question is where should it go within the docs?
just put this example under the faq#segfault?
(which, btw, crashed my chrome on the 1st load, but worked on reload ;)
--
tom
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
20 matches
Mail list logo
