igemnace has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 246 seconds]
thonkpod has quit [Ping timeout: 240 seconds]
thonkpod has joined #commonlisp
akoana has quit [Quit: leaving]
Oladon has joined #commonlisp
[Reinhilde] has quit [Quit: Bye Open Projects!]
[Reinhilde] has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
herjazz has quit [Quit: leaving]
jladd- has joined #commonlisp
triffid has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
dtman34 has joined #commonlisp
beach` is now known as beach
Oladon has quit [Quit: Leaving.]
rainthree has joined #commonlisp
habamax has joined #commonlisp
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
semz has joined #commonlisp
bilegeek has quit [Quit: Leaving]
hashfunc has joined #commonlisp
rgherdt has joined #commonlisp
herjazz has joined #commonlisp
rgherdt has quit [Ping timeout: 246 seconds]
son0p has quit [Ping timeout: 264 seconds]
rgherdt has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
Brucio-61 has quit [Ping timeout: 246 seconds]
Brucio-61 has joined #commonlisp
shka has joined #commonlisp
msavoritias has joined #commonlisp
mi6x3m has joined #commonlisp
<mi6x3m>
friends if I can do something with a relatively simple closure should I use it instead of a class?
<mi6x3m>
and also, is the the convention for a closure factory to use the make- prefix?
tevo has quit [Read error: Connection reset by peer]
<hayley>
A closure is an object (in the message-passing/method-sending sense) with one method. Standard objects are nicer to inspect and debug though.
<mi6x3m>
I guess so yeah
tevo has joined #commonlisp
hashfunc has quit [Remote host closed the connection]
occ has quit [Ping timeout: 245 seconds]
Inline has joined #commonlisp
Inline has quit [Remote host closed the connection]
mi6x3m has quit [Ping timeout: 245 seconds]
czy has quit [Read error: Connection reset by peer]
phadthai has quit [Ping timeout: 246 seconds]
Gleefre has joined #commonlisp
mgl has joined #commonlisp
pve has joined #commonlisp
occ has joined #commonlisp
dino_tutter has joined #commonlisp
son0p has joined #commonlisp
Brucio-61 has quit [Ping timeout: 246 seconds]
Brucio-61 has joined #commonlisp
jmdaemon has quit [Ping timeout: 245 seconds]
phantomics has quit [Ping timeout: 246 seconds]
mi6x3m has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
phadthai has joined #commonlisp
Lord_of_Life has joined #commonlisp
McParen has joined #commonlisp
rtypo has joined #commonlisp
<McParen>
does somebody know if a cffi:defcfun wrapper around a function that returns a C string also automatically free that memory? or does it have to be manually freed?
msavoritias has quit [Remote host closed the connection]
<mi6x3m>
McParen, I doubt that
<mi6x3m>
most likely you need to free manually
cage has joined #commonlisp
igemnace has joined #commonlisp
cage has quit [Remote host closed the connection]
rainthree3 has joined #commonlisp
cage has joined #commonlisp
rainthree has quit [Ping timeout: 245 seconds]
msavoritias has joined #commonlisp
<McParen>
mi6x3m: do you maybe know if that is stated specifically somewhere in the cffi manual? I've tried to look that up, but had no luck so far.
<mi6x3m>
McParen, which is the function you're using?
<mi6x3m>
because the CFFI has no idea of your C function's semantics
<mgl>
Is there a thread-safe hack to make PPP:XXX print as NNN:XXX when NNN is a nickname of the package PPP?
<McParen>
mi6x3m: I've kind of come to the same conclusion that it likely should be freed explicitely, but that would somewhat contradict the return type :string of a defcfun wrapper. that would mean that in most cases wrapping a function that returns a string would not be the way to go.
<McParen>
but manually calling "foreign-funcall" and then "foreign-free" the return pointer.
igemnace has quit [Remote host closed the connection]
msavoritias has quit [Remote host closed the connection]
<pjb>
well, getenv may return a pointer into a memory block, not to an allocated memory block, so you couldn't free its result.
random-nick has joined #commonlisp
akoana has joined #commonlisp
<McParen>
so would you say that it is general implied practice that when the returned pointer has to be freed that the docs explicitely say so as in the case of the above "keybound"?
tyson2 has joined #commonlisp
attila_lendvai has joined #commonlisp
phantomics has joined #commonlisp
Brucio-61 has quit [Ping timeout: 246 seconds]
Brucio-61 has joined #commonlisp
<pjb>
Yes. C API must be quite specific about the parameters and the results. Because the C type system is very poor. Eg. char* is a pointer to a single character, not a string, not an array of character, not the insides of an array of character, etc.
<pjb>
McParen: eg. a char* parameter could be a string input parameter, or it could be a char output character. or it could be an array of char input-output parameters. Who knows? Only the documentation.
<McParen>
ok, thanks for the clarification.
dcb has joined #commonlisp
<McParen>
I generally wish more stuff would be explicit right in the code, not only in C. It is quite difficult to find out all the implicit assumptions.
dcb has quit [Ping timeout: 264 seconds]
dcb has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
karlosz has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
<mi6x3m>
tbh char* exists for compatibility with old C apis
azimut has joined #commonlisp
<mi6x3m>
new code with at least some ounce of design in it knows to abstract this shit away and give you other types
<mi6x3m>
pjb is right, but the duality of char* has it's usefulness
<beach>
McParen: What do you need C code for?
<hayley>
Somehow I'm not enjoying the hysterical raisins, though they may exist.
karlosz has quit [Quit: karlosz]
<pjb>
McParen: at least, in lisp you have a lot of tools to make things explicit. you can write macros, add custom declarations, and write tools to process them, etc.
dcb has quit [Ping timeout: 246 seconds]
dcb has joined #commonlisp
<McParen>
beach: i am calling the ncurses library from cffi.
<mi6x3m>
just don't use char* when you need a string and all will be fine
<hayley>
See the prior comment about unfunny raisins.
<beach>
mi6x3m: For what kind of software is C a nice language?
<McParen>
for interoperating with the last 50 years of software written in C?
<pjb>
mi6x3m: indeed, nothing prevents C programmer to define typdef struct { … } string; and use string* instead of char*. But most don't. Notably because there's no reader macro to map "foo" to string objects. But you can write a macro S("foo") --> string _foo42={…,"foo",…};
<beach>
McParen: That is not quite an answer to my question.
<pjb>
C is a nice programming language to give a job to old programmers :-)
<pjb>
Like Cobol or Fortran.
* hayley
feels old
<AkashaPeppermin4>
* is oblivious to C's pitfalls and proceeds to google why I shouldn't use string*
<hayley>
There isn't a string type in C.
<AkashaPeppermin4>
oh right, duh
<McParen>
rewriting software every few years in the newest "modern" languge seems as wasteful and pointless as rewriting literature every few years in the newest lingua franca.
<hayley>
Lisp predates C, yet Lisp is a hell of a lot more memory safe.
<hayley>
And reading Old English texts has yet to give anyone security bugs.
<hayley>
So it needn't be a "modern" language, it's hardly pointless, and dead literature doesn't make for an apt analogy.
<mi6x3m>
lisp and c and bunch of other stuff can coexist
<mi6x3m>
c is good, lisp is good
<beach>
McParen: I don't think anybody suggested rewriting existing sofware.
<hayley>
Bullshit.
<mi6x3m>
bad programmer writes bad shit in C, lisp and anything else
<beach>
*software.
<hayley>
Yet somehow bad Lisp doesn't manage to pwn machines.
<McParen>
beach: sorry, I seem to have misunderstood your comment then. my point was that the major appeal of C (at least for me) is interoperability with the wealth of preexisting code. avoiding preexisting code because you dont like a language leads to reinventing the wheel over and over.
<hayley>
Story time - I was offered a job once to work on web browsers. With the implementation language (C++) and number of users who could be affected by a blunder, I didn't think the job could go well, though I think I'm decent enough at C and C++. But I'm not good enough to be sure I don't slip up.
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
dino_tutter has quit [Ping timeout: 245 seconds]
tyson2 has joined #commonlisp
<contrapunctus>
McParen: if you rewrite the library in Common Lisp, and call it from other languages...wouldn't that give you memory safety as well as stability against churn?
<hayley>
(You may look through my commits in <https://github.com/no-defun-allowed/swcl> if you want to judge my proficiency in C yourself. I'd also like to mention that the parallel GC is hopefully inching towards being ready to merge.)
<ixelp>
GitHub - no-defun-allowed/swcl: Steel Wool Common Lisp
<beach>
McParen: But if C is good for interacting with existing code, why do you attempt to use Common Lisp for exactly that?
<McParen>
beach: Because I like Lisp a lot more than I like C, I guess.
<McParen>
And also Lisp isnt a fast moving target either.
<McParen>
I am just generally noticing how every few years a new "hot" language makes a lot of people rewriting everything from scratch and not reusing anything whatsoever except the underlying operating system.
<McParen>
I dont even work in IT or software development and even in a mostly technical environment I dont count how much code has been thrown out over the years just because it wasnt compatible with the new environment any more.
<McParen>
that completely contradicts how work is done outside of IT, where you basically can profit off several decades of previous research and knowledge.
<McParen>
</end of rant>
<hayley>
It's hard to reuse such code while keeping memory safety. There are other cross cutting things in FFI - for example, the HotSpot JVM takes its time to do foreign calls (for reasons I don't know), and the Google Go implementation and GHC have to set up a not-green thread for the foreign function to run in.
<hayley>
We don't even want to interface with Common Lisp for a project involving a capability system, as Common Lisp has ambient authority. Such safety measures always are as good as the weakest link, so rewriting can improve that link.
<pjb>
AkashaPeppermin4: well, you have to use pointers in C since there are no references. But I agree that one should put it in the type: typedef struct { … } *string; so you can write int foo(string input, string* output);
<ixelp>
Pascal J. Bourguignon / Common Lisp Suggested Projects · GitLab
<beach>
pjb: I just meant in this particular conversation.
<pjb>
ok ;-) (just for the nice reminder)
<pjb>
McParen: CFFI can indeed help you, transforming some C data into lisp objects and vice-versa. My advice is to avoid even this "highlevelness", to use CFFI to define the lowest level of C FFI, and then to write a high level lisp library wrapping the low-level C FFI. See for example: https://gitlab.com/com-informatimago/com-informatimago/-/tree/master/clext/pkcs11