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 - cmpitg

Pages1
#1
Anything else we might add? / Re: Documentation Fix
June 22, 2011, 07:21:32 PM
On newLISP FAQs page, section 6 Does newLISP have hash tables?,



     
[*]"better for key acces" should be "better for key accessing" (I think accessing is better than access since we're talking about the act, not the capability, right?)
 
  • [*]The link to "Problems with hash tables" is dead.
    • [/list]

    Please fix them.
    #2
    Whither newLISP? / Re: Common Lisp newLisp module?
    June 22, 2011, 07:10:53 PM
    How about implementing newLISP inside ANSI Common Lisp? I'm (slowly) doing one with Emacs Lisp.
    #3
    Whither newLISP? / Re: Tail call optimization
    June 22, 2011, 10:36:41 AM
    I see.  I just want to write functions with functional programming style. In my oppinion, it's a disadvantage of newLISP not to have tail call optimization.
    #4
    Whither newLISP? / Tail call optimization
    June 22, 2011, 07:14:56 AM
    I have done some search in the forum but yet I haven't found the answer for a just-out-of-curiosity question: Does newLISP do tail call optimization?
    #5
    Anything else we might add? / Documentation Fix
    May 30, 2011, 02:01:53 AM
    I discovered some small errors on the page "http://www.newlisp.org/index.cgi?page=Differences_to_Other_LISPs">Differences to Other LISPs"[1], a couple of lines before section "Implicit Indexing":



    "readong/translation" should be "reading/translating"

    "This wayte h overhead" should be "This way, the overhead"



    Please fix them.



    [1]: http://www.newlisp.org/index.cgi?page=Differences_to_Other_LISPs">//http://www.newlisp.org/index.cgi?page=Differences_to_Other_LISPs
    #6
    newLISP and the O.S. / Re: Colors in Terminal
    May 29, 2011, 10:19:33 AM
    Thank you very much! I'm using ROXTerm in Gentoo GNU/Linux with Zsh and it works beautifully :-).



    Now I understand.  ASCII's 033 in octal is equivalent to 27 in decimal.  (Somehow) newLISP uses decimal system to describe escape codes instead of octal.
    #7
    newLISP and the O.S. / Colors in Terminal
    May 29, 2011, 08:41:05 AM
    Hi guys,



    I'm developing a console application which makes use of VT-100 compatible terminals.  Usually, to produce text color, I use the escaped phrase `\033$COLOR_CODE`.  For example, to output the world "Hello world" in red, I use


    Code Select

    echo "\033[41mHello world!"


    In newLISP, I tried to do the same thing with


    Code Select

    (println "\\033[41mHello world!")
    (println {\033[41mHello world!})


    But neither works. Does anyone know how to produce colors in terminal with newLISP?
    #8
    newLISP and the O.S. / Re: Memory management in shared library
    May 29, 2011, 05:00:31 AM
    Should these notes be available on newLISP Code Patterns or newLISP Manual and Reference, guys?  I think extra cautions, especially cautions about memory, are never redundant.  Right?
    #9
    newLISP and the O.S. / Re: Memory management in shared library
    May 22, 2011, 12:15:20 AM
    Thank you, Lutz.  That makes sense.  Let me summarize a little bit to see if I really understand it right.  Please correct me if I'm wrong:



    [*] Any allocation performed by foreign functions (functions which are imported from shared libraries) has to be deallocated manually if there's no call to do so.
  • [*] In case of calling foreign functions with passing by reference, memory for variables need to be allocated beforehand by newLISP, and hence, they need not be deallocated manually.
    • [/list]

    Examples:


    [list=1]
  • [*] Taken from newLISP Code Patterns, one needs to free the memory with C's ``free`` function.

  • [*] Using newLISP with gtk-server. No manual deallocation should be taken since gtk-server does that after the call for ``gtk_quit()`` or so.

  • [*] Taken from the reference of ``import`` function in newLISP Manual, which you have just mentioned.
    • [/list]
    #10
    newLISP and the O.S. / Memory management in shared library
    May 21, 2011, 08:36:53 PM
    Hi newLISPers,



    I have a question about memory management when loading shared library.  In C/C++, after finishing using a library, one needs to unload it to ensure that:



    [*] memory is properly deallocated, and
  • [*] the system could do some clean-up, like closing file handlers, ...
    • [/list]

    In newLISP, should/must we use the same method? If yes, then how to do it properly.  Let's take the example in newLISP Code Patterns:



    We have this C program:


    Code Select

    /* compile with:
     *     $ gcc <filename> -fPIC -shared -o <libname>
     * or
     *     $ tcc <filename> -shared -o <libname>
     **/

    #include <string.h>
    #include <stdlib.h>

    typedef struct mystruc
    {
        int number;
        char *ptr;
    } MyStruc;

    MyStruc *foo3(char *ptr, int num)
    {
        MyStruc *astruc;
        astruc = malloc( sizeof( MyStruc ) );
        astruc->ptr = malloc( len( ptr ) + 1 );
        strcpy( astruc->ptr, ptr );
        astruc->number = num;
        return astruc;
    }


    After compiling it to a shared library, we can import ``MyStruc`` to our newLISP program by using:


    Code Select

    (import "mystruc.so" "foo3")
    (setq 'astruc (foo3 "hello world" 123))
    (get-string (get-integer (+ a struc 4))) ;; 4 = sizeof int in C
    (get-integer astruc)


    Do we have to manually deallocate memory allocated to ``astruc``?  According to what I understand, since ``astruc`` is created by newLISP, exists in newLISP environment, newLISP's garbage collector automatically takes care of memory management for us.  Right?
    Pages1