freenode/#lisp - IRC Chatlog
Search
6:27:21
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?
6:30:06
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
7:16:23
emaczen
I just tried calling NSApplicationMain, and I don't get that OS warning anymore, but now my REPL thread is tied up
7:17:23
emaczen
No, I put something together using #/performSelectorOnMainThread:withObject:waitUntilDone:
7:22:12
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
7:23:42
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
7:31:36
fiddlerwoaroof
Hmm, I'm not sure if that breaks the rule about calling into lisp from foreign threads
7:32:47
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."
7:34:15
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
7:38:06
emaczen
I'm going to try adding format forms to print sb-thread:*current-thread* and (sb-thread:main-thread)
8:12:47
Ukari
Josh_2, " jackdaniel: Ukari: atomic operations are in develop branch (not in 16.1.3 release)"
14:07:39
phoe
If we have a paragraph of text, let's say, "Hello world dhfjhdf world!", what spellchecking algorithm should we utilize?
14:08:12
phoe
Should we split that paragraph into ("Hello" "world" "dhfjhdf" "world") and spellcheck those?
14:08:40
phoe
And if a word fails the check, should we report back the position of the offending word in the original paragraph?
14:09:48
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?
14:25:16
edgar-rft
phoe: there's a company named Dhfjhdfnzhou that might match your pattern: <https://www.companiess.com/dhfjhdf_info683568.html>
14:27:48
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?
14:39:44
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.
14:41:30
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
14:59:15
therik
phoe: https://bitbucket.org/jctherik/flapping.js/src/master/sbcl-server/listener.lisp and https://bitbucket.org/jctherik/flapping.js/src/master/src/server/sbcl.js
14:59:48
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
15:01:59
phoe
therik: I wonder why it's called sbcl.js if your code seems not tied to SBCL as an implementation
15:02:57
phoe
therik: sure, throw it at /r/common_lisp when you're done with your uploading and cleaning
15:04:06
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
15:50:02
dxtr
And I'm fine with making my own function and using conditionals but I couldn't find an equivalent in ccls documentation
15:52:21
dxtr
_death: https://common-lisp.net/project/usocket/api-docs.shtml "socket should be a datagram-usocket."
15:54:02
dxtr
That was the first thing i reached for. Then I realized I'm reading from a stream so READ-SEQUENCE should work
15:54:21
dxtr
Problem is, if I understand the problem I'm having, is that READ-SEQUENCE looks for :eof
15:56:16
_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
16:00:38
beach
_death: You wrote the dbus library right? Can you tell me the relationship between what you wrote and cl-dbus?
16:01:08
dxtr
phoe: Make a buffer of 1024 bytes, read-sequence a socket to that buffer, send 4 bytes to said buffer
16:02:17
dxtr
But i have gotten my four bytes so I don't want to hang anymore, I want to process them
16:03:04
therik
is there some useful lib for unix sockets? iolib seems messy, can't even compile now
16:07:51
phoe
orthogonal question: how can you be sure that you got to the end of the message and are able to process it?
16:09:35
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
16:14:04
dxtr
I found https://stackoverflow.com/questions/34125365/single-threaded-sequence-reading-multi-user-usocket-server that points out the same thing, basically
16:14:53
_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
16:33:00
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
16:35:20
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
16:35:35
dxtr
Guess one could make a loop with wait-for-input with a low timeout and then read a byte with read-byte
16:38:36
_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
16:42:08
dxtr
I *want* to read from the stream because I'm using cl-tls too (It's configurable in the stuff I'm doing)