Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - hartrock

#76
Thanks: this is good for my usecase (and probably some of others).



Some feedback:

[*]Inconsistency:

Using additional "debug" flag, "list debug" differs from "raw debug", which does not show sent headers:

> (get-url "http://localhost/doesNotExist.txt" "list debug")
GET /doesNotExist.txt HTTP/1.1
Host: localhost
User-Agent: newLISP v10604
Connection: close

HTTP/1.1 404 Not Found

("Date: Fri, 17 Jul 2015 11:17:21 GMTrnServer: Apache/2.2.22 (Debian)rnVary: Accept-EncodingrnContent-Length: 289rnConnection: closernContent-Type: text/html; charset=iso-8859-1rnrn"
 "ERR: server code 404: HTTP/1.1 404 Not Foundrn<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">n<html><head>n<title>404 Not Found</title>n</head><body>n<h1>Not Found</h1>n<p>The requested URL /doesNotExist.txt was not found on this server.</p>n<hr>n<address>Apache/2.2.22 (Debian) Server at localhost Port 80</address>n</body></html>n"
 404)
> (get-url "http://localhost/doesNotExist.txt" "raw debug")
("Date: Fri, 17 Jul 2015 11:17:30 GMTrnServer: Apache/2.2.22 (Debian)rnVary: Accept-EncodingrnContent-Length: 289rnConnection: closernContent-Type: text/html; charset=iso-8859-1rnrn"
 "ERR: server code 404: HTTP/1.1 404 Not Foundrn<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">n<html><head>n<title>404 Not Found</title>n</head><body>n<h1>Not Found</h1>n<p>The requested URL /doesNotExist.txt was not found on this server.</p>n<hr>n<address>Apache/2.2.22 (Debian) Server at localhost Port 80</address>n</body></html>n"
 404)

I would expect to see sent headers for "raw debug", too.
  • [*]Docu:

    Difference in semantics between "raw" and "list" seems to be, to avoid redirection in "raw" case (not tested); because both return the HTTP status code as third element (which is good and should stay IMO):

    > (get-url "http://localhost/doesNotExist.txt" "list")
    ("Date: Fri, 17 Jul 2015 11:18:07 GMTrnServer: Apache/2.2.22 (Debian)rnVary: Accept-EncodingrnContent-Length: 289rnConnection: closernContent-Type: text/html; charset=iso-8859-1rnrn"
     "ERR: server code 404: HTTP/1.1 404 Not Foundrn<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">n<html><head>n<title>404 Not Found</title>n</head><body>n<h1>Not Found</h1>n<p>The requested URL /doesNotExist.txt was not found on this server.</p>n<hr>n<address>Apache/2.2.22 (Debian) Server at localhost Port 80</address>n</body></html>n"
     404)
    > (get-url "http://localhost/doesNotExist.txt" "raw")
    ("Date: Fri, 17 Jul 2015 11:18:11 GMTrnServer: Apache/2.2.22 (Debian)rnVary: Accept-EncodingrnContent-Length: 289rnConnection: closernContent-Type: text/html; charset=iso-8859-1rnrn"
     "ERR: server code 404: HTTP/1.1 404 Not Foundrn<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">n<html><head>n<title>404 Not Found</title>n</head><body>n<h1>Not Found</h1>n<p>The requested URL /doesNotExist.txt was not found on this server.</p>n<hr>n<address>Apache/2.2.22 (Debian) Server at localhost Port 80</address>n</body></html>n"
     404)
  • [/list]
    #77
    Let me explain my current usecase a bit (there is no use of newLISP -http mode).



    Usecase (being topic in this thread) is HTTP-server testing by newLISP scripts, being the clients of an HTTP server.

    Therefore I wanted to get rid of calling curl commands by newLISP scripts (after getting rid of curl commands as part of bash scripts). Why using curl, if there already is similar functionality built in newLISP?



    So I've started using (get|post|delete|put)-url funcs, which looked promising for this purpose.

    But for fully testing server behavior, it makes sense to have access to whole server response - headers, content (which mostly is part of a server reply) and HTTP status code in a unique way.



    Because there already is

    [*] some parsing of server responses for creating HTTP net-errors,
  • [*] "devel" mode for *-url requests, giving almost all headers;
  • [/list]

    at first sight less effort seems to be needed for a great improvement of server testing capabilities.

    But I may be wrong here, because there surely are some complications (from the manual):
    Quoteget-url handles redirection if it detects a Location: spec in the received header and automatically does a second request. get-url also understands the Transfer-Encoding: chunked format and will unpack data into an unchunked format.

    And if someone wanted to test e.g. redirection behavior of some server, then there may be further feature requests... (but not from me ;-) )



    I'm assuming, that implementing such functionality as a module - funcs possibly named http-(get|post|delete|put|head)-url - would double much stuff already there as part of built in functions (and reuse instead of doubling is a good thing).



    It was never meant to be full a featured web server.[/quote]
    #78
    Thanks: OK now!



    Another thing (kind of feature request):

    What about
    Quote(http-error) for more fine-granular checking of http responses?


    Currently I have client code like (snippet):

           (setq res (get-url (append "http://localhost/ViPLab/" r))
                  net_err (net-error))
            (if (not net_err)
                (if (not (find "^ERR: server code 404:" res 0))
                    (print res)
                    (begin
                      (logg:err (0 (find "n" res) res))
                      (exit 1)))
                (begin
                  (logg:err net_err)
                  (exit 1)))

    There may be a need to extend this further for other error messages (formatting stable?)...



    It would be nice to have a unique and simple access to last HTTP status/error code (may be nil for no or (syntactically) invalid server response).

    It already will be parsed somewhere...



    Then simple error checking could be done by (htt-status is better than http-error)
    (>= (http-status) 400)
    or so (besides checking for net-error).



    (get-url) "list" mode does not help for a unique access:

    there is no HTTP status (error or not) in headers part (which I would expect there, because it is a header), but only some error messages (covering which HTTP status codes?) prepended to content from server; and if there is no error (which HTTP status codes?), there is no access to HTTP status code at all (there is more no-error status codes than just '200 OK').
    #79
    Hello Lutz,



    first thank you for the very fast reaction!



    Checking last (just downloaded) devel version gives problems:

    sr@mad:/tmp/newlisp-10.6.4$ make check
    ./newlisp qa-dot

    Testing built-in functions ...
    make: *** [check] Segmentation fault

    But:

    sr@mad:/tmp/newlisp-10.6.4$ ./newlisp qa-dot

    Testing built-in functions ...
    upper-case of UTF8 characters not available - not critical -
    lower-case of UTF8 characters not available - not critical -
                                 
    Testing contexts as objects and scoping rules ...

    total time: 2730

    >>>>> ALL FUNCTIONS FINISHED SUCCESSFUL: ./newlisp

    sr@mad:/tmp/newlisp-10.6.4$ make testall
    make checkall | grep '>>>'
    Segmentation fault
    >>>>> Dictionary API tested SUCCESSFUL
    >>>>> XML API tested SUCCESSFUL
    >>>>> XML callback tested SUCCESSFUL
    >>>>> JSON translation tested SUCESSFUL
    >>>>> Signal testing SUCCESSFUL
    >>>>> Network eval and network file functions IPv4 SUCCESSFUL
    >>>>> Network eval and network file functions IPv6 SUCCESSFUL
    >>>>> The Cilk API tested SUCCESSFUL
    >>>>> Reference testing SUCCESSFUL
    >>>>> Time per simple message: 8 micro seconds
    >>>>> Time per round trip : 70 micros seconds
    >>>>> Time per proxy trip: 20 micro seconds
    >>>>> Message API tested SUCCESSFUL
    >>>>> Memory allocation/deallocation SUCCESSFUL
    >>>>> Exception testing SUCCESSFUL
    >>>>> Floating point tests SUCCESSFUL
    >>>>> FOOP nested 'self' tested SUCCCESSFUL
    >>>>> FOOP symbol protection SUCCESSFUL
    >>>>> UNIX local domain sockets SUCCESSFUL
    >>>>> In-place modification passed SUCCESSFUL
    >>>>> 0.005 ms per write->read pipe/fork (0.0356 ms Mac OSX, 1.83 GHz Core 2 Duo)
    >>>>> libffi API testing SUCCESSFUL
    >>>>> callback API 1234567890 (simple callback API) SUCCESSFUL
    >>>>> callback API 1234567890 12345.6789 (extended callback API) SUCCESSFUL
    >>>>> struct tested SUCCESSFUL
    >>>>> struct ptr tested SUCCESSFUL
    >>>>> testing big ints arithmetik ...
    >>>>> abs bigint float gcd length zero? + - * / % ++ -- big ints tested SUCCESSFUL
    >>>>> parsing big integers SUCCESSFUL
    >>>>> Benchmarking all non I/O primitives ... (may take a while)
    >>>>> total time: 1503.266
    >>>>> Performance ratio: 0.62 (1.0 on MacOSX 10.9, 2.3GHz Intel Core i5, newLISP v10.6.0-64-bit)

    Digging deeper this difference in behavior is suspect:

    sr@mad:/tmp/newlisp-10.6.4$ make check | more
    ./newlisp qa-dot

    Testing built-in functions ...
      -> >>          
      -> array                
      -> begin                
      -> clean              
      -> cpymt                  
      -> def-                  
      -> div                  
      -> error              
      -> file?                
      -> gammai            
      -> inc                
      -> lambda?train          
      -> macro-case          
      -> net-close          
      -> net-receive            
      -> now                      
      -> pop-                
      -> prompt-event          
      -> read-file            
      -> replace              
      -> series            
    make: *** [check] Segmentation fault
      -> share                
    sr@mad:/tmp/newlisp-10.6.4$ ./newlisp qa-dot | more

    Testing built-in functions ...
      -> >>          
      -> array                
      -> begin                
      -> clean              
      -> cpymt                  
      -> def-                  
      -> div                  
      -> error              
      -> file?                
      -> gammai            
      -> inc                
      -> lambda?train          
      -> macro-case          
      -> net-close          
      -> net-receive            
      -> now                      
      -> pop-                
      -> prompt-event          
      -> read-file            
      -> replace              
      -> series            
      -> sort                
      -> sys-error            
      -> transpose   ght          
    upper-case of UTF8 characters not available - not critical -
    lower-case of UTF8 characters not available - not critical -
      -> xml-parse            
                                 
    Testing contexts as objects and scoping rules ...

    total time: 2753

    >>>>> ALL FUNCTIONS FINISHED SUCCESSFUL: ./newlisp


    First checks 'share', second not?



    OS:

    sr@mad:/tmp/newlisp-10.6.4$ uname -a
    Linux mad 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux
    #80
    A GET resulting into a reply with Content-Length 0 should be possible: from

      http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#message.body">http://svn.tools.ietf.org/svn/wg/httpbi ... ssage.body">http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#message.body

    :
    Quote
    The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. ...



    ... All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length.

    So this applies to e.g. '200 OK' and  '404 Not Found' responses, which may have a zero message body.



    newLISP:

    sr@mad:~$ newlisp
    newLISP v.10.6.2 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h

    > (get-url "http://localhost/empty.txt" "debug")
    GET /empty.txt HTTP/1.1
    Host: localhost
    User-Agent: newLISP v10602
    Connection: close

    HTTP/1.1 200 OK

    "ERR: HTTP document empty"
    > ; but:
    > (get-url "file:///tmp/empty.txt" "debug")
    ""


    curl:

    sr@mad:~$ curl -v -X GET http://localhost/empty.txt
    * About to connect() to localhost port 80 (#0)
    *   Trying ::1...
    * connected
    * Connected to localhost (::1) port 80 (#0)
    > GET /empty.txt HTTP/1.1
    > User-Agent: curl/7.26.0
    > Host: localhost
    > Accept: */*
    >
    * additional stuff not fine transfer.c:1037: 0 0
    * HTTP 1.1 or later with persistent connection, pipelining supported
    < HTTP/1.1 200 OK
    < Date: Fri, 10 Jul 2015 12:49:10 GMT
    < Server: Apache/2.2.22 (Debian)
    < Last-Modified: Fri, 10 Jul 2015 12:10:49 GMT
    < ETag: "8075b-0-51a84433bdbcf"
    < Accept-Ranges: bytes
    < Content-Length: 0
    < Vary: Accept-Encoding
    < Content-Type: text/plain
    <
    * Connection #0 to host localhost left intact
    * Closing connection #0

    (empty message body).



    Ideas:

    [*] (http-error) for more fine-granular checking of http responses?
  • [*] net-error '24 HTTP document empty' only (possibly with 'empty' -> 'missing'), if there is no 'Content-Length or Transfer-Encoding header' for a response with an HTTP error code needing a message body?
  • [/list]
    #81
    Thanks for clearifying the difference between symbols and Tree or (ctxt "someKey") hashmap values.



    My usecase is a state machine modeled by a hash map with string state IDs as keys, where I want to count state changes. So I have two Tree hash maps: one for the states, another for the counters; both with same string keys.

    Best solution I think is to init the corresponding counter hash map val with 0, just with adding a new state to state machine hashmap (which will be done by a func); so above check for nil can be omitted.



    Using symbol keys for states like sm:someState would be possible, too; but then there could be a conflict with funcs like sm:add-state, located in same context as state hashmap.
    #82

    sr@mad:~$ newlisp
    newLISP v.10.6.2 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h

    > (new Tree 'hm)
    hm
    > (hm "foo" (+ (or $it 0) 1))
    1
    > (++ (hm "foo"))
    2
    > ; OK, but:
    > (++ (hm "bar"))

    ERR: invalid parameter in function ++
    >

    Is this a bug, or is there a reason for this behavior?



    It would be nice, if checking for nil could be avoided here.
    #83
    newLISP in the real world / Re: newlisp-js license?
    January 06, 2014, 01:46:40 AM
    Hello Hans-Peter,
    Quote from: HPWHello Lutz,



    Most JavaScript Frameworks and library's can be used under MIT-license:



    http://en.wikipedia.org/wiki/MIT_License">http://en.wikipedia.org/wiki/MIT_License



    How does newlisp-js fit in such enviroment?

    Can it be used in combination with this Frameworks and with own js and Lisp-code?

    Or are own js/lisp again data for the Interpreter?

    The MIT license is a mostly liberal one: so there shouldn't be any problems to use newLISP together with MIT licensed libs and to distribute the resulting thing under the newLISP license (GPL).



    Problems could arise the other way: if you want to distribute newLISP together with some Javascript software, the MIT license probably could not be used for this, because GPL is more restricted and forbids some things, which an MIT license allows.



    Note: I'm not a lawyer, but I have read something about these issues in the process of choosing a license for

      http://www.evolgo.de/RYT/">http://www.evolgo.de/RYT/

    (AGPL'ed).
    #84
    newLISP newS / Re: newLISP in a browser
    January 03, 2014, 02:03:06 AM
    Just a few thoughts:
    Quote from: Lutz
    (2) I wonder if there is JS code from other applications, which could be used.

    I can say something about experiences I've made with development of

      http://www.evolgo.de/RYT/">http://www.evolgo.de/RYT/

    some time ago.

    For user interaction this heavily uses jQuery and jQueryUI as tools for reaching browser compatibility (and many other libs for e.g. SVG stuff). It runs in almost all browsers (Firefox, Safari, Chrome; but probably not IE (due to SVG stuff)).

    From my experiences (some time ago) I can recommend using jQuery stuff for reaching browser compatibility (instead of trying to build such a thing yourself).



    For a newLISP repl a light-weight editor is needed.

    Question is, how to proceed: to implement such a thing by using browser side newLISP - enriched by some Javascript interface - or choosing some free Javascript one? As more will be used from the Javascript world, as more dependencies have to be managed...

    Possibly first using a free one and then going a newLISP way?



    Another question is how to proceed organizationally: browser side newLISP outside the newLISP core could well be a community project; e.g. for:

    [*] Javascript/DOM bindings,
  • [*] accessing browser storage,

  • [*] UI widgets;
  • [/list]

    to name a few.

    Why? Because this could be too much for a single person doing much other stuff ;-)
    #85
    newLISP newS / Re: newLISP in a browser
    January 03, 2014, 12:48:57 AM
    Quote from: HPW
    I wonder why the Emscripten-generator/auhor decided to make a popup-promt as the input-element.

    To have synchronous input behavior should be the reason; see:

      https://github.com/replit/jsrepl#standard-input-hacks">https://github.com/replit/jsrepl#standard-input-hacks

    (reached from https://github.com/replit/repl.it#replit">https://github.com/replit/repl.it#replit).
    #86
    Quote from: AstrobeThis is a property named stability (https://en.wikipedia.org/wiki/Sorting_algorithm#Stability">https://en.wikipedia.org/wiki/Sorting_a ... #Stability">https://en.wikipedia.org/wiki/Sorting_algorithm#Stability), which depends on the sorting algorithm.


    Thanks to the pointer: this is the point of my question.

    I've updated the post title accordingly.



    Condensed the question could be: is (sort) stable according the link above?
    #87
    [Update 2014-01-02] links: emscripten, Resig's blog entry to asm.js.



    Beginning of new year and after doing things with newLISP for a while, it is a good time to say thanks to Lutz for:
    [*] publishing newLISP under a community oriented open source license;
  • [*] being open-minded regarding suggestions for improvements (this is not a matter of course after working with a self designed language and developing it further for such a long time);

  • [*] being communicative with giving comments to many topics: for a better understanding, why some things are as they are (which helps to learn and to avoid unsuited paths).
  • [/list]

    I've seen many programming language following different paradigms so far; amongst them are Pascal, Lisp (a classical variant sitting at terminals at a computer science department), C (near to the metal), C++ (the former + OOP with metal), Smalltalk (a very nice language for doing OOP consequently without thinking about the metal (view of Smalltalk programmers, VM implementors always (there may be rare exceptions) have to deal with the metal)), F-Logic (logical programming paradigm).



    Thinking about writing a C interpreter for Kernel http://web.cs.wpi.edu/~jshutt/kernel.html">http://web.cs.wpi.edu/~jshutt/kernel.html, I've started working through a thick book about garbage collection (because such a project would need a garbage collector). Now I've stumbled about a new language just avoiding this big can of worms: it's very interesting to me, what's possible without GC and just ORO rules.



    newLISP gives me (the unexpected) motivation to learn a new language. Under the things I like are:

    [*] Clearly functional, but without being dogmatically functional (destructive functions where it makes sense).
  • [*] Very good docs.

  • [*] Very fast reaction with fixes to bug reports.

  • [*] Let the OS make for which it is made for: e.g.

       
    [*] -> light weight processes instead of light weight threads.
  • [/list]

  • [*] The feeling, that there is a good sense for balancing different features to get high expressiveness without feature bloat (which would be difficult to be fully grasped).

  • [*] The capability of storing the state of a started newLISP system: this reminds me on Smalltalk images; possibly this feature could be used for a similar IDE functionality like in Smalltalk systems.

  • [*] System composition by starting newLISP and loading modules (libs): this is good for avoiding code bloat (in Smalltalk systems there is often the need to strip a very big development system (which can be hard)).
  • [/list]

    One newLISP thing, I've stumbled over recently.

    To me the following makes sense (this said with having some but without having much experience with newLISP):
    [*] To prefer expanding of nested lambdas against proliferation of newly generated symbols with lambdas bound to them (closure style, see http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=4400&hilit=uuid">http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=4400&hilit=uuid). I think this is in line with the philosophy of the language.

    I assume, the latter could lead to symbols bound to lambdas hanging around not being GCed (because there is none). On the other side there is the possibility to automatically generate names for symbols bound to lambdas, if it is really needed (due to the flexibility of the language): but then you should know why you are deviating from the default (philosophy of the language), and do it explicitely.[/list]


    At last an interesting thing outside, but related to porting newLISP.

    There is emscripten:

      https://github.com/kripken/emscripten/wiki">https://github.com/kripken/emscripten/wiki

    ; and here is asm.js:

      http://ejohn.org/blog/asmjs-javascript-compile-target/">http://ejohn.org/blog/asmjs-javascript-compile-target/

      https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/">https://hacks.mozilla.org/2013/12/gap-b ... mizations/">https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/

      http://asmjs.org/spec/latest/">http://asmjs.org/spec/latest/

    .

    This could lead to some newLISP interpreter running inside the browser, without too much porting effort.

    Not to ignore the issues: good Javascript and DOM bindings are laborious (these and a newLISP interpreter written directly in Javascript could be an interesting project on its own, too).
    #88
    [2. Update 2014-01-02]: it has a stable ordering (see Lutz' reply).

    [1. Update 2014-01-02]: added 'stable' to title (see replies below).



    Example:

    > (setq l '( ("0" 3) ("1" 3) ("2" 3) ("3" 3) ("4" 3)  ("foo" 2) ("bar" 4) ("foo" 1) ("bar" 5)  ("5" 3) ("6" 3) ("7" 3) ("8" 3) ("9" 3)))
    (("0" 3) ("1" 3) ("2" 3) ("3" 3) ("4" 3) ("foo" 2) ("bar" 4) ("foo" 1) ("bar" 5) ("5" 3) ("6" 3) ("7" 3) ("8" 3) ("9" 3))
    > (sort (copy l) (fn (x y) (<= (last x) (last y))))
    (("foo" 1) ("foo" 2) ("0" 3) ("1" 3) ("2" 3) ("3" 3) ("4" 3) ("5" 3) ("6" 3) ("7" 3) ("8" 3) ("9" 3) ("bar" 4) ("bar" 5))
    > (sort (copy l) (fn (x y) (< (last x) (last y))))
    (("foo" 1) ("foo" 2) ("9" 3) ("8" 3) ("7" 3) ("6" 3) ("5" 3) ("4" 3) ("3" 3) ("2" 3) ("1" 3) ("0" 3) ("bar" 4) ("bar" 5))
    > ;;
    > (= (sort (copy l) (fn (x y) (< (last x) (last y)))) (reverse (sort (copy l) (fn (x y) (>= (last x) (last y))))))
    true
    > (= (sort (copy l) (fn (x y) (> (last x) (last y)))) (reverse (sort (copy l) (fn (x y) (<= (last x) (last y))))))
    true


    Observations:

    Sorting with

    - '<=' or '>=' does not change the order of elements compared '=';

    - '<=' results into reversed elements of sorting with '>', and

    - '>=' resutls into reversed elements of sorting with '<' .



    Is this behavior guaranteed?

    In the (sort) section of the manual there is no statement regarding the '=' case.

    Sorting behavior of elements compared equal could be different without violating their sorting relation '<', '<=', '>' or '>=': in principle the ordering amongst elements compared '=' could be *arbitrary* after sorting.



    Motivation:

    I've started sorting a similar list with '<' and handled '=' elements specifically, because their order had changed compared with the original list (without being surprised about this effect). After that I've seen, that sorting with '<=' does exactly what I wanted (keeping original ordering of elements compared '='), without specific handling of the '=' case.

    Question remains, if this can be exploited or is just an implementation incident (which may change in a later newLISP version).
    #89
    Regarding refs, lists and arrays behave similar, but not the same.

    There seems to be a possibility for further unification.



    This works for both:

    (setq l (sequence 1 10)
          a (array 10 l))
    ;;
    ;; Applying refs works for both lists and arrays:
    (setq r (ref 5 l))
    (l r)
    (a r)

    But getting a ref does only work for lists (see above); this does not work:

    > (ref 5 a)

    ERR: list expected in function ref : (1 2 3 4 5 6 7 8 9 10)


    What about having refs for arrays, too?



    Then this would work, too:

    (setq r (ref 5 a))
    (l r)
    (a r)


    The semantics of an array ref could/should be the same as for list refs.



    Such unification would be good for functions operating on containers - being agnostic against the array/list difference.



    Because there already is setf for arrays, I'm assuming that most machinery to get this done already exists.
    #90
    This should work under most (all?) Linux systems:

    (setq tput_cols (exec "tput cols"))
    (if tput_cols (pretty-print (- (int (tput_cols 0)) 11)))
    ;;
    ;; then try:
    (symbols)