<Nilby>
Maybe you could wrap calls that need it to bt:interrupt-thread the main thread instead?
rvirding has quit [Ping timeout: 260 seconds]
FreeBirdLjj has quit [Ping timeout: 260 seconds]
<d4ryus>
jmercouris: do you load this from via slime/swank?
chewbranca has quit [Read error: Connection reset by peer]
shangul has joined #lisp
jhei has quit [Ping timeout: 246 seconds]
<jmercouris>
yes, I do
EvW has joined #lisp
<jmercouris>
Nilby: isn't that what trivial main thread does?
<d4ryus>
does it work if you: remove the quickload lines, remove the (start) line and run: sbcl --eval "(ql:quickload '(:trivial-main-thread :cl-webkit2))" --eval '(load "<the-file.lisp>")' --eval "(gtk-tutorial::start)"
<jmercouris>
Let me give that a try
FreeBird_ has quit [Remote host closed the connection]
<Nilby>
Yes, but even better, so nevermind.
<jmercouris>
why not --load file.lisp? instead of --eval?
<d4ryus>
jmercouris: because i did not remember the syntax :)
<jmercouris>
d4ryus: there is some improvement for sure
<jmercouris>
it doesn't crash on window resize
<jmercouris>
still, it doesn't draw, despite the widget being created
<jmercouris>
again because it is not in the main thread
<jmercouris>
I believe the problem is that within-main-loop is within the main GTK loop, not the main thread
<d4ryus>
jmercouris: hmm, there should be no other thread besides the main thread now
<jmercouris>
is the GTK thread not a separate one?
<jmercouris>
I try to restart Xquartz, maybe there is state
<jmercouris>
no change
<jmercouris>
I monitor the network, I even see the requests
<jmercouris>
if there is only one thread, calling wrapping everything in trivial-main thread should cause it to lock?
EvW has quit [Ping timeout: 246 seconds]
<jmercouris>
well, seems not
EvW1 has joined #lisp
billstclair has quit [Ping timeout: 248 seconds]
wxie has joined #lisp
XachX has quit [Ping timeout: 248 seconds]
<d4ryus>
jmercouris: from reading the tutorial, maybe you need to add the container first, before doing webkit-web-view-load-uri?
<jmercouris>
I'm desperate at this point, so why not :-D
milanj has joined #lisp
<jmercouris>
it is now the final form in within-main-loop
<jmercouris>
so outside of SLIME, just in a terminal: sbcl --load webview-gtk.lisp
<Nilby>
Are other cl-cffi-gtk programs working in mac in the same setup, just not with webkit?
<d4ryus>
jmercouris: does the demo in demo/simple-browser.lisp work? (the difference seems to be that it calls gtk:join-gtk-main after within-main-loop)
tazjin has quit [Ping timeout: 245 seconds]
jmercouris has quit [Ping timeout: 268 seconds]
wxie has quit [Ping timeout: 265 seconds]
dddddd has joined #lisp
pfdietz has joined #lisp
brandelune has quit [Quit: This computer has gone to sleep]
cosimone has quit [Quit: Terminated!]
<pfdietz>
phoe: the hu.dwim style puts me off a bit. It feels like they've overlaid too many differences on top of conventional CL idioms.
<phoe>
pfdietz: I feel the same way. To write their libs, they've defined their own language that they use instead of CL.
cosimone has joined #lisp
<Odin->
... isn't that partly the point?
jmercouris has joined #lisp
<pfdietz>
All things in moderation.
<jmercouris>
Nilby: other programs are working with this set-up
<phoe>
Odin-: their code usually has not a single DEFUN or DEFPARAMETER or DEFCLASS
<jmercouris>
Nilby: I can show every widget except webview widgets, there seems to be something unique about them
<phoe>
everything is being defined using a single extensible DEF macro
<Odin->
phoe: Hm. That is going a bit far, granted.
<phoe>
that's one novel thing that their code introduces and utilizes
<phoe>
I mean, sure, if you have an extensible SETF, why not have an extensible DEF
<pfdietz>
This is all tolerable until something breaks. Then you have to learn their DSL to figure out what is going on.
brandelune has joined #lisp
<jmercouris>
what I would likke to know how is to query which thread something is running on
<phoe>
but it is one more idiom that you have to understand and/or macroexpand in order t---
<phoe>
this
<jmercouris>
can I put a statement or so within the body of a defun that will print it's thread?
<phoe>
(print (bt:current-thread))
<jmercouris>
can someone help me understand CFFI a little bit better
<jmercouris>
let's say we call some C function, we are still in the same thread/process right?
<Nilby>
I remeber having trouble on mac, specificly with having to kick webkit threads. Sorry, my memory is fuzzy on it though.
<phoe>
you call a C function but this does not cause anything to switch threads
<jmercouris>
Nilby: I wish you remembered more
<jmercouris>
Nilby: I know certainly that when I exit my GTK program even if i call leave-gtk-main I have to restart SBCL to launch anything
<phoe>
the control of that thread switches to C code, and then eventually goes back to Lisp
<jmercouris>
it seems that remenants remain
patlv has joined #lisp
frgo has quit [Remote host closed the connection]
chewbranca has joined #lisp
Guest19180 has joined #lisp
tazjin has joined #lisp
<pfdietz>
The hu.dwim code would feel better if they had copious documentation. But I don't see many docstrings in there. Sad, because they could have extended documentation as well. That would have been a real contribution.
lukego has joined #lisp
<jmercouris>
I do have a setup that can launch a window successfully that shows a webkit view, just not with cl-cffi-gtk, I'm going to investigate to see if the thread count is different and what is running on which thread, perhaps it will provide some clues as to what is going on
patlv has quit [Client Quit]
Bike has joined #lisp
frgo has joined #lisp
<Nilby>
Sorry, I'm not much help, since my mac broke and also I gave up making a webkit lisp browser.
jhei has joined #lisp
rvirding has joined #lisp
<jmercouris>
Nilby: what is your github / repository for your old work?
gjnoonan has joined #lisp
<Nilby>
I never put it up, since it was crap. I was mostly doing it so I could make a dark mode hacking CSS in lisp.
<jmercouris>
Oh I see
<jmercouris>
leider
lucasb has joined #lisp
<phoe>
pfdietz: Lisp code that doesn't document internally used macros is buggy Lisp code
Guest19180 has quit [Ping timeout: 272 seconds]
<jmercouris>
I disagree, lack of documentation is not a bug
<jmercouris>
unpleasant, annoying, but not a bug
grewal has quit [Ping timeout: 265 seconds]
<pfdietz>
A primary purpose of code is to communicate to people reading it. Code that fails at a primary purpose is bugged.
<phoe>
it is a bug
<phoe>
code is meant to be read first and foremost
brandelune has quit [Quit: This computer has gone to sleep]
amerlyq has quit [Quit: amerlyq]
<phoe>
if your code is meant to be used by other people it means it is meant to be read by other people
<jmercouris>
someone reading the Peps? :-D
grewal has joined #lisp
<jmercouris>
anyways, it doesn't matter much, I probably shouldn't have said anything
<pfdietz>
To be charitable, documentation is often deprioritized.
<montaropdf>
pfdietz: so true in almost every project I work for :()
<montaropdf>
s/()/(/
<pfdietz>
I like the frogface emoticon
* montaropdf
curses emacs auto-complete
<phoe>
I try to be the change I want to see in the world and at least document the basics of the stuff I set for public consumption
jonatack has joined #lisp
<jmercouris>
OK
<jmercouris>
here is the more fascinating thing
<jmercouris>
I put as phoe suggested (print (bt:current-thread))
<pfdietz>
They had an opportunity with this def macro to put in enriched documentation. Not just strings, but structured information about the things being defined. All sort of uses for that.
<jmercouris>
when I run from REPL I get two different threads
<montaropdf>
jmercouris: your run the repl from slime/sly?
<jmercouris>
my REPL is SLIME
swills has quit [Ping timeout: 265 seconds]
<jmercouris>
my swank lisp only contains (setf swank:*globally-redirect-io* t)
<montaropdf>
So I guess this is why you have 2 threads
<montaropdf>
One is for slime itself.
<montaropdf>
You are working with a mac?
swills has joined #lisp
<jmercouris>
I am working with a mac, yes
<montaropdf>
I guess, that there is an issue with mac and thread allocation/access, but I can't recall what.
<jmercouris>
always so close, yet so far :'(
<jmercouris>
how can it be there is only one print?
<montaropdf>
It is a feature of MAC
<jmercouris>
that just blows my mind
<jmercouris>
as soon as we join the GTK main thread output ceases?
EvW1 has quit [Ping timeout: 240 seconds]
<jmercouris>
interesting interesting
<jmercouris>
as soon as I kill the window, I get the second print
<jmercouris>
WHAT?
<Nilby>
One thing I used to check stuff was running under dtrace/strace on the command line to see what syscalls it's actually doing, where it might get stuck.
<jmercouris>
I will try, thank you
<jmercouris>
I'm also going to see which threads the working code is using
stepnem_ has joined #lisp
<Nilby>
It can help with threads becuase it can cross library c-code boundaries. Sometimes there's another sneaky thread you can't see.
stepnem has quit [Ping timeout: 240 seconds]
shifty has quit [Ping timeout: 260 seconds]
<phoe>
jmercouris: maybe the buffer wasn't flushed after the print
<phoe>
(print ...) (finish-output)
shifty has joined #lisp
<jmercouris>
I check phoe
<jmercouris>
OK, mystery solved
<jmercouris>
you are correct
<jmercouris>
probably because it immediately switches contexts or something before it can write to stdout or something
<Nilby>
Heh. I think that's why ccl used to do a sometimes annoying periodic (finish-output) in a background thread.
<jmercouris>
you know
<jmercouris>
I didn't try doing this in CCL
<jmercouris>
I'm going to try that
<Nilby>
CCL is "Made for MacOS" :P (macos 7 that is)
jibanes has quit [Ping timeout: 260 seconds]
jibanes has joined #lisp
<jmercouris>
CCL is made for you and me
* jmercouris
hums CCL theme song
orivej has quit [Ping timeout: 268 seconds]
swills has quit [Ping timeout: 260 seconds]
swills has joined #lisp
icov0x29a has joined #lisp
pjb has quit [Ping timeout: 272 seconds]
ebrasca has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
rippa has joined #lisp
pjb has joined #lisp
frgo has quit [Ping timeout: 265 seconds]
cosimone has quit [Quit: Quit.]
shifty has quit [Ping timeout: 260 seconds]
Cymew has quit [Ping timeout: 268 seconds]
shifty has joined #lisp
cosimone has joined #lisp
|Pirx| has joined #lisp
jmercouris has quit [Ping timeout: 260 seconds]
icov0x29a has quit [Ping timeout: 252 seconds]
kajo has quit [Ping timeout: 252 seconds]
v88m has joined #lisp
bjorkintosh has joined #lisp
frgo has joined #lisp
ljavorsk has quit [Ping timeout: 265 seconds]
frgo has quit [Ping timeout: 272 seconds]
scymtym has quit [Ping timeout: 260 seconds]
gxt has quit [Ping timeout: 240 seconds]
dddddd has quit [Remote host closed the connection]
jmercouris has joined #lisp
sammich has quit [Ping timeout: 260 seconds]
smazga has joined #lisp
frgo has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
montaropdf has quit [Quit: ERC (IRC client for Emacs 26.3)]
scymtym has joined #lisp
shifty has quit [Ping timeout: 272 seconds]
shifty has joined #lisp
sammich has joined #lisp
fivo has joined #lisp
<p_l>
Nilby: which is why it doesn't work on release day for last two OS releases ;)
<p_l>
(or more correctly, OSX is that bad)
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
Guest19180 has joined #lisp
Guest19180 has quit [Ping timeout: 260 seconds]
shifty has quit [Ping timeout: 268 seconds]
<Nilby>
Yes. Ironicly maybe SBCL/CMU/Spice Lisp was made to run on the Mach kernel? Except it used to trigger a bad problem in Mach not even the BSD part.
gareppa has joined #lisp
jonatack has quit [Ping timeout: 260 seconds]
MCP has joined #lisp
MCP is now known as Guest38178
ebzzry has quit [Ping timeout: 265 seconds]
ebzzry has joined #lisp
gko_ has quit [Ping timeout: 268 seconds]
ebzzry has quit [Read error: Connection reset by peer]
gnufr33d0m has joined #lisp
ebzzry has joined #lisp
v_m_v has quit [Remote host closed the connection]
fivo has quit [Quit: WeeChat 2.4]
manualcrank has quit [Quit: WeeChat 1.9.1]
stepnem has joined #lisp
gareppa has quit [Quit: Leaving]
stepnem_ has quit [Ping timeout: 272 seconds]
LiamH has joined #lisp
<p_l>
IIRC a program written in CCL once triggered a bug core to Mach in a way that was close to impossible to patch for years
<p_l>
CMU did work for some time on Mach, afaik, but it also worked on something that predated Mach
jonatack has joined #lisp
orivej has joined #lisp
EvW has joined #lisp
sjl_ has joined #lisp
davepdot_ has quit [Ping timeout: 240 seconds]
<Nilby>
If it's the one I remember, it popped up a big message from the kernel every few instructions, which was hard to get rid of. I've never seen any other program trigger it.
rozengla` has joined #lisp
rozengla` has quit [Client Quit]
gareppa has joined #lisp
rozengla` has joined #lisp
rozengla` has quit [Client Quit]
gareppa has quit [Remote host closed the connection]
rozenglass has quit [Ping timeout: 268 seconds]
hhdave has quit [Quit: hhdave]
phlim has quit [Quit: WeeChat 2.4]
rozenglass has joined #lisp
smazga has quit [Ping timeout: 272 seconds]
smazga has joined #lisp
<Xach>
Hmm, what's a nice way to find out of a generic function was created implicitly via defmethod?
<Xach>
"find out if", rather
sjl_ has quit [Quit: WeeChat 2.3-dev]
<scymtym>
Xach: if you can live with an implementation-dependent solution as well as C-c C-c and (make-instance 'standard-generic-function …) giving false positives, you could check whether the generic function has a source location
akrl`` has quit [Read error: Connection reset by peer]
akrl`` has joined #lisp
rozenglass has quit [Ping timeout: 268 seconds]
manicennui has joined #lisp
manicennui has quit [Client Quit]
jmercouris has quit [Ping timeout: 260 seconds]
Guest19180 has joined #lisp
jmercouris has joined #lisp
Guest19180 has quit [Ping timeout: 272 seconds]
jmercouris has quit [Remote host closed the connection]
dale_ has joined #lisp
dale_ is now known as dale
z147x has joined #lisp
m00natic has quit [Remote host closed the connection]
z147d has quit [Remote host closed the connection]
Necktwi has quit [Ping timeout: 260 seconds]
manicennui has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
|Pirx| is now known as |Pirx_off|
Necktwi has joined #lisp
ArthurStrong has joined #lisp
adriano1 has quit [Ping timeout: 260 seconds]
adriano1 has joined #lisp
adriano1 has quit [Ping timeout: 268 seconds]
papachan has joined #lisp
CrazyPython has joined #lisp
zooey has quit [Ping timeout: 240 seconds]
|Pirx_off| is now known as |Pirx|
zooey has joined #lisp
shangul has quit [Ping timeout: 272 seconds]
buffergn0me has joined #lisp
efm has quit [Ping timeout: 260 seconds]
pirmino has quit [Ping timeout: 240 seconds]
pirmino has joined #lisp
manualcrank has joined #lisp
Nilby has quit [Read error: Connection reset by peer]
DGASAU has quit [Read error: Connection reset by peer]
DGASAU has joined #lisp
Sauvin has quit [Ping timeout: 260 seconds]
efm has joined #lisp
gareppa has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
Posterdati has joined #lisp
gareppa has quit [Quit: Leaving]
gnufr33d0m has quit [Quit: gnufr33d0m]
varjag has joined #lisp
dddddd has joined #lisp
orivej has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
pfdietz has quit [Remote host closed the connection]
pfdietz has joined #lisp
ggole has quit [Quit: Leaving]
cl-arthur has joined #lisp
Guest19180 has joined #lisp
EvW has quit [Quit: EvW]
ebzzry has quit [Read error: Connection reset by peer]
Guest19180 has quit [Ping timeout: 268 seconds]
icov0x29a has joined #lisp
CrazyPython has quit [Read error: Connection reset by peer]
icov0x29a has quit [Read error: Connection reset by peer]
lucasb has quit [Quit: Connection closed for inactivity]
Posterdati has joined #lisp
Posterdati has quit [Client Quit]
Posterdati has joined #lisp
izh_ has joined #lisp
pfdietz has quit [Remote host closed the connection]
scymtym has quit [Ping timeout: 260 seconds]
pfdietz has joined #lisp
denis_ has joined #lisp
denis_ has quit [Client Quit]
izh_ has quit [Client Quit]
izh_ has joined #lisp
jeosol has quit [Remote host closed the connection]
LiamH1 is now known as LiamH
efm has quit [Ping timeout: 272 seconds]
milanj has joined #lisp
katco has quit [*.net *.split]
SumoSud0 has quit [*.net *.split]
knobo has quit [*.net *.split]
knobo has joined #lisp
EvW has joined #lisp
SumoSud0 has joined #lisp
rvirding has quit [Ping timeout: 240 seconds]
notzmv has quit [Ping timeout: 268 seconds]
rvirding has joined #lisp
narimiran has quit [Ping timeout: 260 seconds]
vap1 has joined #lisp
vaporatorius has quit [Ping timeout: 260 seconds]
efm has joined #lisp
gravicappa has quit [Ping timeout: 240 seconds]
Bike has quit [Remote host closed the connection]
Bike has joined #lisp
EvW has quit [Ping timeout: 260 seconds]
efm_ has joined #lisp
efm has quit [Ping timeout: 260 seconds]
scymtym has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
okflo has joined #lisp
stepnem has quit [Ping timeout: 268 seconds]
stepnem has joined #lisp
efm_ has quit [Quit: Konversation terminated!]
Khisanth has quit [Ping timeout: 265 seconds]
srji has joined #lisp
srji has quit [Client Quit]
srji has joined #lisp
Khisanth has joined #lisp
Guest19180 has joined #lisp
brettgilio has quit [Ping timeout: 246 seconds]
Guest19180 has quit [Ping timeout: 260 seconds]
CrazyPython has joined #lisp
brettgilio has joined #lisp
frodef has joined #lisp
okflo has left #lisp ["ERC (IRC client for Emacs 28.0.50)"]
cosimone has quit [Quit: Quit.]
jeosol has joined #lisp
gnufr33d0m has joined #lisp
asarch has joined #lisp
papachan has quit [Ping timeout: 265 seconds]
izh_ has quit [Remote host closed the connection]
jfb4_ is now known as jfb4
EvW1 has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
nullniverse has joined #lisp
Guest19180 has joined #lisp
Bike has quit [Quit: Bike]
CrazyPython has quit [Read error: Connection reset by peer]
asarch has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
ArthurStrong has quit [Quit: leaving]
cl-arthur has quit [Remote host closed the connection]
<mrcom>
Xach: (/me emerges from rabbit hole): Well, something that _doesn't_ work in SBCL is (SB-IMPL::INFO :FUNCTION :WHERE-FROM <func name>). DEFGENERIC sets WHERE-FROM to :DECLARED, but then calls ENSURE-GENERIC-FUNCTION which clobbers it to :DEFINED-METHOD. compiler/globaldb.lisp says that :DECLARED is supposed to trump :DEFINED-METHOD, but ain't so.