<OscarL>
oh, they even have a Cray there! NOICE :-D
<OscarL>
A Kaypro too :-)
<OscarL>
lol @ the IBM PS/2 with a keylock! Totally forgot those where a thing for a time :-D
<OscarL>
I was reading about APE/Cosmopolitan the other day, and thought... I bet coolcoder613 would find this interesting. So... in case you haven't seen it yet: https://justine.lol/ape.html
<coolcoder613>
I have
<coolcoder613>
Can you try telnetting to ebmc.freemyip.com?
<scantysnax>
what port?
<scantysnax>
~> telnet ebmc.freemyip.com
<scantysnax>
Trying 59.102.30.231...
<scantysnax>
telnet: connect to address 59.102.30.231: Operation would block
<scantysnax>
telnet: Unable to connect to remote host
<OscarL>
timeout here.
<coolcoder613>
port 23
<scantysnax>
yeah, same thing.
<coolcoder613>
now try 2323
<scantysnax>
that worked
<OscarL>
:-D
<OscarL>
Users online: 3
<OscarL>
I call that a party.
<scantysnax>
i disconnected, it was super slow
<erysdren>
OscarL: do you know how to debug a segfault/crash/etc in a Haiku program? atleast a stack trace?
<OscarL>
did you get a .report file generated by Debugger?
<erysdren>
no, i havent tried that yet
<erysdren>
i want to figure out why SDL2 programs always segfault when closing
<OscarL>
SDL2 crashes are almost always related to a locking issue around GL.
<erysdren>
ah
<OscarL>
you should save the .report when offered by the crash-dialog (or use the Debugger, directly, I guess)
<scantysnax>
OscarL, what time is it on your end?
<OscarL>
scantysnax: 22:44
<scantysnax>
ah, okay, only one hour ahead of me.
<erysdren>
weirdly enough SDL3 is not segfaulting
<OscarL>
erysdren: usual crashes with SDL2 programs ported to Haiku... resizing/maximizing/closing window :-D
dalme_ has quit [Remote host closed the connection]
<erysdren>
OscarL: you mentioned hrev57794, my QEMU Haiku VM is on a newer hrev than that, i wonder if i could just dd the VM to a usb or CD :P
<erysdren>
instead of having to go thru the install process, which i can't even get to
<OscarL>
You could use the installer from your QEMU VM, installing it into an USB pendrive.
<erysdren>
also true
<OscarL>
I've done the same, but from VBox.
<OscarL>
if you can move the HDD/SDD, and pass that to the VM... that should also work.
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
AlienSoldier has quit [Quit: Vision[]: i've been blurred!]
SLema has quit [Quit: WeeChat 3.8]
PetePete has quit [Ping timeout: 480 seconds]
SLema has joined #haiku
SLema has quit []
SLema has joined #haiku
SLema has quit [Quit: Vision[]: i've been blurred!]
SLema has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
akash has quit [Quit: Connection closed for inactivity]
MisthaLu has joined #haiku
Begasus has joined #haiku
<Begasus>
g'morning peeps
Calisto has joined #haiku
<Calisto>
Heyyy
<Begasus>
Hi Calisto
<Calisto>
Hi Begasus
<Calisto>
Good morning :D
<Calisto>
How are you doing today?
<Begasus>
fine, just starting up here :)
<Calisto>
yup
<Begasus>
how is it going there, solved the issue at gerrit?
<Calisto>
yup
<Calisto>
it compiled it just fine :D
<Begasus>
nice
<Begasus>
+1
<Calisto>
the static_cast<int32> worked :)
<Calisto>
just waiting for the reviews to be done now :)
<Calisto>
also posted the blog to the github haiku website :D
<Begasus>
no harm in continueing with other things related? ;)
<Begasus>
cool, will check it out later
<Calisto>
nope. I'll be continuing the folder filter now :)
<Calisto>
especially since waddlesplash gave a bit of clarity on why a general filter doesn't fit into C++ style of code
<Calisto>
so I'll be sticking to a specific Folder Filter :)
<Begasus>
yeah, saw quite some conversation on IRC yesterday
<Calisto>
yup :D
<Calisto>
well i'd better get started on that then :) i managed the front-end part of it on the Find panel.. now I'll be adding in the filter at the Pose View Level :)
carlomon2e has joined #haiku
<Begasus>
should give it a spin at one point I guess :)
<OscarL>
k. I got the updated mandoc patchset as close as the original as I can.
<OscarL>
but I think that patchset had problems since its first version.
<OscarL>
mandoc.db files are created, but not properly found/loaded. and man always ends up scanning the filesystem for the man pages.
<Begasus>
nice!
<OscarL>
Not sure I'll be able to to fix it properly, thou. Given my skills... too much effort for just a harmless warning, and a bit of extra time before the man page is rendered.
<Begasus>
Error: This rockspec for Lanes does not support haiku, unix platforms. ... tss
xet7 has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
Nephele has quit [Quit: Vision[]: i've been blurred!]
Nephele has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
<Begasus>
note to self: don't use Alt-Fn when qemu is running ...
<phschafft>
hm?
<Begasus>
it switches host Desktops, but screws up keybindings inside qemu
Nephele has quit [Quit: This computer has gone to sleep]
HaikuUser has joined #haiku
<phschafft>
hm.
<Begasus>
tasty cookies again? :P
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
ty3r0x_ has quit []
ty3r0x has joined #haiku
FreeFull has quit [Ping timeout: 480 seconds]
Nephele has joined #haiku
Begasus_32 has joined #haiku
<Nephele>
Begasus: probably you need to press alt again in qemu to fix this
<Habbie>
right, haiku probably missed the alt release event
CalistoMathias has joined #haiku
Calisto has quit [Ping timeout: 480 seconds]
Nephele has quit [Quit: This computer has gone to sleep]
<phschafft>
Begasus: as always. also checked yesterday, they're actually from Vienna.
Calisto_Mathias has joined #haiku
Nephele has joined #haiku
<phschafft>
nephele: I was checking on find_directory() after your comment.
CalistoMathias has quit [Ping timeout: 480 seconds]
<Nephele>
:)
<phschafft>
I was wondering a bit about that concept since years.
<phschafft>
I must say that the Haiku API is better than most.
<phschafft>
but I personally would do it a little different.
novaphoenix has quit [Quit: gone fishing]
<Nephele>
a little?
<phschafft>
there are two main difference I think:
novaphoenix has joined #haiku
<phschafft>
0) I would always return handles, not path names. path names are such a mess t work with resulting in all strange effects (from race conditions to stuff breaking on chroot/mount/namespaces).
<phschafft>
1) in a sense of 'everything is a file' make it a bit more universal. e.g. allowing to locate some important system services as well.
<Nephele>
what do you mean by system services?
<phschafft>
for example:
<phschafft>
several operating systems worked out ways to overcome the problem of a random device not being around when chrooting a process for security. specifically if you work with crypto stuff you may want high level of isolation AND access to a random device of some kind.
<phschafft>
if such a call would implement both 0) and 1) it could provide access to a open handle to a random device even within such a restricted env.
<Nephele>
the solution to this kind of problem seems to be to not use a file in the first place
<phschafft>
and access to such services could be easily limited by simple ACLs. at least on a basic level which is often already a big step forward from 'hey, look, over there is /dev!' ;)
<Nephele>
find_directory currently only returns directories anyhow
<phschafft>
nephele: maybe it is still a file or maybe not. but as long as you can access a handle for it it just doesn't matter. which would make it fit into many operating systems.
<Nephele>
Not direct files
<phschafft>
nephele: yes. but you asked what I would change. now how it is. ;)
<Nephele>
Well, in my view what you prosose sounds like a good api /next to/ find_directory ;)
<Nephele>
for example for configuration files you could ask it for the file handle then and never have to deal with figuring out what the correct location is in the directory
<phschafft>
not sure about that (however clearly not wanting to remove anything that is considerd stable API).
<Nephele>
well considering we can't just change the return type of find_directory and the usecase and specifics are different i would not call it the same thing
<Nephele>
especially since it does neither find anything nor find directories then
<Nephele>
since the location then becomes irrelevant
<Begasus>
will check on the next run nephele, thanks for the pointer :)
<Begasus>
Habbie, I think I got it working well enough now for lua/luarocks :)
<Nephele>
Habbie, probably not missed but not send to qemu
<phschafft>
nephele: again, not saying that it is a direct replacement of find_directory() but a new generation solution to the same problem.
<Nephele>
sure
* Begasus
wonders why we need luarocks_x86
<phschafft>
one would also need to check the status on *at() to see how to best go for it in any OS.
<phschafft>
some systems are a bit behind with the *at() system call variants.
<Nephele>
Well, one problem your api has is that if i want to return the *correct* settings handle I need to know the mimetype of the application
<Nephele>
in the C++ api this is easy and known
zard has joined #haiku
<Nephele>
in the C api however it is not. So likely would require C apps to pass their mimetype or something
<phschafft>
why is it a problem on the C side but not the C++ side?
<Nephele>
Because in order to have a BApplication you already need to have your mimetype specified
<Nephele>
in most cases (in all if you have gui apps) this is already the case, so can be dealt with more easily
<phschafft>
yes, but how is that different for both worlds?
<Nephele>
You will never have the mimetype known beforehand for the C version
<Nephele>
so you can't make a version of the api that does not require it
<phschafft>
and how do you know it from the C++ world?
<phschafft>
is it in some global storage?
<Nephele>
BApplication object
HaikuUser has joined #haiku
HaikuUser has quit []
<phschafft>
and that is a global singleton?
<phschafft>
ah, I see: The BApplication object is automatically assigned to the global be_app variable. The be_app variable allows you to refer to your BApplication object from anywhere in the code.
<phschafft>
so, why not just provide a call to allow creation of that very object from the C side?
<Nephele>
why would you? what's the point of using it in C?
<phschafft>
I don't know. you said it is needed for find_directory() to work?
<phschafft>
I'm really just trying to understand your point.
mmu_man has quit [Ping timeout: 480 seconds]
<Nephele>
No, find_directory works as is from C since you only pass it constants for directories you want
<Nephele>
in your example api if you want a handle to a settings file directly (not the directory) then the api would need to get this mimetype from the application to return the correct application specific settings file
<Nephele>
or handle, anyhow
<phschafft>
I mean sure, a function needs all the parameters it needs to work?
<phschafft>
so, what's the problem?
<Nephele>
yes, and in the C++ api we already have the mimetype available so we can simply do get_handle_for(kSettings)
<Nephele>
while in the C api you would need to to get_handle_for(kSettings, myMimeType) and a shorthand would not be available at all :)
<phschafft>
sure, the same functionallity will have a different interface in different languages.
<phschafft>
and if you want a short hand, just add one.
<Nephele>
yes, that was all i was saying
mmu_man has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
MisthaLu has joined #haiku
Nephele has quit [Quit: This computer has gone to sleep]
PetePete has joined #haiku
<Begasus>
why!!! :/ luarocks doesn't seem to respect datarootdir on 32bit it seems
PetePete has quit [Ping timeout: 480 seconds]
Nephele has joined #haiku
UW_Mill has joined #haiku
<Begasus>
k, fixed ... now LUA_NOBUILTIN=1 doesn't seem to take effect on 32bit
<zard>
2. Not an expert there, but I believe app_server is responsible for the GUI
Nephele has joined #haiku
<JME[m]>
@zard so somewhere some code explicitly calls/starts app_server?
<zard>
That is launched by the launch_daemon, which afaik is our init system
<zard>
You can play with the launch_daemon using the launch_roster command
<Nephele>
It depends what documentation you want to update. If it is stored in the source tree you can send a change request (Not a PR) to gerrit
<zard>
Right. If the documentation is in the main repo, you'll want to push the changes to Gerrit
<zard>
If it's in the website repo, you'll want to use GitHub
<JME[m]>
>> You can play with the launch_daemon using the launch_roster command.
<JME[m]>
Can one set another app to run as the main task? I know this sounds odd.
<Nephele>
in theory you could, but the system is not designed to operate like this. expect the userland to break if you try that
<Nephele>
the question would be why you want to replace app_server, what are you trying to achieve?
<JME[m]>
nephele: thx. indeed. imagine one was trying to run a different userland.
<Nephele>
... why?
<JME[m]>
the eternal question.
<Nephele>
Well it boils down to this, like BSD haikus kernel and userland are deeply integrated. You probably can rip it out with enough effort and time, but you wouldn't really gain anything
<Nephele>
just using a different kernel that is designed to operate like this for example minix 3 or linux would be much easier and faster
HaikuUser has joined #haiku
HaikuUser has quit []
<phschafft>
nephele: what's your status later today?
<Nephele>
when is later?
<phschafft>
after dinner.
<phschafft>
(which is not yet on the stove)
<Nephele>
hmm, would be pretty late, i think tommorow or next week would be better then