<Begasus>
k, that was in the pipeline long enough :)
JakeSays has joined #haiku
JakeSays1 has quit [Ping timeout: 480 seconds]
freddietilley has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
freddietilley has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
MisthaLu has joined #haiku
<Lt-Henry[m]>
hi
<Lt-Henry[m]>
I've been some days wondering... what are the benefits (right now) of a vga device handled by a driver (ie: intel_extreme) vs the framebuffer?
<Lt-Henry[m]>
framebuffer does not allow to change resolution, but as long as it matchs de monitor native specs, I does not look like a problem to me
<Lt-Henry[m]>
is there some performance gain?
<Begasus>
hi Lt-Henry[m], not an expert, but for my needs I don't really see any performance gain?
<Lt-Henry[m]>
yeah, thats why I am asking, because I see no difference
<Lt-Henry[m]>
well, tbh, on my ivy bridge it looks smoother
<Lt-Henry[m]>
but can be a sensation biased by a lot of factors
<Begasus>
right :)
<Lt-Henry[m]>
so... the acceleration method is nothing but memcpy?
<Lt-Henry[m]>
:D
<Begasus>
my memory cpy is lost :)
<Begasus>
biab
Begasus has quit [Quit: Vision[]: i've been blurred!]
freddietilley has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
Begasus has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
mmu_man has joined #haiku
jessicah has quit [Quit: Connection closed for inactivity]
freddietilley has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
freddietilley has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
FreeFull has quit [Quit: Lost terminal]
HaikuUser has joined #haiku
HaikuUser is now known as Yoke
<Yoke>
Morning Ya'll
zard has joined #haiku
Yoke has quit [Quit: Vision[]: i've been blurred!]
vdamewood has joined #haiku
<Begasus>
OK, at least the one laptop still containing a CD/DVD drive is still working :D
_justin_kelly1666 has joined #haiku
<nephele_xmpp>
Lt-Henry: native intel_extreme allows setting monitor brightness, blaanking the display and such
<nephele_xmpp>
but no, no performance gain
<nephele_xmpp>
in the future allowiing to controll volume/brightness for connected (over hdmi) displays would be an additional benefiit, but we don’t have that yet
_justin_kelly166 has quit [Ping timeout: 480 seconds]
thelounge917 has quit []
MisthaLu has quit [Quit: Leaving]
Anarchos has joined #haiku
<dovsienko>
nephele_xmpp: ddcutil does that for me on Linux
thelounge917 has joined #haiku
<Anarchos>
hello
thelounge917 has quit []
<nephele_xmpp>
dovsienko: okay? I don’t think it makes sense to have a cli tool for that which implements this itself. The driver should really do that, then we can hook it up to volume buttons etc directly
<dovsienko>
let's not argue about it
thelounge917 has joined #haiku
linuxmaster has quit [Ping timeout: 480 seconds]
dru_satori has joined #haiku
yuui has joined #haiku
thelounge917 has quit []
robert7 has quit [Quit: Bye]
robert7 has joined #haiku
thelounge917 has joined #haiku
robert7 has quit []
<Lt-Henry[m]>
thanks for the info nephele
robert7 has joined #haiku
<Lt-Henry[m]>
modesetting, brightness, and dual output (wip)
<nephele_xmpp>
(And I still disagree that this should use document colors)
<nephele_xmpp>
Skipp_OSX: Color drops should be implemented for a proper solution
<nephele_xmpp>
but go ahead if you want to merge it
* phschafft
could now ask if colours are a propery of the system, the session, or the terminal ;)
<nephele_xmpp>
Well, i’m sure phschafft has more interesting questions ;)
<phschafft>
(or maybe the user/account)
<nephele_xmpp>
(The answer is of course: all of them, some colors are local to instances of apps, some to apps, some are to the session etc)
<phschafft>
(or maybe it's a matter of the container hierarchy? so each view matches the display of it's parent plus updates based on it's own inherent properties. e.g. a document-view would switch default colours to document colours, but a text view would use the values from it's parent)
<phschafft>
(basically like HTML/CSS does, just going up all the way to the OS kernel)
<Skipp_OSX>
I thought I had cleared this complaint by demonstrating using the olive theme from ThemeManager
<nephele_xmpp>
Honestly, No, it’s quite the opposite for me. settiing the document color to oliives thus making other stuff olives is not an upside
<nephele_xmpp>
especially not when the thing is a ui control you are supposed to interact with
<nephele_xmpp>
by the way: please make the cursor a hand when moving over the clock to make this discoverable
<nephele_xmpp>
Don’t get me wrong, I have no problem with people *wanting* their clock to be olive, but i think they should be able to do this without having to set their documents to olive and such
<phschafft>
time for shopping, see you a little later with more fun questions ;)
<Begasus[m]>
what's up with my olive theme? :P
PetePete has quit [Ping timeout: 480 seconds]
<waddlesplash>
nephele_xmpp: I think you are being far too stringent here. The clock right now has hard-coded colors, and getting these to be the Document colors instead will be correct in 99% of cases. In the remaining minority cases we can work on implementing a new feature. But I don't think this is a reason to block merging the change.
<nephele_xmpp>
waddlesplash: I’ve already removed my -2, and I don’t want to work on color drops myself right now
<Skipp_OSX>
Specifically the clock color in the bottom right
<Skipp_OSX>
Which I guess is merged now... so hooray for olive clock.
<zard>
Congratulations :D
<Skipp_OSX>
If I did 2 pixel offset like you say it would be border on border which would be a double border and look bad. I made the two borders overlap on purpose. (going back to the earlier image and discussion)
<Skipp_OSX>
The point is, if you are using the olive theme, you get an olive clock. So that's why document color is used.
<Skipp_OSX>
And why document color? Well because there was only a handful of color constants on BeOS R5 and it was one of them so we use it in a bunch of places.
<nephele_xmpp>
We really don’t
zard has quit [Quit: leaving]
<nephele_xmpp>
Your justification was “it’s black by default”, and I still disagree that it is a good idea to overload semantic colors even more
<Skipp_OSX>
document color is White by default. Right matching the default clock color...
<nephele_xmpp>
Implement color drops, or don’t. Your patch is still a bad design regardless
<Skipp_OSX>
color drops are irrelevant
KapiX has quit [Quit: KapiX]
<nephele_xmpp>
Why do you want to drag up this discussion again...?
<Skipp_OSX>
You're setting up a straw man with color drops but it's not either or, you can do both.
<Skipp_OSX>
Oh I didn't, phschafft did...
<nephele_xmpp>
A straw man is where you put arguments into the mouth of other people, and is a logical fallacy
<Skipp_OSX>
I thought it was when you create a fictitious argument and argue against that instead of the actual point...
jmairboeck has joined #haiku
<nephele_xmpp>
Color drops are the right way to implement this, that or drop the skeumorphic tendency and make it look like a proper control. But really, let’s not rehash iit
<Skipp_OSX>
color drops are the straw man, you keep pointing to it and saying, see, that's the argument.
<nephele_xmpp>
> I thought it was when you create a fictitious argument and argue against that instead of the actual point...
<nephele_xmpp>
A fictious argument you put into other peoples mouth “My oponents would say <made up point> to that ii say <x>”
<nekobot>
[haiku/haiku] e0101fa39b0a - runtime_loader: Clean up code in remap_images().
<nekobot>
[haiku/haiku] e38be9392a8c - runtime_loader: Actually respect PF_EXECUTE program header.
<nekobot>
[haiku/haiku] b21f31ea1687 - runtime_loader: Consolidate some elf_region code.
<nekobot>
[haiku/haiku] 26cf47386e93 - kernel/elf: Map user images with kernel protections only at first.
<Skipp_OSX>
ok well maybe I don't know what a straw man is then but that's what I meant.
<Begasus>
Olive looked better in ZETA where it was created :)
<waddlesplash>
no, Skipp_OSX is correct, that's basically what a strawman is
<nephele_xmpp>
No, arguing about a correct implementatiion is not a strawman
<nephele_xmpp>
I think color drops are the correct way to do this, you may disagree but that doesn’t make it a strawman
<waddlesplash>
I meant the definition, not necessarily the application
<Skipp_OSX>
DeskCalc demonstrates that you can have color drops _AND_ use a color constant to set the color.
HaikuUser has joined #haiku
HaikuUser has quit []
<Skipp_OSX>
But I've said all this already so I don't know why I'm arguing it again...
HaikuUser has joined #haiku
<nephele_xmpp>
yes, and it uses control colors because it is a control, while the clock is also a control… and now uses a different color
<Skipp_OSX>
I think nothing uses control color except buttons...
<nephele_xmpp>
In any case, we disagree here. Done. And let’s drop it here
HaikuUser has quit []
<nephele_xmpp>
hand cursor on hover for the clock would be nice, as would color drops, for the future.
<Skipp_OSX>
I would like you to accept my argument.
<nephele_xmpp>
I think overloading a color constant with a semantic meaning is a bad idea. Regardless of how it interacts with color drops
<Skipp_OSX>
right see, now we're past the strawman
<nephele_xmpp>
It’s still not a strawman
<nephele_xmpp>
Stop claiming that
<Skipp_OSX>
ok well, the other argument then
<Skipp_OSX>
the color drop thing
frkazoid333 has quit [Read error: Connection reset by peer]
<nephele_xmpp>
The thing is, this is a control, but you don’t want it to look like one. That is the main problem here
<waddlesplash>
I wouldn't mind it using control colors, probably
<waddlesplash>
document colors also seem fine tho
<nephele_xmpp>
if you can’t use color constants without either a) ignoring them or b) ignoring their semantic meaning, the only thing that remains iis color drops
<Skipp_OSX>
the real problem is I don't want to change the default control color to make it work because stuff is relying on it.
<nephele_xmpp>
we can change default colors, or the implementation in haikucontrollook as we want
<Skipp_OSX>
well i't probably not, really we'd just have to change button and then we could change the control color.
<Skipp_OSX>
yeah we can, I'm reluctant to do so as it's been that way a long long time, since BeOS times and so it might have unintended consequences.
frkazoid333 has joined #haiku
<nephele_xmpp>
Yes, but those consequences are things we have to fix regardless if we want to support the dark mode
<waddlesplash>
the control color really needs to be changed yes
<waddlesplash>
seeing as most things that use it heavily tint it
<waddlesplash>
which is kind of not the point
<Skipp_OSX>
I'm not opposed to that, the control color does seem like the right thing to use for controls.
<nephele_xmpp>
Yeah, but we should adjust it to be closer to what controls look like if waddlesplash is right with the current heavy tinting
<nephele_xmpp>
In any case, I also like to work on rendering stuff based on colors. And if you want to change the control color then go right ahead
<Skipp_OSX>
The way I understand it it's the color of the background inside the control, so basically just for buttons.
<nephele_xmpp>
and also for scrollbars, knobs etc
<nephele_xmpp>
sliders too
<nephele_xmpp>
tabs
AlienSoldier has joined #haiku
<nephele_xmpp>
comboboxes
<nephele_xmpp>
as a side note: webkit still implements scrollbars itself instead of asking the controllook to draw it :/
<Skipp_OSX>
well it's not actually used there but perhaps it should be
<Skipp_OSX>
The only place currently using B_CONTROL_DOCUMENT_COLOR is BButton, and yeah it's tinted
<Skipp_OSX>
err B_CONTROL_BACKGORUND_COLOR I mean
<nephele_xmpp>
its used for scrollbars
<nephele_xmpp>
because scrollbars call the button background drawing
DKnoto has quit [Ping timeout: 480 seconds]
<nephele_xmpp>
and i think same for comboboxes, but not sure about that one
<Skipp_OSX>
uhhhh ok I don't think so but maybe
<Begasus>
closing down
<Begasus>
cu peeps
Begasus has quit [Quit: Vision[]: i've been blurred!]
<nephele_xmpp>
huh, it seems it doesnt do that in haikucontrollook, but it does the same thing in webkit. wierd
<nephele_xmpp>
now i’m confused xD
<nephele_xmpp>
in any case, the controllook properly draws only with the passed colors
<nephele_xmpp>
so that should be fine
<Skipp_OSX>
Well we should probably update to use control color where that makes semantic sense, but we'd have to change the color first, and the clock still wouldn't use it unless we tinted because it's not white...
<nephele_xmpp>
Yes, so either we change the clock appearence, or we shouldn’t use semantic colors for it :)
<nephele_xmpp>
it seems B_PANEL_BACKGROUND_COLOR is used for severall controls?
<Skipp_OSX>
well that makes sense though, for the outside of the control, control background only for the inside.
<nephele_xmpp>
even the controllooktest uses panel background to draw buttons with. lol
<Skipp_OSX>
:/
DKnoto has joined #haiku
FreeFull has joined #haiku
<Skipp_OSX>
because we want panel color even though it's semantically not the right thing to do we're doing it anyway.
<Skipp_OSX>
Except in BButton, but we tint control background color to get it to be panel background color again, approximately.
<nephele_xmpp>
I guess, change the control color a bit and then move over things
<nephele_xmpp>
afterwards we can figure out if we want to change the panel color a bit aswell
<nephele_xmpp>
by the way, the deskbar also used to just modify the menu color before using it, i had also removed that :)
* phschafft
adds a note to himself: NEVER make a joke about some argument in here again.
<Skipp_OSX>
You opened a can of bees, but hey it worked, we're one step closer now.
thelounge917 has quit []
thelounge917 has joined #haiku
B2IA has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
PetePete has quit [Ping timeout: 480 seconds]
Hiryu has joined #haiku
<zdykstra>
I didn't know bees came in cans
<Hiryu>
I'm attempting to build Haiku on MacOS (been doing it on Linux for a while). I'm getting attribute creation failues: Error: Failed to create attribute "BEOS:TYPE" of file "data/licenses/IJG": Permission denied
<Hiryu>
any idea what's wrong?
<nephele_xmpp>
does that actually exiist?
<nephele_xmpp>
the fiile it wants to set an atribute on
<Hiryu>
Hmm. Good question. Scrolling up, I see a bunch of errors relating to not finding stdlib.h, ie: "cstdlib:79:15: fatal error: stdlib.h: No such file or directory"
<nephele_xmpp>
in particular the invocation of configure has changed since that article iiirc
<Hiryu>
Yes, it has. I had to make adjustments :D
<Hiryu>
yeah, seems the prereqs have changed a bit too
<nephele_xmpp>
probably zstd? :)
zardshard has left #haiku [#haiku]
<nephele_xmpp>
—use-xattr also doesnt seem to exist anymore
<Hiryu>
correct
<nephele_xmpp>
anyway, try -j1 so we can see the first error that happens, then open a ticket or maybe post the log here (using something like 0x0.st)
<nephele_xmpp>
i recall someone else mentioning problems on macos recently, but i have not tried myself on my macbook
<Hiryu>
trying again with the updated prereqs in cases it just works... Once that failes, I'll try with -j1
<nephele_xmpp>
-j 1 -q
<nephele_xmpp>
anyhow
dru_satori has joined #haiku
zardshard has joined #haiku
<Hiryu>
ack
<Anarchos>
i have a 'general protection fault' when trying to use _AcceptVisitor which is virtual method of BPartittion and BDiskDevice. It is in the stacktrace of LegacyBootMenu::CollectPartitions(), which is weird because LegacyBootMenu::CanBeInstalled has the same structure and doesn't segfault.
mmu_man has joined #haiku
<Hiryu>
well, no more stdlib.h missing errors at least
<Hiryu>
Fails on this first error: Error: Failed to create attribute "BEOS:TYPE" of file "develop/headers/c++/algorithm": Permission denied
<Anarchos>
nephele_xmpp "-j1" not "-j 1"
<dru_satori>
wee, first patch submitted.
* dru_satori
dons asbestos suit
<Hiryu>
Seems to exist: ./generated.x86_64/build_packages/gcc_syslibs_devel-13.3.0_2023_08_10-1-x86_64/develop/headers/c++/algorithm
x10z has joined #haiku
<Hiryu>
trying to determine how the attributes are even being set under MacOS
<Hiryu>
I'm able to set/get attributes manually via xattr...
nicoco has quit [Ping timeout: 480 seconds]
PetePete has joined #haiku
nicoco has joined #haiku
BlueSky76 has quit [Quit: WeeChat 3.8]
Chain|Q has quit [Quit: brb]
Chain|Q has joined #haiku
<nephele_xmpp>
Anarchos: I don’t see why that should matter...
<Anarchos>
Hiryu look at owner/group/persmissions of the file ?
<Anarchos>
nephele_xmpp i do'nt see either !
<nephele_xmpp>
dru_satori: agp_part? Is that in reference to AGP as in the graphhics card connector?
<Hiryu>
permissions are fine :D
<nephele_xmpp>
Hiryu: can you upload the log to https://0x0.st or similar service?
<Hiryu>
Will do
mmu_man has quit [Ping timeout: 480 seconds]
<dru_satori>
@nepehlele_xmpp yes, the bus and the driver have to be updated in sync or the driver never picks up the card
<dru_satori>
( that took me a while to figure out )
<nephele_xmpp>
I’m just a little confused about the file name, agp isn’t on boards that these cpus would run on? though maybe there is still some internal detail I am unaware off
<dru_satori>
so, the change impacts both the add-ons/kernel/busses/agp_gart and add-ons/kernel/drivers/graphics/intel_extreme
<dru_satori>
from what I can tell, even though the GPU's are integrated, they are managed as if they are attached via an AGP bus
<dru_satori>
so they go in lock step
<nephele_xmpp>
well, PCI also is handled in that file. Anyhow, graphics drivers are not my area of expertise :)
<dru_satori>
for the most part, I just echoed the TigerLake implementation, to which this is nearly identical
<nephele_xmpp>
patch looks good otherwise, you can ignore the spam from the format bot
<dru_satori>
I figure this will be Pulko and or waddle
<nephele_xmpp>
Do you have hardware that was fixed by this?
<Skipp_OSX>
looks ok to me, I was going to complain about tabs but there's no consistency in the file nvm.
<dru_satori>
I do.
mmu_man has joined #haiku
<dru_satori>
both of those chipsets
<nephele_xmpp>
Neat
<dru_satori>
hence the reason I could test both
<dru_satori>
ultimately, the N version is the goal as it is a nearly perfect Haiku box. Sadly it's wireless card is going to take a bit more work to get right
<dru_satori>
silly MEdiaTek cards
<Skipp_OSX>
well at least it's not Broadcom so there's a chance
BlueSky76 has joined #haiku
<dru_satori>
I've got source from a FreeBSD implementation as a reference.
<nephele_xmpp>
what is the INTEL_PCH_ADP -> INTEL_PCH_TGP about?
<Skipp_OSX>
I also asked on ticket, looks like a mistake but maybe that's on purpose?
<dru_satori>
seemed silly to duplicate the defines throughout, when they are functionally identical, despite the generation bump on the chipset
<dru_satori>
so, mapping it to the TigerLake
<nephele_xmpp>
Hmm, I’d rather have it make a distinction, even when the final code can treat them the same
<nephele_xmpp>
there might be other differences the current code does not have to deal with yet
<Skipp_OSX>
yeah no good reason to change it
<dru_satori>
fwiw, this is the device I'm targetting that has the mediatek
<nephele_xmpp>
dru_satori: you don’t *need* to write a driver based on the FreeBSD one
<dru_satori>
yeah, if_mwx.c, I've been using that code as a reference point
<nephele_xmpp>
because, we already steal drivers as-is from FreeBSD
<nephele_xmpp>
and have a freebsd wifi driver compat layer
<Skipp_OSX>
right it's just the best place to port drivers from
<dru_satori>
not *quite* as is. looking at some, there is a little bit of glue to go in to make things work.
<nephele_xmpp>
Native drivers are cool, but at this point with drivers from FreeBSD and OpenBSD, and FreeBSD wanting to port from us and OpenBSD, maybe we can get to a point of having common drivers for this stuff ;)
<nephele_xmpp>
Yes there is, I’ve not looked too closely at the glue
<Skipp_OSX>
looks like there may be an OpenBSD driver in the works as well
<nephele_xmpp>
waddlesplash: with the FreeBSD desktop improvement project maybe we can indeed colaborate more directly with both of them. Any thoughts?
<nephele_xmpp>
dru_satori, anyhow your patch looks mostly okay, but add some defines for tiger lake aswell please, so those can be identified properly
<dru_satori>
Skipp_OSX same codebase for both drivers
<Skipp_OSX>
yeah, figures
<waddlesplash>
nephele_xmpp: I remain in contact with FreeBSD WiFi devs and occasionally OpenBSD ones
<nephele_xmpp>
For example the cpu monitor applet has seperate graphics for each processor generation, so recognizing this properly is wanted
<waddlesplash>
and I keep tabs on those projects yes
<dru_satori>
nephele I'll tackle that shortly :)
<nephele_xmpp>
waddlesplash: I figure reducing the differences in this space so we can pool ressources would be cool, I’m happy you are keeping in touch!
<dru_satori>
although, music bingo at the brewery calls in 45 minutes...
<nephele_xmpp>
the patch isn’t running away
<nephele_xmpp>
:)
<dru_satori>
i dunno. sometimes code magically breaks when ignored too long
gouchi has quit [Quit: Quitte]
x10z has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
digitalbox98 has joined #haiku
digitalbox98 has quit []
x10z has joined #haiku
<dru_satori>
now I remember why I went back to the TGL definitions.
x10z has quit []
<dru_satori>
duplicating the entire TGL_PLL_* defines, since both TigerLake and AlderLake are technically Gen12 chipsets.
<dru_satori>
I think I see how to do this and keep it simple.
<nephele_xmpp>
does this command work on it’s own?
<nephele_xmpp>
this should be build for on-the-host, and work as the package tool does
<Hiryu>
Here's an example of how the command is run that reproduces the error: DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Users/hiryu/haiku/haiku/generated.x86_64/objects/darwin/lib" objects/darwin/arm64/release/tools/package/package extract -C "build_packages/gcc_syslibs_devel-13.3.0_2023_08_10-1-x86_64" download/gcc_syslibs_devel-13.3.0_2023_08_10-1-x86_64.hpkg
<nephele_xmpp>
oh, so this is output from package? the error: line?
<Hiryu>
yes, it works on its own without the arguments
<nephele_xmpp>
hmm, wonder if macos has an equivalent to strace
<Hiryu>
That's the command that gets run, I was able to grab it by adding "-dx" to jam
<Hiryu>
it doesn't have strace, even via brew, I already looked. And there's not debugging or verbosity args for "package" :(
<Hiryu>
There's dtrace, but I'm not really familiar with it
<nephele_xmpp>
dtrace works like in FreeBSD
<Hiryu>
I don't know it in dtrace or Solaris either :D
<Hiryu>
er, in FreeBSD
<nephele_xmpp>
I hear many good things about it! Not that I know how to use it either
<Hiryu>
strace is one of my gotos for this sort of thing, but not available for this platform sadly
<nephele_xmpp>
I will check this out once i can get to the M1 pc :)
<nephele_xmpp>
Anyhow, if you don’t mind you can create a ticket with this info: building on macos on apple ARM, build fails to extract the package: package tool fails with the same invocation with this
<Hiryu>
nephele_xmpp: Would I do that here? https://dev.haiku-os.org/ (looks like Trac! I haven't seen or set that up in a while!)
<nephele_xmpp>
Yes, it’s trac
<nephele_xmpp>
I’ve not used trac before working on Haiku, but I learned to apreciate it :)
chaosDNA has joined #haiku
<Hiryu>
nephele_xmpp: I set it up back in the 2000's as we needed both a wiki and a ticketing system :D
<nephele_xmpp>
well, the wiki part is getting more and more replaced with proper docs for us, but there is still quite interesting stuff there (like we keep wiki pages for each release noting down which news mentioned us :D)
<Hiryu>
now the best captcha...
<Hiryu>
*not
<Hiryu>
I can't create tickets. I get a 403 error with a message in haiku format hahaha
<Hiryu>
oh I think I have to verify my email
<nephele_xmpp>
Not the best? but why not?
<nephele_xmpp>
people keep entering HaikuOS and then asking on the forums why it doesn’t work
<nephele_xmpp>
Funnily enough someone mentioned another captcha in another chhannel right now, pehaps you’d prefer it :D
chaosDNA has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
lol took me a few times to pass that captcha
<Hiryu>
nephele_xmpp: I saw a horrible low res captcha blown up to be larger and it was very difficult to read all the letters, and took me multiple tries. One of the harder captchas I've ever had to deal with
<nephele_xmpp>
oh, i thought you ment our *other* captcha
<nephele_xmpp>
that just asks the question “What operatingg system are you trying to report a bug for?”
<nephele_xmpp>
but image captchas nowadays are hard for humanss and by now easy for robots
<nephele_xmpp>
so eh. not a great fit
<Hiryu>
I typed for that "Haiku", and it said I failed
<nephele_xmpp>
did you actually try to compile beta5 or a recent revision?
<nephele_xmpp>
asking since your ticket has beta5 set as version
<Hiryu>
a recent revision, I'll fix that
<Hiryu>
I don't see that I can update that
<nephele_xmpp>
I can do that :) what revision was it?
<Hiryu>
cc389ab3149a78b269795364eda30995ce918546
<nephele_xmpp>
hrev58538, okay :)
<nephele_xmpp>
we tag each commit (or group of simultanious merged commits) with an ascending revision number
<nephele_xmpp>
makes it a bit easier to reason about when something was introduced
<Skipp_OSX>
the devs at the time were insistent when we moved from svn to git that we maintain an incrementing revision
wicknix has joined #haiku
<Hiryu>
ah, I see it as a tag now
<Hiryu>
Skipp_OSX: makes sense to me. Git's hashes can be... confusing.
<Skipp_OSX>
Sourcetree has been updated in the meantime to be able to handle 10s of thousands of tags that we use
<Hiryu>
I remember pulling haiku with svn back in the day
<Hiryu>
where has all the time gone?
<Skipp_OSX>
4 alphas and 5 betas so far
<nephele_xmpp>
hmm, wikipedia gives confliicting info when haiku got started
<Hiryu>
the project should offer coffee mugs again... I had a really nice mug I got for donating but my kids broke it... This was over a decade ago :D
<Skipp_OSX>
Our commit logs say Jul 9 2002
<nephele_xmpp>
crazy
<Hiryu>
I remember trying to follow development back in 02 when it was still called OpenBeos
<nephele_xmpp>
i’m like three years older than Haiku
<Skipp_OSX>
although that was the initial commit, there was a year of work that proceeded that.
<Hiryu>
What was the original source control system? CVS?
<Hiryu>
oh svn came out in 2000... I thought it came out years later
<Skipp_OSX>
I do not know what was version control used between 2001 and 2002, maybe nothing
<Hiryu>
svn was probably pretty primitive back then... and CVS is painful
<Skipp_OSX>
OpenTracker used CVS for sure
<Skipp_OSX>
Tracker was added to build May 23, 2005
<nephele_xmpp>
Hiryu: i had a coffee mug with haiku with this kind of transparent becoming iink when it becomes hot
<Hiryu>
I don't think I had that one... I remember the logo being consistently there
<nephele_xmpp>
but it started peeling off, so i stopped using it… didn’t really want to eat it
<nephele_xmpp>
Well, no, i got this myself once so “custom” printer
<nephele_xmpp>
I wanted to see if one can get visible-becoming ink iin different colors, so if you add hot coffee you can imitate the haiku boot screen ;)