<Regenaxer>
Hmm, I feel it rather confuses even more ;)
<beneroth>
I meant your response to Arie
<beneroth>
explaining the basic misconceptions :)
<Regenaxer>
yes
<Regenaxer>
But it is hard to explain, all the confusion about quotes and (non)evaluating
<Regenaxer>
I'm not even sure what exactly he wanted to do
<beneroth>
I guess he just wanted to assign a variable.
<beneroth>
I found your email spot-on, would have written it the same way.
<Regenaxer>
yeah, but he was content in the end with (de x . '(1 2 3 4))
<Regenaxer>
ok, thanks!
<beneroth>
well it was the first way which worked for him, but he surely hasn't grokked it. You explained the background and alternatives.
<beneroth>
I would guess most people have to play around a bit and fall into the numerous traps before grokking the underlying architecture and concepts :)
<Regenaxer>
He seemed to have some knowledge about Scheme I think
<Regenaxer>
'set!' may be in Scheme, not sure
<beneroth>
Of course some people could get there faster by reading and learning the picolisp internal structures first, but I guess many/most people come there with a more hands-on approach ;-)
<beneroth>
yeah
<Regenaxer>
yes, and most give up quickly :)
<beneroth>
T
<Regenaxer>
understandable
<beneroth>
but that is a widespread problem, not limited to programming I would say. :P
<Regenaxer>
true
<Regenaxer>
Must go, bbl
<Regenaxer>
afp
<beneroth>
cu!
<tankf33der>
beneroth: picolisp shipped with setf function
<rick42>
sup. how ru, beneroth, Regenaxer and tankf33der?
<rick42>
diff between de and def is only to be understood be reading ref
<rick42>
imho
<beneroth>
T. but maybe not on the first reading ;)
<rick42>
hehe
<beneroth>
sup rick42 o/ nice to see you here :)
<rick42>
\o likewise
<beneroth>
tankf33der, oh nice find!
<rick42>
tankf33der's gone deep already
<rick42>
mmans repo. he's still keeping it up? nice.
<beneroth>
it's automatically kept up to date (scrapping Regenaxers download page) afaik
<rick42>
even better!
<beneroth>
common, we're picolispers ;)
<tankf33der>
beneroth: good arie didnt find it
<beneroth>
haha, maybe. maybe it would speed up his confusion and than his understanding. dunno :)
<beneroth>
it has a nice Regenaxer comment at the top :D
<rick42>
:) (just read it)
<rick42>
my favorite part is the let block that contains the expression (eval "P"). very nice example of expert lisp programming (and leveraging dynamic binding)
<beneroth>
yeah I saw the file ages ago, forgot it.
<beneroth>
haha, yeah I have such stuff in my code, too. works well. but its not optimal.
<beneroth>
I'm working on better solutions.
<rick42>
(I'm singing "Don't Fear Dynamic" to the tune of "Don't Fear the Reaper" by BOC lol :)
<beneroth>
I fear I have a lot of ugly picolisp code currently in my software. It's a work in progress, and good enough for my current (and past) applications. One reason why I don't publish my code yet.
<beneroth>
haha :)
<rick42>
you are a perfectionist, like me :)
<beneroth>
T
<beneroth>
One need to be careful with perfectionism. Too often people use it as an excuse to do nothing at all.
<beneroth>
One must not be afraid of failure. Failure is progress.
<beneroth>
Well, knowledge-gaining, to be more accurate.
<beneroth>
Edison "I didn't had 500 failures. I found 500 ways which don't work."
<rick42>
lol
<rick42>
T
<rick42>
on the subject of `setf` in picolisp: aah, might as well use the intrinsic `set`. n00b's have to learn right away that picolisp is a differnet lang from CL, scheme, etc. Don't let the similar syntax fool you -- it's a diff lang with diff assumptions, ideas, etc -- just hunker down and learn it.
<rick42>
it's difficult for opinionated people (like me, I'm the perfect example) to approach a lang like picolisp, after carrying around the ideas of other lisps, as if there were no other ways of doing things (like binding, symbols, etc). To learn picolisp, people like me need to dump the baggage carried from our previous experiences (no matter how important we believe thay are) and give picolisp an honest consideration. I
<rick42>
ly.
<rick42>
think this is haaaaard. It's hard to think about things without the context that you are used to carrying around (because, after all, that context has *helped* you in the past to understand things in an organized way, right?). Well, we don't have to ultimately forget the past (we shouldn't), but learning new things with a truly fresh (not empty) mind is what's need, but I have found this very challenging, personal
<rick42>
bbl
<beneroth>
T
styx has joined #picolisp
<Regenaxer>
ret
<Regenaxer>
Hi rick42! :)
<Regenaxer>
Yeah, 'setf' was meant as a joke ;)
reed has joined #picolisp
<reed>
Hi all. Is there a way to open a file that doesn't exist yet with the "vi" command?
<reed>
If I could do this simply, I could almost completely avoid leaving the pil repl .
<beneroth>
yeah I see your point. Had this thoughts too, at the beginning.
<beneroth>
:)
<beneroth>
afaik.. no. because (vi) does not take a file
<beneroth>
but you can surely make it happen
<beneroth>
maybe (call 'vim "path/to/new/file") and then (load "path/to/new/file") =
<beneroth>
?
<beneroth>
you could put it into a single function
<reed>
hmm, let me try
<reed>
(de vi-open (Filename) (call 'vim Filename)) works well
<reed>
Is there a way to load that function in the repl without modifying my "@lib/lib.l" file?
<reed>
And of course without loading it manually every time
<beneroth>
(load Filename) ?
<beneroth>
then henceforth working with (vi) instead of (vi-open). (vi-open) only to create new functions
<reed>
I mean, to have the "vi-open" function available by default.
<reed>
Is there like a .pil config file?
<beneroth>
there is a .pil directory in your home dir
<beneroth>
containing the repl history (when pil started with + debug flag)
<beneroth>
and a directory tmp, there (tmp) creates files (and deletes them automatically when the process ends normally)
<beneroth>
pil itself is a simple bash script
<beneroth>
you could customize the pil bash script or make your own separate version
<beneroth>
it basically starts the picolisp binary and loads some (usually essential) picolisp standard "libraries"
<reed>
Ahh, that seems reasonable. Thank you!
<beneroth>
glad to help :)
<reed>
So, adding the definition to the "editor" file in the .pil directory worked, and seems a little cleaner than changing the script in /usr/bin
<beneroth>
perfect :D
<Regenaxer>
hi reed, this is possible
<Regenaxer>
At least with Vip which is what I'm using
<reed>
Is there a more standard way than defining a wrapper function in the "editor" file?
<Regenaxer>
If you include "@lib/vip.l" on your command line
<Regenaxer>
no need for a wrapper
<Regenaxer>
Just (vi "myfile")
<Regenaxer>
or (vi 'car) to edit sources as before
<reed>
when I do that on an empty file, I get an error "/usr/lib/x86_64-linux-gnu/libncurses.so: file too short"
<Regenaxer>
ah
<Regenaxer>
yeah, the ncurses problem
<Regenaxer>
I described it in the Vip article, let me check