pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
rurtty has joined #commonlisp
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
theBlackDragon has quit [Ping timeout: 260 seconds]
theBlackDragon has joined #commonlisp
waleee has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
xaltsc has joined #commonlisp
thuna` has quit [Remote host closed the connection]
cercopith_ has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 246 seconds]
<AadVersteden[m]>
I'm in the break-camp too, including helper macros to make the process easier. I don't use the debugger enough to remember what keybindings let me inspect the object at point.
<pjb>
(inspect object-at-point) ;-)
_cymew_ has quit [Ping timeout: 248 seconds]
<AadVersteden[m]>
pjb: From emacs `M-x slime-inspect`? I should read the manual, perhaps it'll stick then.
* AadVersteden[m]
is too old-school and should try sly instead
<_death>
C-c I.. in the debugger you can just type 'i'
<AadVersteden[m]>
I'll try to remember `i` for today. A small step ... ^_^ I think it's just that I don't use it enough though. More lisp, less other-stuff.
cage has joined #commonlisp
thuna` has joined #commonlisp
_cymew_ has joined #commonlisp
elderK has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
Lord_of_Life has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
Everything has left #commonlisp [#commonlisp]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
makomo_ has joined #commonlisp
Hrodgar has quit [Quit: Leaving]
morganw has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
tyson2 has joined #commonlisp
chipxxx has quit [Read error: Connection reset by peer]
<Josh_2>
Good Morning
_cymew_ has quit [Ping timeout: 265 seconds]
makomo has joined #commonlisp
Catie has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
waleee has quit [Ping timeout: 246 seconds]
xlarsx has quit [Remote host closed the connection]
xlarsx has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
eddof13 has joined #commonlisp
xlarsx has quit [Ping timeout: 250 seconds]
eddof13 has quit [Client Quit]
Guest6495 has quit [Quit: WeeChat 3.6]
eddof13 has joined #commonlisp
waleee has joined #commonlisp
doomduck has joined #commonlisp
doomduck has quit [Client Quit]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
eddof13 has joined #commonlisp
pve has quit [Quit: leaving]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
<Shinmera>
I remain hopeful that we can make a breakthrough porting SBCL to the Switch next year, but it'll be a bit before that process gets started up again.
tevo has quit [Read error: Connection reset by peer]
tevo has joined #commonlisp
nnamdi has joined #commonlisp
nnamdi has left #commonlisp [#commonlisp]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
<lagash>
Shinmera: ah, that kind of console! lol
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
hosk1 has joined #commonlisp
hosk1 is now known as goober
xlarsx has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<luis>
Shinmera: nice
xlarsx has quit [Ping timeout: 260 seconds]
<Shinmera>
lagash: it is one for all intents and purposes
shka has quit [Ping timeout: 268 seconds]
mrcom__ has quit [Read error: Connection reset by peer]
mrcom__ has joined #commonlisp
attila_lendvai has quit [Quit: Leaving]
xlarsx has joined #commonlisp
<aeth>
Doesn't seem like a console to me. The whole point is that any game that runs on Linux (including via wine) should just work. Even if it runs with keyboard+mouse controls and no controller support.
<Shinmera>
it's a device specifically manufactured to play games on.
attila_lendvai has joined #commonlisp
<Shinmera>
if you believe that consoles also must have proprietary APIs and hardware that's on you.
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
xlarsx has quit [Ping timeout: 265 seconds]
<verisimilitude>
That's cool, Shinmera.
<verisimilitude>
Does a game just work when inserted or downloaded? If not, it's not really a console.
mrcom__ has quit [Read error: Connection reset by peer]
mrcom__ has joined #commonlisp
<Shinmera>
that's a weird definition
<verisimilitude>
The idea behind a video game console is that uniform hardware enables precise targeting and avoiding issues common under, say, personal computers.
<Bike>
is this really important? cool work shinmera
<verisimilitude>
I'm not criticizing Shinmera.
<Shinmera>
and the steam deck sure has uniform hardware.
mrcom__ has quit [Read error: Connection reset by peer]
<verisimilitude>
Thus, any game targeted at a video game console should work without issue.
<aeth>
verisimilitude: it has uniform hardware; what makes it not a console imo is you can just go to http://www.sbcl.org/platform-table.html and download the latest AMD64 SBCL and it will run
mrcom__ has joined #commonlisp
<Shinmera>
why would that not make it a console lmfao
<Shinmera>
yall are out of your minds
<verisimilitude>
A video game console isn't inherently locked down.
attila_lendvai has quit [Quit: Leaving]
<Shinmera>
aight I'm off to sleep.
<verisimilitude>
Say, give me one moment, Shinmera.
mrcom__ has quit [Read error: Connection reset by peer]
<aeth>
verisimilitude: a video game console is inherently locked down imo... it's just that some of the older ones were really, really easy to bypass
<Shinmera>
no
<verisimilitude>
Alright; good night, then.
<aeth>
but if people disagree, they disagree
<aeth>
nobody's changing their mind on stuff like that
<verisimilitude>
That's stupid, and I disagree.
mrcom__ has joined #commonlisp
attila_lendvai has joined #commonlisp
<verisimilitude>
People are, of course, free to believe falsities, aeth.
<aeth>
Game-oriented, uniform-hardware microcomputers existed in the 1980s and weren't considered consoles. e.g. the Amiga.
<verisimilitude>
The Atari VCS is a video game console.
<masinter>
If a tree falls in the forest, but no one plays a video game with it, did it really fall down?
<verisimilitude>
Yes.
mrcom__ has quit [Read error: Connection reset by peer]
mrcom__ has joined #commonlisp
doomduck has joined #commonlisp
doomduck has quit [Client Quit]
<masinter>
the problem with expert systems is that non-experts have trouble with expert-defined terms
doomduck has joined #commonlisp
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
<masinter>
'have trouble' = disagree on definitions
<aeth>
Well, first of all, there's a lot of ways to define it. For one thing, Valve is very careful not to describe it as a console because then Sony would probably pull their games (which all run on the Deck) from Steam.
<aeth>
So by self-definition and marketing it's not a console.
<aeth>
But it is a device primarily designed to run games. But it's also a device that isn't in any way locked down to just games and has a desktop mode that (with some controller bindings, which are apparently not done by default) runs just about anything OK. You can use it as yet another Firefox machine.
mrcom__ has quit [Read error: Connection reset by peer]
attila_lendvai has quit [Remote host closed the connection]
<masinter>
you choose the definition to match some criteria that other systems derive from the categories you've assigned, but others, with different applications, don't like the categories you've assigned.
attila_lendvai has joined #commonlisp
<aeth>
And as for whether the OS is a "gaming OS" or a general purpose OS is also questionable.
mrcom__ has joined #commonlisp
<masinter>
it's the general problem with metadata
<aeth>
It does require no special effort to port software to it, though.
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
<Bike>
seriously, what purpose does this definition serve. and what reason is there to talk about it here.
<masinter>
can it run lisp? can you build a console game in Lisp?
xlarsx has joined #commonlisp
<Bike>
well, the steam deck apparently can, and shinmera is planning on porting sbcl to the switch
<aeth>
masinter: As I said, you can just pull in the official SBCL from the internet and run it (and it has the SDL libraries available out of the box so if you *only* use SDL and OpenGL, it will work)
<Bike>
and there are some prior examples like jak and daxter
<Bike>
though that wasn't exactly common lisp
<masinter>
we need to finish SDL for medley
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
<char[m]>
Hello common lisp. Is there any implementation of all ansi macros that uses only other ansi macros, special-forms, and ansi functions?
<Bike>
probably not, since some of them can't be done with just that, like print-unreacable-object off the top of my head
<Bike>
SICL is probably the closest
<Bike>
unreadable*
xlarsx has quit [Ping timeout: 244 seconds]
<Bike>
formatter would also be pretty annoying...
<verisimilitude>
Give me a few years, char[m].
mrcom__ has quit [Read error: Connection reset by peer]
<aeth>
Based on my experience benchmarking on the Steam Deck, I don't think that the Switch is a viable target for Common Lisp.
pillton has joined #commonlisp
<aeth>
You'd have to really, really, really spend a lot of time benchmarking and optimizing for a very weak platform that probably only has a few years left in it
mrcom__ has joined #commonlisp
<verisimilitude>
One gigahertz is ``very weak'' nowadays.
<aeth>
My stuff on the Deck seems to take up 10% of the CPU in its benchmarking overlay, which was surprising given how little it does. I wouldn't be surprised if running it on the Switch at 60 FPS was impossible.
<Bike>
some macros also depend on various other aspects of the runtime that may or may not count; for example handler-bind and restart-bind are often implemented to bind an internal special variable
mrcom__ has quit [Read error: Connection reset by peer]
<char[m]>
binding a special variable is not a problem for me. That uses let which is a special-form.
mrcom__ has quit [Read error: Connection reset by peer]
Lord_Nightmare has joined #commonlisp
mrcom__ has joined #commonlisp
<char[m]>
The internal variable is not a problem, just an internal function would be a problem.
<aeth>
verisimilitude: A 2015 Nvidia ARM Tegra chip on TSMC 20 nm or 16 nm with 4 cores clocked at 1 GHz may not be strong enough, no. It's all about how much time you want to spend fitting what you want to do within the desired framerate. Now divide by 3 to 5 because it's CL. And also keep in mind that if you push something near its limits, you're going to lose frames to the GC.
<verisimilitude>
It's still ridiculous to call such a machine ``very weak''.
attila_lendvai has quit [Remote host closed the connection]
<verisimilitude>
It's a supercomputer.
attila_lendvai has joined #commonlisp
<Bike>
char[m]: it's in particular hard for me to imagine implementing the more complicated macros, like formatter or loop, without defining some accessory helper functions
<Bike>
the accessory functions might not need to do anything too implementation-defined, but i don't know if that matters for whatever your use case is
<aeth>
verisimilitude: It's not about if it would have been considered to be a supercomputer in 1995 or not. It's about if you can fit your logic within the rather strict time limits you have to compute everything. On a modern desktop, the CPU is essentially irrelevant they're that fast. You literally don't need to care about the choice of language. On the Switch, you might have to rewrite parts of SBCL to make
<aeth>
them run faster or more deterministically.
<aeth>
verisimilitude: A supercomputer is batch-oriented and has all day to run your simulation. A video game does not.
<char[m]>
Bike, you're totally right. My question is mal-formed. What I'm actually looking for is for the expansion to only include ansi stuff. If it is not feasable still, what is the largest subset of ansi macros that easily follow these rules.
<aeth>
verisimilitude: If you target a platform where you have to focus on CPU optimizations, you may find that that platform is obsolete (i.e. not sold anymore) by the time you're finished and that all of your time was wasted.
<verisimilitude>
For those two in particular, additional functions are effectively required, Bike. Even I wouldn't try to write them otherwise.
<verisimilitude>
The expansion is perfectly reasonable, however, and I'm not familiar with any implementation that does such.
<Bike>
it's pretty common to have accessory macros or functions even in the expansions
<Bike>
like WITH-LOOP-COLLECTION-HEAD or whatever it's called on sbcl, off the top of my head, and some extra functions for the more specific format directives
<verisimilitude>
A supercomputer isn't strictly batch-oriented.
<Bike>
as i said, i think SICL is the best bet here, since beach has tried to write it to be usable by different implementations
<verisimilitude>
Anyway, if one gigahertz isn't enough for Common Lisp, that only reveals the pathetic nature of the implementations.
<char[m]>
accessory macros are fine as long as they expand to only ansi stuff. I'm talking full expansion.
<masinter>
i'm looking for the same for ANSI common lisp macros for things not in CLtL 1
<aeth>
verisimilitude: A 2015 mobile chip that's probably as strong as a 2005 desktop chip isn't going to have a fun time running 2022 Common Lisp, especially when you have soft real-time constraints. It's just a fact. There's a reason why embedded is always years behind the rest of the industry, after all. People were still writing assembly for handheld games in the early '00s long after everyone else moved on.
<aeth>
verisimilitude: I don't know why you want to keep arguing this point
mrcom__ has quit [Read error: Connection reset by peer]
causal has quit [Quit: WeeChat 3.6]
<aeth>
You can only do so many things a second. And if you write for weak hardware, you're going to spend all of your time squeezing in more things into a second instead of actually writing your program.
<verisimilitude>
A one gigahertz machine isn't ``embedded''.
mrcom__ has joined #commonlisp
<verisimilitude>
People have a totally warped perception of how fast computers are, because of the army of idiots responsible for most programming work.
<Bike>
i don't really understand your use case, char[m]. for example a handler-bind implementation that expands into some internal variable binding won't work with other implementations' SIGNAL functions, whereas some weird nonstandard function being in an expansion doesn't inhibit other kinds of static analysis
doomduck has quit [Quit: WeeChat 3.6]
<aeth>
verisimilitude: I wrote an incredibly fast, optimized prime sieve for Project Euler years ago. Perhaps the fastest prime sieve for SBCL. Definitely in the top 10 because there can't be that many people who cared that much. I absolutely would not want to put that much effort into every line of code going into a 3D game. At some point, you have to ship.
<aeth>
Optimizations can be fun, but my target tick rate is 1 ms. Everything needs to fit in that budget. The faster the hardware, the less work I need to do for that.
mrcom__ has quit [Read error: Connection reset by peer]
doomduck has joined #commonlisp
<verisimilitude>
Sure, and this is why supercomputers spend minutes loading basic things. I fault no one here, of course; all of this optimization work should've been finished decades ago.
attila_lendvai has quit [Ping timeout: 268 seconds]
<verisimilitude>
One conclusion here could be that Common Lisp isn't really suited to video games, however.
mrcom has joined #commonlisp
<Bike>
some kinds of game may not actually need to push the performance envelope of whatever they're running on, such as, just hypothetically, a 2d action platformer
<aeth>
verisimilitude: Or we can just leave mid-2010s mobile chips in the dustbin of history and write for the handhelds of the 2020s... which also means that any desktop and most laptops from the 2010s will also be able to run it.
<Bike>
also there's a cool and semi trivial theorem that says that optimization can't be finished
mrcom has quit [Read error: Connection reset by peer]
<Bike>
lucky for me
<aeth>
Because by the time you shipped something for the Switch (someone whose game is almost complete may be a different story), the Switch will be obsolete for the next generation of consoles
doomduck has left #commonlisp [#commonlisp]
<verisimilitude>
That just moves the goalposts, aeth.
doomduck has joined #commonlisp
mrcom has joined #commonlisp
<aeth>
verisimilitude: you have to balance the time constraints of the program with the time constraints of the programmer.
<verisimilitude>
I say the balance is too damn far in one direction.
<aeth>
Everything takes a lot longer to write than you think
<verisimilitude>
It's so far it's absolutely sickening.
<char[m]>
Bike: If my macros expand to different things on all implementations, how can I expect to analyze them consistently.
<Bike>
true enough.
<masinter>
i'm unclear on the relationship between DEFMACRO and SYMBOl-FUNCTION
<masinter>
or FDEFINITION?
mrcom has quit [Read error: Connection reset by peer]
<aeth>
verisimilitude: Common Lisp is perfectly fine even for 3D games, but you can't really push your luck too far. You're not going to be able to write a Quake clone in Common Lisp that actually runs in the same minimum system requirements as Quake (Pentium 1?). In theory, maybe you would be able to if you wrote your own Common Lisp compiler for the Pentium and Windows 95 and spent the next 10 years on this
<aeth>
project. But why?
<verisimilitude>
It's not clear, masinter.
<verisimilitude>
I seem to recall macros aren't necessarily treated like functions, but can be.
mrcom has joined #commonlisp
<Bike>
masinter: fdefinition (or symbol-function) on a macro name will get you some weird thing you can't use dependently, and you probably shouldn't do it.
<Bike>
masinter: you can instead use macro-function.
<masinter>
i'm working on the masterscope code-walker to fix up some common lisp handling
<Bike>
i'm uh, not sure what word i should have used instead of "dependently" there
<masinter>
and I ran into some cases where the same symbol had a DEFMACRO definier and an Interlisp FDEFINITION
<verisimilitude>
Perhaps ``portably'', Bike.
<masinter>
(a.k.a IL:GETD)
<aeth>
verisimilitude: If you avoid every choice of language that's slower than another choice of language (at least for the current implementations), then you'd only write assembly. And at that point, good luck keeping up with everyone else using a more productive programming language.
<verisimilitude>
I do occasionally write little games in machine code, but that's not the point.
<Bike>
well, i don't know what interlisp fdefinition does.
<masinter>
i think it's worthwhile to target programmers who have no idea about O(1) vs O(e^n) algorithms
<verisimilitude>
Common Lisp is suited to very dynamic systems, which a game may be, but a game may be a very predictable and static system, which makes Common Lisp entirely unsuited to it.
<aeth>
verisimilitude: My point is, you pick a target for minimum acceptable performance on minimally viable hardware (which, yes, is more than 1 GHz ARM), you find a programming language and an software architecture that can hit that target, and then you write.
<aeth>
If you can then later on optimize it to run on weaker machines, great. If not, oh well.
<masinter>
raspberry pi makes a very nice lisp machine
<aeth>
Optimization really is endless
<verisimilitude>
This isn't a good faith argument.
<verisimilitude>
Something being endless is no excuse to barely try.
<aeth>
verisimilitude: look, predictable and static in the data format that a game expects: (make-array 42 :element-type 'single-float :initial-element 0f0)
<verisimilitude>
Also, for any machine, there's at least one optimal form of any program it can execute.
<hayley>
How do I find it?
<verisimilitude>
Exhaustion is one method some compilers use.
<verisimilitude>
Regardless, I've demonstrated this isn't even truly endless.
<hayley>
Will I get that time back, compared to using heuristics?
<verisimilitude>
I don't know.
<aeth>
"Oh, look, I wrote the most perfectly optimal way to handle my float-based vide-" *Ryzen 7000 releases.* "oh, shit, look at that. AMD has AVX-512 now, looks like I need to rewrite everything."
<aeth>
Optimization definitely is endless if you want to support the PC platform because they keep adding new instructions and APIs.
<verisimilitude>
This is another reason video game consoles are better targets.
<drakonis>
are they?
<aeth>
These days, video games often release on three generations of consoles (e.g. PS3, PS4, PS5) because a popular game can outlive the lifespan of one console.
<aeth>
Not to mention releasing on more than one console platform, as well as PC, etc., etc.
<verisimilitude>
Sure, and that's an argument for a high-level representation of the game, which isn't necessarily what the game itself uses.
<aeth>
And if you hand-optimize everything for 1080p, what happens when everyone slowly moves onto 1440p now that 1440p is basically as affordable as 1080p? Or 2160p in 10 years?
<verisimilitude>
All of this to excuse sloth.
<hayley>
That's not what I'm trying to argue.
<verisimilitude>
Allow me to shift the goalposts a little. What's more important than speed is correctness, and very few games are correct. Common Lisp actually does help with this a little.
<verisimilitude>
Right now, most software is slow and doesn't work, which is unacceptable.
<aeth>
I'm saying that it will never be worth the effort to make a 3D Common Lisp game engine (note that the original engine in question is 2D; an easier task) work on the Switch because by the time you do that, Nintendo will move onto something else. Because it takes time and the Switch is already near the end of its life.
<aeth>
This isn't excusing sloth. This is just the reality of having limited time and money.
<verisimilitude>
Well, historically, it's not worth the effort to make a video game in Common Lisp at all.
mrcom has quit [Read error: Connection reset by peer]
<boigahs>
I dont see how this logic is limited to common lisp
<verisimilitude>
It's not.
mrcom has joined #commonlisp
<aeth>
If something bordering on a 3D hello world uses a noticeable amount of resources on the Steam Deck (but not noticeable on a desktop), there's no way you're going to get a 3D game engine working on the Switch in a reasonable amount of time.
<hayley>
I've taken months to make a parallel GC that doesn't crash, and it hasn't shown any speedup yet. I'm not convinced that I'll ever make the time back, and I might not due to Amdahl's law.
<verisimilitude>
That really says more about the language than the hardware.
<verisimilitude>
Amdahl's Law is often used as sophistry.
<aeth>
But that's OK because not everyone needs to play it on the Switch. Plenty of games either don't run on the Switch or have poor ports on the Switch and that's not just because they're lazy or w/e. It's often because they try to do more than the poor Switch can keep up with. Because 1 GHz on the IPC of a 2015 ARM CPU is less than you think.
<verisimilitude>
A non-von Neumann architecture can completely avoid this ``law'', hayley.
<hayley>
I mean, my time would be better spent on some other not-GC part of the system.
<verisimilitude>
It's more than we could ever think, aeth.
<hayley>
Sure, but I am stuck with the dataflow-when-I-feel-like-it-but-usually-von-Neumann architecture most computers use.
<verisimilitude>
Yes, unfortunately.
<hayley>
And yes, people have published papers on how modern CPU architecture sucks for implementing a GC, arguing for hardware accelerators.
<verisimilitude>
The only way to fix computing is to destroy most of it.
<aeth>
hayley: As long as it doesn't have any *slowdown* it's worth it
<hayley>
aeth: That's also hard.
<aeth>
yes
<hayley>
I tested it on my laptop and programs ran way slower, due to some second-order business. Maybe locality, maybe allocator locking shenanigans (as I technically use pages less efficiently than copying GC).
<aeth>
My game engine's still single-threaded because just naively adding a bunch of threads slowed it down.
<aeth>
It's not easy.
<hayley>
The least I can say is that I have an algorithm that I know how to parallelise without breaking it, but I can't find any speedups yet.
<masinter>
it's possible to do motion graphics in lisp if you have a lot of headroom for every thread
<aeth>
masinter: but to verisimilitude, it doesn't matter if you have a lot of headroom for every thread... you must have a lot of headroom for every thread on every processor, even absolute garbage ones
<masinter>
only the ones involved in updating the graphics
<masinter>
i've had to go in and add delay in a lot of graphics demos in medley because it was updating the screen too fast
<aeth>
absolutely... I force vsync on because if I don't my graphics card literally whistles it goes through frames so quickly and I'm kinda concerned it'll break.
<aeth>
never heard it get that loud on any real game, even ones that don't hit 60 FPS
xlarsx has joined #commonlisp
<aeth>
But a fast-for-2019 desktop CPU and a fast-for-2016 desktop GPU are considerably more powerful than a 2015 mobile CPU/GPU.
<aeth>
And I'm not going to waste time optimizing for a 2015 mobile CPU/GPU just because it's probably as capable as a 2005 desktop CPU and GPU
<masinter>
i'm working on code written for 1986 workstations
xlarsx has quit [Ping timeout: 260 seconds]
les_ has quit [Quit: Adios]
<aeth>
so nobody will notice if you slow things down 10x
les has joined #commonlisp
<masinter>
it was built for big-endian machines, so the emulator has to byte-swap like crazy