freenode/lisp - IRC Chatlog
Search
23:54:03
Shinmera
By nature of the flets being lexical, and thus compile-time, there is no fdefinition to retrieve it at run-time.
23:54:35
Shinmera
You can just use #'foo to get the function object if you know the name at compile-time, though.
0:00:10
malice
I was wondering whether you could do something like (flet <definition of function X> (setf (<value of local function> X) <other function>)), but you can't.
0:06:07
pjb
malice: (let ((f (lambda () 1))) (flet ((f () (funcall f))) (list (f) (setf f (lambda () 2)) (f)))) #| --> (1 #<Anonymous Function #x302006D189BF> 2) |#
0:06:39
malice
Riiiiight. I was thinking of setf though. Someone asked about defun = setf fdefinition, and I was thinking of ways of rebinding local functions
0:15:01
aeth
Imo, if you don't actually need the features flet offers, consider defining separate functions just for debugging and clarity. e.g. (defun %foo (x y z) "something-internal") or even (declaim (inline %foo)) (defun %foo (x y z) "something-internal")
0:15:24
aeth
Pretty much every time I've started with a flet, I wound up later refactoring it out of the function for clarity.
0:16:01
aeth
%foo is usually local enough. If people use it, it's their fault, the % is warning them not to use it.
1:09:22
Xach
i mainly stop with flet when there's only one local function. but even then sometimes it gets recursive and needs a labels.
1:43:03
dmiles
can someone share with me a test case that is an example where alpha renaming is required to make something work?
1:46:25
dmiles
often times i notice macros will use a gentemp to avoid problems when used recursively.. i've assumed that was to avoid some renaming that work automatically happen
1:57:17
resttime
Any resource/tutorial out there for working with the bytes/bits for numbers like C? I dunno a good way of getting two bytes high/low and combining them to make a signed 16bit integer (short) and vice versa.
1:57:45
resttime
I can think of an explicit solution jsut by reading bits but I'm wondering if there's something more 'built-in'
2:08:01
resttime
That works, I can (ldb (byte 15 0) (logior (ash #xFF 8) #x01)) then read the MSB to for the sign
2:48:27
fiddlerwoaroof
I think so: if the destination is all zeroes, you can just use #'(setf ldb) to set the appropriate bytes
2:51:11
resttime
Reading in a short integer from a serial device that sends a low byte and high byte
2:57:44
Zhivago
But it's probably simplest to assemble an integer from the bytes arithmetically and use ldb.
3:01:45
resttime
Sweet, found a function DPB: (dpb (aref byte-vector 0) (byte 8 8) (aref byte-vector 1))
3:03:23
resttime
Then multiply the result (ldb (byte 15 0) combined-bytes) based on the MSB (ldb (byte 1 15) combined-bytes)
3:04:52
resttime
So far this seems to be the best solution, I still wonder though if there's something like (coerce combined-bytes '(signed-integer 16))
3:25:39
binary_
Hey all, this might be a stupid question but does anyone know why learnlispthehardway.org is down?
3:26:59
nyef``
resttime: Not easily-and-portably. I typically end up with something like (defun sign-extend (value width) (if (logbitp (1- width) value) (logior (ash -1 width) value) value)).
3:27:48
nyef``
resttime: If you're working with machine-native types, you might be able to do something clever with an FFI system.
3:32:07
fiddlerwoaroof
binary_: I've never heard of it before, but it looks like you can find it on github
3:33:37
binary_
I've been using the github, it's just that the hyperlinks are ill-adapted for markdown (read-- it would take a hell of a regex to make them work). I'll check out Practical Common Lisp, thank you!
3:34:07
minion
binary_: look at practical common lisp: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
4:07:04
aeth
There is a correct, lossless default mapping, i.e. going cl <-> json losslessly. Afaik, none of the major libraries do that by default.
4:09:01
aeth
iirc the correct methodology for losslessness is: null <-> :null; false <-> nil; [] <-> #(); {} <-> (make-hash-table)
4:09:37
aeth
cl-json's default is particularly bad because it doesn't have a :null so it goes null <-> nil and false -> nil
4:10:25
aeth
You want to disambiguate between null-as-nil (not very common in CL) and null-as-false (extremely common in CL)
4:10:52
aeth
fiddlerwoaroof: In cl-scheme, yes, I turn #f into :false, but that's because Scheme has lists, so CL's nil is becoming '() so I can use the built-in list data structure
4:11:07
aeth
But mapping null, as in the nonsense thing that breaks type symbols, into nil is not a good idea imo
4:11:09
nyef``
I like :null as null because I can pass that from JSON straight to the database and back if necessary.
4:11:39
aeth
"null" is literally just "the thing that breaks type systems" and there is no direct equivalent in CL, where nil, even when used in a sort of nullish way, is false.
4:14:16
aeth
The only time CL's nil behave sort of like a null is when working with lists because (listp nil) is true. Otherwise, you're only going to get nil as null if you define it as such, e.g. the type definition (or null simple-vector)
4:16:53
nyef``
Ah, the other thing that I find important is to know when there ISN'T a field by a particular name in a {}.
4:17:15
aeth
an empty tagged plist or tagged list would still not be nil because the cdr would be nil and the car would be the tag
4:17:46
fiddlerwoaroof
Especially in the latter case, where you're probably going to be looking things up by keys
4:18:35
aeth
(:json-list 1 2 3) -> [1, 2, 3] and (:json-object :foo 42 :bar 7) -> {"foo" : 42, "bar" : 7} seems decently sensible, especially if by default it's a one-way mapping and the vector/hash-table thing is the default. I don't think that would cause issues.
4:19:26
aeth
Well, besides going from symbol to string, but you get that with hash-tables, too. Treating it in a case insensitive way (i.e. upcase to symbol and downcase to string) would usually work unless you're processing arbitrary JSON from the outside world, which could be an overridable flag.
4:34:28
Fare
fiddlerwoaroof, I just meant that cl-json's maintainer seems to have dropped the ball, so forking is required.
4:36:11
Fare
When simple github PRs that unbreak the build go unanswered after many months, it's time to fork.
4:38:44
Fare
If I were still actively developing CL code, I'd join sharplispers and fork a lot of stuff...
4:58:42
jackdaniel
Fare: why didn't you fork a lot of stuff when you did actively develop CL code then?
5:02:32
Fare
jackdaniel, I did fork, take over or helped maintain a few: ASDF, POIU, ASDF-DEPENDENCY-GROVEL, CL-CONTAINERS, CL-PROTOBUFS, LAMBDA-READER -- in addition to those I started.
5:02:42
jackdaniel
another thing is that if they work fine and changes to buildsystem make them break, then is it really problem with support or maybe rather ecosystem stability?
5:03:42
Fare
what if they didn't work that fine, but the bugs they had weren't as visible when the build system itself had its own bugs that are now fixed?
5:05:00
Fare
When I fixed F2CL to work with ASDF 3.3, the code I had to replace was not just bad design that violates the ASDF interfaces, it also had a lot of bugs in corner cases.
5:05:43
Fare
the old code that happened to work in the conditions that the original author tried them isn't sacred, and its bugs don't deserve to live forever.
5:07:11
Fare
jackdaniel, another reason I didn't fork as much back in the days was because there were all these other hackers who hadn't quit yet, like I'm doing.
5:07:12
jackdaniel
I agree that software has bugs. I disagree with implicit equalizing bugs with buildsystem problems. but what do I know? I need to go and fix bugs in software I maintain before sunset
5:08:40
Fare
jackdaniel, going into another project's undocumented internals and expecting it to keep working forever... it's a bug.
5:09:35
Fare
... and even the specification sometimes evolves, to account for previously unforeseen circumstances.
5:09:39
nyef``
The traditional stability guarantee for anything using internals of another project, documented or not, is "if it breaks you get to keep both pieces."
5:10:22
Fare
ASDF has its share of poking at other project internals, BTW, so will need maintenance when these internals change.
5:11:02
aeth
Fare: ah, so you define a custom (:foo-file ...) that goes in :components, like grovel's :cffi-grovel-file and :cffi-wrapper-file here? https://www.common-lisp.net/project/cffi/manual/html_node/Groveller-ASDF-Integration.html#Groveller-ASDF-Integration
5:12:31
Fare
you'll need a new operation that compile-op and load-source-op depend on, that creates the .lisp file.
5:13:49
Fare
I saw some horrors that made sense when written for unmaintained 2006 ASDF 1, but don't make sense at all for 2017 ASDF 3.3. Is it a bug to fix them? I say no.
5:14:52
Fare
I mean, when ASDF 3 breaks them, 2006 kluges are bugs that need to be fixed, not enshrined with more kluges on the ASDF side.
5:57:28
aeth
Wow, the roswell update process is messy. I basically had to delete both the installed directory and .roswell to get it to run without either segfaulting the C part or erroring in the CL part (which, interestingly, both did and didn't drop me into the debugger depending on how and when it errored in the process)
5:59:09
aeth
but I guess roswell is the way to go to quickly test a library on as many implementations as possible with "ros use foo; ros emacs &"
10:02:39
fourier
i did some simple tests against hand-written loops and purely functional approach to the same problems (like sum of squares of a list of numbers) and was surprised what the code generated by series is as performant as hand-written loops and at least twice more performant than pure functional approach with reduce/map
10:05:46
Fare
whereas naive map/reduce sees its arguments as opaque and must do a lot of "administration" at runtime
10:07:32
fourier
series basically generates loops with (go) out of composition of expressions. cool what it is generate as performant code as hand-written loop while still using functional approach.
10:09:48
fourier
yep functional approach lead to creating intermediate lists after applying remove-if/subseq etc, which definitely hits the performance
10:15:01
jmercouris
Hey everyone, I just released version 0.06 of nEXT Browser https://www.reddit.com/r/lisp/comments/7kd3xu/next_browser_version_006/
10:15:29
jmercouris
If you like my project, please consider leaving a star, I'll be working on the GTK port in earnst for the next release, so any help in this domain would be greatly appreciated!
10:21:29
jmercouris
I also would be extremely interested if any users have any feedback, please feel free to contact me via any medium
10:21:54
jmercouris
unless it's something like smoke signals, in which case I cannot guarantee reception
10:27:57
beach
I see some code duplication between history-add and history-typed-add. You might want to create a common abstraction for those.
10:29:08
jmercouris
beach: Yeah, there's some macro that allows you to use the database, but I couldn't figure it out how to work
10:29:33
jmercouris
so you can normally do something like (with database ...) and it'll be like a context thing
10:30:04
jmercouris
Maybe, I would like to figure out the proper way actually, the way the lib wants you to do it
10:30:34
jmercouris
I have to go cook breakfast now, but I'll be back/read anything, thank you for the suggestions thus far
10:32:59
jmercouris
beach: One other thing, I wanted to make a (with-new-buffer) macro, but I couldn't think of a good way to do it
10:33:12
jmercouris
a lot of my functions involve acting on the current buffer, and then there is a derivative acting on anew buffer
10:33:45
jmercouris
beach: It is in parenscript, so I'm very hesitant to write earmuffs, not sure if they are supported in JS, but I try
10:33:48
beach
Yes, I am not reading the code in order to understand what it does. Just doing superficial stuff.
10:34:07
jmercouris
beach: Fair enough, that is also still very useful to me, I miss a lot of things as you can see :D
10:37:36
beach
If so, don't write (WHEN CHILDREN ...) because WHEN suggests that it is a Boolean value. I would write (UNLESS (NULL CHILDREN) ...) instead, as Norvig and Pitman suggest.
10:38:21
beach
And you need to work on your LOOP indentation. I suggest you use SLIME-INDENTATION to get it right.
10:39:23
beach
Furthermore, you have inconsistent LOOP formatting. Sometimes you have DO at the end of a line, and sometimes at the beginning. It is best to put it at the beginning of the line that starts the clause.
10:42:06
Zhivago
Although to be honest, if you want to talk about a list being empty, I'd write (when (empty children) ...) -- null is quite semantically overloaded, too.
10:46:08
|3b|
fourier: same meaning to lisp implementation, but might be interpreted differently by human readers
10:46:42
|3b|
ACTION personally finds (when x ...) easier to parse than (unless (whatever x) ...) though
10:48:05
Zhivago
fourier: You can think of it (when children ...) being an implied (when (true children) ...).
10:48:52
Zhivago
Personally I think if you're happy with overloading null, then you might as well be happy with overloading it in the opposite direction.
10:50:26
|3b|
yeah, i think UNLESS EMPTY is better than UNLESS NULL for me, but still worse than just WHEN
10:50:49
|3b|
ACTION probably wouldn't tell people to change any of them though, since that's just 'for me' :)
10:51:46
beach
fourier: It has nothing to do with semantics and everything to do with the intention as communicated to the reader of the code.
10:52:54
Zhivago
And since C has no common list structure this is more important to communicate perhaps than in CL.
11:02:22
borodust
indentation in emacs CL (via slime) buffer is often breaks for me if there are docstrings present
11:02:35
fourier
i got a feeling what it mostly relevant for string variables,, which could either be null or "". I use alexandria:emptyp for this case then (unless (emptyp arg)..)
11:04:51
beach
Also for docstrings, I use #.(format nil ...) so that I can use ~@ at the end of lines and indent the next line without affecting the docstring.
11:09:49
Shinmera
borodust: Parens at the beginning of lines within strings or comment blocks screw with SLIME
11:26:08
jmercouris
Ok, so I'll always put do on the line with the clause, that's a good rule to have
11:26:31
jmercouris
In terms of the when, unless not, I always prefer not using double negatives, so that one I will have to consider for some more time
11:26:58
jmercouris
In terms of indentation, I don't like always what slime is doing for me, especially in parenscript, it has some strange behavior sometimes
11:27:41
beach
I take it most people in #lisp are not used to collaborative programming. I guess that's kind of normal in some way.
11:30:15
jmercouris
I am very used to collaborative programming, that's why I'm such a huge fan of standards
11:31:05
jmercouris
In python one should only care about the truthiness, and I think that's a good way of doing things
11:32:12
beach
jmercouris: Notice how you say "I always prefer", "I don't like", "I think that's a good way".
11:33:59
beach
jmercouris: That you claim to be in favor of standards, but then you have several objections that indicate that your personal preference if more important.
11:34:35
jmercouris
beach: I think you're right I should reconsider my objections, thank you for pointing out this inconsistency
11:34:51
beach
jmercouris: Look, I don't care how you write your code. I gave you advice that corresponds to what two great Common Lisp gurus have written. If you don't want to follow it, then that's fine with me.
11:35:19
jmercouris
beach: I understand you have no stake in it, which is what makes your opinion objective and useful, you don't have to remind me of that
11:35:54
jmercouris
I am always ready to admit when I am wrong, which is unfortunately too frequently :D
11:37:40
jmercouris
shka: being wrong is fine, being stubborn is the worst, and being correct is the best ;)
11:38:37
|3b|
ACTION thinks being stubborn isn't too bad when you are right, but since you tend to think you are right when you are wrong, any blanket rating of stubbornness isn't much use :)
11:45:02
jmercouris
Zhivago: that it is, I was not lying about my position :D, but it is true that I should be more open to reconsidering some of my opinions if they conflict with some of the best lisp devs
11:45:31
jmercouris
maybe in the end I will not agree, but I should give them a more thorough consideratio