freenode/#lisp - IRC Chatlog
Search
11:01:57
White_Flame
that sort of style is fine for banging out quick & dirty utilities for one-off use or prototypes
11:02:31
White_Flame
but as far as code that you're going to keep goes, that's going to be an opaque blob if you come back a month or two later and need to rework something
11:02:49
pjb
Now, the funny thing with that exercise, is that it cannot be so easily implemented in C on a 32-bit machine :-)
11:03:51
White_Flame
that sort of style is fine for banging out quick & dirty utilities for one-off use or prototypes
11:03:52
White_Flame
but as far as code that you're going to keep goes, that's going to be an opaque blob if you come back a month or two later and need to rework something
11:07:55
shangul
perhaps you are right. But I've red a part of PCL and wrote that code and another one a little longer than that. I'll get frustrated if I go like this.
11:09:20
White_Flame
code golf is fine when you're learning and fiddling with how to call certain standard functions
11:09:37
pjb
shangul: for example, you use read-line to read the numbers. Fine. But users are know to add spaces before or after their inputs! So at least you should use string-trim to remove those spaces.
11:09:57
White_Flame
but as I was talking above in comparison to haskell, Lisp tends to be a bit verbose in the micro-issues, but becomes much more compact for larger projects
11:10:28
White_Flame
it doesn't hyper-optimize on the line-by-line syntactic issues, but rather allows you to build abstractions well, which makes difficult problems much easier to tackle
11:12:53
White_Flame
if something doesn't make sense to you yet (like why people whould make all thse named defuns for everything), then just keep going with other things first
11:13:59
shangul
pjb, I'm not saying you are wrong, I'm just saying 100 lines for a one week beginner is too much
11:16:03
White_Flame
the thing is, the complexity is not high there. You just have to get more comfortable with the language (like any language) to be able to skim & read it well, instead of seeing it as a big impenetrable wall
11:19:47
shangul
pjb, phoe, I was afraid of this. that you write 100 lines for me and I waste your time by not using it
11:20:22
White_Flame
at some point in the near future you'll look back to this problem and say "oh, duh"
11:22:34
pjb
shangul: granted, there are two different phases. When you're just learning the language, you write small expressions just to exercise the operators you're learning. In that case, you're essentially writting tests for the language operators :-)
11:23:27
pjb
shangul: but if you present a small problem statement, like a school exercise, I would grade differently the two kinds of solution.
11:25:07
pjb
In the first phase, you are analysing and studying the details of each operators. In the second phase, you are synthesizing small programs, demonstrating your understanding on how the individual language elements can be combined to implement a solution. This is more like real programming.
11:25:52
beach
kuribas: Here are some ideas for you: http://metamodular.com/Common-Lisp/suggested-projects.html
11:25:53
pjb
kuribas: this is wrong; those great libraries are usually implemented in C or C++ and they are just used from python. you can use them as well fromCL.
11:41:47
White_Flame
kuribas: the appeal of Python is that it makes the easy easy. There's a lot of simple tools at hand, and low barrier to entry for the syntax
11:42:33
kuribas
White_Flame: I suppose also that it has easy answers to most problems. Unfortunately those aren't always the best.
11:43:03
White_Flame
sure, but it keeps a lot of newbies, which then take the language beyond where it really is comfortable going
11:43:56
kuribas
And then they get into problems because of the backwards way of doing things in Python.
14:20:13
jmercouris
So I was reading a bunch of the response to my article on reddit about eco-programming
14:20:46
jmercouris
"An interesting example of an inefficient part of a language would be LISP's 'list' structure - compared to say C++'s vector. Vector is specified to be a single contiguous block of memory - allowing for efficient pointer arithmetic lookup."
14:20:54
jmercouris
"Although theoretically you can store your cons-list thing in a contiguous memory block; you can't do the same pointer arithmetic to give you the nth cell (unless you make a non conforming LISP with the guarantee attached)."
14:21:24
jmercouris
Now, I am thinking I am pretty sure it is possible to make the pointer arithmetic hold true AND have a conforming lisp by layering some abstraction on top
14:22:06
jmercouris
beach: to put things into context, the discussion was, can one design a language such that the implementation HAS to be inefficient
14:22:29
jmercouris
my answer was, I don't believe so, the implementation can always make something implementation as long as it fulfills the grammar syntax, and built-inrequirements of the language
14:23:04
jmercouris
beach: here's the sub-thread: https://www.reddit.com/r/programming/comments/8r9ngc/the_ecoprogrammers_dilemma_use_electron_or_save/e0rn7kq/?context=3
14:23:17
beach
jmercouris: Vectors are faster for random access, but list are more flexible in that they can grow and shrink easily. They can also share elements between several lists.
14:23:39
jmercouris
but the question is rather, can one design a language such that the implementation *MUST* be slow
14:25:09
jmercouris
is it possible to design a language specification such that the counting of the numbers would take longer in language A then language B
14:25:33
jmercouris
given that the implementation is free to implement the language however they so choose
14:26:31
beach
I suppose you can specify in your language definition that numbers have to use Church encoding.
14:29:12
beach
jmercouris: What *is* true is that Common Lisp lists pretty much have to have O(n) lookup complexity. But comparing them to vectors is really dumb too, because vectors are bad with other things.
14:29:43
Bike
old lisp implementations did cdr coding so there were O(1) lists, but it's kind of silly
14:29:46
beach
jmercouris: Try adding a new element to the front of a vector. That's an O(n) operation, where n is the length of the vector.
14:30:05
Bike
and on the flipside, just being able to get pointers into a vector doesn't actually mean they're contiguous, or that access is O(1)
14:30:17
beach
jmercouris: So vectors and lists are two different data structures that are good for different use cases.
14:30:30
Bike
c.f. whatever latest article about how turing is wrong because cpu caches exist, or whatever
14:31:57
jmercouris
beach: yes, but couldn't one had a vector with the addresses to each element in the list?
14:33:00
jmercouris
Here's what you'd have to do, you'd have to shuffle all sorts of elements around whenever you cons something
14:33:11
jmercouris
depending on whether you need to allocate a new array to grow it, or insert something in the middle etc
14:33:32
jmercouris
you'd lose a lot of those characteristics, BUT, you would have the very fast look up time
14:33:34
Bike
well, that's what beach said earlier- you're losing the "can grow and shrink easily" property
14:34:05
jmercouris
as long as you are adding and removing from the end of the list, it should be fine
14:34:54
jmercouris
yes, of course, but if you pad enough, it could result in very fast look up times, and some other interesting properties
14:34:56
Bike
it's just a resizable vector, which is a nice structure, but has different characteristics from a list
14:38:00
Bike
i mean, lisp has this already, you make an adjustable vector and vector-push-extend it
14:54:15
pjb
jmercouris: Of course there are comparisons of lists vs. vectors, eg. by Stroustrup in C++, but: 1- the author is obviously biazed, 2- it depends on the hardware (notably caching), 3- it's rather unrelated to global performance, which depends more on other language design factors. For example, C const is used so inconsistently, that you often have to copy a const char* string to pass it to a char* parameter, even if most of the t
14:54:15
pjb
it won't be mutated. It's even worse in C++, where a lot of copying is done or has to be done when in lisp you would just pass a reference.
14:56:25
pjb
jmercouris: notice notably how passing a reference to a mutable or an immutable object in lisp doesn't depend on compilation time declarations, but on run-time check. Therefore if the actual processing doesn't try to mutate the object, when an immutable one is passed, it will work perfectly good. It's all win, programmer time, compiler time, run-time. At the minimal cost of a small dispatch or check at run-time. On the other ha
14:56:25
pjb
equivalent would require a big cost in programmer time, compiler time (compiling lots of generics variants or templates), AND still at run-time in copying things everywhere.
14:59:37
jmercouris
I guess there are indeed many assumptions, and lots of external factors not considered within this argumentation
15:00:06
jmercouris
a complete analysis would probably be too much work and effort for the sake of replying to a comment on reddit
15:00:10
pjb
For example, there's the famous argv thing. In programs, usually it's treated as an immutable vector of immutable strings. However, some programs want to overwrite some of the argument strings (eg. passwords). The actual effect is implementation dependent (eg. whether this has consequences on how ps(1) reports the command). Nonetheless, in programming languages as C or C++, there's no easy way to denote that you won't mutate an
15:00:10
pjb
in general, but sometimes you will stil mutate it. In lisp, if the string are mutable then they're mutable, and if not, then they're not, and it's a run-time check.
15:01:04
pjb
Basically, what I mean is that C and C++ programmers and language designers don't have the means of what they aim at.
15:02:22
pjb
If you understand lists in lisp, then all your accesses to list elements will always be O(1).
16:03:13
loke
Scrolling in the climaxima windows looks horrible, and in the videos you get a taste of that
16:10:53
loke
beach: I was looking at the WITH-DOUBLE-BUFFERING macro, and tried to use it in the simplest possible way when scrolling.
16:11:09
loke
Something did happen (I got lots of garbage on the screen, and _some_ of the content moved)
16:11:39
loke
beach: Do you know how that thing works? It clearly wors in some cases (like the cube game in demodemo)
17:26:43
White_Flame
hmm, there's no way to setf array-displacement to slide a window over another array?
17:27:57
White_Flame
just figuring out a nice fast clean way of doing hex string -> unsigned-byte 8 vector conversion
17:35:54
aeth
White_Flame: Depending on how long the range is, you might also just want to return multiple values and write a simple macro on top of that to (values (aref ,a ,i) (aref ,a ,(1+ i)) (aref ,a ,(+ 2 i)) ...)
17:36:31
aeth
For a low number (3-5 maybe?) you'd probably produce faster code, at the cost of not having sequence functions available for your range.
17:40:59
aeth
Lisp libraries in your distribution's package manager are for full applications using Lisp that your distribution happens to ship, such as Maxima.
17:43:35
White_Flame
...and a 2-character displaced string window sliding across a long input string works. Nifty
17:46:17
aeth
White_Flame: Oh, 2 characters? I meant something like this (and only the setter needs to be a macro, actually): (declaim (inline two-aref)) (defun two-aref (a i) (values (aref a i) (aref a (1+ i))))
17:48:00
aeth
Yeah, :start and :end should be on every sequence operation, built-in and library-added, exactly so you don't need this sort of thing.
17:57:31
White_Flame
hmm, my ffi union between a double-float and a long doesn't match the byte-endianness of doing the same in Javascript's byte buffers. fun
18:15:07
asarch
Where could I find this function? "The function ASDF/INTERFACE::OPERATION-FORCED is undefined."
18:30:31
asarch
Since Debian's native SBCL cannot use McCLIM from QuickLisp, I downloaded this sbcl-1.4.8-x86-64-linux to use
18:32:35
Bike
current asdf has asdf/interface though https://github.com/fare/asdf/blob/b6d2f9b44c047a5e65520692159cab7d3e9e072e/interface.lisp
18:43:34
pjb
White_Flame: have a look at com.informatimago.common-lisp.cesarum.array:nudge-displaced-vector
19:20:21
White_Flame
the notion tends to be called a barrier, when you're waiting on N things to complete
19:20:27
asarch
One stupid question: what's the problem with CLisp (the implementation)? What's wrong with it? Why SBCL over it?
19:21:38
aeth
asarch: CLISP is an interpreted Lisp that isn't dead (it's still under development) but is a zombie (it hasn't had a new release in 5-7 years, not sure when)
19:22:01
aeth
asarch: SBCL is the fastest ahead-of-time compiled Lisp, with very frequent releases, and the most helpful warnings/errors (most of the time).
19:22:04
pjb
It's not a zombie: it's a stable implementation, that doesn't break your programs every month!
19:22:15
White_Flame
because it's a byte-coded interpreter, clisp is very compatible to run on new platforms
19:22:32
pjb
But if you want changes, you can always get the HEAD of the git repo, and have fun, eg. with clearvir being integrated into clisp.
19:23:25
aeth
Does CLISP have a larger fixnum and specialized arrays for :element-type single-float and double-float, yet?
19:25:12
edgar-rft
clisp is newbie-friendly because it has a good command-line REPL. Newbies don't need to learn Emacs first. In the long run of course it pays off to learn Emacs, too.
19:25:33
aeth
If you even have to think about performance at all, you can support SBCL and CCL, and basically cannot support CLISP. If performance is not an issue, use whatever.
19:26:05
pjb
Well again about performance, it depends on what and how. For scripts, clisp is faster.
19:26:29
pjb
it loads faster (begin much smaller), and it starts to run the script earlier, so for short-running scripts, it will also end earlier.
19:27:19
pjb
ecl is the most integrated into unix, since it compiles by generating C code compiled with an external compiler (gcc).
19:28:13
edgar-rft
compiler-based CL implementations tend to choke with every little typo. Using CLisp turned out to be much friendlier with my idiotic mistakes.
19:30:19
Xof
pjb: I don't believe that clisp's startup is faster than sbcl's. It wasn't the last time I measured
19:30:48
pjb
Perhaps it has changed. New benchmarks would be in order… mine were a long time ago too.
19:32:25
aeth
If you really want to cheat, just have your script use the SBCL image that's already running to power your stumpwm. Via swank or something.
19:34:55
aeth
pjb: What's the CLISP equivalent of your command? Because I get sbcl --no-userinit --eval '(quit)' 0.00s user 0.00s system 87% cpu 0.008 total
19:36:52
aeth
pjb: SBCL might run fast for me because it's always running, assuming a different SBCL in memory would have an impact on a new one spawning
19:37:17
aeth
In fact, more often than not, there are two SBCLs running, one for stumpwm and one in emacs+slime.
19:38:50
White_Flame
Xof: it would be interesting to do that with a script of some dozens of lines of defuns, with a (quit) at the end
19:40:01
White_Flame
well, there are the plain parallel funcalls and such, which I presume would block until all finish. But if you're launching things at arbitrary times, not all at once, then yeah it's more management
19:43:08
pjb
The point is that all implementations have their strong points and their weakness. Use all of them!
19:45:00
Xof
but in any case, that evidence is consistent with my prior that clisp startup is twice as slow as sbcl
20:00:11
Ukari
multiple value and defstruct, which is better for return result in the form of {a, [...b]}?
20:06:25
White_Flame
the tradeoff with just 2 values is a small allocation + having to use slot accessors in the caller; vs the verbosity of multiple-value-bind
20:09:55
White_Flame
btw, fiddling around with SBCL disassemblies, it looks like it fits up to 3 return values in registers before spilling to the stack
20:56:21
drmeister
The ASDF version that ships with Clasp is 3.3.1.2 - is quicklisp getting some other version of ASDF?
20:56:43
drmeister
I feel like I've seen this before and fixed it and now it's back again - but it's been at least a year.
21:03:48
drmeister
It happens when I build cando within a docker image - maybe I'm cloning another ASDF in the Dockerfile.
21:08:56
k-stz
I just updated to emacs26.1+slime2.0 and it freezes for a short time everytime I type in an argument to a function at the repl. It does so for every character
21:17:42
k-stz
just found a thread on reddit with exactly the same problem: https://www.reddit.com/r/emacs/comments/8nyl9w/errors_in_sbcl_slime_repl/
21:41:00
msmith
so I'm trying to read utf-8 bytes from a file for testing purposes. For some reason, when I read-byte I'm not getting what I expect. here is the paste https://pastebin.com/9rySSXTK
21:49:21
pjb
Theorically, an implementation could have different binary file formats, but in practice, not on posix systems.
21:49:37
Bike
the external format tells lisp how to convert bytes into characters. you're not having it do that, so, pointless.
21:50:23
pjb
msmith: a file containing text encoded in utf-8 won't contain any null byte. Your file, starting with 129 0 0 0 126, assuming those are the values of the 6 first bytes, is not an utf-8 encoded file.
21:51:09
pjb
msmith: on the other hand, if your file starts with the string "129 0 0 0 126", then the bytes are actually: (map 'list 'char-code "129 0 0 0 126") #| --> (49 50 57 32 48 32 48 32 48 32 49 50 54) |# and this INDEED starts with the byte 49 which is the ASCII or utf-8 code for #\1 !!!
21:51:56
pjb
So if your file is a TEXT file containing integers representing the values of octets, you must read it as a text file, and use READ to parse those integers.
21:53:07
pjb
(with-open-file (s p :direction :input :element-type 'character :external-format #+sbcl '(:utf-8 :replacement #\?) #-sbcl :default) (loop for byte = (read s nil nil) while byte collect byte))
21:53:59
pjb
msmith: you may want to have a look at: https://www.cliki.net/CloserLookAtCharacters and I might write someday a similar page about binary files…
21:55:34
msmith
yeah, I was under the impression that the external format option would cause the with-open-file to read the integers as bytes
21:55:52
pjb
And yes, don't laugh, but we find this kind of representation/encoding problem a lot of times, in places it shouldn't appear. People (well, "C programmers") don't understand the difference between binary and text, and that hexadecimal is a textual representation for binary, etc.
21:56:34
pjb
And worse, those idiots write data as hexadecimal textual representation and are not able to parse it back in a case insensitive manner, so you find broken middle ware in places you wouldn't believe…
21:57:03
Bike
if you deliberately wrote in the integers that's a more normal mistake than i was imagining, anyway
21:58:01
pjb
In lisp you have to be careful indeed, because you can write a textual representation of a sequence of bytes easily with PRINT in a text file. But it is as easy to write it in binary form with WRITE-SEQUENCE in a binary file.
22:06:57
karlosz
is there any way to check if a symbol is external in a package without do-external-symbols?
22:09:57
pjb
(multiple-value-bind (ps sk) (find-symbol (symbol-name s) p) (and (eq ps s) (eq :external sk)))