Re: PicoLisp SSL Problem
Look at this: http://forums.mozillazine.org/viewtopic.php?f=38t=2416901 -- Rand On Feb 15, 2012, at 11:52 AM, Henrik Sarvell wrote: Yes, if FF blocks the result before Tamper gets to access it then what I said above is not correct, that is the big caveat. On Wed, Feb 15, 2012 at 5:43 PM, dexen deVries dexen.devr...@gmail.com wrote: On Wednesday 15 of February 2012 11:12:32 you wrote: On Wed, Feb 15, 2012 at 09:47:48AM +0100, Alexander Burger wrote: What I could see was that 'httpGate' does an accept() on the connection, but nothing else. So this means, that the certificate isn't sent at all! Forget that. I traced the wrong process :( The certificate is probably indeed sent. output from tcpdump and Konqueror suggests the cert is sent alright. there's that `ssldump' tool that dumps content of HTTPS session, could help. -- dexen deVries [[[↓][→]]] Already many of the mutants disguised as human beings are walking the streets of Earth's cities. -- Music Instructor, ``Electro City'' -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp is DEAD (Was: PicoLisp and its (lack of) libraries)
I have to agree with Alex here. This language has its place and is very useful in that place. I am currently doing embedded in C, and have no choice about what to use. But I have to say, I in very much in favor of the succinctness of PicoLisp and its ability to link with any library. If someone, Henrik, wants to use something else that is great, if you, Henrik, want to enhance PicoLisp with distributed databases, that would be great, too. I don't find any problems with PicoLisp, for what it is intended. Keep going Alex! And Happy Birthday! -- Rand On Sun, Jan 22, 2012, at 08:42 AM, Alexander Burger wrote: OK, I understand. The language is not useful or usable, and the Community (I count 70 members in this list) is silent. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: UB-Tree support
Hi Alex, I added an account recently apobits to Twitter - this is for an idea I am working on. Since it has to be portable to Mac, Windows, Android and iPhone, I have to do it in C, not picolisp :-( BTW, the verb form is twittered or better tweeted. A twitter is the sound a bird makes, and to tweet is the verb form for what a bird does. NO twote! Cheers ~Rand On May 20, 2011, at 7:20 PM, José Romero wrote: BTW, I felt that I should finally try Twitter! So I created an account a few days ago, and just now I twittered (tweeted, twote?) the good news about the UB-Tree into the world :D @Henrik: You are the first (and only one so far) I'm following ;-) Anybody else? Following you! i'm @cyborgar :] Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Problems with +Blob
Hi Henrik, I just went and read that too - links per inode would include both directories or files or a mix of both. I checked the filesystem code for this, the ext3 inode is limited by a 16bit links_count. Under linux (UNIX) a directory simply contains a list of names and their inodes (a link) - there is no difference at that level between a file and a sub-directory. So, yes, that applies to files, too. Alex, can that number of db files be reached (likely, not probable, impossible)??? Rand On Sun, Aug 16, 2009 at 7:11 PM, Henrik Sarvell hsarv...@gmail.com wrote: Works, but I can't pretend to understand how the folder and file naming wor= ks. I just checked the ext3 limits on wikipedia, apparently it can't handle more than roughly 32000 sub folders inside a folder, it's unclear whether that applies to files too or not. Anyway, how does it work, could this level be reached or is there a stopper somewhere? /Henrik On Sun, Aug 16, 2009 at 7:17 AM, Alexander Burgera...@software-lab.de wrot= e: Sorry to all. My mistake! I did not look closely enough :-( The two operations must be in opposite order, first the 'put' and then the 'out'. Otherwise the blob file might not exist yet. So the correct procdeure is: =A0 (put! Article 'body T) =A0 (out (blob Article 'body) =A0 =A0 =A0(prinl a really long text) ) Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: First 64-bit release
Hi Alex, Thanks for the explanation. I haven't seriously programmed in assembly since 1986. However, the mental transitions that you mention are very familiar to me. I remember starting to write macros for everything and very soon it didn't matter that there were often unnecessary instructions hidden in the macros. Performance was not important then, code readability was. The goal soon became to write everything in C and use assembler as little as possible. Your decisions here to write picolisp64 in assembler and define an optimum virtual assembler should lead to a very optimum system. Cheers, - Rand On Thu, Jul 23, 2009 at 8:21 AM, Alexander Burgera...@software-lab.de wrot= e: Hi Tomas, Also, it would allow for macros/shortcuts to automate common patterns. I think I have to try to explain some of the reasons that drive me. When I program in assembly, I switch to a completely different mindset. While writing a core function in assembly, I want it to be as close to the optimum as possible. It does not matter how often I re-arrange the code, or how long I need for that, because this function will be written just once, but called very often later. There lies also the fun of it. This is completely different from using Lisp to write applications. There I want to be as productive as possible, to have an easier life, and to be able to abstract as much as possible. On the assembly level, I want to know each individual bit personally. Try not to hide anything. I want to keep my mind within the data model, as described e.g. in doc64/structures. For example, I had a long fight with myself whether I should introduce and use constants like 'BIG', 'CDR', or 'TAIL'. They are defined in src64/defs.l: =C2=A0 (equ BIG 4) =C2=A0 =C2=A0# Rest of a bignum + bignum tag =C2=A0 (equ CDR 8) =C2=A0 =C2=A0# CDR part of a list cell =C2=A0 (equ TAIL -8) =C2=A0# Tail of a symbol A completely straightforward, good and normal thing in daily programming. It is used like that: =C2=A0 ld E (E CDR) =C2=A0# Take CDR What is my problem with that? It hides the true nature of the underlying data structures. It could instead be written as =C2=A0 ld E (E 8) =C2=A0# Take CDR which results in the x86-64 code =C2=A0 mov 8(%rbx), %rbx Now when I use an opaque constant 'CDR' instead of '8', I easily forget what goes on on the low level, and have a higher concept of a CDR in mind. This makes it more difficult in some situations to keep in control of the lower levels, and to recognize common patterns. If I use 'TAIL' instead of '-8', I easily forget how I am accessing the pointers of a cell, how they are related to the pointers of neighboring cells etc. Then I have to keep both concepts in mind at the same time, and constantly switch between them. The awareness about the nature of constant like 4, -8 is necessary to interconnect them to the pointer tags in the lowest four bits =C2=A0 cnt =C2=A0 ... S010 =C2=A0 big =C2=A0 ... S100 =C2=A0 sym =C2=A0 ... 1000 =C2=A0 cell =C2=A0... and I need to constantly juggle with knowing that cnt is 2, big is 4 and so on. For the same reasons I was reluctant to introduce macros like =C2=A0 cnt A =C2=A0# A short? which could equally be written as =C2=A0 test A 2 =C2=A0# A short? or, in this case =C2=A0 test B 2 =C2=A0# A short? Could I explain what I mean? Though each higher-level abstraction makes the code easier, more readable and (the important point) better searchable, it departs me more and more from the real model. This becomes very obvious when I debug the code with 'gdb'. Then you see only pointer structures, identified by the tag bits, and numeric constant offsets like -8, 4 and 8. Now I'm used to immediately see the type of a data object in the debugger, knowing that if it ends with a '8' it is a symbol, and if it ends with a '2' it is a short number or string. If I see in the debugger =C2=A0 $rbx =3D 0x2b484d2d6538 (contents of the register 'E'), it is a symbol, because it ends with a '8'. So I can inspect it by replacing the 8 with a 0 to get the cell pointer: =C2=A0 (gdb) x/2g 0x2b484d2d6530 =C2=A0 0x2b484d2d6530: 0x0612 =C2=A0 =C2=A0 =C2=A00x0= 0619438 You see that the 'TAIL' (the CAR of that cell) ends with a '2', so this is a name. The hex code 61 is the ASCII char a. What we have here is the symbol 'a'. =C2=A0 The value '0x00619438' of that is a symbol again (turns ou= t =C2=A0 to be NIL): =C2=A0 (gdb) x/2g 0x00619430 =C2=A0 0x619430 data_start+560: =C2=A0 =C2=A0 =C2=A00x04c494e2 = =C2=A0 =C2=A0 =C2=A00x00619438 (4e is 'N', 49 is 'I' and 4c is 'L') Well, as you see, I stayed with 'TAIL', and 'CDR', use the test macros 'cnt', 'big', 'sym' etc., and also implemented flow macros like 'if' and 'while'. I always try to keep their double-nature in mind. But there are limits on how far I want to go. E.g. push/pop: there are lots of
Re: Compiling on Mac
Hi Alex, From http://www.apple.com/macosx/ Coming September 2009 with every new Mac. Upgrade from Mac OS X Leopard f= or just $29. Yeah, it could be hoped that they also update the assembler. But there will likely be call interface updates and so on, and the 32 bit version will continue to work for now (except for case insensitive dependencies, which don't bother me at this time). So it will probably be less work to wait for the new version in September. And I still have a lot going on anyway. Now if I could just get an English keyboard for the thing (the German MAC keyboard is a catastrophe! [ =3D Alt-5 ] =3D Alt-6 | =3D Alt-n .. a real nightmare for programming. Cheers, - Rand On Tue, Jul 21, 2009 at 7:46 AM, Alexander Burgera...@software-lab.de wrot= e: Hi Randall, thanks for the research! I can't believe that there is only such a crippled assembler on the Mac. Alignment was in the earliest assemblers in the 1970s ;-) equiv - .set Not really satisfactory, because I would like to have an error message if there is a re-definition. align - .space Won't help. 'align' is a different operation, aligning to a multiple of a given value. string - .ascii =C2=A0 (check the syntax ...) Could work, but needs an explicit zero-byte. =C2=A0 =C2=A0mov =C2=A0 =C2=A0 =C2=A0$Nil, %rbx ?? =C2=A0 =C2=A0leaq Nil(%rip),%rbx This might involve many places. On the other hand, it could produce tighter code. Alex, compare hello.s: globl _a =C2=A0 =C2=A0 =C2=A0 =C2=A0 .data =C2=A0 =C2=A0 =C2=A0 =C2=A0 .align 2 Here we have '.align'? Otherwise, I think it might assemble. But I'm rather sure it will not run. Probably the C function call conventions will be utterly different, considering this 32/64 bit mixture. So the Mac OS is basically still a 32-bit operating system, with some 64-bit facilities. Should we be better wait for Snow Leopard? Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Alex, The *.s files don't assemble as expected: $ as -n x86-64.linux.base.s x86-64.linux.base.s:3:Unknown pseudo-op: .equiv x86-64.linux.base.s:3:Rest of line ignored. 1st junk character valued 72 (H). x86-64.linux.base.s:4:Unknown pseudo-op: .equiv x86-64.linux.base.s:4:Rest of line ignored. 1st junk character valued 67 (C). x86-64.linux.base.s:5:Unknown pseudo-op: .equiv x86-64.linux.base.s:5:Rest of line ignored. 1st junk character valued 90 (Z). x86-64.linux.base.s:6:Unknown pseudo-op: .equiv x86-64.linux.base.s:6:Rest of line ignored. 1st junk character valued 79 (O). x86-64.linux.base.s:7:Unknown pseudo-op: .equiv x86-64.linux.base.s:7:Rest of line ignored. 1st junk character valued 84 (T). x86-64.linux.base.s:8:Unknown pseudo-op: .equiv x86-64.linux.base.s:8:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:9:Unknown pseudo-op: .equiv x86-64.linux.base.s:9:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:10:Unknown pseudo-op: .equiv x86-64.linux.base.s:10:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:11:Unknown pseudo-op: .equiv x86-64.linux.base.s:11:Rest of line ignored. 1st junk character valued 73 (I). ... -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: 'native' and errno or *Err
Hi Alex, I tried to compile the 64 bit version on my macbook yesterday - no joy. I think I have to create the /usr/bin/picolisp and /usr/lib/picolisp links to the 32 bit version and then create the .s files. I didn't get that far yet. Thanks for the 'errno' call. I'll try again this evening btw. The 64 V3 version runs my sum.l flawlessly too. Rand On Tue, Jul 14, 2009 at 9:11 AM, Alexander Burgera...@software-lab.de wrot= e: Hi Randall, How do I get the value of errno after my call? Now there is an 'errno' function (64 bits only). For example: =C2=A0 : (in mist (read)) =C2=A0# Produce an error =C2=A0 !? (in mist (read)) =C2=A0 mist -- Open error: No such file or directory =C2=A0 : (errno) =C2=A0# Get the error number =C2=A0 - 2 Then this also works: =C2=A0 : (native NIL strerror 'S (errno)) =C2=A0 - No such file or directory Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Compiling on Mac (was: 'native' and errno or *Err)
Hi Alex, I don't have the specifics in my head, but it complains that it cannot find *darwin*.s files. And when I just try as linux.*.s I get a lot of error messages. I haven't looked deeper yet, but the as may be tuned somehow for Mac - it is GNU as, but . I'll take a closer look this evening and let you know (post my findings her= e). Cheers, - Rand On Tue, Jul 14, 2009 at 9:46 AM, Alexander Burgera...@software-lab.de wrot= e: Hi Randall, I tried to compile the 64 bit version on my macbook yesterday - no joy. I think I have to create the /usr/bin/picolisp and /usr/lib/picolisp links to the 32 bit version and then create the .s files. =C2=A0I didn't get that far yet. This should not be necessary. The .s files are in the release already, so calling 'make' should only invoke the GNU assembler. Only if you modify one of the src64/*.l files, you need a runnable bin/picolisp (no matter if 32 or 64 bits) to re-create the *.s files. Thus, a bootstrapping without a pre-installed PicoLisp should work. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
'native' and errno or *Err
Hi Alex, I am trying to use 'native', am getting only 'NIL' as the return value, where I would like to be getting a file descriptor number. How do I get the value of errno after my call? Cheers, - Rand -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Deprecate 'begin'?
Hi Alex, none from me! Rand On Sat, Jul 11, 2009 at 12:17 PM, Alexander Burgera...@software-lab.de wrote: Hi all, has anybody ever used 'begin' (i.e. nested database transactions)? I'd rather doubt it. I used it just once, and only for a short time. This functionality cannot be implemented in the 64-bit version, because the low-level representation of external symbols changed. Besides this, it is rather inefficient and not as useful as I thought. I want to deprecate it also in the 32-bit version for compatibility reasons. Any objections? Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: The 'native' function (Was: First 64-bit release)
Hi Alex, This looks very cool! Yes, that is what I wished for at bmsc. Thanks! Rand On Tue, Jul 7, 2009 at 7:48 PM, Alexander Burgera...@software-lab.de wrote: now the 'native' C function call is working. It is in the testing release, and I think it looks quite nice! :-) -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Three things for me to try this evening... Rand On Wed, Jun 17, 2009 at 4:40 PM, Tomas Hlavaty t...@logand.com wrote: Hi Jon, Randall and Alex, this might not be related but still an idea. =C2=A0Have you tried to buil= d picolisp with gcc optimizations off? =C2=A0Recently, I had a problem with with code which was something like (mapcar char ...) where picolisp crashed for some strange reason. =C2=A0The problem went away when I remov= ed -O2 flag from Makefile (I think it worked with -O1, not sure now). =C2=A0= I think there was some other problem mentioned on this mailing list that was caused by -O2... Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Jon, Perhaps I can try it this week. I am interested in this. Alex, would you like to arrange a debugging session with me on a return trip through Munich? Rand On Tue, Jun 16, 2009 at 10:23 AM, Jon Kleiserjon.klei...@usit.uio.no wrote: I have now tested the OpenGL programs again, with the very latest testing version of Pico Lisp, and with the latest OS X (10.5.7) on my Mac, and I still get the Bus errors. If there are other users on this list that run Pico Lisp on Intel Mac, I would be interested to hear whether you get those Bus errors. The basic OpenGL library needed can be found here: http://folk.uio.no/jkleiser/pico/gl.tgz The most stripped down program that gives me Bus error, is this: http://folk.uio.no/jkleiser/pico/gltst.l As you see, it contains an explicit call to the garbage collector, (gc). All it takes to get the error here, is to move the mouse. Most of my other OpenGL programs give me a Bus error after a while. One exception is this: http://folk.uio.no/jkleiser/pico/gl/cube.l So, do you get the Bus errors on your Intel Mac? If you do, do you have any idea where the bug could be? (In the gl library, in Pico Lisp, or in the Mac OS X?) -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Alex, I'll get everything installed, and let you know if I can reproduce the problem. Cheers, - Rand On Tue, Jun 16, 2009 at 11:20 AM, Alexander Burgera...@software-lab.de wrote: Alex, would you like to arrange a debugging session with me on a return trip through Munich? Good idea! I don't know yet whether I travel to Kufstein this week. I'll call you. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Alex, Jon, I just installed the current testing picoLisp (now: 17.6.09) and the gl libraries. I get exactly your described behavior, Jon, gltst.l immediately produces a bus error signal. I then started it with gdb - and it runs fine - no buserror core dump. Hmmm. No more time right now. Cheers, - Rand On Tue, Jun 16, 2009 at 11:51 AM, Randall Dow randall@gmail.com wrote: I'll get everything installed, and let you know if I can reproduce the problem. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: 'call' function disables echoing input
Hi Alex, Do shells really? A simple case of the opposite: start vim, kill -9 from another shell, and you have to type stty sane. I think it is more up to the application to save and restore. Although, picolisp does bring surprises, whether you start with dbg.l and *Dbg on or not. But I think the way it works is ok, there are real advantages, once you understand it. Cheers - Rand On Fri, May 8, 2009 at 2:35 PM, Alexander Burger a...@software-lab.de wrote: Yes. I hope in time we'll get 'call' right. It must be possible, because shells do the same. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: 'call' function disables echoing input
Hi Alex, So, something must still be wrong. I just never noticed it because I only called non-interactive processes (except 'vim'). But that is my point - vim goes to a lot of effort to handle the STOP and CONT signals and get the terminal handling right. I have created apps similar to vim - and the onus is on the app to do it right, not the calling shell! The calling shell does have some things to do, but as you point out: vim and picolisp work well together! That can only happen if picolisp is basically doing it's part right. (look up onus: Beweislast, Verspflichtung) Cheers! - Rand -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: postscript utf8
Hi Tomas, I would presume that you are beginning to get close to the reason that one often encapsulates strings into an object. You need to know the display length of something to center it, and that means that you want to know the length of the string. Without an encapsulating object, you need to recalculate the length often. For most applications, this is quite acceptable, but if you are recalculating the length too often, you might consider encapsulating your strings into some sort of a string object. @Master: what do you think?? (I mean: Alex :) Hey, Tomas, where are you? Are you Czech? My son from Prague is here visiting in Munich this weekend! Cheers! - Rand On Sun, Apr 26, 2009 at 9:06 AM, Tomas Hlavaty t...@logand.com wrote: Hi Alex, there was a bug in the previous code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((=3D 130 C) # utf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let? L (cdr (ass= oc C *PsGlyph)) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (prinl )= ) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (prin [= ) should be: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((=3D 130 C) # utf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let? L (cdr (assoc C *P= sGlyph)) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(prinl ) s= how) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(prin [) However, centering unicode/non-ascii characters does not work. =C2=A0Any ideas how to achieve that? That's probably a question for comp.lang.postscript ;-) Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: parsing input
Hi Alex, Thanks, will try it, now going to pick up Francesca. - Rand On Sat, Apr 25, 2009 at 7:41 AM, Alexander Burger a...@software-lab.de wro= te: Hi Tomas, 01/02/2009 =C2=A0 30.00 =C2=A0 =C2=A0400.00 =C2=A0 =C2=A0t =C2=A0 =C2= =A0Randall Dow ... (use (@A @B @C @D @E) =C2=A0 =C2=A0(when (match '(@A @B @C @D @E) (line)) =C2=A0 =C2=A0 =C2=A0 (mapcar clip (list @A @B @C @D @E)) ) ) While this is an elegant solution, it does not work as expected, because the '@X' symbols do not necessarily match non-white characters. I would stick with Randall's solution, just a little simplified: =C2=A0 (filter prog (split (line) )) Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: parsing input
Thanks all! (let L (mapcar pack (filter prog (split (line) ))) converts: 01/02/2009 30.00400.00tRandall Dow to (01/02/2009 30.00 400.00 t Randall Dow) which is just what I want. I could have left out the '(mapcar pack' and left it as a char list, which would still produce a more efficient program overall. Thanks Alex! Rand On Sat, Apr 25, 2009 at 10:51 AM, Tomas Hlavaty t...@logand.com wrote: Hi Randal Alex, While this is an elegant solution, it does not work as expected, because the '@X' symbols do not necessarily match non-white characters. I see, I should have tried that first;-) Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
parsing input
Hi Alex, I read a line, which looks something like: 01/02/2009 30.00400.00tRandall Dow in which the fields are separated by a varying number of spaces. That gets put into L, and then I delete the NILs that come from multiple spaces. Do you have a suggestion for a better way than this: (let L (mapcar pack (split (line) )) (loop (NIL (memq NIL L)) (setq L (delete NIL L)) ) Regards, - Rand -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: database contest article
Hey, this is getting to be fun! Alex, thanks for stopping and having a beer! Till next time! Cheers! - Rand On Thu, Dec 4, 2008 at 6:56 PM, Alexander Burger [EMAIL PROTECTED]wrote: On Thu, Dec 04, 2008 at 05:06:39PM +, Tomas Hlavaty wrote: are we officially adopting blame culture? ;-) No, no, just protecting Randall :-) Because I'll meet him in one and a half hours in Munich. Cheers, - Alex -- --=_Part_40801_16679864.1228426029980 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey, this is getting to be fun!nbsp; Alex, thanks for stopping and having a beer!brbrTill next time!brbrCheers!br- Randbrbrbrdiv class=gmail_quoteOn Thu, Dec 4, 2008 at 6:56 PM, Alexander Burger span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/span wrote:br blockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;div class=Ih2E3dOn Thu, Dec 04, 2008 at 05:06:39PM +, Tomas Hlavaty wrote:br gt; are we officially adopting blame culture? ;-)br br /divNo, no, just protecting Randall :-)br Because I#39;ll meet him in one and a half hours in Munich.br br Cheers,br - Alexbr divdiv/divdiv class=Wj3C7c--brbr /div/div/blockquote/divbr --=_Part_40801_16679864.1228426029980-- -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
unsubscribe
Good bye [EMAIL PROTECTED] :-( You are now unsubscribed moving address -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
subscribe
--=_Part_49457_20659296.1224836490221 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hmm, that didn't work! -- Randall Dow +49-176-24129991 --=_Part_49457_20659296.1224836490221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hmm, that didn#39;t work!br clear=allbr-- brRandall Dowbr+49-176-24129991br --=_Part_49457_20659296.1224836490221-- -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
subscribe
--=_Part_3856_17715030.1224838301864 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Cheers! - Rand +49-176-24129991 home: +49-89-12417690 --=_Part_3856_17715030.1224838301864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline br clear=allbr-- brCheers!br- Randbrbr+49-176-24129991 nbsp; nbsp; home: +49-89-12417690br --=_Part_3856_17715030.1224838301864-- -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
How to best ...
Hi Alex, I would like to do something like: (de keyword @ ... ) (de main () (eval L) where L looks like: '(keyword 'any)' But that doesn't work directly. How would you do this efficiently? Seems like I've done something similar, with plio, but we defined symbols to make it work. Thanks! Rand -- Randall Dow Witneystrasse 7, D-82008 Unterhaching, Germany phone: +49-89-12417690 mobile: +49-176-24129991 -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
