<pjb>
And it's probably targetting sbcl, which is why you have the problem in ecl.
<pjb>
You should find how you can compare and swap in ecl, and #+sbcl … #+ecl … #-(or sbcl ecl) (error "Not implemented in ~A" (lisp-implementation-type))
<Ukari>
there is a `#+ecl` before mp:compare-and-swap, so it target ecl
<Josh_2>
yes but there is no mp:compare-and-swap in the manual
<no-defun-allowed>
maybe you didn't compile it with support for that?
<Josh_2>
I don't have it either, and I have it compiled with libatomic
<Ukari>
I install it by roswell...
<Ukari>
would it matter?
robdog has joined #lisp
charh has quit [Ping timeout: 240 seconds]
robdog has quit [Ping timeout: 268 seconds]
robdog has joined #lisp
Lycurgus has joined #lisp
loli has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 250 seconds]
<pjb>
Ukari: possibly, since package manager will compile packages with specific options chosen not for your need, but for the need of the distribution, which are basically that the binary package should work everywhere.
<pjb>
Ukari: only gentoo gives you a little more freedom by being a source package distribution by default, and of course, the various "linux from scratch" like distributions.
<Josh_2>
I'm using Gentoo, I've compiled ecl with libatomics flag and I don't have the compare-and-swap function
<pjb>
Ukari: basically: compile all the programs you use everyday yourself, don't rely on an administrator to do it for you and millions of other users thousands of km away.
<Josh_2>
Yeh, use Gentoo
<pjb>
Josh_2: in that case, I don't know. Ask in #ecl.
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
loli has joined #lisp
d4ryus has quit [Ping timeout: 246 seconds]
<dxtr>
So I'm trying to use READ-SEQUENCE on a usocket stream and it's blocking indefinitely - even though I'm receiving data. How come?
charh has joined #lisp
<Josh_2>
did u use socket-accept?
<Josh_2>
usocket had me all up in arms the other day xD
<dxtr>
No, but I did use socket-connect
<Josh_2>
yeh you have to use something like this (socket-stream (socket-accept (socket-connect .. )))
<dxtr>
Why would I accept a connected socket?
<Josh_2>
idk, idk what ur doing
robdog has joined #lisp
d4ryus has joined #lisp
vilivulpine has joined #lisp
<pjb>
dxtr: you need to distinguish server (listening) sockets, from connection sockets.
charh has quit [Ping timeout: 255 seconds]
robdog_ has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
robdog_ has quit [Read error: Connection reset by peer]
robdog has joined #lisp
charh has joined #lisp
tsiolkov has joined #lisp
sjl has quit [Ping timeout: 268 seconds]
robdog has quit [Ping timeout: 250 seconds]
igemnace has joined #lisp
dale has quit [Quit: dale]
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
charh has quit [Ping timeout: 245 seconds]
charh has joined #lisp
robdog has joined #lisp
jack_rabbit_ has joined #lisp
markong has quit [Quit: Konversation terminated!]
robdog_ has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
robdog_ has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
Lycurgus has quit [Quit: Exeunt]
loli has quit [Ping timeout: 245 seconds]
robdog has quit [Ping timeout: 264 seconds]
sjl has joined #lisp
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
loli has joined #lisp
robdog has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
robdog has quit [Ping timeout: 245 seconds]
q9929t has joined #lisp
q9929t has quit [Read error: Connection reset by peer]
nirved has quit [Quit: Leaving]
robdog has joined #lisp
robdog has quit [Ping timeout: 255 seconds]
Jesin has quit [Quit: Leaving]
wanz has joined #lisp
robdog has joined #lisp
Jesin has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
robdog has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 258 seconds]
ggole has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
dddddd has quit [Remote host closed the connection]
robdog has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
loli has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
<beach>
Good morning everyone!
didi` has joined #lisp
<didi`>
How do I control how FORMAT's ~S and ~A will print my structure? I want ~S to print my structure as it normally does (#S(...)) but I want ~A to print the structure differently, in a more eye-candy way.
robdog has quit [Ping timeout: 264 seconds]
<no-defun-allowed>
"~A binds print-escape to false, and print-readably to false."
<didi`>
no-defun-allowed: oic. So I should check these variables inside my printer funcion.
robdog has joined #lisp
<didi`>
function*
<no-defun-allowed>
That could work.
<didi`>
no-defun-allowed: Is there another way?
<no-defun-allowed>
well, print-escape seems pretty standard
<didi`>
no-defun-allowed: Thank you.
<no-defun-allowed>
"If [p-e is] true, an attempt is made to print an expression in such a way that it can be read again to produce an equal expression."
robdog has quit [Ping timeout: 250 seconds]
loli has joined #lisp
robdog has joined #lisp
notzmv has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 255 seconds]
<didi`>
Hum. I wonder if there's a way to only implementing the aesthetic printing, i.e. I don't want to re-inplement the default printing because o it.
<ggole>
Because print-object already has a less specific method for structure objects?
<Bike>
yeah. i mean, that's what you're relying on anyway, no?
<ggole>
I thought it would fall back on the method for foo (if there is one)
<ggole>
That's probably a bit silly though, since if you wanted specific printing for foo you would just put it in the other arm of the if
robdog has joined #lisp
<Bike>
yes.
notzmv has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
notzmv is now known as Guest80927
Guest80927 has left #lisp [#lisp]
zmv has joined #lisp
zmv is now known as notzmv
robdog has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
loli has quit [Ping timeout: 246 seconds]
amerlyq has quit [Quit: amerlyq]
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
loli has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
Oladon has quit [Quit: Leaving.]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
liead has joined #lisp
jack_rabbit_ has quit [Ping timeout: 268 seconds]
bobby has joined #lisp
casouri has quit [Remote host closed the connection]
d4ryus has quit [Ping timeout: 255 seconds]
Lord_of_Life has quit [Ping timeout: 255 seconds]
igemnace has quit [Ping timeout: 255 seconds]
notzmv has quit [Ping timeout: 255 seconds]
Jesin has quit [Ping timeout: 255 seconds]
charh has quit [Remote host closed the connection]
charh_ has joined #lisp
shka__ has joined #lisp
dlowe has quit [Ping timeout: 246 seconds]
adlai has quit [Ping timeout: 246 seconds]
scymtym has quit [Ping timeout: 246 seconds]
dyelar has quit [Ping timeout: 246 seconds]
shka_ has quit [Ping timeout: 246 seconds]
lxpz has quit [Ping timeout: 246 seconds]
Bob- has quit [Ping timeout: 246 seconds]
jockc has quit [Ping timeout: 246 seconds]
Kaisyu7 has quit [Ping timeout: 246 seconds]
acolarh has quit [Ping timeout: 246 seconds]
kqr has quit [Ping timeout: 246 seconds]
flip214 has quit [Remote host closed the connection]
flip214 has joined #lisp
vertigo_ has joined #lisp
d4ryus has joined #lisp
robdog has joined #lisp
lxpz has joined #lisp
kqr has joined #lisp
vertigo has quit [Remote host closed the connection]
keep_learning has quit [Ping timeout: 250 seconds]
emaczen has joined #lisp
acolarh has joined #lisp
dale has joined #lisp
Lord_of_Life has joined #lisp
robdog_ has joined #lisp
igemnace has joined #lisp
robdog has quit [Ping timeout: 257 seconds]
Jesin has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
dyelar has joined #lisp
robdog has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
akoana has left #lisp ["Leaving"]
robdog has quit [Ping timeout: 255 seconds]
sjl has joined #lisp
robdog has joined #lisp
robdog_ has joined #lisp
robdog__ has joined #lisp
<emaczen>
fiddlerwoaroof: I added some code to ensure execution in the main thread, but I still get the message from the OS saying that GNUstep is not responding. Any ideas?
robdog has quit [Ping timeout: 268 seconds]
robdog_ has quit [Ping timeout: 268 seconds]
<emaczen>
Well, perhaps my code does not ensure execution on the main thread, but regardless I've tried performSelectorOnMainThread:withObject:waitUntilDone: passing a NSWindow and the makeKeyAndOrderFront: selector as the arguments
<emaczen>
And I get that same message from the OS
robdog__ has quit [Ping timeout: 268 seconds]
loli has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
loli has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
Lycurgus has joined #lisp
milanj has joined #lisp
robdog has joined #lisp
<fiddlerwoaroof>
emaczen: not sure, I don't really use cocoa
<fiddlerwoaroof>
s/cocoa/gnustep
robdog has quit [Ping timeout: 250 seconds]
nowhere_man has quit [Ping timeout: 258 seconds]
<emaczen>
fiddlerwoaroof: Is your lisp/objc program dynamic?
<emaczen>
by "dynamic" I mean, can you modify it at the REPL?
robdog has joined #lisp
<fiddlerwoaroof>
I've done that before
<fiddlerwoaroof>
but, my current version doesn't actually do that
robdog_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
FreeBirdLjj has joined #lisp
<emaczen>
Can you point me to the sample code of a dynamic program?
<fiddlerwoaroof>
It's all mixed up in my codebase... let me try to put something together :)
Bike has quit [Quit: Lost terminal]
<emaczen>
I'm trying to get a better idea of what exact GUI methods to call -- thanks
<emaczen>
I just tried calling NSApplicationMain, and I don't get that OS warning anymore, but now my REPL thread is tied up
<emaczen>
Practically all of my cocoa experience is with the CCL bridge :)
<fiddlerwoaroof>
Are you using trivial-main-thread?
<emaczen>
No, I put something together using #/performSelectorOnMainThread:withObject:waitUntilDone:
<emaczen>
will cffi callbacks stay in the main thread if already there?
robdog_ has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
<fiddlerwoaroof>
unless they spawn their own thread
<emaczen>
Ok, then what I made should work fine
keep_learning has joined #lisp
<emaczen>
When you call my function #'execute-in-main-thread which takes a function as an argument, it redefines an objective-c method called #/runInMain that calls the function via a CFFI callback and then runs #/performSelectorOnMainThread:withObject:waitUntilDone: with an NSObject, the runInMain selector that was just defined, a null pointer and then I've tried yes and no for the last argument
robdog has quit [Ping timeout: 250 seconds]
igemnace has quit [Ping timeout: 250 seconds]
<emaczen>
The function that I've been passing to #'execute-in-main-thread is typical objective-c code to create an autorelease pool, a NSApplication, and a Window
<fiddlerwoaroof>
Hmm, I'm not sure if that breaks the rule about calling into lisp from foreign threads
<fiddlerwoaroof>
"Direct calls to pthread_create (instead of MAKE-THREAD) create threads that SBCL is not aware of, these are called foreign threads. Currently, it is not possible to run Lisp code in such threads."
wanz has joined #lisp
<fiddlerwoaroof>
I guess you're not directly calling that pthread function, but I'm a bit unsure if an objc selector that switches the thread a bit of code runs in has issues
robdog has joined #lisp
<emaczen>
Any ideas for testing it out to determine what threads are being used/
<emaczen>
?
<emaczen>
I'm going to try adding format forms to print sb-thread:*current-thread* and (sb-thread:main-thread)
<emaczen>
in the passed function to #'execute-in-main-thread
robdog has quit [Ping timeout: 250 seconds]
Lycurgus has quit [Quit: Exeunt]
fosonmeng has joined #lisp
fosonmeng has quit [Max SendQ exceeded]
fosonmeng has joined #lisp
fosonmeng has left #lisp [#lisp]
robdog has joined #lisp
loli has quit [Ping timeout: 272 seconds]
robdog has quit [Ping timeout: 250 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
robdog has joined #lisp
loli has joined #lisp
emaczen has quit [Ping timeout: 264 seconds]
robdog has quit [Ping timeout: 252 seconds]
igemnace has joined #lisp
dale has quit [Quit: dale]
<Ukari>
Josh_2, " jackdaniel: Ukari: atomic operations are in develop branch (not in 16.1.3 release)"
robdog has joined #lisp
<jackdaniel>
right, that
robdog has quit [Ping timeout: 250 seconds]
_whitelogger has joined #lisp
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
robdog has joined #lisp
guicho has joined #lisp
rippa has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
cyraxjoe has quit [Read error: Connection reset by peer]
cyraxjoe has joined #lisp
makomo has joined #lisp
robdog_ has joined #lisp
sjl has quit [Ping timeout: 255 seconds]
ravenous_ has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
robdog_ has quit [Ping timeout: 264 seconds]
wusticality has joined #lisp
robdog has joined #lisp
loli has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 250 seconds]
arpunk_ has joined #lisp
wusticality has quit [Ping timeout: 255 seconds]
ravenous_ is now known as ravenousmoose[aw
arpunk has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
ravenousmoose[aw is now known as ravenous_
guicho has quit [Quit: ERC (IRC client for Emacs 26.1)]
loli has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
wanz has quit [Quit: wanz]
Zaab1t has joined #lisp
robdog has joined #lisp
robdog has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
<phoe>
Is there a portable way of expanding type specifiers at runtime?
<beach>
I don't think so.
<beach>
But there has bound to be a "trival-" library for that. Or else, there should be.
<beach>
Er, I assume you mean types defined by DEFTYPE, yes?
orivej has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
<phoe>
Yes
<phoe>
oh, I see
<phoe>
Bike's INTROSPECT-ENVIRONMENT has #'TYPEXPAND and #'TYPEXPAND-1
lumm has joined #lisp
orivej has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 255 seconds]
wxie has joined #lisp
orivej has joined #lisp
akoana has joined #lisp
lumm has quit [Ping timeout: 258 seconds]
lumm has joined #lisp
orivej has quit [Ping timeout: 245 seconds]
tripty has quit [Ping timeout: 264 seconds]
tripty has joined #lisp
orivej has joined #lisp
akoana has left #lisp ["Leaving"]
random-nick has joined #lisp
akoana has joined #lisp
akoana has left #lisp [#lisp]
akoana has joined #lisp
orivej has quit [Ping timeout: 272 seconds]
q9929t has joined #lisp
orivej has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
loli has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Ping timeout: 255 seconds]
rippa has quit [Ping timeout: 250 seconds]
wusticality has joined #lisp
loli has joined #lisp
ravenous_ has quit [Read error: Connection reset by peer]
ravenousmoose has joined #lisp
metallicus has joined #lisp
metallicus has quit [Client Quit]
varjag has joined #lisp
gxt has quit [Quit: WeeChat 2.3]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #lisp
pierpal has quit [Ping timeout: 246 seconds]
gxt has joined #lisp
orivej has quit [Ping timeout: 250 seconds]
pierpal has joined #lisp
Zaabtop has joined #lisp
Zaab1t has quit [Ping timeout: 272 seconds]
Zaabtop is now known as Zaab1t
matijja has quit [Remote host closed the connection]
orivej has joined #lisp
igemnace has quit [Quit: WeeChat 2.3]
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #lisp
q9929t has quit [Quit: q9929t]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #lisp
loli has quit [Ping timeout: 246 seconds]
grumble has quit [Quit: bring black roses for the wicked one]
grumble has joined #lisp
robdog has joined #lisp
loli has joined #lisp
orivej has quit [Ping timeout: 250 seconds]
robdog has quit [Ping timeout: 250 seconds]
quipa has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Essadon has joined #lisp
Essadon has quit [Max SendQ exceeded]
Lord_of_Life has joined #lisp
quipa has quit [Ping timeout: 246 seconds]
Zaab1t has quit [Quit: bye bye friends]
rozenglass has joined #lisp
robdog has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
orivej has joined #lisp
quipa has joined #lisp
robdog has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
wanz has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
robdog_ has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
robdog has quit [Ping timeout: 250 seconds]
dddddd has joined #lisp
robdog_ has quit [Ping timeout: 252 seconds]
igemnace has joined #lisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #lisp
robdog has joined #lisp
q3d has joined #lisp
robdog_ has joined #lisp
orivej has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 268 seconds]
loli has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
orivej has joined #lisp
rippa has joined #lisp
marvin2 has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
robdog has quit [Read error: Connection reset by peer]
Inline has quit [Remote host closed the connection]
lumm_ has joined #lisp
lumm has quit [Ping timeout: 257 seconds]
lumm_ is now known as lumm
robdog_ has joined #lisp
void_pointer has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
akoana has left #lisp ["Leaving"]
quipa_ has joined #lisp
quipa has quit [Read error: Connection reset by peer]
robdog_ has quit [Ping timeout: 250 seconds]
quipa_ has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
charh_ has quit [Ping timeout: 250 seconds]
vilivulpine has quit [Remote host closed the connection]
robdog has joined #lisp
robdog_ has joined #lisp
charh has joined #lisp
q3d has quit [Ping timeout: 256 seconds]
robdog has quit [Ping timeout: 250 seconds]
robdog_ has quit [Ping timeout: 250 seconds]
makomo has quit [Ping timeout: 245 seconds]
<phoe>
Well, time to shave another yak
lumm has quit [Remote host closed the connection]
lumm has joined #lisp
robdog has joined #lisp
<phoe>
If we have a paragraph of text, let's say, "Hello world dhfjhdf world!", what spellchecking algorithm should we utilize?
<phoe>
Should we split that paragraph into ("Hello" "world" "dhfjhdf" "world") and spellcheck those?
<phoe>
And if a word fails the check, should we report back the position of the offending word in the original paragraph?
robdog has quit [Ping timeout: 250 seconds]
<beach>
What are your other options? I mean, if you check the spelling of each individual word without any context, that is what you have to do it seems. No?
<edgar-rft>
...or at least your spelling would be correct :-)
<therik>
Hello, I've got a little hobby project that I've never finished few years ago, it uses CL in the background for calculations and node.js in the front to talk to clients. The two are connected via socket and can send messages to each other. I'm thinking of extracting this connection in packages and putting it on github, quicklisp and npm. Do you think people might find it useful?
<edgar-rft>
therik: can't judge how useful, but to me it sounds interesting
wusticality has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
loli has joined #lisp
MichaelRaskin has joined #lisp
makomo has joined #lisp
<phoe>
therik: sounds good, yes - what is the protocol you use over the socket?
robdog has quit [Ping timeout: 250 seconds]
<therik>
phoe: i have to dust it first to see the details, but it's json messages prepended with "#X" where X is number of bytes from "{" to "}" in the json object. I think it would need some way of recovering from when the clients get out of sync.
<therik>
phoe: the json object contains "msg" key that has a name of function that'll be called in the other part, everything else is passed as &key parameters to the lisp function being called or as a hashmap (object) to the node function being called
robdog has joined #lisp
zotan has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
<therik>
phoe: i have no idea what state is it in and I'd be very surprised if it actually worked now, I've lost my latest backups a year ago and recently rediscovered this bitbucket
robdog has joined #lisp
<phoe>
therik: I wonder why it's called sbcl.js if your code seems not tied to SBCL as an implementation
<phoe>
but, oh well, I guess that's me being nitpicky and foreign to this code
<phoe>
therik: sure, throw it at /r/common_lisp when you're done with your uploading and cleaning
<therik>
phoe: great idea
<therik>
phoe: there's lot to clean, the name, the packages, the macros, logging, dependencies, etc. I wonder if the npm packages are still up to date now
<_death>
right, I don't see why it should only be defined for datagram-usockets.. but read-sequence doesn't wait for end-of-file
<phoe>
oh right
<phoe>
it modifies a sequence
<dxtr>
phoe: But I don't want to wait until the buffer is filled up
<phoe>
dxtr: so if there are no more elements at the moment, you do not want to hang
<dxtr>
No, I want to hang until I get data. Just like a regular C recv()
<phoe>
I don't understand
<phoe>
READ-SEQUENCE *will* hang until it gets data
<dxtr>
What? I didn't for me
<phoe>
and it will hang until it gets enough chars to fill the buffer
robdog has joined #lisp
<dxtr>
Yeah that's the issue
<phoe>
or at least it should
<dxtr>
I want it to work like C recv()
<_death>
you could submit a patch to usocket
<dxtr>
I.e. it should wait until there is data and then it reads at most len bytes
<dxtr>
I don't want to wait until the buffer is filled up
<phoe>
can't reproduce, it hangs for me
<beach>
_death: You wrote the dbus library right? Can you tell me the relationship between what you wrote and cl-dbus?
<_death>
beach: none that I know
<dxtr>
phoe: Make a buffer of 1024 bytes, read-sequence a socket to that buffer, send 4 bytes to said buffer
<dxtr>
to said socket*
<beach>
_death: OK.
<phoe>
dxtr: I did, and it hung for me
<phoe>
one sec, lemme record that
<dxtr>
That's exactly my point. It keeps hanging
<dxtr>
Even after it has received the four bytes
<dxtr>
But i have gotten my four bytes so I don't want to hang anymore, I want to process them
<therik>
is there some useful lib for unix sockets? iolib seems messy, can't even compile now
robdog has quit [Ping timeout: 268 seconds]
<phoe>
dxtr: no, you do not want to read four bytes
<phoe>
you want to read 1024 bytes because this is your buffer size
<phoe>
that is what Lisp understands
<dxtr>
NBut that's not how sockets work :P
<dxtr>
I can't force the opposite end to send me 1024 bytes
<phoe>
hmmm
<phoe>
do you know how many bytes you will receive?
<dxtr>
no
<dxtr>
It's a stream that will be connected potentially forever
<phoe>
orthogonal question: how can you be sure that you got to the end of the message and are able to process it?
<dxtr>
There's and end-of-message marker
<dxtr>
IRC is a prime example of this. \r\n = end of message. Sure, messages can't be larger than 512 bytes or so but I can't sit around waiting for 512 bytes because that might take a while to get if there's no activity
<dxtr>
in lisp I could use read-line for that case, but still
robdog has joined #lisp
<phoe>
hm
<phoe>
I know that ECL also implements sb-bsd-sockets
<phoe>
but I do not know if there is a function in CL that does exactly that behavior
<dxtr>
I was kind of surprised to see that usocket didn't have it
<phoe>
it's not a socket question but a stream question
<dxtr>
I mean this isn't really an exotic case
<phoe>
usocket provides you with a stream from which you can read until there's no more data
<dxtr>
Well that's true
<_death>
I'm guessing usocket authors chose not to implement socket-receive for tcp sockets because some implementations didn't provide for the required semantics.. but that's not such a good excuse
robdog_ has joined #lisp
makomo_ has joined #lisp
robdog has quit [Ping timeout: 268 seconds]
makomo has quit [Ping timeout: 244 seconds]
robdog_ has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
parjanya has joined #lisp
makomo_ has quit [Ping timeout: 246 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
<dxtr>
Yeah I don't even see how to implement this portably if not all implementations have a wrapper around recv(2) - without using non-blocking sockets that is
mister_m has joined #lisp
<_death>
read-byte-no-hang
<_death>
which does not exists.. I guess read-byte and listen
robdog has joined #lisp
<therik>
phoe: i forgot to mention that the cl and node are connected over unix socket, not network socket. I made it because I needed performance, I suppose I could rewrite it to work over network
<dxtr>
Guess one could make a loop with wait-for-input with a low timeout and then read a byte with read-byte
<dxtr>
But that'd be awfully slow :P
<_death>
dxtr: such implementations deserve that
<dxtr>
hehe
<_death>
I'd think implementing it for your favorite CL and providing a default that sucks but works may got others to implement the rest
<_death>
*get
<phoe>
therik: I see
<dxtr>
_death: Right now I'm just erroring out if not sbcl
robdog has quit [Ping timeout: 268 seconds]
<_death>
dxtr: I mean as a patch to usocket
<dxtr>
Oh right
<dxtr>
I just realized something that complicates things a bit more
<dxtr>
I *want* to read from the stream because I'm using cl-tls too (It's configurable in the stuff I'm doing)
<dxtr>
Dammit
loli has quit [Ping timeout: 255 seconds]
robdog has joined #lisp
<dxtr>
Oh well, something to think about
makomo_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
onawebuc has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
robdog has joined #lisp
loli has joined #lisp
wanz has quit [Quit: wanz]
Ukari has quit [Ping timeout: 258 seconds]
robdog has quit [Ping timeout: 245 seconds]
robdog has joined #lisp
gareppa has joined #lisp
Ukari has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
izh_ has left #lisp [#lisp]
wusticality has joined #lisp
robdog has joined #lisp
prite has quit [Ping timeout: 245 seconds]
ggole has quit [Quit: Leaving]
wusticality has quit [Ping timeout: 255 seconds]
robdog has quit [Ping timeout: 250 seconds]
didi has joined #lisp
robdog has joined #lisp
gravicappa has quit [Ping timeout: 258 seconds]
lumm has quit [Read error: Connection reset by peer]
rozenglass has quit [Quit: ERC (IRC client for Emacs 26.1)]
robdog_ has joined #lisp
lumm has joined #lisp
Achylles has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
gareppa has quit [Quit: Leaving]
robdog_ has quit [Ping timeout: 268 seconds]
makomo_ is now known as makomo
mejja has joined #lisp
Arcaelyx has joined #lisp
robdog has joined #lisp
<fiddlerwoaroof>
dxtr: I don't think I'm following, but you could also just read-sequence a small buffer (e.g. 4 bytes) and then store those bytes somewhere until you hit the end of message marker
<fiddlerwoaroof>
I guess that doesn't work if there's a EOM in the middle of the small buffer
robdog has quit [Ping timeout: 250 seconds]
loli has quit [Ping timeout: 246 seconds]
robdog has joined #lisp
Achylles has quit [Quit: Leaving]
<dxtr>
fiddlerwoaroof: That's the issue
<dxtr>
And it's also more efficient to read everything that's available in one go
robdog_ has joined #lisp
<dxtr>
I can't just read X bytes because no matter what that'll eventually leave me hanging unless I also combine it wait-for-input
<dxtr>
with wait-for-input
<dxtr>
And in that case I can only read one byte at a time
robdog has quit [Ping timeout: 250 seconds]
robdog_ has quit [Ping timeout: 246 seconds]
lumm has quit [Quit: lumm]
loli has joined #lisp
robdog has joined #lisp
lumm has joined #lisp
housel has joined #lisp
robdog has quit [Ping timeout: 264 seconds]
space_otter has joined #lisp
Josh_2 has joined #lisp
Achylles has joined #lisp
moei has joined #lisp
<fiddlerwoaroof>
Don't the socket classes have a timeout initarg?
Oladon has joined #lisp
tomaw has quit [Quit: Quitting]
jack_rabbit_ has joined #lisp
tomaw has joined #lisp
nowhere_man has joined #lisp
<onawebuc>
i installed quicklisp but I can't find where .quicklisp was installed ..
<onawebuc>
i was actually in another directory, is why the .quicklisp didn't install to ~
<Xach>
I'm sorry, that site gives bad advice.
<onawebuc>
oh ok. hmm. i just intend to install a slime environment
<Xach>
It will get you that far
<Xach>
The rest of the advice seems similarly off-kilter. I would not use that site for much.
wusticality has quit [Ping timeout: 244 seconds]
<onawebuc>
thank you
prite has joined #lisp
loli has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
<pjb>
phoe: you can call LISTEN before READ-SEQUENCE to avoid a hang. Then it will only read the bytes available (check the result).
<Xach>
ok, clisp's delete-dir issue should be fixed.
nowhere_man has quit [Ping timeout: 258 seconds]
<phoe>
pjb: not really?
<phoe>
LISTEN will only check if there is any data; if there are only five bytes on the socket stream but you read into a six-byte sequence, there'll be a hang.
<dxtr>
Xach: I wasn't even thinking about listen(2). I was digging through usocket to see if I had missed some feature
<MichaelRaskin>
makomo: let me see…
<makomo>
MichaelRaskin: the point of WITH-OVERLOAD is to "syntactically rewrite" (i.e. "name-based" substituion, not "symbol-based") all occurences of a certain operator and replace it with another operator
<Josh_2>
u have to socket-accept that stream-server-usocket which will block, listen stops it blocking
<dxtr>
Yeah I'm an ass!
<dxtr>
Mixed up functions
<makomo>
MichaelRaskin: MAP-OPERATOR-2 is my little wrapper around AGNOSTIC-LIZARD:WALK-FORM that will go over all of the operators
<Xach>
dxtr: cl:listen on a connected socket might tell you if there is data to read.
<makomo>
MichaelRaskin: now, i would have expected the 5th example to behave just like the 4th one, i.e. for the local macro HELLO to be expanded by agnostic-lizard
<makomo>
because WITH-OVERLOAD passes the current environment to WALK-FORM
<makomo>
so i would expect that WALK-FORM would see the macro
<makomo>
MichaelRaskin: if you notice any other irregularities or wrong assumptions, i'm all ears :-)
<MichaelRaskin>
Are you using this as a reduced example while wanting to do something much larger, or does with-overload do what you actually want to use?
<makomo>
MichaelRaskin: the latter
<MichaelRaskin>
Did you consider a wrapper over standard macrolet?
<MichaelRaskin>
Because «this in operator position should be replaced with that» sounds like precisely a simple macro (that can be generated, too)
<makomo>
MichaelRaskin: i have, but the problem is that then i have to know the package of the operator that is to be replaced
<makomo>
hm, perhaps when i said "the latter" i lied a little
<makomo>
the point is to use WITH-OVERLOAD around users' code, which might use various operators like these
<phoe>
pjb: how can CL:LISTEN change state though?
<makomo>
MichaelRaskin: and their code will reside in their own package, which i won't know about
<phoe>
isn't it a predicate answering the question "is there data on the stream"?
<makomo>
so i want to do name-based rather than symbol-based substitution
<dxtr>
That's what I get from the documentation, phoe
<MichaelRaskin>
Makomo: flatten, and generate substitutions based on all the symbols with interesting names present?
<phoe>
pjb: adding a LISTEN before the READ clearly makes the function not hang anymore, so it means that LISTEN has side effects
<phoe>
which is counter-intuitive to me
<makomo>
MichaelRaskin: oh, hm, let me think. i did literally the same thing with variables (i.e. collect the variables and then "substitute" them using LET). not sure why i didn't think of the same for operators
<MichaelRaskin>
I know I am not doing a good job advertising Agnostic-Lizard, but if you can make compiler do the work, it will be much more performant
<makomo>
MichaelRaskin: mhm. thanks for the great library though, it's awesome :-)
<MichaelRaskin>
Did you read the slides or the paper?
bendersteed has joined #lisp
<makomo>
MichaelRaskin: yup, but i'm still rereading the paper as some parts are quite dense
<MichaelRaskin>
There is a catch that if you pass an environment, you probably want to pass the :names argument, if possible
<MichaelRaskin>
The paper contains an example proving that doing the job correctly is impossible, after all
<makomo>
MichaelRaskin: does that apply to my case? is the behavior i'm seeing with example 5 expected or? is it the result of heuristics failing?
<makomo>
MichaelRaskin: right :(
<MichaelRaskin>
Also, if macro-based walker is suitable, you want to use it
<MichaelRaskin>
In your case it is
<makomo>
MichaelRaskin: i thought about that but didn't get to it yet
<MichaelRaskin>
Hm, your code never calls macroexpand-1, so it should be possible to make work with AA
<MichaelRaskin>
AL
<makomo>
AL?
<makomo>
oh
<MichaelRaskin>
Agnostic Lizard
<makomo>
yeah, got it :-)
<makomo>
right, i'm not playing any dirty environment tricks
trafaret1 has joined #lisp
<MichaelRaskin>
But debugging the walkers in presence of local macros is a bit of pain
<MichaelRaskin>
Wait a minute. Is lizard-func ever used?
<makomo>
MichaelRaskin: err, woops, nope.
<makomo>
yeah, sorry about that, the whole FLET can be thrown out
<makomo>
it's a leftover from the previous version (hence the "-2" in the name :-))
<pjb>
phoe: not hanging doesn't mean that you actually all read-byte!
<pjb>
cl:listen doesn't mutate the state, it tests it!
robdog has quit [Read error: Connection reset by peer]
robdog has joined #lisp
<phoe>
if it just tests the state, then it is a pure function
<phoe>
and if it is a pure function, then we can omit it
<phoe>
since it comes before READ-*
<phoe>
that's my thinking
loli has quit [Ping timeout: 245 seconds]
<pjb>
you really have a strange thinking…
<makomo>
MichaelRaskin: a question regarding the code walking itself -- https://plaster.tymoon.eu/view/1189#1189. why is :on-function-form-pre called for the arguments to + here?
<makomo>
is that expected? maybe i got the wrong impression from what i read from the paper
<pjb>
phoe: what do you do of the WHEN?
<Xach>
phoe: a photo sensor tests state. if you run it at noon and at midnight you might get different results.
<_death>
phoe: if something sometimes returns true and other times returns false, for the same input (say, the same stream), it's not a pure function
<phoe>
wait a second then
<phoe>
I misunderstand something obvious in that case
* phoe
re-reads this
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<makomo>
MichaelRaskin: there's an extra "code-walking::" in my last paste
<MichaelRaskin>
makomo: well, it allows to swap things that do not look like special/hardwired forms
<MichaelRaskin>
It is called before actually expanding
<phoe>
oh wait, there is a WHEN there
<phoe>
and LISTEN goes as a test to WHEN
<phoe>
I am stupid
<MichaelRaskin>
Hm, maybe checking for atoms would indeed be a good idea…
<makomo>
MichaelRaskin: right, but it is called not only for the operator form (+ 1 2) (which might also be a macro), but also for the atoms 1 and 2
<makomo>
MichaelRaskin: yes, that's what threw me off :-)
<MichaelRaskin>
Yeah, the atoms _can_ be expanded to function forms
<makomo>
oh hm, right
<makomo>
symbol macros
robdog has quit [Ping timeout: 264 seconds]
<MichaelRaskin>
And I am not sure what would be less bad here
robdog has joined #lisp
<MichaelRaskin>
makomo: now I read the comment above walk-form…
<MichaelRaskin>
OK, there is a catch
<MichaelRaskin>
It wants a proper metaenv or walker-metaenv
<_death>
phoe: indeed, read-sequence tries to read elements to fill the sequence, and will return fewer elements only if it encounters eof.. this is why I suggested read-byte and listen earlier
<phoe>
_death: that's what I was thinking of and IIUC pjb was trying to convince me otherwise
<makomo>
MichaelRaskin: ah, so i have to somehow construct a metaenv/walker-metaenv from the implementation-specific environment?
<MichaelRaskin>
In a sense, if just a flatten and generating a macrolet is easier than finding what you need from comments and paper, it is a sign AL is not the tool for the job
<MichaelRaskin>
(it is slow in inventive and interesting ways)
loli has joined #lisp
<makomo>
MichaelRaskin: so far i've only dealt with small examples so i haven't hit any slowness problems
<makomo>
MichaelRaskin: we can always improve the tool :-)
<makomo>
i don't yet understand AL completely though. i have to study it more
<MichaelRaskin>
In a way we cannot
<makomo>
and i don't really want to write yet another code walker
<makomo>
MichaelRaskin: yeah, i understand that 100% portability is impossible, but i guess we can get pretty close
lumm has quit [Read error: Connection reset by peer]
robdog has joined #lisp
lumm has joined #lisp
<MichaelRaskin>
The code is agnostic (so no calling of implementation-specific functions that are technically speaking free to do something else), so to do some approximations close enough it needs to construct environments via on-the-fly compiled code
<makomo>
MichaelRaskin: did AL come to life because you were doing some interesting code walking yourself, or just because you wanted to (nearly) solve an interesting problem?
ravenousmoose has quit [Quit: Taking a quick nap...ZZzzz]
<makomo>
MichaelRaskin: ah
<MichaelRaskin>
Well, if you look at ELS programs you can find out
ravenousmoose has joined #lisp
ravenousmoose is now known as ravenousmoose[aw
<pjb>
phoe: if you add force-output or otherwise go beyond the internal buffering, you need multiple threads.
pierpal has quit [Read error: Connection reset by peer]
<MichaelRaskin>
Those who write a walker after AL without understanding AL, are doomed to provide an unnecessary failure to AL's testsuite!
<makomo>
MichaelRaskin: will do
<makomo>
MichaelRaskin: exactly :-)
<MichaelRaskin>
(It has a test case for every previous code walker where the previous walker had a chance to work but failed )
drolax has joined #lisp
<pjb>
_death: but on socket streams, eof = end of current datagram.
<makomo>
whaaat, ELS 2012 was held in Croatia?
<MichaelRaskin>
Indeed
<phoe>
pjb: not on TCP socket streams
<makomo>
wow
robdog_ has joined #lisp
<makomo>
shame, i was too young to attend then :-)
karlosz has joined #lisp
<MichaelRaskin>
makomo: if you are interested in doing something that might have a use and involves AL, I can published my partially working code for implementation-agnostic debugger
Volt_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
<MichaelRaskin>
It's a bit crazy, but there it seems believable that AL is a hammer of correct size
<MichaelRaskin>
(actually, in ELS proceedings you can find an interesting practical tool that uses AL — and I learned about that tool at ELS)
makomo has quit [Ping timeout: 255 seconds]
<_death>
pjb: I see no evidence for that on sbcl
robdog has joined #lisp
makomo has joined #lisp
Achylles has quit [Ping timeout: 252 seconds]
wusticality has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
<makomo>
MichaelRaskin: if you get the time, yes please. that would be cool
didi has left #lisp ["O bella ciao bella ciao bella ciao, ciao, ciao."]
<makomo>
MichaelRaskin: which year should i look under?
hiroaki has joined #lisp
<MichaelRaskin>
My work: a year _before_ AL there was a combo rant/tool about fighting optimiser to get useful debugging information
svillemot has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
robdog has joined #lisp
svillemot has joined #lisp
loli has joined #lisp
<dxtr>
Does it make sense to run call-next-method at the beginning of a method? Or should I rather use :before?
<Bike>
that would be more like :after, which i would usually prefer yeah.
<dxtr>
I meant putting :before on the parents method
keep_learning has quit [Quit: Ping timeout (120 seconds)]
robdog has quit [Ping timeout: 268 seconds]
casouri has joined #lisp
<therik>
when I (ql:quickload :usocket), why doesn't it pull the server.lisp file too? I have to do separate (ql:quickload :usocket-server) for that
flip214 has quit [Ping timeout: 268 seconds]
Oladon has quit [Quit: Leaving.]
flip214 has joined #lisp
robdog has joined #lisp
karlosz has quit [Quit: karlosz]
robdog has quit [Ping timeout: 250 seconds]
casouri has quit [Ping timeout: 250 seconds]
karlosz has joined #lisp
robdog has joined #lisp
moei has quit [Quit: Leaving...]
Achylles has joined #lisp
robdog_ has joined #lisp
robdog has quit [Ping timeout: 250 seconds]
<Xach>
therik: it is just the way it works.
<fiddlerwoaroof>
dxtr: do you need to change the return value?
Oladon has joined #lisp
robdog_ has quit [Ping timeout: 250 seconds]
<fiddlerwoaroof>
The main reasons to use :AROUND are either you want to change the return value of a primary method (and don't want to make people remember to call #'CALL-NEXT-METHOD) or you want to prevent the primary methods (and :BEFORE/:AFTER methods) from running
<fiddlerwoaroof>
Or, you're doing something interesting, like trying to make the implementations of your function run in a different thread
makomo has quit [Ping timeout: 244 seconds]
robdog has joined #lisp
dmiles has quit [Remote host closed the connection]
robdog has quit [Ping timeout: 268 seconds]
drolax has quit [Ping timeout: 246 seconds]
dmiles has joined #lisp
casouri has joined #lisp
robdog has joined #lisp
<casouri>
Hi, I'm tring to inplement a simple irc backend. I think I would have two streams: one connects to emacs and one connects to irc server. And the program and send/recieve messages from/to them. I've thought of some structure of the program but they all seems complicated.
Ukari has quit [Ping timeout: 246 seconds]
<casouri>
For one that I can think of, I would have two special variable bound to streams and have lock on them, and loops through 1) send to emacs, 2) recieve from emacs, 3) send to irc, 4) recieve from irc
robdog has quit [Ping timeout: 264 seconds]
<casouri>
Does that sound right?
<fiddlerwoaroof>
If you have a recent enough version of slime/swank (I'm not sure if it's in quicklisp), you can use swank-buffer-streams to get a stream that outputs to an emacs buffer
<fiddlerwoaroof>
But, there's no input-stream
<fiddlerwoaroof>
Anyways, that sounds right in really broad terms
Ukari has joined #lisp
<therik>
Xach: where's that written? I just randomly typed :usocket-server out of desperation and it downloaded it
<casouri>
Thanks, swank feels a bit of an overkill to me. A tcp socket should work fine for messeges
loli has quit [Ping timeout: 246 seconds]
wusticality has joined #lisp
robdog has joined #lisp
<casouri>
Is there any way to do non-blocking read on normal streams? I searched around and didn't found anything that mentions it.
wusticality has quit [Ping timeout: 255 seconds]
hhdave has joined #lisp
<verisimilitude>
I take it READ-CHAR-NO-HANG isn't sufficient, casouri?
robdog has quit [Ping timeout: 246 seconds]
rozenglass has joined #lisp
<fiddlerwoaroof>
casouri: you can also use CL:LISTEN to check if there's any waiting input
<fiddlerwoaroof>
something like (loop when (cl:listen s) thereis (sl:read-char s) do (sleep 0.1))
<fiddlerwoaroof>
err.. (loop when (cl:listen s) thereis (cl:read-char s) do (sleep 0.1))
hhdave has quit [Ping timeout: 246 seconds]
<casouri>
verisimilitude: Thanks. Would it be ok if I instead spawn four threads and connects them to some CSP channels?
hhdave has joined #lisp
loli has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
xkapastel has quit [Quit: Connection closed for inactivity]
<casouri>
Because it seems a non-blocking READ-LINE is more difficult to implement that that. I need to create a buffer and read char to buffer and only return t when I read a newline.
robdog has joined #lisp
<verisimilitude>
I was only giving a solution to your immediate issue, casouri.
<casouri>
Sorry, English isn't my native language, no offence :(
<verisimilitude>
It's no issue.
therik has quit [Remote host closed the connection]