floof58 has quit [Read error: Connection reset by peer]
floof58 has joined #haiku
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
HaikuUser has quit []
Hannah has quit []
Hannah has joined #haiku
frkzoid has joined #haiku
frkazoid333 has quit [Ping timeout: 480 seconds]
Maturi0n has joined #haiku
Maturi0n_ has quit [Ping timeout: 480 seconds]
xet7 has joined #haiku
<zdykstra>
Off chance, but does anybody have a weechat plugin that uses the haiku notification system? Shouldn't be hard to do, but I don't want to duplicate effort if it's done already.
<augiedoggie>
seems like something i wrote many years ago, i'm sure it's gone though
<waddlesplash>
do you need a plugin?
<waddlesplash>
you can just run the "notify" command in the background
<zdykstra>
It'd have to be a plugin to act in the right type(s) of weechat events. I'll just take the one that uses libnotify on Linux and tweak it.
<OscarL>
k, *now* I'm happy with the coverage recipe.
<OscarL>
off to remove imutils :-D
<Begas_VM>
another one down! :)
<OscarL>
if korli gave it the thumb-down... who am I to disagree? :-D
<Begas_VM>
lol
<OscarL>
Should I add the "git rm" as a second commit to that PR (I was attepmting to update it first), or should I just "git commit --amend" && force push the removal instead?
<OscarL>
(the --amend after using rm, of course)
<OscarL>
guess I could reset && git rm too. The question is... do I drop the attempt to update it too, or leave it there?
<OscarL>
Nothing really of value will be lost, I guess. I think I'll just kill it all. Muaaahahahaaa!
<Begasus>
for imutils?
<Begasus>
nuke it :)
<OscarL>
writting the commit msg, now :-).... Man.... I could use a spellchecker in nano :-D
<Begasus>
:D
<OscarL>
In nano, in Pe, in IRC... IRL... :-P
white-wolf has quit [Remote host closed the connection]
white-wolf has joined #haiku
<OscarL>
4 recipes to go from korli's bulk update. We're getting there!
<botifico>
[haikuports/haikuports] OscarL ea3ebbf - coverage: update to version 7.2.2. (#8148)
mmu_man has joined #haiku
<Begasus>
lol
<Begasus>
(latest comment on imutils) ;)
<OscarL>
:-(
<Begasus>
updated texstudio with the missing peaces mentioned by jmairboeck
Begasus_32 has joined #haiku
<Begasus>
knowing the people from texstudio they probably got a new version out by now ...
<Begasus>
ah no, still on par :)
<Begasus>
bugger, needs a rebuild
<OscarL>
ouch.
<Begasus>
well, only to checkout here (texstudio), no use in bumping upstream before texlive_2023
<Begasus>
doesn't take as long as building texlive :P
<OscarL>
should we prefer using SOURCE_URIs from PyPi instead of github's tag archives for the Python packages recipes?
<OscarL>
(would make sense to me, as PyPi is the "central" point for python packages)
<OscarL>
Also, PyPi has the file hashes.
<OscarL>
(already did that move for a couple of recipes... just wondering if there's already a consensus about this)
<Begas_VM>
waddlesplash, some flaw in the check for static libraries? https://ibb.co/9p8mVqz
<Begas_VM>
the "libiodbc" ones are disabled in the recipe and are fine, the libodbc still has both static and shared (removed the static one in the recipe), shoulnd't haikuporter have picked this up?
<OscarL>
Darn. While using the coverage recipe as a base for others, I keep finding small things to improve/simplify in it :-/ (I was overusing "eval")
<Begas_VM>
never done :P
<OscarL>
indeed.
AlaskanEmily has quit [Remote host closed the connection]
<Begas_VM>
atexstudio build running :)
* OscarL
crosses fingers
<Begas_VM>
still the same version, so no real changes, only needs to pick up the new texlive packages :)
dqk has joined #haiku
dqk_ has quit [Ping timeout: 480 seconds]
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
Hell yeah, finally got bash-completion to work. (an old setting file was blocking its use :-(
<OscarL>
The "bash_completion" package provides a "settings/etc/profile.d/bash_completion.sh". But it is not updated if an update of "bash_completion" is installed.
<OscarL>
and that file has a version-revision specifc path, so it stops working after you update :-(
<OscarL>
Guess the recipe should not use auto-merge for that file in GLOBAL_WRITABLE_FILES?
<OscarL>
Can we call "packageEntries $pythonPackage" more than once? (I'm about to find out)
<OscarL>
Seems to work.
<OscarL>
(*for the same $pythonPackage, I meant)
<Begasus_32>
why would you?
<OscarL>
Because I need to only add $dataDir for only one of the packages.
<OscarL>
and $dataDir doesn't exits for the others.
<OscarL>
Mmm, I guess I could also leave it empty,
<Begasus_32>
not possible through a "if then" in INSTALL ?
<OscarL>
did that to copy the file I want into $dataDir, but as I was only creating $dataDir inside that "if then" block... packageEntries could not stat $dataDir for the others :-D
<OscarL>
Grrr, now the other packages end up with an empty dir in $dataDir :-(
<Begas_VM>
if then ... else ... fi ? ;)
<OscarL>
I'm not seeing how can I do "packageEntries $pythonPackage $binDir $dataDir" for the three of them (without separating that call to packageEntries).
<OscarL>
if $dataDir exits... I end with emtpy dirs I don't want (for the ones that have nothing in there). If I remove $dataDir... packageEntries fails.
<OscarL>
Am I making sense?
<Begas_VM>
yeah, like the seperate tools packages etc
<OscarL>
thus, I was calling "packageEntries $pythonPackage $binDir" for the three, and "packageEntries $pythonPackage $dataDir" only for one of them.
<OscarL>
but I wasn't sure if that would work. (seem it does)
<Begas_VM>
guess those are the things I need to check before I can comment ;)
<Begas_VM>
k, TeXstudio up and running nice with Texlive-2023
<OscarL>
one less thing to worry about :-)
<Begas_VM>
yep, only I don't know where I left off on the static libraries on the other laptop ;)
<OscarL>
the ripgrep recipe has a typo in it.
<Begas_VM>
patches welcome :)
<OscarL>
tries to install bash completions into "etc/bash-completions/" (but the actual path doesn't has the final "s")
<Begasus>
heh
<OscarL>
I could send a patch, but no way I'm going to run "hp ripgrep" to test it :-)
<Begasus>
got a file with failing builds that I'll post later at haikuports, some maybe easy to fix, need a version bump or ...
<OscarL>
+1
<Begasus>
mimetic not checked with gcc2 (untill now), so now I can mark it as broken :P
<Begasus>
std::char_traits unsupported
mbrumbelow[m] has left #haiku [#haiku]
<Begasus_32>
mmfile.cxx:60:14: error: ordered comparison of pointer with integer zero ('char*' and 'int')
<Begasus>
another one for the list
<OscarL>
that "mmfile.cxx:60:14" might need to change some "ptr > 0" with "ptr != 0" (if I'm understanding the issue correctly)
<OscarL>
"ptr" being whatever pointer variable it is trying to compare to 0.
mbrumbel_ has joined #haiku
mbrumbel_ has left #haiku [#haiku]
mbrumbelow has joined #haiku
<Begasus>
waddlesplash, if you build libiodbc currently in haikuports and add "--disable-static" to configure you'll see it still installs both static and shared one for libodbc
<Begasus>
(like in the screenshot)
<waddlesplash>
Begasus: yes, but the screenshot you have shows a .a of a library not in the prepareInstalledDevelLibs
<zdykstra>
that codename shortage blurb is hilarious
<OscarL>
:-)
<Habbie>
lol
<OscarL>
When BeDoper stopped updating... I opened BeDoperer (just to follow the traditon: BeDope -> BeDoper -> BeDoperer)... Only ran for 2 numbers (a 3 article I didn't published).
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
Too bad that I've used googlepages for that, and those got lost.
<nephele>
I'd sure like to know why WebPositive pegs one thread at 100% with nothing going on, it makes my fan spin and it's annoying .-.
<OscarL>
nephele: browsing Github?
<OscarL>
that's where I guet that 100% on one core on Web+.
<nephele>
waddlesplash: looks like a different issue
<waddlesplash>
"I'd sure like to know why WebPositive pegs one thread at 100% with nothing going on"
<waddlesplash>
that's the issue I linked
<nephele>
Yes... nothing is going on, the page is loaded. It should not do anything
<nephele>
i don't see how that is related to http2 support in curl
<waddlesplash>
because HTTP2 is a keepalive protocol
<waddlesplash>
get a backtrace of the thread that's using all the CPU, it will likely be the same
ADS_Sr has quit [Ping timeout: 480 seconds]
zard has joined #haiku
<nephele>
none of the threads running are related to http2, anyway the issue linked above is more relevant
<waddlesplash>
is there a curlThread?
<nephele>
i'd assume a issue only showing up in github is releavant to github
<nephele>
yes, we use the curl backend
<waddlesplash>
is the curlThread the one using all the CPU
<nephele>
no
<waddlesplash>
hmm. then it may be different indeed
<nephele>
according to activity monitor it is the main one, that is either HaikuLauncher or WebPositivew
<nephele>
though i'm not sure what they would be doing with it
<nephele>
It looks to be related to the unhandled promise though, each unhandled rejectin message triggers a new BMessage beeing send
<nephele>
maybe that is where the cpu time is going
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
<nephele>
waddlesplash: do you have an example of the "last message repeated N times" implementation we use? I think it's different ones, i'd guess that if i simply add this to haikuwebkit i could catch this messagespam more easily
<nekobot>
[haiku/haiku] 8c58c0c5e3f8 - BaseTranslator: Use PreferredSize() not ExplicitPreferredSize() in resize.
<waddlesplash>
zdykstra: if you want to look at deleting the SetExplicitPreferredSize from all remaining translators and make sure they still work, that is an easy change that will clean up code quality :)
<zdykstra>
perfect - I can tackle that tonight
<waddlesplash>
note translators are in haiku_datatranslators.hpkg, make sure to build and update that one when testing, not haiku.hpkg