rumbler31 has quit [Remote host closed the connection]
dvdmuckle has quit [Quit: Bouncer Surgery]
dvdmuckle has joined #lisp
Essadon has quit [Quit: Qutting]
terpri has joined #lisp
shifty has joined #lisp
Arcaelyx has quit [Ping timeout: 250 seconds]
semz has quit [Ping timeout: 276 seconds]
patche has joined #lisp
jinkies has quit [Ping timeout: 250 seconds]
patche has quit [Client Quit]
patche has joined #lisp
patche has quit [Client Quit]
slac-in-the-box has quit [Ping timeout: 250 seconds]
rumbler31 has joined #lisp
rumbler31 has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 244 seconds]
kajo has joined #lisp
ryan_vw has joined #lisp
Guest13389 has quit [Ping timeout: 245 seconds]
warweasle has quit [Quit: night]
patche has joined #lisp
patche has quit [Client Quit]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
robotoad has quit [Quit: robotoad]
Guest13389 has joined #lisp
rumbler31 has joined #lisp
rumbler31 has quit [Ping timeout: 252 seconds]
robotoad has joined #lisp
patche has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
nullniverse has quit [Remote host closed the connection]
nullniverse has joined #lisp
edgar-rft has joined #lisp
Arcaelyx has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 272 seconds]
pjb has joined #lisp
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
dddddd has quit [Remote host closed the connection]
<Ober>
well the cl spec predates the use of roman letters
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 268 seconds]
pjb has quit [Ping timeout: 252 seconds]
smokeink has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 252 seconds]
smokeink has joined #lisp
<oni-on-ion>
o_o... does it? =)
dale has joined #lisp
steiner has quit [Remote host closed the connection]
pjb has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
<gendl>
predates electricity.
xificurC has quit [Remote host closed the connection]
<no-defun-allowed>
predates life on earth
Bike has quit [Quit: Lost terminal]
igemnace has quit [Quit: WeeChat 2.2]
<aeth>
predates the universe
ryan_vw has quit [Ping timeout: 252 seconds]
<gendl>
predates the current life of Brahma
<gendl>
the cl spec was spoken most recently by Lord Krishna to Arjuna on the battlefield of Kurukshetra. But it was spoken millions of times before that.
<gendl>
had been* spoken
pjb has quit [Ping timeout: 252 seconds]
igemnace has joined #lisp
<gendl>
Before it was finally written down for our puny modern brains to be able to grasp, the cl spec was recited in rythmic triṣṭubh meter (which provides a kind of built-in verbal checksum) and carried by this spoken tradition from master to disciple throughout the eons.
ryan_vw has joined #lisp
dale has quit [Quit: dale]
sauvin has joined #lisp
Kundry_Wag has joined #lisp
ealfonso has quit [Disconnected by services]
ealfonso` has joined #lisp
shka_ has joined #lisp
ealfonso has joined #lisp
pjb has joined #lisp
<ealfonso`>
is anyone aware of something like a third-party oauth plugin for hunchentoot?
<ealfonso`>
actually, I can reuse another project's oauth flow for google sign in
Kundry_Wag has quit [Ping timeout: 252 seconds]
vlatkoB has joined #lisp
igemnace has quit [Quit: WeeChat 2.2]
kajo has quit [Ping timeout: 250 seconds]
pjb has quit [Ping timeout: 252 seconds]
Lycurgus has joined #lisp
ggole has joined #lisp
kajo has joined #lisp
rumbler31 has joined #lisp
rumbler31 has quit [Ping timeout: 244 seconds]
kajo has quit [Ping timeout: 252 seconds]
pjb has joined #lisp
eminhi has joined #lisp
<Shinmera>
ealfonso`: North allows you to implement oauth 1.0a client and server flows. For oauth 2 you're on your own.
<beach>
Good morning everyone!
<shka_>
good morning beach
nullniverse has quit [Quit: Undertaking stack overflow prevention]
angavrilov has joined #lisp
<no-defun-allowed>
morning beach
<no-defun-allowed>
happy saturday c:
shifty has quit [Ping timeout: 252 seconds]
<beach>
Thanks.
<beach>
A day to take it easy.
<no-defun-allowed>
indeed
<beach>
This is mid October in Bordeaux, but it is going to be 30°C today. I believe it's a record.
<shka_>
insane
<no-defun-allowed>
it actually got warm today in melbourne
<nyingen_>
We are getting blasted with polar wind here in NZ
<nyingen_>
It *was* spring 3 days ago but now winter is back all of a sudden
<beach>
Oh, a kiwi! Great! I spent a year in Auckland.
<nyingen_>
Well, "kiwi". I'm a recent immigrant from USA
<beach>
Oh!
<beach>
Still.
<nyingen_>
how was Auckland? I've only spent a few days there here and there
easye has joined #lisp
<beach>
Great place. Not the architecture so much, but the people, the food, etc.
SaganMan has joined #lisp
<nyingen_>
Yeah, it's an interesting city
<no-defun-allowed>
has anyone considered running Lisp on a MIMD/VLIW processor?
ryan_vw has quit [Ping timeout: 246 seconds]
galdor has quit [Ping timeout: 250 seconds]
<beach>
nyingen_: Where are you located?
<shrdlu68>
Cloudy in Nairobi.
<no-defun-allowed>
if everything is sufficiently unboxed, i think a lot could be parallelised on a MIMD system.
<beach>
no-defun-allowed: It's iffy. Common Lisp is a very sequential language.
<no-defun-allowed>
that's true
<nyingen_>
wow quite a diversity of locations here
<nyingen_>
beach: I'm near Tauranga, in the Bay of Plenty
<beach>
Nice!
<nyingen_>
You are in France?
<beach>
Yes.
<White_Flame>
(in Nice?)
<beach>
Heh.
nika has joined #lisp
<White_Flame>
no-defun-allowed: when it comes to custom lisp processors, assistance with GC, numeric type dispatch for fixnum vs bignum, and direct support for tag bits would be most helpful
<no-defun-allowed>
that's true
pjb has quit [Ping timeout: 252 seconds]
<beach>
I don't think a custom Lisp processor could compete with a good implementation on stock hardware these days.
<White_Flame>
that, too
<White_Flame>
it would basically be an exercise in reducing the impedance mismatch between lisp low levels and the target asm
<beach>
Such a processor would have to be as fast as the fastest microprocessors today, and that would cost a fortune to make.
<no-defun-allowed>
it'd be less difficult to write a good implementation though
<Shinmera>
You're just shifting the difficulty onto making the processor
<Jachy>
For certain workloads you might be able to make a non von-neumann design in an FPGA that does pretty well even with a MHz clock rate...
<Shinmera>
And I'd argue that solving things efficicently in silicon is harder than in software
<no-defun-allowed>
maybe
<beach>
Jachy: I seriously doubt that.
<no-defun-allowed>
well, per clock FPGAs can be very performant.
pjb has joined #lisp
asarch has quit [Quit: Leaving]
<no-defun-allowed>
embarrasingly parallel workloads shine on FPGAs for example
<White_Flame>
x86 can do many instructions per clock
<White_Flame>
so that makes up for a lot of it, plus runs at a very fast clock
<shka_>
no-defun-allowed: it is not practical for everything else then gigadollar corpo running ultra specific piece of software
<shka_>
*anything else
kushal has quit [Ping timeout: 256 seconds]
<no-defun-allowed>
also, a lisp-optimised machine might also sidestep issues we have seen in the past but i'm speculating on that
<White_Flame>
there isn't much of a barrier to entry for FPGA, though
<no-defun-allowed>
haha, speculation.
<White_Flame>
so as a hobby exploration it could be doable
kushal has joined #lisp
<Jachy>
The last time I seriously looked at it was this project, I don't remember the details very well though. (It was also Haskell.) https://www.cs.york.ac.uk/fp/reduceron/
<beach>
Jachy: My guess is that the mismatch between Haskell and stock hardware is much greater than the one between Common Lisp and stock hardware.
Cymew has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
<beach>
So it might be more beneficial to run Haskell on a dedicated processor.
<shrdlu68>
Doesn't defclass define a type of the same name?
<beach>
It does.
<White_Flame>
a class is a sort of type
<shrdlu68>
Ah, I was in the wrong package.
Cymew has quit [Ping timeout: 250 seconds]
dim has quit [Ping timeout: 272 seconds]
Cymew has joined #lisp
<aeth>
afaik a class is a type but a type isn't necessarily a class because you can have types like (integer 0 *) or (simple-array (unsigned-byte 8) (42))
Roy_Fokker has quit [Read error: Connection reset by peer]
<aeth>
at the very least, I've never had a problem with using classes (structure or standard) where types go (defstruct creating an array obviously doesn't count: that doesn't create a type even though it could and probably should)
semz has joined #lisp
dim has joined #lisp
Cymew has quit [Ping timeout: 252 seconds]
<aeth>
The only thing you'd want in custom Lisp hardware is unboxed (unsigned-byte 64), (signed-byte 64) and double-float imo (and other type optimizations).
Cymew has joined #lisp
Kundry_Wag has joined #lisp
abbe has quit [Remote host closed the connection]
mood has quit [Ping timeout: 272 seconds]
abbe has joined #lisp
Cymew has quit [Ping timeout: 252 seconds]
mood has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
Cymew has joined #lisp
Cymew has quit [Ping timeout: 244 seconds]
shka_ has quit [Quit: Konversation terminated!]
<stylewarning>
aeth: that’s not very imaginative. We can’t make GC better enabled by HW?
<Shinmera>
You can.
Cymew has joined #lisp
<aeth>
stylewarning: but would it be worth it because of the lack of the programmability of it?
<Shinmera>
What
<aeth>
the disadvantage of doing something in the hardware
<semz>
can always go for a middle ground where the HW has some helpers for a software GC on top, iirc that's how symbolics did it
<no-defun-allowed>
type tagging in hardware would be nice
<Shinmera>
You don't implement GC in the hardware. You add features that make GC easier/better.
<stylewarning>
It seems Lisp HW could also improve the function call in Lisp.
<stylewarning>
For example, native hardware schemes for managing cross-function boundaries of data passing, hardware schemes for communicating multiple values (maybe?), ...
<stylewarning>
Anyway I think my point is that Lisp hardware probably can be better than “just unboxed 64-bit integers”
<no-defun-allowed>
non-Lisp hardware just has unboxed 64-bit integers
Cymew has quit [Ping timeout: 268 seconds]
<no-defun-allowed>
or 8, 16 or 32 dependent on your setup
<ggole>
Almost no functions return multiple values, so making that fast wouldn't help you much
<ggole>
And you can (probably) use tricks to make known calls fast anyway without any hardware support
nowhereman_ has quit [Ping timeout: 250 seconds]
<stylewarning>
ggole: but maybe no functions return MV because they’re tricky to make very fast? Who knows
<stylewarning>
ggole : I feel I always have to inline them in order to eliminate the baggage. And then SBCL inserts these CLC instructions for just about EVERY function call and that has to do with MV
<stylewarning>
(I may be misremembering though. Don’t quote me.)
<aeth>
ggole: lots of functions use multiple values
Cymew has quit [Ping timeout: 272 seconds]
tko has joined #lisp
<beach>
stylewarning: There is no particular reason to do it that way, though.
Cymew has joined #lisp
<stylewarning>
I’m sure there is a particular reason, but that reason isn’t canonical. :)
<aeth>
imo there are two reasons why multiple values are not as common as they could be (1) they're not esay to work with (multiple-value-bind is separate instead of (let (((values foo bar baz) (foobar 42))) ...))
<aeth>
and (2) there aren't convenient built-ins for easily working with them (e.g. no multiple-value-map)
<stylewarning>
I want MV to be a low-level construct. MV isn’t a data structure so much as it is a low-level scheme for moving data around between functions
<aeth>
Yes, but you can't do something like multiple-value-map without consing a list via multiple-value-list and thus defeating one of the points of having multiple values, so a lower level implementation could be justified.
SaganMan has quit [Quit: WeeChat 1.6]
<tko>
I just tried to install sbcl via apt-get on Ubuntu, would anyone know why attempting to start up a repl gives me "fatal error encountered in SBCL pid 16302(tid 140737353966144):
<tko>
"
<tko>
can't load .core for different runtime, sorry
<ggole>
If you want multiple values to just be returned in registers, you don't really need hardware for that
<stylewarning>
Well, to be clear, you don’t really need HW for anything. We have perfectly reasonable Lisp implementations on hardware that’s nearly adversarial to Lisp. (:
<ggole>
You just need an implementation with the necessary tricks to do that and still handle redefinition (including redefinition where the number of values returned has changed)
Cymew has quit [Ping timeout: 272 seconds]
<ggole>
Redefinition does make it more difficult.
kajo has joined #lisp
zfree has joined #lisp
<beach>
tko: I suggest you install SBCL from the sourceforge site instead.
<beach>
tko: It seems you have a version mismatch between the .core file and the executable file.
robotoad has quit [Quit: robotoad]
<tko>
ok thanks, luckily I just about to try that so that makes me feel a bit better
Kundry_Wag has joined #lisp
FreeBirdLjj has joined #lisp
Kundry_Wag has quit [Ping timeout: 252 seconds]
heisig has joined #lisp
nowhereman_ has joined #lisp
<tko>
beach: ok that worked, thanks!
<beach>
Great!
random-nick has joined #lisp
sshirokov has quit [Ping timeout: 246 seconds]
DataLinkDroid has joined #lisp
sbryant has quit [Ping timeout: 246 seconds]
oni-on-ion has quit [Ping timeout: 268 seconds]
MichaelRaskin has quit [Ping timeout: 268 seconds]
Lycurgus has quit [Quit: Exeunt]
sbryant has joined #lisp
sshirokov has joined #lisp
orivej has joined #lisp
asymptotically has joined #lisp
shifty has joined #lisp
frodef has joined #lisp
JohnMS has joined #lisp
quazimodo has quit [Ping timeout: 244 seconds]
quazimodo has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
<makomo>
morning
earl-ducaine has joined #lisp
pjb has joined #lisp
<tko>
allo
varjag has joined #lisp
<earl-ducaine>
I just ran into a character syntaxt that I've never encountered before: #.form
<earl-ducaine>
"Read-time value of form " ....effectively a quasi comma you can use inside ordinary quotes, e.g. '(one two #.(+ 1 2))
<earl-ducaine>
(one two 3)
<beach>
That's an interesting description of it.
<earl-ducaine>
Is there ever a good reason to use that syntax?
<beach>
Sure.
ealfonso` has quit [Ping timeout: 252 seconds]
<beach>
Sometimes you want to make clear to the person reading your code what the origin of a constant is.
HerrBlume has joined #lisp
<Shinmera>
For instance: (case something (#.*some-constant* ..) ..)
JohnMS is now known as JohnMS_AWAY
<Shinmera>
since case does not evaluate the cases, you can use read-time evaluation to get the constant in.
<HerrBlume>
CLSQL question: How do i do column aliases using the symbolic sql syntax?
<earl-ducaine>
I'm seeing the usage in xlib.... something like the following:
<earl-ducaine>
Is there any reason to prefer the #. construct to the quasi-quote one?
zfree has quit [Remote host closed the connection]
<beach>
earl-ducaine: With #., the evaluation takes place at read time.
<beach>
earl-ducaine: So there is no run-time cost involved.
<earl-ducaine>
Aha! That makes sense now.
<beach>
earl-ducaine: Here is another one for you #.(exp (* #c(0 1) pi (/ 4)))
nokdoottt has joined #lisp
<earl-ducaine>
My brain is too tired for CL obfustication... the #. I think is the source of trying bug. Periodically, I have to delete the binaries of a file I've compiled, even though the contents of the source file has never changed.
<earl-ducaine>
e.g. in my above example, if the function make-event-mask is changed, the value it produced when *event-mask-alist* was compiled will never get the update in an ordinary asdf build.
<kristof>
I was going to suggest a range check on char-int
Jesin has joined #lisp
<Bike>
your implementation might provide checking for the unicode WSpace property
<emaczen>
it will work 99% of the time for me on OSX and 1% of the time on raspbian
<|3b|>
how does it fail?
<emaczen>
I get a memory access error in local function get-family when evaluating the form (cffi:foreign-slot-value addr '(:struct sockaddr) 'sa-family)
<russellw>
I think I like kristof's solution best. thanks to everyone who replied!
<Shinmera>
it's also not portable but who cares
<|3b|>
what do your struct defs look like?
<|3b|>
also, (cffi:foreign-type-size :pointer)
<|3b|>
(and use cffi to allocate it rather than mixing in some other FFI and manual malloc/free)
<emaczen>
|3b|: ffi is my own code
<|3b|>
ffi:malloc you mean?
<emaczen>
It is just c functions defined with defcfun
<emaczen>
yes
<|3b|>
if so, write a (ffi:with-malloc ... ) macro :)
<emaczen>
|3b|: Yep, I will get to it eventually
* |3b|
would still just use cffi:with-foreign-object (buf :pointer) though
<emaczen>
|3b|: I'll make another paste for my struct definitions
<|3b|>
c code works reliably on both?
jmercouris has quit [Remote host closed the connection]
<emaczen>
The only type difference I am aware of are between sa_family and sin_family
<emaczen>
I forgot to try the c code on my pi. Give me a sec
<emaczen>
yep, C code works fine on my pi too
<|3b|>
hmm, does (get-family (cffi:mem-ref buf :pointer)) work any better?
* |3b|
wouldn't expect it to work at all if that was the problem (or at least give nonsense results), but doesn't look right
<emaczen>
what doesn't look right?
<russellw>
when you don't specify in-package, your symbols are defined in :cl-user, aren't they?
<|3b|>
actually, ignore that
* |3b|
is confusing things
<emaczen>
they are interned in the current package
<russellw>
right, but what is the current package by default?
nowhereman_ has quit [Remote host closed the connection]
<|3b|>
ok, try (setf buf (cffi:mem-ref buf :pointer)) before the loop
nowhereman_ has joined #lisp
<emaczen>
|3b|: That seems to have done it....
<emaczen>
Why?
<|3b|>
i think it was working by luck if it happened to have 0s in the right place after the pointer, since setf buf ... ifa-next would be same as above
<|3b|>
but that happens after first call to get-family, so would depend on what was in memory there
kristof has quit [Ping timeout: 252 seconds]
<|3b|>
in cl you had equivalent of struct ifaddrs** buf; getifaddrs(buf);...
<|3b|>
so first time you were passing pointer to the pointer returned by getifaddrs to the other things
<emaczen>
|3b|: wait, I don't see how I had ** instead of just *
<|3b|>
and buf->ifa_next happens to be the same as *buf, so if it survives the first iteration, it works OK
<|3b|>
well, CFFI doesn't really distinguish
<|3b|>
so you could think of it as struct ifaddrs* buf; getifaddrs(buf); too (minus any warnings from static typing)
<|3b|>
you pass a pointer to getifaddrs, it stores a pointer in the memory pointed to by the passed pointer
<emaczen>
that is what my c code looks like
<|3b|>
you pass &buf in c
<|3b|>
you pass buf in lisp
<emaczen>
Ok
<emaczen>
ahhhh
<|3b|>
cffi tends to have 1 extra layer of pointers than corresponding C code, which can be confusing to get used to :/
* |3b|
supposes you should check for null pointer before that first dereference of buf too
<|3b|>
in case you happen to be on an odd system without even a loopback interface :)
<emaczen>
|3b|: I see the difference between my C code and my Lisp code but I don't quite see why cffi:mem-ref does the trick
<|3b|>
that gets rid of the extra pointer
<emaczen>
|3b|: but I thought I was missing a pointer... since the C code passes the address via & and in my lisp code I just passed the pointer
<emaczen>
I guess it is this:
<emaczen>
getifaddrs expects a struct ifaddrs**
<emaczen>
in CFFI we only give it a :pointer
<|3b|>
well, you could allocate another pointer if you wanted, but doesn't really matter
<emaczen>
so for cffi we have to get rid of an extra pointer because getifaddrs thinks it is a **
<emaczen>
Does that make sense?
moei has quit [Quit: Leaving...]
<|3b|>
something like that
<emaczen>
hah weird
<|3b|>
in C we can make a local variable, and pass a pointer to it, in cl, we can't make a local, so have to allocate the "struct ifaddr*" explicitly
<|3b|>
in C, we can make a local temp pointer to the struct ifaddr*, but in lisp we would have to explicitly allocate that too
<|3b|>
explicitly allocate and then fill
<|3b|>
or we can just allocate a single pointer and use it for both
<|3b|>
adding the extra dereference to your code is the latter
varjag has quit [Ping timeout: 268 seconds]
<|3b|>
actually, all that assigning to buf probably messes up your deallocation
<|3b|>
in both C and lisp
<|3b|>
but more so in lisp since you have 2 allocations (though you never freeifaddrs in lisp)
<oni-on-ion>
same list different pile
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #lisp
graphene has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 272 seconds]
orivej_ has joined #lisp
graphene has joined #lisp
orivej_ has quit [Ping timeout: 246 seconds]
marusich has quit [Ping timeout: 260 seconds]
orivej has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]