rumbler31 has quit [Remote host closed the connection]
orivej has joined #lisp
stereosphere has joined #lisp
dale has quit [Quit: dale]
Kundry_Wag has joined #lisp
slyrus_ has quit [Quit: Leaving]
Kundry_Wag has quit [Ping timeout: 268 seconds]
MetaYan has joined #lisp
slyrus has joined #lisp
<margaritamike>
how could i use lquery to get comment node
Lycurgus has quit [Quit: Exeunt]
CommanderViral is now known as cameronbroe
cameronbroe is now known as CommanderViral
ebrasca has joined #lisp
marvin2 has joined #lisp
jprajzne has joined #lisp
Kundry_Wag has joined #lisp
anewuser has quit [Ping timeout: 268 seconds]
Inline has quit [Quit: Leaving]
Kundry_Wag has quit [Ping timeout: 258 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 258 seconds]
micro has quit [Ping timeout: 250 seconds]
<splittist>
good morning
micro has joined #lisp
esrse has joined #lisp
mange has quit [Quit: Quittin' time!]
makomo has joined #lisp
ebrasca has quit [Ping timeout: 244 seconds]
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
mingus has quit [Remote host closed the connection]
pierpal has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
schweers has joined #lisp
Kundry_Wag has quit [Ping timeout: 268 seconds]
dented42 has joined #lisp
xrash has quit [Ping timeout: 246 seconds]
Kundry_Wag has joined #lisp
dented42 has quit [Ping timeout: 244 seconds]
Kundry_Wag has quit [Ping timeout: 245 seconds]
p9fn has quit [Ping timeout: 252 seconds]
nirved has quit [Read error: Connection reset by peer]
nowhere_man has quit [Ping timeout: 252 seconds]
varjag has joined #lisp
notzmv has quit [Ping timeout: 244 seconds]
notzmv has joined #lisp
scymtym has quit [Remote host closed the connection]
drot has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
quazimodo has quit [Ping timeout: 268 seconds]
dented42 has joined #lisp
varjag has quit [Ping timeout: 268 seconds]
nowhere_man has joined #lisp
orivej has quit [Ping timeout: 258 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 246 seconds]
dented42 has quit [Ping timeout: 245 seconds]
nirved has joined #lisp
orivej has joined #lisp
space_otter has quit [Remote host closed the connection]
nirved is now known as Guest64365
nirved has joined #lisp
mrcom has quit [Read error: Connection reset by peer]
Guest64365 has quit [Ping timeout: 252 seconds]
stereosphere has quit [Read error: Connection reset by peer]
<ogamita>
minion: memo for jmercouris: sorry, I made a mistake in the commands for sedit. I'll talk to you this evening.
<minion>
Remembered. I'll tell jmercouris when he/she/it next speaks.
mrcom has joined #lisp
heisig has joined #lisp
beach has quit [Disconnected by services]
beach has joined #lisp
refpga has joined #lisp
megalography has joined #lisp
ebrasca has joined #lisp
Kundry_Wag has joined #lisp
zotan has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
status402 has joined #lisp
varjag has joined #lisp
zotan has joined #lisp
Kundry_Wag has quit [Ping timeout: 268 seconds]
iovec has quit [Quit: Connection closed for inactivity]
gxt has quit [Quit: WeeChat 2.3]
themsay has quit [Ping timeout: 250 seconds]
themsay has joined #lisp
amerlyq has joined #lisp
themsay has quit [Ping timeout: 246 seconds]
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
themsay has joined #lisp
kajo has quit [Ping timeout: 268 seconds]
refpga has quit [Ping timeout: 268 seconds]
refpga has joined #lisp
dented42 has joined #lisp
pierpal has joined #lisp
scymtym has joined #lisp
dddddd has joined #lisp
rumbler31 has joined #lisp
status402 has quit [Quit: status402]
status402 has joined #lisp
ecraven has quit [Ping timeout: 264 seconds]
ecraven has joined #lisp
Kaisyu has quit [Quit: Connection closed for inactivity]
dented42 has quit [Ping timeout: 258 seconds]
engblom has joined #lisp
<engblom>
Do you know about any tiling (dynamically, not manually) written in any lisp dialect (CL, Scheme, Clojure, whatever)?
<engblom>
Something that would basically be a clone of xmonad or dwm...
<engblom>
tiling window manager, I meant.
yangby has joined #lisp
yangby has quit [Client Quit]
<beach>
Isn't StumpWM such a thing?
yangby has joined #lisp
yangby has quit [Client Quit]
<beach>
"StumpWM is a tiling, keyboard driven X11 Window Manager written entirely in Common Lisp."
<engblom>
beach: It is a manual tiling window manager. When you create a new window, it does not automatically shrink all other windows to dynamically use all of screen space available.
<engblom>
In the same way, when you close one window, the rest are not growing to use all space.
<engblom>
Most tiling window managers are dynamic, which means this all happens automatically.
<ogamita>
engblom: perhaps the exwm emacs X window manager?
Kundry_Wag has joined #lisp
<engblom>
ogamita: I have to check out, even though I kind of dislike emacs itself
<engblom>
It looks like my main issue with emacs also appears when using exwm.
<engblom>
I was using emacs for IRC for a long time, but I got tired of the complete lockout while emacs was waiting for something to happen.
Kundry_Wag has quit [Ping timeout: 250 seconds]
<ebrasca>
engblom: You can modify stumpwm.
rumbler31 has quit [Remote host closed the connection]
m00natic has joined #lisp
<engblom>
ebrasca: To add that feature I would have to put more work into it than what it is worth. Xmonad already got all the features I want. I was just thinking that if I had a wm written in any lisp dialect it would have a bit of smaller foot print. Xmonad requires GHC (the Haskell compilator) and the whole system takes more than a Gb of space.
hectorhonn has quit [Quit: Page closed]
heisig has quit [Remote host closed the connection]
<beach>
I think you should go for Xmondad.
ebrasca has quit [Remote host closed the connection]
<beach>
Xmonad.
<beach>
Sheesh.
<engblom>
beach: It is what I am using and probably I will stay with it if I do not find a smaller alternative.
ebrasca has joined #lisp
pierpal has quit [Ping timeout: 245 seconds]
nowhere_man has quit [Ping timeout: 245 seconds]
<beach>
engblom: A GB of disk space only costs a few cents. Might not be worth worrying about.
<ebrasca>
engblom: I have 30TiB of space, 1GiB is small.
<no-defun-allowed>
Depends on the storage medium.
themsay has quit [Ping timeout: 246 seconds]
<ebrasca>
no-defun-allowed: Do you mean someting like sd or ssd?
<no-defun-allowed>
SSDs are closer to 30c/gb, and slightly higher still if they use PCIe interconnections.
<ebrasca>
I don't undestand why someone is going to get SSDs instead of 16TiB HDD.
heisig has joined #lisp
<no-defun-allowed>
I only have 120GB of flash storage, of which 40GB aren't used by games, the OS, and LaTeX, roughly in order of storage size.
<no-defun-allowed>
SSDs are almost a magnitude faster, and are even faster with random reads.
Necktwi has joined #lisp
<ebrasca>
mmm what about more RAM?
<no-defun-allowed>
If you can afford it while price fixing is happening, sure.
<ebrasca>
I only have 64 GiB of RAM...
<ebrasca>
ddr4
<no-defun-allowed>
My dad got 16GB of memory a few years back for $100. The single 8GB stick I have costed $80.
<no-defun-allowed>
Oh, I thought beach had the record for most RAM in #lisp.
<beach>
I don't have very much.
<no-defun-allowed>
Didn't you say you had 32GiB?
<beach>
Yes.
<shka__>
it is plenty
<no-defun-allowed>
The "10GB heap" you suggest in the SICL readme is more memory than most people at my school have.
<shka__>
as much as you can stick into "ordinary" pc
<beach>
But many #lisp people are professionals and work for good companies, so I imagine many will have plenty more.
<no-defun-allowed>
That's true.
<shka__>
heh
esrse has quit [Quit: 안녕히계세요]
<no-defun-allowed>
"Whoops, I accidentally ran my parallel Lisp universe simulator on our work servers."
<shka__>
I program in C++ sometimes, needing that much to compile is not out of ordinary.
<shka__>
but SBCL has troubles with very large heaps
<no-defun-allowed>
That said, I do think SSDs are often a better performance boost, unless you have to fit your entire dataset in memory for some reason.
<shka__>
not sure why but when given 70GB of heap it will loose invariant frequently
<no-defun-allowed>
I think many of us would volunteer to test that.
<no-defun-allowed>
(Not as many would be actually testing it, be careful. ;)
<no-defun-allowed>
In perspective, a good 250gb SSD goes for about US$50, which is as much as a physical copy of SICP, and a decent 1tb SSD is only a bit more than (the book) ANSI Common Lisp. I don't think it's a waste of money.
ebrasca has quit [Read error: No route to host]
ebrasca has joined #lisp
Kundry_Wag has joined #lisp
<ebrasca>
Do you have some recomendation to read for making API design?
<beach>
So for file systems, it seems like you should come up with a bunch of operations that are common to all kinds of file systems, and then for each special version, figure out what is special about it and define additional operations for that.
<ebrasca>
beach: Thank you! I going to read your pdf.
<beach>
The only protocol I see in that code is the Gray streams protocol, which you didn't design.
<ebrasca>
I have put someting from 3 files to 1 file.
<ebrasca>
beach: I have implemented this Gray streams methods.
<beach>
Yes, but it is an existing protocol. You were asking about API design.
<beach>
This one is already designed.
orivej has joined #lisp
<ebrasca>
mmm do you think I have only refactor it?
<shka__>
i think that you have unusual notion of "api design"
<beach>
ebrasca: I don't think I could tell from the little knowledge of it that I have.
themsay has joined #lisp
<ebrasca>
Maybe I am stupid.
<beach>
What makes you say that?
<ebrasca>
beach: Read my ext and fat32.
<shka__>
ebrasca: i think that it would be beneficial to focus on specific issue
<shka__>
for instance: what exactly is wrong with your code?
<ebrasca>
beach: I don't know how to manage diferent verisions of file systems.
<ebrasca>
shka__: ^
<shka__>
ebrasca: sure, so what beach would recommend is to ask yourself what is the common set of operations that MUST be implemented by each of those systems?
<ebrasca>
Like superblock from ext2 vs superblock from ext4.
<ebrasca>
I don't know.
<ebrasca>
I have not yet lean btrfs...
<shka__>
this maybe the core problem
<beach>
ebrasca: It doesn't sound like your problem is API design.
* ebrasca
don't undestand.
<shka__>
ebrasca: it may be a good idea to make notes and list all functions that allow to "use" file system
<shka__>
then, extract only those that can't be implemented as combinations of other functions
<shka__>
or in terms of...
<ebrasca>
How to you manage with diferent version of one structure?
<beach>
ebrasca: I take "API design" to mean coming up with a bunch of names and signatures of operations that operate on a set of types. The problems you describe have more to do with implementation techniques, it seems.
<shka__>
ebrasca: generic functions are a good thing to use
Zaab1t has joined #lisp
pierpal has joined #lisp
* scymtym
has the impression understanding the domain and the requirements should be the first step here. i.e. which concepts are essential, which are accidental (filesystem, file, directory vs. superblock, inode, etc.)? what should a user of the filesystem module be able to do with it?
<beach>
ebrasca: I guess you don't. You use a different structure for each version.
kajo has quit [Ping timeout: 268 seconds]
<ebrasca>
beach: But if I have different structure for each version , do I need to duplicate other functions?
<beach>
ebrasca: I agree with scymtym, and it looks like you are just asking for help implementing this thing. Which is fine, but doing that would require everything that scymtym says, which is a lot of work. So I don't think I can give you any hints in just a few minutes of looking at your code. I personally don't have time for such an investment, but others might.
kajo has joined #lisp
gxt has joined #lisp
* ebrasca
probably don't undestand what he is asking for.
<beach>
That makes things even harder. :)
gxt has quit [Client Quit]
<schweers>
shka__: what problems do you have with large heaps in SBCL?
<ebrasca>
beach: I am thinking to try tu use classes instead of structures and see what come from it.
<schweers>
I use a heap size of 250000 with SBCL, plus mmap quite large files.
<beach>
ebrasca: OK.
<shka__>
schweers: GC looses invariants
<scymtym>
ebrasca: sorry if i confused you. my observation was that you seem to be viewing the problem with the technical realizations of different filesystems as the starting point. my suggestion is, for the API design part, to focus on what somebody using your filesystem module would need from it
<shka__>
schweers: any protips?
<schweers>
I don’t know what you mean by that :(
<shka__>
you never got GC invariant lost! in sbcl?
<schweers>
As I don’t know what it is, is might very well be that way, yes.
<shka__>
hmmmm
<shka__>
i thought that everyone has this problem
<shka__>
could you tell me please what version of sbcl are you using?
<schweers>
Is the OS relevant? I do this on linux
<shka__>
linux as well
<shka__>
i also compiled sbcl from source
<schweers>
SBCL 1.3.14.debian
<shka__>
hmmm
<shka__>
i have newer
<shka__>
maybe some regression happend?
<schweers>
I have a more recent version on my development machine, but there I only use heapsizes of 20000 or so.
<shka__>
i will check older version and see what happens
<schweers>
I’l like to know what you find
<shka__>
sure thing
Kundry_Wag has joined #lisp
<schweers>
On the other hand, I could try a newer version of SBCL. As far as I know, SBCL can be used without being installed, so I don’t have to mess around in the system.
* ebrasca
is afk.
pierpal has quit [Quit: Poof]
<shka__>
yes
pierpal has joined #lisp
<schweers>
I’ve got a job running at the moment, so I can’t try something for a few days.
Kaisyu has joined #lisp
<shka__>
schweers: no problem, i am on smaller heap currently as well
<schweers>
shka__: does your problem sometimes come up for no apparent reason? I.e: how do you deal with it?
<shka__>
well, it happens during garbage collection, and i think that i have reliable way to trigger it (allocate (and retain some) lots of standard instances while asking GC to perform full sweep multiple times in the meantime) but I don't know exactly what is causing it
emar has joined #lisp
<shka__>
it seems to work fine on 8GB heap, but when i crank it up to 80GB things start to break
<schweers>
So it just plain doesn’t work on larger heaps for you?
<shka__>
it kinda does, as long as i don't allocate large number of standard-objects
<shka__>
i am kinda surprised that you never expirienced this error yourself, googling sbcl gc invariant lost yields plenty of results
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
<schweers>
Ah, one problem I do have, which may or may not be my own fault: I have several asdf systems which implement some task or other, which represent different stages of processing. I have a small wrapper application which depends on said systems and runs those stages given on the command line. Sometimes when processing a large dataset, GC fails to reclaim memory after one or more steps have run. When I then simply restart
<schweers>
stages out which were already complete, it works. As far as I can tell, I don’t hold onto anything which might be large, but as I am not perfect, this may be my own wrongdoing. At any rate, have you experienced something similar?
<schweers>
I’m pretty sure that I didn’t read anything about an invariance being lost.
<shka__>
hm, ok
<schweers>
I have such a job running, I’ll check if it does indeed report something like your problem
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<shka__>
well, i can't figure out what to do with it so it is pretty much whatever to me ;-)
xkapastel has joined #lisp
<scymtym>
shka__: you could try talking to dougk about it (unless you already did)
<shka__>
i don't know how to debug this
<shka__>
like, at all
kajo has quit [Ping timeout: 258 seconds]
status402_ has joined #lisp
status402 has quit [Read error: Connection reset by peer]
<beach>
Maybe you don't have to. If you can make it easy to reproduce, that might be good enough.
gxt has joined #lisp
<shka__>
beach: i will investigate it, but this is company machine
<ogamita>
engblom: indeed. I use 3 emacsen: one for gnus, one for erc, and one for development.
dented42 has joined #lisp
iovec has joined #lisp
status402_ has quit [Quit: status402_]
<ogamita>
that's a good idea. I will sell SSDs, and deliver them loaded with lisp books.
<shka__>
lisp guerilla
scymtym has quit [Ping timeout: 268 seconds]
dented42 has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 250 seconds]
<ogamita>
ebrasca: I would say the most important feature of an API is for it to be "introspective". ie. that you may use it to query and get all the meta-information you need to use it even if you don't know it a-priori. This includes that no API call may crash, whatever the arguments passed or not. Basically, the opposite of FFI.
<ogamita>
in the case of a "file system" API, one should be able to use the API equaly easily to access any and all file systems, whatever their quirks and idiosyncrasies. (eg. use logical pathnames, not physical pathnames ;-) )
status402 has joined #lisp
<ogamita>
schweers: I would assume that when you have a lot of memory the GC would feel much less pressured to collect garbage… So garbage would accumulate.
<schweers>
That may be the case, but why does SBCL then not run the GC when memory becomes tight? If I remember correctly, SBCL reports that it could not allocate any memory.
<ogamita>
Ok, the point is that some GC algorithms need temporary memory to work. Probably this temp space is proportional to the garbage (or perhaps the live set). In any case, they may have sized it hard wired for expected heap sizes, not for 10 times that amount. Perhaps you can play with sbcl command line options to leave more space available for this temp space?
orivej has joined #lisp
<ogamita>
(I'm just daydreaming here, I don't know any details).
undiscovered has quit [Remote host closed the connection]
undiscovered has joined #lisp
refpga has quit [Read error: Connection reset by peer]
refpga has joined #lisp
sloanr has joined #lisp
meepdeew has joined #lisp
Mr-Potter has joined #lisp
sword has joined #lisp
m00natic has quit [Remote host closed the connection]
shka_ has joined #lisp
Kaisyu has quit [Quit: Connection closed for inactivity]
themsay has quit [Ping timeout: 245 seconds]
ckonstanski has joined #lisp
CrazyEddy has joined #lisp
CrazyEddy has quit [Remote host closed the connection]
ntbre has quit [Quit: ntbre]
CrazyEddy has joined #lisp
JetJej has quit [Quit: [Quit]]
Arcaelyx has joined #lisp
terpri_ has quit [Ping timeout: 258 seconds]
sauvin has quit [Read error: Connection reset by peer]
ntbre has joined #lisp
terpri has joined #lisp
ntbre has quit [Client Quit]
refpga has quit [Ping timeout: 268 seconds]
refpga has joined #lisp
cqs has joined #lisp
_atomik has joined #lisp
hiroaki has quit [Ping timeout: 268 seconds]
JetJej has joined #lisp
stereosphere has joined #lisp
Khisanth has quit [Read error: Connection reset by peer]
amerlyq has quit [Quit: amerlyq]
cqs has quit [Quit: cqs]
xrash has joined #lisp
hiroaki has joined #lisp
cqs has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
Khisanth has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
akr has joined #lisp
<akr>
Hello, could anyone tell me roughly how painful would be updating a project from SBCL 1.1.14 to 1.4.5? This project has around a 100 dependencies.
<hjudt>
did anyone ever have any reason to adjust sbcl --control-stack-size? default is 2mb
<dlowe>
akr: probably not very
<Josh_2>
hjudt: I had to expand to 10mb but I can't remember why :(
<dlowe>
too much recursion, presumably
<Josh_2>
Yeh probably some noob stuff
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
<Bike>
akr: if the project doesn't use sb-ext i imagine it would go pretty smoothly. if it does (or other sbcl specific packages) you might need to make a few adjustments.
<aeth>
There might be bug fixes in obscure corners of elaborate parts of the language like FORMAT or LOOP that accidentally didn't follow the standard exactly.
<aeth>
So if your program already runs on different CLs there's probably going to be fewer surprises.
<White_Flame>
akr: if you update your dependencies as well (which is likely where SBCL specifics might lie, in back-end implementations), I doubt you'll have any major issues at all
<aeth>
in particular, things that might affect you are "incompatible change" and "minor incompatible change"
<verisimilitude>
A properly written Common Lisp program should face no issues in this situation, akr.
<pjb>
akr: yes, that's about it: if you wrote (or use) code that is accidentally not conforming, but just worked so far, and the implementation changes to become more conforming, you can have to do some maintenance. Also, if you used internal API, but then it was your fault, you've always been told not to use internal APIs >:-}>
<aeth>
an example from 1.3.14: "minor incompatible change: the SB-PCL walker no longer recognizes macros expanding into a DECLARE expression. This is not a language change, since ANSI forbids such usage (X3J13 issue DECLARE-MACROS:FLUSH)."
<verisimilitude>
It's good practice to test your code across multiple implementations, akr, not just to test for conformance, but also because different implementations perform different optimizations and inspections and so you can realize smaller issues in this way as well.
<aeth>
pjb: Never use internal APIs *directly*. If you could never use them then CFFI, bordeaux-threads, etc., couldn't work. Just make stuff like that the responsibility of some library author to maintain, if possible.
<aeth>
(And if not possible, become the library author and put it in a library like that.)
<akr>
okay, so I thought I'd give it a try, but I'm getting a build error that I'm not sure how to debug
<akr>
The symbol "*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*" is not external in the ASDF/FIND-SYSTEM package.
<aeth>
ASDF ships with the implementation and so that's a newer version of ASDF with a newer ASDF API.
<akr>
the problem is this is I don't know where this symbol is accessed
<_death>
grep
<akr>
tried that, not in my project or any of the libs
<_death>
the error's backtrace
gxt has quit [Ping timeout: 245 seconds]
<akr>
hmm, buildapp doesn't really offer one
<_death>
also the error message may also indicate the location
varjag has joined #lisp
<akr>
yeah, but it says "dumper-2SKVI5f7.lisp"
<akr>
why I'm guessing is some file where it concatenates all the sources or something
<akr>
which*
<_death>
so you need to look into the build process
<akr>
hm, it's fairly straightforward and I'm not really sure how to make it better
<aeth>
akr: have you tried loading the system from quicklisp to see if you get the same error? (unfortunately, you might have discovered a bug in buildapp, though)
<_death>
so perform these steps without buildapp
<akr>
quicklisp is unfortunately not used in this project
<akr>
like, at all
<aeth>
akr: Unless I'm misunderstanding what the "--load-system" means in buildapp, there's an ASDF system, so you could load it via Quicklisp in SLIME with (ql:quickload :lisperator) if it knew where to find lisperator
<White_Flame>
I've manually copied libraries from quicklisp into non-ql builds. if you have >100 it might be a lot, but the directories under QL are independently usable, if you want the latest versions whose inter-dependencies are tested
_atomik has quit [Quit: Leaving]
<aeth>
You could also try asdf loading.
<akr>
ok, thanks for the tips everyone. I'll go play with it some more.
<aeth>
akr: are you on the latest version of buildapp?
<akr>
probably not, cause it's ubuntu
<akr>
version is 1.5.6
<akr>
oh that looks like latest
Kundry_Wag has joined #lisp
<Xach>
quicklisp bundling is fun also
hiroaki has quit [Ping timeout: 264 seconds]
<Xach>
(i don't have any context sorry)
hiroaki has joined #lisp
hiroaki has quit [Max SendQ exceeded]
hiroaki has joined #lisp
hiroaki has quit [Max SendQ exceeded]
hiroaki has joined #lisp
pierpal has joined #lisp
hiroaki has quit [Ping timeout: 250 seconds]
Kundry_Wag has quit [Remote host closed the connection]
ravndal has quit [Quit: WeeChat 2.3]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
ravndal has joined #lisp
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
_atomik has joined #lisp
ealfonso has quit [Disconnected by services]
hiroaki has joined #lisp
undiscovered has quit [Ping timeout: 256 seconds]
undiscovered has joined #lisp
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
Essadon has joined #lisp
ntbre has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
nowhere_man has joined #lisp
karlosz has joined #lisp
nowhere_man has quit [Remote host closed the connection]
nowhere_man has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
hjudt has quit [Ping timeout: 258 seconds]
Josh_2 has joined #lisp
karlosz has quit [Client Quit]
<cqs>
hello, is it possible to store something that my function returns into a variable?
<cqs>
something=list
<dlowe>
you mean like (let ((variable (my-function)))) ...)?
<cqs>
yes
<dlowe>
or (setf something (my-function))?
<dlowe>
perhaps you'd like to join #clschool :)
<cqs>
actually i'm not sure what is the difference between those 2
hjudt has joined #lisp
<cqs>
i'm an empty page when it comes to lisp
<aeth>
cqs: the let creates a new binding, but setf in this context (or setq in general) sets an existing binding
<cqs>
dlowe: definitelly :)
karlosz has joined #lisp
<aeth>
cqs: so the let is basically "int foo;" or "int foo = 42;" and the setf is basically "foo = 42;"
<aeth>
except there's no type there so it's more like a language that uses "var" or "local" or even "let" rather than "int"
<cqs>
thx
shka_ has quit [Remote host closed the connection]
karlosz has quit [Client Quit]
rumbler31 has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
xrash has quit [Ping timeout: 258 seconds]
Josh_2 has joined #lisp
isBEKaml has joined #lisp
isBEKaml has left #lisp [#lisp]
JetJej has quit [Ping timeout: 252 seconds]
JetJej has joined #lisp
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
rumbler31 has quit [Remote host closed the connection]
mange has joined #lisp
karlosz has quit [Client Quit]
permagreen has joined #lisp
hiroaki has quit [Ping timeout: 250 seconds]
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
meepdeew has quit [Remote host closed the connection]
refpga has quit [Ping timeout: 250 seconds]
refpga has joined #lisp
undiscov1 has joined #lisp
undiscovered has quit [Ping timeout: 256 seconds]
undiscov1 has quit [Remote host closed the connection]
undiscov1 has joined #lisp
Bike has quit []
<Fade>
minion: tell cqs about PCL
<minion>
cqs: please see PCL: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
mrcom has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
sjl_ has quit [Ping timeout: 246 seconds]
Kundry_Wag has quit [Ping timeout: 250 seconds]
ntbre has quit [Quit: ntbre]
ckonstanski has quit [Quit: bye]
undiscov1 has quit [Ping timeout: 256 seconds]
LiamH has quit [Quit: Leaving.]
undiscov1 has joined #lisp
sjl has quit [Quit: WeeChat 2.2-dev]
mrcom has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life_ is now known as Lord_of_Life
JetJej has quit [Quit: [Quit]]
adamantium has joined #lisp
Bike has joined #lisp
ntbre has joined #lisp
varjag has quit [Ping timeout: 250 seconds]
refpga has quit [Ping timeout: 245 seconds]
refpga has joined #lisp
sjl has joined #lisp
akoana has joined #lisp
refpga has quit [Read error: Connection reset by peer]