<tankf33der>
abu[7]: how brutal and hard to make a rpc-json call to daemon on picolisp without calling curl?
<beneroth>
good morning tankf33der o/
<beneroth>
http request is rather easy, the hard part is TLS
<beneroth>
might be possible with bin/ssl? not sure
<tankf33der>
ah
<tankf33der>
I forgot about ssl
<beneroth>
yeah a (native) TLS/SSL client in picolisp would be nice :)
<beneroth>
btw. stunnel could also be used
<tankf33der>
I think i can disable ssl, this is monero rpc wallet daemon. I would like to test it on picolisp
<abu[7]>
Yeah, I would try @bin/ssl first
<abu[7]>
RPC via JSon should not be so difficult
geri` has joined #picolisp
geri has quit [Ping timeout: 260 seconds]
beneroth has quit [Ping timeout: 248 seconds]
beneroth has joined #picolisp
<taleon>
Probably something like HAProxy would be useful to put in front of it. That can then also do SNI etc.
<taleon>
On OpenBSD, I use relayd(8) for this, since it is already integrated in the base system.
<taleon>
A native implementation in PicoLisp would of course be a dream, although the chain of trust would then also have to be guaranteed, and implementing that is probably not trivial.
<beneroth>
in the above discussion I assumed that picolisp should be the client - but you're right, tankf33der stated picolisp should offer the daemon
<beneroth>
for HTTPS server picolisp comes with httpGate, which does HTTPS termination and starting picolisp worker processes as needed
<beneroth>
or any reverse-proxy can be used (HAProxy, nginx, ...) (might need adaption of session handling & worker processes in picolisp)
<beneroth>
I have setups with either httpGate or nginx
<taleon>
Yes, using a proxy is probably the most elegant solution. You don't have to reinvent the wheel and the proxies are already battle-tested and you can extend a proxy to all possible services and ports.
<taleon>
I have no experience with httpGate in terms of security, performance and flexibility. In terms of code, httpGate.c is quite straightforward.
<beneroth>
performance is good, as it doesn't do much as you can see in the code.
<beneroth>
if you configure another proxy to also deliver static files, maybe after checking permissions with a request to the picolisp app, that might be something a mainstream webserver might do better than httpGate+picolisp-app, as those webservers also have compression and various caching schemes (e.g. ETag) implemented out of the box
<beneroth>
but as always - it depends
<beneroth>
if you don't have many bigger static files, that doesn't make a difference
<beneroth>
if you have a database-heavy business application for a few hundert concurrent users (one typical picolisp use case), then httpGate + standard picolisp httpserver + form.l-GUI with one process per session will bring the best database caching
<beneroth>
something easily ruined if you do a naive approach of proxy + your own forking picolisp webserver
<taleon>
I host an ancient browser game on my server, which consists of over 1 million lines of PHP code and over 10k lines of C++ code for the service. I would like to migrate it to PicoLisp bit by bit, even if it's just for testing. The number of active users is only a few hundred players now, but it would be nice if the service could handle a few thousand players.
<taleon>
I know this is an ambitious undertaking, but I can't get through the PHP code anymore and I've tried in vain to migrate to a current PHP version because a bunch of 3rd-party code is included that is now legacy and no longer maintained.
<beneroth>
that is certainly possible, but might require you to roll your own webserver implementation, or at least not using the standard one not like in a business application but more like in the wiki
<beneroth>
yeah PHP is horrible :)
<beneroth>
how is the C++ codebase?
<beneroth>
did you write the game or something you inherited?
<taleon>
I'm not allowed to tell anyone, but currently it's going like this: OpenBSD->VMM->Alpine Linux->Docker->Ubuntu 14 with PHP 5. The whole thing is hardened with various security measures against outside access. It's running stable, but I'd like to run it directly on hardware.
<beneroth>
the standard picolisp webserver (included in the distro) also has server-sent events (SSE), but no web socket support. But we had people doing web sockets with picolisp.
<beneroth>
oh I still host PHP 5 stuff for clients
<taleon>
The code base is already 20 years old and I took over the code a few years ago to save the game from death.
<beneroth>
it's not ideal but not so problematic as it might sound
<beneroth>
cool :)
<taleon>
https://demonlords.de/ It's an old German browser game. I just grew up with it and I like the people there. :-)
<beneroth>
why the Ubunut within Docker within Apline and not directly as VM on OpenBSD?
<beneroth>
yeah Germany was once the leader in browser games :))
<beneroth>
I remember well
<beneroth>
I don't think I ever played demonlords
<taleon>
I can't get Ubuntu 14 to run in VMM and QEMU wasn't performant enough.
<beneroth>
btw. taleon just FYI this channel gets logged an archived (it's in the subject .. whitequark.org) just you are aware ;)
<beneroth>
taleon, ah I see
<taleon>
It's not secret, so it's okay that it's being logged. This is a bit off topic. But I just wanted to say that my long-term plans are to migrate to PicoLisp. I just lack the skills and the time. :-)
<beneroth>
I lack the time, but I'm happy to help insofar as I can (timewise)
<beneroth>
I came into programming through gaming and wanted to make my own browsergame(s) but came never around to do it for one reason or another ^^
<beneroth>
I went once to the browsergame conference in Frankfurt (organized by a lawyer). It was funny - all the big ones showed up, except GameForge (the biggest besides BigPoint).. later there was a presentation from the guys behind Die Stämme, and then it was clear why GameForge didn't show up.. the Die Stämme guys presented a talk about how GameForce lincensed their game for France but didn't maintain it very well, so they bought the license back fro
<beneroth>
m GameForge, and GameForge made a clone with even most assets stolen and probably code from the Die Stämme game
<taleon>
Yes, it was similar for me. I started programming on the C64. I was never really interested in games and I quickly lost interest, but I was fascinated by the cracktros. I wanted to do something like that too and so I started learning assembly language and at some point I ended up in the so-called demoscene.
<beneroth>
I don't know what the eventual outcome was of the legal struggle that came from this
<beneroth>
ah I see
<beneroth>
so you're probably like 10 years older than me, estimated xD
<taleon>
I also remember Gameforge. They used to have an office in our building. AOL used to be in there too, with all their servers.
<beneroth>
btw. about off-topic: usually no problem here, as long no one complains and no picolisp questions are asked by others at the same time. We're a pretty unusual community (and we like it that way)
<beneroth>
yeah Gameforge was huge. Still exists. They made Ogame originally
<taleon>
You are only as old as you feel. :-) And I started programming at the age of 10 on the C64. I was lucky that my parents were open-minded and bought me a computer at that age.
<beneroth>
yeah I didn't have my own personal computer when I started IT education xD
<beneroth>
I started relatively late with 16
<beneroth>
what database does your game currently use?
<taleon>
MySQL
<beneroth>
I see
<beneroth>
depending on the nature of the data, pilDB can be quite an optimization I'd think.
<taleon>
Or rather, mariaDB, which runs on the host system.
<beneroth>
I've found pilDB just perfect for "graph-like" data, and game data is usually not very accounting-like (for which relational database are more optimized for)
<taleon>
I would like to run all active game data in RAM and not perform dozens of database queries for each action. Only changes should be saved in the database. At least that's my idea.
<beneroth>
and that picolisp has no separation between database layer and application layer, as database objects are first citizens (just a persistent type of symbols, on top using the picolisp OOP plus additional scheme and transaction checkings)
<beneroth>
yeah that would work well with pilDb
<taleon>
Great :-)
<beneroth>
everything gets cached in RAM and updated (cache invalidated) when the data changes (emptied from RAM, and processes fetch it anew from database files if they need the data)
<abu[7]>
:)
<taleon>
My idea was also to provide a pure API server that delivers JSON. This way, clients can be written in any language, as long as they adhere to the API. Possibly also http, that remains to be considered.
<beneroth>
JSON API use HTTP as transfer protocol, so to say
<beneroth>
but yeah, certainly possible
<taleon>
I meant httpd. So a real web server. :-)
<beneroth>
of course it's a major rewrite, not a refactoring but a complete new implementation you plan there :D
<taleon>
That's right, but all the formulas are already there, which hopefully makes it easier.
<beneroth>
yeah sure
<beneroth>
and assets (images etc.)
<taleon>
And the balancing and ecosystem has also been optimized over the years. That's usually the hardest part.
<beneroth>
that's probably the main reason I never invested further into doing my own game.. the backend part can be achieved faster/with less resources with smart programming and smart tech, but assets, texts, formulas - a lot of content which is needed for most types of games, and that cannot be easily scaled just with being clever
<taleon>
Yes, that's right. Graphics are another thing that still needs to be tackled. It's just a long-term project until retirement and beyond. :-)
<beneroth>
(maybe now with GenAI, but well..)
<taleon>
In the old days, I pixelated a lot of graphics and also worked with advertising graphics for our company. I am familiar with Inkscape, Blender and Gimp. However, it's all quite time-consuming and I'm probably rusty. That's why I found the idea of a pure API server quite charming. Then others can take care of the clients and graphics. :-)
<beneroth>
hehe, yeah that's the same idea I had
<beneroth>
I have a notebook full of ideas for a game, a kind of mix of a strategy browsergame and MMORPG, and the plan to do it implement it as backend and in a way that cheating is mostly impossible and the clients can be FOSS
<beneroth>
but so far I'm busy with business projects and not lot of free time for something like that
<beneroth>
game business also changed a lot. I think it's way more risky now doing it for income, alone with the discovery problem
<beneroth>
Nistur is in the game industry, afaik.
<taleon>
Yes, you only work with something like this if you either have a financial interest in it or it's a hobby and your heart is in it. :-)
<beneroth>
I didn't dox him that far, or it wasn't online back then :P
<taleon>
Anyway, nice pixel graphics.
<taleon>
Ah ok :)
<beneroth>
I can help you with pilDB and also custom webserver implementations. So just come here and ask :)
<beneroth>
abu[7] and tankf33der can help you with algorithm optimization and/or best implementation of your formulas
<abu[7]>
yep
<taleon>
Wow, thank you so much for your offers of help. You can be sure that I will ask here. :-)
<abu[7]>
👍
<taleon>
It will be a few days yet before that happens, though. Maybe even months or years. One step at a time. :-)
<beneroth>
oh no worries, we're here - when not, then a few hours later
ygrek has joined #picolisp
<abu[7]>
What I'd be interested in would be a game involving hundreds or thousands of non-player agents, running as coroutines
<abu[7]>
That would be interesting to investigate
<beneroth>
I don't know taleons game enough to tell, but I guess there some candidates for coroutines in it.
<abu[7]>
nice
<abu[7]>
let's see ..
<beneroth>
many games are build basically built upon a collection of final state machines, for which coroutines are also interesting I think (if task is not enough)
<abu[7]>
Yeah, and all three strategies work together
<beneroth>
I think the older browser games usually modeled that in the database and had then client requests (the ugly way) or crontab triggering a update procedure before handling the client request...
<beneroth>
abu[7], T
<beneroth>
or use coroutines to model queues for client updates, when you don't want to have one process per client but need to support more clients with fixed number or processes or so
<abu[7]>
Right
<abu[7]>
es ist also possible
<beneroth>
that's already a topic with single page web applications (SPA) and server-sent events I'd say
<beneroth>
abu[7], your model train example is a very good illustration and very nice example
<abu[7]>
yeah
<tankf33der>
I failed make a json http request on picolisp
<tankf33der>
I asked without curl, is it possible at all
<tankf33der>
i can do it with curl
<abu[7]>
Curl is here only for en/decryption
<tankf33der>
my rpc is sslless
<tankf33der>
i am testing monero
<taleon>
There are also NPC players in this game. However, I plan to let the ecosystem and the NPCs continue to develop in the background and act independently. You could do that in the past with the game Ultima Online. When the wolf population increased too much, there were hardly any hares to eat and then the wolves became aggressive and hungry and invaded human cities. That kind of thing.
<taleon>
And yes, the browser game works with cron jobs. The smallest increment is 10 minutes. This is when the monster fields grow, for example, or mana regenerates, etc.
<taleon>
s/increment/tick
<abu[7]>
"act independently" is what I want to play with coroutines with
<taleon>
aye
<taleon>
There is also a queue for everything. Train units, build buildings, move troops to other fields, research spells in the library, brew potions, search for dragon eggs and gems, etc. The combat system is also very tactical for surviving battles. You can rob other player settlements, search for tracks, engage in espionage, etc. There is a trading system, dynamic market prices, a tribunal with judges who
<taleon>
pass sentences for violations of the law, a war and diplomacy system, and much more. All in all, a very complex game.
<abu[7]>
cool
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
bjorkintosh has quit [Changing host]
<taleon>
I am considering programming an equipment calculator. A troop consists of various unit types. Each unit type can carry a maximum weight of equipment. Strong units more, weak units like mages less.
<taleon>
There are 5 equipment slots: weapons, shields, armor, helmets and jewelry. Each item has values such as AP (attack points), VP (defense points), MP (magic points), HP (health points) and a weight.
<taleon>
I imagine the equipment calculator like this: I enter a maximum weight (e.g. 100 kg) and specify that the value distribution should be e.g. 80% AP and 20% HP and the equipment calculator then selects the best items within this maximum weight.
<taleon>
An equipment calculator like this shouldn't be a problem if I brute force all the combinations and then pick the combination that doesn't exceed the maximum weight and has the most AP and second most HP.
<taleon>
But presumably there's a more elegant way of doing it with vectors or something, since brute force is quite computationally intensive. Anyone happen to have an idea? :-)
<beneroth>
tankf33der, do you have a simple example for the JSON request you wanna do? just a GET or also sending a body/JSON with the request?
<beneroth>
taleon, this goes into configurator/rule engine systems.
<beneroth>
I'm currently programming one in picolisp for a commercial project. and I programmed one once before in C# (lang was client spec)
<tankf33der>
can not make it sorter otherwise not repeatable
<abu[7]>
walking home, a bit later
<tankf33der>
i will write a little what i see and go afk too:
<abu[7]>
good
<tankf33der>
if type *two* times and (stack) inside error context and
<tankf33der>
exit from it by enter then you can not later find "a" by correct exec.
<tankf33der>
if *one* it is NOT repeatable.
<tankf33der>
should be nasty and trivial as always before.
<tankf33der>
afk.
<abu[7]>
Hmm, back now after a few beers with friends. But I think calling the main coroutine from inside an error handler is not a good idea.
<abu[7]>
I would say this is not a bug
<abu[7]>
In general is an error handler to investigate the environment of an error, and then leave it with <enter> etc. before contieuing any processing, *especially* if the error was in a coroutine, as we are still inside that coroutine's stack segment
<abu[7]>
Producing another error inside an error handler may give even more unpredictable results ;)