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

#61
Sorry, I just skimmed over this thread and saw Dragonfly mentioned. Just want to mention that Dragonfly should take care of all the uploading stuff for you, you don't need to write your own. See the documentation for the $FILES:



http://www.rundragonfly.com/dragonfly_api">http://www.rundragonfly.com/dragonfly_api



$FILES is for multipart-form data.



There's also a different method of uploading data, which is basically a POST to the URL with binary data, in which case use $BINARY.
#62
newLISP newS / TextMate bundle for newLISP
July 08, 2010, 01:53:10 PM
I've added my TextMate bundle for newLISP to github:



http://github.com/taoeffect/newLISP.tmbundle">http://github.com/taoeffect/newLISP.tmbundle
#63
Whither newLISP? / Re: Nesting and Booleans
July 06, 2010, 12:55:47 PM
I haven't played with it much and I'm not sure it's a very efficient solution, but you might want to take a look at the 'reader-event' function, which may allow you to implement the | syntax.
#64
Whither newLISP? / Re: Nesting and Booleans
July 04, 2010, 06:43:36 PM
I should elaborate that beyond being non-idiomatic, it would make it difficult to tell whether the code you're seeing is function composition, or a call to a function that's accepting several arguments, which is why it's probably better to be explicit.
#65
Whither newLISP? / Re: Nesting and Booleans
July 04, 2010, 06:14:24 PM
I can't find the original thread where define-smacro was discussed....



Only thing I've been able to find that discusses the hygenic macro issue is here:



http://newlispfanclub.ryon.webfactional.com/forum/viewtopic.php?f=5&t=1080">http://newlispfanclub.ryon.webfactional ... f=5&t=1080">http://newlispfanclub.ryon.webfactional.com/forum/viewtopic.php?f=5&t=1080
#66
Whither newLISP? / Re: Nesting and Booleans
July 04, 2010, 06:06:48 PM
I think it's cool, but I'm not sure this would result in very clear code (for others reading it). People coming to newLISP from other Lisps would be baffled by this. Does the advantage of not having to write an 'if' make it worth it? I'm not sure...



BTW, Clojure has a builtin function called 'comp' (for composition) that is essentially your 'nest' macro. I think explicitly calling nest/comp is the better way of doing it, as that's more "idiomatic".



Some bugs I noticed: new-integer? and bool-if should be macros so that they don't evaluate their arguments (and you might want to use define-smacro, see below), there are missing calls to parameters in the sn/cs functions, and your nest macro is polluting its calling context by not using 'let' to set 'op', rargs, r, and lst.


(define-macro (define-smacro)
    (let (_temp1 (append (fn-macro) (cons (1 (args 0)) (rest $args))) _temp2 (args 0 0))
        (def-new '_temp1 (sym _temp2 _temp2))
)
)
#67
Quote from: "vlad lorenzo"Thank you very much for sharing, I'll check it out.



Up to now my impression is that the approach of xml to name-spaces is provably the most effective one:

Using a URL to define a unique global name-space and a symbol that references it as a prefix to cut down on the verbosity.

e.g.: in the module file:

(context 'example.com/library-name/module-name)

; code...

(context)



in the MAIN file:

; since (context) is the las evaluated expression it can be assigned to a symbol

(define xx (load "/home/vlad/newlisp/example.com/library-name/module-name.lsp"))



I thought of creating a library to add more features, but adding another dependency creates a barrier to sharing code.

i.e.: if every developer has his own unique way of managing name-spaces interoperability tends to suffer.

But I'll check out your library before settling on this.


Based on that I think you'll find it suits your needs. :-)


Quote* creating anonymous contexts to pass around as references without name clashes. (I still haven't looking into FOOP, so there might be a solution there)


That's one of the things Objective newLISP can solve (click the link in my signature).
#68
Quote from: "cormullion"It's cool! Thanks. Some useful by-products from your recent Clojure investigations?!


Yup!



I actually use http://www.taoeffect.com/other/clj.lsp.html">a newLISP script to run Clojure. :-p
#69
newLISP in the real world / Re: SBCL to newLISP
July 03, 2010, 09:27:53 AM
Yes, though the manual does use that convention for some reason, I don't see the point. I see it as adding confusion to my code and giving me one more thing to have to worry about (should I use setf or setq here?). There's no reason to burden yourself with unnecessary complexity.
#70
Oh, and btw, this was made possible by the recent addition of the prefix function. :-)
#71
I just released a little bit of code that makes modularization real simple and safe like in Java. Check it out:



http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3670">http://newlispfanclub.alh.net/forum/vie ... f=2&t=3670">http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3670
#72
I've created a little project that adds Java-like namespaces to newLISP!



You can now do stuff like:


(ns-import 'com.example.*)
(ns-import 'com.example2.Test)

(Test:foo "bar")


In a nutshell, this solves the name clashing issues in newLISP and means newLISP is now much easier to use for large projects.



It's on GitHub and Bitbucket!



http://github.com/taoeffect/namespace-newlisp">http://github.com/taoeffect/namespace-newlisp

http://bitbucket.org/taoeffect/namespace-newlisp">http://bitbucket.org/taoeffect/namespace-newlisp
#73
newLISP in the real world / Re: SBCL to newLISP
July 02, 2010, 11:19:35 AM
Quote from: "m i c h a e l"So it looks like both setq and setf are faster than set. I ran these tests multiple times, and the q and f versions are consistently faster. Lutz, should we be using setq in place of set for the slight speed increase?


I don't think setq should be used at all, there's no reason for it as it's just an alias for setf (which is why you're seeing those results), and included for compatibility with old code.



I originally thought set was faster than setf for multiple assignments, but it seems like I must have made a mistake in those benchmarks, so setf is faster for everything. So, I don't know about you, but for consistency and speed I'm going to use setf for everything (unless I explicitly need to set on a symbol, which happens often enough, in which case there's no choice but to use set).
#74
newLISP newS / Re: Bug in 'process'?
June 30, 2010, 06:11:38 PM
OK thanks, either I forgot about that, or I never knew it to begin with. :-p



Maybe that could be mentioned in the fork/process docs? Seems like something that could trip up a lot of folks..
#75
newLISP newS / Re: Bug in 'process'?
June 30, 2010, 03:59:11 PM
Same problem with 'fork':


> (fork) (sleep 2000) (exit)
19389
2000
[shell]$