programming

[real sierra]

actually released his own source code?

wdym not using the API

[stray dragon]

not using the api or macros, released source code, reduced tokens by huge amount already??

this dude is so real

[fierce ether]

commands to cute chess

[stray dragon]

holy shit

[rigid timber]

damn, bro playing on hard mode

[stray dragon]

he means no api

[fierce ether]

rnbqkbnrpppppppp................................PPPPPPPPRNBQKBNR

my goat

[real sierra]

who's gonna tell bro I'm compiling with -std=c23

[fierce ether]

wdum

[stray dragon]

variable types must be declared

[clear sedge]

no implicit int

[stray dragon]

no having i; as a declaration of i

[clear sedge]

[stray dragon]

needs to be int i;

also for functions, and for function inputs

also: variable names can be as long as you want

they'll still count as 1 token

long numbers also count as 1 token

[fierce ether]

is my cmakelists file not the same as that? or have a done a massive oops

[amber fractal]

On the positive note, macros are going to have a field day existing with #define ONE 1, #define ZERO 0, #define TWO 2,

[trim valve]

not really, that's still gonna need two tokens?

[rigid timber]

someone also tell Smeagle that it's about token count, not character count...

[stray dragon]

error: type of "minimax" not declared
error: type of "d" not declared
error: type of "a" not declared
error: type of "b" not declared
error: type of "m" not declared

[rigid timber]

you don't need to have single-variable names without any spaces anywhere

[stray dragon]

no implicit typing

you have to explicitly tell it what type each variable is

[stray dragon]

this too

[clear sedge]

or use auto if you're a pussy

[stray dragon]

not a thing in C i think

only in C++

[amber fractal]

mb, thought {ONE TWO ZERO 1} would parse

[real sierra]

auto's face when I #define PBoard Board *

[clear sedge]

it's a thing in c23

[stray dragon]

oh fr?

[real sierra]

^

[clear sedge]

yes

[stray dragon]

hmmm.

[real sierra]

auto already existed in C but with a different and useless meaning

[trim valve]

I think it will, but surely the spaces count?

[real sierra]

they extended it to have the C++ meaning as well

[stray dragon]

this could save me like 2 tokens

[real sierra]

anyway I think smeagle should be ok still, they just might have to gain a few tokens

[clear sedge]

afaik auto was always implicitly there with the original storage class meaning

[trim valve]

guys I'm goated

[real sierra]

gotta add those types

[clear sedge]

i love when i auto auto

name so nice you say it twice

[real sierra]

I mean this looks pretty good no?

[amber fractal]

That's one for testing, because the list with spaces would be 3 tokens each

[trim valve]

its probably a lot more golfable in C

[fierce ether]

1699...

[real sierra]

and then you use macros

[stray dragon]

you could save a bunch by adding the chess api from shiro, probably

[real sierra]

that's also true but if you're really committed to not doing so

though I have to admit, I'm not sure how your current code gets the board from the chess host

[stray dragon]

calculating legal moves without the api is not that fun

[amber fractal]

Wait, I don't need to install the C toolchain to test the token count

[stray dragon]

would expect it to cost like 500 tokens minimum

accounting for the complexity added by en passant and castling

[amber fractal]

Laptop get over here I'm writing sudocode

[real sierra]

if they want to challenge themselves then that'd be really cool

[stray dragon]

^

[fierce ether]

yeah but i dont do that lmao

[real sierra]

a minimal legal moves implementation is no joke

[trim valve]

pseudocode

[obsidian mantle]

will gcc handle this

vscode is scared

[stray dragon]

fair, they're rare anyways

[real sierra]

is that a bug

oh I see

I would just make the bool an int

[trim valve]

I'm still more than mildly tempted to force something to assume I have popcnt so I get a mild board evaluation speed boost

[clear sedge]

are you passing a bool where it expects an enum?

[real sierra]

should work the same and the warning will probably go away

[obsidian mantle]

im calling is_white and passing it to chess_get_bitboard

[obsidian mantle]

yes

[real sierra]

oh, yeah that's probably fine

[clear sedge]

i mean it'll compile and probably work

[obsidian mantle]

i'll try to compile lets see what g++ says

[clear sedge]

it'll probably give you a warning

[trim valve]

with the slight side effect that the program would have invalid instructions if shrio didn't have popcnt

[clear sedge]

you're safe to ignore it though

[real sierra]

warnings are good

[trim valve]

but

[real sierra]

warnings are a sign you're being token efficient

[rigid timber]

just set target cpu to native in Cargo.toml

[trim valve]

genius

[obsidian mantle]

it shows it as error

vscode

oops

[clear sedge]

[real sierra]

then have to cast

[obsidian mantle]

is this a cast

[rigid timber]

tbh I'm pretty sure Shiro's CPU supports SSE4, Rust is just very conservative with the defaults

[real sierra]

should be

[clear sedge]

that is a cast yes

[real sierra]

if that fails then there's always chess_is_white_turn(board) ? WHITE : BLACK

[obsidian mantle]

worse

[real sierra]

which will work for sure

[obsidian mantle]

cant cast piecetype

[real sierra]

6

[obsidian mantle]

king

[clear sedge]

just use the enum value

[real sierra]

can you just do KING instead

[clear sedge]

it's the same amount of tokens either way unless it's an enum class

[obsidian mantle]

i thought i need to do something like piecetype.king

alright then

[real sierra]

in C, just KING should work

✅

[obsidian mantle]

works here too looks like. alright

[clear sedge]

c++ has the same behavior for non-class enums

:3

[real sierra]

C++

[obsidian mantle]

do i need to make a function to convert piecetype to bool

[stray dragon]

stupid ass enums smh

[real sierra]

other way I think

[obsidian mantle]

what if i pointer cast it

[real sierra]

^

this is probably easiest

[clear sedge]

* (T *) &t is probably more tokens than ternary

[obsidian mantle]

yeah fine

worked i think

[stray dragon]

does something like !!chess_is_white_turn(board) work?

[clear sedge]

it's still a bool tho

[real sierra]

need to convert it to PlayerColor not to bool

[stray dragon]

ah i see

[real sierra]

idk why the conversion is being so upset

[stray dragon]

so your function sucks

thanks shiro

[rigid timber]

if you're converting PlayerColor to PieceType, I'd be very concerned ngl

[real sierra]

how can C not convert bool to enum

[clear sedge]

it's c++

[obsidian mantle]

what scenario could cause problems

in this kind of conversion

[real sierra]

my brain is half shut down I don't even remember typing that

[amber fractal]

@trim valve Whitespace is not counted

Now for the lols let me justttt

[clear sedge]

idk why this is slightly funny to me

[stray dragon]

it's free real estate

[fierce ether]

see this is why you release source code

thank yall

[stray dragon]

but what if my super secret bot search method gets leaked and then everyone uses it 🥺

[real sierra]

im too scared to release my source code in case someone improves it more than I do

[trim valve]

I know that if I release my code I will be safe because anyone who codes better than me will be writing C anyways and despise rusts syntax

[stray dragon]

i'm not sharing mine because it was all written before the tournament rules and the silly little -std=c23 was there (also it's never been tested) ((also also it's probably dogshit))

just gonna do a full rewrite i think

maybe carry over the neural net and eval function

and then redo the search method

[amber fractal]

Added a #define _ONE -1, as well. From 199 tokens to 167

[stray dragon]

how many -1's do you HAVE

[amber fractal]

Well it is all 4 defines

On the other hand... I only did line 4

[real sierra]

is -1 actually two tokens

[stray dragon]

yes

it is

[amber fractal]

Yep

[real sierra]

why...

[nocturne olive]

Unfortunately no macros in Kotlin

[stray dragon]

i just have a #define n1 -1 lol

[stray dragon]

kotlin is fine i think

[real sierra]

I would just find the unsigned int equivalent

[obsidian mantle]

0b11111111111111111111

[stray dragon]

competitive enough on its own

[real sierra]

and use that

[nocturne olive]

Yeah it makes up in having an insane STD

[quick sun]

I may be stupid but what is a token (I'm a python dude)

[stray dragon]

fuck that's smart

[real sierra]

roughly speaking, a word or punctuation character

[quick sun]

interesting

[stray dragon]

a unit of parsed language

[real sierra]

int myVar = 1; --> ["int", "myVar", "=", "1", ";"]

[stray dragon]

in this case, a token is whatever the toknt thing says it is

[rigid timber]

might as well go for 0xFFFF...

[nocturne olive]

One example of Kotlin STD being insane here in my patched in anti-stalemate

[stray dragon]

string of 8 billion characters? yeah that's 1 token

[clear sedge]

parsers chop text/code up into more digestible pieces; tokens
def main(): -> [def, "main", open_paren, close_paren, colon]

[stray dragon]

1 single comma? yeah that's also 1 token

[amber fractal]

For the lols, defines for 0, 1, -1, 2, decrease line 4 from 199 tokens to 167

[real sierra]

why define 0

[nocturne olive]

This code is cursed but also small

[stray dragon]

you fool

it's 0,

not 0

[quick sun]

I just realised I'm a chess player and a programmer and have no idea what I'm doing still. this'll be fun

[real sierra]

smart

[rigid timber]

I still haven't started any work on my bot

[clear sedge]

dw neither have i

[nocturne olive]

getLegalMoves(newBoardState).apply { if (this.isEmpty()) scoreCpy -= 99999999 }.forEach {
Kotlin STD silliness

[rigid timber]

I do have most of the JS bindings done tho...

[obsidian mantle]

it worked
first actual mate

[stray dragon]

i'm a comma HATER so i personally do this because i'm deranged

[clear sedge]

js bindings

[quick sun]

just reading that ending makes me very confused

[rigid timber]

surprisingly simple with Deno tbh

(I haven't actually tested them yet)

[stray dragon]

ah wait i need spaces

[quick sun]

ahhh

that makes sense

[nocturne olive]

Well make sure you're definitely passing Move s by value, I got tripped up by that for a bit

[obsidian mantle]

maybe its luck i'll check more

[real sierra]

nice mate

[rigid timber]

yeah, I did notice that

[clear sedge]

i feel like this is bordering on using strings for non-stringy purposes

[stray dragon]

perfect

[rigid timber]

tbh the larger issue will be properly representing a Move without copying it twice...

[stray dragon]

it's not evaluating

[clear sedge]

you can just merge them all into one string constant to save even more tokens

[real sierra]

did t see the 64-bit token rule

[stray dragon]

i did

that's why they're all 64 bits

[real sierra]

then you're fine

[stray dragon]

each string is up to 1 long long

and no more

[real sierra]

totally valid for the use case if those are storing what I think they are

[clear sedge]

1 long long long?

[stray dragon]

long long long long long

[rigid timber]

loooooong loooooooong maaaaaaaaaaaaaaan

[real sierra]

windows: yeah looks like an int to me

[clear sedge]

how long is a long long int if a long long could long long int

[nocturne olive]

I just copied it twice to have a different binding on the native and Kotlin sides

Just cleaner

[rigid timber]

I don't like it

[stray dragon]

the network is hungry

[clear sedge]

"best i can do is 16 bits"

[nocturne olive]

You may not like it but it's the cleanest solution

[stray dragon]

i must feed it many hex codes

[rigid timber]

but I think I'll just do a copy first and see if it actually affects performance

[stray dragon]

before i had them all hidden away in a single massive string of parameters lol

then i saw that annoying rule

truly unfortunate

i wonder if i can find a way to compress them later.

[amber fractal]

Yeah that was my doing

[stray dragon]

damn it iggly

[rigid timber]

so what actually are those long longs?

[stray dragon]

i could have had INFINITE parameters for my neural net

[rigid timber]

ah

[stray dragon]

ternary parameters for a neural network, packed into ulongs

[amber fractal]

Shiro said they were going to check for exactly that anyways, so I just put it on paper

[clear sedge]

imagine making the chess bot with a backdoor where you can control what it does directly

[rigid timber]

question for the C nerds, is Move 24 bytes?

[clear sedge]

cheating? most definitely
funny? most definitely

[clear sedge]

"Move"?

[rigid timber]

the Move struct

[trim valve]

does vscode let you hover over the struct for that info

I know rust does

[clear sedge]

just print sizeof(Move)

[rigid timber]

can't do that in JS lmao

[clear sedge]

oh

my condolences

[nocturne olive]

I think it's 8 + 8 + 4 + 1 + 1

[rigid timber]

that's 22 bytes, which doesn't exactly align to anything

[clear sedge]

i mean depending on compiler & options it may also align to like 16 bits in which case it'd be 32 bytes

[nocturne olive]

Oh, no, it's 8 + 8 + 1 + 1 + 1

[rigid timber]

[obsidian mantle]

not mating anymore
its over

[rigid timber]

well fuck me I guess, bc depending on the compiler not to fuck with the alignment is kinda futile

[clear sedge]

just test the alignment and size in c using the same flags as the readme says it uses

[rigid timber]

I'll just trust what bred got, surely it won't result in anything bad

otherwise it's Shiro's fault

[real sierra]

my best bet would be that C packs the bools into one byte with masking but it's probably implementation defined

[final tinsel]

chayleaf idk if ur here rn but ik you live here, so i wanted to tell you that i noticed that you are in the infinite free wil gif

https://cdn.discordapp.com/attachments/1067638175478071307/1324813969055285290/free_will.gif

[nocturne olive]

Yeah that's how the JVM accepts them

[nocturne olive]

Using Byte instead of Bool is way more reliable

[clear sedge]

bool? more like boooooooooo

[stray dragon]

fuck bool

[clear sedge]

[stray dragon]

imagine using bool

lmao

[trim valve]

lol that reminds me

iirc c++ does some shenanigans with vectors of booleans

https://en.cppreference.com/w/cpp/container/vector_bool.html

[sage crag]

oh this thing

[rigid timber]

it actually is 24 bytes, at least on Windows with MSVC...

[sage crag]

bitflags

they should have just put it in a different type

to be honest

vector => vector

bitflags => bitflags

[trim valve]

no konii

you must abide to the thinking of my a level computer science teachers

[rough bloom]

makes sense I think?
it's 8 + 8 + 1 + 1 + 1, alignment of 8 bytes because uint64 so 24 bytes with padding

[rigid timber]

well yeah, but who knows how the compiler would fuck with it

[sage crag]

what did they think

[rigid timber]

trusting a C compiler not to do something stupid is like trusting Shiro not to have a birthday today

[stray dragon]

"Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt."

poor shiro

[rough bloom]

are compilers allowed to mess with structs like that
I thought alignment and such are defined as part of the target, so they should at least be consistent on one platform

[sage crag]

yes, compilers can mess with structs however they like unless you define a specific alignment

[rigid timber]

dinkdonk Shiro go specify the struct alignment

[sage crag]

all the c spec guarantees is that members are stored in order and that sizeof(T) includes padding

iirc

it allows compilers to insert padding or do alignment, but its up to them what they do with it

oh also it obviously defines that accessing members with a.b or a->b is safe

[rough bloom]

ye, the specific alignment for each type isn't given by the spec I think, it's given by the target
but surely if the spec guarantees that fields are in order and are aligned then it's consistent as long as the same alignment is used for everything?

[sage crag]

struct A {
  uint8_t b;
} __attribute__((aligned(16)));

struct C {
  uint8_t d;
  uint16_t e;
} __attribute__((packed));

[sage crag]

alignment determined by the compiler, therefore it may vary from compiler to compiler and from target to target

therefore padding bytes may vary and therefore the whole struct size

[rough bloom]

is this the view of the C spec or are there actual differences in alignment between compilers for the same target

[sage crag]

its why things like sizeof(Struct) exist rather than just deciding its sizeof(uint8_t) + sizeof(uint16_t)

[sage crag]

by-and-large there will be no difference between compilers on the same target

especially with the main two gcc and clang

though clang's is more up to llvm, and who knows what llvm is doing

[rough bloom]

ye, this is basically what I was getting at
I'm not sure if for the C spec the concept of a "target" even really exists, but for LLVM it certainly does

C is technically platform-agnostic so it doesn't specify anything here, but the actual compilers do

-# kinda

[sage crag]

yup pretty sure the c spec doesnt define any platform things except for behaviour that must be followed on all platforms

cpu arch + abi + os are for compilers and toolchains

c spec is for c

actually this is a notable case

abi may force different alignment

as well as cpu arch

os is less common but im sure something of that kind happens too since long means different things on windows and linux

[real sierra]

tldr do not assume anything about the size or alignment of the move struct

[rigid timber]

well that's nice but that doesn't really work

if we get a raw pointer and a move count, how are we supposed to pick out moves from the array the pointer points to if we don't know the size of Move

[sage crag]

shiro can add __attribute__((packed))

to the def of the struct

or shiro could provide a better api for moves

[rigid timber]

y'know what, I'll create an issue for exactly that

[real sierra]

surely your ffi backend has methods for extracting fields from a struct

[rigid timber]

it doesn't, no

[real sierra]

[rigid timber]

because structs don't have a concrete representation if you don't specify it

[real sierra]

surely you can just specify the field types and the ffi backend can figure out how that translates on your system tho

[sage crag]

__attribute__((packed)) wont really pessimise performance that much, and it would guarantee alignment on most compilers

[rigid timber]

well no, how would it know what it translates to?

[nocturne olive]

Is Chess fixing done yet? I TETOed too much

[real sierra]

how does it for every other ffi implementation

[sage crag]

ffi backend work on .so, not .c

the structs are opaque to ffi

[rough bloom]

this works, but only if you glue half a C compiler into your language (like Rust does)

[real sierra]

so adding __attribute__((aligned(N))) and __attribute__((packed)) to Move would fix this?

for reasonable N that is

[trim valve]

that a bool was one bit

[sage crag]

one or the other

[sage crag]

a logical boolean is one bit, its true

[nocturne olive]

I spent wayyyyy too much time on this Finnish TETO thing

[trim valve]

yes but a Boolean does not take up one bit of space in any sane language as much as they tried to convince me they did 😭

[sage crag]

to argue semantics, for the language the boolean is one bit

for the platform it is not

[trim valve]

I guess, but that clearly wasn't what either of us were meaning at the time

[sage crag]

bool is typically defined (per-platform) as the minimum addressable size of the platform

[sage crag]

true true

[sage crag]

packed will ignore alignment (removes all padding bytes), and aligned(N) will set the alignment

packed is typically equivalent to aligned(1) so im not sure the reason for it existing

[rigid timber]

if the alignment is larger than some of the fields, the padding is after the actual field value, right?

[sage crag]

aligned() works on bytes and not bits so as per the c spec packed and aligned 1 should be equivalent

[sage crag]

depends on endian

[rigid timber]

well assuming little endian bc pretty sure nobody here has a big endian CPU

[real sierra]

this can be done

[sage crag]

pick one or the other though

i dont think they play nicely together

[real sierra]

will do packed

[sage crag]

ideally packed for abi compatibility

[real sierra]

simpler

[rigid timber]

yay

[sage crag]

might pessimise performance a bit but oh well

[rigid timber]

do I still have to create the issue for you to not forget?

[sage crag]

should be negligible

[rough bloom]

unaligned memory accesses

[real sierra]

if you make a PR I can approve it soon

[rigid timber]

just add a couple bytes of padding at the end of the struct

[real sierra]

otherwise will take a bit of time

[rough bloom]

manual padding

[trim valve]

I love packed

I love ub

[obsidian mantle]

a bit

[rigid timber]

packed structs have ub?

[sage crag]

program memory is typically aligned to 1 byte anyway

[trim valve]

https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked-reprpackedn

[nocturne olive]

Me when my entire array reading function explodes

[sage crag]

its defined behaviour (in c)

[real sierra]

FFI devs telling me the problems are my fault and I should add UB to the API to fix it

[sage crag]

you should use #[repr(C, packed)]

[sage crag]

no no, there's no UB in the c code

rust skill issue

[real sierra]

it joke

[trim valve]

ah

[nocturne olive]

You better not break my code ```kt
fun getLegalMoves(board: Board): Array<Move> {
val len = IntByReference()
val movesPtr = nativeBindings.chess_get_legal_moves(board.value, len)

    val moves = Array(len.value) { i ->
        val offset = i * MoveByPointer().size()
        MoveByPointer(movesPtr.share(offset.toLong())).toMove()
    }

    nativeBindings.chess_free_moves_array(movesPtr)
    return moves
}

[real sierra]

rust

[rough bloom]

a uint64 read should be 8 byte aligned, no?

[sage crag]

the reason its UB is because some cpus dont allow unaligned accesses

[rigid timber]

it will totally break your code (sorry)

[nocturne olive]

If you break it you're responsible for fixing it too

[sage crag]

sorry when i said 1 byte i actually meant 4096 byte

since that's the typical page size

[rough bloom]

[rigid timber]

send a PR that sets __attribute__((aligned(4096)))

[nocturne olive]

I was told the API was meant to be unchanging

With no breaking changes

[sage crag]

it wont impact most systems, since the os gives out aligned memory usually of the max alignment for the platform or the page size

[nocturne olive]

And changing the sizes of things in memory would definitely be a breaking change

[sage crag]

unaligned reads do can pessimise a lot, mostly on older cpus

or embedded

[nocturne olive]

Make forced alignment a compile flag disabled by default or something

[rough bloom]

I love C
it's great that it's become the standard for FFI everywhere, even though there may be no C code involved at all
truly amazing

[rigid timber]

would you rather have "unknown so anything can happen" for the size or "known but have to change the code a bit now"?

[nocturne olive]

I would like the current existing and fully functional behavior that JNA has no trouble with so make the patches optional

Compile flag or something

[rigid timber]

JNA makes the same assumptions I'm making, that it aligns to 4 bytes

[sage crag]

with typical alignment yes

[rough bloom]

I'm 99% sure that this is only true for memory given to userspace from the kernel
allocators can do whatever they want with that as long as they respect struct alignment

[nocturne olive]

I recommend making changes to the API optional and disabled by default unless you can confirm existing bindings work with them fine

[sage crag]

the biggest issue with unaligned reads is partial loads, crossing page boundaries, and crossing cache-line boundaries

which, really arent a huge issue most of the time on modern cpus

[sage crag]

userspace allocators can do whatever they want, yes.

[nocturne olive]

Anyway I need to sleep soon-ish probably, so you better not break my code in the meantime

[rigid timber]

too bad

[rough bloom]

mods, break his code

[nocturne olive]

Like really please don't break my code

[opaque sigil]

all code shall be broken

[nocturne olive]

I need my code not be broken

[sage crag]

1 + 1

[trim valve]

shiro can you make it so the struct layout is random and you have to infer it every time

[nocturne olive]

I hate dealing with raw memory access as-is so I may not have the motivation to fix memory issues

[rough bloom]

Rust has this as a feature

[trim valve]

[rough bloom]

-# or rather, the reference compiler does

[nocturne olive]

I just want to build a silly Chess bot in peace and not have to worry about my core API breaking in the middle of it

[trim valve]

idk how badly bindgen would implode

[nocturne olive]

Like if you change the memory alignment AT LEAST make it optional and disabled by default

[rigid timber]

bindgen should be fine, since it reads the C code

[trim valve]

[rigid timber]

that's the one thing that probably won't get broken

[rough bloom]

would be surprised if bindgen didn't deal with packed structs before

[rigid timber]

I mean, Shiro could "just" add manual padding to actually make it 24 bytes always

bc I'd imagine it's 24 bytes everywhere now, just not guaranteed

[rough bloom]

it should be, ye

[rigid timber]

at least it's 24 on Windows

[real sierra]

[nocturne olive]

Just please don't break my Kotlin bindings and I'll let you do whatever you want, as long as I can just compile a new SO and throw it in as-is

[opaque sigil]

worst case you have to add like 1 line for the struct's alignment

[real sierra]

I'd rather avoid breaking changes to every existing bindings just to support another, but it sounds like not specifying the alignment is a proper issue for cross-platform compatibility

so I'm willing to make a change to the C API to specify the alignment

[nocturne olive]

Make it a compile flag PLEASE

[real sierra]

let's put it this way

you don't know what alignment my system uses

or how my system will align or size this struct

[nocturne olive]

Or confirm that it works with my bindings I don't want to deal with the mess of rebuilding the bindings and redoing all that again

[real sierra]

without defining the alignment, there is zero guarantee your bindings even work on my system

[sage crag]

i am here to unfortunately announce

#define SEED ((__TIME__[6] - '0') * 10 + (__TIME__[7] - '0'))
enum { RAND_VAL = ((unsigned long long)(SEED) * 1103515245ULL + 12345ULL) & 0x7fffffffULL };

typedef struct {
    long x;
    short y;
    unsigned c;
} __attribute__((aligned(1 << (RAND_VAL % 4)))) Erm;

this works

[rigid timber]

[opaque sigil]

[trim valve]

[rigid timber]

Shiro can you ban that person, they're commiting crimes against humanity

[clear sedge]

https://tenor.com/view/spy-tf2-team-fortress2-kill-me-piemations-gif-19518641

[nocturne olive]

Well, you said a Linux system and compiled with GCC
And that is the configuration I am using so mine should be safe
Just, try to figure out a way to make it work with whatever GCC on Linux compiles which seems the most sensible

[rough bloom]

in theory you can also make all bindings that don't support inferring the struct layout from the definition (like whatever daavko is doing) invoke a C compiler to find out

[rigid timber]

nobody says GCC on one Linux system will do the same as GCC on another one

[real sierra]

if you're willing to answer the resulting hate mail

[nocturne olive]

That seems weird
But like it works with JNA so surely it's standard enough, right?

[rough bloom]

[rigid timber]

no, JNA just assumes the struct will look a certain way and it happens to work out

[nocturne olive]

Well try to make the changes make it so the assumption is guaranteed to be true since if JNA makes that assumption it can be semi-safely assumed other language bindings make the same assumption

[rigid timber]

honestly I'm surprised nobody brought it up earlier

[nocturne olive]

Just don't break my bindings I don't want to deal with them any more I just want to make a Chess bot

[olive sable]

[rough bloom]

for most bindings it doesn't matter because they just follow whatever GCC and LLVM do
but if your languages FFI doesn't do that for some reason then yeah, it's an issue

[rigid timber]

I mean, it probably does, but I wouldn't know

[nocturne olive]

I don't know, just make sure it works with all the existing bindings

Don't break stuff for no reason

If you can avoid breaking stuff, then do so

[rough bloom]

I don't think I've ever really looked at JS bindings to C APIs

it's JS though, so surely there's a way

[rigid snow]

fyi bun ffi embeds tcc

[nocturne olive]

Anyway as usual I'm extremely stressed by changes that may break my stuff

[rigid snow]

and uses that for bindings

[rigid timber]

Deno specifcally, JS has no specific standard for FFI

[rigid timber]

yeah, and it doesn't do structs at all at this time

[nocturne olive]

So if you could just confirm you'll try to not break things I would be satisfied and could sleep

[rigid snow]

compat wise definitely go with node bindings but they're a pita

[safe path]

holy shit doom emacs is so much easier to use than whatever I had going on with my config

[rigid snow]

i mentioned that here before yeah

[real sierra]

the changes should be minimal, and if you aren't doing anything that relies on the particulars of the move struct layout it should be okay

[nocturne olive]

Well my code relies on its size

And probably anything else that reads the moves array

[olive sable]

if you're cold, they're cold, put them in the chess api

[real sierra]

it's necessary to ensure that bindings will work the same on all platforms, and thus that they'll work on my system

if your system happens to work the same as mine already then it probably won't affect anything

if it does affect something then your bindings would've broken on my system

that's my understanding

[nocturne olive]

Well since everyone's bindings so far seem to work fine make the changes reflect what is happening with the bindings now rather thann doing something that breaks things

[real sierra]

I'm not trying to make changes that break things that should obviously not be the goal

[rigid snow]

since they usually use a helper lib for conversion of types, many runtimes implement that and support them

regardless if it’s v8 or not

[nocturne olive]

Well I may just be paranoid, I do not want to deal with more memory issues

[sage crag]

need to make a bindings generator

:mhm:

[opaque sigil]

diff --git a/src/main/kotlin/MoveByPointer.kt b/src/main/kotlin/MoveByPointer.kt
index 8513792..9e0e346 100644
--- a/src/main/kotlin/MoveByPointer.kt
+++ b/src/main/kotlin/MoveByPointer.kt
@@ -16,6 +16,10 @@ open class MoveByPointer() : Structure() {
     @JvmField
     var castle: Byte = 0
 
+    init {
+        setAlignType(ALIGN_NONE)
+    }
+
     fun toMove(): Move = Move(this)
 
     override fun toString() = "Move(from=${from}, to=${to}, promotion=${promotion}, capture=$capture, castle=$castle)"

here, problem solved

[rigid snow]

chatgpt

[nocturne olive]

I don't want to recompile for a change in the API preferably, so could you maybe instead align to what is expected by default on the API side?

[sage crag]

we just had this conversation

not possible

[nocturne olive]

What do you MEAN not possible?

[sage crag]

FFI uses .so or .dll

struct information only exists in the .c file

[rigid snow]

yeah, it has to be reflected in the consumer code

[rough bloom]

adding manual padding to make the size 24 bytes again should keep existing bindings (mostly) working on x64 Windows and Linux and would avoid any performance impact from unaligned reads
small downside is that it will probably break elsewhere unless bindings are adjusted to match the new definition in the C header but who cares

[opaque sigil]

at that point just remove the alignment

[sage crag]

it will not avoid performance impact of unaligned reads because

[opaque sigil]

the speed difference is negligible at best

[nocturne olive]

Well removing the alignment would 100% break stuff

[sage crag]

the padding will also be unaligned

[rigid snow]

are we talking about the move struct

[rigid timber]

yes

that's the only struct that any of the bots can actually interact with

everything else is behind pointers

[rigid snow]

yeah it’s in an array if you change that you should pad

[rough bloom]

the issue is that just removing the alignment actually does break stuff for existing bindings

[real sierra]

well I'll let you all figure out how you want it to be fixed given you, the bindings maintainers, are the main stakeholders here

[nocturne olive]

Yeah, the one annoyance that annoys binding makers

[rough bloom]

the performance stuff is just a bonus

[rigid timber]

I mean it's either breaking some of the bindings now, breaking some of the other bindings now, or maybe breaking some of the bindings during the actual tournament...

[rough bloom]

just keep the paddings uninitialized, how hard can it be

[real sierra]

performance impacts from changing the move struct are unimportant given it applies to every API user

ultimately, the move struct being a byte or two larger is not going to be what makes your bot win or lose

so don't worry about performance

[rigid timber]

but I need every nanosecond

[real sierra]

compatibility is the key issue here

[sage crag]

the move struct should actually get smaller

[nocturne olive]

Well yeah it's a difference of the bot running or crashing

[sage crag]

just update the bindings with the appropriate alignment of (1 or no alignment)

[opaque sigil]

if you're going to break anyone's code go break everyone's at least

[nocturne olive]

I don't want to have to deal with that any more

[rigid timber]

alignment to 8 bytes

[nocturne olive]

I just want my code to work

[sage crag]

write bindings also requires maintain bindings

ultimately only you are affected if you dont want to update them

[nocturne olive]

Well I expect the API I was told would not change, to not change and explode things, an avoidable breaking change is dumb

[opaque sigil]

do you depend on the actual size anywhere explicitly because from what i saw going through the kotlin bindings it's all up to jna to figure out

which requires exactly one line to be added

[rough bloom]

it's more specific, manually adding padding breaks only some bindings on only some platforms
but ye, things will break regardless

[opaque sigil]

or 3 with some nicer formatting

[nocturne olive]

Well this is the cloests

[nocturne olive]

AND way too much compiling and removing and replacing files

And restarting stuff

I hate restarting stuff

[sage crag]

class FFIStruct : Structure(Structure.ALIGN_NONE) {
  ...
}

[trim valve]

note to self, do not unprivate the repo that leaks both my school and my home coordinates down to the meter

[sage crag]

or something

[opaque sigil]

this is provided by jna so it's a non-issue

[opaque sigil]

actually good point, even better than what i had

[nocturne olive]

Well then simply make it be what JNA thinks it is

[final tinsel]

._.

[nocturne olive]

Why remove alignment when you can just make the alignment consistent instead?

[rigid timber]

what JNA thinks is also platform-dependent

[opaque sigil]

jna thinks nothing

it just uses whatever alignment you give it

[sage crag]

removing alignment is making alignment consistent

[rough bloom]

sorry to say, but JNA is not the only consumer of the C API in existence
also "what JNA thinks" is not exactly well defined

[nocturne olive]

Well it's a bad way because it breaks everything

[opaque sigil]

diff --git a/src/main/kotlin/MoveByPointer.kt b/src/main/kotlin/MoveByPointer.kt
index 8513792..3640110 100644
--- a/src/main/kotlin/MoveByPointer.kt
+++ b/src/main/kotlin/MoveByPointer.kt
@@ -4,7 +4,7 @@ import com.sun.jna.Pointer
 import com.sun.jna.Structure
 
 @Structure.FieldOrder("from", "to", "promotion", "capture", "castle")
-open class MoveByPointer() : Structure() {
+open class MoveByPointer() : Structure(Structure.ALIGN_NONE) {
     @JvmField
     var from: Long = 0
     @JvmField

new diff, there you go

[sage crag]

no, it prevents random breakages in the future

for one breakage now

that is easily fixed

[nocturne olive]

I just hate dealing with these kinds of things when I just want to have fun and make a Chess bot

[real sierra]

everyone does, but not adding this change means some of those bots could fail to run in the final tournament when submitted if the bindings only work on specific platforms

[sage crag]

am i wrong for saying dont write bindings if you dont want to maintain them

[real sierra]

that's the risk this change would address

[nocturne olive]

I did not sign up for stressing out about memory alignment

[trim valve]

then don't stress about it??????????

[sage crag]

you dont need to

you change one (1) line

and be done

[nocturne olive]

Well then keep the memory alignment

[trim valve]

everyone here seems to be suggesting you need to make a one line change

[nocturne olive]

So I don't need to stress about it

[trim valve]

that is not stress worthy

[sage crag]

❓

[nocturne olive]

I don't even know any more, I'm too tired for this mess and dealing with more versioning mess

[sage crag]

are the bindings public? can someone just submit a PR?

[nocturne olive]

Updating this stuff is a whole massive process that is a worthy competitor to the post-karaoke sync

[trim valve]

what

[sage crag]

what, git pull?

[trim valve]

post-karaoke sync literally is one shell script for me

[real sierra]

I think people here would be very happy to help with changes if they do end up being needed

[rough bloom]

toast literally already posted the diff
you need to do practically no work for your bindings to continue functioning, this is not a huge change

[nocturne olive]

Yes, but that won't magically compile them, recompile 12 bots of which 9 I no longer even have the code for with the new bindings, submit a new release with the recompiled code and restart my IDE

[sage crag]

why would you need to recompile 12 bots

you only need to recompile the bot you are working on

[nocturne olive]

Because that's how many I have made?

[sage crag]

and they are prototypes yes?

[nocturne olive]

Most but I like to compare them

Like if MK1 ver10 can beat MK1 ver 8

[sage crag]

ok so, you made the issue

[final tinsel]

is it even programming if you arent making more issues for yourself?

[rough bloom]

certified spacebar heating moment

[nocturne olive]

I don't know, manually going in and replacing the bindings related class files seems like a massive pain

[sage crag]

one (one) file

[nocturne olive]

No

[sage crag]

one (one) line in fact

[nocturne olive]

At least 9 * classFileCountInCompiledBindings files

Manually replaced in JAR files which is also fiddly

[real sierra]

I think super box is saying the old bots are jar files right now, and they don't have the source code that built them, so they would need to modify the jar contents directly

[nocturne olive]

YES

[sage crag]

yeah but, those bots wont be any different

you dont need to recompile it

just keep two versions of the bindings

[real sierra]

unless the .so is built in

[sage crag]

no, if the .so is built in that's even better

[nocturne olive]

I do if I want them to work with the upcoming new fixes

Like the fix to the castling bug

[sage crag]

can i ask why you dont have the source code

[nocturne olive]

Because I made changes to make a new version

[sage crag]

if you used version control this wouldnt be an issue

[nocturne olive]

Ver10 is built on Ver9 is built on Ver8 and so on

[nocturne olive]

And you expect me to use that for a fun project? I only use it for big serious projects

[sage crag]

uhh yeah kinda

[rough bloom]

Git for everything

[sage crag]

no vcs => lose code

[nocturne olive]

If you change the bindings that will be a massive pain

[sage crag]

its a pain you caused yourself though

[real sierra]

I hate git too but always a good idea to keep a copy of code you still use

I just copy to another file

[nocturne olive]

Well how could I know the bindings I was told WILL NOT CHANGE would change

[sage crag]

its a hobby chess tournament, there are no guarantees

[rough bloom]

if you don't care about Git and proper version control then at least regularly copy the folder
it won't give you branches and commits and all the good stuff but at least you have a version history
-# I do both

[sage crag]

i dont know who said the bindings couldnt or wouldnt change, but that does seem like a strong assertion to make considering bug history

[real sierra]

I apologise for changes, certainly I've worked to minimize any changes required to the chess API

but I will note that this is a change to the header file

[nocturne olive]

Shiro when I was making the bindings and was told anything in the chessapi.h would not be changed

[sage crag]

well shiro was wrong

stable bindings dont exist

[trim valve]

did shiro know alignment was a thing (to consider) at that point

[sage crag]

shiro certainly did not foresee such an issue, otherwise it would have been fixed at the time when the bindings were made

[real sierra]

the intention is to make as few breaking changes to the .c and .h files as possible

[rough bloom]

should've explicitly defined the memory layout of all structures in a separate document smh /s

[real sierra]

but ultimately this is my first time doing something like this and planning ahead for the variety of issues that supporting every language and platform entails is rather challenging

[opaque sigil]

this is why you have an rfc process

[sage crag]

there's a reason semver dictates that before version 1.0.0, any breaking change is allowed

[nocturne olive]

Well try to keep the alignment change as non-breaking as possible then, try to keep the alignment the same as whatever it most likely is now and hopefully it works for most bindings
Those that it doesn't work for fix it, those that it does carry on

[real sierra]

this is why a change log exists on the GitHub repo, in the front page readme, to document these major changes

[sage crag]

er no

[nocturne olive]

Why no???

Shiro just said as few breaking changes as possible

[sage crag]

yes, this is a pretty important change

forcing the struct to be packed will reduce the amount of work for everyone else and reduce the chance that it breaks when shiro has to compile it

[real sierra]

I'm open to other suggestions to resolve this but ultimately the Move struct needs to be well-defined cross-platform

[rough bloom]

this is just not really how it works

keep the alignment the same as whatever it most likely is now
the current alignment and struct layout is not well defined, there's not really a way to keep it

[sage crag]

unfortunately this is the only solution that works universally

[nocturne olive]

Well I would think the safest option would be aligned to 8 bytes

[real sierra]

there's plenty chance that this change doesn't break existing bindings

[opaque sigil]

you end up with broken bindings in that case too

[real sierra]

and if it does, it should be a very easy fix

[opaque sigil]

if you hardcode it to 8 bytes

[sage crag]

very unlikely it doesnt break existing bindings

[real sierra]

oh really?

[sage crag]

yes, but the fix is a 1 line change

[trim valve]

I can test the rust bindings if you want shiro

[nocturne olive]

And hours of pain and suffering to replace files in files

[real sierra]

I would've thought many systems would assume the packed size anyway, or if bindings use an FFI library that the library would just infer the field locations anyway

[nocturne olive]

I would guess most systems assume 8-byte aligned size

[sage crag]

im going to be evil

just dont do that?

[nocturne olive]

I need to though, if I want updates to the API that fix broken stuff

[sage crag]

ultimately you lost the source code anyway so you cant submit that bot to begin with

since you can only submit source code and not compiled files

[nocturne olive]

Well I use those bots as test cases to see if I'm improving or getting worse

[rough bloom]

if bindings use an FFI library then they very likely just assume whatever C does by default, not the packed representation
that's why it works in the existing bindings already

[sage crag]

you can still do that though, your existing bots dont change behaviour

[opaque sigil]

if they end up being worse you don't need them and if they end up better you can't submit them anyway

[sage crag]

you dont need to replace them or their bindings

[nocturne olive]

I don't even know any more, it's just a massive pain to deal with all this

I really need sleep

[real sierra]

so will this break bindings using those libraries?

will python ctypes for example no longer work as documented

[sage crag]

yes, with 1 line fix

[opaque sigil]

realistically changing it to packed will break all bindings

[rough bloom]

yes, that's the whole issue here
everyone needs to specify packed representation to match the C header

[real sierra]

[sage crag]

https://runebook.dev/en/articles/python/library/ctypes/ctypes.Structure._pack_

i think this is ai generated, this is garbage

[rigid timber]

it reads really strange

[sage crag]

iirc its just a 1 line change

class FFIStruct(Structure):
  _pack_ = 1
  _fields_ = [...]

[trim valve]

concerning lack of packed from bindgen

wait this is almost certainly a skill issue

[sage crag]

attribute packed comes after struct definition

[trim valve]

yeah I realised

thanks google

[sage crag]

typedef struct {
  uint8_t field;
} __attribute__((packed)) Erm;

[nocturne olive]

Pain

[rough bloom]

initialization dependent on field order
Python my beloved

[trim valve]

[rigid timber]

fwiw, sorry for breaking everyone's bindings by bringing up the alignment issue

[trim valve]

thank you C for letting me put __atribute__ somewhere meaningless and still compiling, very cool

[nocturne olive]

I hate whoever did that now and especially whoever decided packed was the best option rather than explicitly aligned

That's gonna cause me so much pain

[opaque sigil]

packed is explicitly aligned

[sage crag]

• you lost your source code files, all you have is compiled bots
• you cant submit them because they are precompiled
• you can only use them for testing
• after bindings change, you can still use them for testing, as long as you dont update their bindings
• you wont get bugfixes, but you dont have the source code, so frankly it's your own mistake, sorry.

[nocturne olive]

So annnoyinng
I'm too tired to deal with this this took 1 hour of my meant to be sleep time

[sage crag]

you dont have to deal with it right now?

[nocturne olive]

I was way too stressed about things breaking to go to sleep, that's the main issue

[sage crag]

[nocturne olive]

So especially with me being tired I think I exceptionally hyperfocused on making things stay compatible

[sage crag]

[opaque sigil]

is there even anything stopping you from just using the old version with your old bots and use the new one moving forward?

am i missing something

[sage crag]

exactly what i said

[opaque sigil]

you only need the .so don't you

[sage crag]

yup

[rough bloom]

no you're not missing anything, this is possible

[sage crag]

[nocturne olive]

The castling bug I want fixed?

I don't want random broken castling moves breaking my results

[sage crag]

should have kept the source code then

im sorry that i lack pity

[cosmic sphinx]

i would praise anyone if they had a LLM that could play chess without hallucinating position past move 20

[rough bloom]

your old bots are already broken, they just stay broken

[sage crag]

[nocturne olive]

I don't even kknow any more, I just need to sleep or something

[opaque sigil]

couldn't you also keep the old header and use the new fixed c implementation

[sage crag]

yes literally

[opaque sigil]

unless shiro does some really cursed stuff inside there

[sage crag]

there are literally 0 problems

[rough bloom]

would result in a slightly funny version of the chess API library but yes that would work too

[stark needle]

Shiro current situation

[rough bloom]

worst case you can rebuild the newest version of the library with just the packed representation for Move reverted

[olive sable]

imma sleep

goodnight

[stark needle]

Gn

[sage crag]

is that a single pawn

shiro is in a losing position

[nocturne olive]

At this point I may just do that eventually I don't want to deal with replacing files in a jar file
Alright now sleep for real surely maybe

[stark needle]

Yes

[final tinsel]

man brotli compression suuuuuuuucks

[real sierra]

🫸 ♟️

[sage crag]

are you compressing with good settings

brotli i found was comparable or better than zstd and lzma for packed binary data when i was testing

[final tinsel]

its for hyperspectral image compression

[stark needle]

Shiros 1500 elo bot will carry the pawn trust

[sage crag]

1500 elo is a strong term

[real sierra]

one too many 0s

[rough bloom]

isn't brotli the one meant for web stuff

[sage crag]

you would do better with a dedicated image compression algorithm

[sage crag]

brotli is google's compression

[rough bloom]

they have multiple for different purposes

[sage crag]

yup

[final tinsel]

oh totally, but UNP wants us to test however many different compression algorithms, make a decision matrix, and justify our choice.

we are pretty sure we are gna use bzip2 tbh

[sage crag]

you tried zstd?

[rigid timber]

is there something other than cutechess that can find things that exist?

[final tinsel]

not yet, just trying to basically verify that the benchmark util works before we do higher loop numbers

[sage crag]

my first choices are typically

• zstd,
• lzma,
• xz,
• bzip2,
• gzip,
• and brotli

[opaque sigil]

zstd my beloved

[sage crag]

you will need to care to set the correct compresion parameters for each compression

they use different numbers and it can be confusing

[sage crag]

you need to pack it into an executable

[rough bloom]

✅ zstd best

[sage crag]

depends on your data

[real sierra]

i do wanna quickly confirm

[rigid timber]

deno.exe is an executable

[sage crag]

ive had both lzma and brotli outperform it on packed data

[rough bloom]

unless you need giga compression and can accept slow decompression, then mabe lzma or xz

[real sierra]

packed will for sure fix the alignment issue?

[sage crag]

yes but this is the wrong way of doing it

[sage crag]

yes

[real sierra]

there's nothing implementation-specific about it?

and is it needed on the enums as well

[sage crag]

shouldnt be

[rigid timber]

what's wrong about running an exe with arguments?

[real sierra]

enums are just a typedef and constants so i doubt it's needed but

[sage crag]

nope, c encodes all enums as 32 bits unless you specify otherwise

[real sierra]

[sage crag]

because the arguments are being considered part of the path

[rigid timber]

bruh

that's more than a little stupid from cutechess, ngl

[sage crag]

that's how that typically works

[final tinsel]

we ideally want time efficient, space efficient, and power efficient- but we know getting all 3 is unlikely. we also need it to be reliable, as this is for a satellite

[sage crag]

all 3 is impossible

[final tinsel]

yeaaa

[sage crag]

time efficient is the same thing as power efficient for most machines

space efficiency is inversely proportional to time efficiency

[rough bloom]

integer and pointer sizes are still implementation-specific I think but for Move in particular there shouldn't be an issue
packed fixes the only the alignment issue but everything else is already be taken care of, surely
so as a result the struct layout should be the same everywhere

[final tinsel]

time efficiency is likely what we'd be able to sacrifice most on as we could allow it to compress for longer while we arent in our downlink period

[rough bloom]

LZMA I understand but brotli is surprising to me

[sage crag]

i would recommend defining your enums with a specific integer though

[sage crag]

like this

typedef enum : uint8_t {
  variant
} CoolEnum;

[real sierra]

thats possible?

[sage crag]

yes

[real sierra]

im learning so much about C

that shouldn't break anything right

at least to my knowledge

[sage crag]

brotli is competitive from my testing one very specific set of data

[sage crag]

if you set it to uint32_t then yes it should be fine

[real sierra]

ill just do that then

[final tinsel]

Compressor,Image specs (res/bands/depth),Iterations,Compress time total (us),Compress time min (us),Compress time max (us),Compress time mean (us),Compress time std dev (us),Original size (B),Compressed size min (B),Compressed size max (B),Compressed size mean (B),Compressed size std dev (B)
brotli,2048x1088/96/10,1,768889350.000,768889350.000,768889350.000,768889350.000,0.000,427819008,215436765,215436765,215436765.000,0.000``` 50% size reduction, dang!

[rigid timber]

well, got it to work through a batch file... still stupid, but at least it does random moves now

[sage crag]

i recommend it

just so ffi struggles less

i think its less common to be able to set the backing integer of enums in ffi

ctypes and rust both have that capability but others im not sure

[trim valve]

please tell me I am reading the compress time total wrong

[final tinsel]

no. no you are not.

[trim valve]

[final tinsel]

it did take 12.8 mins.

[sage crag]

12.8148 minutes

[rigid timber]

nerd

[final tinsel]

im sending the results to Space Software Dad so he can get that in the sheet but yea

[sage crag]

phrrr

[final tinsel]

he says, in the programming channel

[rigid timber]

after inciting an hour long discussion about struct alignment because he wanted to make JS bindings

which work btw

[opaque sigil]

v8 bindings?

[rigid timber]

Deno

but it's v8 under the hood so... yeah

[sage crag]

nice try

[opaque sigil]

i'll take that as a yes

[sage crag]

https://cdn.discordapp.com/emojis/1276149117717970964.gif?quality=lossless&name=nopy&size=64

[rigid snow]

3^2

[sage crag]

9 == 8

proof by chatter

[final tinsel]

-# edited

it said 9 when i typed it

[opaque sigil]

[sage crag]

[rigid snow]

v9 engine

[sage crag]

[final tinsel]

[rigid snow]

powering the all new chromium 2

[final tinsel]

holy cheeto hair evil

[sage crag]

ye dipped in dust

[final tinsel]

welp imma head out now, ttyall later

[sage crag]

whenever i come here i lose years off my life due to stress of communicating with programmers

[jagged turtle]

[final tinsel]

(hi its me programmers)

[trim valve]

don't worry

think about how many you gain by writing hblang

[sage crag]

0

[trim valve]

and therefore making the gods of ableos happy

[sage crag]

[trim valve]

at least zero is not losing

[real sierra]

i come here and feel underqualified

[rigid snow]

?

[sage crag]

well, most people here arent either

it's A
actually it's B
actually you're all wrong it's C

nope answer was 92

[rigid snow]

i am just starting out after all ...

[jagged turtle]

maybe those solutions work but let me introduce you to D

[real sierra]

week ago

[rigid snow]

i hav 2gb ram

[sage crag]

confidently incorrect or being obstinate or having an issue that only exists for one person

or speaking to a lion only for the lion to eat your face off

programmers

[real sierra]

my issues are usually me not knowing convenient language features or not wanting to obey best practices for hobbyist test code

[sage crag]

best practices are subjective and i will kill you if you dont follow my advice to exact letter

[rigid snow]

chessapi doesn't compile for me at night when using my dad's handrolled c compiler he wrote 35 years ago after your recent change. i demand it be rolled back

[sage crag]

btw i dont have the compiler source code my dad left the binary to me in his will

[trim valve]

the chessapi doesn't compile for my stm32, please rewrite the entire stdlib

it is the only way

[jagged turtle]

hobbyist test code best practices is do what you want unless you like reading

[rigid snow]

i started porting semicolons bf interpreter to rp2040 but i just forgot i was doing that one day

[sage crag]

chess api and cutechess failed to run on my breadboard with custom riscv cluster compute unit

please patch

[trim valve]

shiro why doesn't this run on my capacitor

please fix

[real sierra]

the unspoken cost is that you can never get help with bugs because people will get lost on 2 hour tangents about how you should rewrite the entire codebase

[sage crag]

shiro the api doesnt support sending chess moves via light rays

[rigid snow]

capacitor no run capacitor dumb

stupid

[sage crag]

my cpu doesnt have any electrons only photons

please help

[real sierra]

qubits will not be supported by the chessapi

[sage crag]

quantum computers are too busted for chess anyway

[trim valve]

shrioooo can you restructure the entire api to be SOA instead of AOS so it plays 1% more nicely with simd

[sage crag]

chess is one of the problems that qc is very good for

[real sierra]

simd

[sage crag]

the most cmd shiro has in chess api is

[trim valve]

how are you gonna enforce the no simd rule

[real sierra]

i look at your code and if it spawns a thread then you die

[sage crag]

i thought the rule was no multiprocessing

[trim valve]

simd is not threads

[rigid snow]

what

[sage crag]

simd is not threads

[rigid snow]

shiro

[trim valve]

konii i said that

tax

[sage crag]

well i said it slower so it has more weight

[real sierra]

the actual wording of the rule is

... or otherwise run code in the background/in parallel ...

so no simd

[trim valve]

shiro am I banned from using bitboards

[sage crag]

technically simd isnt running code in parallel its just one instruction

[real sierra]

bitboards are legal

[trim valve]

because I am accessing each position in the board in parallel

[rigid snow]

NO CODE PARALLEL simd first two letter "single instruction"

[rough bloom]

simd does not require running code in parallel
it only processes data in parallel

[sage crag]

(multiple data)

[real sierra]

are you doing simd on the cpu

[trim valve]

what

[real sierra]

if its on the gpu thats parallel to the cpu code

[sage crag]

yes thats what simd is

[rigid snow]

[trim valve]

instructions must be no longer than 4 characters long

[rigid timber]

what if the gpu call was blocking

[sage crag]

gpu compute is also simd-like to be fair

gpu compute is actually simt though

[rigid timber]

also what do I name my bot...

[sage crag]

bot bot

[real sierra]

how are you planning to make gpu calls in 1024 tokens with stdlib only anyway

[sage crag]

there will be no gpu calls

[rigid timber]

well Deno has a large stdlib...

[trim valve]

eitherway shiro I think you fundamentally misunderstand what simd is

[rigid timber]

I wonder if there's webgpu stuff in Deno...

[rigid snow]

there is no fucking way you just typed that out too but beat me to pressing enter

[sage crag]

simd => perform instruction on wide register

[real sierra]

i know what simd is im just trying to make a point that its not allowed

[sage crag]

[trim valve]

but why

[real sierra]

stop beating me up for semantics wins

i dont wanna make the rules longer over a silly clarification

[trim valve]

what if I coarce the compiler into autovectorization

is that suddenly simd and banned

[rigid snow]

i agree simd is perfectly legal by this definition

[sage crag]

no no as the rules currently are simd is allowed

not as like, a semantic thing

but because simd is literally the same as regular execution

[rigid timber]

oh hey, Deno has @std/webgpu

[sage crag]

except with larger numbers

[real sierra]

ah ok i was thinking gpu simd only

[trim valve]

[sage crag]

gpu is simt

[real sierra]

well yeah then on cpu its fine

[trim valve]

time to force target-feature=+popcnt for the execution time savings

[sage crag]

simd just mean "single instruction multiple data", as in, its an instruction that executes on larger cpu registers than 64 bits

[real sierra]

programmers thinking tiny performance gains will decide the winner

[rigid timber]

just target x86-64-v3

[real sierra]

surely your algorithmic complexity isnt vastly more important

[rigid snow]

thank you for keeping NNs viable. this certainly will be fun

[sage crag]

simd is actually a huge difference though

[opaque sigil]

yeah in terms of tokens