cmatei has quit [Read error: Connection reset by peer]
cmatei has joined #lisp
Kaisyu has joined #lisp
Mutex7 has quit [Quit: Leaving]
vtomole has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 240 seconds]
securityranch has joined #lisp
krwq has joined #lisp
comborico1611 has quit [Quit: Konversation terminated!]
Oladon has joined #lisp
nowhereman_ has quit [Ping timeout: 240 seconds]
smurfrobot has joined #lisp
nowhereman_ has joined #lisp
froggey has quit [Ping timeout: 240 seconds]
smurfrobot has quit [Ping timeout: 256 seconds]
Arcaelyx has quit [Ping timeout: 265 seconds]
fikka has joined #lisp
nowhereman_ has quit [Ping timeout: 256 seconds]
nowhereman_ has joined #lisp
froggey has joined #lisp
dingaling has quit [Ping timeout: 256 seconds]
froggey has quit [Ping timeout: 268 seconds]
dandruff has joined #lisp
<dandruff>
Would the Lisp Machine operating systems have been more portable and able to compete with Unix if they had been built around a Lisp that compiled to VM bytecode like Smalltalk?
froggey has joined #lisp
edgar-rft has joined #lisp
sysfault has quit [Remote host closed the connection]
sysfault has joined #lisp
milanj_ has joined #lisp
warweasle has joined #lisp
smurfrobot has joined #lisp
<caffe>
dandruff: no
<caffe>
the lisp machine processors don't actually understand lisp natively, it worked more in the sort of fashion you're describing
<krwq>
has anyone tried implementing lisp in brainfuck?
<aeth>
dandruff: The thing that killed Lisp Machines was, afaik, performance. The much cheaper commodity hardware eventually beat specialized hardware in Lisp performance.
<aeth>
krwq: Well, I tried implementing it. I decided it wasn't worth my time to continue along that path because of how hard it is, even compared to directly writing in assembly. It looks like dandruff's link takes a much easier approach. Modify an existing C compiler, and then simply write a Lisp interpreter.
<aeth>
It was very hard. Strings that aren't NUL-terminated (it's trivial when they are) probably would take a week to write. I never finished that part.
smurfrobot has joined #lisp
EvW has quit [Ping timeout: 256 seconds]
<dandruff>
caffe: right, I remember hearing that they were stack machines hardware support for bignums and GC. I can't find much on them, though. I haven't even been able to find if they used a monolithic kernel or something else entirely. I've been thinking about writing a Forth implementation in assembly with their features as a compilation target for Lisp Machine Lisp and looking for the source code.
<dandruff>
stack machines with hardware support*
smurfrobot has quit [Ping timeout: 248 seconds]
terpri has joined #lisp
damke has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
<caffe>
why not just write a ZetaLisp implementation for amd64?
<caffe>
(or a clone of it)
vtomole has joined #lisp
<stacksmith>
I've spent a lot of time exploring ideas like that (and a few decades of writing Forth-like system for almost every imaginable platform)... It's one of those things like trying to build an interstellar spaceship... A couple of decades of technology will make yours obsolete every time.
jealousmonk has joined #lisp
<stacksmith>
Stack machines are dead - register architectures beat them every time. It almost made sense a couple of decades ago to make super-simple super-fast Forth machines, but a decent compiler on a mobile phone can outstrip them for an general purpose tasks.
<dandruff>
caffe: Isn't the spec similar to Common Lisp's? Yikes. Anyone can implement Scheme in a day at most; SBCL couldn't even have been built from the ground up.
d4ryus1 has joined #lisp
securityranch has left #lisp [#lisp]
<dandruff>
stacksmith: so that means that it would be impossible to make a reasonably performant system where a stack machine on an FPGA handles the compiled OS language and communicates with a normal CPU?
<stacksmith>
A couple of orders of magnitude in performance if you use an FPGA.
<stacksmith>
Just clock speed mind you.
<caffe>
dandruff: i'm not sure i'd start from the ground up... more likely taking something like SBCL or GCL and building down
<stacksmith>
I've spent a lot of time trying and it's fun.
* caffe
is currently working on such a project
d4ryus has quit [Ping timeout: 256 seconds]
<stacksmith>
Chuck more has some gigahertz async stack machines, like a hundred of them, but they are so small that they are useless.
<dandruff>
asynchronous stack machines?
<stacksmith>
Yup. Check out Green Arrays. There is no clock, they run as fast as possible. Generally stack machines have a couple of dozen instructions, and his processors do them all simultaneously while the decoder is figuring out the opcode. Then the one you want gets the results latched.
<dandruff>
thanks, I'll take a look
<stacksmith>
But, Green Arrays is a couple of hundred async cpus with something like 256 bytes of ram each. Just loading code into them makes me want to go take a bath.
<pjb>
dandruff: clisp is compiled to a VM byte code. Do you think clisp competes with linux?
<caffe>
if you really want to 'compete' with linux... the best way is to not compete with it at all
<caffe>
just adopt it and build on it
<pjb>
Or write an OS in lisp, and make linux irrelevant, like Android.
<caffe>
so maybe something like a Kernel Lisp Machine?
<caffe>
as a loadable module
<pjb>
done.
<caffe>
pjb: yep
<pjb>
caffe: well, not for CL, but for scheme. How many times did you use the scheke linux loadable module?
<pjb>
See how useful that is.
<caffe>
never. wasn't aware it existed. don't do much with scheme, either
<caffe>
i have too strong a strong preference for CL
<caffe>
too strong a preference*
<dandruff>
If it's all embarrassingly parallel and they're an intermediary between an OS and the *real* hardware (some AMD or Intel chip), would the system still take a huge hit? pjb: Java is competitive with C, isn't it? Also, Android uses Linux IIRC. What I'd really like is something like Emacs all the way down with orthogonal persistence; I don't want to displace Linux.
<aeth>
There are two ways to do a LispOS. Bottom up and top down. By bottom up I mean start with the kernel and build your way up. By top down I mean start with user space applications and eventually replace intermediate components with Lisp equivalents.
<caffe>
dandruff: it might take a negligible hit
<aeth>
Starting with LispM hardware isn't even really a viable option for a LispOS at the moment.
<caffe>
but honestly, i'd rather let linux kernel devs work for me than try to work against them myself
<aeth>
The problem with the kernel isn't the kernel itself, it's the drivers.
<aeth>
There are basically two OSes that support lots of hardware. Windows and Linux.
<aeth>
Good luck.
<caffe>
the android-like approach would yield better results, and be easier to maintain and keep 'not obsolete' for a longer time
<aeth>
Yes, Android wisely sidesteps the driver issue that way, even though it's essentially JavaOS
<caffe>
most drivers would be developed for you upstream
<caffe>
i would hate to try to build the whole enchilada myself...
<caffe>
you'd die before your first release
<caffe>
with a 20 foot beard
fikka has quit [Ping timeout: 260 seconds]
<caffe>
and a half-done project, at best
epony has quit [Remote host closed the connection]
fikka has joined #lisp
<caffe>
riding on linux/GNU's back would allow your work to be finished before it becomes obsolete
<caffe>
and less ickly boilerplate for you
<aeth>
no, not GNU/Linux, Linux
<aeth>
You don't need GNU software
<aeth>
(well, except to build the kernel, but not every machine needs to build kernels)
<caffe>
you might not NEED it, but it would still be useful
<caffe>
i'd rather use GNU tls than write my own implementation
<pjb>
dandruff: it's mostly irrelevant if Android uses Linux. Android application developers mostly don't touch unix. The would have to code in C to even know it's there…
<aeth>
The really hard to replace things would probably be xorg and systemd
<pjb>
Basically, Linux is the device driver set of Android.
<caffe>
there's still GNU components in android
<aeth>
but it certainly shouldn't be called GNU/Linux
<caffe>
aeth: i wasn't trying to start that battle
<pierpa>
one could start from minix instead
<aeth>
caffe: Well, what I mean is, it doesn't matter whether you call Debian Linux distro or a GNU/Linux distro. But Android or a LispOS that took a similar use-the-Linux-kernel approach isn't "GNU/Linux" because the GNU would be marginalized if present at all
<caffe>
just nothing that both the kernel, and GNU utilities had very useful pieces you could utilize so you don't have to keep reinventing the wheel for every little thing, and focus more n developing the lisp environment
<caffe>
noting*
<aeth>
Well, you'd probably have to take the GNU approach of incremental replacement. That's how GNU gradually replaced Unix utilities afaik.
<caffe>
i'm aware, but i didn't say "Linux/GNU" to trigger anyone or start that old rant here
<aeth>
There'd be advantages to having a sh written in CL, but no need to prioritize writing one when bash, zsh, ksh, tcsh, etc., exist.
<pjb>
Yes, you could start rewriting the GNU tools in Lisp. ls, cp, cat, etc… When you can rename the system from GNU/Linux to Lisp/Linux, you just replace Linux by Mezzano.
<aeth>
pjb: Mezzano will get really interesting when (1) rich graphical CL applications move from cl-opengl to cl-vulkan and (2) Mezzano implements its own Vulkan backend (considerably easier to support than OpenGL)
<dandruff>
caffe: if the Linux kernel drivers all use POSIX syscalls, could one build a common API to convert their output to something readable by a Lisp OS? People could then rewrite them natively as the years go on.
<caffe>
i don't know. honestly, i think the pursuit of a Lisp OS is a dead end
dingaling has joined #lisp
<caffe>
mixed-language systems aren't something i see us ever pulling away from
<aeth>
caffe: I suspect it will have similar issues as Lisp machines. Lisp machines went away because they were worse performance than commodity hardware. If running SBCL on the Linux kernel beats your LispOS in performance, it probably won't get many users, either.
python47` has joined #lisp
<caffe>
a Lisp OS would have 'purity' going for it, and little else. and probably wouldn't survive long, if even seeing the light of day
<dandruff>
I'd think so too, but I've heard some things from people who I know are working on neuromorphic chips. I doubt they're going to totally replace von Neumann architectures, but between them and quantum computers and other new hardware, I think we're about to take a turn for the weird
<aeth>
On the other hand, if a LispOS can have good performance, it could make sense as a lightweight OS for running Lisp applications in the cloud. Drivers wouldn't matter that much, either, if it's running in a VM.
<aeth>
Sure, no end users would use it, but at least it would have uses.
Oladon has quit [Quit: Leaving.]
<dandruff>
a functional language is truly platform-independent because lambda calculus abstractions are so powerful and have a common, tiny core. C's going to die along with Go and Java; if Lisp doesn't make a comeback, then Haskell will eat its lunch. Then we'll have to deal with templates and subverting the type system to get stuff done for who-knows-how-long.
<aeth>
dandruff: imo Haskell won't win because (1) it makes it hard to write multiparadigm code and (2) it's lazy
<caffe>
haskell is hard to read
<dandruff>
We're probably going to have computers with many processors with fundamentally different ways of computation, all with different roles and jerry-rigged integration. If something "just works", people will deal with it. I don't know that much about Haskell, but those monads look scary.
smurfrobot has joined #lisp
<aeth>
dandruff: We'll have a CPU, a GPU, a TPU, a QPU, etc.
<dandruff>
we're gonna have PUs we can't even imagine!
<aeth>
Maybe an FPGA, too. Especially if they can rebrand it to *PU. Perhaps "R" for "Reprogrammable"?
<Xach>
The only on-topic connection I can tenuously make is Luke Gorrie's work on dedicated hardware running niche language binaries in userspace to do some amazing stuff. And only loosely relevant because he did some common lisp stuff, like an experimental CL tcp stack.
<Xach>
(he did the CL stuff long long ago)
<dandruff>
Xach: links? Sounds cool.
<Xach>
snabb switch is his work. it's based on luajit. he forked it into raptorjit. he also started teclo networks to do ip acceleration of mobile networks. both not in CL though, which is the topic of this channel.
sjl has joined #lisp
smurfrobot has quit [Ping timeout: 252 seconds]
<dandruff>
thanks
dandruff has quit [Quit: Page closed]
krwq has quit [Remote host closed the connection]
zooey has quit [Remote host closed the connection]
zooey has joined #lisp
ja-barr has quit [Ping timeout: 252 seconds]
cheers has left #lisp ["WeeChat 1.4"]
Oladon has joined #lisp
ja-barr has joined #lisp
warweasle has quit [Quit: Leaving]
Pixel_Outlaw has quit [Quit: Leaving]
python47` has quit [Ping timeout: 276 seconds]
fikka has quit [Ping timeout: 256 seconds]
Elite-Epochs has quit [Quit: ZNC 1.7.x-git-876-42939c9 - https://znc.in]
Elite-Epochs has joined #lisp
asarch has joined #lisp
deng_cn has quit [Read error: Connection reset by peer]
deng_cn has joined #lisp
Kristof_HT has joined #lisp
yangby has joined #lisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #lisp
LocaMocha is now known as Sauvin
Selwyn has quit [Ping timeout: 276 seconds]
ja-barr has quit [Ping timeout: 252 seconds]
ja-barr has joined #lisp
edgar-rft has quit [Quit: Don't Cry for Me, Argentina...]
gabiruh has quit [Ping timeout: 255 seconds]
guaqua_ has quit [Ping timeout: 252 seconds]
guaqua has joined #lisp
smurfrobot has joined #lisp
gabiruh has joined #lisp
<fouric>
stacksmith: any feel for how much effort would be required to make a stack machine perform on par with a register machine?
<fouric>
I mean, yes, a mid-tier ARM CPU can destroy a stack machine that you build on an FPGA in your free time, but that's because one had a few orders of magnitude more time put into it than the other.
smurfrobot has quit [Ping timeout: 256 seconds]
arescorpio has quit [Quit: Leaving.]
<fouric>
Do you have informed guesses (you said you've been playing around with stack architectures for a bit) on if one or the other is easier to make better given equal effort?
<pierpa>
it is not possible to build a stack machine which performs on par with a register machine, unless the register is handicaped in some ways, or there are some constraints you are not mentioning
<pierpa>
such as a minimalistic compiler, for example
<fouric>
No constraints - just curiosity.
<fouric>
Why is it impossible?
<pierpa>
becasue the stack acts as a bottleneck which the register machine does not have
<fouric>
Got it.
<Bike>
stack means memory. memory is slow.
<fouric>
Erm, what if you implemented the stack using register-level SRAM?
<pierpa>
consider for example the JVM
<fouric>
("register-level" being "small and very close to the CPU cores")
<pierpa>
JVM is a stack architecture. To get good performance, most of the work is the destackification of the code :)
damke has quit [Ping timeout: 264 seconds]
<Bike>
registers aren't sram. but whatever. you mean using the register file as stack space.
<fouric>
Yes, that. Sorry.
<Bike>
having more registers makes them harder to use, since it takes more bits to address them.
<Bike>
and if there aren't enough you have a stack too small to be very useful.
<Bike>
kind of a "why don't they just make the whole plane out of the blackbox material" question there
<Xach>
heh
<fouric>
But registers are limited in quantity, too - and have to be swapped out to RAM when you make function calls, right?
damke has joined #lisp
<Bike>
sometimes, some of them.
<Bike>
but stack machines would not be any less hit by such considerations
<pierpa>
the need to spill to memory is not different. The possible parallelism in the instruction stream is different.
Misha_B has quit [Ping timeout: 256 seconds]
<fouric>
I can sort of see that. Something something it's harder to design a CPU that reorders operations on a stack than one that does so with named registers?
<pierpa>
I think this is the current consensus, yes
<fouric>
I think I understand. Thanks for the explanations!
<pierpa>
OTOH, stack architectures are kind of cute
<pierpa>
in a minimalistic sense of cute
<Bike>
unlike really used modern architectures, which are the exact opposite of cute
<pierpa>
yep
<pierpa>
RISC-V is not bad thought. Hope we will have soon workable boards...
<pierpa>
*though
schoppenhauer has quit [Ping timeout: 240 seconds]
<beach>
Good morning everyone!
<Bike>
goodmorning
schoppenhauer has joined #lisp
gabiruh has quit [Ping timeout: 248 seconds]
<stacksmith>
Good morning.
gabiruh has joined #lisp
Bike has quit [Quit: Lost terminal]
cromachina_ has quit [Quit: Leaving]
test1600 has joined #lisp
cromachina has joined #lisp
deng_cn has quit [Read error: Connection reset by peer]
attila_lendvai has quit [Ping timeout: 256 seconds]
<aeth>
It would probably be more productive to make a RISC-V CPU in a CL DSL (that compiles to Verilog or VHDL?) than to make a specialized, Lisp-oriented CPU.
deng_cn has joined #lisp
* fouric
shudders at the thought of making anything that emits Verilog as a backend
<vtomole>
Why? The CPUs we use now run Lisp just fine.
<pierpa>
btw, a RISC-V working group about extensions useful for dynamic languages has just been created.
<pierpa>
well, it would be nice to have BOTH safe and fast code at thesame time. Just saying...
ja-barr has joined #lisp
<beach>
I think that is possible with existing CPUs, unless of course you deliberately make the compiler emit unsafe code. And I think that any attempt to make specialized hardware will be so much slower than existing CPUs that the performance hit will be much worse than the additional cost of just emitting safe code on existing CPUs.
gabiruh has quit [Ping timeout: 240 seconds]
<beach>
Sure, you can dream of Intel or AMD making a processor that is as fast as existing ones but specialized for Lisp. But that aint gonna happen.
smurfrobot has joined #lisp
<pierpa>
specialized instructions could give array bounds checking with no performance penalty, for example
<pierpa>
it IS happening for RISC-V though
<bjorkintosh>
pierpa, how would you know you're working in lisp if there are no performance penalties??
<beach>
Yes, but array accesses are typically in a loop, so you can check the bounds once.
<bjorkintosh>
it's part of its charm!
<pierpa>
:)
<beach>
In my opinion, it is much better to focus on so called "aggressive "compiler optimizations than to dream of specialized processors.
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<beach>
pierpa: If only a single array reference is executed, then it is very likely that other stuff like function calls and such will dominate performance. So it is best to focus on array references in loops. And then we can often get rid of the bounds checking.
<pierpa>
it was just an example...
gabiruh has joined #lisp
dingaling has left #lisp [#lisp]
<beach>
OK, here is another "mistake". SBCL treats NIL specially, so that CAR and CDR is a valid operation on NIL without any special test for NIL. But CAR and CDR are important for performance mostly in a loop, traversing the list. And then, the compiler could emit code to check for CONSP first, which will almost always be true.
<beach>
Unfortunately, SBCL now needs two tests in each iteration, one for LISTP and one for NIL. I think it is way more productive to think about how we organize our Common Lisp systems and what we want the compiler to do.
<beach>
In fact, for the entire SICL project, I am totally against unsafe code. So I try very hard to make the code both safe and fast.
smurfrobot has quit [Ping timeout: 256 seconds]
<pierpa>
I'll have to study SICL
<beach>
I have thus invented fast generic-function dispatch, and I have a way of compiling the sequence functions that make them very fast as well.
<beach>
That kind of work is way more productive than dreaming of influencing major hardware manufacturers.
<pierpa>
I read your paper about this
<pierpa>
(the sequence one)
<beach>
Great! Thanks.
<pierpa>
to you!
<pierpa>
but the hardware manufacturers *are* thinking about these issues. OK, they are thinking about Java, but probably it will benefit us as a side effect.
<beach>
Another thing is multi-threading. I try to design the system so that locks can be avoided in favor of faster techniques such as CAS. If you design your system without thinking of multi-threading, it won't matter what specialized processor it runs on; it will still be slow.
<pierpa>
yes, true
<bjorkintosh>
pierpa, why so worried about the hardware? is it that big a problem these days?
<bjorkintosh>
8 cores too few?
<pierpa>
yes, they are never enough
<bjorkintosh>
hmm. have you looked into fpgas then?
<bjorkintosh>
perhaps you might find a handy, custom solution there.
<pillton>
beach: Do you really think multi threading is important? I would have thought copying a first class environment would be a better approach.
<pierpa>
I'm not a hardware designer
<beach>
Oh, right, cores. We are still using stop-the-world garbage collection, simply because existing systems were designed without taking multiple cores into account.
<bjorkintosh>
so it's the implementation that needs some help.
<beach>
pillton: Yes, I do think it is important to think about multi-threading. Because one part of memory management is common for all threads.
<beach>
In my opinion, these issues (and many more like them) are way more important than the raw speed of the processor. But, of course, addressing these issues takes a lot of knowledge of compiler design, GC design, synchronization, etc.
<pillton>
beach: True. I hadn't considered that part. I was thinking at a higher level.
<beach>
I am thinking at least one core could be dedicated to global GC, running concurrently with the mutator threads.
<aeth>
Do CL native compilers use an assembler that's available (e.g. nasm) or do they do their own assmbling? (if that's the verb?)
<bjorkintosh>
aeth, it's lisp! everything is custom made by hand.
<pierpa>
aeth: I think that typically they use their own assembler
<pierpa>
I mean, none of the systems I know uses an external assembler
shka_ has joined #lisp
<pierpa>
except, indirectly, the ones which compile to C
<pierpa>
ah, you said "native"! then no exceptions :)
<beach>
Existing assemblers are not adapted to on-the-fly compilation. They assume the batch-compilation style of C-like languages, i.e. reading a source file, parsing it, emitting an object file. All that parsing and file manipulation is wasted effort.
LocaMocha has joined #lisp
Sauvin has quit [Ping timeout: 276 seconds]
LocaMocha has quit [Ping timeout: 260 seconds]
Kristof_HT has quit [Read error: Connection reset by peer]
rippa has joined #lisp
LocaMocha has joined #lisp
milanj_ has quit [Quit: This computer has gone to sleep]
ja-barr has quit [Ping timeout: 256 seconds]
* fouric
salivates at the idea of a fully concurrent GC in SBCL
<fouric>
(or any CL implementation, really)
<beach>
fouric: SBCL has a huge historical baggage in that a large part of it was written before we had things like multi-core processors, concurrent GC techniques, etc. The signals I receive from SBCL maintainers are that no such radical changes in SBCL are possible.
gabiruh has quit [Ping timeout: 256 seconds]
<beach>
That is why I think it is time to design a new Common Lisp implementation with all these new techniques in mind. And I think it is important to focus on maintainability and portability, so that we can decrease the collective effort of maintaining free Common Lisp implementations.
gabiruh has joined #lisp
<pierpa>
yes, it is sad to see components which could have been written portably but they weren't.
<stacksmith>
I have a really hard time grokking SBCL's code generator and VOPs... It would be nice to have something straightforward. On the other hand, decades of accrued should not be underestimated...
<beach>
I totally agree.
<beach>
pierpa: I totally agree.
asarch has quit [Quit: Leaving]
smokeink has joined #lisp
<beach>
stacksmith: So what do you suggest?
<stacksmith>
Oh, just complaining. Code generation and optisation is never easy...
ja-barr has joined #lisp
<stacksmith>
Is CCL's GC better? I haven't spent much time with it...
<beach>
I don't know.
<beach>
The other thing is that for the past several decades, great progress has been made in the domain of compiler optimization techniques. We need to read up on those techniques and see which ones can be applied to Common Lisp code, and perhaps how they need to be adapted.
<aeth>
stacksmith: SBCL is the most optimized CL, but you can write something that's considerably more optimized, if you had the time and/or money
<aeth>
Optimization's not easy, but it's not like the bar is set to an impossible height at the moment.
<stacksmith>
Don't forget the brain.
<stacksmith>
You can coax SBCL to produce decent code, but it takes some effort. It took me a while to get used to a single function doing not too much compiling to kilobytes of code...
angavrilov has joined #lisp
<beach>
Isn't that the direct result of wanting safe code without putting in enough declarations?
<stacksmith>
Indeed.
jealousmonk has quit [Quit: Leaving]
<aeth>
I think you could get fast code without declarations for many things if you sacrificed two things: memory and compilation speed.
<aeth>
Live recompilation kind of complicates global analysis, but I think it can be done.
<stacksmith>
By keeping a lot of bookkeeping information around?
<aeth>
Exactly.
<stacksmith>
Have you looked at Self? The polymorphic caches seemed like an interesting idea for accelerating dynamic dispatchin...
<stacksmith>
g
wigust has joined #lisp
<aeth>
Oh, I forgot, the other complicating factor is that you *can* access private functions, with ::
fikka has joined #lisp
<vtomole>
How about compiling CL-LLVM to take advantage of it's optimizing compiler? Is Clasp doing that?
<k-hos>
something something stalin
<aeth>
vtomole: I believe that the standard answer is that CL is just too different from C/C++
<aeth>
One of the standard examples is multiple return values. I forget the others.
<aeth>
This channel should have an FAQ.
damke_ has joined #lisp
<k-hos>
mutltiple return values is something LLVM supports if I remember right
<k-hos>
LLVM isn't made specifically for c/c++
<vtomole>
aeth: I second the FAQ suggestion. What about C--? Haskell uses it.
<stacksmith>
LLVM does a few things that C can't...
<k-hos>
it supports a bunch of things that c/c++ doesn't, like half floats
<k-hos>
I wouldn't say 'can't'
damke has quit [Ping timeout: 264 seconds]
<stacksmith>
figuratively speaking :)
<aeth>
k-hos: CL is a fairly bizarre language, though, with an image-oriented interaction model that is like Smalltalk (and basically no other language?), a strange way to handle errors, etc.
<pierpa>
prolog
<stacksmith>
Forth
<aeth>
pierpa: Interestingly, CLs often came bundled with Prologs. I think all of the commercial ones still are.
smurfrobot has joined #lisp
<pierpa>
Franz and LW, certainly do
lugh has quit [Quit: quitting bouncer]
sz0 has joined #lisp
<beach>
vtomole: I don't know much about LLVM, but with Cleavir and Clasp we have run into several difficulties, mainly resulting from the combination of nested functions and threads made possible in Common Lisp. This feature makes it hard to obtain a precise control flow, and thereby a precise data flow, and those are required for many optimizations.
smurfrobot has quit [Ping timeout: 260 seconds]
<beach>
vtomole: Oh, and there is another interesting mismatch. Clasp uses C++ exceptions to implement non-local control transfers, which are common in Common Lisp. But LLVM assumes that exceptions are infrequent, so they have not been sufficiently optimized. This fact makes them almost useless for implementing Common Lisp.
SumoSudo has joined #lisp
shka_ has quit [Quit: Konversation terminated!]
vyzo has quit [Ping timeout: 260 seconds]
dddddd has quit [Remote host closed the connection]
borei has joined #lisp
SumoSudo has quit [Read error: Connection reset by peer]
pierpa has quit [Quit: Page closed]
vyzo has joined #lisp
Karl_Dscc has joined #lisp
deng_cn has quit [Read error: Connection reset by peer]
<wigust>
b
deng_cn has joined #lisp
gabiruh has quit [Ping timeout: 256 seconds]
gabiruh has joined #lisp
vlatkoB has joined #lisp
pierpa has joined #lisp
axg has left #lisp ["ERC (IRC client for Emacs 25.3.1)"]
Mutex7 has joined #lisp
Oladon has quit [Quit: Leaving.]
oleo has quit [Quit: Leaving]
drewc has joined #lisp
drewc has quit [Ping timeout: 240 seconds]
Karl_Dscc has quit [Remote host closed the connection]
smurfrobot has joined #lisp
vtomole has quit [Ping timeout: 260 seconds]
varjag has joined #lisp
flamebeard has joined #lisp
mishoo has joined #lisp
wigust- has joined #lisp
wigust has quit [Ping timeout: 245 seconds]
<jasom>
beach: it's more than "insufficiently optimized" they are specifically optimized in favor of low-overhead when not being thrown.
<aeth>
If I wanted to see how far I could get writing Lisp for x86-64, should I start with writing an assembler, or should I use an existing assembler and only write an assembler when needed?
dtornabene has joined #lisp
<Shinmera>
beach has an assembler in Lisp that supports AMD64
<aeth>
Shinmera: This wouldn't be for actual users. This will probably be one of those projects where I'll implement 20% to 50%, learn what I wanted to learn, and leave it incomplete and never upload it to the Internet.
<aeth>
So it'd probably involve doing more from scratch than is rational.
<Shinmera>
The assembler is the least interesting part of a compiler
<Shinmera>
because it just does instruction encoding according to fixed rules.
<Shinmera>
Just write a compiler that either emits asm or use a library like beach's.
<aeth>
The most well defined parts of a program are the most interesting parts because they can be rewritten indefinitely.
<dtornabene>
hey all, I'm curious about macrolet, I've read some code using it, but I guess I don't understand a use case specifically that calls for something like that
<Shinmera>
aeth: What? No.
<Shinmera>
There's barely any creativity involved in writing an assembler.
<Shinmera>
dtornabene: Same as flet, keeping things in a local scope because they wouldn't make sense outside of that scope?
<dtornabene>
i guess I just don't understand the use of a macro for that over flet
<Shinmera>
Huh? flet makes functions. Functions are fundamentally different from macros.
<dtornabene>
right, I get that, why would you need to make a *local* macro, not a global one
<aeth>
You almost never do, but there's probably a case when you need it. A lot of the standard is like that.
<Shinmera>
Avoiding the pollution of the global namespace, keeping things semantically tied together to inform the reader that it's, well, local
<dtornabene>
local functions I get, not so much local macros, I guess I haven't travelled far enough down the path yet
smurfrobot has quit [Remote host closed the connection]
<jackdaniel>
dtornabene: because you may need it only locally (i.e for one use with dozen of constructs to have avoid code duplication)
<jackdaniel>
for instance: you define functions for rows and columns and they are different only in x y argument order
<Shinmera>
I also sometimes allow myself "pleasures" in local macros that I don't in global ones, such as not using gensyms or making them anaphoric in some sense.
<dtornabene>
i guess I need to grep some code bases and find examples to read
<Shinmera>
dtornabene: I mean, that's just me, but I feel like the define-generic-arith-routine could easily be a standard macro definition too.
<Shinmera>
Or should just be one, even.
<dtornabene>
hahahaha, sweet. that makes me feel better. even though I had no idea macrolet existed before tonight and am glad to have learned about it
Mutex7 has quit [Quit: Leaving]
<dtornabene>
which is weird, because I've frayed my copy of seibels book with use. I must not have read that chapter that close
quazimodo has quit [Ping timeout: 240 seconds]
<jackdaniel>
truth to be told it is not commonly used operator and one could live happily without it. that said it comes handy at times
<jackdaniel>
you may check out also symbol-macrolet. you could use it for something like (symbol-macrolet ((my-hash (gethash :foo *ht*))) (setf my-hash 10) my-hash)
hajovonta has joined #lisp
sz0 has quit [Quit: Connection closed for inactivity]
smurfrobot has joined #lisp
Amplituhedron has joined #lisp
<dtornabene>
looking it up now jackdaniel
xantoz has quit [Quit: WeeChat 1.9.1]
xantoz has joined #lisp
<dtornabene>
now that looks interesting
<dtornabene>
looks like I have some practice code to write this week
stacksmith has quit [Quit: stacksmith]
stacksmith has joined #lisp
<stacksmith>
I think both are quite useful. Without symbol-macrolet you couldn't have with-slots and such. And macrolet becomes very handy for serious macro work.
<jackdaniel>
ClTl2 had some other goodies, like compiler-let :-)
<hajovonta>
hello all
Cymew has joined #lisp
smokeink has quit [Ping timeout: 240 seconds]
smurfrobot has quit [Remote host closed the connection]
smokeink has joined #lisp
<beach>
Hello hajovonta.
heisig has joined #lisp
pierpa has quit [Ping timeout: 260 seconds]
<stacksmith>
Is name-char only capable of names like "LATIN_CAPITAL_LETTER_A"? My SBCL doesn't like "A" or 'A
smokeink has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 245 seconds]
pierpa has joined #lisp
damke has joined #lisp
quazimodo has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
Xof has quit [Ping timeout: 256 seconds]
<beach>
stacksmith: If you have "A", then just do (CHAR "A" 0)
Amplituhedron has quit [Ping timeout: 245 seconds]
Shinmera- has joined #lisp
Shinmera has quit [Remote host closed the connection]
borodust has quit [Quit: Leavin']
isoraqathedh has quit [Quit: No Ping reply in 180 seconds.]
isoraqathedh has joined #lisp
smurfrobot has quit [Remote host closed the connection]
solene has joined #lisp
<solene>
hello, I'm currently thinking about packaging lisp libraries for an operating system but I wonder if any software would benefit from this. I only know stumpwm as a lisp software. Does someone know some lisp software that would be interesting to package in an OS ?
<beach>
solene: McCLIM comes to mind.
<solene>
beach, it's a libraries, not an end-user software right ?
<beach>
McCLIM is a GUI library, yes.
<solene>
i'm looking for lisp software which could benefit from packaging libraries, to become available as packages. I don't know if I explain well :D
orivej has joined #lisp
<Shinmera->
In my opinion it's wrong to package language libraries with the OS. We already have systems in place that do this, specifically for the language, in a better way than the OS ever could.
Shinmera- is now known as Shinmera
<jdz>
Also, common-lisp-controller has created more problems than it has solved, IMO.
<Shinmera>
Shipping language libraries with the OS only leads to the following: an incomplete, outdated, unmaintained set of libraries that will confuse newcomers.
<jdz>
It was a good effort, and has provided us with experience.
<stacksmith>
Can it do anything Quicklisp can't?
<jdz>
Yes — make you stuck with 3 year old implementation.
<jackdaniel>
sign packages come to mind
<flip214>
Shinmera: I would actually prefer if there was an OS-package-management compatible channel (so, eg. for Debian something like "testing" or "unstable"),
<flip214>
that would automatically track and package new quicklisp releases.
<aeth>
The only reason to put a library in an OS package manager is if an application that's also in the OS package manager uses those libraries. e.g. If your OS ships with stumpwm, and if stumpwm has any dependencies, then that's where it makes sense.
<flip214>
and if that kept older versions (like archive.debian.org) as well, it would be much cleaner to install such software.
<flip214>
aeth: many QL systems _do_ require some OS libs or binaries.
<flip214>
Anything that wants to compile a shared object, like osicat, for example.
<flip214>
--
<aeth>
That's not what I meant.
<flip214>
ISTR that hunchentoot (or cl-who or ...?) had a function that returns an URI with the current parameters, but with a few overrides?
<Shinmera>
The problem is Linux has too many distros. It is not feasible to maintain your package in every damn distro out there. And people are gonna run to /you/ for problems with their outdated OS packages.
<flip214>
Shinmera: debian already has an URL field for (nearly) automatic updates.
<aeth>
I meant that if your distro ships stumpwm in its package manager, then it makes sense for your OS to also ship CLX, a dependency of stumpwm. In that case, the distro's CLX is not for you, the CL programmer. It's for users of the distro's (outdated, but stable) stumpwm.
<flip214>
so that sounds like a cronjob to me.
<Shinmera>
flip214: So what
<solene>
Shinmera, I understand your opinion, but I think it as pros and cons to ship language lib in the system. At least if the package maintainer does it well, you are make sure the programs will run well because you tested it
<jackdaniel>
actually some distributions maintain clx package, I have a request from time to time to make a release, because they want to update
ioa has joined #lisp
<Shinmera>
I for one would be vehemently opposed to having any of my libraries in any of the linux distro package managers.
<aeth>
Then hope that no application that distros want to ship depends on them.
<Shinmera>
Fine by me.
<aeth>
The only CL application that I'm aware of in Fedora is maxima
<solene>
at least quicklisp runs as a user and is simple. Installing perl cpan modules in userland is a bit cumbersome in comparison
<aeth>
But Debian or Arch probably are eager to ship everything.
yangby has quit [Quit: Go out for a walk and buy a drink.]
<aeth>
Oh, Debian. That would frighten me as a library author. People using code I wrote many years ago?!
<Shinmera>
aeth: Exactly
hhdave has joined #lisp
<aeth>
I understand why the xscreensaver person hated it
hhdave has quit [Remote host closed the connection]
hhdave has joined #lisp
<Shinmera>
We already have this problem: debian ships wildly outdated versions of libraries, and every so often someone thinks they should use them and then stumble in here wondering why nothing works.
<solene>
it's an interesting point of view I didn't think about
<Shinmera>
Ideally the lisp application would be shipped as a binary anyway, in which case it already has all the libraries in it. So the only thing needing access to libraries is the one making the package
<Shinmera>
In which case they can use Quicklisp or whatever.
fikka has joined #lisp
<hajovonta>
+1
<aeth>
I don't like it when some distros try to package literally every library on some language's package manager. Libraries from a language package manager (excluding C/C++ if they ever get one) should be strictly for dependencies for applications shipped in the distro package manager. But... there's no real way around it, or else they can't add that application at all.
<aeth>
Stale libraries is the cost of doing things the way distros do things.
<solene>
Shinmera, you can't ship a binary into the package, you have to put the build recipe to create the package, so you need others packages for the dependencies
<Shinmera>
solene: The build recipe can use Quicklisp
<Shinmera>
all it needs is an implementation.
<solene>
Shinmera, quicklisp should always produce the same build then
<Shinmera>
it can, just tag a specific version to download.
<solene>
so it's the same as packaging fixed version libraries
<Shinmera>
it's not, because the libraries never end up in the ecosystem
<solene>
I see
<Shinmera>
only the reproducibly built application does, which is fine.
<solene>
currently it's what I've done to package stumpwm, the build system download the few libraries to compile the stumpwm binary and it get packaged
<solene>
but then you miss the stumpwm reload flexibility
<Shinmera>
Not necessarily. After all, the binary will include a full Lisp, so you can just ask the user to download the sources somewhere and then direct stump to upgrade using those.
fikka has quit [Ping timeout: 268 seconds]
<Shinmera>
In other news, Didier and I are testing the ELS registration in live mode now, so registration should be open today or tomorrow!
<aeth>
Shinmera: The binary won't necessarily include a full Lisp. Eventually, tree shakers will come.
<Shinmera>
It does at this time.
<aeth>
Probably not anytime soon, but in the scale of Debian releases, maybe soon
fikka has joined #lisp
<Shinmera>
Plus even with a tree shaker, anything using CLOS will likely pull in the full compiler anyway, so
pagnol has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
<aeth>
interesting
fikka has joined #lisp
pierpa has quit [Ping timeout: 260 seconds]
deng_cn1 has joined #lisp
deng_cn has quit [Ping timeout: 256 seconds]
deng_cn1 is now known as deng_cn
<beach>
I personally think we should have a Common Lisp implementation with most of its system code, including the compiler, in a shared library. That way, we have the full functionality of the system, without any complaints about the size of application binaries.
python47` has joined #lisp
<loke>
beach: Isn't that basically ECL?
<Shinmera>
Or libsbcl.so (whenever that finally happens)
<beach>
loke: Maybe so. I don't know the ECL details.
fikka has quit [Ping timeout: 240 seconds]
<jackdaniel>
yes, ecl binary is just a small wrapper over libecl.so
<jackdaniel>
(libecl.a is possible too)
deng_cn has quit [Remote host closed the connection]
<jackdaniel>
and all compiled systems (i.e alexandria.fas) are in fact shared objects by default
wigust- has quit [Ping timeout: 256 seconds]
<jackdaniel>
(compiling systems to .so and .a is possible too)
deng_cn has joined #lisp
fikka has joined #lisp
milanj_ has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
energizer has quit [Ping timeout: 248 seconds]
fikka has joined #lisp
python47` has quit [Quit: nickkkk]
fikka has quit [Ping timeout: 268 seconds]
smurfrobot has joined #lisp
SumoSudo has joined #lisp
<dtornabene>
has anyone here ever read "The Semantics of Destructive Lisp"
<beach>
jackdaniel: Excellent!
_cosmonaut_ has joined #lisp
fikka has joined #lisp
python476 has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
<flip214>
when I have an accessor name (for a CLOS slot), can I call the setter from that?
<flip214>
database error 28000: no postgresql-username passed in initial packet.
fikka has quit [Ping timeout: 240 seconds]
<jackdaniel>
jmercouris: yes, I've helped to integrate it
<jmercouris>
jackdaniel: so, if my understanding of the project is correct you can call functions/pass data back and forth between any of the supported languages?
<jackdaniel>
correct
<jackdaniel>
you are able to play with CL service provider from python for instance
<jackdaniel>
(and vice versa)
<jmercouris>
jackdaniel: and the calling of these functions must be two separate processes right?
<jmercouris>
jackdaniel: aka, you can't just call a c function without a c program running
<jackdaniel>
I don't understand
<jackdaniel>
ah, protocol is language agnostic
<jackdaniel>
you can't call a service method if there is no entity which provides the service
<jmercouris>
Yes, that was my question
<jmercouris>
very interesting technology
<jmercouris>
thank you for integrating it, I think I will use it for what I am doing
dtornabene has quit [Quit: Leaving]
<jackdaniel>
sure, good luck. when we fix the missing bits for CCL and ECL I will submit it to Quicklisp
<jackdaniel>
(the CL library that is)
smurfrobot has quit [Ping timeout: 260 seconds]
<jmercouris>
ah, so I'll have to use it with SBCL for now then
<jackdaniel>
you may also make a pull request with your favourite implementation port
<jmercouris>
it's definitely going to be a much less friction approach than me effectively reinventing a high level approach of that in my frontends
<jmercouris>
ok, I'll keep that in mind
<jmercouris>
jackdaniel: can you explain why someone would choose a different protocol in thrift?
<jmercouris>
so is the transport protocol exposed to the implementor?
<jackdaniel>
yes
<jmercouris>
I assume I have to do write some "serialization" and "deserializaiton" stubs?
<jmercouris>
in the form of either inheritance or delegation?
<jackdaniel>
I think you'll be better served by the actual implementation and Thrift documentation than my faulty memory (and not-so-perfect English)
<jmercouris>
your english is fine, but I'll look at the docs anyway
<jmercouris>
thanks for the info
EvW1 has joined #lisp
<jackdaniel>
thanks, I hope it is - it is still not perfect (as asserted ;)
karswell_ has joined #lisp
karswell has quit [Remote host closed the connection]
lakota has joined #lisp
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
heisig has quit [Remote host closed the connection]
EvW1 has quit [Ping timeout: 240 seconds]
raynold has quit [Quit: Connection closed for inactivity]
oldtopman has quit [Ping timeout: 276 seconds]
milanj_ has quit [Quit: This computer has gone to sleep]
smurfrobot has joined #lisp
milanj_ has joined #lisp
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
test1600 has quit [Ping timeout: 256 seconds]
nowhere_man has joined #lisp
knicklux has joined #lisp
oldtopman has joined #lisp
nowhereman_ has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
python476 has quit [Read error: Connection reset by peer]
lnostdal has quit [Remote host closed the connection]
lnostdal has joined #lisp
SumoSudo has quit [Ping timeout: 240 seconds]
lakota has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
test1600 has joined #lisp
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
d4ryus1 is now known as d4ryus
EvW has joined #lisp
nowhere_man has quit [Ping timeout: 276 seconds]
knobo1 has joined #lisp
scymtym has joined #lisp
Bike has joined #lisp
Bike is now known as Bicyclidine
smurfrobot has quit [Remote host closed the connection]
rumbler31 has quit [Remote host closed the connection]
tripty^ has quit [Remote host closed the connection]
smurfrobot has joined #lisp
pierpa has joined #lisp
Digit has quit [Ping timeout: 248 seconds]
<hajovonta>
what is the idiomatic form of binding variables to elements of a list?
<hajovonta>
like (multiple-value-bind (a b) (list 1 2) (list a b)) but it doesn't work because list only returns 1 value and the other will be nil.
<Bicyclidine>
destructuring-bind
<hajovonta>
thanks
smurfrobot has quit [Ping timeout: 256 seconds]
schweers has joined #lisp
muresanvlad_ has joined #lisp
Murii has quit [Read error: Connection reset by peer]
muresanvlad__ has joined #lisp
<jmercouris>
what if the values in the list are like this (list "key1" "value1" "key2" "value2") what's the best way to turn that into an easy to access data structure like a hash-table?
Digit has joined #lisp
<Bicyclidine>
(loop with result = (make-hash-table :test #'equal) for (key value) on list by #'cddr do (setf (gethash key result) value) finally (return result))
<jmercouris>
Bicyclidine: I was hoping for some built in, a library I'm using returns json results in that manner
<Bicyclidine>
why does it matter if it's built in
<flip214>
jmercouris: (alexandria:plist-hash-table) or similar
muresanvlad__ has quit [Client Quit]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
muresanvlad_ has quit [Read error: Connection reset by peer]
<jmercouris>
Bicyclidine: Doesn't matter, just means I'd have to make a "utility" function, I wouldn't like embedding that snippet into my codebase
Murii has joined #lisp
<jmercouris>
like I wouldn't put that inline in every function that works with that list
<jmercouris>
flip214: that sounds good, thanks!
<flip214>
jmercouris: alexandria has quite a few such thingies
<Bicyclidine>
no, you'd put it in a function definition, obviously
<flip214>
jmercouris: but if there are not that many entries, a simple list might be faster to process.
<flip214>
jmercouris: or you could tell your json library to return a hash-table in the first place!
<jmercouris>
What I currently have is like a (position "key" list) and then do nth +1 on the position of the key I'm looking for
Kundry_Wag has joined #lisp
<flip214>
how many times is the question....
<jmercouris>
flip214: Not too many, so it is okay, I think it'd be smarter to change the json lib return though, you're right
muresanvlad_ has joined #lisp
<jmercouris>
there is (yason:parse stream :object-as :plist), I'm sure there is :hash-table as well or something
<jmercouris>
I was just wondering about this problem in general
<jmercouris>
is there a way to get the documentation under the symbol at a point?
muresanvlad_ has quit [Client Quit]
<jmercouris>
e.g. (yason:parse ...) and my cursor is there, can I jump to the docstring for that function somehow?
makomo_ has joined #lisp
<sigjuice>
M-. to jump to the function
<Bicyclidine>
jmercouris: you can use getf instead of that position stuff.
smurfrobot has joined #lisp
<jmercouris>
sigjuice: That is quite useful, that one I did know about though, imagine something more like a help buffer
<Bicyclidine>
no, wait, there's no test. guess you can't
<sigjuice>
and M-, to jump back
<jmercouris>
Bicyclidine: yeah says only "identical"
Murii has quit [Ping timeout: 265 seconds]
<sigjuice>
M-. on yason:parse did not show a docscring with any useful info about :object-as
<jmercouris>
The M-, jump back I did not know, interesting!
<jmercouris>
yeah, I wish it included a list of "keyword arguments" ... which "can be used to override the parser settings"
<sigjuice>
but M-. on *parse-object-as* says (defvar *parse-object-as* :hash-table)
<jmercouris>
but it is visible above in parse%
<jmercouris>
so maybe it does make more sense to just jump to source instead of opening a help buffer with the docstring
<jmercouris>
yeah, I see the following: (check-type *parse-object-as* (member :hash-table :alist :plist) as possibilities
<jmercouris>
so hash-table is the default then
<sigjuice>
I didn't read far enough to see that %parse was a thing. I saw *parse-object-as* and immediately mmmdotted
smurfrobot has quit [Ping timeout: 240 seconds]
<jmercouris>
ah, the docstring for the defvar also includes that information
<jmercouris>
well, I'll be :)
<jmercouris>
so M-, always seems to unwind this stack
<jmercouris>
very useful
<sigjuice>
also a quick experiment: CL-USER> (with-input-from-string (s "{}") (yason:parse s)) => #<HASH-TABLE :TEST EQUAL :COUNT 0 {1008D960A3}>
rotty has quit [Ping timeout: 256 seconds]
Denommus has quit [Ping timeout: 256 seconds]
BitPuffin has joined #lisp
rotty has joined #lisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
makomo_ has quit [Ping timeout: 248 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
attila_lendvai has quit [Ping timeout: 260 seconds]
Murii has joined #lisp
pierpa has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 265 seconds]
smurfrobot has joined #lisp
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
asarch has joined #lisp
dotc has left #lisp [#lisp]
Ven`` has joined #lisp
pierpa has joined #lisp
dddddd has joined #lisp
<thodg>
beach: thanks !
<beach>
thodg: Anytime!
Amplituhedron has joined #lisp
Bike has joined #lisp
* Shinmera
just registered for ELS'18. Public registration imminent!
Kundry_Wag has quit [Remote host closed the connection]
khisanth_ has quit [Ping timeout: 248 seconds]
rumbler31 has joined #lisp
smurfrobot has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Naergon has quit [Remote host closed the connection]
Naergon has joined #lisp
Selwyn has joined #lisp
khisanth_ has joined #lisp
shka has joined #lisp
warweasle has joined #lisp
milanj_ has quit [Quit: This computer has gone to sleep]
Selwyn has quit [Remote host closed the connection]
LiamH has joined #lisp
makomo has joined #lisp
smokeink has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 268 seconds]
Kundry_Wag has joined #lisp
<dim>
wow
knicklux has quit [Quit: Leaving]
milanj_ has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
rumbler3_ has joined #lisp
pfdietz_ has joined #lisp
ja-barr_ has joined #lisp
pagnol has quit [Ping timeout: 240 seconds]
smokeink has quit [Quit: Leaving]
ja-barr has quit [Ping timeout: 276 seconds]
pfdietz has quit [Ping timeout: 276 seconds]
rumbler31 has quit [Ping timeout: 276 seconds]
anunnaki has quit [Ping timeout: 276 seconds]
joast has quit [Ping timeout: 276 seconds]
anunnaki has joined #lisp
test1600 has quit [Quit: Leaving]
damke has joined #lisp
dmiles has quit [Ping timeout: 240 seconds]
nowhere_man has joined #lisp
oleo has joined #lisp
BitPuffin has quit [Remote host closed the connection]
cross has quit [Remote host closed the connection]
Cymew has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
rumbler31 has joined #lisp
nowhereman_ has quit [Ping timeout: 260 seconds]
nowhereman_ has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
joast has joined #lisp
Kundry_Wag has joined #lisp
igemnace has quit [Quit: WeeChat 2.0.1]
parjanya has quit [Ping timeout: 256 seconds]
BitPuffin has joined #lisp
comborico1611 has joined #lisp
axg has joined #lisp
araujo has joined #lisp
araujo has quit [Max SendQ exceeded]
Kaisyu has quit [Quit: Connection closed for inactivity]
<borei>
hi all
nullman has quit [Remote host closed the connection]
vtomole has joined #lisp
EvW has quit [Ping timeout: 240 seconds]
EvW has joined #lisp
lnostdal has quit [Read error: Connection reset by peer]
zooey has quit [Read error: Connection reset by peer]
lnostdal has joined #lisp
<borei>
to find how to implement "true lisp" solution to particular problems. Not easy task id say.
<borei>
some non-technical thoughts, but rather more language philsophy. Using lisp for last 8 months i started to realise that im using (or trying to use) it in the same way like i used to use "traditional languages" - like C/C++ or python. The same classes, functions, program structure etc etc. Recentely i found very interesting book - "Let over lambda". That book is targetting to change approach in regards to programming in lisp. Now i'm trying
zooey has joined #lisp
smurfrobot has joined #lisp
<jackdaniel>
borei: LoL doesn't show how Lisp practicioners solve problems. It may be amusing though.
<borei>
can't say, but it opened eyes is absolutely different way. I finally started to understand what is closure, but don't know how to use it, except for couter-like problem.
<dlowe>
borei: unlike some, CL is not an "opinionated" language, so you should feel free to work however you want. You can pick tricks up along the way.
smurfrobot has quit [Ping timeout: 256 seconds]
<borei>
true, but i think very important part is - to know your "tools set" and to how to use that tools in most efficient way.
FreeBirdLjj has quit [Remote host closed the connection]
Amplituhedron has quit [Ping timeout: 248 seconds]
<jmercouris>
borei: there is no most efficient way
<jmercouris>
it really depends on the problem at hand, different approaches lend themselves to different tools, in the context of lisp, that may mean different paradigms that it supports
<jmercouris>
what others have said is true, lisp is not opinionated, this flexibility allows you to adapt your style to the problem at hand
<pjb>
borei: closures are equivalent to objects.
<jmercouris>
pjb: That is a very interesting thought, I never thought of it that way
<pjb>
borei: the only difference, is that closures are anonymous, and have all their methods (functions) in the same lexical scope, while with CLOS, methods are written all over the place.
random-nick has joined #lisp
<pjb>
and classes are named (usually).
<jmercouris>
If we have a reference to a closure, is it still considered anonymous?
mlf has joined #lisp
<pjb>
So in terms of software engineering, you will usually want classes, as soon as it becomes more complex than an anonymous object with one or two methods.
<pjb>
jmercouris: yes. There's no (find-closure 'name)
<jmercouris>
what about this (defvar something (lambda () (print "my function"))) is my lambda still an anonymous function?
<pjb>
It is.
lakota has joined #lisp
<pjb>
(something) -> no such function.
flamebeard has quit [Quit: Leaving]
<jmercouris>
but I have a symbol pointing to it (or whatever the word for "something" in this context is)
<jackdaniel>
(let ((foo 3)) (defun bar () (incf foo))
<pjb>
jmercouris: but in general, you're right that naming is only a question of context.
<jackdaniel>
is bar anonymous? ;-)
<jmercouris>
but if I run (funcall something) it'll run
<jackdaniel>
that means it is a function
<Bike>
the songs name is called haddocks' eyes
<pjb>
And I argue that (lambda (x) x) is the name of the function (lambda (x) x), since we call functions with (<name> …) and ((lambda (x) x) …) shows that (lambda (x) x) is the name.
<jmercouris>
the rabbit hole goes deeper... :D
<jmercouris>
jackdaniel: my point was that I have a way of invoking it by name
<jmercouris>
it's not referenceless, just unnamed
<jackdaniel>
no, you invoke it by references not by name
<pjb>
borei: one advantage of closures over CLOS objects, is that it takes its slots from the lexical environment. So "object construction" is easy and almost invisible.
<jackdaniel>
you'd invoke it by name if you had setf'ed some name fdefinition with it
<jmercouris>
anyways, when we say anonymous, we mean unnamed, then yes?
<jackdaniel>
and then called (my-name), or did (funcall 'fname)
lakota has left #lisp [#lisp]
<jackdaniel>
anonymous function is a function which is not bound to an identifier
<Bike>
when we talk about anonymous functions, what we're actually trying to emphasize is that functions are values like anything else, rather than some details of how binding works.
<jmercouris>
Right, so not bound to a symbol, basically, unnamed
<beach>
jmercouris: In (defvar x 3) is 3 named?
<jmercouris>
maybe I'm not using the right words
<Bike>
many programming languages do not allow functions to be dealt with as values, and only allow referencing them less directly through names. that's it.
<hajovonta>
what I really liked is that the author showed that it's possible to keep the lexical environment
<jmercouris>
but I believe I understand
<jmercouris>
beach: no, but we have a reference to it
<jmercouris>
so all functions are anonymous, but we have references to them?
<pjb>
Well, really, there's no (function-name f) operator, so we could say that in lisp, no function is named.
<pjb>
You can implement function-name returning a list of symbols fbound to the function. Not very satisfatory, and very slow.
<beach>
jmercouris: All Common Lisp objects are anonymous in that respect. But we have references to them. Otherwise the GC would get them.
<jmercouris>
interesting
<beach>
jmercouris: Common Lisp uses what I call "Uniform reference semantics".
<jmercouris>
is there a way to "dereference" a function and have it be garbage collected?
<pjb>
characters, classes, pathnames, sites, restarts, symbols and packages have names.
<jmercouris>
so if I do (defun lol ()) can I get rid of "lol" somehow?
<beach>
jmercouris: Lose all references to it.
<jmercouris>
I mean the function, not the symbol
dyelar has quit [Remote host closed the connection]
Kundry_Wag has quit [Remote host closed the connection]
<_death>
but minion didn't find it
<jmercouris>
is this book available online?
<beach>
jmercouris: Common Lisp, the Language, Second edition. Guy Steele.
<beach>
Yes.
<pjb>
_death: minion found the page, but it's not formatted to contain a _definition_.
<jmercouris>
for future readers:http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html
whartung has quit [Read error: Connection reset by peer]
<_death>
maybe minion could pick the first line then
whartung has joined #lisp
<pjb>
Yes, something smart should be done.
<beach>
_death: I think the minion maintainer has declared that the Cliki format changed and he is not going to modify minion to recognize the new one.
<pjb>
(incf (AIQ minion))
<jmercouris>
I feel like Guy Steele is a name I've seen before, is there something he is famous for in the context of lisp?
<_death>
beach: a project for someone else then ;)
<beach>
jmercouris: Java was a great improvement over what was before.
<pjb>
Sadly true.
<beach>
jmercouris: Java has (almost) uniform reference semantics, possible thanks to GC.
<jmercouris>
beach: I didn't live in a pre-java world, so it hard for me to judge what life was like then, but java is a great language, with great ideas, it's just a little too verbose for my taste
<pjb>
Bah, java8 has lambdas…
<beach>
jmercouris: It had no new ideas. But it had the syntax that made C++ programmers think it was not too different. Boy were they wrong. It is closer to Common Lisp.
<jmercouris>
beach: why do you say that? because of GC? no pointers? stuff like that?
whartung has quit [Ping timeout: 256 seconds]
<beach>
jmercouris: If you have no GC, you can't really program only with references (or pointers) as we do in Java or Common Lisp, because you never know how many references you have. So you get this very complex programming style with templates, copy constructors, smart pointers, you name it.
whartung_ has joined #lisp
<jmercouris>
I wish I knew C++ so I could understand the differences, I only know some basic C which doesn't have any of those features as far as I know
<jmercouris>
an interesting story nontheless
<beach>
jmercouris: Correct, C doesn't have those, which makes it totally impossible to write applications in it. The C++ features are there to make it somewhat possible.
<jmercouris>
I remember it being very difficult, yes
<_death>
sorry, I prefer C++ to Java ;) luckily, we agree on Lisp
lakata has joined #lisp
hajovonta has quit [Quit: hajovonta]
igemnace has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
comborico1611 has quit [Quit: Konversation terminated!]
smurfrobot has joined #lisp
borodust has joined #lisp
Nouv has joined #lisp
Amplituhedron has quit [Ping timeout: 265 seconds]
<pjb>
come on, come on, C11 has generics! You can write applications with it ;-)
<beach>
Yeah, right!
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
smurfrobot has quit [Remote host closed the connection]
schweers has quit [Ping timeout: 265 seconds]
<beach>
jmercouris: If you ever get stuck with using C or C++ to write applications, the best thing to do is to link you program with the Boehm/Weiser garbage collector and then you use pointers for everything just like we do in Java and Common Lisp. That's the only sane way to write applications in those languages.
<_death>
really depends on what kind of application you're writing..
Amplituhedron has joined #lisp
<jmercouris>
beach: thanks for the advice, but I don't plan on working any C/++ jobs anytime soon :D
Satou has joined #lisp
pierpa has quit [Ping timeout: 260 seconds]
<pjb>
yes, BoehmGC, and GnuMP for numbers :-)
<pjb>
Bref, you're redoing what's in ecl.
<pjb>
Just link with libecl, and do the sane thing!
<beach>
One may or may not be able to get away with that. But yeah, that's a good idea.
Cymew has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
nsrahmad has joined #lisp
nsrahmad has quit [Client Quit]
hhdave has quit [Ping timeout: 256 seconds]
Tobbi has joined #lisp
energizer has joined #lisp
<dim>
well I still spend some time writting applications in C... in PostgreSQL-C that is... it's special, but not that bad
Satou has quit [Quit: Cya soon guys!]
smurfrobot has joined #lisp
_cosmonaut_ has quit [Ping timeout: 240 seconds]
smurfrobot has quit [Ping timeout: 248 seconds]
Karl_Dscc has joined #lisp
fisxoj has joined #lisp
vtomole has quit [Ping timeout: 260 seconds]
damke_ has joined #lisp
Amplituhedron has quit [Ping timeout: 256 seconds]
damke has quit [Ping timeout: 264 seconds]
al-damiri has joined #lisp
ckonstanski has joined #lisp
Nouv has quit [Remote host closed the connection]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
Kundry_Wag has quit [Remote host closed the connection]
rstandy has joined #lisp
Kundry_Wag has joined #lisp
rstandy has quit [Client Quit]
nowhereman_ has quit [Ping timeout: 276 seconds]
troydm has joined #lisp
parjanya has joined #lisp
Ven`` has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
quazimodo has quit [Ping timeout: 256 seconds]
fisxoj has quit [Quit: fisxoj]
Ven`` has joined #lisp
parjanya has quit [Read error: Connection reset by peer]
Kundry_Wag has quit [Read error: No route to host]
Kundry_Wag has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
smurfrobot has joined #lisp
Ven`` has quit [Ping timeout: 252 seconds]
skali has joined #lisp
lnostdal has quit [Remote host closed the connection]
energizer has quit [Disconnected by services]
energizer has joined #lisp
energizer has quit [Remote host closed the connection]
energizer has joined #lisp
Ven`` has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
smurfrobot has joined #lisp
skali has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shka_ has joined #lisp
vlatkoB has quit [Remote host closed the connection]
Ven`` has quit [Ping timeout: 240 seconds]
smurfrobot has quit [Remote host closed the connection]
Cymew has joined #lisp
smurfrobot has joined #lisp
random-nick has quit [Ping timeout: 260 seconds]
ckonstanski has quit [Remote host closed the connection]
smurfrobot has quit [Ping timeout: 240 seconds]
Cymew has quit [Ping timeout: 260 seconds]
Satou has joined #lisp
Ven`` has joined #lisp
xrash has joined #lisp
smurfrobot has joined #lisp
comborico1611 has joined #lisp
lakata has quit [Ping timeout: 248 seconds]
nowhereman_ has joined #lisp
smurfrobot has quit [Ping timeout: 248 seconds]
EvW1 has joined #lisp
alexmlw has joined #lisp
hiroaki has joined #lisp
<comborico1611>
Why is it when you do M-del in Slime, all the text is deleted except for all the parentheses?
<pjb>
comborico1611: type C-h k M-del
raynold has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
Ven`` has quit [Ping timeout: 240 seconds]
<comborico1611>
pjb: Hmm. I never realized that. I am new to Emacs, though. I just thought I would have realized that by now. Weird.
<comborico1611>
Thanks!
<pjb>
so, the why is because it's bound to that paredit-backward-kill-word command.
<comborico1611>
pjb: Best procedure then, is to kill line?
<pjb>
Now why do we have such a command in paredit?
<pjb>
Nope.
<pjb>
Best procedure is to understand that paredit provides a higher level editing mode.
<comborico1611>
I see.
<pjb>
paredit provides _structured_ editing.
<comborico1611>
I'll fight with it until I get this book knocked out.
<pjb>
Instead of editing the text, with indiscriminate structure, with paredit you're editing the sexp, with it's tree-like structure specified by the parentheses.
<pjb>
(and auxiliarily, by brackets, braces, and double quotes)
Satou has quit [Quit: Cya soon guys!]
<pjb>
So you have commands to process the text itself, and commands to process the structure of the sexp.
<pjb>
You can use C-M-k (kill-sexp) to kill a whole sexp.
<pjb>
C-k is paredit-kill, which respects the structure still.
<pjb>
and check the Paredit minor mode section.
fikka has joined #lisp
sindan has joined #lisp
wigust has quit [Ping timeout: 248 seconds]
smurfrobot has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
grublet has joined #lisp
smurfrobot has quit [Ping timeout: 240 seconds]
jmercouris has joined #lisp
Ven`` has joined #lisp
<jmercouris>
My advice would be to ignore paredit for now, and just use c-d to kill chars
<jmercouris>
or c-space, highlight and then c-w to kill
fikka has quit [Ping timeout: 256 seconds]
milanj_ has quit [Quit: This computer has gone to sleep]
smurfrobot has joined #lisp
<comborico1611>
jmercouris: Yeah, definitely not an essential skill at the moment.
<dim>
jmercouris: then why not ignore lisp altogether and go write Python code instead, I wonder? paredit is really nice to have, and like everything, demands some learning... when new to Emacs I'm not convinced paredit adds too much to the learning curve after all
damke_ has quit [Ping timeout: 264 seconds]
<jmercouris>
dim: You are free to your own opinion. You've presented a false dichotomy though; paredit or python, it doesn't work that way
<jmercouris>
paredit isnt THE killer feature that makes lisp good, so it doesn't merit frustrating new users
<jmercouris>
I believe it is best to slowly add things to your workflow as you master them instead of piling them on all at once
damke_ has joined #lisp
<rumbler31>
I find a tension between new users losing their proper nesting while hearing that "lisp has no syntax" to be a strong driver behind calls to use paredit earlier than other tools
<jmercouris>
having said all of this, I would reccommend at a minimum smart-parens mode
smurfrobot has quit [Ping timeout: 240 seconds]
<comborico1611>
jmercouris: It appears some people forget how difficult it was starting off.
<rumbler31>
I remember losing my nesting and staring at the parens thinking, where the hell am I supposed to add the missing one!
<jmercouris>
they don't forget how hard it was, they think it will save you frustration in the very near future
smurfrobot has joined #lisp
<jmercouris>
they are very correct about this, but I would say, when you get to that point, you can pick it up
<comborico1611>
rumbler31: That may be if the new user isn't using a book to guide them or something. And that is more of an experienced programmer coming to Lisp.
<dim>
all I'm saying is that if new to Emacs and paredit is installed, I'd be surprised that learning how to use paredit in Emacs would be much more difficult than learning bare Emacs
<dim>
(ok I also said that I don't understand why you'd target lesser quality tools than the ones you have)
<dim>
one way or another learning new skills is very hard
<rumbler31>
comborico1611: what do you mean about using a book, are you following along in a text that is instructing you in what to type?
<jmercouris>
I don't disagree with you, it's not like I don't use paredit, I just think it's a lot for a new user, I could barely remember the movement commands after using emacs for a day
<comborico1611>
I suppose so. The position I'm in at the moment is to focus 100% of my time working on this beginner's book to CL. Then, if I'm still intersted in pursuing more Lisp coding, then add on things.
<jmercouris>
then again, it has been many years, so I am not sure how much I can really remember about how it was
<comborico1611>
rumbler31: yes, it is instructing me what to type.
asarch has quit [Quit: Leaving]
Ven`` has quit [Ping timeout: 245 seconds]
<comborico1611>
I would go so far as to say if one doesn't know Emacs, skip Emacs and go through this book, then pick it up later. The disclaimer on that is whether the newcomer to Lisp is freestyling it or following in a book. If they are freestyling/more advanced, then whatever they want to do.
<rumbler31>
what book?
<comborico1611>
Common Lisp: A Gentle Introduction to Symbolic Computation
lakata has joined #lisp
smurfrobot has quit [Ping timeout: 248 seconds]
<jmercouris>
So, I'm thinking about how to represent something like the emacs window layout, I assume this done using a tree, right?
<jmercouris>
possibly like ("split-vertical" buffer1 ("split-horizontal" buffer2 buffer3))?
Ven`` has joined #lisp
<jmercouris>
this would I guess show buffer1 on the left hand side, and buffer2 in the top right corner, buffer3 in the bottom right corner
lakata has left #lisp [#lisp]
<cgay>
You're more-or-less describing what a window layout looks like in CLIM/DUIM source code.
<jackdaniel>
I can't connect to european-lisp-symposium.org
lakota has joined #lisp
<jmercouris>
cgay: Ok, good to know that my reinvention of the wheel will be similar to existing paradigms :D, it means a step in the right direction I guess lol
<k-hos>
make your wheel a tank track
<jmercouris>
k-hos: is there some hidden advice in this?
<k-hos>
nope :>
<jmercouris>
ok, just checking :D
quazimodo has joined #lisp
<Bike>
just solid vehicle design advice.
<rumbler31>
that way you can steamroll your competition
<rumbler31>
I mean.... navigate any terrain
<jmercouris>
My issue is how I'll deal with traversal of this tree
<Bike>
the earth itself is my greatest rival.
<jmercouris>
basically implementing windmove will be a pain I believe
<rumbler31>
jmercouris: I recommend low gear and steady application of the throttle
<jmercouris>
I'll have to probably make a tree with references to parent as well
<jmercouris>
rumbler31: I'll keep that in mind, thanks :D
<jmercouris>
I think I'll use a structs to build my tree instead of plain lists, it'll make it conceptually easier for me
alexmlw1 has joined #lisp
angavrilov has quit [Remote host closed the connection]
Ven`` has quit [Ping timeout: 240 seconds]
alexmlw has quit [Ping timeout: 265 seconds]
alexmlw1 is now known as alexmlw
alexmlw has quit [Read error: Connection reset by peer]
<cgay>
Why would you even think of using plain lists? :)
alexmlw has joined #lisp
lakota has quit [Ping timeout: 276 seconds]
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 240 seconds]
Ven`` has joined #lisp
Ven`` has quit [Ping timeout: 256 seconds]
Ven`` has joined #lisp
fourier has joined #lisp
EvW1 has quit [Remote host closed the connection]
noobly has quit [Ping timeout: 260 seconds]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
alexmlw has quit [Quit: alexmlw]
sysfault has quit [Quit: Leaving]
smurfrobot has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Ven`` has quit [Ping timeout: 248 seconds]
milanj has joined #lisp
smurfrobot has quit [Ping timeout: 268 seconds]
<fouric>
~/b 7
<fouric>
mb
SumoSudo has joined #lisp
Ven`` has joined #lisp
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
Ven`` has quit [Ping timeout: 256 seconds]
Kundry_Wag has quit [Remote host closed the connection]
lakota has joined #lisp
Kundry_Wag has joined #lisp
parjanya has joined #lisp
Ven`` has joined #lisp
parjanya has quit [Read error: Connection reset by peer]
jmercouris has quit [Ping timeout: 260 seconds]
Mutex7 has joined #lisp
Ven`` has quit [Ping timeout: 256 seconds]
lakota has left #lisp ["ERC (IRC client for Emacs 27.0.50)"]
fikka has joined #lisp
nowhere_man has joined #lisp
shka_ has quit [Ping timeout: 260 seconds]
nowhereman_ has quit [Ping timeout: 268 seconds]
fourier has quit [Ping timeout: 268 seconds]
smurfrobot has joined #lisp
hiroaki has quit [Quit: Leaving]
Kundry_Wag has quit [Remote host closed the connection]
smurfrobot has quit [Ping timeout: 256 seconds]
Kundry_Wag has joined #lisp
smurfrobot has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
parjanya has joined #lisp
smurfrobot has quit [Ping timeout: 245 seconds]
<pjb>
comborico1611: in anycase, for all the minor modes listed in C-h m, you can disable and enable them at will. Most of the time, their command will toggle them: M-x paredit-mode RET Otherwise type C-u 0 M-x paredit-mode RET to disable, and C-u 1 M-x paredit-mode RET to enable.
<pjb>
However, before enabling paredit-mode you need to check that parentheses are well balanced. Use M-x check-parens RET
smurfrobot has joined #lisp
asarch has joined #lisp
<pjb>
And yes, I agree that newbies may start using NotePad.exe (or nano) to edit lisp, and use the clisp REPL in a terminal (or rlwrap ccl or rlwrap sbcl). But not more than a couple of weeks. Once you feel the pain of working with a text editor and in a terminal, you should switch to emacs+paredit+slime and understand their advantages.
rumbler31 has quit [Ping timeout: 252 seconds]
damke has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Ping timeout: 240 seconds]
parjanya has quit [Read error: Connection reset by peer]
damke_ has quit [Ping timeout: 264 seconds]
smurfrob_ has quit [Ping timeout: 252 seconds]
LiamH has quit [Read error: Connection reset by peer]
energizer has quit [Remote host closed the connection]
LiamH has joined #lisp
energizer has joined #lisp
rumbler3_ has quit [Remote host closed the connection]
BitPuffin has quit [Remote host closed the connection]
parjanya has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
parjanya has quit [Read error: Connection reset by peer]
LiamH has quit [Quit: Leaving.]
<dim>
what's the intended behavior when a condition is signaled and not handled from within a with-open-file form? is there an implicit unwind-protect that properly closes the file?
<Shinmera>
Just read clhs: "When control leaves the body, either normally or abnormally (such as by use of throw), the file is automatically closed. If a new output file is being written, and control leaves abnormally, the file is aborted and the file system is left, so far as possible, as if the file had never been opened.
<Shinmera>
"
<dim>
oh, that would explain, thanks
ikki has joined #lisp
mishoo has quit [Ping timeout: 268 seconds]
<dim>
this old code of mine is a little hard to debug with its use of make-broadcast-stream to capture output and errors of uiop:run-program in both the console and a log file
<dim>
error handling is always the hardest part, right?
Bike has quit [Ping timeout: 260 seconds]
rumbler31 has joined #lisp
rumbler3_ has joined #lisp
Karl_Dscc has quit [Remote host closed the connection]
rumbler31 has quit [Ping timeout: 268 seconds]
LocaMocha is now known as Sauvin
smurfrobot has joined #lisp
<pjb>
dim: it's not that it's hard, it's that it may need to be exhaustive: the condition hierarchy in your application may easily be the triple of the size of your application class hierarchy.
<comborico1611>
pjb: Portacle has been a life-saver for me. It should be one of the first things that comes out of the mouth of the Lisp community to beginners.
<pjb>
comborico1611: good for you. I don't know the first thing about portacle.
<Shinmera>
comborico1611: Glad to hear!
<pjb>
Having been into programming since 1975, I tend to either have learned stuff before stuff existed, or just have a natural preference to go to the main reference (however hard or arid it may be to read), and to build my own tools.
Amplituhedron has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
<fe[nl]ix>
comborico1611: there is no Lisp community
<pjb>
Of course, I can understand the interest of having nice pedagogical environments (and even perhaps IDEs for professional work), but the former should be the task of teachers, and the both require a lot of resources to develop and maintain.
<Shinmera>
I've ironed out some more bugs in portacle today. There should be a new release tomorrow.
<pjb>
Notably, before portable there has already been 2 or 3 other such things for CL…
<comborico1611>
pjb: Yes, but as an active contributor to assisting beginners, I'm just telling you what my experience has been. You listed your recommendation for newbies (emacs+paredit+slime).
<Shinmera>
pjb: None of them were close to as complete as Portacle though!
axg` has joined #lisp
Ven`` has joined #lisp
<comborico1611>
pjb: I've never seen nor seen a reference to that website. Sometimes #lisp is going to be the first place a person goes to for info. Anyways, I'm not trying to debate what's the best resource avenue for a beginner, I'm just telling you what I think as a beginner. And that is Portacle is the best thing out there for the growth of Common Lisp.
<pjb>
comborico1611: but don't tell it to me, since I'm a seasonned lisper. Tell it to your fellow newbies, by updating this cliki page.
axg has quit [Ping timeout: 256 seconds]
<pjb>
It's when you're learning that you know best what information you need to learn. Therefore it's now that you should document that, leavining little bread crumbs on cliki.net
<comborico1611>
pjb: I see.
<pjb>
And furthermore, have fun browsing this wiki, there is a lot of interesting informations and links.
<comborico1611>
pjb: Yeah, I think it is really adequate as it is. My verbage would sound very fanatical/fan-boy. The first subject of the page is Portacle, so that's on target.
pierpa has joined #lisp
<comborico1611>
But I'll be sure to check it out more.
<comborico1611>
The book section is gold.
<comborico1611>
That's exactly what is needed.
<pjb>
Ah good, so it's up to date.
sindan has quit [Quit: Leaving]
Kaisyu has joined #lisp
grublet has quit [Ping timeout: 248 seconds]
Ven`` has quit [Ping timeout: 248 seconds]
Bicyclidine is now known as Bike
Amplituhedron has quit [Ping timeout: 256 seconds]