jackdaniel changed the topic of #lisp to: Common Lisp, the #1=(programmable . #1#) programming language<http://cliki.net/> logs:<https://irclog.whitequark.org/lisp,http://ccl.clozure.com/irc-logs/lisp/> | SBCL 1.4.5, CMUCL 21b, ECL 16.1.3, CCL 1.11.5, ABCL 1.5.0
fikka has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
makomo has quit [Ping timeout: 268 seconds]
skidd0 has joined #lisp
Patzy has quit [Ping timeout: 240 seconds]
Denommus has joined #lisp
Patzy has joined #lisp
jack_rabbit has quit [Ping timeout: 272 seconds]
jack_rabbit has joined #lisp
rumbler31 has joined #lisp
<slyrus1> scymtym: if you've got a moment, can you take a look at https://github.com/sharplispers/closure-common/pull/2 ? thanks!
equwal has quit [Ping timeout: 244 seconds]
equwal has joined #lisp
pierpa has quit [Quit: Page closed]
Fare has joined #lisp
hvxgr_ has joined #lisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jinkies has joined #lisp
Fare has quit [Ping timeout: 240 seconds]
hvxgr_ has quit [Quit: leaving]
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
HighMemoryDaemon has joined #lisp
mathZ has joined #lisp
Kundry_Wag has quit [Ping timeout: 240 seconds]
Denommus has quit [Remote host closed the connection]
hvxgr_ has joined #lisp
robotoad_ has quit [Quit: robotoad_]
aphprentice_ has quit [Quit: Connection closed for inactivity]
Oladon has quit [Quit: Leaving.]
v0|d has quit [Ping timeout: 244 seconds]
robotoad has joined #lisp
HighMemoryDaemon has quit [Remote host closed the connection]
jack_rabbit has quit [Ping timeout: 272 seconds]
Fare has joined #lisp
<beach> Good morning everyone!
<jgkamat> good morning!
dented42 has joined #lisp
jack_rabbit has joined #lisp
<kenster> Streaming some epic lisp and C++ programming: https://youtu.be/lEL0Nly2CE0 or https://www.twitch.tv/kingherring
<asarch> If I have a git directory, how could I know the full address of it on the GitHub server?
rumbler31 has quit [Remote host closed the connection]
<Bike> git remote -v
<Colleen> Bike: karlosz said 20 hours, 57 minutes ago: i meant that the let can introduce a lexical location which can be captured and has no dominating definer.
<Colleen> Bike: karlosz said 20 hours, 59 minutes ago: I found a possible cause. Code like this (let ((*x* (or ... ...)))) can introduce a lexical location that is defined in two branches. Thus, we have our no dominating definer case we were looking for. I generalized the code to handle placing it in the lowest common ancestor node in the dominance tree.
<asarch> Thank you!
_whitelogger has joined #lisp
skidd0 has quit [Quit: WeeChat 2.2]
captgector has quit [Ping timeout: 256 seconds]
captgector has joined #lisp
captgector has quit [Ping timeout: 260 seconds]
Oladon has joined #lisp
captgector has joined #lisp
jinkies has quit [Ping timeout: 240 seconds]
captgector has quit [Read error: Connection reset by peer]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
captgector has joined #lisp
<ym> There is a paper by Jogn Alan McDonald called "Object-oriented programming for linear algebra." and dated July 10, 1989. It tells about "a system for numerical linear algebra and optimization, implemented in Common Lisp[l3] and CLOS[l], called Cactus.". Cannot google this Cactus system location in the Internets.
<ym> Maybe someone here more aware about this system?
<asarch> One stupid question, does Scheme have an ANSI standard just like Common Lisp has (ANSI X3J13)?
<no-defun-allowed> i think scheme goes by RnRS
<no-defun-allowed> n<7 at the moment
<no-defun-allowed> *n<=7
captgector has quit [Remote host closed the connection]
captgector has joined #lisp
<asarch> But, is it an ANSI standard?
<asarch> It isn't, is it?
Pixel_Outlaw has quit [Quit: Leaving]
<Bike> there's an ieee standard.
<beach> asarch: No, it's not an ANSI standard. But there is nothing special about ANSI.
<beach> asarch: There are several standards organizations in the world. Each country typically has at least one. Then you have IEEE, ISO, ECMA, etc.
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<beach> asarch: It is important to understand that a standards organization is not necessarily appointed by anyone in particular. It can be an association, or it can be a for-profit company. The important role of a standards organization, as far as programming languages are concerned, is that it is independent of the organizations that provide the implementations.
captgector has quit [Ping timeout: 240 seconds]
dddddd has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
<asarch> I see
<asarch> Thank you for the explanation
pjb has quit [Ping timeout: 256 seconds]
<beach> Sure. It's an important concept that is, unfortunately, often unknown to software developers. In fact, it is often unknown even to project leaders whose task it is to choose a programming language. The result is that they often choose programming languages that do not have an independent standard, with potentially dire consequences to the projects they are leaders of.
aindilis has quit [Ping timeout: 240 seconds]
<drmeister> If an array of unsigned byte8's only contains values between 0x01 and 0x7f inclusive - then it can be stored in a simple-base-string - correct?
pjb has joined #lisp
<beach> Nothing says that a simple base string can hold all the characters with those codes.
<drmeister> I thought that might be the answer - so I asked. What about printable ascii characters? 0x20 to 0x7f?
<beach> Are you asking about the standard or some typical implementation?
pjb has quit [Remote host closed the connection]
<beach> The standard says nothing about the encoding of characters.
<beach> So there is no relation between ASCII and the character set.
<beach> This is the point where I ask "what are you trying to do, and why?".
<drmeister> Right - it says nothing about the encoding of characters. I need to decide if an array of bytes can be coerced into a simple-base-string.
<drmeister> I have some arrays of bytes failing utf-8 encoding.
<drmeister> I could coerce those to arrays of bytes - I was looking for some other way of testing rather than failing utf-8 encoding.
shlecta has joined #lisp
<White_Flame> " Whether a character is a base character depends on the way that an implementation represents strings, and not any other properties of the implementation or the host operating system."
<beach> As far as I know, a UTF-8 string with bytes only between 0 and 127 contains only ASCII characters.
<beach> drmeister: So if it contains only bytes like that, then it can't fail.
<drmeister> I'm working on code that receives messages from the pzmq library - they are foreign-data. The foreign-data is being run through: (cffi:foreign-string-to-lisp (pzmq:msg-data msg) :count (pzmq:msg-size msg) :encoding cffi:*default-foreign-encoding*) - occasionally it fails.
<beach> drmeister: I don't understand why you need to coerce an array of bytes into an array of bytes.
pjb has joined #lisp
<White_Flame> btw, why did you say 0x01 - 0x7f instead of including 0x00?
<drmeister> I need to coerce the foreign data into strings when they can be and coerce them into arrays of bytes when they cannot be.
<White_Flame> that seems fraught with ambiguity
jack_rabbit has quit [Ping timeout: 272 seconds]
<drmeister> I'm trying to fix the cl-jupyter library. I has had a bug since its inception.
<drmeister> When the cl-jupyter library reads a message using the pzmq library the message contains a part called the identity followed by the message.
<drmeister> The very first message that is read has a pzmq supplied identity - which is a 5-byte array. Every other identity is a text uuid.
<drmeister> The cl-jupyter library doesn't seem to be aware of this and tries to coerce every part of every message (including identities) into simple-base-string's
pjb has quit [Ping timeout: 256 seconds]
<drmeister> I believe that the only reason the cl-jupyter library has worked for the last two years is some fluke of the communication protocol that allows it to sync up with the server after many failed messages have gone back and forth. I believe it all comes down to this 5 byte array.
<drmeister> So - to deal with it - I need to recognize when a foreign-data array of bytes can not be encoded as a simple-base-string and in that situation - encode it as an array of bytes.
JuanDaugherty has joined #lisp
<drmeister> I think I will apply the #'graphic-char-p predicate to every byte - and if they all pass - then I will convert it to a simple-base-string.
ft has quit [Ping timeout: 240 seconds]
<White_Flame> isn't this just a simple state machine, where the first message is binary and the rest are text?
<drmeister> I don't think so.
<drmeister> Each message has several parts.
<drmeister> The first part of the first message is binary and all parts after that are text - as far as I understand.
pjb has joined #lisp
<drmeister> I'm not sure what I said is correct - I'm not sure if the identity should be considered part of the message.
<drmeister> I'm still feeling my way around here. What I have figured out is if you treat all parts of all messages as strings - there is trouble.
pjb has quit [Remote host closed the connection]
shlecta has quit [Ping timeout: 272 seconds]
captgector has joined #lisp
Oladon has quit [Quit: Leaving.]
dented42 has joined #lisp
dented42 has quit [Ping timeout: 268 seconds]
Inline has quit [Quit: Leaving]
jack_rabbit has joined #lisp
mrcom has quit [Read error: Connection reset by peer]
mrcom has joined #lisp
Kevslinger has quit [Quit: Connection closed for inactivity]
zfree has quit [Quit: zfree]
orivej has quit [Ping timeout: 244 seconds]
energizer has quit [Ping timeout: 256 seconds]
energizer has joined #lisp
vlatkoB has joined #lisp
v0|d has joined #lisp
mathZ has quit [Remote host closed the connection]
aindilis has joined #lisp
impulse has quit [Ping timeout: 244 seconds]
impulse has joined #lisp
tralala has joined #lisp
SaganMan has joined #lisp
froggey has quit [Ping timeout: 240 seconds]
froggey has joined #lisp
equwal has quit [Ping timeout: 240 seconds]
shrdlu68 has joined #lisp
<phoe> This doesn't sound right, drmeister
<phoe> You have five bytes that are either a simple-base-string or binary data.
<drmeister> What are you thinking?
<phoe> These two aren't disjoint. There's binary data that also decodes to a simple-base-string.
<phoe> I don't think a sane person would create a protocol based on guessing like that.
<drmeister> I'm getting binary data that fails to decode to a simple-base-string
<phoe> Yep. I'd dig into the code that sends this data and figure out what the hell it is.
<drmeister> That is the wire protocol.
<drmeister> This part... b'u-u-i-d', # zmq identity(ies)
<phoe> Yes, I see.
<drmeister> In every message except for the very first one - the identity(ies) is a uuid string.
<drmeister> In the very first message - the identity isn't provided by the jupyter notebook framework. Ident = None
kenster has quit [Ping timeout: 240 seconds]
<drmeister> The serialize function is called with ident=None
<drmeister> I spent the last two days digging into the zeromq documentation and code.
<phoe> Yes, I see.
<phoe> I'm looking at https://github.com/jupyter/jupyter_client/blob/master/jupyter_client/session.py now to see if the implementation shows anything to me.
<drmeister> As a historical note, ZeroMQ v2.2 and earlier use UUIDs as identities. ZeroMQ v3.0 and later generate a 5 byte identity by default (0 + a random 32bit integer). There's some impact on network performance, but only when you use multiple proxy hops, which is rare. Mostly the change was to simplify building libzmq by removing the dependency on a UUID library.
<drmeister> From this...
<drmeister> The very first message I'm getting has a 5-byte identity that can not be translated into a simple-base-string using the UTF8 encoder - in cl-jupyter it errors out saying this.
<drmeister> cl-jupyter has been generating this error for two years - Fredrick Peschanski apologized to me about it two years ago when I started using cl-jupyter. I don't understand why cl-jupyter worked at all - but I suspect it was some fluke of the protocol.
<phoe> I don't understand how the identities are generated and then how they are told apart after they are sent.
zfree has joined #lisp
<phoe> The whole message looks like [ident1, ident2, ..., DELIM, HMAC, p_header, p_parent, p_metadata, p_content, buffer1, buffer2, ...]
<phoe> So many identities can happen before DELIM(iter).
<drmeister> A couple of weeks ago it stopped working. I've been debugging this for three days and it's pretty clear that because this first identity can't be encoded into a simple-base-string that the return message from the kernal is missing the identity and so zeromq is dropping it.
<drmeister> Yes - the identities come before the DELIMiter. The DELIMiter is the string "<IDS|MSG>"
<drmeister> Which means IDS before and MSG parts after.
<phoe> Yes, I see.
<drmeister> So - if I were to store anything before the DELIM as (array (unsigned 8)) and pass that through to the return messages - everything would (hopefully) be fine.
<drmeister> Most of the time though - the identity(ies) are text UUID's - so it's fine to store them in simple-base-strings.
<phoe> Why is it encoding identities as strings at all?
heisig has joined #lisp
<phoe> "As a historical note, ZeroMQ v2.2 and earlier use UUIDs as identities. ZeroMQ v3.0 and later generate a 5 byte identity by default (0 + a random 32bit integer)."
<drmeister> The original cl-jupyter code converted every message part as a string - I think that was the problem.
<phoe> These identities are NOT textual data.
<phoe> They are arbitrary binary data.
<phoe> It's a logical error to treat that as a string - that's what I see.
nirved has joined #lisp
<drmeister> Note how he uses (cffi:foreign-string-to-lisp (pzmq:msg-data msg) :count (pzmq:msg-size msg) :encoding encoding) to try to convert the foreign-string into a lisp string with the default encoding (UTF-8) and then if it fails it prints a warning and uses LATIN-1 and says it's ugly.
<phoe> Yes, I see.
<phoe> I don't know the full context, but now it smells to me that there was a type assumption that these identities are text.
<phoe> And the spec itself proves that wrong.
<drmeister> It's more than ugly - it's mangling the identity and then I can't send a response using the mangled identity because zeromq drops the message.
<drmeister> There is a type assumption in cl-jupyter that everything is text - yes.
<phoe> The first byte of zmq3.0 identity is #x00 - that's not a textual character in any charset I know.
<phoe> Well then, that's a type bug that I see there.
<drmeister> I am very grateful for your feedback - I am not at all convinced that I'm on the right track.
<Shinmera> phoe: 0 is #\Nul.
gravicappa has joined #lisp
<phoe> Shinmera: #\Nul is not a standard character.
<phoe> clhs 2.1.3
<Shinmera> Sure, but it is in ASCII and UTFs
<phoe> Oh, I see now.
<Shinmera> The standard's charset is pretty irrelevant to anything we do nowadays and have been doing for the past twenty years
<phoe> Yes, but it would be absolutely weird for me to have a string containing NULs.
<Shinmera> That much is true.
<phoe> Theoretically, (flex:octets-to-string #(0)) doesn't error; in practice, I'd freak out seeing the resulting "^@" anywhere in my program.
<drmeister> The tricky thing here is that zeromq switched to using these 5-byte 0x0 W X Y Z (where W X Y Z are 4 bytes of an int) identities when the user doesn't provide a UUID identity. UUID identities can be coerced to simple-base-string. 0x0 W X Y Z can not be - so I thought I would coerce it to an (array (unsigned 8))
<phoe> That sounds so much better.
<phoe> This looks like a prime case for an (array (unsigned-byte 8) (5))
<phoe> Since the first byte is 0x0 and the rest are arbitarry bytes.
<drmeister> But I would only coerce it to an (array (unsigned-byte 8)) if it contains any characters for which graphic-char-p is NIL.
<phoe> In general, it seems that that identity may be completely arbitrary.
<phoe> drmeister: I may sound radical, but it *does* look like a hack.
<Shinmera> Why not just leave it as a byte array always?
<phoe> You seem to be working around the problem that cl-jupyter treats binary data as text.
<phoe> What Shinmera said.
<drmeister> Because the cl-jupyter code needs to work with simple-base-strings for everything that isn't this one identity.
<phoe> Gaaah.
pacon_ has quit [Ping timeout: 260 seconds]
<drmeister> I don't think it ever looks into the contents of identities - it only passes them around and uses them to generate responses for requests
<phoe> Then it seems that cl-jupyter was based on the false assumption that identities are strings.
<phoe> Hm.
<phoe> If it's just passing them around, then it doesn't seem that there are so many call sites that would need to be edited to make it work with arrays.
<drmeister> Right.
<phoe> Basically just encoding and decoding would need to be thrown out.
<drmeister> It's easy to see why cl-jupyter believed this: b'u-u-i-d', # zmq identity(ies)
<phoe> Yes, I can see that.
<phoe> But, in their case, you could completely throw out the try-to-coerce-into-string-or-whatever functionality and go for a much simpler one: read five bytes, write five bytes.
<phoe> And then pass this thing around, whatever it is.
<drmeister> Well - it's ambiguous if I read it as "a byte literal that contains a u-u-i-d"
<phoe> Yes, that's absolutely true.
<drmeister> I think the big problem is that zeromq switched to these binary identities by default when previously they used uuid's
<phoe> Ayup.
<drmeister> Python handles it because it has the binary literal type.
<drmeister> Common Lisp doesn't have a binary literal type - right?
asarch has quit [Quit: Leaving]
<phoe> Huh? (array unsigned-byte) is binary literal.
<phoe> You mean something autoconvertible to strings or something?
<drmeister> I think I mean something autoconvertible to strings.
<Shinmera> "autoconvertible"?
<drmeister> I'm a little confused by this.
<phoe> I don't really know what I said, either.
<drmeister> I'm a lot confused by this. These components of the wire protocol are converted to JSON.
<shrdlu68> Do you mean #B?
<phoe> Something that acts like a string but is binary stuff in reality.
<drmeister> JSON doesn't have byte literals
<drmeister> I meant byte literals - sorry.
pacon has joined #lisp
<drmeister> I didn't mean to say "binary literals".
<phoe> Oh. Well, the closest thing in Lisp is an u8 vector, I think.
<phoe> Oh yesss, I see now.
<phoe> From Python docs: `Bytes literals are always prefixed with 'b' or 'B'; they produce an instance of the bytes type instead of the str type. They may only contain ASCII characters; bytes with a numeric value of 128 or greater must be expressed with escapes.`
<phoe> So basically, 'asdf' in Python is "asdf" in Lisp, but b'asdf' in Python is (flex:string-to-octets "asdf") in Lisp.
<Shinmera> Or, if your implementation supports it, a static-vector with element-type base-char.
<phoe> Oh. I didn't know that trick.
<shrdlu68> Do the python docs mean "octet" by "byte"?
<phoe> AFAIK, octet == (unsigned-byte 8).
<drmeister> Shinmera: What do you mean - a static-vector with element-type base-char?
<Shinmera> Or, if you're SBCL, (sb-sys:with-pinned-objects (string) (.. (sb-sys:vector-sap string)))
<Shinmera> drmeister: static-vectors is a library that implements lisp vectors for which you can retrieve a pointer that you can pass to C
<phoe> drmeister: there's a library called STATIC-VECTORS that allocates Lisp vectors suitable for CFFI usage.
<Shinmera> so you can exchange data without copying.
<phoe> Exactly this, yes.
varjag has joined #lisp
<phoe> Basically, you get a chunk of memory that is guaranteed to act the same when read/written from Lisp (via Lisp primitives) and read/written from C (via pointers). It gets funny when the memory is allocated as a base-char vector, because in C you get bytes, but in Lisp you get base-chars.
<phoe> But I don't really think this is what you want here. You don't have CFFI happening.
<drmeister> I am using cffi here.
<phoe> Oh. Wait a second.
pierpal has quit [Quit: Poof]
<drmeister> Rather, I started using cffi because pzmq only accepts lisp strings and foreign data objects.
pierpal has joined #lisp
<drmeister> I'm starting to think that the proper thing to do would be the following.
<drmeister> The wire protocol dictates python byte arrays are used. So I send and receive (array (unsigned 8)) arrays.
<drmeister> Rather - when I receive a message - I receive it as (array (unsigned 8)).
<drmeister> Then I pass those parts to wire-deserialize - and it converts what it needs to into lisp strings.
<phoe> Yep, that seems like the proper thing to do.
<drmeister> Later I pass dictionaries containing lisp strings to wire-serialize - that converts the strings into (array (unsigned 8)) arrays and then I send those back to zeromq.
<drmeister> Identities are not encoded by wire-serialize or wire-deserialize - they are only prefixed or removed from the start of the message.
<phoe> Identities are basically tokens that you receive and send but don't anyhow interact with, right?
<phoe> That's what I understood so far.
<drmeister> I think that's correct.
<phoe> So it would be sane to treat them as raw bytes that you only receive and send.
angavrilov has joined #lisp
<drmeister> I think my current approach will work - but it's weird because for one thing - it encodes strings immediately when things come in to recv -
<SaganMan> Morning Folks
<beach> Hello SaganMan.
unanimousarc has joined #lisp
<phoe> Hey hi
<unanimousarc> hello
<phoe> drmeister: that process is weird, yes. Instantly encoding everything into strings is weird, especially that these things aren't strings.
<beach> Hello unanimousarc.
<unanimousarc> I have a Q, I'm going through Land of Lisp and there's this part where the lisp reader creates an instance of a structure directly from the printed representation: "(defparameter *that-guy* #S(person :name "Bob" :age 35 :waist-size 32 :favorite-color "blue"))" However, I get an error when I do this in SBCL
<beach> Did you define the structure type named PERSON?
<unanimousarc> yes one sec
<phoe> unanimousarc: what's the error that you get?
<unanimousarc> (defparameter *bob* (make-person :name "Bob"
<unanimousarc> :waist-size 32
<unanimousarc> :age 35
<unanimousarc> :favourite-colour "blue"))
<unanimousarc> oops
<unanimousarc> sorry
<phoe> Use a service like https://plaster.tymoon.eu/edit for the future
<unanimousarc> "don't know how to dump #S(person ...)"
<beach> unanimousarc: My question was whether you have a (defstruct person...)
<beach> in your code
<beach> If not, it won't create a person for you.
<unanimousarc> oh yes, one sec
<beach> It sounds like the error is when you are trying to compile the file.
<phoe> Wrap DEFSTRUCT in (eval-when (:load-toplevel :compile-toplevel :execute) ...)
<phoe> There's a subtle thing here.
<beach> phoe: OK, I'll leave it to you. Thanks!
<phoe> beach: no no, please don't leave yet!
<beach> Too late.
<phoe> I'll likely get the details wrong while explaining this.
<phoe> :P
<beach> I am not good with structs anyway.
<unanimousarc> I wrapped the defstruct but that doesn't seem to change it, should I wrap everything in the eval-when?
<phoe> Hm.
<phoe> Gimme one second.
<beach> I think it has to do with trying to save a struct to a FASL.
<unanimousarc> I can just eval rather than compiling and loading, that works
<phoe> beach: actually not.
<phoe> That is related to the use of #S reader notation.
<phoe> If we comment out the last line and compile the resulting file, it'll work.
<beach> phoe: So why does it work when he evaluates it? And why does the error mention "dump"?
<phoe> beach: SBCL-specific stuff.
<beach> That has to do with a reader macro?
<beach> Hmm.
<trittweiler> Yes but it's still what beach hints at. In the case of #S(...) the person struct will be created at read time, and the object will have to be dumped into the fasl, to be bound to *that-guy* at load time
<beach> phoe: OK, you go ahead and analyze it.
<phoe> Oh right, that's correct.
<beach> *sigh*
<unanimousarc> I will take this as a subtlety right now :P
<phoe> Well, actually
<phoe> It is subtle.
<trittweiler> unanimousarc, Yeah, there's a way around that involving make-load-form but it's really quite advanced,I would suggest you to just go with MAKE-PERSON instead of the #S(...) notation. Note that the #S(...) notation would also create a read-only object.
<unanimousarc> okay cool, thanks :)
<phoe> There are several "times" in Lisp that are basically reader/compiler/etc. passes from raw text to actual Lisp code and data.
<phoe> The file compiler's role is to grab Lisp forms, turn them into code and dump all of the resulting code into compiled files.
<phoe> (make-person ...) is Lisp code.
<phoe> #S(person ...), when it's read, actually results in a Lisp *instance*. The reader turns it into an instance of PERSON.
<phoe> Now, the file compiler needs to know how to dump that instance into a file.
<phoe> The file compiler does just fine with lists, code, functions, and so on. But it chokes on actual instances of objects, for a good reason.
<unanimousarc> hm, I'll have to read more about this compilation stuff eventually, for now I'll just treat lisp like an interpreter
<phoe> Yes, it's complicated.
<phoe> A good tl;dr is, use MAKE-PERSON inside your files instead of the #S notation.
<phoe> You can use the #S notation inside the REPL just fine.
zxcvz has joined #lisp
unanimousarc has quit [Remote host closed the connection]
fikka has joined #lisp
rumbler31 has joined #lisp
unanimousarc has joined #lisp
moei has quit [Quit: Leaving...]
fikka has quit [Ping timeout: 248 seconds]
MoziM has quit [Quit: WeeChat 2.2]
fikka has joined #lisp
* no-defun-allowed tries to act fancy
<no-defun-allowed> AeroNotix: [here is cl-decentralise in its god awful hackish form](https://gitlab.com/Theemacsshibe/cl-decentralise)
charh has quit [Ping timeout: 256 seconds]
jack_rabbit has quit [Ping timeout: 272 seconds]
<no-defun-allowed> i guess it will flow past 400 loc :c
araujo has joined #lisp
MoziM has joined #lisp
quipa has joined #lisp
erratic has joined #lisp
jack_rabbit has joined #lisp
rumbler31 has quit [Remote host closed the connection]
housel has quit [Read error: Connection reset by peer]
housel has joined #lisp
m3tti has joined #lisp
m3tti has quit [Remote host closed the connection]
moei has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
xificurC has joined #lisp
random-nick has joined #lisp
<phoe> AeroNotix: you should make it possible to declare what the delimiter is. It should be possible to customize the delimiter, just like in HTTP content-type multipart/form-data. It has a custom boundary.
ft_ has joined #lisp
<v0|d> beach: why no dtors in CLOS?
Kaisyu has quit [Quit: Connection closed for inactivity]
nirved has quit [Ping timeout: 272 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<beach> v0|d: Because most modern garbage collectors don't touch objects that are no longer live. Such collectors could not call any destructor for dead objects.
<beach> v0|d: Some Common Lisp implementation have what is known as "finalizers" that can accomplish some of what a destructor does. However, it is still not predictable when the garbage collector will detect that an object is no longer live.
<Zhivago> The more important point is that by the time the object is collected it is no-longer reachable by a destructor. If it were, it could be re-linked into the graph by the destructor. Leading to things like resurrecting objects from the dead (once only) in Java.
<Zhivago> Finalizers get around this by not operating on the dead object, but usually share some (still live) substructure.
<heisig> v0|d: You could, however, implement your own generic function (destroy-instance X), which would internally do a (change-class X 'destroyed). Then CLOS would have destructors :) Of course this would be unrelated to the GC.
fikka has joined #lisp
emacsoma` has quit [Ping timeout: 240 seconds]
milanj has joined #lisp
<v0|d> Interesting.
m00natic has joined #lisp
<phoe> v0|d: depends on what your destructor would do
<phoe> the basic use case for a destructor is freeing resources - Lisp has garbage collection instead.
<phoe> another basic use case is closing closeable resources when they are no longer used - Lisp has WITH-* macros for that.
<phoe> yet another use case is closing closeable resources that isn't limited to the dynamic scope of an object, so WITH-* macros can't help you there - and, for that, you can write an ordinary function in Lisp.
<heisig> You forgot another use case - accidentally breaking your program. That is why I proposed DESTROY-INSTANCE :)
<phoe> heisig: I have no idea what you are talking aboSegmentation fault (core dumped)
<v0|d> Zhivago: Is it possible to detect for a compiler that a user defined finalizer can ressurect objs?
makomo has joined #lisp
<v0|d> say just by static analysis.
quipa has quit [Remote host closed the connection]
<phoe> Lisp finalizers cannot resurrect objects.
<phoe> A Lisp finalizer can't close over the object. It can't have a reference to it.
<phoe> Therefore, there's no means of resurrecting it.
housel has quit [Read error: Connection reset by peer]
<Shinmera> If a lisp finalizer references the object itself, it is never freed.
<phoe> because it's always alive, yep.
<Shinmera> Because the finalizer stays alive due to the object and the object stays alive due to the finalizer
<Shinmera> GCs protect against double frees and forgetting to free, but you can still create memory leaks.
<phoe> Shinmera: it's a little bit more complicated than that, AFAIU
<phoe> the finalizer must be registered in the GC-accessible location somewhere, so GC knows to fire it when the collection occurs
<phoe> And if the finalizer is registered in a live location, then the object it closes over is also live
<phoe> So the object is live, so the object won't ever die
<phoe> if A closes over B and B closes over A, then both of them are dead if neither of them is accessible
<phoe> so "the finalizer stays alive due to the object and the object stays alive due to the finalizer" is not enough to proclaim the object or the finalizer alive.
<phoe> That's how I understand it.
rumbler31 has joined #lisp
<Shinmera> It's not necessarily the case that a finalizer is registered as a root, it just needs to be treated specially since, yes, usually cyclic references in objects are freed just fine.
<v0|d> In C++, finalizer is not linked to the object itself right? (ie in vtable)
<phoe> Yep - it doesn't really have to be registered anywhere, but the GC needs to know where it is and how to fire it.
<v0|d> Interesting.
<v0|d> So you say, a gf finalizer would be linked to the object.
<v0|d> I didn't know that.
fikka has quit [Ping timeout: 244 seconds]
<Shinmera> GFs have nothing to do with it
<Shinmera> If a function is called with an argument, that argument has to exist.
<Shinmera> If it exists, it's not garbage.
Fare has quit [Ping timeout: 240 seconds]
<v0|d> This boils down to defining a separate environment for GC and migration objs to it.
rumbler31 has quit [Ping timeout: 240 seconds]
<v0|d> s/migration/migrating/g
JuanDaugherty has quit [Quit: Exeunt]
hvxgr_ has quit [Quit: leaving]
dddddd has joined #lisp
hvxgr has quit [Quit: leaving]
<v0|d> Thnx for all the help.
makomo has quit [Ping timeout: 256 seconds]
makomo has joined #lisp
ofi has joined #lisp
hvxgr has joined #lisp
<no-defun-allowed> I keep reading girlfriend finaliser.
<phoe> oh gods no
<no-defun-allowed> It's very odd.
<beach> no-defun-allowed: It's because, for some reason, people don't use Emacs abbrevs. Don't ask me why.
<no-defun-allowed> GF is also generic function I guess?
<beach> You think?
<no-defun-allowed> I do?
<jackdaniel> beach: not everyone use emacs for irc, that could be the reason
<heisig> From the spec: "A girlfriend is a function whose behavior depends on the classes or identities of the arguments supplied to it." Well put :)
fikka has joined #lisp
<phoe> No doubt that Lisp isn't all that popular if Lisp programmers finalize their girlfriends
<beach> jackdaniel: Then they should use the equivalent of Emacs abbrevs in the IRC client they are using.
gravicappa has quit [Ping timeout: 256 seconds]
unanimousarc has quit [Remote host closed the connection]
<heisig> Does anyone know a good library for type inference in Lisp? I'd like to have something like (infer-type 'cl:floor 'double-float) -> '(integer double-float).
<no-defun-allowed> I can't convince my girlfriend to learn Lisp.
<no-defun-allowed> There's a chatroom with two other lispers, me and her and she hasn't been converted yet.
<v0|d> no-defun-allowed: according to the definition, try supplying a proper argument to her.
<v0|d> sry for causing this nonsense, I'll be more careful next time.
<no-defun-allowed> Interesting.
<no-defun-allowed> Ooh I know.
<no-defun-allowed> (coerce (get 'no-defun-allowed 'girlfriend) 'lisp-weenie)
MichaelRaskin has quit [Quit: MichaelRaskin]
<no-defun-allowed> COERCE isn't usually destructive so just imagine I setf (get ...) too.
schweers has joined #lisp
scymtym has quit [Remote host closed the connection]
<TMA> no-defun-allowed: and then the old girlfriend would be garbage collected and possibly finalized. may I suggest CHANGE-CLASS instead?
<no-defun-allowed> Alright
<no-defun-allowed> (change-class girlfriend 'lisp-weenie) it is.
orivej has joined #lisp
scymtym has joined #lisp
<no-defun-allowed> I'll try (funcall girlfriend '(lisp is way more fun than css)) actually
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
makomo has quit [Ping timeout: 240 seconds]
xificurC has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
pjb has joined #lisp
Kevslinger has joined #lisp
quipa has joined #lisp
makomo has joined #lisp
fikka has quit [Ping timeout: 272 seconds]
Bike has joined #lisp
<hjudt> why do some programmers use keyword prefixes in loop? e.g. (loop :with manual-names...)
<Shinmera> they think it looks better
<hjudt> holy cow
<shrdlu68> Such is man's perversity.
<hjudt> lol
fikka has joined #lisp
LiamH has joined #lisp
<phoe> heisig: hm
<phoe> clhs floor
<phoe> heisig: you basically want a mechanism for fetching ftypes, correct?
<phoe> ...oh, not necessarily
fikka has quit [Ping timeout: 256 seconds]
FreeBirdLjj has joined #lisp
fikka has joined #lisp
<phoe> heisig: you could base one on top of some mechanism that is based on ftypes
<phoe> SBCL has especially good inference, so it should be able to help you with that
rumbler31 has quit [Remote host closed the connection]
FreeBirdLjj has quit [Ping timeout: 256 seconds]
<heisig> phoe: I already considered using SBCL internals. But I also like to have things portable. Maybe a mix of both.
<phoe> It seems that SBCL's mechanism is *highly* internal, at least judging by the name
<phoe> #'sb-impl::%fun-type
<pjb> hjudt: this is because loop keywords are not exported from CL. Therefore they can be exported from other packages.
<pjb> hjudt: for example, you could have a package exporting for, while, collect, etc.
<pjb> hjudt: in that case, if you write a loop in your package without using KEYWORD, you intern symbols with those names in your package. Then if you use-package the package that exports symbols with the same name, you get collisions!
<phoe> hjudt: loop doesn't care which package its keywords come from
<pjb> But use-package does.
<phoe> these keywords aren't even exported from CL package
<pjb> which is the problem.
<phoe> (loop #:for i #:in '(1 2 3 4 5) #:do (print i)) is valid
<pjb> but ugly.
<phoe> (loop :for i :in '(1 2 3 4 5) :do (print i))
<phoe> the only difference is ###
<pjb> is a good compomise.
<pjb> +t
<pjb> s/t/r/
<phoe> well
<phoe> (loop #.(make-symbol "FOR") i #.(make-symbol "IN") '(1 2 3 4 5) #.(make-symbol "DO") (print i))
<pjb> and for the people who find that loop is not lispy enough, using KEYWORDS instead of symbols makes it look more or less like an operator with &key arguments :-)
<pjb> (loop ⟳for i ⟳in '(1 2 3 4) ⟳do (print i))
<pjb> with ⟳ being an adequate reader macro.
MoziM has quit [Quit: WeeChat 2.2]
kajo has quit [Ping timeout: 256 seconds]
arbv has joined #lisp
arkaros has joined #lisp
igemnace has joined #lisp
light2yellow has joined #lisp
unanimousarc has joined #lisp
jack_rabbit has quit [Ping timeout: 272 seconds]
<phoe> Actually, does the exist a TRIVIAL-FTYPE library?
<phoe> Something that would allow me to (trivial-ftype:function-ftype #'phase) ;=> (FUNCTION (T) (VALUES (OR (DOUBLE-FLOAT -3.141592653589793d0 3.141592653589793d0) SINGLE-FLOAT) &OPTIONAL))
<phoe> There is CL:TYPE-OF, but for functions, it returns the type, not the ftype.
<phoe> and the type isn't all that interesting - it's FUNCTION
<Shinmera> phoe: cltl2's function-information does what you want
<phoe> s/the/there/
<phoe> Shinmera: !
warweasle has joined #lisp
<AeroNotix> Using keywords in LOOP makes it more readable. Less symbol soup.
<phoe> Shinmera: ...kinda.
<AeroNotix> It's already one of the most unreadable forms you can use, anything to make it more readable helps
<phoe> That's what it returns. That's the declared type, not the inferred type.
<AeroNotix> heisig: out of interest what you are writing that will use the inferred types?
<jackdaniel> AeroNotix: I suspect he investigates options to improve petalisp performance
<heisig> AeroNotix: In Petalisp (https://github.com/marcoheisig/Petalisp), I JIT-compile array definitions to fast specialized code. To do so, I need to know that adding floats produces floats and so on.
<jackdaniel> spot-on :-)
<heisig> :)
<heisig> Ideally, I could also use type inference to prevent code like (+ "foo" 5) from ever being run. Run-time errors in distributed systems are not pretty.
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
Denommus has joined #lisp
arkaros has quit [Read error: Connection reset by peer]
arkaros has joined #lisp
arkaros has quit [Read error: Connection reset by peer]
Inline has joined #lisp
arkaros has joined #lisp
mindCrime has quit [Ping timeout: 256 seconds]
tralala has quit [Ping timeout: 240 seconds]
<AeroNotix> heisig: very cool
<heisig> AeroNotix: Thanks!
Bronsa has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
heisig has quit [Quit: Leaving]
charh has joined #lisp
felideon has left #lisp ["WeeChat 0.4.3"]
fikka has joined #lisp
FreeBirdLjj has joined #lisp
quipa has quit [Quit: Leaving]
mindCrime has joined #lisp
Copenhagen_Bram has quit [Ping timeout: 260 seconds]
ofi has quit [Read error: Connection reset by peer]
jusss has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
jusss has quit [Client Quit]
TMA has quit [Ping timeout: 268 seconds]
jusss has joined #lisp
arkaros has quit [Ping timeout: 260 seconds]
jusss has quit [Client Quit]
housel has joined #lisp
fikka has quit [Ping timeout: 272 seconds]
Copenhagen_Bram has joined #lisp
schweers has quit [Ping timeout: 240 seconds]
rumbler31 has joined #lisp
Fare has joined #lisp
rumbler31 has quit [Ping timeout: 248 seconds]
dwrngr has joined #lisp
rippa has joined #lisp
arkaros has joined #lisp
Fare has quit [Ping timeout: 240 seconds]
chipolux has joined #lisp
arkaros has quit [Ping timeout: 240 seconds]
yozefCatina has joined #lisp
test1600 has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
ft_ is now known as ft
<ym> Is there any tool to visualize AST/ASG of LISP code so that it would be displayed as interactive graph like in modern visual programming DSLs?
shrdlu68 has quit [Ping timeout: 260 seconds]
<phoe> ym: which modern visual programming DSLs?
<slyrus1> scymtym: thanks! do you have a preference for merging the PR vs just pushing a (cleaned up) commit to master?
<phoe> ym: I somehow don't find the right side of https://raw.githubusercontent.com/cuichaox/visual-cells/master/demo/slime-screenshot.png readable at all
<ym> phoe, AudioMulch for example.
<phoe> it's not suitable for Lisp code.
<phoe> it's a good way of turning four lines of readable code into half a screen of unreadable graph, as you can see above.
<phoe> if anything, these are named boxes with some inputs and outputs.
<pjb> ym: there were such tools in Genera, but currently, there's nothing interactive AFAIK.
JuanDaugherty has joined #lisp
<pjb> (at least, opensource).
<ym> Yep, I also found only very old abandoned examples.
fikka has joined #lisp
<pjb> The thing is that things are un flux. There are various user interface toolkits, but they're usually hard to use natively (despite CL libraries). There's CLIM, but AFAIUI, McCLIM is being rewritten.
<pjb> This should not prevent you to use it, but it probably means "batteries NOT included".
<pjb> And if you wanted to put the GUI on a tablet, then we don't have many CL implementations running there either, and it's awkward.
FreeBirdLjj has joined #lisp
<ym> I'm aware of McCLIM. Don't like it's framework nature, too overthinked protocol. I want just zoom in/out the depth of code represented in network graph in respect to packages/function nesting for example. For me it's most comfortable way of getting a fast glance of system structure.
fikka has quit [Ping timeout: 265 seconds]
<scymtym> slyrus1: i think either is fine
<slyrus1> scymtym: merged. thanks!
<pjb> If you don't need sophiticated user interaction, people often use secundary programs to render the graph, such as GraphViz, displaying it as a bitmap.
cage_ has joined #lisp
<ym> Some good guy from here shared his graph visualization program (cl-frame.lisp). That's enough to start with, but I'm just can't get why such useful features aren't widespread.
shlecta has joined #lisp
fikka has joined #lisp
<pjb> ym: that's because, as I've said, there has been and still is a lot of changes in the graphic and UI technologies.
<pjb> So bit rot occurs quick.
<pjb> Also, you'd have to choose a platform for it. (asuming you cannot write versions for all the platforms). A lot of lispers use macOS. Another big share use linux.
<pjb> More of them use emacs. Perhaps this would be the right choice of a platform for such tools.
asarch has joined #lisp
yozefCatina has quit [Remote host closed the connection]
<ym> Well, I don't get this software "evolution" tendency either. I thought that layers of abstraction should hide implementation details and provide simple interface. Like 20 years ago I was able to write SCREEN 12 CRICLE (320, 240), 32 in QBasic to ouput a circle. And now I have to struggle with X protocol, CLX, write over 20 SLOC to make the same.
fikka has quit [Ping timeout: 260 seconds]
fouric has joined #lisp
whartung has quit [Quit: whartung]
<fouric> would anyone happen to know how i can disable SBCL's automatic 80-column wrapping?
fouric has quit [Quit: WeeChat 2.2]
fouric has joined #lisp
<edgar-rft> fouric: have you already tried to change *print-right-margin*?
<ym> I think it's (defconstant default-line-length 80) in src/code/early-pprint.lisp.
<phoe> yes, but AfAIK later that's customizable via *print-right-margin*
<fouric> i did not! that works well enough for now, thanks!
<fouric> (and yes i did google it but did not find that variable)
* fouric sets to 1000
<gendl> Hi, what different conditions or parameter settings can cause (format nil "~t" some-variable) to give different amounts of spacing?
<gendl> I think wrapping (with-standard-io-syntax ...) around it will make it work the same in both cases I'm seeing. But without with-standard-io-syntax, the ~t seems to be generating different amounts of whitespace.
whartung has joined #lisp
<phoe> clhs ~t
<pjb> ym: you're right but in the case of UI, there are yearly fads, it's not software, it's fashion.
<phoe> gendl: different amounts of whitespace? could you provide a test case?
<pjb> ym: I would be the last to reproach you to have an "ugly" or "dated" look in your app.
<gendl> phoe: I'll try. I'm just looking at static customer code right now, without the ability to run it in their environment...
<pjb> ym: strugglying with X11 would be nothing (and very dated!) Nowadays, you'd have to do this in 3D with OpenGL, etc…
<ym> Oh, no. OpenGL is way more horrible thing in this perspective. There is known reason why CS/IT stuff getting worse, but that's off-topic.
<pjb> gendl: the purpose of ~T is to generate different amounts of spaces!
<pjb> If it generated always the same amount, it would be bad.
<gendl> pjb: that's what I'm gathering...
<gendl> it should go to the next "tab stop," right?
<pjb> Yes, something like that (it doesn't assume tabs, but yes).
gigetoo has quit [Ping timeout: 240 seconds]
slyrus1 has quit [Quit: slyrus1]
gypsydave5 has joined #lisp
varjag has joined #lisp
slyrus1 has joined #lisp
dkrm has quit [Quit: WeeChat 2.2]
ft has quit [Ping timeout: 260 seconds]
ft has joined #lisp
<gendl> Ok i have an example which shows different output with & without with-standard-io-syntax
<gendl> how can i paste a code snippet here, I forgot...
<gendl> ok looks like IRCCloud did it for me...
<gendl> So when I wrap this with w-s-io-s, the output has more whitespace (I can post the actual output if that helps)
gravicappa has joined #lisp
<phoe> Can't see it just yet
<gendl> phoe: So you're getting identical outputs with & without w-s-io-s, right?
<phoe> gendl: yes, I am
<gendl> so it means there's something non-standard in my environment.
<phoe> These two strings are identical
<phoe> gendl: please post both resulting strings.
<gendl> with w-s-io-s:
<gendl> without w-s-io-s:
test1600_ has joined #lisp
chipolux has quit [Ping timeout: 272 seconds]
dkrm has joined #lisp
<pjb> I don't see any difference: https://pastebin.com/wwaWzZDg
<phoe> gendl: can you give me the result of (list *print-lines* *print-miser-width* *print-pprint-dispatch* *print-right-margin* *print-level* *print-length* *print-lines* *print-circle* *print-escape* *print-pretty*) ?
<phoe> Both with w-s-io-s and without it.
<pjb> gendl: on the other hand, you have newlines and tabs in your format strings. The newlines are ok but you may prefer explicit ~%. The tabs are bad since they're so implementation dependent.
<gendl> looks like *print-pretty* is different, and the *print-pprint-dispatch* is different.
<phoe> The dispatch table is expected to be different. *print-pretty*, hmm.
test1600 has quit [Ping timeout: 260 seconds]
<gendl> let me try with setting *print-pretty* to nil.
<pjb> gendl: In general, I would avoid with-standard-io-syntax. Instead, I would define my own macro setting all the variables as I want them.
<phoe> gendl: what's your implementation?
<gendl> Allegro CL 10.1 Windows.
<gendl> customer is running ANSI mode, I happen to be running modern-mode here (probably bad, I know)
<gendl> Looks like *print-pretty* is the culprit:
<phoe> ...one more question.
<gendl> The customer is comparing output from our previous version which was Allegro CL 9 (32-bit), vs. our new version they're trying to get into production, which is Allegro 10.1 (64-bit).
<phoe> Why is your printed string so far to the right?
<phoe> There's a *lot* of tabulation on its left side.
<gendl> and their regression test is flagging these differences.
<gendl> phoe: In my function `try' there is a lot of whitespace to the left of all but the first line.
<pjb> also, why do you want to use so many format specifiers? https://pastebin.com/eZqM74JU
<gendl> Should the ~1t force it into column 1, even with all the leading whitespace in the format string?
<phoe> gendl: running your function produces no left-side whitespace here on SBCL.
Fare has joined #lisp
<gendl> Hmm. Well apparently on Allegro it does, even with w-s-io-s.
<gendl> But you're right, that doesn't look right. The ======... should obviously be just below the title.
<gendl> pjb: It's not a matter of what I want -- this is customer code, i have no control over it. (I can make recommendations to them, though).
<phoe> Actually.
<phoe> If the behavior of that code changed between different versions of Allegro CL, then I'd ask Franz for clarification.
<phoe> This is 100% standard code. Its behavior should not change, other than for bugfixes.
housel has quit [Read error: Connection reset by peer]
<phoe> And bugfixes should be noted in some kind of release notes.
housel has joined #lisp
<pjb> gendl: the principle of software is that it should be soft and easily (cheaply) modifiable.
<gendl> phoe: Before I go blaming Franz I have to make sure we didn't inadvertently change *print-miser-width* or *print-pretty* in our stuff.
<pjb> gendl: otherwise, I would write the code to format tables from raw data and headers, without pre-conceived format. The format would be computed automatically from the data.
<phoe> gendl: yes, that's correct.
Bike_ has joined #lisp
<pjb> gendl: notice in my example, that you only have 2 formats: ~A for strings, which should not depend on *print- vars, and ~6,3f. If you get your 6 characters, then this format should not depend on the other *print- variables either.
Bike has quit [Disconnected by services]
<phoe> gendl: nonetheless, neither SBCL or ECL show the left-side tabulation.
Bike_ is now known as Bike
<pjb> What I'm saying, is patch your source, it's bad.
<gendl> pjb: thanks, I'll tell them.
<phoe> ...and if this is code written by the customer, make a shameless suggestion to them to patch it.
<phoe> I'm still very curious about FORMAT behavior though.
<phoe> It differs between SBCL/ECL and ACL here.
vibs29 has quit [Ping timeout: 268 seconds]
vibs29 has joined #lisp
gypsydave5 has quit [Remote host closed the connection]
<pjb> gendl: since you only have absolute ~T directive, preceded only by literal strings (and absolute ~T directives), (apart for the ~F and ~A that are trivial), then I would say that if you get bad results, it's a bug in the implementation.
<gendl> *print-pretty* is supposed to be nil by default, right? I'm noticing in Allegro CL 10.1, *print-pretty* is t, out of the starting gate.
<AeroNotix> Better way to get parity than: (logxor 1 (logand 1 (logcount x))) ?
<pjb> evenp
<gendl> And the difference between having it t and nil is causing the differences which the customer is reporting.
<gendl> Apparently *print-pretty* was defaulting to nil in Allegro 9.
m00natic has quit [Read error: Connection reset by peer]
<AeroNotix> duh
<pjb> AeroNotix: and for oddness: oddp
<AeroNotix> aye, understood. I've been stuck thinking in bits all day
<gendl> Also *print-miser-width* looks like it was nil in Allegro 9 and 40 in Allegro 10.1.
<gendl> Unless I'm doing something quite stupid or really missing something.
<pjb> AeroNotix: So (evenp (logcount n))
<phoe> gendl: check ANSI mode.
<phoe> The default values for *print-miser-width* and *print-pretty* are implementation-dependent.
<gendl> That is starting alisp -qq to make sure no init files are loaded.
<phoe> So they are allowed to change between implementation versions.
sjl has joined #lisp
<AeroNotix> pjb: thanks yeah
<gendl> According to this: http://clhs.lisp.se/Body/m_w_std_.htm
<gendl> the values are set out in the standard -- nil for both.
<gendl> But if you look at the actual documentation for *print-pretty* and *print-miser-width*, they both do say the initial value is implementation-dependent.
<gendl> That looks like kind of inconsistency in the hyperspec, is it?
<trittweiler> standard != initial :)
laurus has joined #lisp
<gendl> trittweiler: Hrmp. I see.
<laurus> Is there a lisp-friendly paste site?
<trittweiler> there are more instances where that's the case. The initial readtable versus (copy-readtable nil), perhaps. (Haven't checked)
<gendl> So 'standard' is what you get with with-standard-io-syntax, but any given vendor can ship an image with non-standard initial values. Got it.
<laurus> Thank you phoe!
<gendl> And no guaranteed that those values stay the same from release to release.
<phoe> gendl: correct
<phoe> (with-acl9-io-syntax ...)
<phoe> (:
<pjb> laurus: https://lpaste.net has a CL option.
<laurus> Thanks pjb
<laurus> :)
arkaros has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
kajo has joined #lisp
<gendl> And Thanks pjb :).
<gendl> and Thanks phoe.
<gendl> and thanks trittweiler.
arkaros has quit [Ping timeout: 272 seconds]
mindCrime_ has joined #lisp
payphone_ has joined #lisp
payphone has quit [Read error: Connection reset by peer]
fikka has joined #lisp
mindCrime has quit [Ping timeout: 248 seconds]
<phoe> no problem
laurus has left #lisp ["Part"]
mathrick has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 268 seconds]
snits has joined #lisp
<gendl> Disclaimer: it looks like those *print-pretty* and *print-miser-width* might not have changed between Allegro 9 and Allegro 10. I don't want to give wrong information here.
<gendl> I have to sort out a few things to confirm (I don't have my Allegro 9 handy here) but it looks like (list *print-pretty* *print-miser-width*) have been (t 40) all along, in Allegro.
kajo has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
gravicappa has quit [Ping timeout: 244 seconds]
<gendl> pjg: wow, thank you! May I pass this on to them (and mention your name of course)
<gendl> pjb: typo, see above
<pjb> Sure.
fzac has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
mathrick has joined #lisp
captgector has quit [Ping timeout: 272 seconds]
gigetoo has joined #lisp
<klltkr> Word
arbxs has quit [Ping timeout: 256 seconds]
arbxs has joined #lisp
fikka has joined #lisp
sauvin has quit [Read error: Connection reset by peer]
Fare has quit [Ping timeout: 272 seconds]
fikka has quit [Ping timeout: 240 seconds]
Fare has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
test1600_ has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 256 seconds]
DKTH has joined #lisp
fikka has joined #lisp
mingus has quit [Ping timeout: 256 seconds]
gpiero has quit [Ping timeout: 244 seconds]
fikka has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
gurmble has joined #lisp
grumble is now known as Guest76306
gurmble is now known as grumble
Guest76306 has quit [Killed (weber.freenode.net (Nickname regained by services))]
cage_ has quit [Quit: Leaving]
fikka has quit [Ping timeout: 256 seconds]
arkaros has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
nowhere_man has quit [Ping timeout: 256 seconds]
FreeBirdLjj has joined #lisp
arkaros has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
<pjb> gendl: sorry, :center was wrong. Here's the correction: https://lpaste.net/4162159592878374912
FreeBirdLjj has quit [Ping timeout: 244 seconds]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
<gendl> ok!
fikka has quit [Ping timeout: 244 seconds]
lonjil has joined #lisp
Jesin has quit [Remote host closed the connection]
grumble has quit [Quit: It would appear there's a kernel update]
terrorjack_ has joined #lisp
vlatkoB has quit [Remote host closed the connection]
grumble has joined #lisp
fikka has joined #lisp
TheReal_aijony has joined #lisp
spaceplu- has joined #lisp
lonjil2 has quit [*.net *.split]
Guest25371 has quit [*.net *.split]
kqr has quit [*.net *.split]
jasom has quit [*.net *.split]
kjeldahl has quit [*.net *.split]
Thorondor[m] has quit [*.net *.split]
Jach[m] has quit [*.net *.split]
PyroLagus has quit [*.net *.split]
thekolb has quit [*.net *.split]
d4gg4d_ has quit [*.net *.split]
Jesin has joined #lisp
himmAllRight has quit [*.net *.split]
terrorjack has quit [*.net *.split]
aijony has quit [*.net *.split]
alandipert has quit [*.net *.split]
spacepluk has quit [*.net *.split]
TheReal_aijony is now known as aijony
spaceplu- is now known as spacepluk
terrorjack_ is now known as terrorjack
lavaflow has joined #lisp
alandipert has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
PyroLagus has joined #lisp
jasom has joined #lisp
kjeldahl has joined #lisp
kqr has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
jkordani has joined #lisp
dented42 has joined #lisp
dented42 has quit [Client Quit]
dented42 has joined #lisp
fikka has joined #lisp
JuanDaugherty has quit [Quit: Exeunt]
fikka has quit [Ping timeout: 272 seconds]
MichaelRaskin has joined #lisp
dented42 has quit [Ping timeout: 240 seconds]
SaganMan has quit [Quit: WeeChat 1.6]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
dented42 has joined #lisp
ebzzry has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
fzac has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 268 seconds]
pierpa has joined #lisp
ebzzry has joined #lisp
kajo has joined #lisp
unanimousarc has quit [Remote host closed the connection]
fikka has joined #lisp
FreeBirdLjj has joined #lisp
asarch has quit [Quit: Leaving]
[X-Scale] has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
ceevusee has joined #lisp
fikka has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
dwrngr has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 272 seconds]
shlecta has quit [Ping timeout: 256 seconds]
jmercouris has joined #lisp
fikka has joined #lisp
arkaros has joined #lisp
arkaros has quit [Ping timeout: 248 seconds]
<AeroNotix> Soo.
<AeroNotix> What are the chances of a new spec?
<no-defun-allowed> Good morning everyone!
<AeroNotix> no-defun-allowed: did you release cl-distribute?
<Bike> approximately zero
<ebrasca> Do you have some recomendations to lern programing with tcp?
<AeroNotix> ebrasca: https://beej.us/guide/bgnet/
<_death> the Stevens book.. but if you're looking for a small tutorial, check iolib's
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
<housel> ebrasca: Internetworking with TCP/IP Volume One (and Volume Two) by Douglas E. Comer
<no-defun-allowed> AeroNotix: yes I did, it's on GitLab
<ebrasca> I have read some chapters from TCP-IP Illustrated Vol 1.pdf .
<ebrasca> no-defun-allowed: I like decentralised programs.
<no-defun-allowed> I still think there's a few edge cases and stuff that need cleaning up but I'm mostly there.
<no-defun-allowed> For example, I forgot to respond with "ok ~a" if the versions are equal, which isn't an error but we ignore the "new" version
<pjb> AeroNotix: the singularity is expected for before a new spec can be developped.
<AeroNotix> no-defun-allowed: where are the tests?
<pjb> AeroNotix: the only choice you have, is whether you want the singularity to occur with CL or with python?
<AeroNotix> I gave up on Python being a good language roughly 1.513 years ago
<fouric> it doesn't have to be good to be successful is the problem
<fouric> see: c++
<no-defun-allowed> The tests will be surprisingly easy to write actually.
housel has quit [Remote host closed the connection]
housel has joined #lisp
<AeroNotix> I really hate to sound rude but I really get the feeling you're misunderstanding how hard reliably distributing state, consistency and networking issues can be
<no-defun-allowed> You're probably right.
<AeroNotix> no-defun-allowed: suggestion: https://github.com/jepsen-io/jepsen
<AeroNotix> This takes out a lot of the setup/teardown and writing of the actual distributed issues you will see and essentially you will receive just "your code breaks assumptions, xyz, during operations jki"
<fouric> AeroNotix: i might be wrong, but it doesn't look like cl-decentralize actually handles synchronization? it looks like it's just allowing for message-sending
<no-defun-allowed> No, it does perform synchronisation.
<no-defun-allowed> When it finds a new node it asks it for any new messages it has, and compares it to its own.
<AeroNotix> These two topics are really why I am interested in projects like cl-distribute.
<AeroNotix> Personally, I find CL would be the perfect language for distributed programming but there are not many genuinely good libraries and some contracts/guarantees are very difficult to implement.
<AeroNotix> See: erlang
<no-defun-allowed> cl-decentralise doesn't do any verification or storage of its own, but it can be done trivially. See example.lisp.
igemnace has quit [Remote host closed the connection]
<aeth> AeroNotix: What contracts are difficult to implement?
<AeroNotix> aeth: I'm talking in general of certain kinds of distributed models of programming
<no-defun-allowed> Well, I had a project which used a simple interpreter which read distributed files to verify data
<AeroNotix> aeth: oh, btw, I didn't mean difficult to implement *in CL*. I just meant in general
<no-defun-allowed> Then I decided it was too big and messy so cl-decentralise was attempt at writing a distributing layer which was as small and as simple as possible
<AeroNotix> no-defun-allowed: right, now prove it works :)
<makomo> hello o/
xristos has quit [Quit: ZNC - http://znc.in]
<AeroNotix> no-defun-allowed: I'm absolutely sure from reading it that it fails under many kinds of netsplits
<AeroNotix> no-defun-allowed: though AS WELL, from the code, it looks as if a flavour of raft (et al) would be easily added on top, before reads/writes.
<no-defun-allowed> Okay, please tell me how to resolve netsplits then.
<AeroNotix> no-defun-allowed: you need a consensus protocol
<AeroNotix> because currently, under netsplits your code will accept writes on both sides of the split. Leading to bad inconsistencies. It doesn't matter about versions
<AeroNotix> imagine a situation where you have clients reading from cl-distribute, and a collection of servers running cl-distribute serving as the client's datastore.
<jmercouris> you don't need a consensus protocol, you need to distribute the information in a fault tolerant way across the network
<jmercouris> something like raid iv
<AeroNotix> jmercouris: same difference
<jmercouris> and then you need some sort of topology you can overlay on-top of the network to handle failure
<AeroNotix> I mention raft because without googling I am sure there will be a CL library for it
<jmercouris> and the topology has to be self-stabilizing, and acyclic
<AeroNotix> enabling googlevision..... NOW
<AeroNotix> wow, ok. I might've been wrong on that based on the 12 seconds of googling. Either way...
<jmercouris> AeroNotix: you can see into the future, truly
<jmercouris> no wait, I take it back
<jmercouris> the username is simply commonlisp lol
<AeroNotix> hahaha
<AeroNotix> Still
<AeroNotix> there will be a C library that's useful.
<AeroNotix> IT DOESN'T MATTER anyway
<jmercouris> I personally think this should be handled by the OS
<jmercouris> something like a cluster running dragonflybsd
<jmercouris> I guess that is not always an option, say for example, if you are running on a provider cloud
<AeroNotix> I'm not familiar with dragonflybsd at all. Will add it to the research pile
<AeroNotix> LWKT, spicy.
<AeroNotix> no-defun-allowed: the point is, GETTING the data to the various servers in your network is like 1% of the problem.
<AeroNotix> the other 99% is making sure you provide reliable consistency guarantees. What parts of the CAP theorum do you provide, etc.
<jmercouris> I think if we operate on the model of a system without faults, it is a relatively easy problem
<jmercouris> just a simple synchronization that can be achieved by running a sweep through the system
<jmercouris> as soon as we introduce failure modes of any kind, then the problem becomes infinitely more complex and expensive
<AeroNotix> jmercouris: things fail
<AeroNotix> I was running many distributed applications in AWS and I would experience a netsplit probably 1-2 a month
<jmercouris> yeah, things fail indeed
<jmercouris> AWS is the worst service the world has ever seen
<no-defun-allowed> You can put verification in stop-put-p which could handle, for example, ECDSA.
<jmercouris> the fact that one most get certified in it is evidence of how convoluted it is
<jmercouris> s/most/must
slyrus has quit [Quit: slyrus]
<AeroNotix> Well yeah, but AWS really taught me how to handle this kind of shit
slyrus1 is now known as slyrus
<AeroNotix> jmercouris: ignore the certification bullshite
slyrus1 has joined #lisp
<AeroNotix> It's genuinely good if someone else is paying for it
<jmercouris> AeroNotix: maybe I should give it a try some day, though I'm quite satisfied with bare metal / digital ocean
<AeroNotix> I've never lost a machine because of AWS' fuckup. I've lost three with DO. Anecdotal information but w/e
<jmercouris> which datacenter were you using?
<AeroNotix> various
slyrus1 has quit [Client Quit]
<AeroNotix> oh in DO. Amsterdam
slyrus1 has joined #lisp
<jmercouris> Hm, I've only been using Frankfurt and NYC, anyways this is a bit OT
housel has quit [Read error: Connection reset by peer]
<AeroNotix> aye.
<AeroNotix> back to cl-distribute
<AeroNotix> I think the idea of a "decentralised lisp term database" is a great idea. Not sure if one exists.
<AeroNotix> no-defun-allowed: did you ever look at mnesia in Erlang?
<AeroNotix> Think this would be right up CL's alley really.
<jmercouris> I think what would be really cool would be an open source graph database implementation in lisp
<AeroNotix> ,allegrograph
<no-defun-allowed> Well, I can certainly make it read lisp forms instead.
<AeroNotix> no-defun-allowed: no no you're not getting me
<jmercouris> AeroNotix: Allegrograph is not free
<no-defun-allowed> Okay, what do you mean by "lisp term database" then?
<AeroNotix> ah missed the "open source" modifier
<AeroNotix> no-defun-allowed: I just meant a distributed database that stored arbitrary terms.
<AeroNotix> but in CL.
<AeroNotix> ala mnesia
<AeroNotix> because what's required to get mnesia working in CL would satisfy all my wants.
<AeroNotix> It's just a large undertaking
<White_Flame> do arbitrary terms include things like function closures?
<AeroNotix> White_Flame: yes
<White_Flame> that's an interesting serializatio problem
<AeroNotix> make it so
<AeroNotix> jk, functions aren't really required
<AeroNotix> but many datatypes, sure.
SaganMan has joined #lisp
<jmercouris> can't functions just be stored as sexpr?
<jmercouris> what would be the problem? capturing the value of a closure?
<White_Flame> a closure itself can't
<jmercouris> ah, so as I suspecte
<White_Flame> and then you get into fun things like file handles, stream objects, etc
<AeroNotix> No, they just fail
<AeroNotix> you call a function with a serialized FD. The FD doesn't exist on the system being read- it fails.
<White_Flame> huh, so you don't prevent the handle itself from serializing, you just assume its usage will break?
<AeroNotix> pretty much
<jmercouris> I wonder how hard it would be to write a graph database in CL
fikka has quit [Ping timeout: 240 seconds]
<jmercouris> I guess you need to support two types of objects, a node object, and a vertex object
<MichaelRaskin> Maybe only FASL-serialisable things would be used.
<MichaelRaskin> Once I used CL-graph to run inferences on top of it
<jmercouris> but of course the hard part is persistence of the graph database, loading it into memory, and searching it
Bike has quit [Ping timeout: 252 seconds]
<jmercouris> MichaelRaskin: like prolog?
<_death> there's vivace-graph
<MichaelRaskin> Maybe even closer to datalog or RDF inference engines
<stylewarning> i love me some MAKE-LOAD-FORM-SAVING-SLOTS
<jmercouris> _death: I saw it before, pretty poorly documented
mindCrime_ has quit [Ping timeout: 256 seconds]
<jmercouris> is there a standard method to serliaze and deserialize object instances?
<stylewarning> jmercouris: READ and PRINT
<jmercouris> or must you specialize print and read for them (or something like that)?
LiamH has quit [Quit: Leaving.]
<stylewarning> (or READ and PRINT-OBJECT if you must)
<jmercouris> stylewarning: this works for any kind of object? what about objects that contain objects?
<stylewarning> jmercouris: It works for objects that respect *PRINT-READABLY*
<jmercouris> what if there is a cyclic relationship between two objects?
<jmercouris> wouldn't that cause an unprintable loop?
<stylewarning> jmercouris: Nested objects are fine. If *print-circle* is respected, then you'll even get proper references
<stylewarning> CL-USER> (let ((x (cons 1 2)))
<stylewarning> #1=(1 . #1#)
<stylewarning> (print x))
<stylewarning> (rplacd x x)
<jmercouris> Oh I see
<jmercouris> you can set *print-circle*
<stylewarning> (the above is with *print-circle* set to t)
<jmercouris> so you can specialize print-object for any kind of class
<stylewarning> yes
<jmercouris> interesting, good to know
<stylewarning> jmercouris: CL-STORE also is pretty useful to know about (https://common-lisp.net/project/cl-store/)
<jmercouris> Yeah, I've seen it before
<jmercouris> I was just thinking aloud about what one would need to do to make a graph database using CLOS
<jmercouris> maybe you could even build it on top of an RBDMS to serve as your persistence mechanism
<jmercouris> and then you only load parts of the graph in memory at a time
<aeth> stylewarning: Use (setf cdr) instead of rplacd
<stylewarning> no
<aeth> They compile to the same thing but lispers can't read the old style
<stylewarning> it's a standard function and I like the character it adds
<stylewarning> reminds me of an old New England-style house
<aeth> Might as well use setq, then
<aeth> and eq
<stylewarning> I do use EQ for reference-level equality.
<stylewarning> EQ has no other equivalent.
<jmercouris> What else would you use?
<AeroNotix> stylewarning: EQ has no EQ
<jmercouris> could you implement EQ or need it be provided by the distribution?
<stylewarning> it needs to be provided
<jmercouris> unless maybe there is some ext that can give you a unique identity hash or something for each object
<jmercouris> in which case, it is still kind of being provided
<aeth> stylewarning: EQ only differs from EQL with numbers and characters. In pratice, you'd only see EQ potentially differ in a 64-bit implementation for double floats and bignums and maybe characters. Where do you use this?
<stylewarning> aeth: I use it when I want to indicate to the reader of my program that I care about equality of reference.
<aeth> (I suppose certain kinds of complex numbers too)
<AeroNotix> aeth: it's really not what stylewarning was even talking about
dented42 has quit [Ping timeout: 244 seconds]
housel has joined #lisp
dented42 has joined #lisp
<stylewarning> jmercouris: actually, you can abuse your way to defining eq. For instance, (defun my-eq (x y) (let ((l (list y t))) (getf l x)))
vibs29 has quit [Ping timeout: 240 seconds]
<stylewarning> boy doesn't it sound nice for EQ to cons
vibs29 has joined #lisp
<aeth> stylewarning: Problem solved: (defun my-eq* (x y) (let ((l (list y t))) (declare (dynamic-extent l)) (getf l x)))
<aeth> 113 byte disassembly (and a call to getf) instead of 32 bytes (with no calls) in SBCL, though
<jmercouris> lol
<jmercouris> stylewarning: thats great
makomo has quit [Ping timeout: 240 seconds]
Denommus has quit [Remote host closed the connection]
Fare has quit [Ping timeout: 260 seconds]
kajo has quit [Read error: Connection reset by peer]
jmercouris has quit [Ping timeout: 244 seconds]
random-nick has quit [Ping timeout: 276 seconds]
makomo has joined #lisp
angavrilov has quit [Remote host closed the connection]
chipolux has joined #lisp
Bike has joined #lisp
Fare has joined #lisp
Fare has quit [Ping timeout: 248 seconds]
robotoad has quit [Quit: robotoad]
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
pierpa has quit [Quit: Page closed]
<aeth> Is atan with two arguments atan2?
<aeth> Lots of formulas on the Internet reference atan2
<housel> Yes
<aeth> great
<Bike> atan2(y,x) = atan(y/x), generally
<Bike> usually with nice special cases for x=0
<pjb> (atan 5 3) #| --> 1.0303768 |#
<pjb> (atan 3/5) #| --> 0.5404195 |#
<pjb> (atan 5/3) #| --> 1.0303768 |#
<pjb> You can always (setf (fdefinition 'atan2) (fdefinition 'atan))
Kundry_Wag has joined #lisp
slyrus has quit [Ping timeout: 240 seconds]
slyrus1 is now known as slyrus
slyrus1 has joined #lisp
chipolux has quit [Ping timeout: 272 seconds]