<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>
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>
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.
<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>
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.
<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.
<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?
<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]
<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.
<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>
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 :-)
<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.
<phoe>
(FTYPE FUNCTION (NUMBER) (VALUES NUMBER &OPTIONAL))
<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?
<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.
<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>
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.
<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.
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>
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)
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.
<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
<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 :)
<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>
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))