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
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).
#62
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
#63
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.
#64
Oh, and btw, this was made possible by the recent addition of the prefix function. :-)
#65
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
#66
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
#67
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).
#68
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..
#69
newLISP newS / Re: Bug in 'process'?
June 30, 2010, 03:59:11 PM
Same problem with 'fork':


> (fork) (sleep 2000) (exit)
19389
2000
[shell]$
#70
newLISP newS / Bug in 'process'?
June 30, 2010, 03:50:31 PM
v.10.2.9


> (begin (process "ls") (sleep 2000) (println "hi"))
hi
"hi"


Or another version:


> ((fn () (sleep 2000) (println "foo")) (process "ls"))
foo
"foo"


That happens instantly. There's no delay despite the (sleep 2000) call. Shouldn't there be a delay?
#71
newLISP in the real world / Re: SBCL to newLISP
June 30, 2010, 12:17:14 PM
Quote from: "Tim Johnson"The idea of using one call to set

with multiple symbol/value pairs

versus

multiple calls to set

with just one symbol/value pair for each call

appeals to my aversion to redundancy.

but michael makes a compelling case in the test code that he posted.


I don't understand, why "but"? His test code shows it's better to use one call.
#72
newLISP in the real world / Re: SBCL to newLISP
June 30, 2010, 10:49:16 AM
Regarding the set thing... I've actually done the same benchmarks, and they've affected how I decide to use set or setf.



Basically, I've found that setf is faster for situations where only 1 variable needs to be set, but if you're setting multiple things in a row, set is faster (if called once for all of them).



It's a really insignificant difference on its own, but I figure if I make that a convention the times will eventually add up to something meaningful since set is called so much. newlisp makes it easy to microbenchmark, and so you can adjust your coding style to always use the faster version, and eventually I figure the entire program benefits from the lots-of-minor-performance-increases.
#73
I'd have to look at your setup to be able to figure out what's going wrong, I can't just guess.



To figure this out, the files you need to look at are config.lsp and dragonfly.lsp.
#74
Check your DRAGONFLY_ROOT constant, make sure it's correctly set. In the standard config.lsp it's set to this:


; docroot (also site root, usually doesn't need modification)
(constant (global 'DOCUMENT_ROOT) (env "DOCUMENT_ROOT"))
; dragonfly root
(constant (global 'DRAGONFLY_ROOT) (string DOCUMENT_ROOT "/dragonfly-framework"))


So you see it's based on DOCUMENT_ROOT being set properly in the environment. It normally is if you're using apache or the newlisp server.
#75
Normally large amounts of data is stored in some sort of a database, not loaded all at once. Dragonfly has excellent support for sqlite3 (see the docs for DF.DB). You can also use something like memcache.