unsubscribe
Good bye Amit Kulkarni :-( You are now unsubscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Removed OpenBSD 64-bit
> OK, the OpenBSD version seems dead :( hi Alex, Sorry for not replying earlier. > So I have removed the half-baked fragments from the release-TGZ and > source repository. Sorry about that, but I don't have the time and > resources to do it myself. > I will look itno it. Please put the stuff back in the nightly! I will look at it in this week and give feedback. thanks -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: picolisp on openSolaris
> I tried to compile picolisp on openSolaris and I got a message: > > 'make: Fatal error in reader: Makefile, line 14: Badly formed macro > assignment' > > These msg I get on both openSolaris 2008.05 and 2009.06. > > I tried 'gmake' the same msg. > > I tied gcc and I got: 'command not found'. It seems that may be gcc is not > installed ? > > So how to compile picolisp on openSolaris ? > use sun studio compiler, either the 2010 or 2011 versions. Check if its installed via the pkg tools or the GUI. Its a much better compiler than gcc. The gcc on OpenSolaris is 3.X series which is ancient. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
On Thu, Sep 1, 2011 at 12:54 AM, Alexander Burger wrote: > Hi Amit, > > thanks for the fixes! > > I've put them into "src64/sys/x86-64.openBsd.defs.l" so far, and made a > new release. > > >> SIGIO is a killer, on Linux it is equivalent to SIGPOLL but its BSD >> thing which was copied over by Linux, and is not POSIX... > > Yes, the same problem was with SunOS, iirc. It is used only by the > 'sigio' function, and not really mission-critical. > > >> I hope they are good. Is there a regress suite which I can run to >> catch any missed problems? :-) > > Yes, now to the interesting part :) > > We should find out if it (partially or all) works. > > If you have build "bin/picolisp", you could first run the interpreter > to see if anything works: > > $ (cd src64; make) > $ ./pil + > : > > And, if everything looks good, run the unit test suite: > > $ ./pil lib/test.l $(/bin/pwd) -bye + > OK > $ > > It prints a final "OK" if all right. Hi Alex, I downloaded and compiled the version from yesterday and it compiled it fine It used the java version to bootstrap. when running the unit test suite.. # ./pil lib/test.l $(/bin/pwd) -bye + (N) [test/src/main.l:11] 7 -- 'test' failed Thanks, amit -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
On Wed, Sep 7, 2011 at 8:03 AM, Jakob Eriksson wrote: > On Wed, Sep 07, 2011 at 02:39:51PM +0200, Alexander Burger wrote: >> On Wed, Sep 07, 2011 at 11:22:33AM +0200, Alexander Burger wrote: >> > Mathias used OpenBSD 5.0, and the interpreter works (at least partially). >> > >> > I'm not sure how we can handle such significant differences in the >> > individual versions of OpenBSD. Looks like a lot of work. >> >> Shouldn't we better restrict support to OpenBSD >= 5.0? > > > +1 > > It's not like there is a huge user base of Picolisp users on > OpenBSD < 5.0 ... :) > > //Jakob +1 +1 thanks, I also saw the stdin, stdout, WIF* errors (was it wifclosed?) we are getting close! amit -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
On Thu, Sep 1, 2011 at 12:54 AM, Alexander Burger wrote: > Hi Amit, > > thanks for the fixes! > > I've put them into "src64/sys/x86-64.openBsd.defs.l" so far, and made a > new release. > > >> SIGIO is a killer, on Linux it is equivalent to SIGPOLL but its BSD >> thing which was copied over by Linux, and is not POSIX... > > Yes, the same problem was with SunOS, iirc. It is used only by the > 'sigio' function, and not really mission-critical. > > >> I hope they are good. Is there a regress suite which I can run to >> catch any missed problems? :-) > > Yes, now to the interesting part :) > > We should find out if it (partially or all) works. > > If you have build "bin/picolisp", you could first run the interpreter > to see if anything works: > > $ (cd src64; make) > $ ./pil + > : hi, Running into compile problems... somewhat similar to what Renaud reported today in the oneiirc thread. I will detail it later tomorrow. thanks -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
Hi Alex, I am writing the changed values hereWherever possible I refer to these docs which are automatically updated within 10 mins of each commit and follow -current. They pull up the latest revision from cvs. > I set most values as they are in your output. However, there are also > some values not covered by def.c, because I took them directly from the > include files. These concern the ranges > > ENOENT .. ECONNRESET from http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/errno.h (equ EAGAIN 35) > O_RDONLY .. O_APPEND from http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/fcntl.h (equ O_APPEND 8) (equ O_CREAT 512) (equ O_TRUNC 1024) (equ O_EXCL 2048) dlfunctions are good http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/dlfcn.h so is termios, but please double check http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/termios.h > SIGHUP .. SIGNALS from sys/signal.h http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/signal.h (equ SIGUSR1 30) (equ SIGUSR2 31) (equ SIGCHLD 20) (equ SIGCONT 19) (equ SIGSTOP 17) (equ SIGTSTP 18) (equ SIGTTIN 21) (equ SIGTTOU 22) (equ SIGIO 23)==> this is BSD_VISIBLE only! unavailable for POSIX (equ SIGNALS XXX) # Highest used signal number plus 1 SIGIO is a killer, on Linux it is equivalent to SIGPOLL but its BSD thing which was copied over by Linux, and is not POSIX... > TM_SEC .. TM_YEAR I couldnt grep these for now...will look again later. > > Could you check if they are correct? I hope they are good. Is there a regress suite which I can run to catch any missed problems? :-) thanks for your great help! -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
> On Fri, Aug 26, 2011 at 07:10:06PM +0200, Alexander Burger wrote: >> Great, thanks! Got "code.s" ... will analyze it on Sunday. > > Good, just now I found the time! :) > > > So I constructed a new "src64/sys/x86-64.openBsd.code.l" from what I > found in your "code.s". I can't test it, but I hope it is correct. > > I think we are quite close now. I put a new "OpenBSD" clause into > "src64/Makefile", and uploaded it all in a new "picoLisp.tgz" (and a > "x86-64.openBsd.tgz") on the download page. > > If you have time, please fetch it, and have a look at the LD-MAIN and > LD-SHARED variables in the Makefile, and experiment to find optimal > values for them, then send us the results. Thanks, I will do it tomorrow and report everything together. i.e the ranges from before and your final result! > Ah, one important point: Can we be sure that OpenBSD uses the ELF linker > format? If not (e.g. the old "a.out" format), we might have problems > similar to those on Mac OS. > ELF is used everywhere except for some exotic arches for OpenBSD, I don't know exactly so I won't be able to answer. But AFAIK, amd64/x86/macppc/sparc/sparc64/loongson (loongson is mips) all use ELF. thanks a ton!!! -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version
> I set most values as they are in your output. However, there are also > some values not covered by def.c, because I took them directly from the > include files. These concern the ranges > > ENOENT .. ECONNRESET > O_RDONLY .. O_APPEND > SIGHUP .. SIGNALS > TM_SEC .. TM_YEAR > > Could you check if they are correct? Give me a day or two for this. I will definitely do it over the weekend. Want to be careful here as I will grep everything to make sure. I have replaced the values you mentioned in the next email... > >> > For the "src64/sys/*.code.l" files, things are a bit more tricky. I >> > usually worte short test programs in C, and then inspected them with >> > 'objdump -S'. I don't know how this works out in OpenBSD. >> >> Will you please send the test programs? > > Unfortunately, I don't have a definite test progam. It was more an > interactive search, writing code snippets, or disassembling other > programs with 'gdb'. > > So I now wrote a short "code.c" program (also attached). Can you compile > this with > > $ gcc -S code.c > > and send me the resulting "code.s"? I'll see if it helps me to extract > what is needed. Thanks , here it is attached. > > >> Do you need ppc64 >> too after amd64 works? I can ask somebody on porting list to give me >> the output for ppc64. They are a friendly bunch when in the right >> mood. > > That's good to hear. For now, I would say, we better try to get x86-64 > running first, and then tackle ppc64. Cool thanks! code.s Description: Binary data
Fwd: OpenBSD (Was: Building the full 64-bit version)
Hi, Background: I am trying to port picoLisp with Alex's help, its written in assembly for 64 bit architectures and C for 32 bit arches. He is ported to amd64, ppc64 and sparc64 is on his roadmap. Can somebody please weigh in on Alex's comment? thanks -- Forwarded message -- From: Alexander Burger Date: Thu, Aug 25, 2011 at 6:00 AM Subject: OpenBSD (Was: Building the full 64-bit version) To: picolisp@software-lab.de Hi Amit, I'm surprised to see that OpenBSD uses only 1024 for BUFSIZ, and - even more - that PIPE_BUF is only 512 (all others so far use 4096 or 5120). Especially the size of PIPE_BUF is critical for performance, as this is the limit for atomic messages over pipes, used heavily in PicoLisp's interprocess communication. Does OpenBSD really need to be so much compatible with ancient Unix? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Building the full 64-bit version (Was: httpGate and libssl
>> Moreover, they can be easily cross-generated. If we have proper a >> "src64/sys/x86-64.openBsd.code.l" and "src64/sys/x86-64.openBsd.defs.l" > > To generate the "src64/sys/*.defs.l" files, I always used the attached > "def.c". If you like, you could compile it on OpenBSD, and send me the > output. I could make "src64/sys/x86-64.openBsd.defs.l" then. Hi Alex, Sorry to get back so late on this... Anyway, I had to make small modifications to get def.c to compile on OpenBSD... i.e +#include -#include Okay, here's the output on amd64 attached to email. Do you need ppc64 too after amd64 works? I can ask somebody on porting list to give me the output for ppc64. They are a friendly bunch when in the right mood. > For the "src64/sys/*.code.l" files, things are a bit more tricky. I > usually worte short test programs in C, and then inspected them with > 'objdump -S'. I don't know how this works out in OpenBSD. Will you please send the test programs? OpenBSD uses gcc 4.2.1 toolchain with binutils 2.15 (moving to binutils 2.17 in this release cycle), so it uses objdump too! Thanks for your help! def.c.out Description: Binary data
Re: Building the full 64-bit version (Was: httpGate and libssl
Hi, > Hi all, > > for completeness, let me list three options for building a full > PicoLisp-64 system, using Debian-amd64 as an example: > > > 1. Stand-alone bootstrap, using a temporary 32-bit version: > > # apt-get install libc6-dev-i386 libssl-dev libx11-dev libxext-dev > > $ (cd src; make all) > $ (cd src64; make) > On OpenBSD, which doesn't mix 32bit and 64bit this approach is impossible. Yet, it is the simplest possible. Is it possible to have 64 bit C bootstrap a 64 bit assembly? > 2. Using a Java runtime system (version 1.6 or higher): > > # apt-get install openjdk-6-jre > # apt-get install libssl-dev libx11-dev libxext-dev > > $ (cd src; make tools gate x11) > $ (cd src64; make) Java is not available on all hardware architectures! > 3. Using the pre-generated "*.s" file package: > > # apt-get install libssl-dev libx11-dev libxext-dev > > $ (cd src; make tools gate x11) > $ wget http://software-lab.de/x86-64.linux.tgz && tar xvfz x86-64.linux.tgz > $ (cd src64; make) Is this approach probably too linux specific? thanks > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: picolisp on openbsd amd64
Edwin, Since picoLisp 64bit is pure assembly, Alex has already ported to am64, ppc64. I sent a email asking pretty much the same question within the last two weeks, see Alex's responses. Thanks On Mon, Aug 8, 2011 at 1:50 PM, Tomas Hlavaty wrote: > Hi Edwin, > >> tried compiling picolisp on an openbsd amd64 install and it seems out > >> - changed all instances of -m32 to -m64 > > the -m32 is there for a reason, you can't just replace it and expect it > to work:-D > > I suppose you are trying to compile the C version, which is 32 bit only. > > Alex implemented the 64 bit version in assembly so it is a different > program (in src64 directory). Try to build this one if you are after 64 > bit picolisp. > > Cheers, > > Tomas > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: request for porting help for OpenBSD 64 bits
On Mon, Jul 25, 2011 at 1:38 AM, Alexander Burger wrote: > Hi Amit, > >> first. Reading about both, and exploring what I would like to use. I >> am looking into packaging PicoLisp for OpenBSD ports. I can get > > Great! I think its easier to package just the C version, without the -m32/m64 switch. Is that ok on 64 bit? >> Is there any plan to add more CPUs or just do it in plain C for 64 >> bits in future (C is strictly no-no)? If no plans to add more CPUs >> right now, the changes that would be needed would be substantial, say >> for sparc64, mips64? I haven't touched assembly (8051 assembly only) >> in 15 years so this is just idle curiosity! > > Since 3.0.7 there is also a PowerPC-64 version. > > I'm planning to tackle Sparc9 next, but didn't find the time yet. Sparc9 > has a very similar structure to Ppc64. > > Some (most?) architectures support both 32-bit and 64-bit executables. > In such cases, the 32-bit version of PicoLisp can be used for the time > being (though it is more limited in its capabilities compared to the > 64-bit version). > thanks for the info. > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
request for porting help for OpenBSD 64 bits
Hi, I am new to lisp. Searched for very small dialect and new/pico came up first. Reading about both, and exploring what I would like to use. I am looking into packaging PicoLisp for OpenBSD ports. I can get miniPicoLisp to work, but would like to see the full package, and in both 32/64 bits & for all architectures! I am using amd64 (or x86-64 as you call it). I am seeing picolisp/src64/arch/ppc64.l and x86-64.l and its difficulty in porting to different CPUs... Is there any plan to add more CPUs or just do it in plain C for 64 bits in future (C is strictly no-no)? If no plans to add more CPUs right now, the changes that would be needed would be substantial, say for sparc64, mips64? I haven't touched assembly (8051 assembly only) in 15 years so this is just idle curiosity! Thanks, amit -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Amit Kulkarni :-) You are now subscribed subscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
