<OscarL>
Mmm, now that I see that kernel/fs commit message, talking about a previous commit regarding ESPIPE... was wondering if I should have used that instead on https://review.haiku-os.org/c/haiku/+/7397
<nekobot>
[haiku/haiku] 05404cc538b3 - freebsd_network: Print the bounce buffer type in panic message.
<waddlesplash>
OscarL: probably not, as there is a "start" and "end"
<waddlesplash>
this is mostly just for FIFOs and other such things that really have no concept of position
<OscarL>
my thinking is... you can't seek those drivers' "files"... and posix says: These functions shall fail if: [ESPIPE] "The file is incapable of seeking."
<OscarL>
but... I'll take your word (and korli's) over my reading of the specs :-)
<OscarL>
heh, seems I have an unfinished "mandoc-1.14.6.recipe", dated 21-Oct-2022 :-D
<Begasus>
tss
<Begasus>
keep track! :)
<OscarL>
good thing that's still the latest version.
<OscarL>
time to drop it's gcc2 version too (only provides "cmd:"s, so should not cause problems)
<Begasus>
+1
<Begasus>
heh
<Begasus>
allowed = {
<Begasus>
{ "SDL2", "SDL2" },
<Begasus>
}
<Begasus>
not a lot of choices :P
HaikuUser has joined #haiku
<OscarL>
ah... mandoc patchset doesn't applies cleanly... no wonder I left it there in 2022... I had no idea how to work with those files back then :-D
<Begasus>
you got a roadmap for that now :P
<Begasus>
(had to strugle with the ones for TBB also), buggers changing things so much :P
* OscarL
reaches for his "updating patches for dummies, and folks with weak memory".
<Begasus>
heh
<Begasus>
writing down the roud to get to the latest "usable" TBB would take too long to read :)
<Begasus>
road*
MisthaLu has quit [Quit: Leaving]
<Begasus>
OscarL, mdnsresponder still wip or good to go?
<botifico>
[haikuports/haikuports] OscarL 5390da8 - mdnsresponder: new recipe. (#10627)
<OscarL>
I think we can add a "revision 2" for it when I finish working on it.
<Begasus>
patches welcome :)
<OscarL>
:-D
<OscarL>
At least I'll know if buildmasters will like the recipe or not :-D
<Begasus>
hwloc2 should be good too, but I need to check depending packgages for that first
<Begasus>
heh
<OscarL>
updated commit 1 of 4 for mandoc (I think it was the largest). Either I'm getting better at this... or it will blow out when I try to compile it :-P
<Begasus>
stil doing manual way here, a bit too complecated how you wrote it for me ;)
<OscarL>
I'll try to simplify it at some point. Maybe I should do some screen-capture. Once you see it, it is pretty easy.
<Begasus>
add a "for dummies" section ;)
<Begasus>
grabbing ecode_bin-0.5.2-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/ecode_bin-0.5.2-1-x86_64.hpkg :)
<OscarL>
heck... I think I'll even will end up writting a script for this, with easier to remember commands, and less typing :-D
<Begasus>
have to use -G though, it puts the .git directory also in the package otherwise?
<OscarL>
that's crazy :-)
<Begasus>
yeah, maybe cp -a does that :P
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
cp -a ./{assets,lib,ecode,ecode.png} $appsDir/Ecode (works well enough)
<OscarL>
And finally... "hp -e mandoc".
<OscarL>
kinda insane that a <700 KiB tarball explodes into a work-dir of 21+ MiB :-/
<OscarL>
"hp -c mandoc && hp -b mandoc"... .patchset applies now. Who knows if I got it right, thou :-P
<botifico>
[haikuports/haikuports] Begasus 2c6c677 - tbb, bump to latest release not introducing tcm (#10631)
<Begasus>
good luck!
<Calisto>
Thanks :)
<Calisto>
btw I just had a small question if anyone could help me out with it.. Is it always necessary to run the InitCheck functions before using things like a BEntry or a BFile?
<Calisto>
or should I just put it in everywhere I use them just in order to ensure everything works well?
HaikuUser has joined #haiku
HaikuUser has quit []
<Begasus>
biab
Begasus has quit [Quit: Vision[]: i've been blurred!]
<botifico>
[haikuports/haikuports] JadedCtrl 77e47b3 - pogger: new recipe (#6263)
<Begasus>
3 yrs old, but still working fine as is :)
<Calisto>
Heyyy
<Begasus>
wb :)
<Calisto>
yup :)
<Calisto>
made some progress.. Going to just finish up my dinner and everything and then continue :)
<Calisto>
thought i'd just peek in on the IRC to see what was happening :)
<Begasus>
enjoy :)
<Begasus>
not much, cleaning up at PR's and going over the remaining ones atm
<Calisto>
btw Begasus, do you work full-time elsewhere or full-time on Haiku... sorry if this is something I shouldn't be asking :(... I was just curious :)
<Calisto>
oh okay that's nice
<Begasus>
retired now :)
<Calisto>
ohhhh wow thats great
<Begasus>
and free time to spare here
<Calisto>
yup :D
<Begasus>
lately about 6hrs a day (give or take a few)
<Calisto>
oh that's nice to hear
<Begasus>
heh, not sure everyone is pleased :D
<zard>
PulkoMandy: It's not possible to upload changes to devconsole
<zard>
I can't register my email address. It fails with "realm does not allow adding emails"
<zard>
And pushing changes fails with "email address is not registered in your account"
<botifico>
[haikuports/haikuports] Begasus 4995113 - kirigami_addons1, bump version (#10638)
<Calisto>
heyyy
<Begasus>
low!!
<Calisto>
Finally got done with all of today's tasks xD
<Begasus>
+1
<Calisto>
now I can peacefully sit and make progress for the Folder Filtering :)
<Calisto>
I mean I did do the tasks for today but still have loads of time for today :-)
<nosycat>
Sounds good!
<Begasus>
ah, take a look at porting jfx then? :P
<Begasus>
jk ;)
<Calisto>
xD
<Calisto>
i'm kinda anxious about what's going to happen once I post the first set of UI changes onto Gerrit
<Begasus>
crash gerrit? ;)
<Calisto>
xD
<Calisto>
but still waiting on the go-ahead signal from nielx[m]
<Calisto>
On that note, I'll try and get working on the Directory Filtering
<Begasus>
kf.kio.core: KIO Connection server not listening, could not connect
<Calisto>
P.S. a lot of these derived classes don't have internal documentation... maybe after GSoC i should try writing the docs for it :)
<Begasus>
annoying bug :P
<Calisto>
things like ModelMenuItem or IconMenuItem aren't mentioned in the Haiku Book at all :(
<Begasus>
make sure you don't forget them Calisto :)
<Calisto>
yup I noted them down on a notebook to make docs for them later
<Calisto>
but probably once I'm done with most of my project
<Calisto>
right now I'm starting to get anxious as to whether its going on track or not :(
<Begasus>
I guess it's as good or even better then having code in without documentation
<Calisto>
btw anyone here who does a lot of things with BMessages... is it very dangerous to send a pointer along with them?
<Calisto>
I was thinking of something where a BMenuItem would send its pointer with a message that is meant to trigger the action to remove it
<Calisto>
is this something dangerous to do if you are 100% sure that the message can only be generated when the pointer points to an active BMenuItem object?
<zard>
re
<zard>
+1 to documenting classes. Maybe I should do some of that myself
<Begasus>
heh
HaikuUser has joined #haiku
HaikuUser has quit []
<phschafft>
isn't the idea that the BMessage is serialisable?
<phschafft>
so basically only stuff should go in there that would be valid in a completly diffrent context as well (such as after a reboot or on a different machine).
<Calisto>
Ohhh okay so putting a pointer goes against that
<Calisto>
that makes sense
<Calisto>
I should probably look for a different way to do it then
<phschafft>
yes, whoever reads that message might have something totally different there or maybe nothing at all.
<Calisto>
yah but this message was specifically meant only to be intra application
<phschafft>
same difference. ;)
<Calisto>
yah :(
<Calisto>
i'll look for some other way to do it :)
<Calisto>
how would you implement something like a BMenuItem that deletes itself when it gets unmarked?
<Calisto>
this is basically the thing i was trying to do
<Calisto>
I had used a BMessage that gets sent to the BView with a pointer to that BMenuItem and it then deletes the BMenuItem at that memory location and removes it from the menu
<Calisto>
it seems to work fine but the logic like you said goes against a BMessage
<PulkoMandy>
zard: How did you log in to the gerrit for devconsole? I think I have configured both github and google but only one works? I'll try to look tomorrow, but otherwise, send your changes by email or put them on some other git host and I'll pull it from there
hightower3 has joined #haiku
<zard>
I use github
<zard>
*used
<PulkoMandy>
No time to look today :(, going to a choir rehearsal in a few minutes (last one before the concerts)
<botifico>
[haikuports/haikuports] Begasus 03737fe - tellico, bump version (#10639)
<zard>
interesting...
<Begasus>
Enjoy PulkoMandy
<augiedoggie>
i don't see a problem with passing internal pointers in a bmessage, i don't often have a need to do it though
<augiedoggie>
that's the reason bmessage has methods like addpointer and addmessenger
<Calisto>
oh okay perfect.
<Calisto>
that simplifies a lot because I can simply just add the BMenuItem's pointer to its own BMessage
<Calisto>
that way when the message to remove it is sent, i can retrieve the pointer, typecast and do the remaining parts
hightower4 has quit [Ping timeout: 480 seconds]
* Begasus
got lost after "simply" :)
vdamewood has joined #haiku
HaikuUser has joined #haiku
WahidShaikh[m] has joined #haiku
<Calisto>
btw could someone tell me how does the ASSERT macro work?
<Calisto>
like I get that its supposed to make the application stop and show an error if the assert condition inside isn't true
<Calisto>
is that all or is there something else as well :)
<zard>
I think that's it. So "if (!condition) { CRASH(); }"
<nosycat>
If you mean the one in assert.h, I think that's pretty much it.
<Calisto>
ohh
<Calisto>
wait so its supposed to cause the program to crash right?
HaikuUser has quit []
<Calisto>
and what about like does its how the error?
<Calisto>
or open the debugger or something?
HaikuUser has joined #haiku
HaikuUser has quit []
<nosycat>
I shows you the expression that failed.
<Calisto>
is it like good practice to use ASSERT instead of just writing an if statement to check for that assert condition?
<Calisto>
like should I use it as much as possible whenever I'm assuming the state of something like a pointer?
<Calisto>
or a BFile or something like that
<Calisto>
also augiedoggie: the pointer thing works :D
<nosycat>
In my experience, most conditions are not actually unexpected or surprising, so an "if" makes more sense in 90% of cases.
<Calisto>
yah in most of the places I've put in, for example, if(fFile->InitCheck() != B_OK) return;
<Calisto>
instead of the ASSERT
<nosycat>
But sometimes you're working on someone else's legacy code, and you have to make assumptions about invariants.
<Calisto>
ohhh okay
<zard>
I use asserts whenever I know bad things will happen with some code if the condition isn't true
<Calisto>
so in general its just better to handle the if case rather than the ASSERT in case it doesn't have a drastic impact
<Calisto>
on the following code rigth?
<zard>
Or else when I know the code won't work but will fail in a non-obviouos way
<Calisto>
ohh I see
<Calisto>
I should probably take a note of that.
<Calisto>
I've used ASSERTs in a few places but just as an alternative to the if statements
<Calisto>
I think I should change that according to the above thigns :)
<Begasus>
closing downhere
<Begasus>
cu peeps!
Begasus has quit [Quit: Vision[]: i've been blurred!]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Calisto>
good night Begasus
<Calisto>
see you tom :)
<Calisto>
btw nosycat: I had a weird question regarding the styling guideline. What do we do in the case that the return type of a function is very long and the function name and parameter list gets wrongly indented because of this? like what's the styling guideline to follow?
<botifico>
[haikuports/haikuports] nielx 32ef878 - binutils: update to 2.42 (#10506)
UW_Mill has quit [Remote host closed the connection]
zard has quit [Quit: leaving]
Calisto has quit [Ping timeout: 480 seconds]
jmairboeck has joined #haiku
MisthaLu has quit [Quit: Leaving]
Anarchos has joined #haiku
<Anarchos>
is there a command to update the date/time with network time ?
<waddlesplash>
Time --update
Calisto has joined #haiku
HaikuUser has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
HaikuUser is now known as OscarL-nightly
<OscarL-nightly>
I was able to connect to WiFi on the first try (idualwifi7260) after updating to hrev57793. Hope it isn't just a fluke :-D
<Anarchos>
waddlesplash thanks i didn't know that !
OscarL has joined #haiku
<OscarL>
Mmm, got a KDL on the other machine. Guess I should have waited for hrev57794 before trying to enable "Powersave mode" :-P
OscarL-nightly has quit [Ping timeout: 480 seconds]
dovsienko has quit [Quit: Leaving]
<OscarL>
nice... was able to connect again after a power down/up cycle. (doens't auto-connects, but that's just the least of my worries :-D)
<Anarchos>
OscarL i never got autoconnect
<OscarL>
Yeah, seems to be a common issue (for some drivers/devices at least?), judging by mentions on the forum. A boot script with a little delay seems to work for some folks, Anarchos. Might worth a try.
<OscarL>
Yeah... happens again when right-clicking on the /var/log/syslog file, and hovering over the "Open with..." menuitem... which remains empty, btw.
<OscarL>
might be related to the latest query changes waddlesplash?
<waddlesplash>
yes it's possible
<waddlesplash>
I'll investigate
<OscarL>
first time the syslog was not yet identified, now that it is... the list of appsignatures on that list has grown (to the apps that support text files).
Calisto has quit [Remote host closed the connection]
Calisto has joined #haiku
OscarL-c10 has quit [Quit: Vision[]: i've been blurred!]
Calisto has quit [Remote host closed the connection]
Calisto has joined #haiku
<OscarL>
mmm: page fault but interrutps where disabled. Touching address 0x000000[...]00034 from ip 0xff[...]8009e6d1
<OscarL>
was reaching for Deskbar to reboot. A CPU core was pegged to 100%. Will try after latest korli's change gets available for updates.
<nekobot>
[haiku/haiku] 1a3dae790e24 - Tracker: Code cleanup around add-ons.
<nekobot>
[haiku/haiku] eca86a00ae91 - Tracker: Add a try/catch around ModelMenuItem's creation in AddOneAddOn.
<OscarL>
Oh... /me likes those if (!condition) return; instead of deeper nesting!
<OscarL>
had some folks tell me they hated them, thou... silly rabbits! :-P
<phschafft>
I would think that the main logic of a functing belongs on it's main level.
Calisto has quit [Remote host closed the connection]
Calisto has joined #haiku
<OscarL>
at least one coworked sweared by the "only one point of return/exit" rule/mantra. Makes for fugly code IMO.
<phschafft>
any rule makes for bad code if you insist on it in a noisy real world. ;)
mmu_man has joined #haiku
<phschafft>
plus this doesn't even mean a violation in the logical sense: for example if you just check your arguments first that is it's own functionallity block. so it doesn't need to count.
<OscarL>
on the other hand... I end up with bad code, no matter the rules I follow :-D
<phschafft>
specifically if you do it in an organised way.
<phschafft>
I enjoy having such a block and then two blank lines after it. plus every step that changes the state of a function gets a comment that tells us what the state is.
<phschafft>
for example 'now a, b, and c are guaranteed to be valid' or 'a is now within the range of [b, c]'
<OscarL>
this guy hated "close to usage" variable declarations to (looooong lists at function's start). Guess he was just too used to old/weird/limited compilers.
<phschafft>
I very much enjoy close to usage, but I'm strictly against code and delercations mixed.
<phschafft>
declerations go to the start of a scope, no code before them. the initialised ones first. longer ones before shorter ones. then a blank line and then code.
<phschafft>
so if you have some functionallity that needs some vars that are only used in part functionallity then you should have it in it's own scope. after all it's it's own functionallity to begin with.
<phschafft>
please just don't write functions with 2k lines and 1k vars all called 'tmp3' ;)
<phschafft>
or as I have seen way to often 'i', 'ii', 'iii', and 'iiij' ;)
<OscarL>
int _;
<OscarL>
and then use reuse it for everything. so much more efficient! :-P
<phschafft>
;)
<phschafft>
and again scopes help with that. they allow the compiler to throw things away again. making the code much more secure and allowing you to reclaim those resources (not just RAM but also mentally)
gouchi has quit [Remote host closed the connection]
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
<OscarL>
Mmm, "try {} catch (...) {}" kinda looks like Python's naked excepts to me. (where you're not specifying an exception type, and thus might end up silencing exceptions one should actually be re-rising/re-throwing).
<waddlesplash>
OscarL: indeed twas a bug in the query parser. I saw the same earlier but hadn't investigated, thought it was just some oddity on my local builds with attributes (they often have issues)
<OscarL>
glad to have you looking into it :-)
<waddlesplash>
well, I'm the one who introduced the bug, so. :P
<nekobot>
[haiku/haiku] 88911fe61c6f - file_systems/QueryParser: Only increment within the operators loop.
<OscarL>
can't make an omellette without breaking some eggs :-)
<PulkoMandy>
The "one point of return" coding style makes sense in C because there are no destructors, so you have to be sure to free everything the function allocated before returning, and if it returns in several place, someone will forget to update at least one of them
<PulkoMandy>
In c++ you can have opjects clean themselves when they go out of scope, so that problem is already solved
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
I was getting complaing about my "return early" style... on Python code, thou. Guess he was just too used to read code in the style he used for embedded systems.
<OscarL>
on the other hand... I had a boss insisting that I needed to use far more inheritance. I did... in the places it made sense. Java guys gonna class it all, I guess.
<PulkoMandy>
Some people apply the rules without understanding why they are there
<phschafft>
;)
<phschafft>
(gcc can btw. call a destructor in C ;)
Anarchos has quit [Quit: Vision[]: i've been blurred!]
mmu_man has joined #haiku
diver1 has joined #haiku
<gordonjcp>
I dislike classes
<gordonjcp>
I'm not even keen on variables
<gordonjcp>
just give me a block of memory
<gordonjcp>
take it all back when I'm done with it
<gordonjcp>
let me deal with what goes on inside it
<OscarL>
using gravitational lensing drive cosmic rays to move those electrons around, aren't ya?
<OscarL>
*to drive
<gordonjcp>
OscarL: no no
<phschafft>
OscarL++
<gordonjcp>
it's just that I can write Z80 machine code on any platform
diver has quit [Ping timeout: 480 seconds]
ClaudioM has joined #haiku
<OscarL>
I remember doing some basic Z80 asm programming exercises at the university. Was on paper only, 18 years ago, so I remember zilch about it... other than it being kinda fun... and that reading instructions timing graphs gave more problems than they should have :-D
OscarL has quit [Quit: Page closed]
OscarL has joined #haiku
<gordonjcp>
OscarL: I grew up with the ZX Spectrum, and used various 6502 and 6809 machines too
<gordonjcp>
OscarL: for a while I did embedded programming for oil tools that ran Z80 code
<gordonjcp>
OscarL: apparently some of that code was repurposed by another business unit that wrote firmware for automotive parts, which is worrying because I don't really know what they were for
<gordonjcp>
OscarL: the possibility exists that there are cars out there with some vital component controlled by a task scheduler originally written for a crappy sidescroller shoot-em-up on the ZX Spectrum by a bored 15-year-old on a tiny island in the North Atlantic with nothing better to do than write Z80 code, drink beer, and eat copious amounts of hallucinogenic mushrooms
<gordonjcp>
so
<OscarL>
heh :-D
<gordonjcp>
uh, drive safe, I guess
<gordonjcp>
if it crashes, it'll lose all its tasks, but only until /INT is asserted again