dddddd has quit [Remote host closed the connection]
graphene has quit [Remote host closed the connection]
pierpal has joined #lisp
graphene has joined #lisp
fikka has joined #lisp
Achylles has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 264 seconds]
Kundry_Wag has quit [Read error: Connection reset by peer]
SaganMan has quit [Ping timeout: 240 seconds]
SaganMan has joined #lisp
fikka has joined #lisp
terpri has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
sjl has quit [Quit: WeeChat 2.2-dev]
maximjaffe has quit [Quit: Leaving]
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
Yaargh has quit [Ping timeout: 245 seconds]
papachan has quit [Quit: WeeChat 2.2]
fikka has joined #lisp
nanozz has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
nanoz has quit [Ping timeout: 265 seconds]
fikka has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
Kundry_Wag has joined #lisp
fikka has quit [Ping timeout: 264 seconds]
papachan has joined #lisp
phoe_ has quit [Ping timeout: 268 seconds]
Fare has joined #lisp
jinkies has quit [Ping timeout: 265 seconds]
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
JuanDaugherty has quit [Ping timeout: 265 seconds]
fikka has joined #lisp
Arcaelyx_ has joined #lisp
nanozz has quit [Ping timeout: 248 seconds]
FreeBirdLjj has joined #lisp
Arcaelyx has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 260 seconds]
NoNumber has joined #lisp
fikka has joined #lisp
robotoad has quit [Quit: robotoad]
fikka has quit [Ping timeout: 260 seconds]
sjl has joined #lisp
fikka has joined #lisp
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
kajo has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
aindilis has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 265 seconds]
vsync has quit [Ping timeout: 264 seconds]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aindilis has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
robotoad has joined #lisp
dented42 has joined #lisp
Kundry_Wag has quit [Ping timeout: 264 seconds]
fikka has joined #lisp
papachan has quit [Ping timeout: 256 seconds]
fikka has quit [Ping timeout: 244 seconds]
NoNumber has left #lisp ["Gone."]
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
smasta has joined #lisp
v0|d has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
graphene has quit [Remote host closed the connection]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
didi has joined #lisp
<didi>
beach: You sent me a link, some days ago, about copying, equality, and other things in Common Lisp. Could you resend it to me? I lost it.
fikka has joined #lisp
renzhi has quit [Quit: WeeChat 2.1]
v0|d has quit [Ping timeout: 240 seconds]
renzhi has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
anewuser has joined #lisp
JuanDaugherty has joined #lisp
v0|d has joined #lisp
<pierpa>
I dont know what beach sent you, but a widely quoted writing about copying and equality is http://www.nhplace.com/kent/PS/EQUAL.html maybe that's the one you want.
fikka has quit [Ping timeout: 240 seconds]
pierpa has quit [Quit: Page closed]
JuanDaugherty has quit [Quit: Exeunt]
fikka has joined #lisp
<didi>
pierpal: Indeed, it is. Thank you.
terpri has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 244 seconds]
<pierpal>
;)
anewuser has quit [Read error: Connection reset by peer]
jlarocco has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<beach>
Good morning everyone!
<beach>
Thanks pierpa.
<no-defun-allowed>
hello beach
renzhi has quit [Quit: WeeChat 2.1]
renzhi has joined #lisp
anewuser has joined #lisp
renzhi has quit [Client Quit]
renzhi has joined #lisp
fikka has joined #lisp
smasta has quit [Ping timeout: 244 seconds]
fikka has quit [Ping timeout: 260 seconds]
detectiveaoi has quit [Quit: Leaving...]
dented42 has joined #lisp
fikka has joined #lisp
anewuser has quit [Ping timeout: 264 seconds]
fikka has quit [Ping timeout: 260 seconds]
Bike has quit [Quit: Lost terminal]
fikka has joined #lisp
nowhere_man has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
nowhere_man has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
JuanDaugherty has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
jlarocco has quit [Remote host closed the connection]
lavaflow has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 240 seconds]
lavaflow has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
vlatkoB has joined #lisp
fikka has joined #lisp
orivej has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
terpri has joined #lisp
fikka has joined #lisp
sauvin has joined #lisp
sauvin has quit [Max SendQ exceeded]
thinkpad has quit [Ping timeout: 268 seconds]
fikka has quit [Ping timeout: 264 seconds]
thinkpad has joined #lisp
thinkpad has quit [Ping timeout: 264 seconds]
<didi>
How many implementations implement SBCL's sequence extension? Is there a "trivial" package for it?
thinkpad has joined #lisp
sauvin has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
shifty has joined #lisp
<shifty>
#join /slackware
shifty has left #lisp [#lisp]
<v0|d>
what does TN stands for in (cmu|sb)cl?
<v0|d>
didi: morning.
rozenglass has quit [Remote host closed the connection]
<didi>
v0|d: o/
fikka has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
gector has quit [Ping timeout: 244 seconds]
gector has joined #lisp
gector has quit [Remote host closed the connection]
<jackdaniel>
v0|d: TN?
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gector has joined #lisp
<jackdaniel>
didi: I think only SBCL and ABCL right now. I plan to add it to ECL at some point, but no work on that has been done so far
fikka has joined #lisp
wildbartty has quit [Remote host closed the connection]
<didi>
jackdaniel: Oh, nice. So it's well received, it seems.
fikka has quit [Ping timeout: 268 seconds]
JuanDaugherty has quit [Quit: Exeunt]
fikka has joined #lisp
gravicappa has joined #lisp
Fare has quit [Ping timeout: 240 seconds]
Fare has joined #lisp
ofi has joined #lisp
dented42 has joined #lisp
<beach>
v0|d: Same question as jackdaniel. What do you mean by TN?
drot has quit [Ping timeout: 268 seconds]
dddddd has joined #lisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drot has joined #lisp
ramus has quit [Ping timeout: 248 seconds]
Fare has quit [Ping timeout: 264 seconds]
quipa has joined #lisp
schweers has joined #lisp
test1600 has joined #lisp
trittweiler has joined #lisp
<beach>
trittweiler: The talk you gave me a link to is very hard to understand, partly because he talks to fast, partly because of his accept, and partly because he assumes knowledge that I might not have. So I have started watching some other talks on the same subject first. After I understand a bit more, I'll get back to the one you recommended.
<trittweiler>
beach: I haven't actually watched it yet except for the first few minutes. I stumbled on it and thought you may be interested, that's really all :)
<shka>
very intense eastern accent
<beach>
Yes, and I thank you for that. It looks quite interesting.
<trittweiler>
If it's not immediately useful, don't sweat over it :)
<beach>
Sure, sure. But I want to know about these things.
<no-defun-allowed>
i got genera running
<beach>
So it's great.
<trittweiler>
there may be
<trittweiler>
(white)papers about that gc
<trittweiler>
which wouldn't have the accent issue
orivej has joined #lisp
<beach>
Yes, I will read some papers and watch some more movies about it.
<beach>
It seems they have some very good ideas.
<beach>
At the same time, I learn about what they have been doing in Java before this one.
<shka>
well, there was A LOT of the development in the java land
<beach>
shka: pronunciation: ʃɛnənˈdoʊə
schweers has quit [Read error: Connection reset by peer]
<shka>
jvm has the benefit of being something that industry loves
<shka>
so there was huge ammount of time and effort thrown into it
<beach>
Indeed.
angavrilov has joined #lisp
ebrasca has quit [Remote host closed the connection]
<aeth>
no-defun-allowed: So it's the best software environment and you're going to be working in it daily?
<aeth>
Hopefully it's much better than VAX like they said!
<no-defun-allowed>
yeah i'm gonna use zmacs to play tetris all day
<aeth>
I love those 90s graphics, complete with "Your Application" not fitting entirely in the circle
<aeth>
A more innocent time, before designers took over.
<beach>
no-defun-allowed: I am convinced that Genera is one of the nicest operating systems around, both when it comes to the user experience (with the integration of the tools) and when it comes to the facility with which one can write applications for it.
<beach>
no-defun-allowed: I am also convinced that we can do better.
<no-defun-allowed>
damn straight
<beach>
no-defun-allowed: In particular, I think we can have all the advantages of Genera, but on stock hardware, and with a safe multi-user environment.
<no-defun-allowed>
not sure about "stock hardware" but the rest is feasible
<beach>
I am absolutely sure.
<no-defun-allowed>
having type- and GC- tagged memory seems less painful than bitshifting out type info
<beach>
Nope.
schweers has joined #lisp
quipa has quit [Quit: Leaving]
quipa has joined #lisp
<aeth>
no-defun-allowed: I think RISC-V is adding tagged memory
<no-defun-allowed>
yep.
<beach>
It is in the same instruction on x86-64. No shifting required.
quipa has quit [Remote host closed the connection]
* no-defun-allowed
shrugs and goes back to genera documentation
<no-defun-allowed>
>Pressing the ABORT key gets you out of most kinds of trouble
<beach>
no-defun-allowed: You can even tell the x86-64 to trap on unaligned memory accesses, so you don't even have to check the type first.
<no-defun-allowed>
m$ removed the ABORT key to enforce the GUI on you!!!
quipa has quit [Client Quit]
<no-defun-allowed>
that is impressive
maximjaffe has joined #lisp
maximjaffe has quit [Remote host closed the connection]
<no-defun-allowed>
risc-v isn't exactly stock though for most uses
quipa has joined #lisp
<beach>
no-defun-allowed: But the main argument is this: if you try to create a Lisp-specific processor today, you couldn't afford to do the work to get all the fancy stuff in it, so it would be slower than if you had an interpreter for the Lisp machine running on the x86-64.
<no-defun-allowed>
that is true
<beach>
This is why I think we should create a SAFE Common Lisp system, include first-class global environments and protection to make it multi-user, and run it on stock hardware.
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<beach>
But, apparently, these days it seems I have to apologize for suggesting that we program in Common Lisp, so I'll be quiet.
nirved has joined #lisp
<aeth>
no-defun-allowed: The great thing about RISC-V is that one day you could write a RISC-V hardware in a CL DSL and have CL all the way down without having to worry about compiler support at the same time as hardware support.
<aeth>
(Well, you still would need to find a way to replace physics with a fresh CL implementation, but that's another step.)
<no-defun-allowed>
i was thinking about doing such a design. it'd be 99% stack machine, with only stack, environment and flag registers publically exposed
<no-defun-allowed>
magic GNU🦄PONUT was involved too
<magicGNUPONUT[m]>
O.o
<no-defun-allowed>
yes you were don't lie to yourself
<magicGNUPONUT[m]>
Shhh, they'll put is in the school prison
pierpal has quit [Quit: Poof]
<no-defun-allowed>
oh no
pierpal has joined #lisp
<no-defun-allowed>
oh no oh no oh no not school prison. wait, whose school and which prison
<magicGNUPONUT[m]>
The one where the os is proprietary and kicks start the free software movment
<no-defun-allowed>
oh yeah that one
<schweers>
beach: no need to apologize for that suggestion ;) I think many people could use that advice.
<beach>
schweers: Thanks.
jsjolen has joined #lisp
ramus has joined #lisp
nirved_ has joined #lisp
nirved_ has quit [Client Quit]
<no-defun-allowed>
btw the mouse cable is a tail now. please update your programs
foom2 has joined #lisp
Plazma_ has joined #lisp
catern has quit [Ping timeout: 248 seconds]
foom has quit [Read error: Connection reset by peer]
bjorkintosh has quit [Read error: Connection reset by peer]
Plazma has quit [Read error: Connection reset by peer]
<LdBeth>
I bet it can survive for another 60 years, so it worths the investment
<no-defun-allowed>
clim 0.9.42 comes with CLIM:MOUSE-HAS-TAIL-P for detecting tail support now
binghe has joined #lisp
Kaisyu7 has quit [Ping timeout: 256 seconds]
<beach>
LdBeth: The thing that worries me is all the crap they put into the processors that might one day prevent us from using free software on them, and that might make spware impossible to avoid.
<ecraven>
beach: isn't that already the case? with the separate minix running in a part of the processor you cannot access?
<ecraven>
wasn't there something about it even running an http server?
<beach>
Yeah.
<shka>
http server?
<shka>
fascinating
<beach>
Scary, too.
pierpal has joined #lisp
<aeth>
Maybe one day LispOS will be the most popular OS in the world instead of Minix.
<antoszka>
Not very likely.
<shka>
aeth: so it can be used for evil? ;-)
<no-defun-allowed>
if you can embed it, sure
* p_l
isn't really sure about that "minix is most popular" ;)
<p_l>
yes, there's a ton of ME v8 and newer devices
<mkolenda>
only intel did that hoax with minix running hidden in processors, right?
<aeth>
AMD has roughly equivalent functionality. It probably doesn't use Minix, though.
<jackdaniel>
but let us not stray away from lisp topic! ;-) I'm sure Common Lisp is a perfect language for writing operating systems
<jackdaniel>
for instance last Mezzano demo looks very nice
<beach>
I like the fact that they now use McCLIM.
<beach>
It will speed up McCLIM development.
<jackdaniel>
that may encourage more contributors (good!), and more peer review demand (well…)
<beach>
Exactly!
<beach>
And generally more tools.
<beach>
... and applications, of course.
<no-defun-allowed>
how do i poweroff the genera emulator?
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<trittweiler>
no-defun-allowed, invoke the garbage-collector ;)
<no-defun-allowed>
i did Save World and i got to the VLM debugger
<no-defun-allowed>
PSA: you do not want to do that, it writes a buggy world which crashes on startup
<LdBeth>
#'no-defun-allowed: type "Halt Genera"
<no-defun-allowed>
of course
<LdBeth>
it will ask you a (Y/N) in cold boot screen, just press "y"
<LdBeth>
and all down
<no-defun-allowed>
it asks three times
<no-defun-allowed>
that's three more than my linux host
<LdBeth>
which Linux distro you use, #'no-defun-allowed? Seems only Ubuntu can run the VM without crash it.
<no-defun-allowed>
ubuntu 7.04 in a VM
<no-defun-allowed>
it requires an old X for some reason
<antoszka>
p_l: ↑ what was the reason for the old X11 server?
<antoszka>
you explained that to me once
<no-defun-allowed>
it needs some fancy function IIRC
<LdBeth>
The new Xorg deprecated some functions
m00natic has joined #lisp
<antoszka>
yeah, just can't remember the particular details
<antoszka>
that I think p_l did
<p_l>
what exactly happens is that some ops fail on X server newer than 7.0
<p_l>
the function isn't exactly fancy or deprecated, but the specific behaviour changed in a way that hangs, related to handling modifier keys iirc
<p_l>
there's a nearly one-line patch that fixes it as well
<p_l>
(it essentially removes a function from Genera's CLX)
<p_l>
the failure is when you do certain operations, not everything, so it will deceptively work at first
<p_l>
also, for sanity, run it inside Xvnc or Xephyr
<p_l>
because Genera *will* fuck up your modifiers leaving you with effect of being able only to write in ALL CAPS
<LdBeth>
There is a issuse other than that, Save World freezes the window on Gentoo Linux
<p_l>
LdBeth: that's due to X11
<p_l>
Genera tries to, I think, change modifier settings at one point (as it has to carefully manage state during Save World) and the function fails hanging the whole process
JuanDaugherty has joined #lisp
<shka>
CLIM is rather interesting
<shka>
i had no idea that you can make toolkit like this
<beach>
We have been saying that for 18 years. :)
<schweers>
is it a known problem that McCLIM has problems with modifiers on X11?
<beach>
I think so, yes.
<beach>
Check with #clim.
<schweers>
to be more specific: I use a keyboard layout which uses Caps Lock (and another key on the german keyboard) as an extra modifier.
<schweers>
Same with Mod4 (Alt Gr).
<loke>
schweers: Which modifiers specifically are you using?
<loke>
schweers: the actual keys should be sent to McCLIM normally.
<schweers>
letters work fine
<schweers>
I tried a few demos, including the ... uh ... method inspector?
<loke>
schweers: However, if you have, like me, added an AltGr key and use setxkbmap to install a special keymap for AltGr combinations, then those inputs will not be seen by McCLIM
<schweers>
anyway, I was prompted for a generic function, and the first that came to mind was PRINT-OBJECT
<schweers>
note the minus sign
<p_l>
loke: sounds like McCLIM needs full redo of the input path
<schweers>
typing “print” went fine, but for the dash I normally use a modifier, that’s when I noticed
<beach>
p_l: It was a mess last time I looked.
<jackdaniel>
there is a bounty on that issue. someone even started it, but didn't have time for it after 60%. most importantly he has figured out what the problem is (namely key -> char mappings)
<schweers>
I use a „regular“ keymap, no xmodmap
<loke>
p_l: well, yes. Someone was looking at linking with existing input manager frameworks
<schweers>
I just issue "setxkbmap de bone" (or "setxkbmap de neo" for what you can see on the website, it doesn’t make a difference)
<loke>
schweers: There is no such thing as a “regular” keymap. It's all setxkbmap
<schweers>
sorry, this is so not my area of expertise. So don’t count on me using the proper terms ;)
<schweers>
but still: please correct me, this is the easiest way to learn.
<loke>
schweers: Anyway. McCLIM uses lowere-level functions to access input.
<schweers>
loke: at any rate, I use setxkbmap and no xmodmap (at least /I/ don’t)
<jackdaniel>
this is not architectural issue but a matter of porting some defines from some X11-header.h file to CL
<loke>
schweers: Like I said. The mechanism you use to modify those behaviours doesn't matter.
<schweers>
ah, that was your point.
<p_l>
loke: I was thinking of possibly punting input to a separate layer which could handle IME as well
<p_l>
well, make the low-level input support cognizant of IMEs
<jackdaniel>
p_l: there is already a layer for that
<loke>
For example, I can type compose-"-o to generate ö. But CLIM will see three keypresses, because it looks purely at each keypress and tries to make sense of it itself
<jackdaniel>
as I said, we simply need to copy mappings from x11 headers
random-nick has joined #lisp
<schweers>
huh, that issue has a bounty on it? How is that going anyway?
<p_l>
jackdaniel: what about XIM?
<loke>
jackdaniel: I think it's more than just the mappings. Things like dead-keys needs additional code to deal with.
<jackdaniel>
or parse them and generate code, nothing super fancy
<jackdaniel>
p_l: I'm just referencing conclusions of people who worked on the issue
<loke>
Still needs to integrate with the input manager framework, unless one wants to reimplement all the specialised input methods like Arabic, Chinese, etc...
<jackdaniel>
and I don't know what xim is
<loke>
jackdaniel: X Inut Manager. A framework for handling input methods.
<loke>
(one of three, in fact... Nothing is ever simple in X :-) )
<jackdaniel>
all I say that there is a dedicated layer for input handling in clx backend
<jackdaniel>
so adding yet another layer instead of improving existing one doesn't make sense to me
<loke>
jackdaniel: You can't support all the input methods using the pur X layer.
<loke>
Modern input methods use some Dbus stuff.
<jackdaniel>
if you talk about some X extension to use, then better place to implement it in clx
<LdBeth>
I would like to start a new IM framework
<jsjolen>
Considering Wayland, wouldn't that make clx purposeless? As in, clx wouldn't workj
<LdBeth>
purly for CLIM
<p_l>
loke: XIM is pure X, and all the "modern" systems support it still
<loke>
LdBeth: You're welcome to write it. That's the route Emacs went.
<loke>
They reimplemented all those frameworks
<jackdaniel>
imho dbus is a pathology. either way the issue mentioned above is related to key mappings
<p_l>
loke: not exactly
<loke>
(although they _also_ support XIM I believe)
<p_l>
loke: Emacs went the way I'd want to take modifications in McCLIM input layer
<loke>
p_l: True. That would make it more "CLIM native"
<jackdaniel>
jsjolen: wayland has X11 layer to make X applications working in it. but yes, investing time into X11 backend won't benefit any other backend in McCLIM
<p_l>
i.e. they have their own framework to plug in methods so they can support different "graphics" drivers
<p_l>
so on X11 you can have XIM, but you can also use internal methods that support terminal, on windows it works with IME, on Macs whatever Macs do, you can hook to several implementations on linux directly (like UIM)
<loke>
p_l: Thank you
<LdBeth>
Actually Windows 10 creates lots of trouble degrades IME experenice with Emacs
binghe has quit [Ping timeout: 264 seconds]
binghe has joined #lisp
AetherWind has joined #lisp
AetherWind has left #lisp [#lisp]
X-Scale has joined #lisp
kozy has quit [Remote host closed the connection]
sjl_ has joined #lisp
troydm has quit [Ping timeout: 256 seconds]
kozy has joined #lisp
Bronsa has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
now the "Lisp stopped itself \n FEP Command:" fortune makes sense
araujo has quit [Ping timeout: 245 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
Bronsa has joined #lisp
troydm has joined #lisp
fikka has joined #lisp
SaganMan has quit [Ping timeout: 264 seconds]
<no-defun-allowed>
If lispcafe didn't have the bloody spambots I'd talk crap there.
Guest43104 has quit [Quit: WeeChat 1.9.1]
<jsjolen>
no-defun-allowed: Instead u r spambot here
SaganMan has joined #lisp
test1600 has quit [Ping timeout: 256 seconds]
binghe has left #lisp [#lisp]
<no-defun-allowed>
Yes, of course I'm a spam bot. Go to dennisritchieisobviouslyapedoyouircusingnolifenerd.wordpress.com for more details please.
<no-defun-allowed>
If that does resolve, please don't click on it. That was a joke.
<tfb>
no-defun-allowed: of course the machine you're probably emulating was itself emulating the FEP.
fikka has quit [Ping timeout: 255 seconds]
HighMemoryDaemon has joined #lisp
<HighMemoryDaemon>
Do backticks and apostrophes have similar functionality?
<no-defun-allowed>
Yes, it was.
<beach>
HighMemoryDaemon: They are implemented very differently, but the backquote facility was meant to resemble a simple quote with additional functionality, so yes.
lavaflow_ has joined #lisp
<beach>
HighMemoryDaemon: You can consider backquote as a quote that allows you to "unquote" some parts of the structure.
fikka has joined #lisp
<no-defun-allowed>
My x86_64 host runs an x86_64 Ubuntu 7.04 virtual machine, emulating the cadr-ish CPU and 68k FEP in this setup.
<HighMemoryDaemon>
beach: Thank you. That is extremely helpful. So there is no way to unquote (use variables) with an apostrophe?
<beach>
Correct.
<beach>
And we call it "quote".
<no-defun-allowed>
No, not with the normal quote.
<HighMemoryDaemon>
Ok, cool.
<beach>
HighMemoryDaemon: In fact, '<mumble> is turned by the reader into (quote <mumble>)
<tfb>
no-defun-allowed: Oh, I thought this would be something emulating an ivory
emacsoma` has joined #lisp
<no-defun-allowed>
However, (list 'a b 'c) gives you a list of the symbol A, the value of B and the symbol C
<beach>
HighMemoryDaemon: i.e. a list of two elements, the symbol QUOTE and the object that was read after the '.
<beach>
no-defun-allowed: You are confusing HighMemoryDaemon.
MoziM has quit [Quit: WeeChat 2.2]
<no-defun-allowed>
That's not quoting the entire list, yada yada, don't listen to me and just follow beach, because that's a different use of quote. Sorry.
<HighMemoryDaemon>
beach: No, no it makes sense.
<HighMemoryDaemon>
Thanks you guys.
uint_ has joined #lisp
trnv2 has joined #lisp
logicmoo has joined #lisp
hvxgr__ has joined #lisp
<beach>
HighMemoryDaemon: And QUOTE is a special operator that returns its single argument unevaluated. So if the evaluator sees (QUOTE <mumble>), then <mumble> is returned.
<beach>
HighMemoryDaemon: So at that point, since forms are not repeatedly evaluated, <mumble> is just data.
<no-defun-allowed>
tfb: I thought they were all based off the cadr, even if they drifted way off in the end.
<no-defun-allowed>
Goodnight everyone.
<beach>
'night no-defun-allowed.
narendraj9 has joined #lisp
benkard has joined #lisp
<no-defun-allowed>
* the variable no-defun-allowed is unbound. I mean...goodbye.
swflint_away has joined #lisp
HighMemoryDaemon has quit [Remote host closed the connection]
JuanDaugherty has quit [Ping timeout: 260 seconds]
lavaflow has quit [*.net *.split]
renzhi has quit [*.net *.split]
aindilis has quit [*.net *.split]
emacsomancer has quit [*.net *.split]
swflint has quit [*.net *.split]
housel has quit [*.net *.split]
peccu4 has quit [*.net *.split]
dmiles has quit [*.net *.split]
sabrac has quit [*.net *.split]
Fade has quit [*.net *.split]
jfrancis has quit [*.net *.split]
lel has quit [*.net *.split]
jasom has quit [*.net *.split]
kqr has quit [*.net *.split]
nullman has quit [*.net *.split]
APic has quit [*.net *.split]
hvxgr has quit [*.net *.split]
himmAllRIght17 has quit [*.net *.split]
thijso has quit [*.net *.split]
uint has quit [*.net *.split]
Ober has quit [*.net *.split]
loke has quit [*.net *.split]
davsebamse has quit [*.net *.split]
trn has quit [*.net *.split]
fluxit has quit [*.net *.split]
mulk has quit [*.net *.split]
f32ff has quit [*.net *.split]
zymurgy has quit [*.net *.split]
gabot has quit [*.net *.split]
[df]_ has quit [*.net *.split]
lxpz has quit [*.net *.split]
cmbntr has quit [*.net *.split]
renard_ has quit [*.net *.split]
trnv2 is now known as trn
benkard is now known as mulk
swflint_away is now known as swflint
lel has joined #lisp
<beach>
I am considering what memory layout to use for a new Common Lisp implementation (SICL) on an x86-64 running Linux. Since I have limited knowledge of Linux, I would like some advice. In particular, I would like to know whether something bad will happen to me if I choose the following layout.
<beach>
I am assuming a 48-bit valid address space, but I will use only the lower 47 bits to avoid stepping on OS territory. This should give me 128TB of memory space. I am thinking of allocating the first 64TB to the global heap and the remaining 64TB to thread-local stuff.
<beach>
I am thinking of allocating 1GB fixed for each thread, making it possible to have 64 thousand threads at most. Each thread would have a few MB of heap and the rest would be the stack. Oh, and I could have made some mistakes in my calculations, of course.
dcluna has quit [Ping timeout: 266 seconds]
vibs29 has quit [Ping timeout: 266 seconds]
LiamH has joined #lisp
fiddlerwoaroof has quit [Ping timeout: 260 seconds]
<beach>
I should have said "address space" rather than "memory space".
<shka>
it does not look wrong
<beach>
I fear that the organization of the page tables might get in my way, but I don't know that for a fact.
<shka>
let me check with coleauges
<shka>
those androids should know better
igemnace has joined #lisp
vibs29 has joined #lisp
jasom has joined #lisp
<beach>
So (virtual) memory would be allocated as needed, of course. The global heap would expand as necessary, as would the individual thread stacks. And (virtual) memory would be given back to the system when a thread exits.
<shka>
obviously
kqr has joined #lisp
fiddlerwoaroof has joined #lisp
gabot has joined #lisp
<beach>
If this layout is possible, it would avoid many problems such as having to choose a (small-ish) fixed size heap at system start-up.
zymurgy has joined #lisp
<beach>
And I can test whether an object is in the global heap with a single comparison with a constant.
kuribas has joined #lisp
<kuribas>
what does the "World Lock" do?
<beach>
Never heard of it. Where did you hear about it?
renard_ has joined #lisp
<jackdaniel>
kuribas: by the name of it it is a giant lock over some big thread-insecure module
<shka>
correct?
<shka>
beach: so from what i understand you want to have 1GB address space per each thread
<p_l>
beach: please use 40bits, not 48bits, so 39bit userland memory space
<jackdaniel>
kuribas: i.e you could lock whole compile/compile-file functionality in compiler to avoid races
<kuribas>
jackdaniel: yeah
<shka>
"Each thread would have a few MB of heap and the rest would be the stack."
<jackdaniel>
kuribas: I like how they put emphasis on how global it is, by doubling number of earmuffs :-)
<shka>
beach: you can check the logs i think
<beach>
Yes, 1GB per thread was my suggestion.
<beach>
p_l: What's wrong with 48?
<beach>
I thought that was the minimum, no?
<beach>
shka: No, per-thread heaps are small to make GC pauses small.
<shka>
beach: it is the address space of cpu
<beach>
"short" rather.
<shka>
ok, i see
<p_l>
beach: no, the minimum is 40
<beach>
Oh, sorry, OK.
<p_l>
... though it might be difference between physical and virtual
<beach>
Then I may have to redo my calculation.
<shka>
p_l: hmm
<p_l>
you might be correct after all, virtual space might be 48bit minimum
<beach>
Whew!
<beach>
I don't care about physical memory for this. It will be much smaller of course.
<p_l>
the confusion stems from how both limits are talked close to each other in ISA requirements ;)
<shka>
"The minimal implementation of the x86-64 architecture provides 48-bit addressing encoded into 64 bits; future versions of the architecture can expand this without breaking properly written applications. "
<p_l>
(and that early 64bit x86 from intel failed the physical requirement)
<shka>
so i guess 48 bits
<beach>
That's what I thought, but it was from (a notoriously bad) memory.
<shka>
so everything looks fine
<beach>
So then the only question is whether something bad will happen to the page tables if physical memory is scattered this way in the address space.
<beach>
shka: Thanks! Very helpful!
<shka>
beach: wouldn't that be bug in the linux itself?
sjl_ has quit [Quit: WeeChat 2.2-dev]
<beach>
Not necessarily.
JPeroutek has quit [Quit: Page closed]
<beach>
shka: It could be that the page table organization will mean that the space required for the page tables becomes huge if the virtual memory allocated is scattered this way.
<beach>
But I don't think it will happen unless there is a very large number of threads.
<beach>
... and then the threads themselves will take more space than the page tables.
<shka>
this probabbly depends on how you are allocating memory
<beach>
I wouldn't think so.
sjl_ has joined #lisp
<beach>
I would think it only depends on where in the address space memory is allocated.
<shka>
... brk vs mmap namely
<p_l>
beach: if you try to linearize actually mapped pages it will work much, much better
<p_l>
because it increases the chances of system using larger pages
Bike has joined #lisp
<jsjolen>
shka: Isn't mmap standard compared to brk nowadays?
<beach>
p_l: That won't be a problem. The global heap is totally linear. Each thread heap and each thread stack is linear, and the thread heap and thread stack will be contiguous.
<shka>
jsjolen: both are in use
<beach>
shka: Oh, so you mean the same issue as p_l pointed out?
<shka>
i think so
mindCrime has joined #lisp
<beach>
shka: I can't use brk or I would have to allocate more than 64TB at startup.
<shka>
yeah
<shka>
anyway, i would say that it should work fine from what i understand
<beach>
Excellent! Thanks to both of you.
<shka>
and the only circumstances where it would be failing are those that would make any universal strategy failing hardcore
<beach>
Whew!
test1600 has joined #lisp
<p_l>
brk *should not* be used
<beach>
Right.
<beach>
OK, last question. Independently of the fact that we now think it will work, does it sound like a good plan?
nhandler_ has quit [Quit: leaving]
<p_l>
beach: I'm not sure about the sizes or layout, but it's good (my heart goes out for different approach that's all)
<p_l>
(and yours is already thought upon and calculated whereas I don't even have time to sketch on a napkin)
<beach>
Understood.
<beach>
Thanks.
<beach>
My main concern is the fixed (but high) hard limit on a thread stack.
wigust has joined #lisp
Fare has joined #lisp
<p_l>
beach: also, I'd probably do some special purpose segments even with your design
<beach>
What would those segments contain?
<beach>
I mean, there is room for such things, below the global heap.
<beach>
Or between the global heap and the threads.
<p_l>
depending on approach, a low-memory one for some "global static" objects (nil, t, possibly references to important implementation objects)
<beach>
I considered that.
<p_l>
but I'm unsure on how it would cooperate with the needs of relocation and randomized memory layout
<beach>
But since objects don't move in my global heap, I won't spend any time copying such objects anyway.
<jackdaniel>
I would keep in such memory pre-allocated conditions for memory problems
<p_l>
actually, that big of a memory map might break with randomized virtual layout
<beach>
p_l: I consider that a bug.
<p_l>
there *could* be ways around it, but I'm unsure on actual real life behavior there
<beach>
jackdaniel: Since my global heap contains objects that won't move, would it not be enough to keeps such stuff there?
<jackdaniel>
yes, you are right
<beach>
OK, that's what I thought. Thanks.
jsjolen has quit [Remote host closed the connection]
<beach>
p_l: I am hoping there will always be a way to disable it. Otherwise, it will be impossible to build a pre-allocated data structure in an executable.
<p_l>
beach: at some point SBCL had patches that allowed reallocation
<beach>
Modify every pointer in the system? Wow!
kozy_ has joined #lisp
kozy has quit [Read error: Connection reset by peer]
<p_l>
it ran a pass during image load, afaik
smasta has joined #lisp
<beach>
What a world we have created. It's all the fault of Unix.
<p_l>
relocations are older than unix
<p_l>
unix was very anti-relocation ;)
<beach>
But randomized address space is new.
<p_l>
but unrelated to unix
<beach>
Not quite.
fikka has quit [Ping timeout: 264 seconds]
<p_l>
only in the sense that unix runs on systems with flat memory model, like most other OSes around
<beach>
It is the fault of Unix that we still insist on emulating the access to a complete machine with addresses starting at 0 so that the application program has access to the stack.
<p_l>
unlike, let's say, Multics, MCP or OS/400
<p_l>
beach: not really, even if C pushed a lot of PDP-11 into computation model longer than it's usable
<beach>
"not really" as it's not the fault of Unix?
<p_l>
beach: I'd consider it orthongal
<p_l>
*orthogonal
SaganMan has quit [Ping timeout: 255 seconds]
<p_l>
beach: Unix by itself promoted approach to memory closer to many Lisp implementations (you have a pointer and you move it to allocate more memory, you can move it to lower the memory but you have to copy the objects)
<p_l>
mmap(), shared/foreign memory and shared libraries are all foreign graft tissue
<beach>
Indeed.
SaganMan has joined #lisp
<p_l>
mmap() in a very convoluted fashion might have arrived from Twenex?
<p_l>
(or was it Tenex?)
<beach>
I don't know.
<beach>
Multics did something similar at the level of an entire segment.
<p_l>
beach: yes, but multics also depended on hw access controls far beyond simplistic paging model
<p_l>
(and if you read Bell Labs notes, there is a giant "do not go for paging, it's horrible")
<beach>
Heh!
<p_l>
x86 had some advanced segmentation with call gates, but it was complex and pretty much died
<p_l>
because flat 32bit segment was easier to reason and use
<beach>
When I say that it's the fault of Unix, all I mean that, if Unix had not become so popular (and I include Windows, and other descendants), perhaps a more sophisticated computing model would have been more popular.
<p_l>
beach: I think microcomputers might be more the cause ;)
<p_l>
availability of reasonably fast and cheap hw favoured designs that didn't support more complex memory models
<beach>
... and then, application programs would not have access to the stack, so we would not have the problem with attacks that modify the return address. And then address space randomization would never have been invented.
<beach>
p_l: Yes, I read an interesting article abou that recently.
<p_l>
beach: stack is not really as much of a problem as you think, since several popular architectures actually don't use memory stack
<p_l>
(for example SPARC)
<beach>
It is entitled "C is not a low-level programming language".
<p_l>
yep
<beach>
Oh, the SPARC uses a stack.
<p_l>
beach: but not in memory
Inline has quit [Remote host closed the connection]
<p_l>
(C code might, but the CPU architecture doesn't)
<beach>
Yes, I see.
<beach>
YOu have to spill the registers at some point.
<p_l>
beach: that's controlled by OS
<beach>
Sure.
<p_l>
beach: which is how OpenBSD managed to encrypt the control stack
<beach>
The article is about how current architectures have been created (by hard work on the part of the designers) to accommodate the semantics of C.
<beach>
p_l: Oh, nice!
<beach>
p_l: Er, so what happens if in C you do { int x; f(&x)}?
<beach>
Perhaps that is undefined C behavior?
aindilis has joined #lisp
<p_l>
beach: not sure about whether it is UB or not, but I suspect the C compiler would have to use "emulated" stack for it
<beach>
I don't think I will read the latest C specification to find out.
<beach>
Interesting questions, though.
<beach>
Off topic, too. :)
<p_l>
I can't recall all of the article you mentioned, but stack isn't one of those "design for C" things
<p_l>
it's more that PDP-11 was of the same "simple stack machine" family that 8080 and related were
sjl_ has quit [Quit: WeeChat 2.2-dev]
<beach>
Sure, I just mentioned the article because of the fact that processors, OSes, and languages evolve in parallel and inter-dependent ways.
fikka has joined #lisp
<p_l>
in this case I would just point that register starved stack machine is the ancestor, not the result :)
<p_l>
(and that technically pure lisp machines were *pure* stack machines)
<beach>
For example, x86-64 with its restrictions on address bits exists because OSes have a kernel and that kernel uses the upper half of the address space.
<beach>
Yes, of course.
<p_l>
beach: the "half address space" tradition exists because it was the cheapest trick in the book since day 0
<beach>
Yes, the VAX did that as I reall.
<beach>
recall.
<p_l>
beach: it's older than VAX
<p_l>
PDP-10 did that
<beach>
Not surprised.
<p_l>
PDP-11 did that (because it took an address latch and interrupt line to implement protected memory this way)
<beach>
But I find it interesting that it propagated to the specification of an architecture.
Josh_2 has joined #lisp
<p_l>
generally outside of multics and S/360 in that era everyone used it
mkolenda has quit [Ping timeout: 240 seconds]
Denommus has joined #lisp
test1600 has quit [Ping timeout: 248 seconds]
<p_l>
beach: I'd say that "stack grows downwards" aspect of x86 (and most other architectures) had a bit to do with that
<beach>
Possibly. But I think we will get kicked if we continue this discussion here. :)
* beach
is getting nervous.
<p_l>
lol
<gendl>
You guys are fine here.
JuanDaugherty has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
<beach>
p_l: I do want to thank you for the remarks on my proposed address-space layout.
<p_l>
we're not disrupting anyone, and IMO Xach and fe[nl]ix would agree that details of how and why computers work might of relevance to lisp
Inline has joined #lisp
* p_l
notes his @ hat
<gendl>
of course, i'm not the authority here. Just giving my humble opinion.
<beach>
p_l: Yes, but we would have to slip in some keywords from time to time.
<beach>
gendl: I think we would be given warnings first, so I am not really nervous.
<p_l>
beach: of interest might be that SPARC included some instructions written with ideas of Lisp and other non-C languages
<beach>
p_l: I am impressed with your knowledge of both current and older systems (processors AND operating systems).
<p_l>
Legacy of misspent youth
<beach>
Yes, I remember the TADDC instruction.
<beach>
That was the name wasn't it?
<p_l>
I think so
<p_l>
T prefix for "tagged"
sjl_ has joined #lisp
<beach>
I wrote a compiler for SPARC some time ago.
<beach>
Yes, and C for... TRAP? :)
<p_l>
don't recall, didn't do much SPARC assembly :)
<beach>
It turns out that the SPARC register windows (and the depth of the register stack) was a result of benchmarks on Unix. For the language I wrote a compiler for, the assumptions were totally false so we had tons of traps in order to spill the register windows.
<beach>
... and they were SLOW.
<p_l>
beach: generally from what I heard people didn't like register windows, no matter how elegant they are in theory
<beach>
You may be right.
<beach>
p_l: Are you working on any Common Lisp implementation?
<p_l>
also, was it just very, very deep in terms of functional calls, or did you have a need to use control stack as the only stack?
<p_l>
beach: not right now :/
<beach>
Did you use to?
<p_l>
once I fix some things I might add some code to mezzano and maybe some more, but no, I didn't use to
<p_l>
but I read some source code :)
<beach>
It was a functional language so deep stacks.
<p_l>
and I have this half-baked idea for a lisp machine emulator
<beach>
p_l: It seems your knowledge would come in handy for writing a compiler, and more generally for a Common Lisp system.
didi has left #lisp ["there are always reasons to /part"]
<p_l>
my issue is getting from theory to practice, something I work on in general
<beach>
You mean you have problems with that?
<p_l>
yep :)
<beach>
I see.
<beach>
Do you know why?
<p_l>
so many interesting things, so little time, so hard to concentrate on paying work :)
<beach>
I fully understand.
<p_l>
(and well, some detritus in terms of organization on my side that is hard to fix)
vultyre has joined #lisp
iskander has quit [K-Lined]
<beach>
Are you busy with some other Common Lisp-related programming projects?
<p_l>
beach: mostly non computing things, some computing things that aren't really programming, and Ops work that occassionally involves light programming (mostly shell scripts and Go)
<beach>
Got it.
<beach>
p_l: So it would be OK if I bounce design questions on you from time to time?
<p_l>
it's perpetual state of "get this all sorted out so I can declare time for personal development"
<p_l>
beach: sure
<beach>
Great! Thanks!
<p_l>
I'll try to do my best for them, because frankly speaking, I feel like I'd backslide without something interesting to think about :)
fikka has joined #lisp
<v0|d>
beach: there is compiler stage called Global TN assignments. I thought TN is type name, still not sure.
sjl_ has quit [Quit: WeeChat 2.2-dev]
orivej has quit [Ping timeout: 256 seconds]
<v0|d>
beach: In this scheme there is no such thing as a ”heap closure variable” in code, since the closure values are moved into TNs by the external entry point. <= from the manual
fikka has quit [Ping timeout: 248 seconds]
<beach>
I Googled it and found it in the CMUCL documentation, but I don't see an explanation for the abbreviation.
sjl_ has joined #lisp
<v0|d>
Xof: *help*
<jackdaniel>
tn is temporary name
<beach>
Oh! :)
<jackdaniel>
in this context
<v0|d>
All the TN based VMR optimizations will apply to closure variables, since closure variables are represented in the same way as all other variables in VMR. Closure values will be allocated in registers where appropriate.
<v0|d>
temporary name based optimization doesnt make much sense to me :(
<jackdaniel>
temporary names are used during optimizations before you are concerned with the actual machine
<jackdaniel>
after that some are assigned to registers, some are allocated on a heap and some on a stack
<jackdaniel>
so in my understanding that means: optimizations before phase of compiling into actual machine code for certain processor
<v0|d>
right, VMr is virtual machine representation after intermiediate continuation repre.
<v0|d>
ir2 vs ir1
fikka has joined #lisp
xaotuk has joined #lisp
<v0|d>
jackdaniel: profiler in ecl fails miserably. profiling counter goes to negative somehow, type checks fail, fyi.
kuwze has joined #lisp
<jackdaniel>
I'm retiring ECL's profiler in favour of metering system (which is based on the same, CMUCL, profiler) which is available from quicklisp
<jackdaniel>
it may fail due to aggressive inlining, because this profiler works by replacing function definitions
<jackdaniel>
fwiw ECL may be used with standard POSIX tools for profiling C applications
vultyre has quit [Quit: Leaving]
* jackdaniel
scribes on his long todo: improve perf output for ECL and write a tutorial how to use that
ofi has quit [Quit: rcirc on GNU Emacs 26.1]
<v0|d>
jackdaniel: compiling is still so slow.
<v0|d>
maybe its possible to dlopen gcc once and compile an asdf system at once.
<v0|d>
otherwise its rlly painful.
fikka has quit [Ping timeout: 245 seconds]
<jackdaniel>
opening gcc doesn't take that much time. main part is gcc compiling files into objects, then linking these objects etc
<jackdaniel>
there has been no work recently on improving compilation speed and none is planned atm (at least on calendar, if someone improves it I'll be happy to test and merge such improvement)
<jackdaniel>
that said, compilation time is not that important (especially that ASDF does some caching); major focus in near future will be in improvements to runtime (especially CLOS)
FreeBirdLjj has joined #lisp
<v0|d>
oh i have a complaint.
<v0|d>
let me see.
fikka has joined #lisp
xaotuk has quit [Ping timeout: 240 seconds]
jack_rabbit has quit [Ping timeout: 264 seconds]
housel has joined #lisp
<shka>
GCC is just slow, and that would be it
<v0|d>
OK got it.
<shka>
MAYBE clang could be better
<shka>
but i am not so sure about that
fikka has quit [Ping timeout: 240 seconds]
<jackdaniel>
you may always compile with tcc
<v0|d>
jackdaniel: in clos/standard.lsp, compute-effective-slot-definition method makes it very hard to use custom slot-definitions.
<v0|d>
the reason is the local fun direct-to-effective is not customizable.
<shka>
direct-to-effective is IIRC not part of MOP
<shka>
and should not be used in portable programs anyway
<v0|d>
shka: its local flet.
<shka>
what difference does it make?
<v0|d>
its not XEP
<v0|d>
SBCL solves this problem by compute-effective-slot-definition-initargs.
<jackdaniel>
v0|d: nothing prevents you from specializing compute-effective-slot-definition on your own class (i.e with eql specializer), isn't this the reason why mop is supported?
<v0|d>
jackdaniel: see the method in SBCL and you'll see what I mean.
<v0|d>
no need to re-implement stuff.
<jackdaniel>
sorry, I'm buried in pending tasks right now. if you report a ticket on gitlab with explanation I'll get to it eventually
fikka has joined #lisp
narendraj9 has quit [Ping timeout: 248 seconds]
fikka has quit [Ping timeout: 268 seconds]
fikka has joined #lisp
<beach>
This new screenshot of the IR viewer shows the three kinds of highlighting that is supported now: highlighting the successors of a particular instruction, highlighting the defining and using instructions of some datum, and highlighting the data defined by or used by some instruction: http://metamodular.com/IR-viewer.png
<beach>
that ARE supported now
fikka has quit [Ping timeout: 265 seconds]
<beach>
With this latest addition, the viewer now has a little more than 1000 lines of code.
Fare has quit [Ping timeout: 248 seconds]
<shka>
it looks cute
<beach>
Thanks. More importantly, I hope it can be used for real IR debugging work.
<beach>
I did not aim for aesthetics.
<v0|d>
beach: is compute-effective-slot-definition-initargs a part of the standard?
<Bike>
when i made a custom slotd class, i defined an :around method on compute-effective-slot-definition that altered the slots manually instead of through initargs. kind of ugly, but works.
<v0|d>
I blieve adding unmake-instance to CL will solve the problem.
<beach>
What?
<v0|d>
eq #'identity (apply 'make-instance (unmake-instance *instance*)) => T
fikka has joined #lisp
nirved has quit [Ping timeout: 244 seconds]
<Bike>
oh, like unmake-instance returns the initargs.
<v0|d>
Instead of writing copy-instance, copy-object etc.
<Bike>
that's kind of problematic since make-instance andinitialize-instance and etc can have arbitrary side effects
<v0|d>
In GHC, you can do that I believe.
<Bike>
haskell? they don't have anything like clos.
<v0|d>
Bike: they have it for alg data types.
<Bike>
yeah. those are simple.
<v0|d>
I use unmake all the time over CLOs objects to implement fmaps.
<Bike>
as per how haskell usually rolls, what you can do is quite restricted so that the system can do amazing things with them.
<v0|d>
True, in CL apply is not optimized at all afaiknow.
<v0|d>
always a full-call.
<Bike>
depends. but that's not what i meant.
fikka has quit [Ping timeout: 256 seconds]
<Bike>
you can, for example, have a shared-initialize method that takes a &key argument that controls some initialization behavior, but which does not itself correspond to a slot.
<Bike>
oh, but i suppose unmake-instance is itself a generic function
<v0|d>
Its possible to arrange stuff to save those args somewhere convenient. Not sure about the particular case you've meant, I'm afraid.
nowhere_man has quit [Ping timeout: 256 seconds]
Kaisyu has quit [Quit: Connection closed for inactivity]
SaganMan has quit [Quit: WeeChat 1.6]
fikka has joined #lisp
light2yellow has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
Baggers has joined #lisp
Baggers has left #lisp [#lisp]
FreeBirdLjj has joined #lisp
<v0|d>
The two main components of VMR are Temporary Names (TNs) and Virtual OPerations (VOPs).
<v0|d>
jackdaniel: you were right.
asarch has joined #lisp
orivej has joined #lisp
fikka has joined #lisp
JuanDaugherty has quit [Quit: Exeunt]
fikka has quit [Ping timeout: 244 seconds]
quipa has quit [Read error: Connection reset by peer]
quipa has joined #lisp
nowhere_man has joined #lisp
<LdBeth>
Is Obj-C dead after Swift promoted? Will there be any plans on a Swift binding?
smasta has quit [Ping timeout: 260 seconds]
kuribas has quit [Remote host closed the connection]
<Xach>
LdBeth: not something to discuss here.
fikka has joined #lisp
Fade has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
Copenhagen_Bram has quit [Read error: Connection reset by peer]
fikka has joined #lisp
schweers has quit [Ping timeout: 255 seconds]
<p_l>
heh
<p_l>
interviewers in job interviews should be prepared to tell me what language they want :>
* p_l
feels reasonably prideful that the code he wrote in browser's TEXTAREA compiled, even if had few errors)
<v0|d>
p_l: w3m?
Copenhagen_Bram has joined #lisp
<v0|d>
heh, emacs->w3->textarea
<p_l>
nothing as fancy as that
<p_l>
chrome, no editor support
<p_l>
wrote a function in CL from memory to verify if an IPv4 address is inside the provided network
<p_l>
it compiled, though it had few errors (forgot arguments to functions in few places, had wrong order of arguments to ASH)
<v0|d>
did you get the job?
<p_l>
well, I'm definitely getting next interview
<Josh_2>
Xach is a package not compiling from Quicklisp your problem? Or do I message the maintainer?
mkolenda has joined #lisp
<mfiano>
Josh_2: That depends on which quicklisp dist you are on, which OS, which implementation, and which implementation version. Xach tests on newish SBCL x64 on Linux.
<Josh_2>
I am on SBCL on Linux
<Josh_2>
x64
<mfiano>
I suppose it also depends on if you have any of its transitive dependencies in local-projects or another asdf central registry location, as well as if it depends on any foreign code
<mfiano>
Perhaps mentioning the system
<Josh_2>
I deleted Quicklisp and reinstalled and it still didn't work
<Josh_2>
It was working until I updated Quicklisp
<mfiano>
As that is what I assume you meant, since Quicklisp does not have anything to do with packages
<Josh_2>
am on 4.16.7 kernel on Gentoo
<mfiano>
You still didn't mention which system
m00natic has quit [Remote host closed the connection]
<Josh_2>
sbcl 1.3.21. What u mean?
<mfiano>
Quicklisp is a frontend to asdf, and the 's' stands for 'system'. That's what we call Common Lisp collections of software
<mfiano>
You erroneously call them packages, which are something else entirely
<v0|d>
p_l: good luck.
<Josh_2>
Well I was just running (ql:quickload "spinneret")
<Josh_2>
just not sure who to tell
<mfiano>
I use spinneret daily. It works fine from Quicklisp.
<mfiano>
Perhaps paste the backtrace and compile log somewhere
<mfiano>
It looks like it's erroring on serapeum, not spinneret. Particularly the strings module, which depends on the string-case library, which got a recent update to support newer SBCL versions. I would ensure you are on the latest stable SBCL, and clear your FASL's.
asarch has quit [Remote host closed the connection]
<mfiano>
But I have to go back to work now. Good luck
asarch has joined #lisp
<Josh_2>
alrighty thanks
Orion3k has quit [Quit: Leaving]
<v0|d>
Josh_2: There is no function named DECLARE.
<v0|d>
this doesn't make sense.
<v0|d>
which lisp is this?
<Josh_2>
SBCL 1.3.21
<jasom>
v0|d: that's an sbcl error message; most other implementations have a less friendly error for the same issue
<Josh_2>
I'm going to delete the portage version and download the 1.4.10 from sbcl website
<kuwze>
do you guys use roswell to have a current sbcl? or do you use something else?
<Josh_2>
updated sbcl to 1.4.9 and still getting the same error
rozenglass has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 260 seconds]
varjag has joined #lisp
fikka has joined #lisp
azimut has quit [Ping timeout: 265 seconds]
Kundry_Wag has quit [Ping timeout: 265 seconds]
fikka has quit [Ping timeout: 240 seconds]
<Demosthenex>
teaching the next generation. having a blast showing my youngest son how to use emacs, slime, and CL to make a text adventure game =]
<varjag>
cool
<dlowe>
sweet
fikka has joined #lisp
<Demosthenex>
he is not intimidated by the hotkeys, he's been quick to pick them up. also, using tmux/screen to share a session we can both work in is GOLDEN
<Demosthenex>
he was upset he'd have to make a bulk edit for some stuff, i did it in seconds using an emacs keyboard macro. blew his mind ;]
vlatkoB has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 268 seconds]
<Josh_2>
Demosthenex: he's probably better at it than me :)
<dlowe>
Demosthenex: curious, how old?
<Demosthenex>
dlowe: 15
<Demosthenex>
good age for learning languages. i learned pascal, x86 assembly, c and c++ in highschool
<Demosthenex>
aeth: that is a GREAT link. thank you!
<Demosthenex>
aeth: at the moment though he's doing a text adventure, like a MUD.
<Demosthenex>
its a good opportunity to learn regular expression, command parsing, REPL loops, basic OOP, and more
al-damiri has joined #lisp
<dim>
Demosthenex: have a look at https://tic.computer even if it's not CL but lua, also there's a CL version out there but you might need to debug it
dented42 has joined #lisp
Fare has quit [Ping timeout: 260 seconds]
<Demosthenex>
pretty cool!
<Demosthenex>
funny that he's enjoying learning some basics, while i chomp at the bit over the lack of TUI libs for basic CRUD interfaces :P
<dim>
we made the skeleton of a game with my 14yo nephew a couple weeks ago, using Tic-80, it all happens in within the same application which is pretty nice
<Demosthenex>
what's good for me is that he's played MUDs before, so he's keen to try and recreate the experience
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Bike>
specifically they were talking about the gc, i think
<jkordani>
ty bike:
<vultyre>
Is anybody familiar with cl-ftp? I am working on an application that uses it as an ftp client, but I am not getting expected behavior. When I try to download a non-existent file, I should receive an ftp:ftp-error object. However, the evaluation just hangs instead.
igemnace has quit [Remote host closed the connection]
<pjb>
vultyre: I'd say you're using an old version ofc l-ftp.
<pjb>
s/c / c/
<vultyre>
Sorry, here's the fixed example: https://pastebin.com/TKye50AV. I was trying to rewrite it in the simplest way possible to show my problem but forgot the conn argument
dented42 has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
Plazma_ is now known as Plazma
orivej has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
orivej has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
hiroaki has joined #lisp
<jasom>
vultyre: shelling out to curl or wget is sadly going to be more reliable. There are many corner cases in how FTP is implemented.
sh1r0 has joined #lisp
<v0|d>
Demosthenex: I want to build a space invaders clone in browser using parenscript. Prob. several pages long, let me know if you are in doing such.
<vultyre>
jasom, I was able to switch it over and verify that it works.
fikka has joined #lisp
pierpal has quit [Quit: Poof]
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pierpal has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
kajo has quit [Ping timeout: 240 seconds]
stylewarning has quit [Changing host]
stylewarning has joined #lisp
stylewarning has joined #lisp
kajo has joined #lisp
angavrilov has quit [Remote host closed the connection]
vultyre has quit [Quit: Leaving]
stylewarning has quit [Changing host]
stylewarning has joined #lisp
stylewarning has joined #lisp
stylewarning has quit [Changing host]
stylewarning has joined #lisp
stylewarning has joined #lisp
test1600 has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
zagura has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
Kundry_Wag has joined #lisp
fikka has joined #lisp
sh1r0 has quit [Ping timeout: 260 seconds]
xaotuk has joined #lisp
v0|d has joined #lisp
chronal has joined #lisp
chronal has left #lisp [#lisp]
Kundry_Wag has quit [Ping timeout: 248 seconds]
pierpa has joined #lisp
nowhere_man has quit [Ping timeout: 240 seconds]
Lycurgus has joined #lisp
quipa has quit [Quit: Leaving]
LiamH has quit [Quit: Leaving.]
reg_32 has joined #lisp
ntqz has joined #lisp
<reg_32>
does anyone know if I can set a default debug level in CCL like what can be done in SBCL with (sb-ext:restrict-compiler-policy 'debug 3)
nowhere_man has joined #lisp
<v0|d>
reg_32: (proclaim (optimize ..)) does not work?
azimut has joined #lisp
<pierpa>
reg_32: AFAIK no. That's a sbcl feature that should be copied by the other implementations.
<pierpa>
v0|d: reg_32 wishes something different
mindCrime has quit [Ping timeout: 248 seconds]
Bike has quit [Ping timeout: 252 seconds]
<v0|d>
I should have guessd that. sry.
<v0|d>
so it basically does what? overrides proclaims?
<pierpa>
yes, basically
<v0|d>
see.
<pierpa>
no, wait.
<pierpa>
overrides local declarations
<pierpa>
so after the command above, a local declaration (debug 0) has no effect
<v0|d>
interesting.
<reg_32>
that's was my point
<reg_32>
thanks pierpa
<pierpa>
yw. keep present that I may be wrong, of course
<pierpa>
I read the CCL manual cover to cover and don't remember this feature. But this does not absolute certainty that there's no sucj a feature.
<pierpa>
*does not give
varjag has quit [Ping timeout: 248 seconds]
nowhere_man has quit [Read error: Connection reset by peer]
asarch_ has joined #lisp
asarch has quit [Ping timeout: 240 seconds]
rpg has joined #lisp
sjl_ has quit [Quit: WeeChat 2.2-dev]
<pjb>
There should be no local optimize declarations. Report the bug to the library author!
Jesin has joined #lisp
equwal has joined #lisp
asarch__ has joined #lisp
asarch_ has quit [Read error: Connection reset by peer]
krrrcks has quit [Ping timeout: 256 seconds]
reg_32 has quit [Quit: Page closed]
<jasom>
pjb: it overrides declaims as well, and there is a case for local optimize declarations to be made. Some numeric code can have massive performance speedups with a safety of 0 and it is often possible to make a safe interface to them.
anewuser has joined #lisp
quipa has joined #lisp
quipa has quit [Max SendQ exceeded]
Jesin has quit [Remote host closed the connection]
quipa has joined #lisp
Lycurgus has quit [Quit: Exeunt]
Jesin has joined #lisp
orivej has quit [Ping timeout: 244 seconds]
fikka has quit [Ping timeout: 240 seconds]
rumbler31 has quit [Remote host closed the connection]
fikka has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
robotoad has quit [Quit: robotoad]
nullniverse has joined #lisp
xaotuk has quit [Ping timeout: 248 seconds]
Bike has joined #lisp
fikka has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
Fare has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
asarch__ is now known as asarch
robotoad has joined #lisp
fikka has quit [Ping timeout: 264 seconds]
Kundry_Wag has joined #lisp
<stylewarning>
yeah, "no local optimizations" is lousy advice
v0|d has quit [Remote host closed the connection]
<aeth>
Additionally, SBCL uses double-float for trigonometric functions on single-floats on the default settings, but not at (speed 3). When speed is more important than precision (such as in real-time graphical applications like games), you want speed instead, especially since using double-floats in this context will cons and could potentially trigger a garbage collection when you don't want it.
<aeth>
(Graphics are mostly done on the GPU, but you often *generate* the matrices that you give to GPU with a bunch of trig functions.)
gigetoo has quit [Ping timeout: 256 seconds]
gigetoo has joined #lisp
patlv has joined #lisp
fikka has joined #lisp
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has quit [Ping timeout: 240 seconds]
hiroaki has quit [Ping timeout: 260 seconds]
patlv has quit [Ping timeout: 268 seconds]
fikka has joined #lisp
fikka has quit [Read error: Connection reset by peer]
mrcom has quit [Quit: Leaving]
kajo has quit [Ping timeout: 268 seconds]
Denommus has quit [Read error: Connection reset by peer]