Re: Signal processing during FFI have no action
Am 02.05.2023 um 16:00 schrieb Alexander Burger: Hi Constantine, I wrote a function that downloads file using libcurl. I found out that when the the downloading process in progress by `curl_easy_perform` I cannot interrupt downloading by Ctrl-C. Even `killall picolisp` does not work. How I can make signals work during FFI? Mayb try the NOPROGRESS option from libcurl like this https://curl.se/libcurl/c/CURLOPT_NOPROGRESS.html Maybe that changes something regards rob -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Proposal: PilCon 2020
count me in and if you need help on locations , u know how to contact me ! rob Am 25.12.2019 um 10:56 schrieb Alexander Burger: Hi all, a merry Christmas to everybody! o/ Since a few weeks we were discussing in the #picolisp IRC channel about holding a PicoLisp Conference in Langweid / Germany next year. It would be on July 27th (Mon), 28th (Tue), and - if necessary - 29th. I can get a room and equipment for about 30 people, in "Kulturbahnhof", the old Langweid train station building. With this mail I'd like to find out how many people are actually interested to participate, and their probabilities of attendance (in percent). Langweid is by train 15 minutes from Augsburg, or one hour from München central station. There are some hotels/pensions in Langweid, and more in Augsburg or one of the villages nearby (reachable by train or bus). I could make two or three presentations about what I'm working on currently, anybody else is welcome to do the same, and/or we could make a general PicoLisp workshop. One of the oldest PicoLisp customers (since 2002, also the one with the largest user base) is about 3 km from Langweid, and I have a probable OK that some interested conference attendees might join to visit them. Let's discuss further details here in the list, or perhaps in the wiki at picolisp.com. I wish peaceful days and a good start into 2020 for all of you! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Irc channel now only for registered nicknames
Dear List Due to the current spam flood on freenode itself, we now only permit messages from registered nicknames. To register your nick see: https://freenode.net/kb/answer/registration Regards rob_w -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Workers for multicore processing (Question and RFC)
Am 28.02.2017 um 12:04 schrieb Petr Gladkikh: I believe modern Linux systems have much higher than 1024 file descriptor per process limits. E.g. on my system $ uname -srv Linux 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 $ cat /proc/sys/fs/file-max 2013532 And you can adjust this limit to your requirements. Sorry to jump in here out of my closet, but i think this fact needs some clarification. My research came up with the following: /proc/sys/fs/file-max is not the "per" process limit , rather then the overall limit of the system This can also be controlled by writing into /proc/sys/fs/file-max. to get to know the hardlimit per process you use ulimit -Hn soft limit is showed via ulimit -Sn as the ulimit manpage states, the hard limit acts as a ceiling for the softlimit , which can be controlled. So we have the per-proccess limitations, but as soon as we fork() and recieve a new pid, we can have yet another set of fds , right ? cheers rob
Re: Perfect Forward Secrecy
Am 27.01.2014 19:45, schrieb Alexander Burger: Hi all, I'm glad to announce that 'httpGate' now supports Perfect Forward Secrecy, using Elliptic curve Diffie-Hellman key exchange. Well done !! You can find out which cipher is used by inspecting the new global variable '*Cipher'. If I connect with Iceweasel, I get : *Cipher - ECDHE-RSA-AES256-SHA and with 'bin/ssl', e.g. by starting the demo app in one terminal and calling $ bin/ssl localhost 443 '!work' in another terminal, I get : *Cipher - ECDHE-RSA-AES256-GCM-SHA384 As a special gift to our friends at NSA :) eat this suckers ! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pico build problem on Mac OS X 10.6
btw a Intel Core 2 Duo can do both 32bit and 64bit. So maybe your MAC runs it on 64bit ?? But will the 64-bit Pico Lisp run on a machine (my Mac) that is 32-bit only ??? /Jon -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: The 64-bit version is complete
So is this then the mighty 3.0 release. Congrats Alex and keep up the good work. Rob- Alexander Burger schrieb: Hi all, this morning I finished the implementation of the last remaining function in the 64-bit version (it was 'commit', btw)! Now the 64-bit version should be compatible to the 32-bit version. As we left off for a family trip for the rest of the day, I did not much testing yet. In fact, the whole version underwent only a few smoke-tests so far. During the next weeks want to see how much is working, and whether we detect serious problems. So complete does not mean finished. But if it turns out not too bad, I'll make it official, and increment the picoLisp version to 3.0 with the next release at the end of this month. If anybody dares: It is available in the current testing release :-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico build problem on Mac OS X 10.6
can you use the type command on some of those .o files you get ? also what is a typical type output on a working binary in your os. maybe remove the -m32 switch in the makefile and see what happens. rob Jon Kleiser schrieb: Hi, I've just installed Mac OS X 10.6, aka Snow Leopard, on a partition on my Mac (Intel Core 2 Duo, which probably means 32 bit only), and I was curious to see what the consequences might be for Pico Lisp. I downloaded the ongoing dev. version of Pico Lisp and did the usual (cd src; make picolisp). The results weren't too nice, but I'm not sure what the problem is: $ (cd src; make picolisp) gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' main.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' gc.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' apply.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' flow.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' sym.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' subr.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' big.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' io.c io.c: In function ‘doEcho’: io.c:2072: warning: ‘op’ may be used uninitialized in this function io.c: In function ‘doCommit’: io.c:3224: warning: ‘note’ may be used uninitialized in this function gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' net.c gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='Darwin' tab.c mkdir -p ../bin ../lib gcc -o ../bin/picolisp -lc -lm -ldl main.o gc.o apply.o flow.o sym.o subr.o big.o io.o net.o tab.o ld: warning: in main.o, file is not of required architecture ld: warning: in gc.o, file is not of required architecture ld: warning: in apply.o, file is not of required architecture ld: warning: in flow.o, file is not of required architecture ld: warning: in sym.o, file is not of required architecture ld: warning: in subr.o, file is not of required architecture ld: warning: in big.o, file is not of required architecture ld: warning: in io.o, file is not of required architecture ld: warning: in net.o, file is not of required architecture ld: warning: in tab.o, file is not of required architecture Undefined symbols: _main, referenced from: start in crt1.10.6.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [../bin/picolisp] Error 1 I also tried building Pico Lisp 2.3.5, but got the same as above. However, running the Pico Lisp 2.3.5 that I built using Mac OS X 10.5.x, went fine, including my OpenGL Chinese Checkers. Snow Leopard does bring some changes re. gcc. Some info may be found here: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9 /Jon -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
