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

Pages1 2
#1
newLISP in the real world / Amazon Module
November 16, 2012, 03:17:48 PM
Has anyone extended the amazon.lsp module to include dynamo, rds, or beanstalk?



Thanks,

John
#2
newLISP newS / Re: Manual Notes 10.2.1
April 08, 2010, 11:33:53 AM
The manual entry for "sync" should not precede "sym".  It should follow the entry for "symbols".



John
#3
Whither newLISP? /
October 03, 2009, 09:57:33 PM
I can reproduce the errors I'm getting with a small script.  The problem is that a lone "[/text]" loads fine when the entire string is less than 2048 characters but causes 2 different errors for lengths exceeding 2048.



In short, if I save the symbol that evaluates to a long string (> 2048 chars) containing "[/text]" and then reload that file newlisp will generate an error.



The script demonstrating this follows.





newLISP v.10.1.1 on OSX IPv4 UTF-8, execute 'newlisp -h' for more info.



> (silent (set 'p (string (dup "p" 2040) "[/text]")))

> (silent (set 'q (string (dup "q" 2041) "[/text]")))

> (save "p.lsp" 'p)

true

> (save "q.lsp" 'q)

true

> (load "p.lsp")

"pppppp <REMOVED> ppppppppppppppppppppppppppppppp[/text]"

> (load q.lsp")

ERR: string token too long : ")"

> (silent (set 'r (string (dup "r" 10000) "[/text]")))

> (save "r.lsp" 'r)

true

> (load "r.lsp")

ERR: symbol expected in function set : [/text]

>
#4
Whither newLISP? / How Saving Works
October 03, 2009, 09:10:00 PM
I've created a script that generates a large data structure and then writes it out as follows:



...create data...

(save "data.lsp" 'data)

(exit)



When I load data.lsp in a separate newlisp session, however, I get a error and newlisp exits.



This isn't a memory limitation.  Although I think a long text string contained in some element of data is generating the error, data itself isn't very large.



Are there any limitations on saving newlisp symbols to a file and reloading them?  It seems unlikely that there is some issue with save, but right now that's all I have to go on.



John
#5
newLISP in the real world /
October 21, 2008, 03:38:55 PM
Much as I would welcome new sets of useful libraries I think attention must also be paid to the framework in which they are loaded and simple ways for new users to create an use libraries within this framework.



I've been using newLISP for several years now and there is no doubt it is the first language I think of using and the one I develop in first even when I must produce code in some other language.  But the one key feature that draws me to Perl or Python (among others) is the ability to load modules in systematic, conventional ways.



I agree it is unwise to break existing code (on the other hand, sometimes we receive a large benefit in return, as in the case of changing "unless").  What I am suggesting is a package loading mechanism that does not require knowledge of the /usr/share/newlisp directory itself.  It would be aware of the modules shipped with newLISP and would protect their respective contexts.  My interest in a convention for the names above is to enable simple inclusion of new modules with a naming mechanism that doesn't overlap.



I'm sure I haven't thought of all the contingencies here.  From reading the replies to my original post it seems that consistency isn't so much what I'm looking for.  It's more a statement about the convention for naming those modules and contexts that are included by default, and a proposal to simplify loading both these and user generated modules.



John
#6
newLISP in the real world / Module Contexts
October 21, 2008, 12:29:49 AM
newLISP installs with several modules that one can load separately, including cgi.lsp and crypto.lsp.  See /usr/share/newlisp/modules



I'm interested in using these but I want to be sure I avoid potential name clashes.  Some of the contexts created by the individual modules are lower case and others are upper case (which I take to be the traditional convention for context names).



Is there another convention at work here that I'm unaware of?



Thanks,



John
#7
newLISP in the real world /
October 07, 2008, 01:09:33 PM
Lutz,



Thank for your quick reply.



The ambiguity you mention is a serious one and it would have to be resolved somehow.  Perhaps an additional argument to flag one or the other form.  However, it's even more serious when you consider the list might contain both the sublist and the element.



I'm a little bit new to match but it looks interesting.  To extend your example to one using variables, would I have to push a * onto the end of the list variable?



Thanks,



John
#8
newLISP in the real world / starts-with question
October 07, 2008, 10:25:05 AM
starts-with now takes a list and expression as an argument.  For example:



> (starts-with '((1 2) 3 4) '(1 2))  -->  true



What is the logic for limiting this to just the first element?  Doing so makes this little more than syntactic sugar for



> (= (first '((1 2) 3 4)) '(1 2))  --> true



Could this instead be a sublist match rather than membership so that the following would be true?



(starts-with '((1 2) 3 4) '((1 2) 3))



This one is more difficult to implement, but it can be done as follows:



> (set 'arg1 '((1 2) 3 4))

((1 2) 3 4)

> (set 'arg2 '((1 2) 3))

((1 2) 3)

> (= (0 (length arg2) arg1) arg2)

true

>



This could pose problems if implicit slicing out of bounds generates an error (it doesn't currently, but then neither did implicit indexing out of bounds not too long ago).  Just imagine arg2 is longer than arg1.  Also, things get more complicated with the corresponding ends-with version.

 

Broadly speaking, I am advocating support for sublist evaluations as well as membership/containment evaluations.  This can get tricky when the potential sublist is situated below the first level of the list, but ultimately the judgment would be the same as for membership of an element.



Thanks,



John
#9
newLISP in the real world / Parse Question
September 04, 2008, 11:27:42 AM
According to the manual when no str-break token is included in parse the function uses "newLISP's internal parsing rules".  Are these described somewhere in the manual?



I've noticed some odd behavior with parse



> (parse {"john d"} " ")

(""john" "d"")

> (parse {"john d"})

("john d")

> (parse {john d})

("john" "d")

>



I was assuming a the break token was a space, but the last two examples are different.



I came across this when I tried to parse a single " without including an explicit str-break.



> (parse {"} " ")

(""")

> (parse {"})



ERR: string token too long in function parse : ""

>



John
#10
newLISP in the real world / Regex Question
August 22, 2008, 11:44:53 AM
How does newLISP control the value of system variables in regex?  It seems they are set only on non-nil regex results.



> (regex ".*([aeiou]{2}).*" "Seattle")

("Seattle" 0 7 "ea" 1 2)

> $1

"ea"

> (regex ".*([aeiou]{2}).*" "San Francisco")

nil

> $1

"ea"

>



If this is the intended behavior it should probably be documented.  I would argue that nil is a result and that $1 should return nil when the regex evaluates to nil.  This was an issue recently because I was checking for $1 to be nil rather than the regex expression itself.  The regex evaluated to nil but $1 retained a previous value.



John

[/i]
#11
newLISP in the real world /
August 08, 2008, 10:45:12 AM
I should clarify.



The purpose of my shell script example was to argue that an inconsistency exists in the way newlisp evaluates command line arguments.  I believed it treated my shell script differently.  Lutz demonstrated that was not the case.  Hence no inconsistency.  Thank you for that clarification.



I don't normally run shell scripts via newLISP.  :-)



Lutz asks, "Why would anybody invoke newLISP interactively with the first argument not being a script?"



This is the core of what I want to do.  Suppose I just want to send some strings as arguments into newLISP from the command line.  The most natural way to do that is as follows:



% newlisp <str1> <str2> <str3>



Now they can be referenced via main-args.  Does it really make sense to automatically evaluate them if they happen to be the names of files in the same directory?  I say no.  Lutz says yes.



It is not merely when running newLISP by itself, however.  In my original example I had a program that took arguments.



Thanks,



John
#12
newLISP in the real world / Command Line Behavior
August 07, 2008, 04:11:57 PM
According to the manual, newLISP will attempt to load files listed on the command line.  Is there any way to control this behavior with a flag?  I would like to prevent it.



I am sure it is often helpful to have this convenience, but when you want to pass a string as an argument that happens to be the name of a file in the directory it can pose a problem.



For example:



--

Moonrise:Documents jd$

Moonrise:Documents jd$ newlisp list_categories.php



ERR: invalid function : (Admin)

Moonrise:Documents jd$

--



This file is not executable from the command line.  Even if one sets the permissions to allow it to be executable it will generate errors.



The other issue here is that this command line behavior is inconsistent.  Consider this file:

--

Moonrise:Documents jd$ cat john

#!/bin/sh

echo "johnjohnjohn"



Moonrise:Documents jd$

--



Simple enough.  Echo the string to the terminal.  This executable file name is treated as a string by newLISP but not executed.



--

Moonrise:Documents jd$ newlisp "john"

newLISP v.9.4.3 on OSX IPv4 UTF-8, execute 'newlisp -h' for more info.



> (main-args)

("newlisp" "john")

>

--



It seems to me that what newLISP considers "a file on the command line" should depend more on a flag setting or on the format of the argument (e.g. "file://..." or something similar) than the contingent contents of the directory.



Thanks,



John[/i]
#13
newLISP newS /
April 29, 2008, 01:52:06 PM
I mistyped in my last reply



Replace <key> with <key|keylist>



John
#14
newLISP newS /
April 29, 2008, 01:50:31 PM
One option would be to treat them all the same



(<command> <key> <list> [<options>])



assoc simply copies out of string, pop-assoc removes from the string, and lookup works just like assoc except doesn't return the <key>.



Roughly translated, do <command> with this <key> on <list>



Lookup could even be handled as an option to assoc.



More generally, all the commands that do something with key-value pair in a list -- e.g. extract it, copy it, set it, or copy the value only -- should have a similar syntax.



John
#15
newLISP newS / pop-assoc, assoc, and lookup
April 29, 2008, 10:05:23 AM
With the introduction in 9.3 of pop-assoc and modifications to assoc, I was wondering why they don't have the same syntax.  Why not allow a form of pop-assoc that allows one to pop based on on key, like the first syntax of assoc?



What I'm proposing is this.



(pop-assoc (<list> <key>)) be equivalent to (pop-assoc <key> <list>)



This is how assoc works now.  A single key can be done in a special case.



Also, why not extend this behavior to lookup as well, i.e. implement lookup so that it is again parallel to assoc?



John
Pages1 2