freenode/#lisp - IRC Chatlog
Search
20:23:56
verisimilitude
I prefer to separate it between what I call ``historical time'', which is measuring time based on regular occurences such as the rotation of the Earth, including leap seconds and all of that crap, and then have just ``time'' for what should be an objective measurement of seconds.
20:24:48
verisimilitude
Base sixty has some nice factors, though, so if we ever reach Star Trek levels of time management, I'd think just extending sixty seconds, sixty minutes, further would be best.
20:26:27
verisimilitude
If you get 60^3, that's just under three days; 60^4 is 150 days; 60^5 is 9,000 days; it works rather nicely, actually.
20:35:49
verisimilitude
That 60^5 unit splits a human life rather well; you'd only live three or four of them, if that.
20:40:02
verisimilitude
It disgusts me that figuring how many seconds old I am, to any reasonable accuracy, requires searching through historical records to see when the idiots decided to add leap seconds here and there and other nonsense.
20:41:16
verisimilitude
If you wanted to create a program that actually traverses the history of the world, as a knowledge base, you'd need to see when a week was subtracted there, and so on and so forth and it's hideously complicated.
20:48:46
pjb
verisimilitude: not counting the international flights you made, which means your proper time got desynchronized with that of Earth!
20:49:48
verisimilitude
I didn't even think of that, though, although probably because I didn't need to.
20:51:56
verisimilitude
See, hideously complicated. I'm usually against changing things just because programming in relation to them is difficult, but time is a mess every which way.
20:54:38
pjb
(let ((my-birth-date '(00 30 18 15 03 1964))) (- (get-universal-time) (apply (function encode-universal-time) my-birth-date))) #| --> 1732073075 |#
20:59:33
aeth
verisimilitude: Base 12 has most of the advantages. Base 60 is just 12*5 for some compatibility with our base 10 (2 * 5) world. The advantages of divisibility (12 items can be divided evenly many ways, while 10 can only be divided evenly into 2*5 or 5*2) are probably not that good now that we live in a digital world. Base 16 would be the way to go IMO.
21:00:36
jackdaniel
luckily for us software is made for real world issues, not for programmers convenience. I doubt computers would be so popular otherwise
21:00:38
aeth
If we had to have a from-scratch number system it would either be base 12 for better dividing, or base 16 (or base 8) for better digital compatibility, though.
21:03:21
verisimilitude
I took the first three primes, two, three, and five, and multiplied them; then you can easily work in halves or thirds or fifths.
21:03:36
verisimilitude
This is also reasonable for a person to learn, since it's still comparable to a normal alphabet.
21:04:21
aeth
30 = 2 * 3 * 5; 12 = 2 * 2 * 3; 8 = 2 * 2 * 2. If you just care about splitting things up, 8 or 12 are simpler because they're smaller. No one would care about fifths if we didn't have base 10
21:05:05
aeth
12 gives you 4ths which are arguably more important than 5ths. You get halves, thirds, and fourths with 12, you only get halves, thirds, and fifths with 30
21:05:36
aeth
60 gives you the most desirable splitting, but it's too large for humans to normally work with as digits
21:05:46
verisimilitude
Really, I'd say base sixty, but that seems unreasonable for a person to learn and may get cluttered with easily confused symbols.
21:07:33
aeth
Oh, and I said 60 doesn't give you 8 but half a minute is a nice, neat division so you can still divide your hour (or other time unit) up into 8
21:07:42
verisimilitude
A base that's a power of two isn't good for thirds, which I'd think is too much to give up.
21:08:44
aeth
The advantage of using octal or hexadecimal is that all of the counterintuitive properties of floating point go away, and the world is increasingly a binary floating point world, with no sign of mainstream decimal floating point support in sight.
21:08:50
verisimilitude
Ultimately, I think it should become a common skill for people to work in many number bases; people are mostly just accustomed to ten and only sixty for time.
21:09:16
aeth
Using a base 2 number system, floating point is (afaik) basically just scientific notation with truncation or rounding in places.
21:11:06
aeth
If my mind was ever uploaded into a computer, and I'm probably born too early for that, I suspect hexadecimal would be more natural to use, at least if my mind got augmented by the technology instead of merely being replicated.
21:11:14
verisimilitude
Let's segue into a Lisp topic; I'm disappointed with using BIT as a stream element type.
21:11:32
verisimilitude
SBCL just ignores every octet that isn't zero or one, which isn't the behavior I wanted.
21:11:41
aeth
verisimilitude: Technically speaking, we're just debating over which *print-base* and *read-base* to use so it's roughly on topic
21:13:32
verisimilitude
So, instead, I'm forced to use (UNSIGNED-BYTE 8) and manually pick it apart, which isn't fun because I'm implementing a format that isn't octet aligned.
21:14:14
verisimilitude
Then again, I could be lazy and wasteful and manually create the bit stream myself.
21:14:16
aeth
if it's not multiple-of-eight I'd expect pain points somewhere along the way no matter what
21:14:46
aeth
Might even be best just to be wasteful and pad it. If you're doing 12, just put 4 0s at the end.
21:16:39
pillton
versimilitude: According to the Handbook of Floating-Point Arithmetic, the Russian SETUN computer represented numbers in radix 3 which is good for floating point arithmetic.
21:17:51
pjb
Once again, only clisp is conforming here: integer 2 is out of range, cannot be output onto #<CLOSED OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 1) #P"/tmp/bits">
21:19:19
aeth
verisimilitude: Space vs speed trade-off, it's probably worth it on modern machines to be faster. If you intend to save it to disk or send it over the network, you also can use those bits to ensure that the data is still valid.
21:23:04
pjb
(with-open-file (bits "/tmp/bits" :element-type (quote bit) :direction :output :if-does-not-exist :create :if-exists :supersede) (write-sequence #(1 0 2 0 1 0 1 0) bits))
21:23:48
aeth
Built in github/gitlab/etc. pastebins are underused, but they're probably the most reliable
21:24:01
pjb
(with-open-file (bits "/tmp/bits" :element-type (quote bit) :direction :input) (let ((v (make-array 8 :element-type 'bit))) (read-sequence v bits) v)) #| --> #*10101010 |#
21:25:01
pjb
I don't know at sbcl. I would expect bit by bit. which is what clisp does, apart from a header used to complement the octet file size.
21:26:14
verisimilitude
To repeat, SBCL has a nasty habit of simply ignoring any octects that aren't zero or one, in this case. I'm stuck working around (UNSIGNED-BYTE 8), unfortunately.
21:29:17
pjb
verisimilitude: yes, it's crazy, abcl, ccl ecl and sbcl write one byte per bit! I strongly advise you to use clisp.
21:29:54
verisimilitude
I have CLISP installed, but I'd prefer it work on most anything and (UNSIGNED-BYTE 8) is the LCD for this.
21:30:26
verisimilitude
If there were ever an update to the Common Lisp standard, this is just one of the things I'd like to see, proper bit writing and all of that.
21:31:25
pjb
verisimilitude: note that the difficulty here, is when the file size metadata is not specified in bits, but in bytes (which can be different from octet by the way).
21:32:03
pjb
verisimilitude: clisp has to add a header to store the actuall bit size differential, since it cannot count on being able to save an additional metadata.
21:32:17
aeth
pjb: In practice, a byte is an octet and a word is a nonnegative integer multiple of an octet. These are assumptions that essentially all future hardware will make (but some historical systems might not have made)
21:33:08
pjb
aeth: and also in practice permanent storage is not always done on hard disk using octets.
21:35:50
verisimilitude
Nevermind, I suppose. Anyway, what is that ninth bit usually used for, pjb? I'm not familiar with tape much.
21:36:31
pjb
verisimilitude: yes, probably parity. On the other hand, punched cards had 12-bit bytes.
21:37:01
pjb
verisimilitude: otherwise, you must learn about abstraction. This would restore your aesthetic sensibilities.
21:38:50
pjb
Yes, but you could have subfunctions, to decode the bytes into bits. and instead of collecting a list of them you could store them to a bit-vector.
21:43:21
verisimilitude
The most convenient way is to rewrite it in Common Lisp as much as is possible.
21:44:06
no-defun-allowed
I don't consider eating more memory than Emacs a good sign for a UI toolkit, nor does using JavaScript make it more palatable.
21:49:33
aeth
CLIM is high level. e.g. If I wrote a basic GUI system in OpenGL+SDL2, someone could write a CLIM backend for it.
21:50:23
jackdaniel
McCLIM works just fine. it is true that the only practical backend right now is clx.
21:51:05
jackdaniel
fact that it is under active development and has bugs doesn't mean it is wip, it is already usable as it is
21:51:37
ym
High level is when I write (circle 10 20 30) - some magic happens and I see a circle I asked for. I can't call new standard "more high level" just because it's brand new and more robust.
21:52:04
jackdaniel
as of: why use McCLIM over CLX: clx is just an event queue and drawing primitives, CLIM gives you object identity on the screen, display, application abstraction and much more
21:53:39
aeth
ym: CLIM is more high level in that someone could write a McCLIM backend or CLIM implementation on top of my GUI thing if I wrote a GUI thing. McCLIM-on-CLX, of course, being the only current example.
21:55:07
jackdaniel
not that they are acceptably fast, but mezzano is not a demon of speed itself (yet)
21:55:40
djeis[m]
In a sense the "context" is baked into the stream, so part of it is that you have to create a stream somehow. That's not difficult tho.
21:56:58
jackdaniel
no, I'm going to work on that *after* adding page support and alignment to clim-stream-panes
21:57:57
jackdaniel
but we have a good plan to make all that thread-safe, it is just matter of time and motivation
21:58:32
jackdaniel
ACTION hopes he did contribute to the discussion, now it is time to rest for him. \o
22:03:57
djeis[m]
As we mentioned, you don't in practice want to just be writing to some random window stream from any thread tho. It'll generally work, and eventually that'll all be safe, but with the current version of McClim sometimes that will break things. If you learn a little more clim you'll find it's fairly easy to make sure your code is running as part of the window's own rendering process, and even in current McClim that's always
22:06:50
djeis[m]
Could also spin up the clim-listener (repl) and do your drawing in a with-room-for-graphics block, which renders it right in the window of the repl.
22:07:38
djeis[m]
And afaik all code run at the actual listener can safely draw to the listener, that's part of its design.
22:25:48
ym
Ok, reading McCLIM documentation farther makes me understand why you all love it so much.
23:03:58
aeth
McCLIM had a legacy OpenGL backend a few years ago, but it was removed for being very legacy. Probably circa 2000 style OpenGL
23:04:57
aeth
Even then, it would probably be easier to work in layers, and have McCLIM target a layer on top of cl-opengl + cl-sdl2 that makes things look a bit more like what it would expect in a backend.
23:06:55
aeth
You would also need to think about what a window is. Do you want to literally create new SDL windows or do you want to create fake windows within the one fullscreen 3D application?
23:08:02
djeis[m]
It'd involve a decent bit of infrastructure, but I'd bet you could implement a frame manager that worked that way.
23:08:39
aeth
I expect that someone will write a minimal OpenGL-based GUI system and someone else will port McCLIM to it or write a CLIM implementation on top of it.
23:10:44
djeis[m]
It could be done, but it'd involve a lot of work if you actually wanted to take advantage of hardware acceleration.
23:11:12
djeis[m]
If all you care about is platform independence there's the CLDK backend, but I'm testing it atm and it seems to have bitrotten a smidge.
23:11:49
djeis[m]
Trouble with 3rd party libraries, they don't keep up. Was working just fine a few months ago, but McClim is a moving target for a backend I'd guess.
23:12:34
djeis[m]
I'm sure the symbol's it's looking for still exist somewhere, they're just not in the package where it's looking for them.
23:13:18
aeth
ebrasca: I'm guessing that CEPL doesn't have enough of what a McCLIM backend expects. For anything designed for a 3D application, you would essentially have to write a fake window system for it, where you can create 'windows' within the graphical application, move them around, etc.
23:14:46
djeis[m]
Yea, there'd be a lot of infrastructure between CEPL and McClim to actually make is useful as a backend.
23:17:47
aeth
djeis[m]: I would personally leave text rendering to the lower level, especially if it's text rendering in a 3D application.
23:19:05
djeis[m]
I mean, sure, definitely could do that. I think it'd require you to implement a lot more of the CLIM drawing primitives in terms of GL instead of relying on CLIM's own software renderer tho.
23:20:24
aeth
ebrasca: 3D applications work differently than most. You want OpenGL and a gaming-oriented input/window portability library like SDL2 (there are probably close to a dozen options, but SDL2 is the most popular). You also want to do everything within one large, probably fullscreen, window, reinventing window management (you probably don't want your game or CAD or 3D modeller to actually have new, separate windows, just fake 'windows' within t
23:20:58
aeth
So to CLIM-on-GL a 'window' would really just be a rectangle that can move around within the real OS window.
23:21:36
aeth
The efficient and desirable way to render text is probably going to be different than the mainstream way, too.
23:22:46
aeth
So something like CEPL would be several layers underneath CLIM since you would target the fake window system on top of a framework on top of cl-opengl+cl-sdl2
23:26:54
aeth
ebrasca: VR is hard to do in a language like Common Lisp because it requires a much higher framerate. Probably above 100 frames per second (which means every action needs to be done in less than 0.01 seconds, including garbage collection pauses!)
23:27:42
aeth
It also requires a very high resolution. Today's VR headsets don't really have a good enough resolution. 4k is probably good enough for a TV viewing distance. A monitor, closer to your face, probably could use 8k. VR probably could use 16k or above. The closer it is to your face, the more pixels you need to avoid seeing pixels.
23:28:06
no-defun-allowed
VR also requires significant investment in hardware off the bat in cee, too.
23:30:54
aeth
ebrasca: Virtual Reality is real time programming. Instead of thinking in terms of batches, you think in terms of actions done in a time interval. Instead of running foo in 1.4 seconds, you run tiny little pieces pieces of foo in 0.0005 seconds and need to leave room for every other tiny little piece that needs to be done that tick of time.
23:31:54
ebrasca
ACTION don't know what to make cl-vulkan triangle , btrfs/etx4/cache for mezzano ...
23:32:15
aeth
Unlike regular game programming you have three issues: (1) the ideal resolution is higher, (2) the ideal framerate is higher (the time to do things is 1/fps, so that means the time to do things, at least related to rendering, is smaller), and (3) missing a frame (by taking too long somewhere) is more problematic because you might make your user ill
23:34:35
aeth
pjb: Assuming you're correct (and you're not quite correct here) that game was in 30 FPS. (/ 30d0) => 0.03333...d0 so You had that much time to do your computations. (It probably did everything in the same framerate without logic independent of rendering.) For VR you're probably thinking in terms of at least (/ 90d0) => 0.01111...d0
23:36:01
aeth
Of course, modern games (should) do logic independently of the rendering framerate so your logic could e.g. be a constant 0.01 s even when you have 90 FPS or 144 FPS at the display, but there are some things that would have to run with the graphical tick even if your logic tick is every 10 FPS or so.
23:36:18
pjb
It can be as CL as you want it to be. The point is that you use CL to metaprogram and make your system generate the binary you need.
23:37:12
no-defun-allowed
Also, https://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html
23:37:56
aeth
pjb: It's funny how you think that I'm ignorant of the topic, though. I'm writing the only Common Lisp game engine that focuses on high performance, high frame rate, and real time over convenience. So when I'm complete it will be the most likely to be usable on actual VR systems without first porting a RTGC to a CL implementation.
23:39:11
aeth
My provided part of the game loop is nonconsing which means the GC will only run when the user wants it to if that's a concern of the user. (Or the user can cons, which could trigger the GC at unexpected times, and it's up to the user, not the framework or engine, where to be on convenience vs. dependable performance.)
23:49:07
aeth
Although it's not really about being usable on $foo it's about how much you can safely do on $foo to stay within the time limitations
0:08:00
aeth
Not a lot of progress lately because it's a very big, fragile thing even though I've tried my hardest to be modular. The nature of the problem is kind of anti-modular. Takes a while to be able to dive into the code.
0:12:42
aeth
ebrasca: CEPL is an interactive graphics framework, Zombie Raptor is a game engine. So they both work on top of cl-opengl and probably both on top of cl-sdl2 (not sure about CEPL), but the abstractions are different. CEPL assumes you're in something like SLIME and wanting to edit graphics interactively. ZR assumes you're creating a game that's run by instantiating the game object with #'make-game
0:13:53
aeth
ZR doesn't do as many things 'live' (i.e. change the code and see the result immediately), but it probably could add some more of that by adding periodic checking for change (like once a second) or by having F5 see if shaders need to be reloaded, etc.
0:16:45
aeth
Jachy: Although I guess that's not quite true. I do have a chess GUI, as in, the user interface of a chess program... a chess engine is the AI part, and I use UCI for that, defaulting to running the "stockfish" command, but it should run any stockfish-like UCI-using chess engine. At the moment it's just AI vs AI because I haven't finalized the click-recognizing API.
0:17:28
aeth
Fun fact: my engine is entirely 3D, but that chess program is currently entirely 2D (using the free chess graphics from Wikipedia). The chess board is actually rendered on the 2D HUD.
0:18:28
pjb
It would be nice to make it 4D so that time is taken into account and movement in the 3D space be possible…
0:18:38
aeth
cl-chess doesn't do complete AI vs AI games yet. I need to be able to recognize checkmate and draws (mostly draws when the AI plays itself). My checkmate code was broken in edge cases so iirc I removed it.
0:21:18
Jachy
Can objects in the HUD have different z-orders, or is it mostly dependent on draw order?
0:21:38
aeth
Jachy: I suspect at the moment if you put two objects on top of each other you're going to get z-fighting.
0:22:00
aeth
Everything is very basic at the moment because you kind of have to do everything 70% of the way in order to get anything that's usable.
0:23:03
aeth
At the moment instead of moving chess piece sprites on top of a board sprite, I use 64 piece-on-board sprites (or blank) for the correct background color
0:27:12
aeth
Well, I don't really promote this engine because it's not really usable at the moment because I can and do break things dramatically. I even got some memory errors a while back in my older test programs when I revisted them because I switched to static-vectors and so it was trying to free CL arrays (there's no way to tell static-vectors arrays appart from CL arrays).
0:30:26
aeth
I had to switch to static-vectors for textures and 3D models to avoid copying from CL arrays to C arrays for use in OpenGL, which made my terrain test (not the one included in the engine, a different one) take several minutes to load instead of < 1 second.
1:08:54
nirved
verisimilitude: how would you write 9 bits to a file? AFAIK all fs are using bytes as smallest thing to write.
2:03:06
pjb
All FS I know are using blocks as the smallest thing they can write. Also, most random-access devices use sectors as the smallest thing they can write.
2:03:50
pjb
You will also observe that some FS will optimize reading and writing from hard disks by using the track or the cylinder as unit of read or write.
2:04:22
pjb
The idea of files as a sequence of bytes is a figment of the imagination of the POSIX standard.
2:05:45
pjb
Now, as for how one would write 9 bits to a file, well, basically what will occur ultimately, is that a sector is read from the hard disk and copied in a memory buffer, then you will modify 9 bits (or more) in that memory buffer, and then that memory buffer will be copied back to write a sector (possibly the same, often a new one).
2:06:37
pjb
Knowing that, how you use the POSIX file abstration to write 9 bits is rather irrelevant; several solutions are possible.
2:07:06
nirved
pjb: you can create an one byte file, so this is the smallest thing; internally there might be blocks, but this is not exposed
2:07:29
pjb
Or you can use the write and read (byte buffer) abstraction of POSIX, and spread the 9 bits over two bytes. Or 9 bytes as non-clisp implementations do.
2:09:28
pjb
nirved: notably, controller-less disk media (eg. Apple floppies), had just hardware to read the tracks as a sequence of bit. Mapping track bits to sectors of bytes was done by software.
2:32:19
nirved
pjb: files with element-type bit are really strange in clisp - there is a 4-byte file-length prefix at the beginning
2:33:52
no-defun-allowed
makes sense, you couldn't count bits just by file length without some information
2:35:04
aeth
Going back to both of the earlier topics of McCLIM and my game engine, I'm not going to be integrating McCLIM because that would go against my two goals of (1) leaving anything that could hurt performance to the user of the engine to do and (2) all-in-one binary distribution (my interpretation of McCLIM's LGPL license would mean that it should ship separately from a binary)...
2:35:15
aeth
...but what does it take to become a McCLIM backend? Because I suspect that there would be interest there.
2:37:47
pjb
With files with more than 1-bit bytes, you can reserve a header and update it to contain the total bit length header, or just the bit-offset in the last byte. Using just the bit-offset would be easier, since it takes only one byte to write.
2:38:32
aeth
pjb: re "The idea of files as a sequence of bytes is a figment of the imagination of the POSIX standard." it seems like it's more than just POSIX
2:39:44
aeth
Even in CL you see either bytes or characters, which are usually UTF-8 translated into the internal format (probably UTF-32) unless there's some configurable encoding support.
2:42:03
aeth
pjb: Well, yes, I'm aware that there's a lie there, I think that's why you have to 'safely remove' external hard drives.
2:42:53
pjb
and again, if you read above, I wouldn't have to repeat that to write a byte to a disk you have to first read a fucking whole sector!
2:44:23
pjb
There's also the case of networks. Both serial and Ethernet are bit-based transmission protocols (level 2).
2:45:29
aeth
pjb: And I don't think you mentioned solid state drives yet, which are afaik extremely elaborate internally.
2:47:36
pjb
Usual hardware UART let you configure the number of data bits and mark bits, and the presence of parity bit, but really, they just transmit bits. When you program a GPIO on raspberry you can send the bits yourself.
2:48:56
pjb
Actually, if POSIX specifies files as sequences of bytes, it's only because it's inspired from unix which was written in C. If it had been written in Lisp, we'd have variable length bytes just as in CL read-byte and write-byte.
2:51:43
pjb
I can't wait the singularity. We'll be able to ask the AI to evole a whole field such as computing, starting from different premices…
3:04:21
aeth
This is why it would be safer to augment human intelligence instead of developing superhuman artificial intelligence from scratch. You know humans will want to benefit humans (or at least themselves)
3:05:05
aeth
In a sense, tools like SLIME already do that, but things will really take off once we get a more efficient brain-computer interface than keyboards.