<saravia>
phoe, sorry but .net core is the same of C#, becose Lovesan/bike tell me ".net core and c++" but i need interoperate -> C# Frameworks 4, is posible doc?
X-Scale has quit [Ping timeout: 265 seconds]
<phoe>
what's C# Frameworks 4?
<phoe>
Oh, I see.
X-Scale` is now known as X-Scale
<phoe>
No idea if that's possible.
<saravia>
but this work names "interoperate" no?
<saravia>
my new job requires visual studio, but to me is more inspiration "interoperate with common lisp + portacle (Emacs) xD"
<pjb>
saravia: AFAIK, there is no CL compiler targetting .Net. Instead, you can write the core of your application in Common Lisp, running in a separate process, and communicating with the .Net environment thru socketsr.
<sjl>
oni-on-ion: don't engage with the child, just report to freenode ops
<oni-on-ion>
sjl, i dont know how or who
<AS_Jon>
u have no basis to report me
brown121408 has joined #lisp
<sjl>
Or also I think Xach might have ops in here?
<phoe>
one sec, let me remember the commands
AS_Jon was banned on #lisp by phoe [*!*18d3e139@*.nc.res.rr.com]
AS_Jon was kicked from #lisp by phoe [AS_Jon]
<Josh_2>
What fun
<oni-on-ion>
excellent
AS_Jon has quit [Killed (Sigyn (Spam is off topic on freenode.))]
<phoe>
I'm a rusty operator since I literally have to remember the op/deop/kickban commands every single time
<phoe>
but still, it seems that I was first
<oni-on-ion>
thanks for it =) we could always have regular drills. =P
brown121408 has quit [Read error: Connection reset by peer]
brown121407 has joined #lisp
oxum has quit [Ping timeout: 260 seconds]
<phoe>
FYI, 18:41 -!- AS_Jon [18d3e139@cpe-24-211-225-57.nc.res.rr.com] has quit [Killed (Sigyn (Spam is off topic on freenode.))]
<MichaelRaskin>
phoe: you want to say you need a translator layer so you can execute a lisp form (in Emacs, I guess) and it would talk to chanserv in your name?
<phoe>
MichaelRaskin: my IRC is in an irssi session sitting on a tmux on a VPS. So, no emacs here.
<MichaelRaskin>
phoe: you say that as if Lisp cannot talk via sockets
brown121408 has joined #lisp
dale has joined #lisp
brown121407 has quit [Ping timeout: 265 seconds]
<Josh_2>
phoe: that's sad :(
bitmapper has joined #lisp
<MichaelRaskin>
On my system Lisp controls quite a bit of non-Lisp software
<koenig>
I'm literally right now banging my head trying to write a WeeChat plugin for ECL.
<jmercouris>
if you make me a moderator I can be of service
<koenig>
With the idea that you could script WeeChat with Common Lisp.
<oni-on-ion>
ohh there's a new ECL release coming up. after 3 years development. excited to see whats in it =)
<koenig>
I'm afraid that I'm not very far along. I know too little about ECL I think.
<koenig>
I'm calling cl_boot() inside the plugin code and am getting a nasty segfault / backtrace in ECL.
<oni-on-ion>
hmm let me see my code that uses it ..
<koenig>
I've been able to call cl_boot() from within a simple C main() that I've written, and then evaluate a simple Lisp form in a string. So I'm pretty sure I know how to do that part.
<oni-on-ion>
koenig, oh, ah... just cl_boot(argc, argv) first line in main()
whiteline_ has joined #lisp
<oni-on-ion>
but doesnt work as weechat plugin ?
<jmercouris>
ping jackdaniel he may know
<oni-on-ion>
i wonder if looking into cl_main() would reveal that weechat's own main conflicts with it. like setting interrupts or whathaveyou
<jmercouris>
are you sure that your plugin isn't segfaulting for some unknown reason? are you able to create/use the same plugin without ECL?
<koenig>
The ECL backtrace seems to get to ecl_init_module() which looks to be pretty far along in the initialization process.
lemoinem has quit [Ping timeout: 260 seconds]
lemoinem has joined #lisp
brown121408 has quit [Read error: Connection reset by peer]
<koenig>
I'm able to create a plugin that doesn't use ECL but does successfully write "Hello world" to the WeeChat core buffer.
ebrasca has quit [Remote host closed the connection]
whiteline has quit [Ping timeout: 268 seconds]
brown121407 has joined #lisp
william1 has quit [Ping timeout: 268 seconds]
hhdave has joined #lisp
hiroaki has quit [Ping timeout: 265 seconds]
<jmercouris>
OK
xkapastel has quit [Quit: Connection closed for inactivity]
<koenig>
But it was a good idea. :)
<koenig>
I think the next step is to build WeeChat with debugging enabled and ECL with debugging enabled and get a gdb attached to the process.
<oni-on-ion>
yeah. or, have the weechat plugin talk to a sepereate ECL process. =P
je4i has quit [Ping timeout: 264 seconds]
<koenig>
If I can trap cl_boot() maybe I can see exactly where things go haywire.
<oni-on-ion>
(too much work there)
<koenig>
oni-on-ion: I had considered that, but it seems kludgy to me.
<koenig>
I want the real deal here.
<oni-on-ion>
yeah. and point being using lisp and not c
stepnem_ has joined #lisp
<oni-on-ion>
at the very least you could put in cl_boot() to weechat's own main =) after checking out gdb .
stepnem has quit [Ping timeout: 268 seconds]
<oni-on-ion>
(very least effort*)
<koenig>
I've done a lot of systems programming in my career, but I am a neophite Lisper. Part of the point of this exercise is to learn a little more about ECL and then a lot more about Common Lisp when I use it to script WeeChat.
<oni-on-ion>
and would not have to restart weechat or the plugin while you are developing it
kajo has quit [Ping timeout: 260 seconds]
<koenig>
I think the right thing to do is to attach a remote gdb to the running WeeChat, then set the cl_boot() breakpoint, then trigger the plugin to load dynamically.
<koenig>
I've restarted weechat seems like a million times while trying to debug this. :)
<oni-on-ion>
ahh the nostalgia of systems programming =)
<koenig>
Yeah. I switched my career about 4 years ago to doing data science after spending about 25 years doing systems programming. So I've gotten an itch to do something "real" again.
je4i has joined #lisp
jmercouris has quit [Remote host closed the connection]
<oni-on-ion>
cool. i been doing system programming and graphic rendering for about 25 . i'm still in hiatus, not sure what i want or need to do yet.
je4i has quit [Ping timeout: 264 seconds]
hiroaki has joined #lisp
<MichaelRaskin>
koenig: BTW, are there many threads by the time ECL plugin is loaded?
awolven has joined #lisp
awolven is now known as clothespin
<MichaelRaskin>
(although it does look like it should not matter)
<koenig>
The WeeChat plugin developer documentation says that your plugin is not supposed to be using threads.
<koenig>
I tried building ECL with the correct --disable-thread option in configure. I verified that *features* in the ECL prompt do not say :THREADS.
<koenig>
But the ECL backtrace I get still seems to be telling me that I'm doing something with pthreads.
kajo has joined #lisp
<koenig>
I'm not sure whether the way I'm building it means "ECL doesn't use threads at all" or means "no user-facing threads are available".
<koenig>
gdb will tell me this, but probably rebuilding everything to allow me to attach a gdb to this mess is going to be about an hour's worth of work, so I have been poking sticks at other things for right now.
<koenig>
My intuition is telling me I just need to spend the time to get a tool attached to this that can let me see what's happening.
<MichaelRaskin>
strace will also tell you about any threads happenning
<koenig>
That's a pretty good suggestion. Let me try that.
<koenig>
But first, I have to eat some pancakes.
mangul has quit [Remote host closed the connection]
mangul has joined #lisp
gravicappa has quit [Ping timeout: 260 seconds]
vaporatorius has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
mangul has quit [Ping timeout: 260 seconds]
longshi has quit [Ping timeout: 260 seconds]
reg32 has joined #lisp
EvW has joined #lisp
<koenig>
Ok, one thing that may not be too nice is that WeeChat of course captures a bunch of signals with its own signal handlers, and of course so does ECL.
<MichaelRaskin>
Well, you always have an option to give up and spin a ECL process communicating with weechat via a socket…
<koenig>
There must be some way to do this. I can't believe that interpreters like Guile and Python and whatever don't do very similar things to what ECL does.
<koenig>
I'm just too ignorant of how ECL works internally to get it yet.
hhdave has quit [Ping timeout: 265 seconds]
<koenig>
The point is, in order to really participate with some topic (say, Common Lisp), you have to have some objective that focuses your attention. Now I have one: namely, this project. :)
<Josh_2>
Just how many system threads can I run before things start to go oof?
<jackdaniel>
koenig: if weechat spawns new processes, then in each new thread you need to call import_thread function (see examples/ directory for details)
<Josh_2>
I'm wondering if I should consider changing some of my functionality to green threads
<Josh_2>
I don't see my server having thousands of simultaneous connections
<jackdaniel>
Josh_2: if you count your processes in thousands then *if* green threads are an option *and* are well supported on your implementation *and* your program can run in such pseudo-parallel fashion then go for it
<koenig>
jackdaniel: I don't see import_thread called anywhere in any file throughout examples/ . I just did a grep -r.
<jackdaniel>
let me see
<eeeeeta>
<koenig> I'm literally right now banging my head trying to write a WeeChat plugin for ECL.
<jackdaniel>
koenig: see src/examples/import.c
<eeeeeta>
this seems like a cool project!
<Josh_2>
jackdaniel: well theres lots of libraries for green threads but I don't know how well they function
<Josh_2>
on SBCL
bacterio has quit [Quit: bacterio]
<jackdaniel>
exact function name is ecl_import_current_thread
<eeeeeta>
koenig: weechat is single-threaded, btw
bacterio has joined #lisp
bacterio has quit [Changing host]
bacterio has joined #lisp
<jackdaniel>
if it doesn't spawn new threads, then cl_boot(narg, argv); should be fine
<jackdaniel>
s/narg/argc/
bacterio has quit [Client Quit]
<koenig>
Yes, eeeeeta is right.
bacterio has joined #lisp
* eeeeeta
would be very interested in a weechat CL project ^_^
<jackdaniel>
do you try to statically link ecl or do you use dynamic linking?
Oladon has joined #lisp
bacterio has quit [Client Quit]
bacterio has joined #lisp
<koenig>
The WeeChat plugins are .so by definition. The WeeChat core invokes the dynamic linker to load them at runtime and then calls into an entry point in each .so called weechat_plugin_init() to initialize it.
<koenig>
My .so dynamically links to the ecl library.
<jackdaniel>
and when you run ecl binary from the same installation it works fine?
<koenig>
Correct.
<jackdaniel>
could you link the initialization code?
mangul has joined #lisp
<jackdaniel>
so I can look at the source code
<koenig>
Also works fine when I write a simple main() of my own that calls cl_boot() and passes in a C string with a simple Lisp form.
<koenig>
I'd have to move it to a place where there's a Web server running.
<jackdaniel>
please link the source code, maybe I'll be able to spot the problem (probably not though)
<jackdaniel>
maybe you could use something like pastebin?
<eeeeeta>
koenig: do you pass through argc and argh?
<eeeeeta>
argv*
<eeeeeta>
/have you tried with argc=0, argv=NULL or similar?
<koenig>
I've tried (1) passing through the argc/argv that WeeChat sends the plugin, (2) creating argc=1 and argv[0]="dummy" argv[1]=NULL, and (3) using argc=0 and argv[0]=NULL.
<jackdaniel>
koenig: does weechat have its own signal handlers?
<koenig>
Yes. Very many.
<jackdaniel>
OK, then that may be the problem. in that case you may want to disable ecl's signal handler
<koenig>
How can I build ECL to do this?
<jackdaniel>
I don't know from the top of my head, let me see
<eeeeeta>
looks like you might want to twiddle all of those boot options to FALSE?
<eeeeeta>
the TRAP_* ones
ebrasca has joined #lisp
<jackdaniel>
right, you may kill the traps on individal signals too
<eeeeeta>
oh huh, there's an option for a "Unix signal to communicate between threads"
<eeeeeta>
maybe that's interfering with a similar weechat mechanism
<eeeeeta>
?*
sjl has quit [Quit: WeeChat 2.2-dev]
<koenig>
Ok, let me try calling ecl_set_option() to set all of ECL_OPT_TRAP_* to False and ECL_OPT_SIGNAL_HANDLING_THREAD also to False.
bitmapper has quit [Ping timeout: 240 seconds]
<koenig>
The WeeChat core intercepts basically tons of signals for its own purposes, including I suspect SIGALARM so it can implement its own callback mechanism.
<koenig>
That's how it functions in a single thread.
<eeeeeta>
sounds good
<eeeeeta>
it says in the docs actually
<eeeeeta>
> Systems which embed ECL as an extension language may wish to deactivate the signal handling thread using the previously mentioned option.
pilne has quit [Read error: Connection reset by peer]
pilne has joined #lisp
<koenig>
Ok, that definitely improved things, but still no love. Looking at the stack trace right now.
<koenig>
ecl_module_init() somehow calls ecl_read_object_with_delimiter() to do something which is where things are going wrong. It gets into FEreader_error() after that, which I'm assuming is ECL's error handler for the reader.
whiteline_ has quit [Read error: Connection reset by peer]
<koenig>
ecl_module_init() appears to get invoked close to the end of cl_boot(), though, so that seems positive.
whiteline has joined #lisp
scymtym has quit [Remote host closed the connection]
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
ggole has quit [Quit: Leaving]
<koenig>
Ok, I'm feeling like I need to rebuild WeeChat and ECL both with debugging enabled so I can attach a gdb to everything. And probably need to go back and re-read documentation now that I have a better idea of what's going on.
<MichaelRaskin>
Of course, gdb will _also_ mess with signals
<rumbler31>
trying to mess with lisp-binary. walking through the diy doom series.
<rumbler31>
I get errors that don't make sense with just simple stuff like the above paste
<rumbler31>
the outcome is the same regardless of the use of flexi stream
mangul has quit [Ping timeout: 240 seconds]
rdh has joined #lisp
<Josh_2>
hmm, so I wrote a snippet of code that interrupts a thread, passes it a function and pushes the result of the thread evaluating the function to a structure that is currently global as I know the thread will be able to access it. I would like to have separate structures for each thread, how would I go about making sure that the thread and the structure is in the 'same environment'.
<Josh_2>
I don't really know the correct terminology ¯\_(ツ)_/¯
<phoe>
environment? no, why?
reg32 has quit [Remote host closed the connection]
<phoe>
make a global hashtable whose keys are thread objects and values are whatever you want, preferably with :weakness :key
<Josh_2>
hmm well that's what I wanted to avoid
<phoe>
and have each thread setf gethash with itself as a key
<phoe>
also, interrupting threads as a part of your normal program code is a bad idea™
whiteline has quit [Read error: Connection reset by peer]
<oni-on-ion>
has anyone ever heard of a communal REPL ? not like Jupyter. but like several users sharing the same lisp image ?
whiteline has joined #lisp
<jackdaniel>
how about multiple slime session connected to the same swank server?
<Josh_2>
Well the reason I was going to do it is because I have a thread that is constantly waiting to download packets from a stream and then pushes these into a queue, however there may be a time where I want another function to download a single packet, perhaps to confirm that the server received a specific type of packet. So I was thinking I can interrupt the thread and get it to download one packet and then return back to normal
<Josh_2>
function. Is this bad phoe ?
<oni-on-ion>
ohhh! i am wearing the wrong glasses today!
<Josh_2>
I can change the functionality if required, It's not a big deal, I've only really been dabbling with it ¯\_(ツ)_/¯
<oni-on-ion>
thanks jackdaniel , been about a week taking break from computer
<phoe>
it's a tiny chat written on top of swank+multislime
<phoe>
more like a proof of concept than like anything else
Lord_of_Life_ has joined #lisp
<Josh_2>
who needs irc when we can all connect to one lisp image and chat that was :D
<Josh_2>
way*
<jackdaniel>
(sb-ext:quit) voila
<jackdaniel>
irc is dead
<Josh_2>
well yes, that's a problem
Lord_of_Life has quit [Read error: Connection reset by peer]
<phoe>
exactly that, Lisp has no sandboxing
<Josh_2>
It would have to be high trust
<phoe>
trust is one thing
<phoe>
you'd also need everyone to be perfect enough to never corrupt the image or blow the stack
<Josh_2>
Only for chatting
<Josh_2>
high trust xD
<Josh_2>
we all pinky promise to only chat
Lord_of_Life_ is now known as Lord_of_Life
<shinohai>
`1
<phoe>
it's called irc
<Josh_2>
phoe: do you have an opinion on what I wrote?
<phoe>
Josh_2: looks like weird architecture to me and breaking of the single responsibility principle
blabagu has joined #lisp
<phoe>
why doesn't the original thread just push everything it downloads into a queue and something else grabs stuff from that queue and executes whatever code is needed?
<Josh_2>
That's what is going to happen
<Josh_2>
Haven't gotten to the processing part yet
<phoe>
why do you even need to interrupt the original thread then?
<phoe>
if the thread is supposed to just download packets, then why would you need to interupt it with something else that also downloads packets
<blabagu>
Hi! Is there any recent opensource web application lying around on github (or similar) that is written in Common Lisp? I'd like to get a feel for how developing something like that in CL might feel
<phoe>
blabagu: I'm working on one right now, but it is just the backend and internal logic - nothing network or web/REST/HTTP related just yet.
<phoe>
Poke me in about two weeks, I should have it ready then.
<phoe>
(Or kinda getting it ready. We'll see.)
<Josh_2>
hmmm
<blabagu>
I found https://github.com/turtl/api but it seems to be depracted since the project was rewritten in nodejs
zooey has quit [Remote host closed the connection]
zooey has joined #lisp
<rumbler31>
and that behavior is the same even without the explicit use of flexi streams
clothespin has quit [Ping timeout: 260 seconds]
<phoe>
rumbler31: could you try making a reproducible test case? this example breaks with #\I not being of type ub8
<rumbler31>
right, so comment out that one and try the next
<rumbler31>
that was my first problem
blabagu has quit [Remote host closed the connection]
<phoe>
ooh
<phoe>
hm
<phoe>
in WITH-OPEN-FILE, explicitly specify the stream element to be (unsigned-byte 8)
<rumbler31>
I assume I have to use streams of type (unsigned-byte 8) and lisp-binary takes care to read chars and convert to lisp strings, so says the docs. But then doing that, I get those blowups where the library wants to allocate a whole bunch
<rumbler31>
right, try running the next line
<phoe>
the second line gives me
<phoe>
There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION LISP-BINARY:READ-BINARY (1)> when called with arguments (HEADER #<FLEXI-INPUT-STREAM {10035C2513}>).
<rumbler31>
hmm
<rumbler31>
well
<rumbler31>
alright, remove the flexi stream make stream line
<phoe>
There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION LISP-BINARY:READ-BINARY (1)> when called with arguments (HEADER #<SB-SYS:FD-STREAM for "file /tmp/what.wad" {10039CB4E3}>).
<phoe>
nope
<rumbler31>
what
<rumbler31>
ok I guess I'll make a better test case
<phoe>
oh
<phoe>
ooooh
<phoe>
yes, I got it
oni-on-ion has quit [Ping timeout: 248 seconds]
<koenig>
jackdaniel: Okay, I've rebuilt WeeChat and ECL both with debug symbols. I can attach a gdb to the remote process and step through initialization.
oni-on-ion has joined #lisp
<koenig>
The problem happens in ECL's main.d:786. This is a call to ecl_init_module(OBJNULL,init_lib_LSP);