smokeink has quit [Remote host closed the connection]
idlus_ has quit [Ping timeout: 256 seconds]
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
idlus_ has joined #lisp
PuercoPop has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
quazimodo has joined #lisp
torbo has joined #lisp
idlus_ has joined #lisp
Folkol has quit [Read error: Connection reset by peer]
campy_fellow has quit [Ping timeout: 255 seconds]
Folkol has joined #lisp
sjl has quit [Quit: WeeChat 2.2-dev]
eschatologist has quit [Excess Flood]
campy_fellow has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
eschatologist has joined #lisp
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
eschatologist has quit [Ping timeout: 258 seconds]
eschatologist has joined #lisp
idlus_ has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
dacoda has quit [Ping timeout: 248 seconds]
eschatologist has quit [Ping timeout: 258 seconds]
eschatologist has joined #lisp
idlus_ has joined #lisp
eschatologist has quit [Excess Flood]
eschatologist has joined #lisp
moldybits has quit [Quit: WeeChat 2.4]
campy_fellow has quit [Ping timeout: 255 seconds]
idlus_ has quit [Ping timeout: 256 seconds]
eschatologist has quit [Excess Flood]
Kundry_Wag has joined #lisp
eschatologist has joined #lisp
moldybits has joined #lisp
caltelt has joined #lisp
Kundry_Wag has quit [Ping timeout: 252 seconds]
campy_fellow has joined #lisp
eschatologist has quit [Ping timeout: 258 seconds]
eschatologist has joined #lisp
idlus_ has joined #lisp
eschatologist has quit [Excess Flood]
eschatologist has joined #lisp
pjb has quit [Ping timeout: 258 seconds]
eschatologist has quit [Ping timeout: 258 seconds]
eschatologist has joined #lisp
karlosz has joined #lisp
q9929t has joined #lisp
Arcaelyx has joined #lisp
pjb has joined #lisp
jameser has joined #lisp
rdh has quit [Remote host closed the connection]
nowhere_man has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
libertyprime has quit [Ping timeout: 246 seconds]
libertyprime has joined #lisp
zotan has quit [Ping timeout: 244 seconds]
eschatologist has quit [Excess Flood]
eschatologist has joined #lisp
zotan has joined #lisp
dieggsy has joined #lisp
q9929t has quit [Quit: q9929t]
Kundry_Wag has joined #lisp
eschatologist_ has joined #lisp
eschatologist has quit [Ping timeout: 258 seconds]
Kundry_Wag has quit [Ping timeout: 245 seconds]
notzmv has quit [Ping timeout: 248 seconds]
mindCrime_ has quit [Ping timeout: 245 seconds]
elderK has quit [Quit: Connection closed for inactivity]
mindCrime_ has joined #lisp
loke` has joined #lisp
nanoz has joined #lisp
<jfe>
hi all
<jfe>
can anyone here think of a good example where lisp macros solve a problem that is unsolvable in any other language?
rozenglass has joined #lisp
<jfe>
i can think of simple cases but i'm not certain that other languages like haskell or scala can't solve them in a similar way.
<jfe>
i'm planning to give a presentation at my company and want to discuss a bit about syntactic abstraction (and make a plug for lisp).
<alandipert>
jfe it's not a problem necessarily, but only with lisp macros can you make your own conditional constructs branches of which aren't necessarily enclosed in functions or otherwise delayed by a runtime abstraction
Bike has quit [Quit: Lost terminal]
<alandipert>
...i guess that's a single consequence of macros that's part of the larger story of using macros to help define the 'language of the problem', which is kind of hard to motivate with a single objective problem statement
eschatologist_ has quit [Excess Flood]
libertyprime has quit [Ping timeout: 246 seconds]
libertyprime has joined #lisp
<alandipert>
maybe another more concrete problem is the inevitable need for some kind of preprocessor in non-lisps... something you never ever need in lisp because of macros
eschatologist has joined #lisp
<edgar-rft>
I think "unsolvable in any other language" isn't possible but "only possible with a huge amount of helper code" would be. For example in contrast to languages where macros are simple string manipulations with Lisp it's easily possible to produce expansions that depend on the data-types of the macro's arguments.
<edgar-rft>
The main difference to other languages is here that Lisp source code is written as proper lists and therefore Lisp source code is a first-class Lisp data type.
<loke`>
edgar-rft: The closest I've seen to Lisp macros in a language which is not Lisp (or a cousin like Scheme) is Elixir.
<loke`>
edgar-rft: It may help you by comparing Elixir and Lisp macros, and emphasise the features the latter has that the former cannot replicate.
<edgar-rft>
it was jfe who asked, not me :-)
<loke`>
Sorry :-)
<LdBeth>
GG
SenasOzys has quit [Ping timeout: 258 seconds]
cdegroot has quit [Ping timeout: 246 seconds]
caltelt has quit [Ping timeout: 258 seconds]
mindCrime_ has quit [Read error: Connection reset by peer]
mindCrime has joined #lisp
pillton has quit [Ping timeout: 264 seconds]
ebrasca has joined #lisp
wigust has joined #lisp
wigust- has quit [Ping timeout: 248 seconds]
zainz has joined #lisp
rozenglass has quit [Remote host closed the connection]
xkapastel has quit [Quit: Connection closed for inactivity]
torbo has quit [Remote host closed the connection]
<aeth>
jfe: What you get with macros are e.g. embedding XML, JSON, JS, HTML, CSS, SQL, GLSL, etc. in s-expresion form inside of .lisp files, which is a fairly unusual way to work with things.
<aeth>
jfe: It's not that it's impossible in (some) other languages (and, on the other hand, there's a CL version of the template library I linked to that no Lisper uses), it's just that what's easy/idiomatic is different
<loke`>
aeth: I implemented a mustashe-like template language in Lisp. It compiles to lisp code that is then run through the Lisp compiler. That allows the template code to be compiled to native code, which probably makes it one of the faster template langauges in existence.
<loke`>
To do it in another langiage, you'd have to generate C code (for example) to a file and then run the compiler on it, generating a dynamic library than can then be loaded into the runtime... And then you'd still have the problem of dealing with reloading after modifying the template.
<loke`>
Lisp solves this beautifully in less than 1000 lines of code.
<loke`>
And that includes the full definition of the template language, which includes infix expressions and all sorts of features.
dale has quit [Quit: dale]
nanoz has quit [Ping timeout: 248 seconds]
<aeth>
loke`: you can solve that in just about any language actually... via libecl.so
<Jachy>
jfe: An argument I'd use is they can help you argue with the language designers about their design choices without necessarily having to flip the table and switch to a whole new language or wait some years for them to maybe come around to your point of view.
<jfe>
nice, i like that argument
<jfe>
i was hoping i could find a nice example of common lisp in chemistry in the CANDO project but not really sure where to look.
<loke`>
aeth: Of course. But doing it in a few hundred lines of cose, completely native to the language, with better performance. Compared to however big the mustashe project is.
<gjvc>
ace. thank you. I am very interested in DSLs in lisp
<beach>
I see.
<beach>
For a course I taught, I also defined a DSL that I cal PreScript, which is like PostScropt, but with prefix notation, and much nicer syntax than PostScript.
igemnace has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
<clothespin>
Why not a portable common lisp emacs lisp compiler
<clothespin>
make sbcl the backend instead of emacs
<karlosz>
thats one option
<karlosz>
the point is their bytecode compiler doesnt produce very good code
hiroaki has joined #lisp
sr5h has joined #lisp
<karlosz>
i couldve sworn they were going for guile instead
<beach>
I am reminded of my email exchange with RMS in 1984 when he announced GNU Emacs. I wrote something like "I think it would be better to write a good Lisp system first, and then write Emacs using it." to which he answered "Sounds good, let me know when you have implemented it.".
<clothespin>
does hemlock fit in there anywhere?
<karlosz>
entirely reasonable exchange, in my opinion
<karlosz>
both ways
<beach>
Yeah.
<clothespin>
i guess that option is too late
<beach>
clothespin: For Common Lisp, we are working on an alternative to Emacs. But it is going to take some more time.
<karlosz>
they really need to get some compiler experts on board i think
<clothespin>
beach: what's it called?
<beach>
clothespin: Second Climacs. There is already (first) Climacs, but I don't recommend it.
<clothespin>
I'm interested in targeting vktk to be a backend for mcclim
<beach>
Sounds good. Do you know about the #clim IRC channel?
<clothespin>
does that mean I could someday run the (second) climacs in vulkan?
Kundry_Wag has joined #lisp
<beach>
That might be possible.
<LdBeth>
Good eve
<beach>
Hello LdBeth.
<clothespin>
I won't have much time for programming until about july
<clothespin>
so I'm focusing on opencascade for now
zotan has quit [Ping timeout: 258 seconds]
<clothespin>
I'll get to the mcclim later
zotan has joined #lisp
<beach>
The plan for Second Climacs is to be an excellent editor for Common Lisp code. Unlike Emacs and other language-aware editors, it has a much better idea of what your code means.
<beach>
To accomplish that, we use an incremental version of the Common Lisp READ function to parse the buffer.
<clothespin>
dynamic typing seems to prevent a lot of the stuff msvc++ does
<beach>
And I plan to use the first passes of Cleavir to analyze the code further.
Kundry_Wag has quit [Ping timeout: 248 seconds]
<clothespin>
you should put the editor in another os process from what you're compiling in the buffer so you don't wedge your editor
<beach>
Thanks for the advice. But I won't do that. I know that many people will then never use it, but so be it.
<LdBeth>
With the concept of environment that won’t be a problem
<beach>
clothespin: I mean, I won't use separate processes.
<karlosz>
thats sort of what os threads are for
<LdBeth>
Incremental compilation is very fast
zotan has quit [Ping timeout: 258 seconds]
<clothespin>
i tried to tell that to Kevin at franz about cgide
<clothespin>
i was never able to use cgide and develop cg at the same time
<clothespin>
developing vulkan was the same way, start lisp, load the environment, irreparable break sbcl, kill lisp, run scripts to start it up again
<clothespin>
C programming with parentheses
zotan has joined #lisp
<clothespin>
i have no concept of what developing on a lisp machine is like
<loke`>
clothespin: For low level stuff, the same.
<beach>
clothespin: My plan is to have all this work with SICL, which, as LdBeth hinted, will have first-class global environments. So the editor will use a first-class global environment that is different from that of the Common Lisp system it runs in.
<clothespin>
save world ... reboot to clean environment ... run scripts to build your new program ... save world
<beach>
clothespin: It might even be possible to use the SICL first-class global environments in any Common Lisp system to run Second Climacs.
<LdBeth>
I don’t think there’s much case of irreparable break except segfault, namespace pollution
<clothespin>
i do that five times before breakfast
<beach>
Sure, if you run arbitrary foreign code in your Common Lisp process, then you are out of luck.
<clothespin>
i know sux
<Jachy>
loke`: Did any lisp machine have an equivalent to a kernel panic / blue screen of death that could be triggered by doing seemingly innocuous things like trying to run a 3D program?
<clothespin>
i know way to much about c++ for a lisp programmer too
<clothespin>
cold load stream
<LdBeth>
Jach: yes, where you would enter a debugger running on a 8086 chip
<clothespin>
difference is you could restart
<Jachy>
A debugger sounds quite a lot better than a BSOD unless your only real option is to reboot anyway.
<clothespin>
restart where you left off that is
longshi has joined #lisp
<clothespin>
what kind of ide like features are you trying to put into second climacs?
zotan has quit [Ping timeout: 248 seconds]
<LdBeth>
So modern IDE’s usually feature a proper lexer and parser, either provided by itself or via communicate the compiler
zotan has joined #lisp
<loke`>
Jachy: The old Lisp machines? Yes of course.
<loke`>
Jachy: You could do bit-fiddling with it, since device drivers were also written in Lisp
<loke`>
Jachy: Of course, a modern Lisp machine (if it existed) wouldn't do that.
<clothespin>
wouldn't it be great if you could click undo once you hit the cold load stream?
<clothespin>
oops didn't mean to write outside the vertex buffer
<clothespin>
doesn't nasa basically do that with the computers on the mars probes?
<LdBeth>
Indeed most of the time you can restart from the exceptions
ricekrispie2 has joined #lisp
<LdBeth>
Even in cold stream
ricekrispie has quit [Ping timeout: 258 seconds]
<pjb>
jfe: Turing Equivalence proves that there is no problem that macros solve that would be unsolvable in any other (Turing Complete) language.
<pjb>
jfe: But beware of the Turing Tarpit!
<clothespin>
if you had a mirrored computer that was a few instructions behind, you could halt the mirror in the debugger when the primary crashed
<pjb>
jfe: The problem that lisp macro solve, is writing the boiler plate. This is solved in other programming languages, by hiring interns to do it by hand.
<flip214>
most will need an UNWIND-PROTECT in there, too; and having all that stuff _instead_ of a simple WITH-* macro is exactly the boilerplate you want to avoid, right??
<no-defun-allowed>
with-with-expander
<flip214>
no-defun-allowed: ever wrote a macro that defined classes, functions, and macros for you? quite some fun with ``,, etc., I can recommend it! Quite a learning experience.
<no-defun-allowed>
yeah, i have a DEFINE-TUPLE in netfarm which assumes something similar to DEFSTRUCT but with DEFCLASS, and also a CEE-CASE which has the semantics of C's switch
<flip214>
I meant something like (defmacro define-foo (name) `(progn (defclass ,(symb name :-class) ...) (defmacro ,(symb :with- name) (...))
<flip214>
made me understand ',', and similar stuff
longshi has quit [Ping timeout: 248 seconds]
campy_fellow has quit [Read error: Connection reset by peer]
<bingbotboom>
i think you replaced yourselves with bot... thats the risk with coders
<bingbotboom>
never do something so well you make yourself redundant
techquila has quit [Ping timeout: 244 seconds]
<dim>
phoe: we're using SBCL binaries in Travis setup for pgloader, I just got confused yesterday when downloading the binary file for computing its checksum (it was late) ; but now we have an SBCL binary that doesn't support core compression
maxxcan has quit [Quit: maxxcan]
<dim>
(when (member :sb-core-compression cl:*features*) t) ; that reads strange to me, but I need the answer to be t/nil, specifically not a list
<dim>
is there another idiom to achieve that?
techquila has joined #lisp
mindthelion has quit [Read error: Connection reset by peer]
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
<aeth>
dim: (if foo t nil) or (and foo t)
<dim>
yeah to me that looks the same as the when variant (though of those also)
<dim>
I guess I'm just too used to using “generalized booleans” and to consider the result of member as been a boolean
<jdz>
dim: I think I'm missing the problem, but you can use FIND (or POSITION) instead of MEMBER?
<dim>
problem here is: The value of SB-IMPL::COMPRESSION is (:SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS ...), which is not of type (OR BOOLEAN (INTEGER -1 9)).
<dim>
find returns a symbol and position returns 45, so I guess they wouldn't fix it here, although I appreciate the alternative, in other contexts it might be exactly what I'd need, thanks
<aeth>
clearly, compose position with member to get the number 0
mindthelion has joined #lisp
v88m has quit [Remote host closed the connection]
techquila has quit [Ping timeout: 244 seconds]
<d4ryus>
dim: null would return a boolean, but you would have to revert it with not: (not (null foo))
<dim>
aeth: nope. 0 is a compression level, it doesn't mean "disable compression"
<aeth>
d4ryus: ah, yes, that's another one, but I saw it as (not (not foo))
<aeth>
d4ryus: I was joking
<aeth>
ah, tab didn't work
<aeth>
dim: I was joking
<dim>
aeth: wasn't that clear, sorry ;-)
<jackdaniel>
dim: if you embrace uiop then there is featurep function
<dim>
yeah I use uiop to some degree already
<jackdaniel>
featurep allows also :not, :and and :or specifiers
<jackdaniel>
but atom situation it resolves like: (and (member …) t)
<dim>
phoe: Travis build is fixed, now trying to optimize it a little further, because it's building pgloader twice as it is...
Folkol_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Folkol_ has joined #lisp
<jackdaniel>
maybe if it does it twice it learns on its mistakes and the second build is better? ;-)
<dim>
ahah
<no-defun-allowed>
it's like LaTeX, to get the crossreferencing right you need to build it twice
<jackdaniel>
well, building software twice in principle may be beneficial - forward-referenced functions for instance may be inlined where that makes sense
oni-on-ion has quit [Ping timeout: 248 seconds]
<jackdaniel>
but that would require same image what is clearly not applicable here :)
<phoe>
remove the first line that has --eval '(ql:quickload "pgloader")'
<phoe>
that will fix the double build
<phoe>
and also fix the redefinition bug
mooshmoosh has quit [Ping timeout: 255 seconds]
JohnMS_WORK has joined #lisp
oni-on-ion has joined #lisp
JohnMS has quit [Ping timeout: 248 seconds]
Folkol_ has quit [Read error: Connection reset by peer]
mooshmoosh has joined #lisp
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
sr5h has quit [Ping timeout: 248 seconds]
cosimone has joined #lisp
scymtym has joined #lisp
zigpaw has joined #lisp
Folkol_ has joined #lisp
<ebrasca>
Hi
<phoe>
hey
libertyprime has joined #lisp
moldybits has quit [Quit: WeeChat 2.4]
bingbotboom has left #lisp [#lisp]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 248 seconds]
anewuser has joined #lisp
samebchase has joined #lisp
orivej has quit [Ping timeout: 246 seconds]
moldybits has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 248 seconds]
oni-on-ion has quit [Remote host closed the connection]
fivo has quit [Ping timeout: 276 seconds]
Folkol_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fivo has joined #lisp
cosimone has quit [Quit: WeeChat 2.3]
<ebrasca>
phoe: How are you doing?
<phoe>
ebrasca: alive, working
<phoe>
you?
zooey has quit [Ping timeout: 256 seconds]
igemnace has quit [Ping timeout: 244 seconds]
vaartis has joined #lisp
<vaartis>
heyo
<vaartis>
is there a portable way to pin objects in memory?
<vaartis>
for ffi, that is
<vaartis>
SBCL has it's way, but i don't see pinning in CFFI, is it SBCL-only?
<shka_>
vaartis: it is not SBCL-only, but it is not portable
<shka_>
ECL for instance does not move objects in memory at all
<shka_>
SBCL won't do this either on x86 CPUs
<vaartis>
So i can basically not care about that?
<phoe>
vaartis: cffi:with-pointer-to-vector-data
<phoe>
you should care about it
zooey has joined #lisp
<phoe>
because it's a difference between a working program and a segfault
<shka_>
vaartis: depends
<shka_>
SBCL won't move objects on x86 in the current version, but may start in the future
<vaartis>
pointer-to-vector-data seems to be for vectors only..
<vaartis>
i think?
<phoe>
vaartis: what other objects do you want to pin?
<no-defun-allowed>
pinning objects makes cheney sad ):
<phoe>
I mean, what other Lisp objects?
<shka_>
so if you want your program to be resistant to such kind of changes, you should work on that
<vaartis>
phoe: a class instance
<shka_>
on other hand you may sometimes simply don't care about that at all
<phoe>
vaartis: why do you want to access a Lisp class instance from cffi?
<shka_>
because for instance it is the throwaway code
<phoe>
how do you even get a pointer to a Lisp class instance and how do you treat it?
<vaartis>
phoe: i need it in a callback
<vaartis>
i mean, i might as well give classes id's and then just pass IDs
<phoe>
are you writing that callback in C?
<phoe>
if you cffi:defcallback you should be able to use normal Lisp references in the written code
<shka_>
phoe: he is writing callback to call lisp from C
<vaartis>
no, it's in lisp, it's just called from C and i can pass it a void* user data
<vaartis>
where i need to store info on what exactly to do
<phoe>
if you write it in Lisp, even if the GC moves the object, the references are moved in the Lisp world
<phoe>
so you don't suddenly get an invalid pointer
sr5h has joined #lisp
<vaartis>
hm
<shka_>
phoe: he is calling it from C
<vaartis>
yeah the callback is called from c
<phoe>
but he calls into Lisp from C if he is writing a callback written in Lisp
<shka_>
yup
<no-defun-allowed>
can you keep those objects closed over in the callback then?
<jackdaniel>
if implementation provides callback interface then GC doesn't move the trampoline
<vaartis>
Nope
<shka_>
no-defun-allowed: he can't
<vaartis>
Closing over won't work here
<shka_>
jackdaniel: never?
<jackdaniel>
such callback would be useless if it did
<phoe>
but he calls into Lisp from C if he is writing a callback written in Lisp
<phoe>
he doesn't need to pin anything
<phoe>
Lisp will take care of the references even if GC happens
<jackdaniel>
because you don't need a ffi callback if you are going to call it from lisp
<shka_>
it would be ankward, sure, but is it behavior you can lean on?
<jackdaniel>
if you call it from somewhere else then there is ffi means to inform, that something go moved
<|3b|>
sbcl moves things on x86, it just doesn't always move them
<jackdaniel>
moving "callback" function defeats its purpose, so pretty affirmative, eys
<shka_>
|3b|: oh, i was sure it didn't
<vaartis>
Now, another question: can i make a(n opaque) pointer from a lisp object and pass it to C
<phoe>
why would you need to?
<shka_>
vaartis: i would trust jackdaniel here
<vaartis>
That's what i was trying to do all along.
<phoe>
yes, but why would you need to
<shka_>
phoe: because argument to callback
<vaartis>
shka_: alright, i see, thanks
<phoe>
oh, I see
<vaartis>
yeah
<phoe>
referencing Lisp objects from inside the C world, that's going to be tricky - you'll need to be able to arbitrarily pin them for that to work
<jackdaniel>
ecl is non-moving and sbcl has sb-ext:purify / sb-sys:with-pinned-objects
<|3b|>
from what i understand, on x86/x8664 it is conservative with respect to stack, so if your C function returns and doesnt keep the pointer, you might be safe since the caller probably has a ref to it on stack, but C keeps the pointer you probably lose, and even if it doesn't it isn't guaranteed
<jackdaniel>
ecl's gc is non-moving
<shka_>
vaartis: i usually simply store objects in the hashtable
<shka_>
but it is a little bit stupid
<vaartis>
|3b|: the object is probably going to live long enough for it to not be lost in the callback, and that exact object is going to be used only once per call, then thrown away
esrse has quit [Ping timeout: 244 seconds]
orivej has joined #lisp
<|3b|>
for 'opaque object to pass to callbacks' i usually just put a counter in a hash table or something like that, and lisp code can look it up there
jameser has quit [Ping timeout: 252 seconds]
<vaartis>
Ok yeah
<vaartis>
I think i'll just do that thn
<|3b|>
not sure if there is a good way to do long-lived pinned lisp objects
<vaartis>
then
<vaartis>
It makes sense for me to have those anyway
<vaartis>
So might as well add them right now
<vaartis>
thanks everyone
vaartis has left #lisp ["~"]
sr5h has quit [Remote host closed the connection]
anewuser has quit [Quit: anewuser]
Folkol_ has joined #lisp
<ebrasca>
phoe: I am fine and programing mezzano.
elderK has quit [Quit: Connection closed for inactivity]
<phoe>
ebrasca: good!
libertyprime has quit [Quit: Lost terminal]
libertyprime has joined #lisp
idlus_ has quit [Remote host closed the connection]
v88m has joined #lisp
idlus_ has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 248 seconds]
Lord_of_Life_ is now known as Lord_of_Life
eMBee has joined #lisp
Younder has joined #lisp
DGASAU has quit [Read error: Connection reset by peer]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
DGASAU has joined #lisp
scymtym has quit [Ping timeout: 248 seconds]
lumm has joined #lisp
cosimone has joined #lisp
zotan has quit [Ping timeout: 252 seconds]
zotan has joined #lisp
mooshmoosh has quit [Ping timeout: 246 seconds]
mooshmoosh has joined #lisp
kajo has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
idlus_ has joined #lisp
andrei-n has joined #lisp
igemnace has joined #lisp
Bike has joined #lisp
wxie has joined #lisp
libertyprime has quit [Ping timeout: 246 seconds]
gxt has quit [Ping timeout: 252 seconds]
angavrilov has joined #lisp
rwlisp has joined #lisp
makomo has joined #lisp
jmercouris has joined #lisp
lumm has quit [Quit: lumm]
Folkol_ has quit [Read error: Connection reset by peer]
lumm has joined #lisp
Kundry_Wag has joined #lisp
lumm has quit [Remote host closed the connection]
sjl has joined #lisp
mindCrime has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
t58 has joined #lisp
brundleticks has quit [Remote host closed the connection]
Zaab1t has joined #lisp
<warweasle>
Did Symboltic machines have hardware based garbage collection?
<phoe>
warweasle: I see that the hacker news debate has touched you as well
Zaab1t has quit [Client Quit]
<warweasle>
We will just keep reinventing lisp until someone remembers we invented lisp.
<warweasle>
There was a story about a hardware based garbage collection system on reddit....
<shka_>
warweasle: not this way
<phoe>
at which point they will discard it because of the parentheses
Denommus has joined #lisp
<warweasle>
I do remember that using libgc can make your program faster, oddly. At the cost of making it non-deterministic...which isn't a cost in typical systems because they are not real time.
<shka_>
there is quite a lot of interplay between data structures, threads, cost of malloc and free etc.
<shka_>
but usually GC is a better choice
lumm has joined #lisp
<edgar-rft>
I think I just invented a hardware garbage collector. Let's imagine we have a switch at the computer and if you switch it off the computer's memory forgets everything...
Denommus has quit [Remote host closed the connection]
<Younder>
warweasle, I seem to remember symbolic s having hardware garbage collection. The guy to ask is Peter Seibel 'java-monkey'.
X-Scale has joined #lisp
<shka_>
thing is, this kind of accelerated GC is suitable just for the big fishes of cloud
<p_l>
Younder: they had supporting elements for GC to work effectively, but no hw GC
wxie has quit [Quit: wxie]
jmercouris has quit [Ping timeout: 245 seconds]
<p_l>
warweasle: also, there are deterministic GCs, for example IBM's Metronome (still present in J9)
<shka_>
so maybe Amazon or Google are intersted, but we won't see this in personal computers i am afraid
<ggole>
There's a David Moon paper on hardware-assisted GC iirc
<jackdaniel>
warweasle: libgc has a wrapper over malloc, so there is potential possibilities for improvement
idlus_ has quit [Ping timeout: 256 seconds]
<p_l>
shka_: they aren't. Those that need to run large java workloads run Azul, J9 or OpenJVM with Shenandoah enabled
<p_l>
Azul iirc implemented fast write barrier without special purpose hw on recent amd64
<shka_>
so this is just curiosity
<p_l>
Shenandoah takes the hit of extra word per each allocated object to implement forwarding pointer
<p_l>
J9 provides constant-time GC, but that one might not collapse your huge mess of garbage fast enough
jmercouris has joined #lisp
<jmercouris>
edgar-rft: very very clever! absolutely no chance of segfaults!
<minion>
jmercouris, memo from defunkydrummer: Hola John; i like CLSQL for postgres due to good documentation and the availability of two PG drivers, one native and other through CFFI. After 'enjoying' iBatis, Hibernate, NHibernate and SQLAlchemy, i don't like ORMs so much. CLSQL's "functional sql" works well for my purposes, and don't forget you can easily retrieve
<jackdaniel>
actually switching power off *is* faulty, LInux moves towards persistent memory (as an option) model
<jackdaniel>
so the barrier between ram and storage is thinner
jmercouris has quit [Remote host closed the connection]
gareppa has joined #lisp
Kundry_Wag has joined #lisp
schweers has quit [Ping timeout: 252 seconds]
Kundry_Wag has quit [Ping timeout: 255 seconds]
asdf_asdf_asdf has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
anewuser has joined #lisp
idlus_ has joined #lisp
t58 has joined #lisp
daniel1302 has joined #lisp
gareppa has quit [Quit: Leaving]
lumm has quit [Quit: lumm]
jprajzne has quit [Ping timeout: 245 seconds]
lumm has joined #lisp
<selwyn>
shka: why isn't hardware-assisted GC useful for the personal computer?
jameser has quit [Ping timeout: 268 seconds]
idlus_ has quit [Ping timeout: 256 seconds]
idlus_ has joined #lisp
lumm_ has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
lumm has quit [Ping timeout: 248 seconds]
lumm_ is now known as lumm
varjag has joined #lisp
idlus_ has joined #lisp
hhdave has quit [Ping timeout: 248 seconds]
jprajzne has joined #lisp
lumm has quit [Remote host closed the connection]
idlus has joined #lisp
idlus_ has quit [Ping timeout: 256 seconds]
rdh has joined #lisp
Achylles has joined #lisp
erkin has left #lisp ["あんたなんて、英吉利牛と一緒に冷凍保存してやるわ！！"]
Kundry_Wag has joined #lisp
pankajgodbole has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
idlus has quit [Ping timeout: 256 seconds]
longshi has joined #lisp
Achylles has quit [Remote host closed the connection]
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
oni-on-ion has joined #lisp
idlus has joined #lisp
LiamH has joined #lisp
Achylles has joined #lisp
idlus has quit [Ping timeout: 256 seconds]
nanoz has joined #lisp
anewuser has quit [Quit: anewuser]
varjag has quit [Ping timeout: 245 seconds]
<White_Flame>
selwyn: GC strategies change per language and per version
<White_Flame>
and memory bandwidth is more constraining than raw CPU horsepower, so the CPU can generally do more software work that might not gain that much speed if implemented in hardware, while remaining flexible
jameser has joined #lisp
<White_Flame>
warweasle: symbolics hardware had hardware forwarding pointers, had GC flags inside its MMU which trapped if you tried to read from marked oldspace, tracked which pages contained pointers to oldspace, and probably some other features I can't recall at the moment
<White_Flame>
I don't think it wasn't a full hardware GC, but rather GC-supporting hardware
idlus has joined #lisp
skidd0 has joined #lisp
Kundry_Wag has joined #lisp
idlus has quit [Ping timeout: 256 seconds]
lumm has joined #lisp
idlus has joined #lisp
pankajgodbole has quit [Ping timeout: 255 seconds]
Kundry_Wag has quit [Ping timeout: 248 seconds]
gjvc has quit [Remote host closed the connection]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
idlus has quit [Ping timeout: 256 seconds]
nullman` has quit [Ping timeout: 244 seconds]
anamorphic has joined #lisp
selwyn has quit [Remote host closed the connection]
varjag has joined #lisp
anamorphic has quit [Client Quit]
lumm has quit [Ping timeout: 276 seconds]
anamorphic has joined #lisp
oni-on-ion has quit [Ping timeout: 248 seconds]
asdf_asdf_asdf has quit [Remote host closed the connection]
jameser has quit [Ping timeout: 255 seconds]
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
housel has quit [Ping timeout: 258 seconds]
karlosz has joined #lisp
fivo has quit [Quit: WeeChat 1.9.1]
karlosz has quit [Client Quit]
karlosz has joined #lisp
nullman`_ has joined #lisp
lumm has joined #lisp
sauvin has quit [Read error: Connection reset by peer]
lumm has quit [Client Quit]
lumm has joined #lisp
ggole has quit [Quit: Leaving]
lavaflow has quit [Ping timeout: 245 seconds]
lumm_ has joined #lisp
karlosz has quit [Quit: karlosz]
nullman`_ has quit [Ping timeout: 245 seconds]
karlosz has joined #lisp
Zaab1t has joined #lisp
lumm has quit [Ping timeout: 257 seconds]
lumm_ is now known as lumm
Denommus has joined #lisp
Zaab1t has quit [Remote host closed the connection]
lumm has quit [Ping timeout: 246 seconds]
lumm has joined #lisp
cosimone has joined #lisp
lumm has quit [Client Quit]
<aeth>
GC sounds like it could be one of those throughput vs. latency situations... especially HW GC
karlosz has quit [Quit: karlosz]
Kundry_Wag has joined #lisp
<aeth>
Personally, the GC buzzwords I'd be looking for are real-time, concurrent, and parallel... and the latency introduced by separate hardware (except maybe if it's a SoC) would probably interfere with RT.
<White_Flame>
I think it's more an issue of custom hardware speed vs general purpose hardware speed
<White_Flame>
but Intel (and presumably AMD) have added some things, like dirty page tracking, that helps GC
<White_Flame>
read & write barriers allow you to run concurrent, so that already mucks with RT
<White_Flame>
whether those be hardware or software barriers, especially the read ones
<aeth>
White_Flame: RT is easy when you don't need concurrent
lavaflow has joined #lisp
<White_Flame>
how so? just allocate time to blocking GC?
<aeth>
White_Flame: Actially your allocate time scheme is concurrent but not parallel, I think
<aeth>
This gets a little confusing!
<White_Flame>
it's literally neither :)
<White_Flame>
"stop and do GC for X msec" would still be realtime
<White_Flame>
if it's known and bounded
<aeth>
That's concurrent-but-not-parallel, like running multiple threads on a 1 core CPU, iirc
cosimone has quit [Client Quit]
<aeth>
I think GC might have to be concurrent if that's the case
ebrasca has quit [Remote host closed the connection]
<White_Flame>
pjb: and of course the actual paper is paywalled, so I don't know what it actually does
<flip214>
beach is trying for a parallel GC, that might be good enough (with enough threads, at least ;)
<White_Flame>
concurrent = GC runs simultaneously with the program
<White_Flame>
parallel = GC runs on multiple cores
nullman` has joined #lisp
<aeth>
Does a GC ever run non-simultaneously? Just waits for the program to end?
<White_Flame>
where "simultaneously" is literally that, not timeslicing a single core
<aeth>
Or would GC running only if you call (gc) count as non-concurrent? I guess it would
<White_Flame>
stop-the-word is non-simultaneously
<White_Flame>
*world
<aeth>
okay
<White_Flame>
and yeah, in ye olde times, things ran without a GC and either crashed or completed, or maybe had manual GC calls at programmer-specified points
<Bike>
for the gc coprocessor you put the "header" of the object in the middle of it, put traversable fields on the left, and nontraversable on the right
<Bike>
stuff they talk about in the fuuuuuuture section ofc
<Bike>
blugh, that stack allocation thing was mentioned in the gc handbook and still blows my mind a little
<Bike>
like, i get it, but still
<aeth>
30 seconds sounds like a nightmare!
<Bike>
that was the joke yeah
Kundry_Wag has joined #lisp
<White_Flame>
it's kind of silly: Have enough memory so you don't have to trigger GC, and it's free! \:D/
<aeth>
The ideal pause is < 10 ms imo. Ideally < 1 ms.
<White_Flame>
not to mention that stack deallocation is also free, as it's often part of function returning
<White_Flame>
the stack pointer has to move anyway
<aeth>
Pause for more than 30 ms and your users will probably notice if it's anything interactive.
<aeth>
Some might notice at 15
housel has joined #lisp
Kundry_Wag has quit [Ping timeout: 255 seconds]
<aeth>
With newer displays we're slowly moving into a sub 1 ms world. No 1000 Hz displays yet (afaik), but the time budget for some things might already be under 1 ms.
<aeth>
This is interesting not just for GC because e.g. standard time functions might work in units of 1 ms.
idlus has joined #lisp
Zaab1t has joined #lisp
<flip214>
aeth: as soon as Java has that, you can just use ABCL and profit!
<aeth>
flip214: Too late, I think the new JVM does have an adjustable GC, including RT-optimized
<aeth>
flip214: Remember, some traders use Java
<flip214>
why too late?
<aeth>
too late to say "as soon as" because they beat you to it
Zaab1t has quit [Client Quit]
<flip214>
oh, that's not a problem... Java is Open Source, so a good GC could just end up as a library and be plugged in somewhere else, right?
<flip214>
as far as the internals allow that, of course...
<aeth>
Java is GPLv2 with classpath exception isn't it?
<Bike>
not very far.
<aeth>
SBCL is public domain. Once *it* gets a good GC then you are free to use it
<flip214>
Bike: ah, that's just an engineering issue ;)
gareppa has joined #lisp
gareppa has quit [Remote host closed the connection]
idlus has quit [Ping timeout: 256 seconds]
edgar-rft has joined #lisp
cosimone has joined #lisp
idlus has joined #lisp
anamorphic has quit [Quit: anamorphic]
nydel has quit [Read error: Connection reset by peer]
mindCrime_ has joined #lisp
anamorphic has joined #lisp
mindCrime has quit [Ping timeout: 255 seconds]
Achylles has quit [Ping timeout: 258 seconds]
anamorphic has quit [Client Quit]
elazul_ has joined #lisp
dacoda has joined #lisp
dacoda has quit [Remote host closed the connection]
dacoda has joined #lisp
idlus has quit [Ping timeout: 256 seconds]
idlus has joined #lisp
Josh_2 has joined #lisp
idlus has quit [Ping timeout: 256 seconds]
nullman` has quit [Read error: Connection reset by peer]
nullman` has joined #lisp
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
<flip214>
advice 11900
<flip214>
minion: advice 11900
<minion>
You cannot just paste code with no understanding of what is going on and expect it to work.
<edgar-rft>
That's how most modern-day software was written.
nanoz has quit [Read error: Connection reset by peer]
nanoz has joined #lisp
baiyang has left #lisp [#lisp]
dacoda has quit [Ping timeout: 248 seconds]
malm has quit [Ping timeout: 244 seconds]
orivej has quit [Ping timeout: 244 seconds]
longshi has quit [Ping timeout: 258 seconds]
lumm has quit [Quit: lumm]
lumm has joined #lisp
slyrus_ has joined #lisp
Denommus has quit [Remote host closed the connection]
gxt has joined #lisp
slyrus__ has quit [Ping timeout: 245 seconds]
ym555 has joined #lisp
andrei-n has quit [Remote host closed the connection]
Achylles has joined #lisp
libertyprime has quit [Ping timeout: 255 seconds]
Josh_2 has joined #lisp
nirved_ has quit [Read error: Connection reset by peer]
t58 has quit [Read error: Connection reset by peer]
t58 has joined #lisp
nirved_ has joined #lisp
malm has joined #lisp
pierpal has quit [Ping timeout: 248 seconds]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
idlus has quit [Ping timeout: 256 seconds]
rwlisp has quit [Quit: rwlisp]
xkapastel has joined #lisp
libertyprime has joined #lisp
cosimone has quit [Quit: WeeChat 2.3]
chrisdone has joined #lisp
cosimone has joined #lisp
cosimone has quit [Client Quit]
mindCrime__ has joined #lisp
mindCrime_ has quit [Ping timeout: 246 seconds]
idlus has joined #lisp
<chrisdone>
hey all - does anyone know of any research papers or articles about the decisions made by lisp implementations on updating code within the image and how that affects running code (updating closures, data structures, keep two versions of the same name in the environment, unlinking the old code, whether to silently ignore different arity functions or allow, etc.)?
<chrisdone>
i'm working on a haskell interpreter to specifically support update in-place update in an image, and there're lots of interesting considerations in this particular part. lisp (and smalltalk) implementations have the most mature stories in this area. perhaps some compiler authors wrote-up their thoughts?
mindCrime__ has quit [Ping timeout: 258 seconds]
<fe[nl]ix>
chrisdone: look into Factor as well. its runtime keeps track of all uses of macros and allows to recompile functions when a macro changes
Josh_2 has quit [Read error: Connection reset by peer]
<chrisdone>
that is pretty cool
idlus has quit [Ping timeout: 256 seconds]
<chrisdone>
i wasn't aware Factor had an image-style interpreter!
<chrisdone>
(interpreter/compiler)
nullman`_ has joined #lisp
<fe[nl]ix>
IIRC, Factor is a weird Forth with generic functions and macros
<Bike>
and quotation, as i recall
<Bike>
neat stuff
<fe[nl]ix>
and its author likes CommonLisp
<Bike>
i don't know of any articles on that subject, by the way, but i'd like to see them
<Bike>
though with lisp semantics i don't think we can "ignore" function redefinitions, we can just have some compiled code be insensitive to it
<chrisdone>
what's a good keyword to search? i'm trying e.g. "hotswap", but i don't think lispers ever referred to updating code in place by a specific name because it's a "natural" thing to do in the environment
nullman` has quit [Ping timeout: 246 seconds]
<Bike>
i think just "redefinition", which unfortunately probably isn't gonna help
<chrisdone>
no, that's helpful, thanks. gives me something else to try
idlus has joined #lisp
karlosz has joined #lisp
nullman`_ has quit [Ping timeout: 246 seconds]
elazul_ has quit [Ping timeout: 255 seconds]
<chrisdone>
Bike: i suppose you also have the problem of e.g. (mapcar #'foo ..) vs (mapcar 'foo ...) where the latter would be updated if still running while you update, and the former would use the old definition, i _think_ in the absence of "compiled" code. although SBCL compiles everything and blurs the line, unlike Emacs Lisp
<pjb>
chrisdone: obviously, this is something you should not do, since it would be non-conforming. mapcar can start with (let ((fun (if (functionp fun) fun (symbol-function fun)))) …) or not.
<Bike>
chrisdone: if the argument is a symbol it actually has to look it up at runtime, so it would get the updated definition even in compiled code
<chrisdone>
right, i may be confusing elisp with CL now
<Bike>
uh... pretty sure
<fe[nl]ix>
chrisdone: I would also ask Slava (author of Factor)
<chrisdone>
good idea, i'll write them an email :)