<pjb>
*query-io* is an interactive bidirectionnal stream to communicate with a human user (an operator).
<pjb>
*standard-input* and *standard-output* ar input and output of the program (could be redirected to/from files or pipes).
<Bike>
it's a two way stream that the user can input things to and read output from
<pjb>
*terminal-io* is an interactive bidirectionnal stream to communicate with the terminal.
<Bike>
so probably standard input and output, yeah.
<pjb>
The diference between *termina-io* and *query-io* is that *query-io* may occur differently than on a terminal. It could be audio, it could be sign language (video), it could be GUI, etc.
<pjb>
*query-io* IS DEFINITELY NOT *standard-input* and *standard-output*.
<pjb>
It could be mapped to *terminal-io*.
<pjb>
Same difference between /dev/stdin /dev/stdout and /dev/tty !
<pjb>
eg. you can read passwords from *terminal-io* or from *query-io*, but not from *standard-input*.
<koshmar>
hm, so even if I use a programm and redirect STDIN/STDOUT via let say "<" ">" , the part with *query-io* will still interact with the user?
<koshmar>
interesting
<pjb>
Then there's *debug-io* and *trace-output*.
<pjb>
*debug-io* is also a bidirectionnal interactive I/O, but to the programmer. It can go to the *terminal-io*, to the *query-io*, or somewhere else, for example, to slime!
<pjb>
*trace-output* is debuggin logs are written.
<pjb>
koshmar: definitely, since *query-io* must go to the human user. So on a terminal, it would go to *terminal-io* which would go to /dev/tty, not /dev/stdin or /dev/stdout.
<pjb>
You can see that it's a littler richer than bare unix…
<Bike>
well, ideally.
<koshmar>
hm, interesting, is it specific for CL or your typical unix/linux has all the same streams?
<pjb>
unix has only stdin, stdout and stderr, with redirections (file, pipes or terminal).
<pjb>
/dev/tty is an addition, it has to be opened explicitely (and it's not available on all unices).
<Bike>
the variable is a lisp thing, of course, but if the lisp is running in a nix operating system it will need some support
<koshmar>
I see, interesting :) if I would have encountered a programm before where I cannot redirect in and out with my "<,>", I would raise an eyebrow...
<pjb>
Of course. But if you run a GUI CL implementation (Clozure CL.app, Lispworks, etc), you can expect *query-io* to go thru the GUI (a dialog), while *terminal-io* would go to a terminal emulation window.
<pjb>
And of course, *debug-io* would go to the GUI debugger.
<koshmar>
ah, I see
<pjb>
koshmar: on unix, you can have programs using curses; you could still redirect stdin/stdout, but it would break. They're designed to work exclusively on the terminal.
<pjb>
The program could check for redirections and use /dev/tty for curses.
<pjb>
koshmar: see TAOUP for more details of all kind of unix programs.
Aruseus has quit [Remote host closed the connection]
sjl has joined #lisp
akoana has left #lisp ["Leaving"]
cyberoctopi has joined #lisp
dacoda has quit [Ping timeout: 252 seconds]
patlv has quit [Ping timeout: 252 seconds]
<PuercoPop>
mfiano: watching the Atlanta CL video I you mentioned that using read-macros for compilers are not a good idea. Wouldn't Vacietis proof otherwise? P.S. Good job plugging Sly!
lumm has quit [Quit: lumm]
patlv has joined #lisp
t58 has quit [Quit: Night]
cyberoctopi has quit [Ping timeout: 240 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
slac-in-the-box has joined #lisp
patlv has quit [Ping timeout: 252 seconds]
Kundry_Wag has quit [Ping timeout: 255 seconds]
pillton has quit [Ping timeout: 264 seconds]
_whitelogger has joined #lisp
pent has quit [Ping timeout: 240 seconds]
pent has joined #lisp
p_l has quit [Ping timeout: 240 seconds]
p_l has joined #lisp
volg has joined #lisp
fowlduck has quit [Ping timeout: 268 seconds]
fowlduck has joined #lisp
cyberoctopi has joined #lisp
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
cyberoctopi has quit [Ping timeout: 252 seconds]
trafaret1 has quit [Ping timeout: 255 seconds]
_whitelogger has joined #lisp
_whitelogger has joined #lisp
slac-in-the-box has quit [Remote host closed the connection]
<theemacsshibe>
No, since the matrix-irc bridge hasn't been restarted after the crack yesterday.
<beach>
Oh.
<theemacsshibe>
I heard it will be restarted in the next few days, but the attacker may have access to the bridge users' passwords as unencrypted messages to nickserv would have been retained.
volg has quit [Quit: Leaving]
<beach>
That's really bad.
cyberoctopi has joined #lisp
<theemacsshibe>
Indeed, we think the attacker also got hashed matrix passwords as well among other data. The attacker was very smug about it too: https://imgur.com/a/c6dGMdO
<theemacsshibe>
On the upside, the 0day used has been reported and patched, and hopefully everything will be back to normal in a week's time.
<aeth>
That's basically my worst nightmare with cloud hosting my IRC and why I went with a "local cloud" of a raspberry pi for that
argoneus has quit [Quit: No Ping reply in 180 seconds.]
<beach>
refpga: A function should usually fit on a screen, and should preferably be a lot smaller.
<theemacsshibe>
Yeah, I think you should break it up into smaller functions before considering much analysis.
<beach>
refpga: You also need to format your code according to established conventions.
<theemacsshibe>
Is this a chess engine? I have one which is admittedly messier but I think it was easier to test...
<refpga>
Sort of, I'm trying to generate moves in reverse.
<theemacsshibe>
Oh. With captures, is that even possible?
<refpga>
It's used in Retrograde analysis. Like Endgame Tablebase generation.
<theemacsshibe>
(Well, it would be possible, but it'd grow very quickly.)
<refpga>
I think it is. Uncaptured pieces are simply the missing pieces, which could at max. be, say, 9 queens for each side, 9 rooks, 9 bishops, 9 Knights, given all the pawns are missing. But To decide how to grow it, I need to have a function that gives a list of possible Reverse moves.
<beach>
refpga: A closing parenthesis should never be preceded by whitespace (including newline).
<beach>
refpga: You have mysterious and arbitrary blank lines.
<refpga>
Sorry, 10 rooks, bishops.
<beach>
refpga: You need to indent your LOOP code properly. I use slime-indentation for that, so that you can put the loop keywords first on a line.
<refpga>
Oh, like I've done with labels?
<beach>
refpga: There is a general rule in programming where you use the most specific construct that will do the job. So rather than (= 0 from--piece), use (zerop from-piece).
<refpga>
Thanks.
<beach>
refpga: Sometimes a docstring is preceded by a blank line, sometimes not. Sometimes it is followed by a blank line, sometimes not.
<beach>
The message is not clear.
<beach>
Why sometimes one and sometimes the other?
<beach>
Sometimes a comment starts with ";;", sometimes with ";; ;;".
<refpga>
I used emacs comment-block. So if I uncomment the block the ";; ;;" one becomes ";;" keeping previously commented ones still commented.
<refpga>
I mean, comment-region
<theemacsshibe>
comment-dwim?
<theemacsshibe>
it's also conveniently bound to M-;
<beach>
refpga: In this case, the only commented block is two lines of comments.
<beach>
Comments on the same line as code should start with a single semicolon.
<refpga>
Yeah. It's messy, I would have cleaned up after it worked.
<beach>
There is no particular reason to have the code currently on line 65 on a line on its own.
<beach>
refpga: vertical space is a precious resource, because the more lines the programmer can see at the same time (given that other layout constraints are respected, of course), the better.
<refpga>
It goes to 112 columns otherwise.
<refpga>
Thanks for the analysis.
<beach>
refpga: But you already have lines that wide, like line 20, 38, etc.
<beach>
Oh, and you can replace #'(lambda ...) with (lambda ...)
<refpga>
That's 97 columns, I have a screen of 101 columns. That's set acc. to font size.
q9929t has joined #lisp
<beach>
Line 100 is how many columns?
dddddd has joined #lisp
<refpga>
I understand #'(lambda) and (lambda..) but, I guess, it's consistent to use #' always for passing functions.
<refpga>
Ah, 119 columns. :D
<beach>
I find it hard to believe that if you put the code on line 65 after that of line 64, then you will get a line that is wider than line 100.
<beach>
So the message is contradictory.
cyberoctopi has quit [Ping timeout: 250 seconds]
<beach>
Either you don't want long lines, and you should limit lines 99 and 100, or you don't mind, and you can eliminate line 65.
<beach>
refpga: (lambda ...) is better.
<refpga>
Thanks, I'll clean it up.
<refpga>
Why do you prefer (lambda ...)?
<beach>
Consider it the constructor for functions.
<theemacsshibe>
It's pretty clear that it will produce a function.
<refpga>
Is there any literature on lisp style, and productivity?
<theemacsshibe>
the lisp-lang.org guide goes further and gives advice on project directory structure, libraries and more: https://lisp-lang.org/style-guide/
<refpga>
I should probably come back with a better design.
<beach>
Right you are.
argoneus has joined #lisp
<beach>
theemacsshibe: Right you are.
nowhere_man has joined #lisp
<refpga>
Also, how does one decide when to use imperetive function names, like make-objectname, or run-process, and when to use declarative names like, objectname? I think functions which produce only side-effects should be imperetive, and the ones which return and substitute the value in an expression (almost always with lisp) declarative. Is that reasonable?
<beach>
Never gave it any though, but it sounds reasonable.
<refpga>
Default function for creating a new struct, created by defstruct is imperetively named, make-structname, but when accessing some field, it's structname-fieldname which seems declarative.
<theemacsshibe>
Depends on how I'd say it in a sentence.
<refpga>
I only thought about it when I read Knuth saying that we must use imperetive names for code blocks, he was talking about literate programming.
<refpga>
theemacsshibe: Can you give examples?
<theemacsshibe>
I'd say "make a colour which is a mixture of the box's colour and the cat's favourite colour", but then maybe I'd lop off the "make" if we put that in context of what a function does.
<theemacsshibe>
So, maybe not actually.
<theemacsshibe>
My choices do usually reflect what words I would use in an English description, but I have had an edge case come to mind recently.
<theemacsshibe>
I want to make a few simple objects to describe how inducting one "object" in a system I made affects another "object", such as adding computed slots to an object.
<theemacsshibe>
It should be "add-computed-slot" by this rule but classes should be noun phrases, like "computed-slot-adder".
<theemacsshibe>
I'll be back in a bit...
<refpga>
I think this distinction can help establish a distinction b/w pure and impure functions that do similar tasks. Is there a better way to make this distinction?
rumbler31 has quit [Remote host closed the connection]
<refpga>
I mean, declarative functions need not be pure, but the library author can mention that in the docs.
rumbler31 has joined #lisp
rumbler31 has quit [Ping timeout: 252 seconds]
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #lisp
ldb has quit [Quit: leaving]
lumm has joined #lisp
<theemacsshibe>
I'm back now.
<theemacsshibe>
I would probably call a machine that adds computed slots a computed-slot-adder, come to think of it. However, the object doesn't perform that work.
_whitelogger has joined #lisp
vaporatorius has quit [Ping timeout: 240 seconds]
<refpga>
yeah, I was concerned with functions. That objects should be nouns is fine.
<refpga>
I thought it would be cool if I could tell which functions are impure merely by reading the function name.
rumbler31 has joined #lisp
<refpga>
There might be better ways though.
<theemacsshibe>
Sometimes the prefix n- (more like nconc, nsubseq, etc) or the prefix ! (more like set!, append! in Scheme) is used to denotate functions with side effects.
<refpga>
I see.
<theemacsshibe>
This is very different from your suggestion to use different forms of a phrase to imply properties of a function though.
rumbler31 has quit [Ping timeout: 250 seconds]
<refpga>
I thought of pure- and impure- prefixes before, but I thought that would not be elegant. That would have been regular though.
<refpga>
Even people who are not much familiar with english can understand with prefixes.
<refpga>
theemacsshibe: Is your chess engine open-source?
<theemacsshibe>
I don't think I will publish it soon, it is very messy as I did not know how to approach the problem when I started.
<refpga>
I see. This is my first non-trivial lisp program (too?).
<theemacsshibe>
I've written several Lisp programs before, but none have been chess engines.
<aeth>
! is a suffix, not a prefix
<theemacsshibe>
My bad, yeah, it's a suffix, aeth.
<aeth>
n is nonconsing... but something with side effects doesn't have to be non-consing e.g. (defun foo (a) (setf (aref a 1) 42d0)) will almost certainly cons because it returns 42d0, which is almost certainly boxed
q9929t has quit [Quit: q9929t]
<aeth>
So the Scheme convention doesn't really have a parallel in CL, which is why it gets borrowed in CL sometimes
rumbler31 has joined #lisp
rumbler31 has quit [Ping timeout: 268 seconds]
<TMA>
aeth: unless it returns the same boxed constant like it would if it were '(1 2 3) there
<aeth>
(random 42d0) then to be extra-portable
<refpga>
What is a boxed constant?
<aeth>
Type checking is usually done at runtime (in rare cases it doesn't have to be) so everything has to have a type tag. If the thing is smaller than a word, it doesn't need to be boxed because the tag fits, so e.g. fixnums or (in 64-bit implementations) single-floats. Most things are boxed. Even though 42d0 fits in a word, the tag makes it too large, so normally it has to be allocated.
<aeth>
By "constant" I think TMA is referring to literals, stuff like "123" or #(1 2 3) or '(1 2 3) which can be optimized internally by assuming they won't mutate.
* TMA
was indeed referring to literals
<aeth>
I think TMA is referring to a potential optimization where there could just be one 42d0 in memory and everything just refers to that 42d0 so there's no new consing
<beach>
aeth: Sometimes, adding a tag is considered "boxing" as well.
<beach>
aeth: As in the difference between a raw machine integer and a fixnum.
<beach>
aeth: There is no "box", then of course.
<aeth>
You can actually have more optimizations than what TMA is talking about with a constant 42d0 in code. e.g. (defun foo (a) (declare ((simple-array double-float (2)) a)) (setf (aref a 1) 42d0) a) ; because it returns a instead of the double-float and it sets to a data structure that must hold double-floats, it never allocates a 42d0
<refpga>
aeth: I see. I'm afraid I don't exactly get what 'tag' are you referring to.
<TMA>
refpga: are you familiar with the concept of tagged union or discriminated record from other languages?
<beach>
refpga: Common Lisp can not use raw machine values, because the system needs to be able to inspect a "pointer" to determine what type it is. So for instance, a fixnum is often represented as a machine integer shifted left one position, so that it always has a 0 in the least significant bit.
<TMA>
refpga: or with the VARIANT type of some COM/OLE/Windows API?
<beach>
refpga: Then other objects will always have a 1 in that position.
<aeth>
refpga: in SBCL if you disassemble code with a literal 42 integer in it, you see SBCL's specific tag. (defun foobar () 42) (disassemble #'foobar) ; notice that 84 is the literal in the asm, not 42, i.e. (ash 42 1) or shifting it once to the left, i.e. multiplying it by two
<aeth>
refpga: in SBCL, the fixnum tag is just a 0 at the end of the integer.
<aeth>
Most have several bits, but it's a similar principle. SBCL's is just the simplest possible (and largest possible) fixnum for 64-bits.
<refpga>
I'm familiar with unions, not with tagged ones. Looking them up.
<refpga>
But what if I need to use all the 64 bits?
<aeth>
CL has bignums. You can also be extra careful
<aeth>
In SBCL, you can safely use (unsigned-byte 64) and (signed-byte 64) if, like with the double-float example, you never have that object leave the scope of the function as a return value and if you set into a data structure only set into a data structure that can only hold elements of that type
<aeth>
Not every CL is that optimized, though
<refpga>
but that would kill the efficiency for storing a chessboard in 64 bits (say) because it wouldn't be stored in a 64 bit word.
<refpga>
Oh
<White_Flame>
you can also use 64-bit bit vectors, depending on your usage
<refpga>
I mean, in a quadword.
<refpga>
I'm using that. But I was thinking of shifting to bitboards later.
<aeth>
refpga: My bitboard is a (simple-array (unsigned-byte 64) (12))
<aeth>
You just have to be careful to never have one leave as a return value, in which case it will be allocated
<aeth>
SBCL is very good at catching these sorts of things with e.g. (optimize (speed 3))
<aeth>
s/one/one of the ub64s/
<White_Flame>
of course, you have to know that effeciency will be an actual issue before getting into stuff like that
<aeth>
White_Flame: in chess stuff, generally it is
<refpga>
Thanks, I'll take care.
<aeth>
White_Flame: Chess is a solved problem, so the main thing is doing it fast
bbbobbb has joined #lisp
<White_Flame>
or using it to learn a language ;)
<refpga>
I don't think all chess problems are solved problems.
<aeth>
well, obviously you can innovate on techniques, but generally you're using established ones
<refpga>
I don't think there's a program that can solve all classic Retrograde problems, like finding the missing piece in a monochromatic game, or the like.
<nirved>
aeth: is chess really solved? which one eventually wins - white or black? or is it a draw?
<aeth>
s/Chess is a solved problem/A chess engine (i.e. chess AI) good enough to beat the best human chess players is a solved problem/
<aeth>
I should be more careful with language there
<refpga>
I did see a chess engine using bitboards in CL, but I didn't know returning them would be trouble.
<aeth>
The good thing about CL is that it will work everywhere, it just will be slow on optimizations that didn't bother with these optimizations
<aeth>
It's an edge issue. It only really matters in practice (on 64-bit implementations) for double-float, (unsigned-byte 64), and (signed-byte 64) and only when you need it to be very fast so it's understandable to not be aware of it.
<refpga>
I'm actually not concerned about performance, more about getting it to work, and learning the language.
<aeth>
s/slow on optimizations that didn't bother with these optimizations/slow on implementations that didn't bother with these optimizations/
<refpga>
Were there any significant chess AI programs written in Lisp?
iamFIREcracker has joined #lisp
<aeth>
If there were, it was probably before 1995
<refpga>
right. Were there any? I'd be surprised if there weren't, given the AI Lisp hype.
<aeth>
Probably, I'm sure someone here knows
<aeth>
And you're right that your priority should be to get it to work first and to make it look idiomatic to the language.
<refpga>
My game-tree depth will not exceed 10 at the moment, so it's not that important.
<refpga>
10 is perhaps an overstatement.
<aeth>
Unfortunately, I can't find a significant chess AI written in Lisp. Perhaps the performance wasn't there.
<aeth>
(Wikipedia doesn't give the languages most of the time)
<aeth>
oh it actually is in that particular Wikipedia article, it's not in most
iamFIREcracker has quit [Remote host closed the connection]
rumbler31 has joined #lisp
<aeth>
Of course, there are lots of modern Lisp chess engines that aren't significant. The ones I found don't use something like the optimize bitboard I just described so they're probably not competitive against other languages' chess engines.
<theemacsshibe>
I think I will quickly add some caching to my engine.
madmuppet006 has left #lisp ["ERC Version 5.3 (IRC client for Emacs)"]
<refpga>
aeth: Thanks.
<aeth>
The good news is, I think you could make something faster in SBCL. e.g. This project's bitboards are different bitvectors stored in globals instead of one array (or maybe struct) of (unsigned-byte 64)s
<aeth>
Obviously integers-as-bits and bitvectors are the two different ways to represent bit data structures, but for something small, the integers-as-bits should win
<theemacsshibe>
Currently I use a 8x8 simple-array of 8-bit encoded pieces in my engine
wxie has joined #lisp
<theemacsshibe>
Seems like the cache makes things a bit faster, it certainly caches my lousy openings for one
<aeth>
refpga: Be warned that parts of that file aren't idiomatic at least in modern style, e.g. it has lots of places with multiple consecutive SETFs
<aeth>
You can just (setf foo 42 bar 43) and when you use multiple lines that's just as readable as (setf foo 42) (setf bar 43)
<mfiano>
That is perfectly acceptable and helps debugging.
<aeth>
Well, you're not going to get universal agreement on style
<refpga>
Thanks anyway.
<aeth>
what stands out more is blank lines inside functions, especially after some LETs
<aeth>
I haven't seen that style before
<refpga>
newline after let*, but not after do*?
<theemacsshibe>
It seems my engine does not scale awfully well to 12 threads, either.
<aeth>
Ignoring some style I haven't seen before, that page is by far the most serious attempt I've encountered
<theemacsshibe>
At least I have literal chess board reader syntax.
<aeth>
theemacsshibe: I don't think I found your program in my search. Is it available somewhere yet?
<theemacsshibe>
No, it's not done yet, since it needs a lot of refactoring and it's not viable, being a very naive minimax implementation.
<aeth>
ah
<theemacsshibe>
Also, it does not play standard chess, it only plays the context-free parts (so no castling, en passant, etc)
<aeth>
yeah, those are tricky
<theemacsshibe>
Additionally, the cache appears to be useless as I cannot use (steps . board) as a key in an equalp hash-table.
<aeth>
I need to finish my CL chess GUI at some point. At the moment, it would only be able to run a CL chess engine as a separate process, communicating via UCI.
<theemacsshibe>
sxhash to the rescue then...
<aeth>
UCI isn't particularly friendly to chess GUIs because it's written assuming a heavyweight chess GUI that e.g. calls draws, checkmates, etc., so I have to add a lot of chess logic that's probably duplicated in a chess engine to complete the GUI
<theemacsshibe>
What the hell? Somehow I've made minimax almost instantaneous?
<aeth>
theemacsshibe: couldn't you turn (steps . board) into an integer fairly easily?
<theemacsshibe>
Yes, I used sxhash to do that.
<aeth>
Just combine steps and board-id or something, ASHing over steps so you can put them in one, concatenated integer.
<theemacsshibe>
Yeah, that could work, there are probably more than 2^64 chess boards too.
<aeth>
oh the board state, you mean
<aeth>
there's a lot
<aeth>
most invalid, like a board of 64 queens
<theemacsshibe>
Hmm...I'm not sure what sourcery I've found but somehow I've turned a 3-second process into "0.000 seconds of real time".
<theemacsshibe>
The speedup should be only around 11x at best from my profiling of cache hits/misses
<aeth>
theemacsshibe: disassemble to see if it's even doing anything?
<theemacsshibe>
No, I think my cache implementation is returning false positives.
<refpga>
aeth: Is your chess engine available on the internet?
<aeth>
refpga: I didn't write a chess engine, I wrote a(n incomplete) chess GUI as a test of my (incomplete) game engine's (incomplete) graphical capabilities
<aeth>
very incomplete because nearly all of the work was in the UCI parsing so I could use existing chess engines to play against each other, in particular stockfish. https://gitlab.com/mbabich/cl-chess/blob/master/uci.lisp
<aeth>
I use my own macro over defun (define-function) in a lot of this sort of code so it's probably not good code to learn CL from. It's also very incomplete.
<theemacsshibe>
Er, am I the only one having 2-factor authentication problems on gitlab.common-lisp.net?
<refpga>
aeth: Can't find Zombie Raptor game engine in your personal projects.
<aeth>
I haven't come up with a good API for mouse click handling yet, so that's why the chess GUI is just two chess engines playing each other at the moment
<aeth>
(mouse motion and keyboard input are handled, though)
<theemacsshibe>
Yes, I have a literal chess board reader macro.
<aeth>
You should probably have your reader macro behave like #() so it fits better with CL-oriented tools
<theemacsshibe>
Probably, yeah.
<aeth>
e.g. #h(...) instead of {...
<aeth>
h for cHess since #c is taken. Don't use it, though. I'm sure people use it for literal hash tables already
<theemacsshibe>
Well, I suppose I will write my own quick hashing algorithm for chess boards.
<pjb>
ok, let's consider a board with 32 black queens and 32 white queens, placed each on a square of its own color. White starts. Can we end the game with a single queen?
<aeth>
theemacsshibe: there probably already is one
<theemacsshibe>
Hmm, there is Zobrist hashing.
<theemacsshibe>
So, it seems we just create a random 64-bit integer for each possible (individual) piece and position and XOR them together.
moldybits has quit [Quit: WeeChat 2.4]
<aeth>
it just occurs to me that I could just select the pieces with the keyboard, no need to design the mouseclick API yet to have a more complete GUI test.
ebrasca has joined #lisp
shifty has joined #lisp
<theemacsshibe>
there, i made the hashing actually work, and i have a more modest 3x speedup as opposed to (a metric fuckton)x
moldybits has joined #lisp
<theemacsshibe>
and there's a 5:6 cache hit:miss ratio which is understandable
<theemacsshibe>
but well, that's going back to the "i might fix it this year" list, since i have more interesting and less explored projects to do
theemacsshibe has quit [Quit: pjb didn't post hog ):]
<flip214>
pjb: on that board, you can't even move - there's no free space ;)
scymtym has joined #lisp
<TMA>
flip214: you can capture quite easily, though
<aeth>
now replace the queens with bishops of the same color
t58 has joined #lisp
<White_Flame>
what's the fastest way to do fixnum/fixnum division in sbcl, ignoring remainder?
<White_Flame>
integer division
<flip214>
(floor (the fixnum ...) (the fixnum ...)), would be my first guess
rumbler31 has joined #lisp
<White_Flame>
yeah, tried various variations of that. they end up with a page of asm code, and often wtih calls to generic math functions
<White_Flame>
even wrapping that result in (the fixnum ...) is still 119 bytes of code
rippa has quit [Ping timeout: 250 seconds]
<flip214>
well, declaring types and my DIV inline makes sbcl give me a IDIV on x86-64, as expected...
rumbler31 has quit [Ping timeout: 246 seconds]
<flip214>
how about a paste?
<mfiano>
(lambda (x y) (declare (optimize speed (safety 0))) (the fixnum (* (the fixnum x) (/ (the fixnum y))))) ;; => 55 bytes
<White_Flame>
I don't know enough about x64 to know what the shift & test on RDX is doing, to jump forward into more test-heavy code: https://pastebin.com/PcWADjSk
<White_Flame>
mfiano: and that still calls two-arg-/ ?
<mfiano>
yep
<White_Flame>
at some point, just flipping to float & back might end up shorter & faster :-P
<Inline>
wth
<aeth>
White_Flame: integer division is just (floor x y) isn't it?
<aeth>
(or truncate etc)
<Inline>
what does (/ (the fixnum y)) do ?
<White_Flame>
reciprocl
<Inline>
or is that a typo ?
<White_Flame>
reciprocal
<Inline>
eh ?
<Inline>
of what ?
<White_Flame>
aeth: yes, but taht's not very fast
<nirved>
(/ (the fixnum y)) = (/ 1 (the fixnum y))
<White_Flame>
Inline: of the parameter
<pjb>
flip214: it is rather easy to enter a pat.
<Inline>
oh ok
Essadon has joined #lisp
Essadon has quit [Max SendQ exceeded]
<Inline>
i thought it would take nil or 0 as a default second parameter and give you div error instead...
<aeth>
White_Flame: Weird, I would have expected this to be more efficient than it is. Apparently there's some point where it thinks there might be a bignum. (defun foo (x y) (declare (fixnum x y)) (values (truncate x y)))
Essadon has joined #lisp
<aeth>
ah, there's one value that makes it complicated. (truncate most-negative-fixnum -1) ; that's (1+ most-positive-fixnum)
<White_Flame>
clever girl
patlv has joined #lisp
<aeth>
White_Flame: if you can change the range, this is probably the most efficient (40 bytes, with a division by zero check). (defun foo (x y) (declare ((integer #.(1+ most-negative-fixnum) #.most-positive-fixnum) x y)) (values (truncate x y))) (disassemble #'foo)
<aeth>
floor semantics are 71 bytes.
<aeth>
at least in the SBCL I'm using
<White_Flame>
wow, nice. thx
<White_Flame>
30 bytes in mine
<aeth>
you probably want to deftype rather than use messy #. hacks
<White_Flame>
I'll just wrap it all in a macro
<mfiano>
43 without the divide by zero check: (lambda (x y) (declare (optimize speed (safety 0) (debug 0))) (the fixnum (truncate x y)))
borodust has quit [Quit: Leavin']
zigpaw has quit [Remote host closed the connection]
orivej has joined #lisp
<mfiano>
White_Flame: 29 bytes without divide by zero check is the best i have the time for: (lambda (x y) (declare (optimize speed (safety 0) (debug 0))) (the fixnum (values (truncate x y))))
<White_Flame>
mfiano: that still makes a general call though
<mfiano>
not here it doesnt
<White_Flame>
which version of sbcl?
<aeth>
mfiano: what happens when x is most-negative-fixnum and y is -1 in that lambda?
<mfiano>
1.5.1
<White_Flame>
hmm, I'm still on 1.4.7 it seems
<White_Flame>
(oh, I updated my workstation, not my laptop)
<mfiano>
aeth: (1+ most-positive-fixnum)
borodust has joined #lisp
iamFIREcracker has quit [Remote host closed the connection]
vlatkoB_ has joined #lisp
vlatkoB has quit [Ping timeout: 268 seconds]
<White_Flame>
I updated to 1.5.1, and get 29 bytes but still with a call to fdefn truncate
<White_Flame>
looks like some peephole or value dependencies got more optimized
<White_Flame>
26 bytes with aeth's version, but 4 of them are the division-by-zero handler
elderK has joined #lisp
<aeth>
#sbcl might be helpful
<White_Flame>
I'm actaully good with this
iamFIREcracker has joined #lisp
<White_Flame>
without the prologue & epilogue stuff, the slightly-less-than-fixnum is basically as small as it'll get with tag bits
<White_Flame>
*version
<White_Flame>
and like good fixnums, it doesn't even have to be preshifted back to tagless for the idiv, since they have a common multiple shifted in :)
<vms14>
solved the problem to parse input and have a list of atoms
<vms14>
instead of strings
<vms14>
just used readline and with-input-from-string
<vms14>
I should use colllect instead of push or append instead of reverse, but meh
<beach>
vms14: You really should indent your code properly.
<vms14>
it works so now I can start doing stuff
<vms14>
beach: I thought it was how lispers wanted xD
<beach>
with line 2 in the leftmost column?
<beach>
With the LET body to the right of the bindings?
<beach>
with (let indented 8 positions?
<vms14>
I don't know how to perform lisper identation
<vms14>
usually my identeation is worse
<beach>
Just use slime-indentation.
<vms14>
I'm using vi
<beach>
And here is the result.
<vms14>
the nvi it comes with netbsd
<vms14>
it can match parens
<vms14>
:set sm
patlv has quit [Ping timeout: 246 seconds]
<beach>
Why are you using an editor that is incapable of helping you with indentation?
<MichaelRaskin>
Because it actually helps with editing!
<beach>
Common Lisp programmers understand code by how it is indented, not by counting parentheses.
<vms14>
I wanted to learn vi only because I knew it's part of posix standard, so once you know vi, you'll be able to use it whenever a posix system is
<beach>
MichaelRaskin: Using and enditor that is incapable of helping with indentation actually helps with editing?
<beach>
MichaelRaskin: I failt to see that.
<vms14>
but with the time I got used to vi and now it's hard to write without vi commands
<MichaelRaskin>
I dunno, vi definition of indentation is consistent enough for me _across_ languages
nanoz has joined #lisp
<vms14>
tried evil mode in slime but failed to install due to a dependence named undo-tree which gives you unlimited undo
<vms14>
emacs*
<MichaelRaskin>
For the operations I actually perform, vi bindings are very good. Again, across languages.
<beach>
vms14: You can do what you want of course, but if you submit code for others to read, make sure it is correctly indented, and make sure it is done automatically. If you indent manually, you will get it wrong and potentially hide bugs in your code.
<beach>
MichaelRaskin: Oh, come on. I have seen some of your badly indented code.
iamFIREcracker has quit [Ping timeout: 268 seconds]
<beach>
MichaelRaskin: But if you are convinced that it is able to do Common Lisp correctly, perhaps you should teach vms14 how to do it.
<MichaelRaskin>
My definition of correctly is what allows to switch between Lisp, Nix, Pascal, C, Pytohng, Julia, TeX with minimal impedance mismatch
<vms14>
it does not follow conventions, but I think is readable
<vms14>
ofc for lispers won't be readable as lisper identation
<beach>
vms14: Like I said, you can do what you want of course, but if you submit your code for others (other Common Lisp programmers I mean) to read, it is very impolite not to respect widely agreed-upon conventions.
<Grue`>
to me it looks like something that a COBOL programmer would format their code like
<vms14>
hmm It's too soon for me to submit anything, but I guess it could be a good exercise to write a lisper formatter program with lisp
lumm has quit [Ping timeout: 252 seconds]
lumm_ is now known as lumm
<Grue`>
it's readable, but solely because it never goes deeper than one level of indentation
<Grue`>
and typical lisp code goes pretty deep
okeg has joined #lisp
lnostdal has joined #lisp
refpga has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
vms14 has quit [Quit: WeeChat 2.3]
nanoz has quit [Read error: Connection reset by peer]
scymtym has quit [Ping timeout: 240 seconds]
lumm has quit [Quit: lumm]
lumm has joined #lisp
warweasle has joined #lisp
lnostdal has quit [Remote host closed the connection]
<pfdietz>
Various reader macros for getting around that (as in Clojure), but it's a different style
patlv has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
kajo has joined #lisp
rumbler31 has joined #lisp
rumbler31 has quit [Ping timeout: 252 seconds]
bonmlp has quit [Ping timeout: 246 seconds]
lumm has quit [Ping timeout: 240 seconds]
Jesin has quit [Quit: Leaving]
lnostdal has joined #lisp
okeg has quit [Quit: WeeChat 1.6]
Kundry_Wag has joined #lisp
zigpaw has joined #lisp
patlv has quit [Ping timeout: 264 seconds]
ym555 has joined #lisp
smasta has joined #lisp
karlosz has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
rumbler31 has joined #lisp
gravicappa has quit [Ping timeout: 255 seconds]
Jesin has joined #lisp
bbbobbb has quit [Remote host closed the connection]
lumm has joined #lisp
patlv has joined #lisp
saturn2 has joined #lisp
patlv has quit [Ping timeout: 250 seconds]
ebrasca has quit [Remote host closed the connection]
lumm_ has joined #lisp
patlv has joined #lisp
lumm has quit [Ping timeout: 252 seconds]
lumm_ is now known as lumm
bbbobbb has joined #lisp
cyberoctopi has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
sdumi has joined #lisp
<aeth>
Common Lisp superficial style (like variables and indentation) is considerably more consistent tham most languages, where you might be able to choose tabs/spaces, how many spaces, camelCase vs. underscore_case, etc. This is probably because the actual details can be considerably different in style (with multiple paradigms, macros, reader macros, etc.) so it helps to have the rest look the same.
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
smasta has quit [Ping timeout: 264 seconds]
<aeth>
In C, you're going to see the same limited idioms over and over so you adjust to things like different indentation much faster imo (but two spaces is the superior indentation everywhere where you have a line length limit)
lumm has quit [Quit: lumm]
rumbler31 has quit [Remote host closed the connection]
marusich has joined #lisp
smasta has joined #lisp
lumm has joined #lisp
smasta has quit [Ping timeout: 264 seconds]
lumm has quit [Remote host closed the connection]
sdumi has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
sdumi has joined #lisp
random-nick has joined #lisp
cyberoctopi has quit [Ping timeout: 252 seconds]
cyberoctopi has joined #lisp
smasta has joined #lisp
shka_ has quit [Ping timeout: 240 seconds]
Kundry_Wag has quit [Ping timeout: 246 seconds]
smasta has quit [Ping timeout: 252 seconds]
patlv has quit [Ping timeout: 246 seconds]
andrei-n has quit [Read error: Connection reset by peer]
smasta has joined #lisp
smasta has quit [Ping timeout: 240 seconds]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
igemnace has quit [Quit: WeeChat 2.4]
smasta has joined #lisp
<moldybits>
hyphenated variable names would probably be standard in other languages as well, if they allowed them. in lisp you have less things to play around with, but more of it (lots of parens). it's much harder to understand poorly indented lisp than something like C, in my experience. one line lisp vs one line C, for example ...
Kundry_Wag has joined #lisp
smasta has quit [Ping timeout: 268 seconds]
rumbler31 has joined #lisp
<pjb>
moldybits: only, it's not 1 line lisp ~ 1 line C, but rather 1 line lisp ~ 30 line C.
libertyprime has joined #lisp
<moldybits>
i meant where you fold everything into one line, like on irc. it's harder to see what goes where in the lisp case
<pjb>
oh, possibly yes.
<pjb>
But then, since you use erc in emacs, it's no pain to re-indent the irc messages.
ggole has quit [Quit: Leaving]
<moldybits>
is there a good c to sexp parser? or a good c parser in cl, period?
<pjb>
Not yet. I intend to work on one.
refpga has quit [Remote host closed the connection]
<pjb>
In the meantime, you may try to use libclang.
<aeth>
moldybits: you can get kebab-case in other languages without full s-expressions as long as you require spaces around tokens, so x+y would be invalid and you'd have to write x + y. I'm surprised people like slightly easier to write (and harder to read) basic arithmetic so much that they give up easier to write and easier to read variable names, when most programs are the latter.
Jesin has quit [Quit: Leaving]
<aeth>
Universal good style puts spaces around everything anyway, except for pointer syntax in C.
PuercoPop has left #lisp ["Killed buffer"]
<aeth>
(around tokens with a few exceptions, like parentheses, of course)
<pjb>
What is kebab-case?
<aeth>
pjb: that's the lisp-style-with-hyphens
<aeth>
and we can use it because almost everything requires a space separator if on the same line
<moldybits>
never heard that term, heh
<aeth>
I've never heard it described any other way. Too bad underscore doesn't really have a fun name that I know of
Jesin has joined #lisp
<aeth>
moldybits: By the way, I'm considering writing a simple C compiler to CFFI data structures just to see if it can be done. It sounds fun. Unfortunately, I haven't started yet.
<pjb>
aeth: my style is no superfluous space. Which is why I hate swift!
<moldybits>
well, get started!! :D
<TMA>
aeth: 'tis call'd snake_case y'know
<aeth>
TMA: ah
<pjb>
if(a!=0){ } in swift doesn't mean what you think!
<pjb>
you have to write if(a != 0){} or if(!(a==0)){ }
<pjb>
beuark!
sdumi has quit [Quit: Quit]
<aeth>
pjb: fortunately in CL we enforce (if (not (= a 0)) ...) with spaces (and with the NOT very explicit)
<moldybits>
+ = + - * is harder to understand and parse than (setf + (- + *)), i think
libertyprime has quit [Ping timeout: 252 seconds]
<aeth>
moldybits: Imo, these languages usually win on simple mutation, especially with arrays. e.g. a[42] = 1f vs. (setf (aref a 42) 1f0) and it would get worse for stuff like *= where you'd have to define-modify-macro first.
<TMA>
pjb: in haskell, you can probably dispense with spaces altogether: a b c can be written as ((a)b)c, unless of course the things are not alphanumeric, in which case it gets hairier
<aeth>
moldybits: Lisp wins for more complicated things, like multi-dimensional arrays. The slightly inconvenient syntax also encourages more abstractions for this sort of thing
<pjb>
(setf + 0) is simplier.
<moldybits>
i feel that lisp encourages me to use longer names. they're really annoying in a language like C but in lisp it looks nice.
<aeth>
Of course, using "=" for something other than equality is imo a bad move. You have to be a programmer to know that "a[42] = 1f" isn't an algebra problem you can solve, and that "x = x + y" isn't "y = 0"
<aeth>
setf is conceptually simpler
<moldybits>
i think lisp could use some better use of syntax highlighting. for example, why aren't macros colored differently, by default?
libertyprime has joined #lisp
<aeth>
Currently, GNU Emacs syntax highlights certain types of advanced macros like defun, as well as things it can catch in a regexp like define-foo and with-bar
<aeth>
Yes, it might just be more consistent to highlight all macros that color
<aeth>
At least, when SLIME is enabled
<pjb>
Try it! Type: (if(not(= a 0))foo)
smasta has joined #lisp
<pjb>
paredit inserts the spaces, not you.
<aeth>
pjb: there's also the other side of bad style: ( if ( not ...
<moldybits>
yuck!
<aeth>
So, yes, CL is not as strict as it could be. Perhaps some compilers could make those sorts of things style-warnings, though
wusticality has joined #lisp
cyberoctopi has quit [Ping timeout: 245 seconds]
cyberoctopi has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
lnostdal has quit [Excess Flood]
random-nick has quit [Ping timeout: 250 seconds]
elem6 has joined #lisp
elem6 has left #lisp [#lisp]
marusich has quit [Remote host closed the connection]
patlv has joined #lisp
cyberoctopi has quit [Ping timeout: 252 seconds]
patlv has quit [Ping timeout: 264 seconds]
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
cyberoctopi has joined #lisp
Kundry_Wag has quit [Ping timeout: 264 seconds]
libertyprime has quit [Ping timeout: 250 seconds]
libertyprime has joined #lisp
akoana has joined #lisp
moei has quit [Quit: Leaving...]
wxie has joined #lisp
karlosz has quit [Quit: karlosz]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
torbo has quit [Remote host closed the connection]
smasta has quit [Ping timeout: 250 seconds]
smasta has joined #lisp
ebrasca has joined #lisp
t58 has quit [Quit: Leaving]
atgreen_ has joined #lisp
karlosz has joined #lisp
karlosz has quit [Client Quit]
ltriant has joined #lisp
wxie has quit [Ping timeout: 268 seconds]
bbbobbb has quit [Ping timeout: 264 seconds]
patlv has joined #lisp
wxie has joined #lisp
dddddd has quit [Read error: Connection reset by peer]
igemnace has joined #lisp
wxie has quit [Ping timeout: 264 seconds]
dale has joined #lisp
akoana has left #lisp ["Leaving"]
atgreen_ has quit [Remote host closed the connection]