Re: The 64-bit version is complete

[Robert Wörle]

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

[Robert Wörle]

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

Re: From Pico to JSON in the client

[Henrik Sarvell]

I've updated the converter now, the current version is more flexible
than earlier and will now also do (:key (1 2 3)) - {key: [1, 2,
3]}.

/Henrik


On Fri, Sep 4, 2009 at 11:10 AM, Henrik Sarvellhsarv...@gmail.com wrote:
 Thanks for the idea TC, another alternative would be to give the
 parser a bias to lean on as an extra argument but that doesn't feel
 100% right. I can't see how :key would create any conflicts either.

 /Henrik


 On Fri, Sep 4, 2009 at 8:23 AM, Tomas Hlavatyt...@logand.com wrote:
 Hi Henrik,

 First of all, to offload the server from having to build json all
 the time.

 your server must be very popular when it struggles to generate json;-)

 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js
 2) Parsing PDFs in OnDoc: works surprisingly well  fast in picolisp.
 3) Parsing postscript: function PsParser() in

 Another case where I built a parser on top of simple picolisp
 functions peek  char (i.e. without regular expressions, the picolisp
 way:-) is the xml parser now part of picolisp distribution in
 lib/xml.l. =A0Basically every picolisp webserver generates html or xml
 on the server side so I cannot see how generating json is any
 different performance-wise.

 Also, your code loops over all characters in the string and calls
 regular expression matcher many times. =A0This matching is redundant and
 the code can be faster by removing the regexp matcher lookehead and
 determining the state directly because sexp have very simple grammar
 anyway.

 Regards,

 Tomas
 --
 UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe


-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: The 64-bit version is complete

[Alexander Burger]

On Sun, Sep 06, 2009 at 04:28:04PM -0300, TC wrote:
 I don't see it in the repo, maybe you forgot to _push_?

Ah, sorry, then we have a misunderstanding. As far as I remember, we
agreed that I will not push ongoing development code (i.e. the 64-bit
stuff), and we wait until 3.0 is finished.

I suggest that we wait till the beginning of October, then set up a
fresh initial repository (I considered the current one as experimental)
which will contain the whole system including the 32-bit stuff (but not
the 64-bit stuff, as this is still too much in a flow).

I'll continue with providing the base system releases, if possible in
three-month-cycles as before, and everybody is free to add and maintain
extensions in the hg repo.


Even better I would find if I would not have to care about the hg repo
at all, and some of our specialists (tc.rucho, hsarvell, ..) could take
the responsibility of adding/updating base system changes to the repo.

This means that only the responsibility of the base system stays with
me, and I would have to implement custom change requests manually as
before, but this would save me a lot of time in total. The
responsibility for custom extensions and modifications in the repo stays
with the individual who initiated them.

Is this ok?

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe