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

Pages1
#1
newLISP in the real world / Re: Where is source file of IDE? Is it open-source ?
March 29, 2012, 11:15:54 PM
Good to know. I installed newLISP using the standard Mac OSX installer, and I have the newlisp-edit executable, but I don't seem to have newlisp-edit.lsp anywhere on my file system. Did a `cd / && find . -name newlisp-edit.lsp` just to make sure.



I assume it would normally be tucked away in "/usr/share/newlisp" ?
#2
newLISP in the real world / Re: Where is source file of IDE? Is it open-source ?
March 28, 2012, 04:54:08 AM
For any other newbies out there (like myself), took me a few minutes to figure out where/how to start the IDE.



[*] Download the source tarball and extract
  • [*] Go to the guiserver/ folder

  • [*] Run the following:
    • [/list]

    Code Select

    java -jar guiserver.jar <port> newlisp-edit.lsp


    Obviously replacing <port> with a port number (47011 is a guiserver default).
    #3
    newLISP in the real world / Re: Unix module, Protected symbols
    March 17, 2012, 08:34:44 AM
    Great! Thanks for the fix and the info.
    #4
    newLISP in the real world / Unix module, Protected symbols
    March 16, 2012, 03:44:52 PM
    Using newLISP 10.4.0, Mac OSX Lion.



    At command-line, I start a newLISP REPL with `newlisp`. I get a prompt. I then load the unix module that comes with newLISP like this:


    Code Select

    (load "/usr/share/newlisp/modules/unix.lsp")


    This file does, indeed, exist at that location. When I evalute this, I get the following error:


    Code Select

    ERR: symbol is protected in function define : (setuid id)


    I'm in the MAIN context when trying this. Am I doing something wrong?
    #5
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 16, 2012, 08:48:34 AM
    Yep, understood on how link.lsp works. newLISP is plenty fast; my only goal was to create self-contained and portable utilities to share between identical machines (at my work).
    #6
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 16, 2012, 05:53:31 AM
    I'm glad I'm not going mad, either :-)



    The only reason I tried it was that I was trying out a few new Lisps (Clojure is my primary language) and was interested in platform executable compilation, as Clojure only compiles to Java artifacts that require a bit more setup to be used as scripts.



    Thanks for all the help!
    #7
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 15, 2012, 10:03:22 PM
    Ok, perhaps I lied, this is just too curious. Lutz - are you moving the compiled file from where you build it? Are you putting it somewhere else on your path and using it elsewhere in your file system?



    Upon further inspection, I'm seeing the same behavior cormullion is. I stopped using my `program` fn, just doing a standard compile. I then make it executable and put it in my ~/bin, which is on my path (and `which mgrep` returns that file path).



    If I go into my home directory and do `mgrep "foo" *` I get the following:


    Code Select

    ERR: invalid function : (TeX Live 2011)


    ...because I happen to have a file that has that text in it, parentheses and all.



    On the other hand, if do ~/bin/mgrep, it works as expected, returning results instead of that error.



    Weird, no? I can confirm this happens for me on Mac OSX Lion and Ubuntu 11.10. Thoughts?
    #8
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 15, 2012, 09:49:44 PM
    Then I officially ask you to stop helping me on this front :-)



    I'm really impressed by the efforts you've taken to reproduce my problem, and I sincerely appreciate the help. I will continue to tinker with the compilation.



    On a slightly unrelated note - is there a syntax for the default globbing support for scripts (which I'm using in mgrep) that will recursively descend into an arbitrary number of directories? Something like the Ruby **/** type syntax?
    #9
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 15, 2012, 06:19:09 PM
    My problem still persists. Lutz - Do you do anything different than what's described in the manual for compilation? Do you have any info on the other behaviors I mentioned above? (that running the compiled version over Lisp code files gave complaints about undefined functions in the code I was read-lining in; and the issue of my compiled version dropping down to a REPL sometimes when it fails?)



    In case your last questions were also directed to me, I am successfully able to put `mgrep` on my path, in which case a `which mgrep` points to my compiled newLISP script.
    #10
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 15, 2012, 08:22:22 AM
    Thanks for addressing this, Lutz.


    Quote from: "Lutz"I cannot repeat that error, no matter if using the 32-bit or 64-bit of newLISP. Can you give exact instructions, how the the link was made and the resulting linked script is used? I am also on OSX Lion.


    Here are the directories I'm working with:


    Code Select

    ~/dev/newlisp/utils/
    ~/dev/newlisp/utils/build/


    The `utils` folder contains my source file, `mgrep.lisp`. The `build` folder contains my newLISP executable and the `link.lsp` file. When I'm ready to build a self-contained executable from my source file, I copy it into the `build` folder so that the newLISP executable, the `link.lsp` file, and my source file are in the same directory.



    I wrote one extra function into my `link.lsp` file (https://gist.github.com/2044763">code here) so I can just write:


    Code Select
    (program "mgrep.lisp")

    ...and it evaluates as:


    Code Select
    (link "newlisp" "mgrep" "mgrep.lisp")

    So when I run `newlisp link.lsp` at the command-line and then run my `program` function, the output is:


    Code Select

    original newlisp executable:newlisp
    new executable:mgrep
    source:mgrep.lisp
    true


    Quote from: "Lutz"There should be no space in here "#! /usr/bin/newlisp", instead "#!/usr/bin/newlisp".

    Then on UNIX systems, like Mac OSX, you can just execute mgrep by itself after making it executable with "chmod 755 mgrep", no linking required.


    Noted, I'll fix the space. It runs fine as a script regardless, which is why I have this question. I want to make executables so I can share my utilities with other folks without them having to install newLISP.


    Quote from: "Lutz"link.lsp doesn't compile anything, it just takes the source script, encrypts it and appends it to the end of a newLISP executable. When linking, make sure you have a newLISP executable and the source in the current directory. When instead using pathnames to point to different locations, make sure you don't point to linked versions of files. Like with a raw script, you have to make it executable.


    Understood. I'm pretty sure I hit all your points in my above process, and as I mentioned, it works under certain circumstances. Thanks again for the help.
    #11
    newLISP in the real world / Re: Different Behavior, Script vs. Compiled/Linked
    March 14, 2012, 10:23:16 PM
    Forgot to include my computer specs:



    [*] newlisp --version => "newLISP v.10.4.0 on OSX IPv4/6 UTF-8"
  • [*] Mac OSX Lion
    • [/list]
    #12
    newLISP in the real world / Different Behavior, Script vs. Compiled/Linked
    March 14, 2012, 10:21:38 PM
    First, a big thanks to Lutz and the community for creating newLISP. I'm new to newLISP.



    I've written a simple grep-like script using newLISP. The code is here:



    https://gist.github.com/2041991">//https://gist.github.com/2041991



    Used like
    Code Select
    mgrep "foo||bar" *.txt

    As a script, this code works as expected; it reads files in line-by-line, printing only those lines that match both "foo" and "bar". However, when I compile and link this (so it's all self-contained), I get strange behavior.



    Various things happen. Sometimes it works as expected; sometimes it drops down to a newLISP REPL instead of printing results; sometimes it complains that Lisp code that I'm read-lining through has undefined functions in it (!).



    Can anyone shed light on any one of these issues? Why such a difference between a "script" version and a compiled version?
    Pages1