<OscarL>
E-450 did not started anymore. Tried tearing it appart, cleaning contacts, battery, mem, hdd, etc, etc. A real shame have to relegate it to e-waste :-(. I guess I'll try to make use of the RAM/HDD, and WiFi card (as it works on Haiku!), perhaps even the little speakers.
<Begasus[m]>
too bad OscarL :(
<OscarL>
using the Celeron N4020 based netbook at the moment (which works "fine", as long as ambient temps do not go over 30-35 C :-D(
<Begasus[m]>
how is it going HaikuUser ?
<OscarL>
welcome HaikuUser. Hope you enjoy your stay :-)
<HaikuUser>
it is going just fine. install was very easy and i am liking what i have so far
<Begasus[m]>
+1 good to hear :)
<HaikuUser>
i'll figure out how to change my name soon XD
<Begasus[m]>
"/nick <somenick>"
HaikuUser is now known as plagueeman
<plagueeman>
thank you
<Begasus[m]>
stupid corrections :P
<Begasus[m]>
/nick newnick
<OscarL>
that will last for current session. plagueeman, if you (hopefully) make a return... you might want to permanently set that up via the Vision settings (will link to the docs in a jiffy)
<plagueeman>
i plan on using only things like fediverse, indieweb, neocities, IRC, etc, exclusively on this machine plus use it for learning C++ and doing some creative writing
<plagueeman>
for sure thats good to know .i would have gotten to vision docs eventually just not there yet. going in alphabetical order...
<OscarL>
(FWIW, seems those docs do not explicitly tell how to setup "IRC network options", and I personally always found Vision settings a bit odd to navigate)
<OscarL>
Begasus[m]: "how weird" seeing both you and humdinger in that Vision screenshot :-P
<OscarL>
also, seems we used to have way more channel operators back then. Guess folks just "retired" from that role :-P
<Begasus[m]>
not that weird seeing the activity OscarL :P
<OscarL>
(thus my use of quotation marks... as in... of course they have to be "the usual suspects" :-D)
<Begasus[m]>
heh
<OscarL>
off-topic but... man, I'm having a really hard time deciding to make a purchase for a new fridge before summer comes. (granted, ~ USD 300, + shipping, is a *lot* of money here, still best new fridge price I can get, by a wide marging)
<Begasus[m]>
it's an essential thing to have, so probably need to bite the bullet?
<Begasus[m]>
weird I don't see IRC messages atm? (in matrix)
<Begasus[m]>
like .. didn't see the messages from plagueeman
<nekobot>
• Begasus (75c96311): opentoonz, revbump, bump boost version to 1.88.0 (#13002)
<OscarL>
I kind "got used" to not having even fresh water even on summers (after so many years without a fridge), but temps keep getting higher and I older). Begasus[m] is most likely right (relatives tell me the same :-D)... I'm just really bad at spending money :-D (thanks for the comment Begasus[m], btw)
<Begasus[m]>
your health is more important then that OscarL :)
<OscarL>
(will let you know if I pulled the trigger! Need to wait for the shop to open to see if they still have it in offer, and how I can get it be sent to my house).
<Begasus[m]>
+1
<plagueeman>
300 USD for a fridge sounds like a good deal to me
talos has joined #haiku
<OscarL>
plagueeman: for reference... it is twice my (current) total monthly expenses.
<plagueeman>
oh wow, never mind then. fridges here are much more expensive i guess
<Begasus[m]>
bleh ... /boot/system/develop/headers/boost/math/tools/roots.hpp:707:39: error: no matching function for call to 'float_distance(double&, double&)'
<OscarL>
to be fair... it is really "cheap", when compared to other things I've seen so... still a good deal, I guess :-)
* OscarL
is happy that Begasus[m] still have the patient/will to deal with boost stuff.
<OscarL>
I just try to run away from it :-D
<Begasus[m]>
lol
<Begasus[m]>
that's the least of my problems, rather boost then python :)
<OscarL>
on the other hand... doing some cleanup around the house... seeing which books I can donate (or which to use for fire starters)... saw one with a few chapters aboout using numpy/scipy, so... saved that one for when I updated those packages.
<OscarL>
so I can try to properly teste them (even if with outdated examples... but better than the ones I was using before :-D)
<swiftbanana[m]>
Is python that painful to port?
<Begasus[m]>
that's one for OscarL :)
<OscarL>
Python as in the interpreter itself?
<swiftbanana[m]>
Well
<swiftbanana[m]>
As whatever seems painful to you
<swiftbanana[m]>
Since I gathered from your talk there is some complexity involved
<OscarL>
on that front... I'd say the worst compexity comes from trying to manage dependencies constraints/trees.
<OscarL>
and having to multiply that for N version of Python interpreters in current use (thus why we have been removing
<swiftbanana[m]>
Yes, that is why poetry and venv are such useful tools in python land, but the issue is obviously no prebuilt binaries for haiku on pypi =/
<Begasus[m]>
most annoying things in python is the library hell there swiftbanana :)
<OscarL>
.... _python3xx packages for other versions than the "default" one.
<plagueeman>
I'm going to read up some more on Vision documentation but it was nice meeting you guys I'll most likely be back . Good night/day
<OscarL>
swiftbanana[m]: tried to package poetry twice... it has A TON of depedencies, and I just gave up.
<Begasus[m]>
biab ... doggies :)
plagueeman has quit [Quit: Vision[]: i've been blurred!]
<swiftbanana[m]>
Don’t make them compile Boostbfor you, poor things
<swiftbanana[m]>
*
<swiftbanana[m]>
@OscarL I’m not sure if poetry needs non native python dependencies, I’ll check
<OscarL>
today.... if it can't be packaged with setuptools (on its slow way out), or build+installer... I'll just do my best to avoid having to add more dependencies.
<swiftbanana[m]>
If it does not, no use in packaging it
<OscarL>
swiftbanana[m]: issue is.... if we provide a "poetry.hpkg", we need to create recipe for all its dependencies... we do NOT run "pip install" (or equivalent) on our recipes.
<swiftbanana[m]>
Yes of course
<OscarL>
and a lot of its deps haven't been needed so far (other than for poetry), so I just gave up on it.
<swiftbanana[m]>
Which means any project using poetry cannot be packaged since you don’t use pip even for build dependencies is that right?
<OscarL>
if things are "pip installable", my default possition is to say: "do not needs to be packaged".
<swiftbanana[m]>
I do agree with that position
<OscarL>
pip cannot properly be used in recipes, because, AFAIK, unlike rust's cargo, it lacks a ".lock" file (like cargo.lock) which correctly and unequivocally pins versions and lists checksums.
<swiftbanana[m]>
Yes that is correct
<swiftbanana[m]>
Poetry does tho
<OscarL>
(I've seen some attemps to "pip.lock", but that is not mandatory, thus... same as not-existent in this context)
<OscarL>
swiftbanana[m]: well... that's the "Python packaging problem" for you... againt's Python's Zen... there's a gazillion ways to do it :-(.
<OscarL>
and we are way too few folks doing recipes updates.
<swiftbanana[m]>
Hum
<OscarL>
last I've heard, all the cool kids are using uv or sumthin'
<OscarL>
as defacto python package maintainer for HaikuPorts (till I get kicked out for my extreme views/decisions :-D)... I. HATE. PYTHON. PACKAGING. and thus I'l always try to avoid adding anything that doesn't relies on the standard library. FUCK depedendencies... what are we.. nodejs?
<swiftbanana[m]>
XD
<OscarL>
small correction... I consider myself more of a Janitor than a Maintainer.
<swiftbanana[m]>
XD
<OscarL>
(given that I mostly try to do .recipe cleanups and upkeep)
<swiftbanana[m]>
I mean, I think we may be trying to nail a screw with a hammer here xD
<swiftbanana[m]>
I may have an idea to maybe (or maybe not) simplify the process, but I have to catch my bus right now ah ah
<OscarL>
we'll always happy to get any help we can get. Be well, swiftbanana[m]. Safe travels!
n005 has joined #haiku
<swiftbanana[m]>
Well, I missed my bus ah ah, but thank you! I´ll wait for the next one
<swiftbanana[m]>
So, okay, hear me out
<swiftbanana[m]>
This is but a proposal, it dos not mean we have to do that
<swiftbanana[m]>
I feel like traditionally, OS package managers and python packages are often a bad match, because developers will use pip/poetry/wathever with pypi anyway, and so the "only use" for the version packaged with the OS’ system is to provide dependencies for applications provided by the OS package manager
<swiftbanana[m]>
In Haiku there is a twist, because no package in pypi is built for Haiku
<swiftbanana[m]>
So while it does not play nicely with oython venvs, HaikuDepot also fills a gap there
<swiftbanana[m]>
(Sorry for the typos I’m on my phone)
<Begasus[m]>
right I guess for the most part, not that much is used in regards of python packages by applications (certainly not by Haiku apps)
<swiftbanana[m]>
What if, we had, say, an extra python-native repo, a HaikuPyPI if you will, that provided those python package builds for Haiku instead of putting them in HaikuDepots? Of course, the way we write recipes for python apps in the repo would have to be updated
<Begasus[m]>
should check what pyside needs in that regard when Krita switches to Qt6 officialy
<swiftbanana[m]>
And for the python apps in the repo, we could use, say, something like poetry or uv or whatever’s convenient that have a lock format
<swiftbanana[m]>
You may say "why if an app have no .lock mechanism", and I’d answer: what is stopping us to provide one (generated by poetry or uv)? Is that that much different from writing the dependency constraints in the recipe file?
<swiftbanana[m]>
We could even imagine providing venv in hpkg if deemed relevant
<swiftbanana[m]>
But the benefit would be that we need only care about packages that needed to be built
<swiftbanana[m]>
Pure python packages would just need to be fetched from the regular PyPI
<swiftbanana[m]>
And it would solve the issue regarding venvs and Haiku python packages
<Begasus[m]>
way too much sidetracks for me, OscarL is tha man! :)
<swiftbanana[m]>
Yeah don’t worry ah ah
<Begasus[m]>
it's a good thing (and tanks!) that OscarL is on that wagon
<Begasus[m]>
I only step in when he want's to remove something I find useful :D
<swiftbanana[m]>
xD
<Begasus[m]>
like the discussion we had yesterday
<Begasus[m]>
having tools like sphinx/rst2man is handy for creating documentation while creating hpkg's
<swiftbanana[m]>
Clearly
<Begasus[m]>
latex too, but don't want to burden the buildmasters on that :D
<swiftbanana[m]>
Latex is quite the beast
<Begasus[m]>
indeed, and we are lucky to have @jmairboeck for that (and the previous peeps that started the first port)
AD_Haiku_onPC has joined #haiku
<Begasus[m]>
pkgman install librecad .... no more boost1.69 whohoo! :D
<swiftbanana[m]>
Yeah!
<Begasus[m]>
it's time to retire 1.69 and 1.70 where possible
<swiftbanana[m]>
Wait
<swiftbanana[m]>
Isn’t Boost 1.69 like decades old?
<swiftbanana[m]>
Well maybe not decadeS
<Begasus[m]>
yeah, latest in the depot is 1.88.0, locally got 1.89.0 already
<Begasus[m]>
calligraplan ... still has it, but they are switching to Qt6 (already build here), so that can wait until they release the new version
<Begasus[m]>
bah ... /sources/s25client_v0.9.5/external/s25edit/callbacks.cpp:769:20: error: 'is_regular_file' was not declared in this scope; did you mean 'boost::filesystem::is_regular_file'?
Begasus has joined #haiku
Begasus is now known as Guest28277
AD_Haiku_onPC has quit [Read error: Connection reset by peer]
AD_Haiku_onPC has joined #haiku
<OscarL>
back for a bit. swiftbanana[m], I think I understand what you're aming at... but... I think same thing could be acommplished "inside" HaikuPorts if there was enough consensus (and written guidelines/docs). Issue remains the same... we are too few, and at least on HaikuPorts, we try to add thing to Haiku, not add *more* work (as it would be to add a "poetry layer") on top of other projects's workload.
<OscarL>
at least the short version of what I think.
<OscarL>
I do agree that we should try to avoid packaging stuff that is pip (or otherwise) installable outisde of "regular/OS" package manager (and I have been trying to reduce packages there).
<OscarL>
trying to focus on providing "hard to compile" (say, numpy/scipy/etc), or stuff that requires patching... and is a dependency... either of some tooling used on Haiku, or provides a nice to have command line / or app. (the "monsterz" game comes to mind :-P)
<OscarL>
for one reason or another, at some point we ended up providing, for a given python package, up to 5 different package versions (for each "supported" Python interpreter version). That clearly is just unsustainable, thus the focus on just providing things for the "defailt Python" (whatever that is).
<OscarL>
hard to focus on upstreaming patches, for example (as we should try to do more often), if we're drowned trying to juggle conflicting depedencies for different versions. Now I think we're at least in a better place... with only having _python310 packages...
<OscarL>
(I should try to move them to _python3.10 before we start adding packages for the future "default Python" :-D)
<Begasus[m]>
are we switching already? :P
<OscarL>
Begasus[m]: I hope not! :-D
<Begasus[m]>
same here :)
<Begasus[m]>
although, for me it isn't that much of a problem I guess, as long as haikuporter keeps working :)
<OscarL>
still not sure if we should just aim for 3.13, or drag our feet on 3.10, and hope we can just jump to 3.14 before 3.10 gets EOLed next year :-D
Aedil has quit [Quit: leaving]
<Begasus[m]>
I guess 3.13 should keep us going for some years (if 3.14 isn't stable yet)
<OscarL>
(depends on how fast projects migrate/support 3.14, I guess, *personally*, I'd like for 3.14 to be our next "long lived" python default, but dunno if skipping 3.13 will be feasible)
<Begasus[m]>
I think "if" we would reach R1 we should at least have a stable/recent python version update before that
<Begasus[m]>
biab
<OscarL>
Well, I expect Haiku R1 to have a way longer shelf-life than a regular Python interpreter (specially for R1... with its focus on BeOS apps compat on 32 bits, at least). So having to update the "default" python at some point in R1 is almost a given.
* phschafft
wonders why the python eco system doesn't call packages 'eggs'.
grim has joined #haiku
<swiftbanana[m]>
It used to be that way ah ah
<gordonjcp>
morgens
<phschafft>
Guten Morgen gordonjcp :)
<gordonjcp>
OscarL: we have a fairly slow release cycle so maybe sticking with whatever say Debian uses is worth considering?
<gordonjcp>
phschafft: servus
<gordonjcp>
OscarL: also updating minor python versions is usually non-breaking
<gordonjcp>
not like when Arch went from 2 to 3 really early and everything was on fire
<OscarL>
gordonjcp: issus is not with updating ("minor") version of Python interpreters... just that if we support different python versions (e.g.: 3.10 vs 3.12), packages can have conflicting depedencies requirements in such scenario.
<OscarL>
s/issus/issue/
mmu_man has joined #haiku
<OscarL>
and yes... perhaps following whatever "stable" (or even "testing"?) Debian targets... should be "good enough", at least in regards of: "what the hell is 'normal/most used' in Python land these days?" :-D
<gordonjcp>
OscarL: yeah but do you not express it as "python >= 3.whatever"?
<OscarL>
?
<gordonjcp>
when you're specifying dependencies
<gordonjcp>
you should say "Python better than version <whatever>" rather than "Python must be version 3.1.6.2.4.6"
<gordonjcp>
unless you really need to be that specific
<OscarL>
I guess you haven't seen some horrorifc version constrains as I had.
<gordonjcp>
OscarL: I work on a biggish flask app
<gordonjcp>
I know about horrific constraints :-)
<gordonjcp>
Ubuntu 24.04 ships 3.12.3
<OscarL>
I just know what I've read in setup.cfg/pyproject.yaml files for the packages I've tried. Have seen some hideaos things there (granted, mostly related to *other* python packages and not *that* much for the interpreters versions themselves, but I did saw odd things there too).
<OscarL>
in any case.... updating the main interpreters packages is *mostly* uneventful for me these days. Trying to solve conflicting version constrains among packages when updating them... not so uneventful :-(
lanodan has quit [Ping timeout: 480 seconds]
<OscarL>
(IIRC, we still don't have pandas for example, because at the time we couldn't conciliate the version requirements and still provide other packages at the same time)
<OscarL>
also... this stuff gets boring/tedious *fast*, I also would like to spend some time writting my own bugs, I mean, code.
mmu_man has quit [Ping timeout: 480 seconds]
ChaiTRex has quit [Remote host closed the connection]