<prokhor__>
the cause for my recent idea were the discussions here on collaborative environments & running lisp images in a kind of container recently...
<beach>
I see.
<prokhor__>
my idea begins with organizing code in packages which can consist of standard packages of therir own
Oladon has quit [Quit: Leaving.]
<beach>
Do you mean "packages" as in the Common Lisp class?
<mfiano>
inb4 fcge's
<prokhor__>
then running each of those "packages of higher order" in a separate process but maintaining interprocess communications
<prokhor__>
i think i imagine them similar to your modules in sicl
<prokhor__>
?
<prokhor__>
like:
<mfiano>
More like a limited subset of first class global environments
<beach>
prokhor__: And by "process", do you mean an OS process?
<prokhor__>
such a "package of higher order" would be capable of hosting a complete cl- dialect with all its packages (eg: cl-user etc)
<prokhor__>
it can be an os process
<prokhor__>
but i could also imagine some kind of capabilities...
<mfiano>
Have you read beach's thoughts on the bad idea of OS processes?
<prokhor__>
i did... i am tooo stupid & too less innovative to fully encompass them for my weird ideas ;)
<prokhor__>
so basically:
<mfiano>
But a first class global environment is a way to have completely separate environments capable of loading packages into the the same image, perhaps even different versions of them.
<mfiano>
and the latest idea is to do so with delta changes, though maybe this is just for bootstrapping, so you can derive an environment from another with low overhead.
<prokhor__>
each of those processes would be a lisp image of its own (single user), the changes therein would be combined in a separate process (lets call them env for brevity) and for testing the product of collaboration could be run in still anoter env foer testing
<prokhor__>
one benefit would be: those envs could run completely differrent cl-dialaects, collaborating where possible..
<mfiano>
I am unsure what a CL dialect is
<beach>
prokhor__: It sounds too advanced for me to understand. Maybe mfiano can do better.
<prokhor__>
like clisp or sbcl
<mfiano>
That is called a CL implementation
<prokhor__>
for brevity:
<prokhor__>
i hacked this porposal together for a friend yeasterday:
<prokhor__>
beach: as i understood, your modules in sicl have some similar properties (?) like being able to be compiled by different compilers...
<mfiano>
It's hard to make sense of your writing, and it is not very well-specified to give my opinion.
<prokhor__>
just give me, what comes to your mind..
<prokhor__>
it can be destroying, if yu like...
yauhsien has joined #commonlisp
<prokhor__>
its also the work of like 15 mins, so its only the sketch of an idea, but:
<mfiano>
My first impression is I think you're severely underestimating the amount of work involved, and over-simplifying the idea.
<beach>
prokhor__: SICL first-class global environments are much more limited. The address space is always shared and so is the memory manager, so there is not much room for a lot of variation.
<prokhor__>
it should be an attempt to achieve a kind of "multiuser images" making them accessible for each other be making an extra namespace layer (thats wy i took the "package" metaphor)
<mfiano>
beach: Will FGCE's be exposed to the client of the completed implementation, such that they could for example, Quickload separate dependency graphs with conflicting package names in different namespaces?
<mfiano>
FCGE's*
<beach>
mfiano: That's the plan, yes.
<mfiano>
Great!
<prokhor__>
beach: would it be possible to implement some kind of "extra namespace layer"
Sankalp has quit [Ping timeout: 240 seconds]
<prokhor__>
like "foo:cl-user:defun" or "bar:somepackage::somefun"
<prokhor__>
?
<mfiano>
Allegro has hierarchical packages if I recall correctly.
<beach>
"possible" for whom?
<mfiano>
It would be non-standard though.
Sankalp has joined #commonlisp
<prokhor__>
one of my imaginated benefits would be:
<beach>
prokhor__: I am notorious for not understanding what people are trying to communicate unless the ideas are very precise and described with consistent terminology. I am afraid I don't have a chance to understand your ideas in their current state. I'll have a look once you have everything written down in a coherent document.
<mfiano>
Such a thing would be inherently coupled to the Lisp reader. You'd probably have to replace the reader of your favorite implementation by extending a portable one like Eclector
<prokhor__>
as most cl implementations use clos (other lisps as well) , one could even incorporate bitrotting stuff in old implementations (such as symbolics lisp)
<mfiano>
I am also having trouble understanding.
<prokhor__>
beach: i know there would be a lot of conceptual work but: does it at least sound worth trying to do so?
<mfiano>
It feels like I am skipping around chapters in a dense book.
* mfiano
goes back to code
Brucio-61 has joined #commonlisp
<beach>
prokhor__: You need to decide that for yourself. I don't understand enough of it to give any advice.
<prokhor__>
obviously that idea is c**p atm, maybe i will come back (if theres) a better version of the concept..
<prokhor__>
beach: mfiano: thx anyway: if it doesnt make sense for you two, there possibly is no sense at all...
<prokhor__>
beach: if i would try to implement such an extra namespace layer for sicl modules (with limited lisp knowledge): where would i begin? what should i read?
<beach>
prokhor__: SICL is nowhere near a state where you could do that.
<prokhor__>
does it seem possible to you, to run an image of an implementation i a separate os process?
<prokhor__>
in a
semz_ has joined #commonlisp
<mfiano>
Isn't that what we already do. All modern OS's use seprate address spaces for applications.
<beach>
The minute you talk about inter-process communication, I am lost. Because now you have to think of object liveness in different address spaces.
<mfiano>
prokhor__: Study how the Lisp reader works, learn how to write a parser, study Eclector.
<mfiano>
Just a few suggestions to put you on your life's journey.
<beach>
... and EQ-ness across address space. My brain is too small for such things.
<prokhor__>
thx :) thats all i needed: some hints..
semz has quit [Ping timeout: 248 seconds]
<mfiano>
and beach is right. It would be quite a feat to pull that off. Even sxhash is implementation-dependent. I have no idea how you'd check for EQ-ness, between separate address spaces, not to mention all the incompatible implementation-specific behaviors.
<mfiano>
This is why we have different implementations. The standard is very flexible in what is considered conforming, and bridging them together would be a fool's errand
<mfiano>
I think it is more than what one would call a pipe dream.
<prokhor__>
i somehow thought of simply reading all defmacros of a given implementation
<mfiano>
What does a macro have to do with any of it?
<prokhor__>
let me be more precise: if therre were sourc code definitions of all commands of an implementation...
<prokhor__>
but i am sure youre right - a pipe dream...
<mfiano>
I think there are serious flaws in your logic there.
<mfiano>
I am also unsure of the definition of command as it pertains to Common Lisp.
notzmv has quit [Ping timeout: 246 seconds]
<prokhor__>
i guess your feedback is already valuable enough for me: thats one cause i asked a stupid question instead of wasting a lot of time..
<prokhor__>
also: pls consider i am still an undergrad, so sry again for bothering...
notzmv has joined #commonlisp
<mfiano>
No problem. Just continue learning and studying Common Lisp and you may form ideas that have weight to them.
<prokhor__>
i hope, your not angry..
<prokhor__>
sometimes people think, some of my ideas are at least original, sometimes there is utter rubbish :)
<prokhor__>
it sometimes helps, seeing it through the eyes or others...
<mfiano>
I don't get angry very easily. I would start lower, and begin learning Common Lisp. There are some holes in your knowledge that can be better solved by asking very specific questions in #clschool.
igemnace has quit [Remote host closed the connection]
<prokhor__>
thx, joined...
<mfiano>
Maybe give a book a read. I think you have a vague idea of Common Lisp, and should not get ahead of yourself. I don't mean any offense. I only wish the best in your learning path.
<prokhor__>
last book i read was practical common lisp, although only selective...
<mfiano>
That book is best read linearly.
<mfiano>
Cover to cover, doing all code exercises (the Practical chapters)
<mfiano>
Of course stopping to ask questions when something doesn't make sense to you.
<prokhor__>
befora that, it was successful lisp, i think... that one cover to cover though..
notzmv has quit [Ping timeout: 248 seconds]
<prokhor__>
i usually learn best by giving myself asome project, learning all the neccessary stuff along the way...
<prokhor__>
but of course not, if its a moonshot - or pipe dream...
<mfiano>
No book can teach you how to be a good programmer. You can only learn this by _doing_.
<mfiano>
You have to graduate your projects.
<mfiano>
I mean, increase them in complexity. Start small.
<mfiano>
Make a tic-tac-toe game :)
<prokhor__>
how do i estimate the learning courve of one?
<prokhor__>
does conways life count?
<mfiano>
It counts for something, but it is a little more advanced than a textual program.
<mfiano>
Cellular automata is simple, but not at the bottom in my book.
<prokhor__>
may i ask: what is your background? (knowing, beach has a teaching background)
<mfiano>
Graphics programming mostly.
<mfiano>
Land of Lisp might be a book you can read.
<mfiano>
I haven't read it but I heard it focuses on interactive text games.
<prokhor__>
i tried....
<prokhor__>
i quickly found those "small bit" examples kind of boring..
<mfiano>
I must go now, but I think you should continue to ask these types of questions in #clschool.
<beach>
That's not my problem with it. The problem is that it is absolutely full of errors.
<beach>
So it is likely to be misleading to newbies.
Bike has quit [Quit: Connection closed]
<mfiano>
It's not a very technical book, so I am not surprised. It's supposed to be a fun introduction to Lisp in general I heard, not an pedagogical introduction to Common Lisp in any form that would be accepted to someone well-versed in the terminology and idioms.
Mandus has quit [Ping timeout: 256 seconds]
<beach>
I don't see how "fun" excludes precision.
Mandus has joined #commonlisp
<mfiano>
It would not be fun to a pedant.
tyson2 has quit [Remote host closed the connection]
aartaka has joined #commonlisp
acebulf has quit [Ping timeout: 276 seconds]
semz_ is now known as semz
livoreno has joined #commonlisp
xantoz has quit [Ping timeout: 245 seconds]
triffid has joined #commonlisp
jamesmartinez has joined #commonlisp
notzmv has joined #commonlisp
guest74 has quit [Ping timeout: 260 seconds]
jmdaemon has quit [Ping timeout: 260 seconds]
random-jellyfish has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
yauhsien has joined #commonlisp
poselyqualityles has quit [Quit: bedtime]
shka has joined #commonlisp
yauhsien has quit [Ping timeout: 256 seconds]
schjetne has quit [Remote host closed the connection]
schjetne has joined #commonlisp
yauhsien has joined #commonlisp
schjetne has quit [Ping timeout: 256 seconds]
Inline has joined #commonlisp
notzmv has quit [Ping timeout: 248 seconds]
treflip has joined #commonlisp
yauhsien has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
notzmv has joined #commonlisp
notzmv has quit [Ping timeout: 240 seconds]
schjetne has joined #commonlisp
notzmv has joined #commonlisp
ttree has quit [Ping timeout: 252 seconds]
akoana has quit [Quit: leaving]
McParen has joined #commonlisp
notzmv has quit [Ping timeout: 248 seconds]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
notzmv has joined #commonlisp
yauhsien has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
attila_lendvai has joined #commonlisp
yauhsien has quit [Ping timeout: 256 seconds]
yauhsien has joined #commonlisp
igemnace has joined #commonlisp
lisp123 has joined #commonlisp
attila_lendvai has quit [Ping timeout: 252 seconds]
jgart has quit [Remote host closed the connection]
jgart has joined #commonlisp
cage has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
random-nick has joined #commonlisp
lisp123 has joined #commonlisp
Inline__ has joined #commonlisp
jgart has quit [Remote host closed the connection]
Inline is now known as Guest4496
Guest4496 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
Inline__ is now known as Inline
utis has joined #commonlisp
<utis>
seems that sly (now?) indents the first line after `(defmethod ...` incorrectly (all the way to the method name). is there a quick fix for this?
rotateq has joined #commonlisp
<utis>
oh, this seems to be triggered by something in emacs 29.0.50
onebitboy has left #commonlisp [#commonlisp]
<phadthai>
hmm there may be a way to switch between native emacs and slime lisp indenting modes
<phadthai>
I seem to remember about this but would have to check myself for details
Inline has quit [Quit: Leaving]
yauhsien has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
Inline has joined #commonlisp
yauhsien has quit [Ping timeout: 256 seconds]
flip214 has quit [Ping timeout: 260 seconds]
flip214 has joined #commonlisp
Dynom has joined #commonlisp
flip214 has quit [Ping timeout: 246 seconds]
flip214 has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 256 seconds]
Lord_of_Life_ is now known as Lord_of_Life
orestarod has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
MajorBiscuit has joined #commonlisp
aeth has quit [Ping timeout: 256 seconds]
aeth has joined #commonlisp
aartaka has quit [Ping timeout: 256 seconds]
aartaka has joined #commonlisp
lisp123 has quit [Read error: Connection reset by peer]
xaotuk has joined #commonlisp
Madsy has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
lisp123 has joined #commonlisp
matt` has joined #commonlisp
slowButPresent has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
mfiano has quit [Quit: WeeChat 3.5]
aartaka has joined #commonlisp
mfiano has joined #commonlisp
yauhsien has joined #commonlisp
analogsalad has joined #commonlisp
<beach>
I just learned that the documentation for Alexandria is generated from documentation strings. That would explain why it is so skimpy in places.
<beach>
My theory is that programmers avoid significant documentation strings because, as I often point out, they are noise to the maintainer.
<mfiano>
That's no excuse since they can be decoupled from their documenting form.
<beach>
That's what I do myself, but many people object to that, since they like the code and the documentation to be physically close together.
<mfiano>
So the issue it seems is just ignorance then? I mean if it's noise, decouple it. Either way, write documentation to complement your work.
<beach>
I think there might be a somewhat schizophrenic attitude. On the one hand, people want the code and the documentation close together. But then it becomes noise. So then it must be kept short.
<lisp123>
I find all good programs have good doc strings -- I don't use any code that doesn't out of principle
<beach>
lisp123: Good to know. But that's not the issue here.
<pjb>
beach: I'd propose better tools: when you navigate to a function in an emacs buffer, the documentation should be fetched automatically by emacs and displayed in an adjacent window.
<beach>
lisp123: The issue is whether you put the documentation string together with the code it documents, or whether you separate it and use (SETF DOCUMENTATION).
<beach>
pjb: I totally agree.
<mfiano>
Sometimes I think Common Lisp is too flexible. Imagine #'(setf documentation) that is called at runtime.
<lisp123>
beach: I think both are fine, and am flexible to accept both
<mfiano>
THat certainly has it's uses, but could royally confuse these poor documentation generation tools.
<pjb>
beach: also, this is one motivation for an emacs written in Common Lisp: easier to maintain this tool layer for CL developers…
<mfiano>
its*
<beach>
lisp123: As a user, you won't see the difference.
<beach>
lisp123: I am personally opposed to documentation strings.
<beach>
For one thing, they can be in only one language, except if you go to great lengths to do (SETF DOCUMENTATION) at run time.
<pranavats>
I think there can be some elisp code to collapse the docstrings for visual aid. Or use literate programming and put code and prose together like books.
<beach>
Furthermore, it becomes difficult to know where to put overall architecture information.
<beach>
So the result is an incoherent collection of unrelated information.
<beach>
Also, there is no way to put things like references (links) in documentation strings, or even to use fonts to make it more readable. They are just way too limited.
<beach>
Now for Alexandria, there is no particular architecture, so it doesn't matter there.
<beach>
But for most libraries, documentation strings only is a disaster.
<lisp123>
beach: I like to keep doc strings but then do an additional document with prose
<lisp123>
But I think everyone thinks differently, so as long as there is _some_ documentation somewhere, I'm grateful
<lisp123>
But I admit its mostly out of habit when it comes to doc strings for me. I don't think they are particularly insightful since mine mostly regurgitate what the function does
<beach>
lisp123: But now you confuse the two audiences again. The code is meant for the maintainer and the documentation string for the user.
<beach>
That's why documentation strings in code are noise.
<beach>
The maintainer already knows what the code does.
<mfiano>
Documentation strings aren't to know what the code does. They are instructions for the user.
<beach>
And that's why comments are different from documentation string.
<mfiano>
The maintainer should use comments
<lisp123>
I usually read the code of a library before using it, so I'm not sure if that puts me halfway between maintainer and user then
aartaka has quit [Ping timeout: 248 seconds]
<beach>
lisp123: I suspect that makes it impossible for you to use any more complex library.
<mfiano>
beach: And the maintainer may know what the code does, but will they 6 months in the future?
<beach>
mfiano: Perhaps not, but that doesn't justify all the noise all the time for all the functionality.
<mfiano>
Or an onboarding maintainer tomorrow?
<mfiano>
Right. I am just reiterating the user of comments for a maintainer, and the instructions for the user in the form of decoupled docstrings using #'(setf documentation). But, #'(setf documentation) is no substitute for good offline documentation with typesetting and figures.
<mfiano>
the use*
<beach>
I suspect we are in agreement.
<lisp123>
beach: Is your opposition to doc strings because they will encourage writing short documentation? Or visual noise
<beach>
I see what is going on in Alexandria. The lambda list shows up with parameters in italics, but then when the parameters are referred to in the documentation string, because of the lack of markup, they are referred to in all capitals, just like the names of functions and such.
<beach>
Then every all-capital word is translated to typewriter font in the Texinfo source. So the parameters are referred to in typewriter font when they should be in italics.
<beach>
lisp123: I think I wrote three reasons.
<mfiano>
lisp123: The former is a side effect of the latter.
<beach>
Exactly.
<lisp123>
Fair enough
<pjb>
beach: again, tools. (setf documentation) is not enough in a multilingual environment.
<beach>
lisp123: Try (DOCUMENTATION 'CAR 'FUNCTION) in SBCL
<pjb>
(defmethod (setf localized-documentation) (object kind language #|!|#) …)
<beach>
pjb: Exactly. Well, it could be made to work, but with lots of kludges.
<mfiano>
Wow that docstring is completely wrong.
<beach>
Yep.
analogsalad has quit [Quit: bye]
<lisp123>
They must have got the intern to write that one
<pjb>
beach: it's not the only part where CL kind of normalized a minimum API/behavior for wanted features, but that should considerably be extended in a real system, which is out of the bounds of the standard.
<beach>
pjb: I totally agree, and I think I have said it before.
<mfiano>
lisp123: But the reader interns ;)
analogsalad has joined #commonlisp
<beach>
I think DOCUMENTATION might have been a reasonable idea when all we had was ASCII terminals and Lisp was used only in English-speaking countries.
<beach>
But we can (and should) do better now.
<lisp123>
mfiano: nice one ;)
<beach>
Luckily, there is nothing that forces us to use DOCUMENTATION. But we need to come up with something that is substantially better.
<lisp123>
beach: agree
<pjb>
So we're right to want and design a more sophisticated documentation system. The only question is whether we may keep using the specified one when sophisticated tools are not available. Separate setf documentation are a usable alternative, so it's an option, but even plain docstrings are usable in a lot of cases.
<beach>
And something better must not rely on a particular input syntax, as I also have pointed out several times.
<pjb>
And indeed, when we use systems like unix with a lot of out-of-band information access, we don't have to use DOCUMENTATION or other inline tools…
<pjb>
I mean, most people don't even realize that to access the documentation of the code they use, they actually rely on the web, so on remote servers and a world-wide infrastructure! Few people use local documentation access methods, since google is so nice at querying!
<beach>
Yes, but then you get things like Quickdocs (I may have gotten the name wrong) that is generated from documentation strings, and exclude carefully crafted documentation.
Lycurgus has joined #commonlisp
<pjb>
It uses what's available. It could also be the editing source of the documentation.
<beach>
Sure, I should have said that this is one type of documentation you then may obtain.
<pjb>
It would be a trivial tool to hide or even move away all docstrings from a lisp sources in emacs.
<pjb>
It may be better to start from what docstrings exist, and then just propose good and nice tools to edit the documentation separately.
<pjb>
Also, I wonder how close we are to have actual AI to generate good user documentation. Have you see the latest demos of Google's AI?
lisp123 has quit [Remote host closed the connection]
<beach>
The SBCL documentation of CAR contains no additional information compared to the language standard, and it excludes the important information it should contain, namely what subclass of TYPE-ERROR is signaled when the argument is not a list.
<shka>
i am looking for library providing functions to write/read binary lisp objects from streams
<shka>
cl-store is great, but i think it is a little bit of overkill
triffid has quit [Remote host closed the connection]
<jackdaniel>
binary-types
<jackdaniel>
shka: ^
<shka>
ok, reading
triffid has joined #commonlisp
<jackdaniel>
perhaps docstrings are more kind of a reminder, something that you show in the pointer documentation pane, and not as a complete documentation of the operator
<beach>
jackdaniel: Sounds good. But then something else is also needed.
<jackdaniel>
sure, I agree
<jackdaniel>
docstrings are not a sufficient substitute of documentation
<jackdaniel>
s/of/for/
lisp123mobile has quit [Remote host closed the connection]
<contrapunctus>
Shinmera: I just checked, the Common Lisp vacancy at RavenPack seems to have closed.
mfiano has joined #commonlisp
<Shinmera>
better luck next time
<pjb>
contrapunctus: try again in six months?
mfiano has quit [Quit: WeeChat 3.5]
mfiano has joined #commonlisp
causal has quit [Quit: WeeChat 3.5]
imjim has quit [Quit: I closed the lid]
aartaka has joined #commonlisp
kpoeck has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
imjim has joined #commonlisp
yauhsien has quit [Remote host closed the connection]
guest74 has joined #commonlisp
yauhsien has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
yauhsien has quit [Ping timeout: 248 seconds]
<guest74>
So two things I see requested a lot are an emacs in cl and better documentation. I propose a more immediate and useful tool that would solve a major problem in implementing the other two. a multiuser brainstorming app that can save/edit files easily viewed over the web at some place like cliki.
<pjb>
Guest74: or directly github or gitlab.
<guest74>
There are lots of opinions, but not really any way to gather those opinions, classify them, and hopefully reduce them into a spec which is then 'easily' coded.
<pjb>
specs is a whole another can of worms. You want to be able to track spec elements, gather them into a specification document, but also, link them to analysis text and objects, design choices and code, so that when you change a spec, you can list the parts in the analysis, design and code that will be impacted, and vice versa.
<guest74>
because for things like emacs, what do people mean exactly? If we want just arbitrary keybindings in a fixed char terminal, then that's easy. but once the bigger picture is specified it should be easier to break off small chunks that individuals can write.
<pjb>
Of course, some such tracking is also in order for user documentation and other technical documentation.
<guest74>
pjb: yes.
<pjb>
An emacs is a program that lets you modify its own program, while you use it.
<pjb>
The keybindings are not arbitrary: they're 100% user customizable!
<guest74>
which is free since we're using cl.
<pjb>
Yes, but you still need to provide the feature. You could as well write closed programs in CL.
<guest74>
pjb: arbitrarily chosen. A user can choose whatever they want.
<pjb>
We'd just need a hundred man-year…
q3cpma has joined #commonlisp
<pjb>
We can do POC faster, but to make something that people would want to use, with some chrome, internet integration, etc…
<q3cpma>
Hello, I'm trying out bordeaux-threads, and the following program https://plaster.tymoon.eu/view/3115 seems to be racy, as calling `sbcl --script test.lisp` randomly print or doesn't print "hello". Any reason for that?
<guest74>
The idea I have is that the architecting is the hardest part to get consensus on. After that, individual parts can be written by anyone in any manner as long as the conform to the protocol/spec in question. A working model can be gotten quickly and bad inefficient code replaced over time as necessary.
<pjb>
q3cpma: flush the buffers!
acebulf has joined #commonlisp
<q3cpma>
Aren't they flushed when SBCL exits?
<pjb>
Of course. If you want to wait for the exit…
<q3cpma>
? If I use sbcl --script, it does exit, right?
<pjb>
Well, I don't know how sbcl specifically deals with buffers in threads…
<pjb>
If you want something deterministic, better flush your buffers yourself.
<pjb>
deterministic and conforming.
<q3cpma>
I'll try, but I would have thinked that *standard-output* was line buffered
<pjb>
You still need to flush, to be conforming.
<guest74>
Anyways, I already have the basics of a brainstorming app, I've just been pondering multiuser interaction for my game engine.
<q3cpma>
Adding a (finish-output) after format in the thread doesn't fix it
mfiano has quit [Quit: WeeChat 3.5]
<pjb>
q3cpma: you should also wait for the thread before quiting. add a bt:join-thread
<q3cpma>
pjb: good point, might be it
<q3cpma>
That was it, thanks
<pjb>
We use thread programming to increase performance in general, so it's natural that more technicalities must be involved.
<guest74>
pjb: have you even tried that ideone? We'd be much better served by just have a server we can create sessions on which run a certain implementation and we can share with our group and interact with through swank.
<q3cpma>
pjb: I do threading in C everyday, it just completely flew over my head this time